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

[noble4cc]

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

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

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

流量而已

[q1angch0u]

json 传 bin 你考虑过吗。。。

[wysnylc]

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

[accacc]

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