tRPC跟Tars有什么聯(lián)系？為什么要將tRPC開源？

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

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

存量的框架的確夠多了，但對騰訊來說，多一套框架不能只是多了一套，核心是讓存量歸一。

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

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

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

三、tRPC 項目是從什么時候開始的？背后有什么故事值得分享嗎？

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

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

四、為什么要將 tRPC 開源？希望開源能給該項目帶來什么？

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

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

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

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

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

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

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

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

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

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

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

編輯：黃飛