百度正式開源其RPC框架brpc
9 月 14 日，百度正式在 GitHub 上基于 Apache 2.0 協議開源了其 RPC 框架 brpc。brpc 是一個基于 protobuf 接口的 RPC 框架，在百度內部稱為“baidu-rpc”，它囊括了百度內部所有 RPC 協議，并支持多種第三方協議，從目前的性能測試數據來看，brpc 的性能領跑于其他同類 RPC 產品。
brpc 開發于 2014 年，主要使用的語言是 C++ 和 Java，是百度內部使用最為廣泛的 RPC 框架，它經受了高并發高負載的生產環境驗證，并支撐了百度內部大約 75 萬個同時在線的實例。據 InfoQ 了解，百度內部曾有多款 RPC 框架，甚至在 2014 年時還開源過另外一款 RPC 框架 sofa-pbrpc。那 brpc 是在什么樣的背景下誕生的？它有什么樣的優勢？又為何要開源？就這些問題，InfoQ 記者采訪了 brpc 負責人戈君。
InfoQ：談談 brpc 的一些基本情況？什么時候開始研發的？經過了怎么樣的迭代和升級？目前在內部應用情況如何？
戈君：brpc 于 2014 年創建，在百度內部稱為“baidu-rpc”。到目前為止，brpc 一共進行了 3000 次左右的改動，現在仍在持續優化中，百度內的 wiki 上可以查詢到每次改動的描述。brpc 的主要語言是 C++ 和 Java，對其他語言的支持主要是通過包裝 C++ 版本，比如 brpc 的 Python 版包含 C++ 版的大部分功能。
brpc 目前支撐百度內部大約 75 萬個同時在線的實例（不含 client），超過 500 種服務（去年的統計，現在已不統計這類數據）。Hadoop、Table、Mola（另一種廣泛使用的存儲）、高性能計算、模型訓練、大量的在線檢索服務都使用了 brpc。brpc 第一次統一了百度內分布式系統和業務線的通信框架。
InfoQ：為什么百度當時要研發 brpc？
戈君：我們在實踐中意識到，RPC 作為最基礎的通信組件，當時的百度已經不領先了。我當時的經理劉煬曾是 Google 的工程師，非常重視基礎架構的建設，也愿意在這個方向投入資源。
我們在內部會更加深入地討論這些問題。“好用”有時看起來很主觀，但其實還是有據可循的，它的關鍵點是能不能真正地提高用戶的效率：開發、調試、維護都要考慮到，如果用戶效率真的被提高了，用戶會想著你的，靠吹噓或政令推廣的東西得不了人心。我們創建 brpc 的初衷是解決百度業務所面臨的實際挑戰，同時也希望成為百度同學最喜愛的工具，哪怕離開百度也會懷念 brpc。我們希望在提供了一個好用框架的同時，也展現了一種工作方法：注釋怎么寫，日志怎么打，ChangeLog 怎么寫，版本怎么發布，文檔怎么組織，甚至對未來不在百度的同學的工作也有幫助，所以從這點來說 brpc 從一開始就是擁抱開源的。事實上，我們在口碑上做得還不錯，brpc 的 wiki 可能是百度內被點贊最多的內容之一。
InfoQ：與其他的一些開源的 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 上匯總。這樣大部分問題用戶可以自助解決。其實我們去看也是看這些，只是會更加專業。內置服務的具體說明可以看這里。
InfoQ：作為公司內部的 RPC 框架，在服務治理方面有什么考慮？
戈君：百度內部 RPC 使用非常廣泛，基本都是 RPC 調用，一些產品線還會通過 local RPC 隔離工程框架和策略代碼。這么多年下來，服務周邊的系統也比較全面了：編譯是 BCLOUD，發布是 Agile，服務注冊和發現是 BNS，認證是 Giano，監控和運維是 NOAH。在百度內部，brpc 和這些系統做了比較緊密的綁定，用戶體驗是一站式的。雖然在開源版本中，這些結合大都刪掉了，但用戶可以根據自己組織中的基礎設施來進行定制：交互協議，名字服務，負載均衡算法都可以定制。對于其中一些特別通用的，我們希望用戶反饋到開源版本中來以方便所有人。
InfoQ：之前百度還開源過 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 框架也是良性的競爭關系，在比拼誰能真正提高用戶效率的過程中共同進步。每個用戶都可以去對比代碼、文檔質量，接口設計，易用程度，擴展能力等，投出自己的一票。
InfoQ：談談 brpc 的整體架構？
戈君：技術棧無外乎是從傳輸層壘到應用層，就略過不講了，具體可以去看下開源出來的文檔。brpc 在架構上強調“在不犧牲易用性的前提下增強可擴展性”，比如 brpc 支持非常多的協議，在百度內部一個 brpc server 同端口可以支持二十幾種協議，這對于服務的平滑遷移就非常好用。
Client 端的協議也非常多，用戶用 brpc 和 bthread 用得很爽，所以希望我們最好能統一所有的客戶端，像對 Redis 和 Memcached 的客戶端支持也是在這個背景下做的，這兩個客戶端比官方 Client 好用多了，感興趣的讀者可以去嘗試一下。但這么多協議的配置非常簡單，填個字符串就行了，比如 HTTP 就是把 ChannelOptions.protocol 設為“http”，Redis 就是“redis”。Server 端甚至不用設，它會自動判斷每個 client 的協議，怎么做到的開源文檔里也有。
名字服務、負載均衡也都可以定制。但為了對用戶負責，我們也不鼓勵“太自由”的定制，比如一點點需求的變化就要搞個新的，這時更需要想清楚本質區別是什么。這個事情我們在百度內的支持群里每天都在做，我們是開放的”乙方”，但我們也是嚴厲的”乙方”。
InfoQ：brpc 的性能如何？這么高的性能是怎么做到的？
戈君：性能是我們非常看中的一點，它和用戶體驗也是緊密聯系的。好用但性能不行，或不好用但性能很牛，用戶會很難受，我們不希望用戶糾結。從另一個角度來看，在推廣初期，我們要說服產品線用 brpc 靠什么？最直觀的就是性能提升。而且這兒的性能不能停留在 benchmark 的圖片上，而是能在真實應用中體現出來。開放出來的案例文檔中或多或少都包含了性能提升，具體如下：
和其他 RPC 框架（包含 thrift、gRPC）的性能對比可以見這里。
開源文檔中概括了性能上的設計， “RPC in depth”這一節下的文檔會談的更細點。這里我不贅述，還請直接閱讀文檔。
InfoQ：為什么要將 brpc 開源？接下來在開源項目的迭代方面有什么計劃嗎？
戈君：因為馬上還有不少依賴 RPC 的百度系統要開源啊。RPC 作為最基礎的組件，開源不僅僅是為了自身，也是為其它開源項目鋪路，比如說我們馬上還會開源基于 brpc 的 RAFT 庫，搭建高可用分布式系統非常方便；以及使用 brpc 的 bigflow，讓流式計算變得很順手。這些年百度對開源的認識也在不斷加深，開源看似曝光了百度的核心技術，但帶來的生態影響力更重要。從 Apollo、PaddlePaddle 開始，百度真的開始擁抱開源了。brpc 的開源版和內部版很接近，只是去掉了對百度內部獨有的一些基礎設施的支持，我們在內網寫的深入分析 RPC 技術細節的文檔也都一并開源了，后續也會及時推送改動，請大家放心。這是一個活項目，不會拉個開源分支就不管了。
來自: InfoQ