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

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

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

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

@idblife 我用 v2ray

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

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

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

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

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

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

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

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

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

刚学 go 的时候我也很疑惑，json_encode, json_decode 和万能的 array 用习惯了而已

刷 star 国际影响不好🤣

推荐私有全局变量, 包内进行相关操作, 尽量可控

interface 了解下

@lesismal codec 的开销可以接受