自研微服务框架

前一小节我们看到，业界已经有非常多的微服务框架了，那我们是不是可以拿来就用就可以了呢？理论上，我们根据团队技术栈选择一个比较符合的微服务框架之后，再适当做些协议编解码、日志、监控等组件的扩展应该就可以用起来了。列出的流行的微服务框架，也有专门的团队维护、生态相对来说也很健康。

那我们似乎没有什么理由不选择这些开源项目？这也未必。

是否有必要自研框架

一个体量很大的公司，比如BAT、ByteDance这种级别的，公司内部的研发人员可能涉及了各种各样的技术栈，CC++、Java、Go、Python、JavaScript、Rust、Ruby、PHP……如果统筹规划一个多语言版本的框架服务于不同技术栈的同学，那是极好的，但是确实需要很大的魄力才能推动这个事情最终落地。

更可能的选择是，不同技术栈的同学选择各自不同的微服务框架，比如Go Micro、Spring Boot、BRpc等，然后针对这些框架分别定制化一些插件，以对接公司业务不同的日志平台、监控平台等。这样看上去节省了人力，但是时间长了以后，未必会省人力。

考虑下不同技术栈的同学之间可能会涉及到服务交接，如工程团队小A同学交接了一批Java服务给小B同学，但是小B主要技术栈是Go，可能会想为什么不交接给懂Java的同学，anyway，这样的情况总会发生的。实际影响就是熟悉这些框架耗费人力、修改维护也比较困难。

还有就是使用了未经统一规划的框架，很可能在框架能力、插件生态上也没有完全对齐，有可能Java选择的微服务框架使用监控系统A，但是Go选择的微服务框架使用监控系统B。这样交接一个Java服务给Go开发同学，由于监控等运营系统的变更，很可能使用起来不习惯或者需要重新对接熟悉的监控系统。

不难理解，这样的情况多了之后，会直接导致研发效率的下降。

腾讯内部tRPC框架

腾讯从2019年7月开始发起了技术治理，其中有一项就是统一微服务框架（tRPC），目前内部开源但是未对外开源。令人可喜的一点就是，不同编程语言的框架开发小组，从框架设计之初就在一起设计、讨论、pk，框架整体架构、框架能力、插件化设计是一致的，如网络通信都是遵循服务注册发现、rpc方式、均支持同样的熔断、限流、重试等策略。

性能方面涉及到具体语言，当然有允许自我发挥的地方，来追求更极致的性能。如trpc-go是go语言版本实现，通过对标准库src/net的深度优化来改善连接管理、IO、处理性能，效果明显。

在整体设计、框架能力、插件化设计等方面对齐后，这意味着服务交接不再是一个困难的问题，至少从开发方式、问题排查方式上是比较接近的。也给了很多同学一种动力想去深入了解下不同版本的框架的实现细节，触类旁通了解共性的同时，也能了解不同语言的一些特性。这也无形中为我们更好地培养社区、协同共建做了一些铺垫。

需不需要自研微服务框架，很多人会将其归类到“重复造轮子”的范畴，算不算呢？算是，也不算是。试想，一个宝马X5的轮子，能算是杜卡迪大魔鬼的轮子吗？轮子不合适再造一个也无妨。这其实就是个正向收益、成本的权衡问题。再造的目的就是让它更符合团队技术侧需要，提高研发、运营效率，提高运营质量，归根结底还是对业务负责。

所以，既然可以明确轮子不合适，那我也并不很在意重新造一个 :)

为什么不使用gRPC

其实腾讯内部也是有团队使用gRPC框架的，比如IEG、CSIG有不少团队是使用gRPC来开发的，tRPC框架也通过codec、transport层面的插件化设计支持了gRPC。

那为什么不直接使用gRPC框架呢？因为不够用。看上去gRPC是一个很通用、插件化设计也做的不错的框架、生态也很健康，但是它不能完全满足公司内部对框架能力的需要。

要知道，腾讯不是一个新成立的公司，团队内部有很多服务是基于tcp、udp等传输层协议构建的存量系统，各种tcp、udp之上的应用层协议不下一二十个。单这一点就足够淘汰gRPC（仅支持http协议），因为支持存量系统接入更现代的监控运维体系，也是非常大的一个考量。

其他更多原因，就不罗列了，在后续的设计实现中会选择性地讲一下。

说明一下，trpc目前已经开源，项目地址见：https://github.com/trpc-group