问题描述
我已经实现了2个服务A和B,其中A可以通过gRPC(使用带有Mali的grpc-node)和纯HTTP REST调用与B通讯。
请求大小可以忽略不计。
响应大小为1000个,如下所示:
{
"productId": "product-0","description": "some-text","price": {
"currency": "GBP","value": "12.99"
},"createdAt": "2020-07-12T18:03:46.443Z"
}
A和B都作为服务部署在GKE中,并且它们使用kube-proxy通过内部网络进行通信。
我发现REST版本比gRPC快很多。 REST调用的p99位于
详细信息
节点版本和操作系统:node:14.7.0-alpine3.12
依赖项:
"google-protobuf": "^3.12.4","grpc": "^1.24.3","mali": "^0.21.0",
我什至通过设置gRPC选项grpc.use_local_subchannel_pool=1
来创建客户端TCP池,但这似乎无济于事。
问题似乎出在服务器端,正如我从日志中看到的那样,grpc lib的call.startBatch
调用花费了几秒钟来发送大小约为51kb的数据。这比REST版本要慢。
我还检查了服务的cpu和网络是否正常。 REST版本可以发送> 2mbps,而gRPC版本只能管理约150kbps。
在服务B(在gRPC中)上运行netstat
会显示许多已建立的TCP连接(由于TCP池,这是预期的)。
我怀疑grpc核心C ++代码在某种程度上不如REST最佳,但我没有证据。
我接下来要看的任何想法?谢谢您的帮助
更新1
以下是一些基准:
设置
Blazemeter --REST--> services A --gRPC/REST--> service B
- 请求正文(两个滞后)可以忽略不计
-
service A
是节点服务+ Koa -
service B
有3个选项:-
grpc-node
:具有grpc-node的节点 -
gRPC + Go
:执行同一gRPC服务 -
REST + Koa
:带有Koa的节点
-
-
Blazemeter --> service A
:响应有效载荷可以忽略不计,所有测试都相同 -
serivce A --> service B
:gRPC / REST响应有效载荷是ProductPrice
中的1000:
message ProductPrice {
string product_id = 1; // Hard coded to "product-x",x in [0 ... 999]
string description = 2; // Hard coded to random string,length = 10
Money price = 3;
google.protobuf.Timestamp created_at = 4; // Hard coded
}
message Money {
Currency currency = 1; // Hard coded to GBP
string value = 2; // Hard coded to "12.99"
}
enum Currency {
CURRENCY_UNKNowN = 0;
GBP = 1;
}
服务已部署到GCP中的Kubernetes,
- 实例类型:
n1-highcpu-4
- 每个服务5个豆荚
- 2个cpu,每个吊舱1 GB内存
- 使用群集IP的kube-proxy(不通过Internet)(我也用
clusterIP: None
进行了无头测试,得出了相似的结果)
加载
50rps
结果
使用grpc-node的服务B
使用Go gRPC的服务B
服务B与REST一起使用Koa
网络IO
观察
-
gRPC + Go
与REST
大致相当(我认为gRPC会更快) -
grpc-node
比REST
慢4倍 - 网络不是瓶颈
解决方法
暂无找到可以解决该程序问题的有效方法,小编努力寻找整理中!
如果你已经找到好的解决方法,欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@)