gRPC 和普通 HTTP API 哪个更适合 APP 客户端与服务器通信？为什么大部分 APP 都还在使用传统 HTTP API？

[drymonfidelia]

[lambdaq]

这什么沙雕问题。我来给你个沙雕回答吧。最适合的是用 h2 传输 pb ，然后 pb 就定义一个 string 字段用来传 json 字符串。

[kw8023cn]

@drymonfidelia #10 如果你的目标用户，地理位置都是山区的话，那确实可以考虑

[tbxark]

http 方便抓包调试，方便给 web 和小程序服务。grpc 还是适合微服务之间通信。

[f7014367google]

如果有服务需要扩容，请问阁下该怎么使用 gRPC 进行负载均衡呢？

[willchen]

@f7014367google 这不是问题吧 nginx 也早支持了

[julyclyde]

@drymonfidelia 客户都弱网了，还有啥价值啊……

以及，为啥要 base64 ？ http 难道不支持 binary 么？

[julyclyde]

@lambdaq 我还以为用 json 代替 pb 作为编码层呢……你这个太狠了

[lambdaq]

@julyclyde 然后把 图片 base64 到 json 里传输～

[minoic]

@hxzhouh1 grpc-web 是为了适配浏览器环境，其实约等于是 grpc-js ，支持各种工作环境反而更方便它替代一些 http 场景。

[jeesk]

@kk2syc 扯淡想要性能还玩 grpc ?

[kaf]

grpc 基于 http2 封装的，而且现在 http2 基本也普及了，直接用 http2 也没什么差别啊，更不要说满大街前端一辈子都是写 json

[sampeng]

你可以不用啊。又没人强迫你。你去怼你同事和老大去啊。。。

[hxzhouh1]

@minoic 所以咯，GRPC 是有缺陷的，需要一些其他组件来支持。

[inhzus]

前司用的就是类似的协议，性能有提升吗：客户端几乎没有，接入层的提升很大。弱网环境相较竞品，快，真的快
大部分 App 有这个必要吗？没必要。

[guoooo00oohao]

还是要看场景，大部分情况下 http 就够用了，生态成熟比如开发，调试，debug ，生产环境的网关，trace 都有很多现成的方案。

grpc 有 encoding 虽然大部分情况下性能比 http 要好一些，但是不容易 debug 。

[kk2syc]

@jeesk 扯淡的说就是提升性能，当然你也可以自己搞一套所谓的压缩复用

[f7014367google]

@willchen 这不就是"又"引入了额外的组件吗？比如跑在 k8s 上的微服务，用了 gRPC ，"又"需要额外引入一个"nginx ingress"。

[KiraMaple]

我个人认为 gRPC 的着重点是 RPC 上，可以在微服务/CS 之间像调用本地函数一样调用其他服务的函数，这能极大提升开发效率，但也需要通信的双方协议对齐，这是 RPC 的特点。因为 gRPC 最终打包接口采用的 protobuf ，一个非常优秀的序列化反序列化方案，这能带来更低的流量和更好的性能。也因为采用了 protobuf ，让浏览器上开发调试的时候变得更加复杂，比如 xml/json 那么清晰。不过 protobuf 带来的好处其实 i 也可以依托其他高效的序列化方案来处理。不过 gRPC 很多特性是依托较新浏览器特性才能支持的，所以它对浏览器的支持有一定要求。
相反在微服务之间的场景几乎没有上述所说的诸多缺点，所以现阶段 gRPC 更多还是用在微服务之间的调用或者 BS 模型的产品。

[skipper1314]

1 、还是 HTTP 更普及，而且不容易被 QOS
2 、HTTP 调试抓包和分析比 gRPC 更方便
3 、gRPC 确实有很多优化，高效的全双工流式传输等等。但是，就像可读性相比性能，肯定可读性和易用性更优先。

[jeesk]

@KiraMaple grpc 和浏览器有啥关系? 不过 gRPC 很多特性是依托较新浏览器特性才能支持的 ?