返回
Featured image of post gRPC 借助 Any 类型实现接口的泛化调用

gRPC 借助 Any 类型实现接口的泛化调用

我发现,人们非常喜欢在一件事情上反复横跳。譬如,以编程语言为例,人们喜欢静态的、强类型语言的严谨和安全,可难免会羡慕动态的、弱类型语言的自由和灵活。于是,在过去的这些年里,我们注意到,.NET 的世界里出现了 dynamic 类型,JavaScript 的世界里出现了 TypeScript,甚至连 Python 都开始支持类型标注。这种动与静、强与弱的角逐,隐隐然有种太极圆转、轮回不绝的感觉。果然,“城外的人想冲进去,城里的人想逃出来”,钱钟书先生说的固然是婚姻,可世上的事情,也许都差不多罢!人们反复横跳的样子,像极了「九品芝麻官」里的方唐镜。曾经有段时间,好多人吹捧 Vue3 + TypeScript 的技术栈,有位前辈一针见血地戳破了这种叶公好龙式的喜欢,“你那么喜欢 TypeScript,不还是关掉了 ESLint 的规则,项目里全部都用 Any”。对于这个吐槽,我表示非常真实,因为我们对于动与静、强与弱的心理变化是非常微妙的。常言道,“动态类型一时爽,代码重构火葬场”,你是如何看待编程语言里的动与静静、强与弱的呢?在 gRPC 中我们通过 Protobuf 来描述接口的参数和返回值,由此对服务提供/消费方进行约束。此时,参数和返回值都是静态的、强类型的。如果我们希望提供某种“泛型”的接口,又该如何去做呢?所以,这篇文章我们来聊聊 gPRC 里的 Any 类型。

Protobuf 里的 Any 类型

在讲 Any 类型前,我想,我们应该想明白,为什么需要这样一个类型?现在,假设我们有下面的 Protobuf 定义:

 1// Vehicle
 2message Vehicle {
 3  int32 VehicleId = 1;
 4  string FleetNo = 2;
 5}
 6
 7// Officer
 8message Officer {
 9  int32 OfficerId = 1;
10  string Department = 2;
11} 

此时,按照Protobuf的规范,我们必须像下面这样定义对应的集合:

1// VehicleList
2message VehicleList {
3  repeated Vehicle List = 1;
4}
5
6// OfficerList
7message OfficerList {
8  repeated Officer List = 1;
9} 

考虑到,在C# 中我们只需要使用 List<Vehicle>List<Officer> 即可,这样难免就会形成一种割裂感,因为你几乎要为每一种类型建立对应的表示集合的类型,从语义化的角度考虑,我们更希望使用下面的 Protobuf 定义:

1message Collection {
2  repeated Any List = 1;
3}

此时,VehicleListOfficerList 就可以统一到 Collection 这个类型中,这样,不但减少了花在类型定义的时间,更能帮助我们打开一点思路。在过去,我们编写 API 的时候,通常会定义下面的类来返回结果:

1public class ApiResult<TData> {
2  public int Code { get; set; }
3  public string Msg { get; set; }
4  public TData Data { get; set; }
5}

类似地,当我们用 gPRC 来做微服务的时候,我们希望在 Protobuf 中沿用这个设计:

1message ApiResult {
2  int32 Code = 1;
3  string Msg = 2;
4  Any Data = 3;
5}

至此,它可以和我们在 C# 中的认知联系起来,不会让你有太多心智上的负担。基于上述两种诉求,我们发现, Protobuf 中存在着需要泛化的场景,你可以理解为,我们需要用 Protobuf 来表示泛型或者模板类这样的东西。幸运的是,Google 为我们定义了 Any 类型,它到底是何方神圣呢?我们一起来看看:

1message Any {
2  string type_url = 1;
3  bytes value = 2;
4}

没错,它就是这样的朴实无华,甚至比古天乐还要平平无奇,简单来说,type_url字段告诉你这是一个什么类型,value字段里则存放对应的二进制数据,而这就是 Any 类型的全部秘密!

在 .NET 中使用 Any 类型

好了,下面我们来演示,如何在 .NET 中使用 Any 类型。通过前面我们已经知道, Any 类型和我们自定义的消息没有区别,所以,它同样实现了 IMessageIMessage<Any>两个接口,唯一不同的地方在于,它拥有Pack()Unpack<T>()TryUnpack<T>()这样几个静态方法,这是实现任意 IMessageAny 相互转换的关键。现在,假设我们现在有如下的 Protobuf 定义:

 1message AnyRequest {
 2  google.protobuf.Any Data = 1; 
 3}
 4
 5message AnyResponse {
 6  google.protobuf.Any Data = 1;
 7}
 8
 9message Foo {
10  string Name = 1;
11}
12
13message Bar {
14  string Name = 1;
15}

此时,如果我们希望在 AnyRequest 或者 AnyResponse 里传递 Any 类型,我们可以这样做:

 1var anyRequest = new AnyRequest()
 2
 3// Foo -> Any,默认类型地址前缀
 4var foo = new Foo();
 5foo.Name = "Foo";
 6anyRequest.Data = Any.Pack(foo);
 7
 8// Bar -> Any, 自定义类型地址前缀
 9var bar = new Bar();
10bar.Name = "Bar";
11anyRequest.Data = Any.Pack(bar, "type.company.com/bar");

反过来,我们可以从 Any 中解析出 IMessage

 1if (request.Data.Is(Foo.Descriptor))
 2{
 3  // Any -> Foo
 4  var foo = request.Data.Unapck<Foo>();
 5} 
 6else if (request.Data.Is(Bar.Descriptor))
 7{
 8  // Any -> Bar
 9  var bar = request.Data.Unapck<Bar>();
10}

默认的 Any 类型,只能对 Protobuf 生成的类型(即实现了 IMessage 接口)进行 Pack ,如果我们想做得更绝一点(最好还是不要),那么,可以使用自定义的 MyAny 类型:

1message MyAny {
2  string TypeUrl = 1;
3  bytes Value = 2;
4}

相应地,我们为 MyAny 类型编写一点扩展方法:

 1public static class MyAnyExtension
 2{
 3    public static MyAny Pack(this object obj, string typeUrlPrefix = "")
 4    {
 5        var any = new MyAny();
 6        any.TypeUrl = $"{typeUrlPrefix}/{obj.GetType().FullName}";
 7        var bytes = Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(obj));
 8        any.Value = Google.Protobuf.ByteString.CopyFrom(bytes);
 9        return any;
10    }
11
12    public static T Unpack<T>(this MyAny any, string typeUrlPrefix = "")
13    {
14        var typeUrl = $"{typeUrlPrefix}/{typeof(T).FullName}";
15        if (typeUrl == any.TypeUrl)
16        {
17            var json = Encoding.UTF8.GetString(any.Value.ToByteArray());
18            return JsonConvert.DeserializeObject<T>(json);
19        }
20
21        return default(T);
22    }
23
24    public static bool Is<T>(this MyAny any, string typeUrlPrefix = "")
25    {
26        var typeUrl = $"{typeUrlPrefix}/{typeof(T).FullName}";
27        return typeUrl == any.TypeUrl;
28    }
29}

接下来,我们就可以对任意类型进行处理,虽然,此时此刻,从严格意义上来讲,它已不再属于 Protobuf 的范畴,因为序列化/反序列化都交给了 JSON :

1var client = serviceProvider.GetService<ProtobufAny.Greeter.GreeterClient>();
2client.Ping(new Foo() { Name = "Foo" }.Pack());
3client.Ping(new Bar() { Name = "Foo" }.Pack());
4client.Ping(new { X = 0, Y = 1, Z = 0 }.Pack());

这样看起来是不是非常酷?我始终认为,这件事情是有意义的,一个系统中最多的接口显然是查询接口,此时,我们可以构建一个通用的 查询 来处理,使用者只需要传递一个实体、一个Proto,一组过滤条件,它就可以返回对应的数据,这样是不是比写一个又一个差不多的接口要好一点呢?过去我们开发 API,主张用数据传输对象(DTO)来隔离持久化层和业务层,从这个角度来看,Protobuf 本身就是 一种 DTO ,对于大多数相似的、模板化的、套路化的接口,我们完全可以考虑用这种方案来实现,只要双方约定好类型即可。

 1// 在业务层构建通用的查询
 2public QueryReply Query<TInput, TOutput>(SearchParameters searchParameters) where TInput : class
 3{
 4    var result = _chinookContext.Set<TInput>().AsQueryable().Search(searchParameters).ToList();
 5    var output = result.Adapt<List<TOutput>>();
 6
 7    var reply = new QueryReply();
 8    reply.List.AddRange(output.Select(x => x.Pack()));
 9    return reply;
10}
11
12// x => { 1, 2, 3 }.Contains(x.AlbumId)
13var searchParameters = SearchParameters();
14searchParameters.QueryModel = new QueryModel();
15searchParameters.QueryModel.Add(new Condition() { Field = "AlbumId", Op = Operation.StdIn, Value = new int[] { 1, 2, 3} });
16
17// 在服务层解析参数,完全可以由调用方提供 SearchParameters
18var inputType = Type.GetType(request.InputType);
19var outputType = Type.GetType(request.OutputType);
20if (inputType != null && outputType != null)
21{
22    var queryMethod = _queryService.GetType().GetMethod("Query").MakeGenericMethod(inputType, outputType);
23    QueryReply queryResult = (QueryReply)queryMethod.Invoke(_queryService, new object[] { 
24      new DynamicSearch.Core.SearchParameters()
25    });
26    return Task.FromResult(queryResult);
27}

本文小结

对于编程语言中的动与静、强与弱,我个人觉得还是要看场景,只要双方定义好契约,我相信,它都可以运作起来,当然,更多的时候,我们是在灵活与严谨间反复横跳。作为一门 DSL,Protobuf 虽然可以对服务提供/消费方产生一定约束,可当我们面对需要泛型或者模板类的场景的时候,这种做法就变成了一种负担,更不必说它缺乏对继承的支持。想象一下,你要写二十多个大同小异的接口,譬如为每一张数据表写一个 GetXXXById() 的接口。此时,我们可以借助 Any 类型来实现类似泛型、模板类的东西,它本质上还是 IMessage 接口的实现类,唯一的不同是增加了 Pack/Unpack 这组静态方法,可以帮助我们实现 AnyIMessage 的相互转换,关于本文中使用的的实例,可以参考:ProtobufAny,好了,以上就是这篇博客的全部内容,如果有朋友对文章中的内容和观点存在疑问,欢迎在评论区积极留言,谢谢大家!

Built with Hugo
Theme Stack designed by Jimmy