V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
noble4cc
V2EX  ›  Java

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

  •  2
     
  •   noble4cc · 2020-09-23 17:51:17 +08:00 · 7480 次点击
    这是一个创建于 1282 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    啊等等,咱俩说的 RPC 应该不是建立在相同的传输层上的
    打扰了
    noble4cc
        4
    noble4cc  
    OP
       2020-09-23 21:02:11 +08:00
    @lxk11153 我也见过这个排行,但是感觉不能解答我的疑问呀
    noble4cc
        5
    noble4cc  
    OP
       2020-09-23 21:03:22 +08:00
    @codehz restful 传递的都是 json,服务端和客户端朝阳只需要 decode 和 encode 就行了,而且一般封装好的框架里都做了
    salmon5
        6
    salmon5  
       2020-09-23 21:16:14 +08:00 via Android
    pv 千亿万亿,服务器 10000+台的公司有实际意义
    salmon5
        7
    salmon5  
       2020-09-23 21:18:19 +08:00 via Android
    性能这一条上,服务器 10000+台的公司有实际意义
    wander639
        8
    wander639  
       2020-09-23 21:23:28 +08:00
    微服务用的比较多吧,要是多个微服务之间传递 json 的话就慢了
    opengps
        9
    opengps  
       2020-09-23 21:30:44 +08:00
    很多时候,最省不等于最好。
    楼主希望通过更换协议省几台机器,却没注意到因为协议变更,带来的人工成本有多大
    协议各有各的优缺点,比如键盘,现在用的键盘布局早在设计之初就被证实不是最高效的,并且设计了更好的布局,但是由于现在这套已经广泛使用,所以没有人会为此主动去修改全人类的电脑键盘顺序
    pastgift
        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 有多好。
    wzzzx
        11
    wzzzx  
       2020-09-23 22:47:22 +08:00   ❤️ 1
    一定要记得,在开发过程中,可维护性 /开发成本,比一切都重要的多的多的多的多。不要为了优化而优化
    kangsheng9527
        12
    kangsheng9527  
       2020-09-24 03:13:41 +08:00
    没写过建议写写,增加自己技术面,不也花费多多少时间。
    jameslan
        13
    jameslan  
       2020-09-24 06:27:33 +08:00
    有的时候只是为了有个明确的 schema

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

    到底用哪个,需要仔细考虑
    KuroNekoFan
        14
    KuroNekoFan  
       2020-09-24 06:45:58 +08:00 via iPhone
    @pastgift 零售场景才是流量算钱的吧,大流量(大公司)场景不是按带宽算钱的吗……
    594duck
        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 。
    594duck
        16
    594duck  
       2020-09-24 06:57:25 +08:00 via iPhone
    @pastgift 我们几百人的电商系统都要用 rpc 总线跑 ESB 和心跳,监控。http 不得行
    AJQA
        17
    AJQA  
       2020-09-24 08:21:24 +08:00
    ESB 服务总线 你们用什么搭建的 apache camel?
    kebyn
        18
    kebyn  
       2020-09-24 08:22:29 +08:00 via iPhone
    @594duck rpc 和 http 并不矛盾,grpc 就是基于 http2 的
    supermoonie
        19
    supermoonie  
       2020-09-24 08:24:27 +08:00 via iPhone
    大数据传输,流量整形,流控,异步,更高吞吐,低延时等等这些,http 不太好做
    kebyn
        20
    kebyn  
       2020-09-24 08:26:09 +08:00 via iPhone   ❤️ 3
    有点不太对劲,感觉好多人都是拿 rpc 和 http 对比了,rpc 是远程调用是不限通信协议的
    594duck
        21
    594duck  
       2020-09-24 08:43:48 +08:00
    @kebyn 默认这 RPC 是 TCP
    fishCatcher
        22
    fishCatcher  
       2020-09-24 08:48:09 +08:00 via iPhone
    顺便问一下 grpc 为什么要基于 http 啊
    laike9m
        23
    laike9m  
       2020-09-24 08:54:43 +08:00 via Android
    RPC 数据有 type,光是这一点 HTTP 就做不到。不要说 JSON
    sonice
        24
    sonice  
       2020-09-24 09:14:23 +08:00
    不就是编码解码在两端做了吗,传输的时候不带字段信息,更轻量。
    现在好多 rpc 底层都是几乎 HTTP2 了,两者不是独立的哈。
    no1xsyzy
        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 矛盾
    xfrgux
        26
    xfrgux  
       2020-09-24 09:35:12 +08:00
    你们在讨论 rpc 比 restful 节省多少资源时,已经有人在说 50Mbps/人的云游戏带宽成本可以被忽略不计了
    wangritian
        27
    wangritian  
       2020-09-24 09:43:40 +08:00
    h2 连接复用和 header 压缩已经很棒了,tcp 队头阻塞大家都有,定个小目标吧,QPS 不上 10W 不必考虑 rpc
    coderxy
        28
    coderxy  
       2020-09-24 10:09:12 +08:00
    rpc 比如 grpc,我觉得最重要的是跨语言。只要写好 proto,不同语言、服务之间只需要编译即可生成调用 client 。非常高效。
    noble4cc
        29
    noble4cc  
    OP
       2020-09-24 10:11:16 +08:00   ❤️ 1
    @coderxy 实际这些 rpc 和 restful 都用过,确实不如 restful 开发维护高效😂
    noble4cc
        30
    noble4cc  
    OP
       2020-09-24 10:12:25 +08:00
    @laike9m 说的就是 restful 一般就是 http+json
    pastgift
        31
    pastgift  
       2020-09-24 10:15:44 +08:00
    @KuroNekoFan 那得看多大的公司了
    比如都是阿里云上部署,内网通讯其实是不收钱的,但是流量太大就要加机器
    如果是更大的公司,类似自建机房的,其实还是要算算钱的,毕竟网卡空载和满载电费发热还是有区别的

    就好像手机 4G 无限流量套餐,超过多少流量要限速。宽带也是按带宽收费,但是你真的每天几 TB 人家一样给你限速
    按带宽算钱说白了就是运营商赌你花不了那么多流量而已
    coderxy
        32
    coderxy  
       2020-09-24 10:18:23 +08:00
    @noble4cc 你确定 rpc 不如 restful 维护高效? 你用 rpc 的时候有实现命令生成 client 吗? restful 的调用传参、method 、url 都得自己一个个写吧。
    pastgift
        33
    pastgift  
       2020-09-24 10:19:15 +08:00   ❤️ 1
    @594duck 看请求数不是看用户数的,心跳就算 3 秒一跳,1 个设备只心跳其他啥都不做,1 天下来也要 28800 次请求了
    HTTP 当然不合适,90%的流量基本都是重复的协议头内容,非常浪费
    wellsc
        34
    wellsc  
       2020-09-24 10:20:34 +08:00
    @594duck grpc 之类的不也是基于 http 的么,只是换了一套 schema 而已
    594duck
        35
    594duck  
       2020-09-24 10:21:46 +08:00
    @pastgift 老哥我支持你,我们的答应都一样只不过过程有点偏差,
    CoderGeek
        36
    CoderGeek  
       2020-09-24 10:41:18 +08:00
    流量而且 其他所谓的老 rpc 没啥优势 问题不少
    CoderGeek
        37
    CoderGeek  
       2020-09-24 10:41:33 +08:00
    流量而已
    q1angch0u
        38
    q1angch0u  
       2020-09-24 10:55:14 +08:00
    json 传 bin 你考虑过吗。。。
    wysnylc
        39
    wysnylc  
       2020-09-24 11:19:48 +08:00
    @pastgift #33 请了解 http2 头部压缩
    accacc
        40
    accacc  
       2020-09-24 15:18:30 +08:00   ❤️ 1
    rpc 是传输工具+序列化,那么 http+json 是属于 rpc 的一种,当然还有更多组合形式。
    noble4cc
        41
    noble4cc  
    OP
       2020-09-24 17:41:26 +08:00
    @pastgift 所以本质上就是流量的区别吗?性能其实在请求处理耗时占比比较大的情况下忽略不计?就算 http+json 的话 json encode 和 decode 性能较差多耗一点 cpu,其他的应该没多少区别
    nl101531
        42
    nl101531  
       2020-09-24 18:23:12 +08:00
    建议目前 HTTP2,后续的 HTTP3,HTTP 是完整的应用层协议,我觉得 HTTP3 时代,RPC 就会被超越
    newtype0092
        43
    newtype0092  
       2020-09-24 18:27:05 +08:00
    如果传大结构体的数据,假设传输 10 个 G 的内容,如果用 json,key 要保持可读性,最终光 key 可能就占了一半,10 个 G 流量传了 5 个 G 的信息。。。
    luwies
        44
    luwies  
       2020-09-24 19:16:07 +08:00
    我们 App 用了 GRPC 速度是杠杆的快。
    abersheeran
        45
    abersheeran  
       2020-09-25 01:06:23 +08:00
    这,其实如果不是大厂你完全没必要考虑这一点的。什么每日调用千万次这种小流量的服务,你用啥都差不多。基本上有一个长连接(比如 http1.1 或者 http2.0 )就可以了。之前为了自家业务随手写了一个 git.io/rpc.py 框架,一天几十万次调用,我连优化都懒得做,http1.0 莽就完事了。
    geligaoli
        46
    geligaoli  
       2020-09-25 11:23:50 +08:00
    光算协议大概能快 2-3 倍,但因为有业务处理,基本上就被拉平了。
    noble4cc
        47
    noble4cc  
    OP
       2020-09-25 12:09:48 +08:00
    @geligaoli 其实我也这么觉得而且事实上也是,可能会快一点而且省几台机器
    yinft
        48
    yinft  
       2020-09-25 15:20:49 +08:00
    restful 不能跨语言么?
    noble4cc
        49
    noble4cc  
    OP
       2020-09-25 16:30:02 +08:00
    @yinft http+json 哪个语言不支持呢?自己封装下 model 呗 又不麻烦
    zunceng
        50
    zunceng  
       2020-09-25 16:52:49 +08:00
    如果是 grpc 的话 这个问题就退化成 http2 和 http1.1 的性能差了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3215 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 11:33 · PVG 19:33 · LAX 04:33 · JFK 07:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.