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

我们真的需要 gRPC 吗?

  •  1
     
  •   Nazz · 2023-02-24 09:39:40 +08:00 · 9296 次点击
    这是一个创建于 398 天前的主题,其中的信息可能已经有所发展或是发生改变。

    相对 gRPC, JSON-RPC:

    • 协议方面更加简单透明
    • 协议方面更加统一, 没有封装和切换的开销, 中间件可以复用
    • JSON 可读性更好, 开发调试方便

    最后问一下, 有根据文件生成各大语言 JSON 代码的命令行工具吗?

    72 条回复    2023-02-25 23:19:10 +08:00
    julyclyde
        1
    julyclyde  
       2023-02-24 09:46:01 +08:00   ❤️ 8
    说白了 gRPC 并不是给人类用的啊,你这个所谓简单透明、可读性其实没啥用

    封装切换开销,json 并不占优
    chendy
        2
    chendy  
       2023-02-24 09:48:05 +08:00
    一个序列化二进制,一个序列化文本
    侧重点就不一样,没法比
    tool2d
        3
    tool2d  
       2023-02-24 09:48:59 +08:00
    一个文本协议,另一个二进制协议,完全不一样的东西。
    sadfQED2
        4
    sadfQED2  
       2023-02-24 09:50:18 +08:00 via Android
    编解码性能差远了,你不在乎这点性能当然无脑 json 啊。高并发场景下 json 编解码动不动就干满 cpu
    totoro52
        5
    totoro52  
       2023-02-24 09:50:55 +08:00
    emmm json 不是更重吗 而且这个就是给机器看的
    DefoliationM
        6
    DefoliationM  
       2023-02-24 09:51:47 +08:00   ❤️ 1
    我们真的需要 HTTP 协议吗,现在感觉 HTTP 协议就是一坨狗屎,不如 rpc 直观方便
    changnet
        7
    changnet  
       2023-02-24 09:51:51 +08:00   ❤️ 1
    json 的序列化性能和 protobuf 的序列化性能(效率和包大小)不是同一个级别的吧,如果对性能不高,用 json 可读性当然更高
    yty2012g
        8
    yty2012g  
       2023-02-24 09:57:22 +08:00   ❤️ 1
    我怎么觉得你这三点都不是基于 json 的 rpc 的优点呀...
    1. grpc 用的 pb 的协议描述文件怎么看也比 json 更加明确和透明,json 的类型不够丰富
    2. 序列化大 JSON 字符串的 CPU 开销是巨大的,代价远比 pb 的序列化要高。
    3. 可读性方面,pb 也可以将对象直接打印出来啊,当然你说要通过抓包的时候就能直接从二进制看出数据内容,那确实 JSON 更好,只不过一般不是这么玩的
    julyclyde
        9
    julyclyde  
       2023-02-24 10:01:29 +08:00
    @DefoliationM 所以后来 http 也不文本了
    echoless
        10
    echoless  
       2023-02-24 10:02:28 +08:00 via Android
    @yty2012g pb 也可以通过代理看明文
    mcfog
        11
    mcfog  
       2023-02-24 10:02:42 +08:00   ❤️ 1
    关于最后一个问题,我推荐一个支持生成各大语言 JSON 代码的命令行工具:protoc
    aladdinding
        12
    aladdinding  
       2023-02-24 10:07:04 +08:00
    是的 我们需要
    Morii
        13
    Morii  
       2023-02-24 10:08:58 +08:00
    你的场景是不是序列化性能不敏感啊
    DamonLin
        14
    DamonLin  
       2023-02-24 10:09:29 +08:00
    还是看场景吧
    kongkongyzt
        15
    kongkongyzt  
       2023-02-24 10:14:33 +08:00
    主要是性能,有的场景是对性能和实时性比较敏感的,比如交易
    lujiaxing
        16
    lujiaxing  
       2023-02-24 10:23:39 +08:00
    当然需要.
    比如你们这些不做 Java 的, 想找一个类似 Dubbo 的服务间通信 RPC 组件要用什么呢? 如果是 .NET 框架的话除了 ABP 以外就只能用 protobuf-net 了.

    还有涉及到高并发场景下本来就是要尽量减少传输体积. 这种情况下不用 gRPC 用什么, 用 JSON 么? 还是 WCF / RMI ?
    julyclyde
        17
    julyclyde  
       2023-02-24 10:25:25 +08:00
    不过 gRPC 也可以换编码的吧
    有人试过 json 吗?体验怎么样?
    Logtous
        18
    Logtous  
       2023-02-24 10:26:25 +08:00   ❤️ 1
    貌似 MessagePack 挺符合 op 的要求
    Maboroshii
        19
    Maboroshii  
       2023-02-24 10:33:08 +08:00
    grpc 除了编码默认是 protobuf 以外,它还跨平台跨语言。 如果不用跨语言,可以随便找个开源的 rpc 框架用了,不过我看 golang 的 rpc 框架,基本都支持了 pb ,而且吞吐都比 grpc 高。
    Nazz
        20
    Nazz  
    OP
       2023-02-24 10:34:58 +08:00
    @Morii 对于大部分公司, JSON 作为 IDL 性能是可以接受的
    fioncat
        21
    fioncat  
       2023-02-24 10:35:43 +08:00
    当你们公司的 QPS 上去之后,就会发现序列化是个很大的性能瓶颈。
    当然,低业务量的时候无所谓,哪个舒服用哪个。
    duke807
        22
    duke807  
       2023-02-24 10:38:24 +08:00 via Android
    MessagePack +1024
    Nazz
        23
    Nazz  
    OP
       2023-02-24 10:43:28 +08:00
    @mcfog 对于 go 真的可以😂, 别的语言不清楚
    Nazz
        24
    Nazz  
    OP
       2023-02-24 10:45:09 +08:00
    @julyclyde 为什么不占优, 所有请求应答服务都用 HTTP JSON-RPC, 去除了 gRPC
    wanguorui123
        25
    wanguorui123  
       2023-02-24 10:46:28 +08:00
    为了通用性还是 HTTP-JSON 靠谱
    Nazz
        26
    Nazz  
    OP
       2023-02-24 10:47:36 +08:00
    @sadfQED2 流量恐怖如斯, 怎么优化都不为过
    Nazz
        27
    Nazz  
    OP
       2023-02-24 10:49:38 +08:00
    @Maboroshii gRPC 性能方面确实不占优势, HTTP1.1+PB 在内网也能达到非常高的 IOPS
    Nazz
        28
    Nazz  
    OP
       2023-02-24 10:51:01 +08:00
    @lujiaxing gRPC 一般是用在内网, 不开启压缩加密 IOPS 会更高, CPU 占用率更低
    Nazz
        29
    Nazz  
    OP
       2023-02-24 10:51:57 +08:00
    @wuhaoecho JSON 可以方便地在 postman 里面手动编辑
    mafanding
        30
    mafanding  
       2023-02-24 11:14:24 +08:00
    我也有个疑惑 按理说发明 grpc 是为了在内部服务之间更高效的调用,那么为什么现在的微服务还要加 tls 层
    julyclyde
        31
    julyclyde  
       2023-02-24 11:18:27 +08:00
    @Nazz 因为 json 解析的速度慢啊
    Nazz
        32
    Nazz  
    OP
       2023-02-24 11:19:40 +08:00
    @mafanding HTTP1 可以不加 TLS. H2C 好像基本没人用
    AugOmin
        33
    AugOmin  
       2023-02-24 11:21:12 +08:00
    我是用了 grpc 的双向 steam ,在 http2.0 里面 grpc 算是比较常用的,之前还试过 websocket 实现双向 steam ,比 grpc 的 steam 开箱即用程度还是差不少
    Nazz
        34
    Nazz  
    OP
       2023-02-24 11:26:58 +08:00
    @AugOmin 要是我的话会选择 WebSocket, 因为我对 ws 非常的熟悉.
    byte10
        35
    byte10  
       2023-02-24 12:21:58 +08:00
    @mafanding 加 TLS 可能是安全的要求,一般 rpc 应该加鉴权就可以了,加 TLS 感觉有点奇怪。。
    joesonw
        36
    joesonw  
       2023-02-24 12:40:36 +08:00 via iPhone
    @byte10 http2 默认 tls
    idblife
        37
    idblife  
       2023-02-24 13:23:16 +08:00
    grpc 用来翻墙都比其它要快。。。
    Nazz
        38
    Nazz  
    OP
       2023-02-24 13:52:51 +08:00
    @idblife 我用 v2ray
    Goat121
        39
    Goat121  
       2023-02-24 14:59:46 +08:00
    既然性能要求无所谓,还用啥 JSON-RPC ,直接 http 不是更简单更通用
    documentzhangx66
        40
    documentzhangx66  
       2023-02-24 15:26:44 +08:00
    可读性、可调试性,HTTP-JSON 方案完胜。

    性能,gRPC 完胜。

    有钱上 HTTP-JSON ,没钱上 gRPC 。就像有钱上虚拟机,没钱上 docker 一样。
    tool2d
        41
    tool2d  
       2023-02-24 15:34:17 +08:00
    @Nazz "要是我的话会选择 WebSocket, 因为我对 ws 非常的熟悉."

    我也对 ws 比较熟悉,但是 ws 并不算一个好协议。

    一开始我们都是文本传输,后来数据量上去了,发现 ws 的文本压缩协议竟然是扩展协议?并不是每一个客户端都能顺利支持扩展的。

    折腾来折腾去,为了最佳兼容性,只能从文本变成二进制压缩。最后 ws 沦落为一个普通的长连接 socket 来使用。
    guonaihong
        42
    guonaihong  
       2023-02-24 15:46:58 +08:00
    "协议方面更加统一, 没有封装和切换的开销, 中间件可以复用"
    通信层面是 http 还是 tlv 包装一个私有协议?
    Nazz
        43
    Nazz  
    OP
       2023-02-24 16:35:32 +08:00
    @tool2d 好像压缩这块早期挺乱的, 现在都是 permessage-deflate 了. 追求最佳兼容性, 可以在服务端关闭拓展, 自行压缩解压. 开箱即用方面确实不如 gRPC, 强在简单透明, 兼容性更好. 我自己为 ws 写了个 api router 提供 header 元数据和中间件路由组, 有兴趣可以看看: https://github.com/lxzan/uRouter .
    Nazz
        44
    Nazz  
    OP
       2023-02-24 16:36:27 +08:00
    @guonaihong 我指的是对内对外统一使用 HTTP JSON-RPC.
    sophos
        45
    sophos  
       2023-02-24 16:38:31 +08:00
    用上 gRPC 你根本就不用关心编码后的数据长啥样,线上查 bug 看日志不是挺好嘛,线下 debug 就更不用说了

    欢迎看看这个 Go 微服务框架,基于 protobuf 自动生成 HTTP+gRPC 接口,一套代码可以同时实现 HTTP 及 gRPC :-)

    https://github.com/douyu/jupiter-layout
    Nazz
        46
    Nazz  
    OP
       2023-02-24 16:38:55 +08:00
    @documentzhangx66 有很多高性能的 JSON 实现, 除浮点数外, 和 protobuf 差距不是特别大.
    securityCoding
        47
    securityCoding  
       2023-02-24 19:35:52 +08:00
    异构系统用 grpc 舒服一点吧
    aper
        48
    aper  
       2023-02-24 19:40:29 +08:00
    @Nazz 差多了,pb 是 tlv 的结构,json 还要处理不同符号,性能完全不在一个档次上。很多技术文档会为了显示自己牛逼,在某几个特定场景展现自己的优势,具体还得自己测测。
    rocmax
        49
    rocmax  
       2023-02-24 19:47:29 +08:00
    后端微服务之间追求效率的话用 grpc,因为 json 里很大比例是括号。
    前端的话 grpc 也不能直接用,相对于传输效率,前后协作方面的需求更大一些。
    graphql ,trpc 都提供了 api 的信息和类型约束。restful 的话就只能靠 openapi 约定。
    json rpc 看不到任何优势。
    BrettD
        50
    BrettD  
       2023-02-24 20:51:41 +08:00 via iPhone
    有些类型不是 JSON 可以原生表达的
    winRain
        51
    winRain  
       2023-02-24 21:32:48 +08:00
    我一直看到说 grpc 性能比 json 强很多,适合高并发。我是一直没用过 grpc ,但是想问问各位大佬,性能大概是强多少,你们大概并发多少的时候 grpc 会比 json 强?有愿意解答的吗
    fox0001
        52
    fox0001  
       2023-02-24 21:58:56 +08:00   ❤️ 1
    看了下,貌似结论是“我们需要 gRPC”
    lesismal
        53
    lesismal  
       2023-02-24 22:23:33 +08:00   ❤️ 4
    1. Body size:json 字节数包含引号逗号方括号花括号、key 这些,字节数远大于 pb ,所以流量更浪费、对应的网络时间消耗也大一些
    2. Codec:即使高性能的实现,通常后端相同语言 codec 性能也比 pb 差
    json 胜在自释,更灵活;但是其他 rpc 也可以使用 pb ,比如 http+pb+rpc
    3. Transport:grpc 绑定了 HTTP2.0 ; json rpc 可以用 tcp 或者其他可靠的协议,如果内网无所谓安全可以使用 4 层的 tcp ,json rpc 在 transport 这层上的消耗比 grpc 节省很多,性能可能更快
    4. 工程性:强类型结构化,工程更规范。pb 默认这样子了,json 也可以工程规范约束使用强类型结构化,也可以规范

    单说 grpc 的话,我觉得谷歌挺坑的。HTTP2.0 没有解决 4 层 TCP 的线头阻塞问题,对于 rpc 场景,多数是内网,直接 tcp 性能和消耗更友好。rpc 的交互模式就是残疾,对于更广阔的领域的交互需求支撑比较麻烦。

    我的 arpc 除了多语言支持不够(只支持 golang 和前端 js ),其他各方面都比 grpc 强太多了:
    1. transport 可定制,能使用 tcp/tls/kcp/utp/quic/websocket...各种实现了 net.Listener/net.Conn 的协议
    2. codec 可定制,能使用 json/pb/msgpack...各种,你想用啥旧用啥
    3. 交互方式多种多样,支持的业务场景丰富,除了支持传统 rpc 的 Client Call ,也支持 Client Notify/Server Call/Server Notify ,而且支持 CallAsync ,在这些丰富的交互模式下,可以做推送、IM 、游戏...各种业务
    4. 支持中间件,比如你用 gin ,很多中间件,arpc 也可以各种定制
    5. 其他扩展,比如你想单机百万连接,可以再基于 nbio 做网络层
    6. 性能:请搜索参考鸟窝老师这个文章,三方压测比较客观:”2022 Go 生态圈 rpc 框架 Benchmark“。性能甩 grpc 简直不是一条街的,完全不屑于跟 grpc 比性能...
    7. 易用性:3 中列举了支持各种交互模式和业务,使用上也非常简单,就像 golang 标准库 http handler 一样 easy ,不需要像 grpc 那样生成僵硬呆板的代码
    8. 异步的粒度:arpc 支持最灵活的异步,请参考这里: https://github.com/lesismal/arpc/issues/41
    ...

    真的有点不屑于跟其他 rpc 对比了。。。
    MOONLIGHTT
        54
    MOONLIGHTT  
       2023-02-24 22:40:27 +08:00   ❤️ 1
    我们一般用 brpc ,调试的时候可以兼容 json 格式
    jdz
        55
    jdz  
       2023-02-24 23:27:42 +08:00 via Android
    @sadfQED2 可以试下 simdjson
    gant
        56
    gant  
       2023-02-24 23:35:21 +08:00 via iPhone
    @wuhaoecho 我对这个工具很感兴趣。能说下名字吗
    WispZhan
        57
    WispZhan  
       2023-02-24 23:37:36 +08:00 via Android
    只会考虑 Web ,和只写 Web 的程序员有点可怕。
    documentzhangx66
        58
    documentzhangx66  
       2023-02-25 00:07:57 +08:00
    @Nazz

    怎么可能性能差别不大,两者都不是一个层面的东西。

    如果测试结果发现差别不大,请检查你的测试哪里出现瓶颈。
    lambdaq
        59
    lambdaq  
       2023-02-25 00:12:32 +08:00
    gRPC 的点在于类型系统和 schema 迁移方案。。。

    别的 RPC 没解决这两个点就没有可比性。
    mikewang
        60
    mikewang  
       2023-02-25 04:53:51 +08:00 via iPhone
    总觉得最近看到过类似的……
    原来是 /t/913233
    Nazz
        61
    Nazz  
    OP
       2023-02-25 07:41:40 +08:00
    @mikewang 不同之处在于我在输出观点: 大部分 gRPC 的使用场景可以被 JSON-RPC 平替.
    Nazz
        62
    Nazz  
    OP
       2023-02-25 07:42:17 +08:00
    @lesismal gRPC 本身太重了吧, 不然不至于性能这么差.
    Nazz
        63
    Nazz  
    OP
       2023-02-25 07:43:19 +08:00
    @aper 字节的 sonic 可以了解下, 丧心病狂的优化.
    Nazz
        64
    Nazz  
    OP
       2023-02-25 07:44:35 +08:00
    @lambdaq JSON 很容易做到这两点, 但是没看到流行的方案, 可能是因为 gRPC 太流行了.
    lolizeppelin
        65
    lolizeppelin  
       2023-02-25 09:20:03 +08:00
    @lujiaxing

    用传统的 c struct 自己封装啊 哈哈哈哈哈哈哈哈哈
    opentrade
        66
    opentrade  
       2023-02-25 11:40:29 +08:00
    你不需要的东西太多了
    lambdaq
        67
    lambdaq  
       2023-02-25 12:44:25 +08:00
    @Nazz 要做当然是能做的。但是你一个人做,不代表别人用 json 的也会遵守。。。protobuf 从底层遵守了这个特点。

    就跟 C++每一个作者都自己发明一套 String 一样。。
    Nazz
        68
    Nazz  
    OP
       2023-02-25 13:04:49 +08:00 via Android
    @lambdaq 一家公司内容易形成规范,同时存在 gRPC 和 gin 经常要写一些胶水代码
    echoless
        69
    echoless  
       2023-02-25 14:31:06 +08:00
    sardina
        70
    sardina  
       2023-02-25 14:58:27 +08:00 via iPhone
    直接用 tcp 吧
    Valid
        71
    Valid  
       2023-02-25 22:40:49 +08:00
    多大体量才要开始考虑这个开销,我要有这个体量宁愿效率换成本
    Nazz
        72
    Nazz  
    OP
       2023-02-25 23:19:10 +08:00 via Android
    @Valid 大厂考虑得很多,字节的 sonic 优化得丧心病狂
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5511 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 08:17 · PVG 16:17 · LAX 01:17 · JFK 04:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.