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

[noble4cc]

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

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

有同样的业务或者近似的业务，从 http 切换到 rpc 的开发经验的老哥吗？切换到 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 的性能差了