目录
背景
做为跨语言的rpc框架,gRPC深受大众的喜爱,但不同于dubbo的生态,目前比较少有较好的多服务可视化测试gRPC的工具。现有的几款工具做一下对比:
BloomRPC | gRPC UI | grpcurl | grpc-swagger |
https://github.com/bloomrpc/bloomrpc | GitHub - fullstorydev/grpcui: An interactive web UI for gRPC, along the lines of postman | https://github.com/fullstorydev/grpcurl | https://gitee.com/grpc-swagger/grpc-swagger |
可视化界面 不需要开启反射 需要proto文件 单服务 | 可视化界面 需要开启反射 不需要proto文件 单服务 | 命令行工具 需要开启反射 不需要proto文件 单服务 | 可视化界面 需要开发反射 不需要proto文件 单服务 对nodejs支持不友好 |
工具看起来也不少,对于开发同学来说做本地调试也够用了,但是对于集成测试和协作来说,就相当不方便,例如:
- 做接口自动化测试:没有办法直接通过http来进行测试,使用上面的工具很难达到这个目的
- 做协同联调:无可视化接口检测工具,只能盲调
另外,以上的工具都是单服务工具,如果要对多个服务进行调试,那需要每次进行配置修改的启动,极大的影响了效率。
解决方案
对以上的几款工具进行源码和原理分析,后三者都是直接利用服务的反射来进行测试的工具,使用比较便捷,因此选择后面三种来进行二次改造。
改造过程中发现,grpc-swagger对java语言的gRPC服务兼容性较好,但对于nodejs语言的服务兼容性不太好,因此选择了gRPC UI进行二次改造,进行多服务支持的改造。
整体服务架构
获取服务信息
参考的是grpcurl的原理机制,gRPC服务开启反射之后,可以通过grpcurl进行调试后,进行如上图操作,建立rpc链接,获取反射链接,获取服务信息,方法清单。
参考此流程,我们即可将整个流程封装为一个rest请求,请求的入参就是服务域:端口,这样就可以支持多域名的服务信息获取了。
获取服务方法信息
获取到服务清单之后,结合grpcurl的GetAllFiles方法我们即可获取到方法文件定义,进行解析和匹配就可以获取到具体方法的类似proto的描述和定义了
可视化操作
当获取到方法定义之后,可以对gRPC UI的可视化展示进行二次改造,保留方法定义展示的两个界面,form和json请求界面、返回界面,提供更友好的可视化展示效果。只需要使用到三个文件即可:webform.js、webform-sample.css、webform-template.html
发起请求
参考grpcurl的使用,进行服务请求,使用的是grpcurl.InvokeRPC,具体的参数如下:
ctx context.Context, source DescriptorSource, ch grpcdynamic.Channel, methodName string,headers []string, handler InvocationEventHandler, requestData RequestSupplier
从gRPC UI中我们可以沿用具体的方法InvokeRPC进行改写:传入服务域名:端口、方法名;创建gRPC链接;获取方法定义;传入body信息即可。
直接使用grpcurl.InvokeRPC的原因有两个:
- 可以通过反射获取方法定义参数,不需要proto
- body可以携带rpc的请求头信息,而不是在rest接口的header中携带,这样的好处是可以减少很多header的限制问题。
经过上面的改造,就可以搭建出一个支持多服务的可视化gPRC服务测试工具了,有兴趣的同学可以尝试一下,可以提高不少效率。