您的位置:  首页 > 技术杂谈 > 正文

我们真的需要这么多 RPC 框架吗?

2023-11-13 11:00 https://my.oschina.net/u/3859945/blog/10142659 肖滢 次阅读 条评论

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插件化的架构,通过和游戏团队合作替换了底层通信组件后,才满足了游戏场景的需求。如果采用的开源框架,这个问题可能就很难解决了。

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接