Grpc protobuf的动态加载及类型反射实战

前言:

我们这有几个grpc protobuf的特殊场景,开发的过程就是抓狂的过程,我期间把grpc的源代码和protobuf godoc api粗略看了一遍,又把grpc周边的组件过了一遍。😅 差不多把grpc和protobuf的动态访问及反射整明白了。
简单说就是你提供一个service/method 加 request json body, 我就可以帮你访问下游的grpc server api,不需要你引入import go pb,不管下游grpc server是unary还是stream模式。

该文章后续仍在不断的更新修改中, 请移步到原文地址  http://xiaorui.cc/?p=5815

哪几个场景?

第一个场景

动态的pb类型装换,场景是一个gateway网关,他会把接收到的grpc的请求组装到消息总线里,然后等待结果返回给grpc client客户端。
核心问题点是,如何动态的把grpc请求的protobuf转换成特殊的消息类型,然后再把接收到的请求返回给客户端。
最简单的方法是静态注册,我们一个个的定义好输入和输出的类型,然后再一个个的register注册。但是这样就涉及到一个问题,下游服务加了一个接口,那么每次上线都需要改代码。

// xiaorui.cc
func (s *Server) StaticRegister() {
	account.RegisterAccountServer(s.gs, &service.AccountServer{})
	asset.RegisterAssetsServer(s.gs, &service.AssetsServer{})
	trade.RegisterTradeServer(s.gs, &service.TradeServer{})
	sys.RegisterSystemServer(s.gs, &service.SystemServer{})
...

func (s *SystemServer) GetSystemConfig(ctx context.Context, _ *common.Empty) (*sysp.SystemConfig, error) {
	return &sysp.SystemConfig{}, nil
}

func (s *SystemServer) GetSymbolConfig(ctx context.Context, _ *common.Empty) (*sysp.SymbolList, error) {
	return &sysp.SymbolList{}, nil
}

如何不改代码怎么实现动态的grpc注册?
protobuf有个descriptor描述符概念,描述符里会记录每个service / method的pb类型。

第二个场景

动态访问的逻辑,我这边已经用grpc stream实现了一个基于grpc协议的行情推送,内部使用完全没问题,但是让外面人去学习使用grpc的话,学习成本相对高。社区对于实时的api大多使用websocket。为了避免重复开发行情推送,那么我做了一个websocket2grpc的proxy代理层。
websocket代理层逻辑很简单,就是代理websocket协议去访问grpc stream bidi模式。
这里涉及到一个问题,就是需要在proxy层使用grpc client连接后端的grpc stream server。

如果下游不断的增加接口,那么我就需要不断的更改proxy的代码?
如何做到根据service/method和request json body,就可以访问下游服务?
社区里有个老外开源了grpc stub的反射访问库,https://github.com/jhump/protoreflect

开源grpcall模块

为了解决上面的问题,我自己封装了grpcall库,我们可以根据service/method获取所有的输入输出类型(protobuf),及通过stub动态构建客户端访问,及解析返回的结果。
开始开发grpcall的时候真是没啥思路,但是看了envoy,grpc-gateway源码后,真是豁然开朗。所以,grpcall里理所当然的吸取了grpc-gateway和grpcurl的一些思路和部分代码。

下次找个时间给大家聊聊envoy和grpc-gateway的实现原理,envoy在http 2 grpc的实现里用了不少高级手段,但grpc-gateway就显得霸道了,直接构建了一堆堆的硬编码,可以简单的理解为通过模板来生成可以适配http和grpc的go代码。
简单可以说,要么各种reflect逻辑,要么直接像protoc那样生成硬代码。

http://xiaorui.cc

grpcall的代码已经扔到github里了,主功能从开发到测试也就花了两三天的时间,有兴趣的朋友可以看看,求个star https://github.com/rfyiamcool/grpcall

grpcall不仅实现了从descriptor动态解析类型,而且可以从grpc server的reflect api里获取类型数据并解析,但我们推荐使用descriptor描述符模式。对于grpc的动态方法调用,grpcall实现了grpc的四个模式,有unary,bidi, client stream, server stream模式。

http://xiaorui.cc

使用grpcall反射库,如何优化上线模式?

如果下游增加了api,或者业务的protobuf有更新,那么我们只需要重新生成protobuf descriptor文件,然后给grpcall传递一个sighup更新信号,那么grpcall会重新加载descriptor文件。 😁

这样避免了服务和连接的终端,当然你也可以使用graceful reload的方案来规避该问题。😅

性能如何?

因为在grpcall里加入了一些缓存逻辑,避免频繁的获取pb类型。使用grpc client池规避单个grpc client的竞争压力及提高tcp层的吞吐。
简单压测了一下,使用grpcall动态访问相比原生少了有5%左右的qps。

总结:

一般来说,开发的库包只要涉及到反射和动态转换的字眼,代码都相对难搞,像json呀,orm呀,template模板引擎。

由于项目前期催的太紧张,grpcall没有好好的打磨一番,几乎没啥文档,有些模块写的相对简陋。好在,代码量本身不多,另外我在testing目录里给出了一个测试的样例,大家可以参考下。 见谅 !!!


大家觉得文章对你有些作用! 如果想赏钱,可以用微信扫描下面的二维码,感谢!
另外再次标注博客原地址  xiaorui.cc