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 插件化的架構，通過和游戲團隊合作替換了底層通信組件后，才滿足了游戲場景的需求。如果采用的開源框架，這個問題可能就很難解決了。

編輯：黃飛