我们真的需要 gRPC 吗?

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

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

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

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

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

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

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

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

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

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

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

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

是的 我们需要

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

还是看场景吧

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

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

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

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

貌似 MessagePack 挺符合 op 的要求

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

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

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

MessagePack +1024

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

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

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

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

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

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

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

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

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

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

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

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

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

@byte10 http2 默认 tls

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

@idblife 我用 v2ray

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

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

性能，gRPC 完胜。

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

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

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

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

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

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

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

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

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

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

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

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

异构系统用 grpc 舒服一点吧

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

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

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

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

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

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

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

@sadfQED2 可以试下 simdjson

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

@Nazz

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

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

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

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

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

@mikewang 不同之处在于我在输出观点: 大部分 gRPC 的使用场景可以被 JSON-RPC 平替.

@lesismal gRPC 本身太重了吧, 不然不至于性能这么差.

@aper 字节的 sonic 可以了解下, 丧心病狂的优化.

@lambdaq JSON 很容易做到这两点, 但是没看到流行的方案, 可能是因为 gRPC 太流行了.

@lujiaxing

用传统的 c struct 自己封装啊 哈哈哈哈哈哈哈哈哈

你不需要的东西太多了

@Nazz 要做当然是能做的。但是你一个人做，不代表别人用 json 的也会遵守。。。protobuf 从底层遵守了这个特点。

就跟 C++每一个作者都自己发明一套 String 一样。。

@lambdaq 一家公司内容易形成规范，同时存在 gRPC 和 gin 经常要写一些胶水代码

@gant https://github.com/bradleyjkemp/grpc-tools/tree/master/grpc-proxy 我很早之前用过

直接用 tcp 吧

多大体量才要开始考虑这个开销，我要有这个体量宁愿效率换成本

@Valid 大厂考虑得很多，字节的 sonic 优化得丧心病狂