10 月 18 日，騰訊開(kāi)源了 RPC 開(kāi)發(fā)框架 ——tRPC，號(hào)稱(chēng)具有 “多語(yǔ)言、高性能” 的特點(diǎn)，首批開(kāi)源支持 Go / Cpp 兩種編程語(yǔ)言。眾所周知，現(xiàn)有的開(kāi)源 RPC 框架已經(jīng)很多了， gRPC、Thrift、Dubbo、bRPC，難道就沒(méi)有一個(gè)能騰訊滿(mǎn)足需求嗎，騰訊是不是在重復(fù)造輪子？我們真的需要這么多 RPC 框架嗎？ 為此，開(kāi)源中國(guó)對(duì)騰訊 tRPC 團(tuán)隊(duì)進(jìn)行了采訪，來(lái)解答網(wǎng)友心中的部分疑惑。

一、有網(wǎng)友認(rèn)為現(xiàn)有的開(kāi)源 RPC 框架已經(jīng)很多了，騰訊搞 tRPC 是在重復(fù)造輪子。您怎么看待這種觀點(diǎn)？

存量的框架的確夠多了，但對(duì)騰訊來(lái)說(shuō)，多一套框架不能只是多了一套，核心是讓存量歸一。

以前在騰訊，都是由業(yè)務(wù)自己選擇 RPC 框架，造成在用的框架種類(lèi)繁多，有開(kāi)源的，有自研的，達(dá)數(shù)十種。它們使用的通信協(xié)議不一樣，使用的名字服務(wù)不一樣，造成服務(wù)之間互通不順暢，阻礙了業(yè)務(wù)的發(fā)展。同時(shí)，眾多的 RPC 框架維護(hù)和使用成本也很高，急需收斂存量框架。是選擇一個(gè)存量框架還是重新開(kāi)發(fā)一個(gè)新的框架去做收斂，我們?cè)陂_(kāi)發(fā) tRPC 之前，也深度思考了這個(gè)問(wèn)題，并在內(nèi)部進(jìn)行了充分的討論，最終決定采用自研 tRPC。因?yàn)轵v訊的業(yè)務(wù)形態(tài)多樣，對(duì)性能、開(kāi)發(fā)語(yǔ)言支持、架構(gòu)開(kāi)放性等方面要求都比較高，已開(kāi)源或者內(nèi)部已有的 RPC 框架或多或少還不能完全滿(mǎn)足騰訊業(yè)務(wù)的需求。

二、騰訊曾在 2017 年開(kāi)源了 RPC 框架 Tars。今天的 tRPC 跟 Tars 有什么聯(lián)系嗎？為什么要另起爐灶又開(kāi)發(fā)了個(gè)新的？

tRPC 和 Tars 是兩個(gè)完全獨(dú)立框架。不過(guò)，tRPC 設(shè)計(jì)之初也有借鑒 Tars 的部分設(shè)計(jì)，tRPC 的部分核心開(kāi)發(fā)設(shè)計(jì)者曾經(jīng)也是 Tars 的核心開(kāi)發(fā)設(shè)計(jì)者。之所以要另起爐灶，主要還是因?yàn)?Tars 不能承擔(dān)起公司內(nèi)部框架存量歸一的目標(biāo)，自身架構(gòu)上比較封閉是最主要的原因。而 tRPC 采用插件化的設(shè)計(jì)，架構(gòu)開(kāi)放性很強(qiáng)，很容易融入到已有的服務(wù)治理平臺(tái)中去，更利于存量收斂。

三、tRPC 項(xiàng)目是從什么時(shí)候開(kāi)始的？背后有什么故事值得分享嗎？

tRPC 項(xiàng)目從 2019 開(kāi)始，到現(xiàn)在已經(jīng) 4 年多了。當(dāng)時(shí)公司存量框架數(shù)量最多的時(shí)候，達(dá)數(shù)十種，嚴(yán)重影響了研發(fā)效率，阻礙業(yè)務(wù)進(jìn)一步發(fā)展。tRPC 從成立到發(fā)展至今確實(shí)也發(fā)生了很多故事。比如在成立之初，對(duì)于是否應(yīng)該另起爐灶去做 tRPC 來(lái)收斂存量框架，當(dāng)時(shí)在公司內(nèi)也是見(jiàn)解不一。我們內(nèi)部論壇就這個(gè)問(wèn)題有一個(gè)帖子，在全公司范圍進(jìn)行了激烈討論，評(píng)論達(dá)到了上百條，pv 到達(dá)上萬(wàn)。不辯不明。

在內(nèi)部經(jīng)過(guò)這么大范圍的討論后，才最終確定了要自研 tRPC。研發(fā) tRPC 得到公司內(nèi)部技術(shù)人員的廣泛支持。為了使 tRPC 能成為集大成的 RPC 框架，能夠承擔(dān)存量歸一的重任，我們研發(fā)采用了內(nèi)部社區(qū)模式，公司很多擅長(zhǎng)框架開(kāi)發(fā)的技術(shù)同事都主動(dòng)積極參與進(jìn)來(lái)，先后為 tRPC 貢獻(xiàn)代碼的人員有數(shù)百人之多。設(shè)計(jì)研發(fā)過(guò)程中也是各種思想碰撞，比如 tRPC 插件化的總體架構(gòu)形態(tài)的確定，就是通過(guò)幾次數(shù)十人的閉門(mén)會(huì)議，在激烈的爭(zhēng)吵中形成的。

四、為什么要將 tRPC 開(kāi)源？希望開(kāi)源能給該項(xiàng)目帶來(lái)什么？

開(kāi)源 tRPC 的原因有兩個(gè)：1. 公司內(nèi)部業(yè)務(wù)對(duì)外擴(kuò)展時(shí)需要。如游戲出海，業(yè)務(wù)需要在外部企業(yè)私有化部署，這時(shí)候因?yàn)闃I(yè)務(wù)開(kāi)發(fā)使用了 tRPC，需要把代碼交付出去。2. 希望通過(guò)開(kāi)源對(duì)外做更多的技術(shù)分享交流，并借助社區(qū)的力量來(lái)進(jìn)一步將 tRPC 打造得更好。

五、官方提到 tRPC 支持多種通信協(xié)議，能具體說(shuō)一下支持哪些通信協(xié)議嗎？協(xié)議的通用性和高性能可以兼得嗎？

tRPC 框架默認(rèn)支持 tRPC 協(xié)議，還支持業(yè)界 HTTP （s）/gRPC/bRPC/Tars/Thrift 協(xié)議，以及公司內(nèi)部多種通信協(xié)議，目前只開(kāi)源了 HTTP （s）/gRPC 協(xié)議，未來(lái)會(huì)逐步開(kāi)源其它協(xié)議。

對(duì)于協(xié)議這塊通用性和高性能是否兼得的問(wèn)題，這里更多地要看業(yè)務(wù)場(chǎng)景和需求，如果想要通用性，可以選擇 HTTP 或者 gRPC 協(xié)議，如果想要高性能，可以選擇 tRPC 協(xié)議，因?yàn)閰f(xié)議本身設(shè)計(jì)和實(shí)現(xiàn)會(huì)對(duì)性能有比較大的影響。

六、相比較于其他開(kāi)源框架，tRPC 出現(xiàn)得比較晚。從 RPC 框架的演進(jìn)歷史來(lái)看，tRPC 與其他開(kāi)源 RPC 框架有什么本質(zhì)上的區(qū)別嗎？

RPC 框架演進(jìn)到現(xiàn)在確實(shí)已經(jīng)很成熟了，業(yè)界開(kāi)源的 RPC 框架各自之間也都很難說(shuō)有什么本質(zhì)區(qū)別，更多的是符合各自業(yè)務(wù)發(fā)展的訴求。tRPC 出現(xiàn)的主要目的是做公司存量框架收斂，它有一定的后發(fā)優(yōu)勢(shì)，可以吸取已有存量框架的優(yōu)點(diǎn)，規(guī)避不足，通過(guò)在高性能的基礎(chǔ)上基于插件化思想去構(gòu)建開(kāi)放性的架構(gòu)，使它能更適用于騰訊多樣復(fù)雜的業(yè)務(wù)場(chǎng)景。

七、官方提到項(xiàng)目規(guī)劃，主要有兩點(diǎn)，一是開(kāi)源更多編程語(yǔ)言：Java、Python、Node，二是豐富生態(tài)，開(kāi)源更多云原生相關(guān)的插件和組件。想問(wèn)下是出于哪些方面考慮，將其作為未來(lái)重點(diǎn)開(kāi)發(fā)方向？

主要還是希望框架能夠更廣泛和高效地使用起來(lái)，更多的開(kāi)發(fā)語(yǔ)言支持能覆蓋更多的場(chǎng)景，如現(xiàn)在很多企業(yè)都是使用 Java 語(yǔ)言，tRPC 只有支持 Java 才有可能成為其候選。又如現(xiàn)在 AI 場(chǎng)景大部分都使用 Python，那么 tRPC 支持了 Python 才有可能被使用。

豐富生態(tài)也是希望 tRPC 能夠幫助使用者能夠更快速構(gòu)建自己的微服務(wù)體系。目前大家都喜歡使用云原生相關(guān)的組件去構(gòu)建自己的微服務(wù)體系，tRPC 如果能夠豐富云原生的插件生態(tài)，那么用戶(hù)使用 tRPC 和這些云原生的組件對(duì)接就會(huì)更高效快捷。

八、騰訊有 tRPC，百度有 bRPC，阿里有 Dubbo，字節(jié)有 Volo，為什么每個(gè)大廠都要開(kāi)發(fā)自己的 RPC 框架？

大廠為什么都要開(kāi)發(fā)自己的 RPC 框架？個(gè)人覺(jué)得主要還是業(yè)務(wù)形態(tài)決定的。雖然 RPC 框架看起來(lái)都差不多，但真正應(yīng)用到業(yè)務(wù)時(shí)，根據(jù)業(yè)務(wù)的形態(tài)不同又會(huì)有很多差異。如果使用開(kāi)源的框架，很有可能要費(fèi)很大的成本才能解決這些差異，花費(fèi)的時(shí)間周期也會(huì)更長(zhǎng)，甚至可能解決不了。比如我們?cè)谟螒驁?chǎng)景使用 tRPC 時(shí)，發(fā)現(xiàn)游戲這種有狀態(tài)的業(yè)務(wù)場(chǎng)景，通用的 RPC 設(shè)計(jì)并不能滿(mǎn)足其需求，我們也是基于 tRPC 插件化的架構(gòu)，通過(guò)和游戲團(tuán)隊(duì)合作替換了底層通信組件后，才滿(mǎn)足了游戲場(chǎng)景的需求。如果采用的開(kāi)源框架，這個(gè)問(wèn)題可能就很難解決了。

編輯：黃飛