把公司内部服务通讯的 http 全改成了 grpc，看着连接数过山车式的下降，真舒坦

[itstudying]

改之前内部服务的连接数比用户的连接数还多

[lxd152]

棒棒棒

[optional]

这 tps/qps 没变少吧，，只是 grpc 走了 http/2

[gstqc]

有性能对比吗

[TypeError]

连接复用了？

[meteor957]

这也太夸张了吧

[fox1955]

经历过 http -> grpc. 性能的提升远不及联调开发效率的降低, 最后换回去了.

[ofooo]

不是只换了一种链接方式么? 通讯量应该一样才对吧?

[dcalsky]

各个服务之间共用 protoc 吗，protoc gen 等基础设施经验能分享一下吗？

[diveIntoWork]

改成 gRpc 后，不走 Http 协议了，统计出来的连接数当然变少了，要看 cpu 利用率、内存占用、吞吐才有意义

[outoftimeerror]

grpc 不也是基于 http2 吗

[itstudying]

@TypeError #4 是的 http2 的多路复用

[itstudying]

@ofooo #7
@diveIntoWork #9
是的 不过改造的目的就只是为了降低连接数，以及因为连接太多带来的内存占用大。监控平台中能最直观看出来改造前后区别的也就这个

[itstudying]

@outoftimeerror #10 是呀 只是因为 http2 支持多路复用，不搞连接池的话也就只有一个连接

[luozic]

这种得开发配套的工具链，否则出问题联调，apm 接入，debug 等等一堆的工具链需要开发配套，如过涉及到 cdn，网络硬件等更深远的坑，就等着哭吧。restful with http 主要是生态，别的东西有个 JB 生态

[itstudying]

@luozic 服务之间通讯使用 rpc 框架不是很正常的吗，grpc 虽然没 http 生态好但也是很成熟的了，也不至于差很多到了会踩很多深坑的地步。更不至于像你说的 JB 生态都没有

[luozic]

@itstudying 我的意思是边界约定好，大公司使用一部分特殊能性能的工具是他们能配套建立全链路的工具，小公司一般没有，而这种全链路的工具没听说过哪家开源的。rest 是因为文本的自然原因导致容易找到全链路的替代品。

[luozic]

最简单的 apm 用啥，API gateway 等最基础的服务治理有几个支持了，支持程度如何？

[wangyzj]

不喜欢 pb
都是 http2
会有很大变化吗

[itstudying]

@luozic grpc 也就是个 http2 也有 header，也有请求 path 多说无益…… 搜索引擎第一页就有结果

[itstudying]

@wangyzj 实际只是复用了连接，不想用 pb 不用就是～