我们真的需要 gRPC 吗?

[Nazz]

相对 gRPC, JSON-RPC:

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

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

[tool2d]

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

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

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

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

[guonaihong]

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

[Nazz]

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

[Nazz]

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

[sophos]

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

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

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

[Nazz]

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

[securityCoding]

异构系统用 grpc 舒服一点吧

[aper]

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

[rocmax]

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

[BrettD]

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

[winRain]

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

[fox0001]

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

[lesismal]

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]

我们一般用 brpc ，调试的时候可以兼容 json 格式

[jdz]

@sadfQED2 可以试下 simdjson

[gant]

@wuhaoecho 我对这个工具很感兴趣。能说下名字吗

[WispZhan]

只会考虑 Web ，和只写 Web 的程序员有点可怕。

[documentzhangx66]

@Nazz

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

如果测试结果发现差别不大，请检查你的测试哪里出现瓶颈。

[lambdaq]

gRPC 的点在于类型系统和 schema 迁移方案。。。

别的 RPC 没解决这两个点就没有可比性。

[mikewang]

总觉得最近看到过类似的……
原来是 /t/913233