百度正式開源其RPC框架brpc

9月14日，百度正式在GitHub上基於Apache 2.0協議開源了其RPC框架brpc。brpc是一個基於protobuf接口的RPC框架，在百度內部稱爲「baidu-rpc」，它囊括了百度內部全部RPC協議，並支持多種第三方協議，從目前的性能測試數據來看，brpc的性能領跑於其餘同類RPC產品。

brpc開發於2014年，主要使用的語言是C++和Java，是百度內部使用最爲普遍的RPC框架，它經受了高併發高負載的生產環境驗證，並支撐了百度內部大約75萬個同時在線的實例。據瞭解，百度內部曾有多款RPC框架，甚至在2014年時還開源過另一款RPC框架sofa-pbrpc。那brpc是在什麼樣的背景下誕生的？它有什麼樣的優點？又爲什麼要開源？就這些問題，InfoQ記者採訪了brpc負責人戈君。

Q：談談brpc的一些基本狀況？何時開始研發的？通過了怎麼樣的迭代和升級？目前在內部應用狀況如何？
戈君：brpc於2014年建立，在百度內部稱爲「baidu-rpc」。到目前爲止，brpc一共進行了3000次左右的改動，如今仍在持續優化中，百度內的wiki上能夠查詢到每次改動的描述。brpc的主要語言是C++和Java，對其餘語言的支持主要是經過包裝C++版本，好比brpc的Python版包含C++版的大部分功能。

brpc目前支撐百度內部大約75萬個同時在線的實例（不含client），超過500種服務（去年的統計，如今已不統計這類數據）。Hadoop、Table、Mola（另外一種普遍使用的存儲）、高性能計算、模型訓練、大量的在線檢索服務都使用了brpc。brpc第一次統一了百度內分佈式系統和業務線的通訊框架。

Q：爲何百度當時要研發brpc？
戈君：咱們在實踐中意識到，RPC做爲最基礎的通訊組件，當時的百度已經不領先了。我當時的經理劉煬曾是Google的工程師，很是重視基礎架構的建設，也願意在這個方向投入資源。

咱們在內部會更加深刻地討論這些問題。「好用」有時看起來很主觀，但其實仍是有據可循的，它的關鍵點是能不能真正地提升用戶的效率：開發、調試、維護都要考慮到，若是用戶效率真的被提升了，用戶會想着你的，靠吹噓或政令推廣的東西得不了人心。咱們建立brpc的初衷是解決百度業務所面臨的實際挑戰，同時也但願成爲百度同窗最喜好的工具，哪怕離開百度也會懷念brpc。咱們但願在提供了一個好用框架的同時，也展示了一種工做方法：註釋怎麼寫，日誌怎麼打，ChangeLog怎麼寫，版本怎麼發佈，文檔怎麼組織，甚至對將來不在百度的同窗的工做也有幫助，因此從這點來講brpc從一開始就是擁抱開源的。事實上，咱們在口碑上作得還不錯，brpc的wiki多是百度內被點贊最多的內容之一。

Q：與其餘的一些開源的RPC框架相比，brpc的優點是什麼？
戈君：brpc主打的是深度和易用性。一方面咱們沒有精力像gRPC那樣攤大餅，什麼都作。另外一方面咱們也注意到gRPC（包括更早的Thrift）的深度和易用性並不夠。技術方面的東西就是這樣，看示例程序，文檔很是牛逼，但實戰中可能就是另外一回事了，爲何各個公司都要造本身的輪子，一個隱藏緣由就是表面高大上的東西在一些細節上讓你沒法忍受。

RPC真正的痛點是什麼？是可靠性、易用性和定位問題的便利性。服務中不要出現不可解釋的長尾，程序的可變項要儘可能少，各類詭異問題要有工具支持快速排查。而這些在目前開源的RPC框架中作的並很差，它們大多看着很牛，但就是沒法在本身組織中推廣開來。回到前面那三點，brpc是如何作的呢？
可靠性。這一方面是代碼質量問題，經過爲brpc團隊設立很高的招聘門檻，以及在團隊中深刻的技術討論，咱們確保了穩固的代碼基礎。另外一個問題是長尾問題，這是設計問題，brpc其實包含了不少模塊，其中的bthread是一個M:N線程庫，就是爲了更好地提升併發避免阻塞。brpc中的讀和寫都是wait-free的，這是最高程度的併發。技術細節請點擊連接查看。
易用性。有種設計是什麼選擇都作成選項丟給用戶，號稱功能都有，但一旦出問題，則是用戶「配置錯了」。並且這樣用戶還很是依賴開發團隊，沒有開發團隊的支持基本用不了，開發團隊有足夠的理由擴充團隊。這麼作其實很是不負責任，用戶面對海量的選項也很難受。brpc對於增長選項很是謹慎，框架能本身作判斷的毫不扔給用戶，全部用戶選項都有最合理的默認值，不設也能用。咱們認爲這對用戶體驗來講很是重要。
定位問題的便利性。這點其它開源框架目前作的都很差，正常使用是能夠的，但出問題就麻煩了。這個問題在百度內部其實也很嚴重，brpc以前用戶排查問題都要拉RPC同窗一塊兒排查，RPC框架對用戶是個黑盒，用戶根本不知道里面發生了什麼。按咱們的經驗，基本天天都有幾個用戶在羣裏問server卡頓，client超時之類的問題，排查問題是常態，人手必然不夠。時間長了用戶就以爲你這個框架各類問題，人還拽的不行不多回他們消息。brpc的解決辦法是給server內加入各類HTTP接口的內置服務，經過這些服務，用戶能夠很快看到server的延時、錯誤、鏈接、跟蹤某個RPC、CPU熱點、內存分配、鎖競爭等信息，用戶還可使用bvar來自定義各種統計信息，並在百度的運維平臺NOAH上彙總。這樣大部分問題用戶能夠自助解決。其實咱們去看也是看這些，只是會更加專業。內置服務的具體說明能夠看這裏。

Q：做爲公司內部的RPC框架，在服務治理方面有什麼考慮？
戈君：百度內部RPC使用很是普遍，基本都是RPC調用，一些產品線還會經過local RPC隔離工程框架和策略代碼。這麼多年下來，服務周邊的系統也比較全面了：編譯是BCLOUD，發佈是Agile，服務註冊和發現是BNS，認證是Giano，監控和運維是NOAH。在百度內部，brpc和這些系統作了比較緊密的綁定，用戶體驗是一站式的。雖然在開源版本中，這些結合大都刪掉了，但用戶能夠根據本身組織中的基礎設施來進行定製：交互協議，名字服務，負載均衡算法均可以定製。對於其中一些特別通用的，咱們但願用戶反饋到開源版本中來以方便全部人。

Q：以前百度還開源過sofa-pbrpc，brpc與它的區別是什麼？
戈君：sofa-pbrpc也是百度開發的一個比較早期的RPC框架，屬於sofa編程框架的一部分，在搜索有應用。brpc相比sofa-pbrpc有以下優勢:
對協議的抽象更通常化，並統一了全百度的通訊架構。bprc能容納很是多的協議，基於Protobuf的，基於HTTP的，百度內的nshead/mcpack，開源的Redis/Memcached，甚至RTMP/FLV/HLS直播協議，brpc能逐漸地嵌入現有系統，而不須要完全重構，但sofa-pbrpc則不具有擴展協議的能力。相似的，sofa-pbrpc也沒法定製負載均衡算法，brpc默認提供round-robin、隨機、一致性哈希，Locality-aware（局部性感知）四種算法，用戶還能定製。
多線程質量更好。多線程編程是很是困難的，看起來簡單的RPC遍及多線程陷阱，好比處理超時的代碼可能在RPC還沒發出去時就運行了；發送函數還沒結束，處理回覆的回調就被運行了；一個回覆還在被處理另外一個回覆回來了，諸如此類。另外，一個異步RPC的回調裏發起一個同步RPC會發生什麼，帶着鎖作同步RPC會發生什麼。這些問題咱們都不能在sofa-pbrpc中找到滿意的答案。
完備的調試和運維支持。解決這個問題的本質還在可擴展性，你如何讓用戶參與進來定製他們感興趣的指標，爲此咱們設計了bvar，讓用戶能用比原子變量代價還小的方式自由地定製各類指標，用戶能在瀏覽器上看到指標的變化曲線，或在運維平臺NOAH看到彙總的監控數據。brpc還加入了大量內置服務方便用戶調試程序，查看鏈接，在線修改gflags，追蹤RPC，分析CPU熱點，內存分配，鎖競爭等包羅萬象。
無需諱言，brpc在誕生之初和sofa-pbrpc在百度內部是有競爭關係的，但就像其餘地方同樣，這種競爭帶來了活力。相似的，brpc和其餘已經開源的RPC框架也是良性的競爭關係，在比拼誰能真正提升用戶效率的過程當中共同進步。每一個用戶均可以去對比代碼、文檔質量，接口設計，易用程度，擴展能力等，投出本身的一票。

Q：談談brpc的總體架構？
戈君：技術棧無外乎是從傳輸層壘到應用層，就略過不講了，具體能夠去看下開源出來的文檔。brpc在架構上強調「在不犧牲易用性的前提下加強可擴展性」，好比brpc支持很是多的協議，在百度內部一個brpc server同端口能夠支持二十幾種協議，這對於服務的平滑遷移就很是好用。

Client端的協議也很是多，用戶用brpc和bthread用得很爽，因此但願咱們最好能統一全部的客戶端，像對Redis和Memcached的客戶端支持也是在這個背景下作的，這兩個客戶端比官方Client好用多了，感興趣的讀者能夠去嘗試一下。但這麼多協議的配置很是簡單，填個字符串就好了，好比HTTP就是把ChannelOptions.protocol設爲「http」，Redis就是「redis」。Server端甚至不用設，它會自動判斷每一個client的協議，怎麼作到的開源文檔裏也有。

名字服務、負載均衡也均可以定製。但爲了對用戶負責，咱們也不鼓勵「太自由」的定製，好比一點點需求的變化就要搞個新的，這時更須要想清楚本質區別是什麼。這個事情咱們在百度內的支持羣裏天天都在作，咱們是開放的」乙方」，但咱們也是嚴厲的」乙方」。

Q：brpc的性能如何？這麼高的性能是怎麼作到的？
戈君：性能是咱們很是看中的一點，它和用戶體驗也是緊密聯繫的。好用但性能不行，或很差用但性能很牛，用戶會很難受，咱們不但願用戶糾結。從另外一個角度來看，在推廣初期，咱們要說服產品線用brpc靠什麼？最直觀的就是性能提高。並且這兒的性能不能停留在benchmark的圖片上，而是能在真實應用中體現出來。開放出來的案例文檔中或多或少都包含了性能提高，具體以下：
百度地圖API入口
聯盟DSP
ELF學習框架
雲平臺代理服務

Q：爲何要將brpc開源？接下來在開源項目的迭代方面有什麼計劃嗎？
戈君：由於立刻還有很多依賴RPC的百度系統要開源啊。RPC做爲最基礎的組件，開源不只僅是爲了自身，也是爲其它開源項目鋪路，好比說咱們立刻還會開源基於brpc的RAFT庫，搭建高可用分佈式系統很是方便；以及使用brpc的bigflow，讓流式計算變得很順手。這些年百度對開源的認識也在不斷加深，開源看似曝光了百度的核心技術，但帶來的生態影響力更重要。從Apollo、PaddlePaddle開始，百度真的開始擁抱開源了。brpc的開源版和內部版很接近，只是去掉了對百度內部獨有的一些基礎設施的支持，咱們在內網寫的深刻分析RPC技術細節的文檔也都一併開源了，後續也會及時推送改動，請你們放心。這是一個活項目，不會拉個開源分支就無論了。