V2EX › 程序员

我们真的需要 gRPC 吗?

Nazz · 19 小时 37 分钟前 · 5247 次点击

相对 gRPC, JSON-RPC:

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

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

60 条回复 • 2023-02-25 04:53:51 +08:00

julyclyde 19 小时 30 分钟前 8

说白了 gRPC 并不是给人类用的啊，你这个所谓简单透明、可读性其实没啥用

封装切换开销，json 并不占优

chendy 19 小时 28 分钟前

一个序列化二进制，一个序列化文本
侧重点就不一样，没法比

tool2d 19 小时 27 分钟前

一个文本协议，另一个二进制协议，完全不一样的东西。

sadfQED2 19 小时 26 分钟前 via Android

编解码性能差远了，你不在乎这点性能当然无脑 json 啊。高并发场景下 json 编解码动不动就干满 cpu

totoro52 19 小时 25 分钟前

emmm json 不是更重吗而且这个就是给机器看的

DefoliationM 19 小时 24 分钟前

我们真的需要 HTTP 协议吗，现在感觉 HTTP 协议就是一坨狗屎，不如 rpc 直观方便

changnet 19 小时 24 分钟前

json 的序列化性能和 protobuf 的序列化性能（效率和包大小）不是同一个级别的吧，如果对性能不高，用 json 可读性当然更高

yty2012g 19 小时 19 分钟前

我怎么觉得你这三点都不是基于 json 的 rpc 的优点呀...
1. grpc 用的 pb 的协议描述文件怎么看也比 json 更加明确和透明，json 的类型不够丰富
2. 序列化大 JSON 字符串的 CPU 开销是巨大的，代价远比 pb 的序列化要高。
3. 可读性方面，pb 也可以将对象直接打印出来啊，当然你说要通过抓包的时候就能直接从二进制看出数据内容，那确实 JSON 更好，只不过一般不是这么玩的

julyclyde 19 小时 15 分钟前

@DefoliationM 所以后来 http 也不文本了

wuhaoecho 19 小时 14 分钟前 via Android

@yty2012g pb 也可以通过代理看明文

mcfog 19 小时 14 分钟前

关于最后一个问题，我推荐一个支持生成各大语言 JSON 代码的命令行工具：protoc

aladdinding 19 小时 9 分钟前

是的我们需要

Morii 19 小时 7 分钟前

你的场景是不是序列化性能不敏感啊

DamonLin 19 小时 7 分钟前

还是看场景吧

kongkongyzt 19 小时 2 分钟前

主要是性能，有的场景是对性能和实时性比较敏感的，比如交易

lujiaxing 18 小时 53 分钟前

当然需要.
比如你们这些不做 Java 的, 想找一个类似 Dubbo 的服务间通信 RPC 组件要用什么呢? 如果是 .NET 框架的话除了 ABP 以外就只能用 protobuf-net 了.

还有涉及到高并发场景下本来就是要尽量减少传输体积. 这种情况下不用 gRPC 用什么, 用 JSON 么? 还是 WCF / RMI ?

julyclyde 18 小时 51 分钟前

不过 gRPC 也可以换编码的吧
有人试过 json 吗？体验怎么样？

Logtous 18 小时 50 分钟前 1

貌似 MessagePack 挺符合 op 的要求

Maboroshii 18 小时 43 分钟前

grpc 除了编码默认是 protobuf 以外，它还跨平台跨语言。如果不用跨语言，可以随便找个开源的 rpc 框架用了，不过我看 golang 的 rpc 框架，基本都支持了 pb ，而且吞吐都比 grpc 高。

Nazz 18 小时 41 分钟前

@Morii 对于大部分公司, JSON 作为 IDL 性能是可以接受的

fioncat 18 小时 41 分钟前

当你们公司的 QPS 上去之后，就会发现序列化是个很大的性能瓶颈。
当然，低业务量的时候无所谓，哪个舒服用哪个。

duke807 18 小时 38 分钟前 via Android

MessagePack +1024

Nazz 18 小时 33 分钟前

@mcfog 对于 go 真的可以😂, 别的语言不清楚

Nazz 18 小时 31 分钟前

@julyclyde 为什么不占优, 所有请求应答服务都用 HTTP JSON-RPC, 去除了 gRPC

wanguorui123 18 小时 30 分钟前

为了通用性还是 HTTP-JSON 靠谱

Nazz 18 小时 29 分钟前

@sadfQED2 流量恐怖如斯, 怎么优化都不为过

Nazz 18 小时 27 分钟前

@Maboroshii gRPC 性能方面确实不占优势, HTTP1.1+PB 在内网也能达到非常高的 IOPS

Nazz 18 小时 25 分钟前

@lujiaxing gRPC 一般是用在内网, 不开启压缩加密 IOPS 会更高, CPU 占用率更低

Nazz 18 小时 24 分钟前

@wuhaoecho JSON 可以方便地在 postman 里面手动编辑

mafanding 18 小时 2 分钟前

我也有个疑惑按理说发明 grpc 是为了在内部服务之间更高效的调用，那么为什么现在的微服务还要加 tls 层

julyclyde 17 小时 58 分钟前

@Nazz 因为 json 解析的速度慢啊

Nazz 17 小时 57 分钟前

@mafanding HTTP1 可以不加 TLS. H2C 好像基本没人用

AugOmin 17 小时 55 分钟前

我是用了 grpc 的双向 steam ，在 http2.0 里面 grpc 算是比较常用的，之前还试过 websocket 实现双向 steam ，比 grpc 的 steam 开箱即用程度还是差不少

Nazz 17 小时 49 分钟前

@AugOmin 要是我的话会选择 WebSocket, 因为我对 ws 非常的熟悉.

byte10 16 小时 54 分钟前

@mafanding 加 TLS 可能是安全的要求，一般 rpc 应该加鉴权就可以了，加 TLS 感觉有点奇怪。。

joesonw 16 小时 36 分钟前 via iPhone

@byte10 http2 默认 tls

idblife 15 小时 53 分钟前

grpc 用来翻墙都比其它要快。。。

Nazz 15 小时 23 分钟前

@idblife 我用 v2ray

Goat121 14 小时 17 分钟前

既然性能要求无所谓，还用啥 JSON-RPC ，直接 http 不是更简单更通用

documentzhangx66 13 小时 50 分钟前

可读性、可调试性，HTTP-JSON 方案完胜。

性能，gRPC 完胜。

有钱上 HTTP-JSON ，没钱上 gRPC 。就像有钱上虚拟机，没钱上 docker 一样。

tool2d 13 小时 42 分钟前

@Nazz "要是我的话会选择 WebSocket, 因为我对 ws 非常的熟悉."

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

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

折腾来折腾去，为了最佳兼容性，只能从文本变成二进制压缩。最后 ws 沦落为一个普通的长连接 socket 来使用。

guonaihong 13 小时 29 分钟前

"协议方面更加统一, 没有封装和切换的开销, 中间件可以复用"
通信层面是 http 还是 tlv 包装一个私有协议？

Nazz 12 小时 41 分钟前

@tool2d 好像压缩这块早期挺乱的, 现在都是 permessage-deflate 了. 追求最佳兼容性, 可以在服务端关闭拓展, 自行压缩解压. 开箱即用方面确实不如 gRPC, 强在简单透明, 兼容性更好. 我自己为 ws 写了个 api router 提供 header 元数据和中间件路由组, 有兴趣可以看看: https://github.com/lxzan/uRouter .

Nazz 12 小时 40 分钟前

@guonaihong 我指的是对内对外统一使用 HTTP JSON-RPC.

sophos 12 小时 38 分钟前

用上 gRPC 你根本就不用关心编码后的数据长啥样，线上查 bug 看日志不是挺好嘛，线下 debug 就更不用说了

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

https://github.com/douyu/jupiter-layout

Nazz 12 小时 37 分钟前

@documentzhangx66 有很多高性能的 JSON 实现, 除浮点数外, 和 protobuf 差距不是特别大.

securityCoding 9 小时 40 分钟前

异构系统用 grpc 舒服一点吧

aper 9 小时 36 分钟前

@Nazz 差多了，pb 是 tlv 的结构，json 还要处理不同符号，性能完全不在一个档次上。很多技术文档会为了显示自己牛逼，在某几个特定场景展现自己的优势，具体还得自己测测。

rocmax 9 小时 29 分钟前

后端微服务之间追求效率的话用 grpc,因为 json 里很大比例是括号。
前端的话 grpc 也不能直接用，相对于传输效率，前后协作方面的需求更大一些。
graphql ，trpc 都提供了 api 的信息和类型约束。restful 的话就只能靠 openapi 约定。
json rpc 看不到任何优势。

BrettD 8 小时 25 分钟前 via iPhone

有些类型不是 JSON 可以原生表达的

winRain 7 小时 43 分钟前

我一直看到说 grpc 性能比 json 强很多，适合高并发。我是一直没用过 grpc ，但是想问问各位大佬，性能大概是强多少，你们大概并发多少的时候 grpc 会比 json 强？有愿意解答的吗

fox0001 7 小时 17 分钟前 1

看了下，貌似结论是“我们需要 gRPC”

lesismal 6 小时 53 分钟前 3

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 对比了。。。