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

[noble4cc]

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

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

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

[codehz]

这种情况主要的问题不是时间和速度，而是可维护性，和跨语言的兼容性，你不需要给每个语言写一遍编码和解码

[lxk11153]

https://www.techempower.com/benchmarks/

[ungrown]

VXI11 底层是 RPC
VXI11 是一个比较老的标准但眼下正被广泛使用
VXI11 广泛应用于工业仪器高精度高速实时数据采集

啊等等，咱俩说的 RPC 应该不是建立在相同的传输层上的
打扰了

[noble4cc]

@lxk11153 我也见过这个排行，但是感觉不能解答我的疑问呀

[noble4cc]

@codehz restful 传递的都是 json，服务端和客户端朝阳只需要 decode 和 encode 就行了，而且一般封装好的框架里都做了

[salmon5]

pv 千亿万亿，服务器 10000+台的公司有实际意义

[salmon5]

性能这一条上，服务器 10000+台的公司有实际意义

[wander639]

微服务用的比较多吧，要是多个微服务之间传递 json 的话就慢了

[opengps]

很多时候，最省不等于最好。
楼主希望通过更换协议省几台机器，却没注意到因为协议变更，带来的人工成本有多大
协议各有各的优缺点，比如键盘，现在用的键盘布局早在设计之初就被证实不是最高效的，并且设计了更好的布局，但是由于现在这套已经广泛使用，所以没有人会为此主动去修改全人类的电脑键盘顺序

[pastgift]

这个看系统体量大小和场景，巨量请求次数小数据包场景下 RPC 有明显优势

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

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

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

另一个例子就是下载类请求，这类请求单次请求 body 大到可以忽略 header，那么这种场景下靠通讯协议是没法提高效率的。因此不管是操作系统更新包，还是什么游戏数据更新包，都是 HTTP 请求即可，没见过有谁说下载个东西用 RPC 有多好。

[wzzzx]

一定要记得，在开发过程中，可维护性 /开发成本，比一切都重要的多的多的多的多。不要为了优化而优化

[kangsheng9527]

没写过建议写写，增加自己技术面，不也花费多多少时间。

[jameslan]

有的时候只是为了有个明确的 schema

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

到底用哪个，需要仔细考虑

[KuroNekoFan]

@pastgift 零售场景才是流量算钱的吧，大流量（大公司）场景不是按带宽算钱的吗……

[594duck]

HTTP 太重了，相对于 tcp 来说 HTTP 大的就像个怪兽。

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

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

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


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

http 只是简单，涉及到性能还是得走 tcp 。

[594duck]

@pastgift 我们几百人的电商系统都要用 rpc 总线跑 ESB 和心跳，监控。http 不得行

[AJQA]

ESB 服务总线 你们用什么搭建的 apache camel?

[kebyn]

@594duck rpc 和 http 并不矛盾，grpc 就是基于 http2 的

[supermoonie]

大数据传输，流量整形，流控，异步，更高吞吐，低延时等等这些，http 不太好做

[kebyn]

有点不太对劲，感觉好多人都是拿 rpc 和 http 对比了，rpc 是远程调用是不限通信协议的

[594duck]

@kebyn 默认这 RPC 是 TCP

[fishCatcher]

顺便问一下 grpc 为什么要基于 http 啊

[laike9m]

RPC 数据有 type，光是这一点 HTTP 就做不到。不要说 JSON

[sonice]

不就是编码解码在两端做了吗，传输的时候不带字段信息，更轻量。
现在好多 rpc 底层都是几乎 HTTP2 了，两者不是独立的哈。

[no1xsyzy]

拿 RPC vs HTTP 不太对，俺常用的 RPC 甚至还是基于 HTTP/1.1 的 xmlrpc 和 jsonrpc （ aria2

记得一个金句：premature optimization is the root of all evils

@kebyn #18 但 “总线” 和 HTTP 矛盾

[xfrgux]

你们在讨论 rpc 比 restful 节省多少资源时，已经有人在说 50Mbps/人的云游戏带宽成本可以被忽略不计了

[wangritian]

h2 连接复用和 header 压缩已经很棒了，tcp 队头阻塞大家都有，定个小目标吧，QPS 不上 10W 不必考虑 rpc

[coderxy]

rpc 比如 grpc，我觉得最重要的是跨语言。只要写好 proto，不同语言、服务之间只需要编译即可生成调用 client 。非常高效。

[noble4cc]

@coderxy 实际这些 rpc 和 restful 都用过，确实不如 restful 开发维护高效😂

[noble4cc]

@laike9m 说的就是 restful 一般就是 http+json

[pastgift]

@KuroNekoFan 那得看多大的公司了
比如都是阿里云上部署，内网通讯其实是不收钱的，但是流量太大就要加机器
如果是更大的公司，类似自建机房的，其实还是要算算钱的，毕竟网卡空载和满载电费发热还是有区别的

就好像手机 4G 无限流量套餐，超过多少流量要限速。宽带也是按带宽收费，但是你真的每天几 TB 人家一样给你限速
按带宽算钱说白了就是运营商赌你花不了那么多流量而已

[coderxy]

@noble4cc 你确定 rpc 不如 restful 维护高效？ 你用 rpc 的时候有实现命令生成 client 吗？ restful 的调用传参、method 、url 都得自己一个个写吧。

[pastgift]

@594duck 看请求数不是看用户数的，心跳就算 3 秒一跳，1 个设备只心跳其他啥都不做，1 天下来也要 28800 次请求了
HTTP 当然不合适，90%的流量基本都是重复的协议头内容，非常浪费

[wellsc]

@594duck grpc 之类的不也是基于 http 的么，只是换了一套 schema 而已

[594duck]

@pastgift 老哥我支持你，我们的答应都一样只不过过程有点偏差，

[CoderGeek]

流量而且 其他所谓的老 rpc 没啥优势 问题不少

[CoderGeek]

流量而已

[ryanbuu]

json 传 bin 你考虑过吗。。。

[wysnylc]

@pastgift #33 请了解 http2 头部压缩

[accacc]

rpc 是传输工具+序列化，那么 http+json 是属于 rpc 的一种，当然还有更多组合形式。

[noble4cc]

@pastgift 所以本质上就是流量的区别吗？性能其实在请求处理耗时占比比较大的情况下忽略不计？就算 http+json 的话 json encode 和 decode 性能较差多耗一点 cpu，其他的应该没多少区别

[nl101531]

建议目前 HTTP2，后续的 HTTP3，HTTP 是完整的应用层协议，我觉得 HTTP3 时代，RPC 就会被超越

[newtype0092]

如果传大结构体的数据，假设传输 10 个 G 的内容，如果用 json，key 要保持可读性，最终光 key 可能就占了一半，10 个 G 流量传了 5 个 G 的信息。。。

[luwies]

我们 App 用了 GRPC 速度是杠杆的快。

[abersheeran]

这，其实如果不是大厂你完全没必要考虑这一点的。什么每日调用千万次这种小流量的服务，你用啥都差不多。基本上有一个长连接（比如 http1.1 或者 http2.0 ）就可以了。之前为了自家业务随手写了一个 git.io/rpc.py 框架，一天几十万次调用，我连优化都懒得做，http1.0 莽就完事了。

[geligaoli]

光算协议大概能快 2-3 倍，但因为有业务处理，基本上就被拉平了。

[noble4cc]

@geligaoli 其实我也这么觉得而且事实上也是，可能会快一点而且省几台机器

[yinft]

restful 不能跨语言么?

[noble4cc]

@yinft http+json 哪个语言不支持呢？自己封装下 model 呗 又不麻烦

[zunceng]

如果是 grpc 的话 这个问题就退化成 http2 和 http1.1 的性能差了