现在各种 rpc 满天飞,grpc rpx doubbo thrift 等等,这些 rpc 性能在基准测试中比 http result 的形式高很多,主要得益于 rpc 二进制协议压缩比高,序列化反序列化性能高,没有 http 协议的种种条条框框
但是有个问题是,如果我们的无论用什么 rpc 方式我们的后端业务逻辑处理耗时基本上是一定的,如果我们后端处理耗时比较高,比如说上百 ms,那上面提到的 rpc 的种种性能优势是否就不明显了,毕竟大部分时间都耗到了业务逻辑上,rpc 省出来的性能消耗占比不是很大
有同样的业务或者近似的业务,从 http 切换到 rpc 的开发经验的老哥吗?切换到 rpc 后能省下多少机器呢?吞吐和总耗时提高了多少呢?
1
codehz 2020-09-23 18:03:14 +08:00 via Android 2
这种情况主要的问题不是时间和速度,而是可维护性,和跨语言的兼容性,你不需要给每个语言写一遍编码和解码
|
2
lxk11153 2020-09-23 20:22:23 +08:00
|
3
ungrown 2020-09-23 20:40:56 +08:00
VXI11 底层是 RPC
VXI11 是一个比较老的标准但眼下正被广泛使用 VXI11 广泛应用于工业仪器高精度高速实时数据采集 啊等等,咱俩说的 RPC 应该不是建立在相同的传输层上的 打扰了 |
5
noble4cc OP @codehz restful 传递的都是 json,服务端和客户端朝阳只需要 decode 和 encode 就行了,而且一般封装好的框架里都做了
|
6
salmon5 2020-09-23 21:16:14 +08:00 via Android
pv 千亿万亿,服务器 10000+台的公司有实际意义
|
7
salmon5 2020-09-23 21:18:19 +08:00 via Android
性能这一条上,服务器 10000+台的公司有实际意义
|
8
wander639 2020-09-23 21:23:28 +08:00
微服务用的比较多吧,要是多个微服务之间传递 json 的话就慢了
|
9
opengps 2020-09-23 21:30:44 +08:00
很多时候,最省不等于最好。
楼主希望通过更换协议省几台机器,却没注意到因为协议变更,带来的人工成本有多大 协议各有各的优缺点,比如键盘,现在用的键盘布局早在设计之初就被证实不是最高效的,并且设计了更好的布局,但是由于现在这套已经广泛使用,所以没有人会为此主动去修改全人类的电脑键盘顺序 |
10
pastgift 2020-09-23 21:42:29 +08:00 5
这个看系统体量大小和场景,巨量请求次数小数据包场景下 RPC 有明显优势
假设 RPC 每次通讯能节约 1ms 耗时,100 字节流量 那么一个每天 1 万次请求的小系统(有可能都没微服务化),每天能节约 10 秒耗时,1MB 流量 这看上去没啥用处 而对于一个每天 10 亿次请求的大系统(微服务化,外部一个请求过来内部通讯假设 10 次) 比如一个 3 亿用户的聊天软件,每人每天只发 3 ~ 4 条消息 那么每天可以节约 166 天处理时间,900GB 的流量 这就是很大一笔费用了 所以推 RPC 的都是大公司,因为这玩意对大公司真有用,真省钱。 小公司为了可维护性,以及不怎么稳定的产品和系统,最好谨慎搞 RPC,收益其实并不明显 另一个例子就是下载类请求,这类请求单次请求 body 大到可以忽略 header,那么这种场景下靠通讯协议是没法提高效率的。因此不管是操作系统更新包,还是什么游戏数据更新包,都是 HTTP 请求即可,没见过有谁说下载个东西用 RPC 有多好。 |
11
wzzzx 2020-09-23 22:47:22 +08:00 1
一定要记得,在开发过程中,可维护性 /开发成本,比一切都重要的多的多的多的多。不要为了优化而优化
|
12
kangsheng9527 2020-09-24 03:13:41 +08:00
没写过建议写写,增加自己技术面,不也花费多多少时间。
|
13
jameslan 2020-09-24 06:27:33 +08:00
有的时候只是为了有个明确的 schema
不用 schema 的 json 最开始的时候当然爽,但是之后的兼容性维护要付出不少精力的。 到底用哪个,需要仔细考虑 |
14
KuroNekoFan 2020-09-24 06:45:58 +08:00 via iPhone
@pastgift 零售场景才是流量算钱的吧,大流量(大公司)场景不是按带宽算钱的吗……
|
15
594duck 2020-09-24 06:55:56 +08:00 via iPhone
HTTP 太重了,相对于 tcp 来说 HTTP 大的就像个怪兽。
以心跳举例子,你想你有 300+的虚拟机每个虚拟机跑了一个服务,你希望心跳是 10ms 一次。你算算看 tcp 心跳包多大,http 多大 如果是性能监控的就更加的厉害了 如果是 ESB 那就更加更加看到差距了。 SOA 做好后,1 份外部流量进系统放大 5 倍。你再算算。 http 只是简单,涉及到性能还是得走 tcp 。 |
16
594duck 2020-09-24 06:57:25 +08:00 via iPhone
@pastgift 我们几百人的电商系统都要用 rpc 总线跑 ESB 和心跳,监控。http 不得行
|
17
AJQA 2020-09-24 08:21:24 +08:00
ESB 服务总线 你们用什么搭建的 apache camel?
|
19
supermoonie 2020-09-24 08:24:27 +08:00 via iPhone
大数据传输,流量整形,流控,异步,更高吞吐,低延时等等这些,http 不太好做
|
20
kebyn 2020-09-24 08:26:09 +08:00 via iPhone 3
有点不太对劲,感觉好多人都是拿 rpc 和 http 对比了,rpc 是远程调用是不限通信协议的
|
22
fishCatcher 2020-09-24 08:48:09 +08:00 via iPhone
顺便问一下 grpc 为什么要基于 http 啊
|
23
laike9m 2020-09-24 08:54:43 +08:00 via Android
RPC 数据有 type,光是这一点 HTTP 就做不到。不要说 JSON
|
24
sonice 2020-09-24 09:14:23 +08:00
不就是编码解码在两端做了吗,传输的时候不带字段信息,更轻量。
现在好多 rpc 底层都是几乎 HTTP2 了,两者不是独立的哈。 |
25
no1xsyzy 2020-09-24 09:23:41 +08:00
拿 RPC vs HTTP 不太对,俺常用的 RPC 甚至还是基于 HTTP/1.1 的 xmlrpc 和 jsonrpc ( aria2
记得一个金句:premature optimization is the root of all evils @kebyn #18 但 “总线” 和 HTTP 矛盾 |
26
xfrgux 2020-09-24 09:35:12 +08:00
你们在讨论 rpc 比 restful 节省多少资源时,已经有人在说 50Mbps/人的云游戏带宽成本可以被忽略不计了
|
27
wangritian 2020-09-24 09:43:40 +08:00
h2 连接复用和 header 压缩已经很棒了,tcp 队头阻塞大家都有,定个小目标吧,QPS 不上 10W 不必考虑 rpc
|
28
coderxy 2020-09-24 10:09:12 +08:00
rpc 比如 grpc,我觉得最重要的是跨语言。只要写好 proto,不同语言、服务之间只需要编译即可生成调用 client 。非常高效。
|
31
pastgift 2020-09-24 10:15:44 +08:00
@KuroNekoFan 那得看多大的公司了
比如都是阿里云上部署,内网通讯其实是不收钱的,但是流量太大就要加机器 如果是更大的公司,类似自建机房的,其实还是要算算钱的,毕竟网卡空载和满载电费发热还是有区别的 就好像手机 4G 无限流量套餐,超过多少流量要限速。宽带也是按带宽收费,但是你真的每天几 TB 人家一样给你限速 按带宽算钱说白了就是运营商赌你花不了那么多流量而已 |
32
coderxy 2020-09-24 10:18:23 +08:00
@noble4cc 你确定 rpc 不如 restful 维护高效? 你用 rpc 的时候有实现命令生成 client 吗? restful 的调用传参、method 、url 都得自己一个个写吧。
|
33
pastgift 2020-09-24 10:19:15 +08:00 1
@594duck 看请求数不是看用户数的,心跳就算 3 秒一跳,1 个设备只心跳其他啥都不做,1 天下来也要 28800 次请求了
HTTP 当然不合适,90%的流量基本都是重复的协议头内容,非常浪费 |
36
CoderGeek 2020-09-24 10:41:18 +08:00
流量而且 其他所谓的老 rpc 没啥优势 问题不少
|
37
CoderGeek 2020-09-24 10:41:33 +08:00
流量而已
|
38
q1angch0u 2020-09-24 10:55:14 +08:00
json 传 bin 你考虑过吗。。。
|
40
accacc 2020-09-24 15:18:30 +08:00 1
rpc 是传输工具+序列化,那么 http+json 是属于 rpc 的一种,当然还有更多组合形式。
|
41
noble4cc OP @pastgift 所以本质上就是流量的区别吗?性能其实在请求处理耗时占比比较大的情况下忽略不计?就算 http+json 的话 json encode 和 decode 性能较差多耗一点 cpu,其他的应该没多少区别
|
42
nl101531 2020-09-24 18:23:12 +08:00
建议目前 HTTP2,后续的 HTTP3,HTTP 是完整的应用层协议,我觉得 HTTP3 时代,RPC 就会被超越
|
43
newtype0092 2020-09-24 18:27:05 +08:00
如果传大结构体的数据,假设传输 10 个 G 的内容,如果用 json,key 要保持可读性,最终光 key 可能就占了一半,10 个 G 流量传了 5 个 G 的信息。。。
|
44
luwies 2020-09-24 19:16:07 +08:00
我们 App 用了 GRPC 速度是杠杆的快。
|
45
abersheeran 2020-09-25 01:06:23 +08:00
这,其实如果不是大厂你完全没必要考虑这一点的。什么每日调用千万次这种小流量的服务,你用啥都差不多。基本上有一个长连接(比如 http1.1 或者 http2.0 )就可以了。之前为了自家业务随手写了一个 git.io/rpc.py 框架,一天几十万次调用,我连优化都懒得做,http1.0 莽就完事了。
|
46
geligaoli 2020-09-25 11:23:50 +08:00
光算协议大概能快 2-3 倍,但因为有业务处理,基本上就被拉平了。
|
48
yinft 2020-09-25 15:20:49 +08:00
restful 不能跨语言么?
|
50
zunceng 2020-09-25 16:52:49 +08:00
如果是 grpc 的话 这个问题就退化成 http2 和 http1.1 的性能差了
|