我们真的需要 gRPC 吗?

[Nazz]

相对 gRPC, JSON-RPC:

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

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

[julyclyde]

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

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

[chendy]

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

[tool2d]

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

[sadfQED2]

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

[totoro52]

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

[DefoliationM]

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

[changnet]

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

[yty2012g]

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

[julyclyde]

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

[echoless]

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

[mcfog]

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

[aladdinding]

是的 我们需要

[Morii]

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

[DamonLin]

还是看场景吧

[kongkongyzt]

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

[lujiaxing]

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

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

[julyclyde]

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

[Logtous]

貌似 MessagePack 挺符合 op 的要求

[Maboroshii]

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

[Nazz]

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