高性能的 rpc 通讯协议在实际应用中比 restful 的方式快多少呢?

2020-09-23 17:51:17 +08:00
 noble4cc

现在各种 rpc 满天飞,grpc rpx doubbo thrift 等等,这些 rpc 性能在基准测试中比 http result 的形式高很多,主要得益于 rpc 二进制协议压缩比高,序列化反序列化性能高,没有 http 协议的种种条条框框

但是有个问题是,如果我们的无论用什么 rpc 方式我们的后端业务逻辑处理耗时基本上是一定的,如果我们后端处理耗时比较高,比如说上百 ms,那上面提到的 rpc 的种种性能优势是否就不明显了,毕竟大部分时间都耗到了业务逻辑上,rpc 省出来的性能消耗占比不是很大

有同样的业务或者近似的业务,从 http 切换到 rpc 的开发经验的老哥吗?切换到 rpc 后能省下多少机器呢?吞吐和总耗时提高了多少呢?

7540 次点击
所在节点    Java
50 条回复
codehz
2020-09-23 18:03:14 +08:00
这种情况主要的问题不是时间和速度,而是可维护性,和跨语言的兼容性,你不需要给每个语言写一遍编码和解码
lxk11153
2020-09-23 20:22:23 +08:00
ungrown
2020-09-23 20:40:56 +08:00
VXI11 底层是 RPC
VXI11 是一个比较老的标准但眼下正被广泛使用
VXI11 广泛应用于工业仪器高精度高速实时数据采集

啊等等,咱俩说的 RPC 应该不是建立在相同的传输层上的
打扰了
noble4cc
2020-09-23 21:02:11 +08:00
@lxk11153 我也见过这个排行,但是感觉不能解答我的疑问呀
noble4cc
2020-09-23 21:03:22 +08:00
@codehz restful 传递的都是 json,服务端和客户端朝阳只需要 decode 和 encode 就行了,而且一般封装好的框架里都做了
salmon5
2020-09-23 21:16:14 +08:00
pv 千亿万亿,服务器 10000+台的公司有实际意义
salmon5
2020-09-23 21:18:19 +08:00
性能这一条上,服务器 10000+台的公司有实际意义
wander639
2020-09-23 21:23:28 +08:00
微服务用的比较多吧,要是多个微服务之间传递 json 的话就慢了
opengps
2020-09-23 21:30:44 +08:00
很多时候,最省不等于最好。
楼主希望通过更换协议省几台机器,却没注意到因为协议变更,带来的人工成本有多大
协议各有各的优缺点,比如键盘,现在用的键盘布局早在设计之初就被证实不是最高效的,并且设计了更好的布局,但是由于现在这套已经广泛使用,所以没有人会为此主动去修改全人类的电脑键盘顺序
pastgift
2020-09-23 21:42:29 +08:00
这个看系统体量大小和场景,巨量请求次数小数据包场景下 RPC 有明显优势

假设 RPC 每次通讯能节约 1ms 耗时,100 字节流量
那么一个每天 1 万次请求的小系统(有可能都没微服务化),每天能节约 10 秒耗时,1MB 流量
这看上去没啥用处

而对于一个每天 10 亿次请求的大系统(微服务化,外部一个请求过来内部通讯假设 10 次)
比如一个 3 亿用户的聊天软件,每人每天只发 3 ~ 4 条消息
那么每天可以节约 166 天处理时间,900GB 的流量
这就是很大一笔费用了

所以推 RPC 的都是大公司,因为这玩意对大公司真有用,真省钱。
小公司为了可维护性,以及不怎么稳定的产品和系统,最好谨慎搞 RPC,收益其实并不明显

另一个例子就是下载类请求,这类请求单次请求 body 大到可以忽略 header,那么这种场景下靠通讯协议是没法提高效率的。因此不管是操作系统更新包,还是什么游戏数据更新包,都是 HTTP 请求即可,没见过有谁说下载个东西用 RPC 有多好。
wzzzx
2020-09-23 22:47:22 +08:00
一定要记得,在开发过程中,可维护性 /开发成本,比一切都重要的多的多的多的多。不要为了优化而优化
kangsheng9527
2020-09-24 03:13:41 +08:00
没写过建议写写,增加自己技术面,不也花费多多少时间。
jameslan
2020-09-24 06:27:33 +08:00
有的时候只是为了有个明确的 schema

不用 schema 的 json 最开始的时候当然爽,但是之后的兼容性维护要付出不少精力的。

到底用哪个,需要仔细考虑
KuroNekoFan
2020-09-24 06:45:58 +08:00
@pastgift 零售场景才是流量算钱的吧,大流量(大公司)场景不是按带宽算钱的吗……
594duck
2020-09-24 06:55:56 +08:00
HTTP 太重了,相对于 tcp 来说 HTTP 大的就像个怪兽。

以心跳举例子,你想你有 300+的虚拟机每个虚拟机跑了一个服务,你希望心跳是 10ms 一次。你算算看 tcp 心跳包多大,http 多大

如果是性能监控的就更加的厉害了

如果是 ESB 那就更加更加看到差距了。


SOA 做好后,1 份外部流量进系统放大 5 倍。你再算算。

http 只是简单,涉及到性能还是得走 tcp 。
594duck
2020-09-24 06:57:25 +08:00
@pastgift 我们几百人的电商系统都要用 rpc 总线跑 ESB 和心跳,监控。http 不得行
AJQA
2020-09-24 08:21:24 +08:00
ESB 服务总线 你们用什么搭建的 apache camel?
kebyn
2020-09-24 08:22:29 +08:00
@594duck rpc 和 http 并不矛盾,grpc 就是基于 http2 的
supermoonie
2020-09-24 08:24:27 +08:00
大数据传输,流量整形,流控,异步,更高吞吐,低延时等等这些,http 不太好做
kebyn
2020-09-24 08:26:09 +08:00
有点不太对劲,感觉好多人都是拿 rpc 和 http 对比了,rpc 是远程调用是不限通信协议的

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/709864

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX