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

Protobuf 里的 Any 类型

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

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

// Officer
message Officer {
int32 OfficerId = 1;
string Department = 2;
}

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

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

// OfficerList
message OfficerList {
repeated Officer List = 1;
}

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

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

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

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

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

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

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

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

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

在 .NET 中使用 Any 类型

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

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

message AnyResponse {
google.protobuf.Any Data = 1;
}

message Foo {
string Name = 1;
}

message Bar {
string Name = 1;
}

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

1
2
3
4
5
6
7
8
9
10
11
var anyRequest = new AnyRequest()

// Foo -> Any,默认类型地址前缀
var foo = new Foo();
foo.Name = "Foo";
anyRequest.Data = Any.Pack(foo);

// Bar -> Any, 自定义类型地址前缀
var bar = new Bar();
bar.Name = "Bar";
anyRequest.Data = Any.Pack(bar, "type.company.com/bar");

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

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

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

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

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

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

public static T Unpack<T>(this MyAny any, string typeUrlPrefix = "")
{
var typeUrl = $"{typeUrlPrefix}/{typeof(T).FullName}";
if (typeUrl == any.TypeUrl)
{
var json = Encoding.UTF8.GetString(any.Value.ToByteArray());
return JsonConvert.DeserializeObject<T>(json);
}

return default(T);
}

public static bool Is<T>(this MyAny any, string typeUrlPrefix = "")
{
var typeUrl = $"{typeUrlPrefix}/{typeof(T).FullName}";
return typeUrl == any.TypeUrl;
}
}

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// 在业务层构建通用的查询
public QueryReply Query<TInput, TOutput>(SearchParameters searchParameters) where TInput : class
{
var result = _chinookContext.Set<TInput>().AsQueryable().Search(searchParameters).ToList();
var output = result.Adapt<List<TOutput>>();

var reply = new QueryReply();
reply.List.AddRange(output.Select(x => x.Pack()));
return reply;
}

// x => { 1, 2, 3 }.Contains(x.AlbumId)
var searchParameters = SearchParameters();
searchParameters.QueryModel = new QueryModel();
searchParameters.QueryModel.Add(new Condition() { Field = "AlbumId", Op = Operation.StdIn, Value = new int[] { 1, 2, 3} });

// 在服务层解析参数,完全可以由调用方提供 SearchParameters
var inputType = Type.GetType(request.InputType);
var outputType = Type.GetType(request.OutputType);
if (inputType != null && outputType != null)
{
var queryMethod = _queryService.GetType().GetMethod("Query").MakeGenericMethod(inputType, outputType);
QueryReply queryResult = (QueryReply)queryMethod.Invoke(_queryService, new object[] {
new DynamicSearch.Core.SearchParameters()
});
return Task.FromResult(queryResult);
}

本文小结

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