大家好~我是
米洛
!
我正在从0到1打造一个开源的接口测试平台, 也在编写一套与之对应的教程
,希望大家多多支持。
欢迎关注我的公众号米洛的测开日记
,获取最新文章教程!
# 回顾
上节我们憋
出了消息中心相关的内容,质量较低,希望各位轻拍。今天我们来聊聊对于grpc支持的事情。
# 为什么要支持grpc
随着postman在新版本已经支持了GRPC
协议的接口调试功能,很多测试开发工程师表示可以"抄"起来了。由于之前公司有用到grpc,所以我在测试平台的设计之初就考虑过如何支持grpc协议的接口测试。为此我也调研,尝试了许多相关的工具。
# 痛难点
grpc最大的痛点我觉得有以下几个,如果都能完美支持
的话,那将会是一款很好用的调试工具。下面我将一一介绍这些痛难点。
- 参考资料少之又少
其实业内基于grpc实现的开源项目有不少,比如etcd
就是,但讲实话,可以参考的例子还真不多。以官网为例的话,grpc作为一款开源的rpc框架,官方文档更多的
介绍是在于如何用各种语言
实现一个grpc的demo。
比如我现在使用Python,进去看官网,都是比较简单的例子,有经典的hello项目,也有稍微进阶一点的stream。但无外乎都是那种demo代码,能跑,但是用于生产还差点火候
。
总结下来便是,资料少之又少,企业内部的实现五花八门,有改protoc插件,有用类似grpc-gateway实现的,但我们好像连个参考的方式都没有。
- 调用方式局限
以Python语言为例,我们如果想要去调用一个grpc
的方法,我们必须得拿到proto文件,并编译为pb文件,当然也可以只要编译好的pb文件,再根据pb里面的Client建立stub实例,以我上篇<<grpc从入门到放弃>>的demo代码为例:
import grpc
import hello_pb2
from hello_pb2_grpc import HelloStub
def run():
# 建立channel
with grpc.insecure_channel('localhost:50051') as channel:
# 获取到hello服务
stub = HelloStub(channel)
# 新建request请求数据
request = hello_pb2.Request(data="米洛")
# 调用hi方法
response = stub.hi(request)
# 打印返回的信息
print("Greeter client received: ", response.message)
if __name__ == '__main__':
run()
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
不难看出,我们需要先引入HelloStub
才能调用对应的方法。那问题来了,如果我接口多,拆分的服务也多,不同语种编写的方法也多,如果用Python调用go的服务端,那岂不是要让go的服务用python-grpc相关的protoc编译出stub,再进行调用?
那万一你用的是别人的服务,就会产生各种各样的问题(这些官网不知道找到没有,但我好像没发现相关的demo)。
总结下来,这样的方式是行不通的,但我似乎听说有部分公司要测试grpc接口的时候,会上传一个protoc的文件,进而生成对应的调用页面
或给出对应的调试方式。
当然这块内容也是有解决方法的,稍微我们会说到。
- 负载均衡相关
现在是微服务时代,我们的grpc服务肯定也是多节点部署
的。不同的公司采用的服务注册发现的工具肯定都不太一样,有zk/etcd/nacos/consul等。但grpc似乎只提供了很普通的负载均衡算法(robin),甚至这块的资料都特少(反正我是没太找到)。
以我之前公司为例,我们用的是zk管理服务注册与发现,测试平台为了支持grpc的调用,我们根据appid找到zk里面活跃的节点,并返回对应的机器ip和端口,而zk里面也有服务的接口相关信息等数据,会一并拉取下来。
# 但ip是变化的,不过企业内部会对服务有个group的区别,我们选择一般不会直接选ip,而是选group1或者group2,但这样一旦group1和2有故障(比如服务在发布)那就不太友好,所以还没完善的是智能选择服务可用的节点。
这样看来的话,作为一个测试工具,我们只用考虑
解决"grpc必须通过stub去调用"的问题就行了。由于篇幅有限。那我们下一节继续讲这块内容,目标是测试平台能够像使用http一样测试grpc接口。做到和类似postman一样的效果即可,当然如果要通用一点,我们可以配置zk/etcd等注册中心的地址,并配置节点路径,完成自动获取ip,智能调用等功能。
下节关键字: grpc_reflection