这是一个创建于 636 天前的主题，其中的信息可能已经有所发展或是发生改变。
相对 gRPC, JSON-RPC:
- 协议方面更加简单透明
- 协议方面更加统一, 没有封装和切换的开销, 中间件可以复用
- JSON 可读性更好, 开发调试方便
最后问一下, 有根据文件生成各大语言 JSON 代码的命令行工具吗?
 |
1
julyclyde 2023-02-24 09:46:01 +08:00  8
说白了 gRPC 并不是给人类用的啊，你这个所谓简单透明、可读性其实没啥用
封装切换开销，json 并不占优 |
 |
2
chendy 2023-02-24 09:48:05 +08:00
一个序列化二进制，一个序列化文本
侧重点就不一样，没法比 |
 |
3
tool2d 2023-02-24 09:48:59 +08:00
一个文本协议，另一个二进制协议，完全不一样的东西。
|
 |
4
sadfQED2 2023-02-24 09:50:18 +08:00 via Android
编解码性能差远了，你不在乎这点性能当然无脑 json 啊。高并发场景下 json 编解码动不动就干满 cpu
|
 |
5
totoro52 2023-02-24 09:50:55 +08:00
emmm json 不是更重吗 而且这个就是给机器看的
|
 |
6
DefoliationM 2023-02-24 09:51:47 +08:00 1
我们真的需要 HTTP 协议吗，现在感觉 HTTP 协议就是一坨狗屎，不如 rpc 直观方便
|
 |
7
changnet 2023-02-24 09:51:51 +08:00 1
json 的序列化性能和 protobuf 的序列化性能（效率和包大小）不是同一个级别的吧，如果对性能不高，用 json 可读性当然更高
|
 |
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 更好，只不过一般不是这么玩的 |
|
9
julyclyde 2023-02-24 10:01:29 +08:00
@DefoliationM 所以后来 http 也不文本了
|
 |
11
mcfog 2023-02-24 10:02:42 +08:00 1
关于最后一个问题，我推荐一个支持生成各大语言 JSON 代码的命令行工具：protoc
|
 |
12
aladdinding 2023-02-24 10:07:04 +08:00
是的 我们需要
|
 |
13
28Sv0ngQfIE7Yloe 2023-02-24 10:08:58 +08:00
你的场景是不是序列化性能不敏感啊
|
 |
14
DamonLin 2023-02-24 10:09:29 +08:00
还是看场景吧
|
 |
15
kongkongyzt 2023-02-24 10:14:33 +08:00
主要是性能，有的场景是对性能和实时性比较敏感的，比如交易
|
 |
16
lujiaxing 2023-02-24 10:23:39 +08:00
当然需要.
比如你们这些不做 Java 的, 想找一个类似 Dubbo 的服务间通信 RPC 组件要用什么呢? 如果是 .NET 框架的话除了 ABP 以外就只能用 protobuf-net 了. 还有涉及到高并发场景下本来就是要尽量减少传输体积. 这种情况下不用 gRPC 用什么, 用 JSON 么? 还是 WCF / RMI ? |
|
17
julyclyde 2023-02-24 10:25:25 +08:00
不过 gRPC 也可以换编码的吧
有人试过 json 吗？体验怎么样？ |
 |
18
Logtous 2023-02-24 10:26:25 +08:00 1
貌似 MessagePack 挺符合 op 的要求
|
 |
19
Maboroshii 2023-02-24 10:33:08 +08:00
grpc 除了编码默认是 protobuf 以外，它还跨平台跨语言。 如果不用跨语言，可以随便找个开源的 rpc 框架用了，不过我看 golang 的 rpc 框架，基本都支持了 pb ，而且吞吐都比 grpc 高。
|
 |
21
fioncat 2023-02-24 10:35:43 +08:00
当你们公司的 QPS 上去之后，就会发现序列化是个很大的性能瓶颈。
当然，低业务量的时候无所谓，哪个舒服用哪个。 |
 |
22
duke807 2023-02-24 10:38:24 +08:00 via Android
MessagePack +1024
|
 |
25
wanguorui123 2023-02-24 10:46:28 +08:00
为了通用性还是 HTTP-JSON 靠谱
|
 |
27
Nazz OP @Maboroshii gRPC 性能方面确实不占优势, HTTP1.1+PB 在内网也能达到非常高的 IOPS
|
 |
30
mafanding 2023-02-24 11:14:24 +08:00
我也有个疑惑 按理说发明 grpc 是为了在内部服务之间更高效的调用，那么为什么现在的微服务还要加 tls 层
|
 |
33
AugOmin 2023-02-24 11:21:12 +08:00
我是用了 grpc 的双向 steam ，在 http2.0 里面 grpc 算是比较常用的，之前还试过 websocket 实现双向 steam ，比 grpc 的 steam 开箱即用程度还是差不少
|
 |
37
idblife 2023-02-24 13:23:16 +08:00
grpc 用来翻墙都比其它要快。。。
|
 |
39
Goat121 2023-02-24 14:59:46 +08:00
既然性能要求无所谓，还用啥 JSON-RPC ，直接 http 不是更简单更通用
|
 |
40
documentzhangx66 2023-02-24 15:26:44 +08:00
可读性、可调试性，HTTP-JSON 方案完胜。
性能，gRPC 完胜。 有钱上 HTTP-JSON ，没钱上 gRPC 。就像有钱上虚拟机，没钱上 docker 一样。 |
|
41
tool2d 2023-02-24 15:34:17 +08:00
@Nazz "要是我的话会选择 WebSocket, 因为我对 ws 非常的熟悉."
我也对 ws 比较熟悉，但是 ws 并不算一个好协议。 一开始我们都是文本传输，后来数据量上去了，发现 ws 的文本压缩协议竟然是扩展协议？并不是每一个客户端都能顺利支持扩展的。 折腾来折腾去，为了最佳兼容性，只能从文本变成二进制压缩。最后 ws 沦落为一个普通的长连接 socket 来使用。 |
 |
42
guonaihong 2023-02-24 15:46:58 +08:00
"协议方面更加统一, 没有封装和切换的开销, 中间件可以复用"
通信层面是 http 还是 tlv 包装一个私有协议？ |
|
43
Nazz OP @tool2d 好像压缩这块早期挺乱的, 现在都是 permessage-deflate 了. 追求最佳兼容性, 可以在服务端关闭拓展, 自行压缩解压. 开箱即用方面确实不如 gRPC, 强在简单透明, 兼容性更好. 我自己为 ws 写了个 api router 提供 header 元数据和中间件路由组, 有兴趣可以看看: https://github.com/lxzan/uRouter .
|
|
44
Nazz OP @guonaihong 我指的是对内对外统一使用 HTTP JSON-RPC.
|
 |
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 |
|
46
Nazz OP @documentzhangx66 有很多高性能的 JSON 实现, 除浮点数外, 和 protobuf 差距不是特别大.
|
 |
47
securityCoding 2023-02-24 19:35:52 +08:00
异构系统用 grpc 舒服一点吧
|
 |
48
aper 2023-02-24 19:40:29 +08:00
@Nazz 差多了，pb 是 tlv 的结构，json 还要处理不同符号，性能完全不在一个档次上。很多技术文档会为了显示自己牛逼，在某几个特定场景展现自己的优势，具体还得自己测测。
|
 |
49
rocmax 2023-02-24 19:47:29 +08:00
后端微服务之间追求效率的话用 grpc,因为 json 里很大比例是括号。
前端的话 grpc 也不能直接用，相对于传输效率，前后协作方面的需求更大一些。 graphql ，trpc 都提供了 api 的信息和类型约束。restful 的话就只能靠 openapi 约定。 json rpc 看不到任何优势。 |
 |
50
BrettD 2023-02-24 20:51:41 +08:00 via iPhone
有些类型不是 JSON 可以原生表达的
|
 |
51
winRain 2023-02-24 21:32:48 +08:00
我一直看到说 grpc 性能比 json 强很多，适合高并发。我是一直没用过 grpc ，但是想问问各位大佬，性能大概是强多少，你们大概并发多少的时候 grpc 会比 json 强？有愿意解答的吗
|
 |
52
fox0001 2023-02-24 21:58:56 +08:00 1
看了下，貌似结论是“我们需要 gRPC”
|
 |
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 对比了。。。 |
 |
54
MOONLIGHTT 2023-02-24 22:40:27 +08:00 1
我们一般用 brpc ，调试的时候可以兼容 json 格式
|
 |
57
WispZhan 2023-02-24 23:37:36 +08:00 via Android
只会考虑 Web ，和只写 Web 的程序员有点可怕。
|
|
58
documentzhangx66 2023-02-25 00:07:57 +08:00
|
 |
59
lambdaq 2023-02-25 00:12:32 +08:00
gRPC 的点在于类型系统和 schema 迁移方案。。。
别的 RPC 没解决这两个点就没有可比性。 |
 |
65
lolizeppelin 2023-02-25 09:20:03 +08:00
|
 |
66
opentrade 2023-02-25 11:40:29 +08:00
你不需要的东西太多了
|
|
67
lambdaq 2023-02-25 12:44:25 +08:00
|
 |
69
echoless 2023-02-25 14:31:06 +08:00
|
 |
70
sardina 2023-02-25 14:58:27 +08:00 via iPhone
直接用 tcp 吧
|
 |
71
Valid 2023-02-25 22:40:49 +08:00
多大体量才要开始考虑这个开销，我要有这个体量宁愿效率换成本
|
Select Language