tRPC跟Tars有什么联系？为什么要将tRPC开源？

10 月 18 日，腾讯开源了 RPC 开发框架 ——tRPC，号称具有 “多语言、高性能” 的特点，首批开源支持 Go / Cpp 两种编程语言。众所周知，现有的开源 RPC 框架已经很多了， gRPC、Thrift、Dubbo、bRPC，难道就没有一个能腾讯满足需求吗，腾讯是不是在重复造轮子？我们真的需要这么多 RPC 框架吗？ 为此，开源中国对腾讯 tRPC 团队进行了采访，来解答网友心中的部分疑惑。

一、有网友认为现有的开源 RPC 框架已经很多了，腾讯搞 tRPC 是在重复造轮子。您怎么看待这种观点？

存量的框架的确够多了，但对腾讯来说，多一套框架不能只是多了一套，核心是让存量归一。

以前在腾讯，都是由业务自己选择 RPC 框架，造成在用的框架种类繁多，有开源的，有自研的，达数十种。它们使用的通信协议不一样，使用的名字服务不一样，造成服务之间互通不顺畅，阻碍了业务的发展。同时，众多的 RPC 框架维护和使用成本也很高，急需收敛存量框架。是选择一个存量框架还是重新开发一个新的框架去做收敛，我们在开发 tRPC 之前，也深度思考了这个问题，并在内部进行了充分的讨论，最终决定采用自研 tRPC。因为腾讯的业务形态多样，对性能、开发语言支持、架构开放性等方面要求都比较高，已开源或者内部已有的 RPC 框架或多或少还不能完全满足腾讯业务的需求。

二、腾讯曾在 2017 年开源了 RPC 框架 Tars。今天的 tRPC 跟 Tars 有什么联系吗？为什么要另起炉灶又开发了个新的？

tRPC 和 Tars 是两个完全独立框架。不过，tRPC 设计之初也有借鉴 Tars 的部分设计，tRPC 的部分核心开发设计者曾经也是 Tars 的核心开发设计者。之所以要另起炉灶，主要还是因为 Tars 不能承担起公司内部框架存量归一的目标，自身架构上比较封闭是最主要的原因。而 tRPC 采用插件化的设计，架构开放性很强，很容易融入到已有的服务治理平台中去，更利于存量收敛。

三、tRPC 项目是从什么时候开始的？背后有什么故事值得分享吗？

tRPC 项目从 2019 开始，到现在已经 4 年多了。当时公司存量框架数量最多的时候，达数十种，严重影响了研发效率，阻碍业务进一步发展。tRPC 从成立到发展至今确实也发生了很多故事。比如在成立之初，对于是否应该另起炉灶去做 tRPC 来收敛存量框架，当时在公司内也是见解不一。我们内部论坛就这个问题有一个帖子，在全公司范围进行了激烈讨论，评论达到了上百条，pv 到达上万。不辩不明。

在内部经过这么大范围的讨论后，才最终确定了要自研 tRPC。研发 tRPC 得到公司内部技术人员的广泛支持。为了使 tRPC 能成为集大成的 RPC 框架，能够承担存量归一的重任，我们研发采用了内部社区模式，公司很多擅长框架开发的技术同事都主动积极参与进来，先后为 tRPC 贡献代码的人员有数百人之多。设计研发过程中也是各种思想碰撞，比如 tRPC 插件化的总体架构形态的确定，就是通过几次数十人的闭门会议，在激烈的争吵中形成的。

四、为什么要将 tRPC 开源？希望开源能给该项目带来什么？

开源 tRPC 的原因有两个：1. 公司内部业务对外扩展时需要。如游戏出海，业务需要在外部企业私有化部署，这时候因为业务开发使用了 tRPC，需要把代码交付出去。2. 希望通过开源对外做更多的技术分享交流，并借助社区的力量来进一步将 tRPC 打造得更好。

五、官方提到 tRPC 支持多种通信协议，能具体说一下支持哪些通信协议吗？协议的通用性和高性能可以兼得吗？

tRPC 框架默认支持 tRPC 协议，还支持业界 HTTP （s）/gRPC/bRPC/Tars/Thrift 协议，以及公司内部多种通信协议，目前只开源了 HTTP （s）/gRPC 协议，未来会逐步开源其它协议。

对于协议这块通用性和高性能是否兼得的问题，这里更多地要看业务场景和需求，如果想要通用性，可以选择 HTTP 或者 gRPC 协议，如果想要高性能，可以选择 tRPC 协议，因为协议本身设计和实现会对性能有比较大的影响。

六、相比较于其他开源框架，tRPC 出现得比较晚。从 RPC 框架的演进历史来看，tRPC 与其他开源 RPC 框架有什么本质上的区别吗？

RPC 框架演进到现在确实已经很成熟了，业界开源的 RPC 框架各自之间也都很难说有什么本质区别，更多的是符合各自业务发展的诉求。tRPC 出现的主要目的是做公司存量框架收敛，它有一定的后发优势，可以吸取已有存量框架的优点，规避不足，通过在高性能的基础上基于插件化思想去构建开放性的架构，使它能更适用于腾讯多样复杂的业务场景。

七、官方提到项目规划，主要有两点，一是开源更多编程语言：Java、Python、Node，二是丰富生态，开源更多云原生相关的插件和组件。想问下是出于哪些方面考虑，将其作为未来重点开发方向？

主要还是希望框架能够更广泛和高效地使用起来，更多的开发语言支持能覆盖更多的场景，如现在很多企业都是使用 Java 语言，tRPC 只有支持 Java 才有可能成为其候选。又如现在 AI 场景大部分都使用 Python，那么 tRPC 支持了 Python 才有可能被使用。

丰富生态也是希望 tRPC 能够帮助使用者能够更快速构建自己的微服务体系。目前大家都喜欢使用云原生相关的组件去构建自己的微服务体系，tRPC 如果能够丰富云原生的插件生态，那么用户使用 tRPC 和这些云原生的组件对接就会更高效快捷。

八、腾讯有 tRPC，百度有 bRPC，阿里有 Dubbo，字节有 Volo，为什么每个大厂都要开发自己的 RPC 框架？

大厂为什么都要开发自己的 RPC 框架？个人觉得主要还是业务形态决定的。虽然 RPC 框架看起来都差不多，但真正应用到业务时，根据业务的形态不同又会有很多差异。如果使用开源的框架，很有可能要费很大的成本才能解决这些差异，花费的时间周期也会更长，甚至可能解决不了。比如我们在游戏场景使用 tRPC 时，发现游戏这种有状态的业务场景，通用的 RPC 设计并不能满足其需求，我们也是基于 tRPC 插件化的架构，通过和游戏团队合作替换了底层通信组件后，才满足了游戏场景的需求。如果采用的开源框架，这个问题可能就很难解决了。

编辑：黄飞