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技術細節的文檔也都一并開源了，后續也會及時推送改動，請大家放心。這是一個活項目，不會拉個開源分支就不管了。
標簽：
本站文章除注明轉載外，均為本站原創或翻譯。歡迎任何形式的轉載，但請務必注明出處、不得修改原文相關鏈接，如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn
金喜正規買球 
5次
金喜正規買球相關的文章 
微信
在線咨詢
渝公網安備
50010702500608號
客服熱線