日韩高清不卡,一区二区在线免费视频,日本丰满少妇

百度正式開源其RPC框架brpc

轉(zhuǎn)帖|行業(yè)資訊|編輯：黃竹雯|2017-09-29 09:35:22.000|閱讀 915 次

概述：百度正式在GitHub上基于Apache 2.0協(xié)議開源了其RPC框架brpc。brpc是一個(gè)基于protobuf接口的RPC框架，在百度內(nèi)部稱為“baidu-rpc”。

9月14日，百度正式在GitHub上基于Apache 2.0協(xié)議開源了其RPC框架brpc。brpc是一個(gè)基于protobuf接口的RPC框架，在百度內(nèi)部稱為“baidu-rpc”，它囊括了百度內(nèi)部所有RPC協(xié)議，并支持多種第三方協(xié)議，從目前的性能測(cè)試數(shù)據(jù)來看，brpc的性能領(lǐng)跑于其他同類RPC產(chǎn)品。

brpc開發(fā)于2014年，主要使用的語言是C++和Java，是百度內(nèi)部使用最為廣泛的RPC框架，它經(jīng)受了高并發(fā)高負(fù)載的生產(chǎn)環(huán)境驗(yàn)證，并支撐了百度內(nèi)部大約75萬個(gè)同時(shí)在線的實(shí)例。據(jù)了解，百度內(nèi)部曾有多款RPC框架，甚至在2014年時(shí)還開源過另外一款RPC框架sofa-pbrpc。那brpc是在什么樣的背景下誕生的？它有什么樣的優(yōu)勢(shì)？又為何要開源？就這些問題，InfoQ記者采訪了brpc負(fù)責(zé)人戈君。

Q：談?wù)刡rpc的一些基本情況？什么時(shí)候開始研發(fā)的？經(jīng)過了怎么樣的迭代和升級(jí)？目前在內(nèi)部應(yīng)用情況如何？

戈君：brpc于2014年創(chuàng)建，在百度內(nèi)部稱為“baidu-rpc”。到目前為止，brpc一共進(jìn)行了3000次左右的改動(dòng)，現(xiàn)在仍在持續(xù)優(yōu)化中，百度內(nèi)的wiki上可以查詢到每次改動(dòng)的描述。brpc的主要語言是C++和Java，對(duì)其他語言的支持主要是通過包裝C++版本，比如brpc的Python版包含C++版的大部分功能。

brpc目前支撐百度內(nèi)部大約75萬個(gè)同時(shí)在線的實(shí)例（不含client），超過500種服務(wù)（去年的統(tǒng)計(jì)，現(xiàn)在已不統(tǒng)計(jì)這類數(shù)據(jù)）。Hadoop、Table、Mola（另一種廣泛使用的存儲(chǔ)）、高性能計(jì)算、模型訓(xùn)練、大量的在線檢索服務(wù)都使用了brpc。brpc第一次統(tǒng)一了百度內(nèi)分布式系統(tǒng)和業(yè)務(wù)線的通信框架。

Q：為什么百度當(dāng)時(shí)要研發(fā)brpc？

戈君：我們?cè)趯?shí)踐中意識(shí)到，RPC作為最基礎(chǔ)的通信組件，當(dāng)時(shí)的百度已經(jīng)不領(lǐng)先了。我當(dāng)時(shí)的經(jīng)理劉煬曾是Google的工程師，非常重視基礎(chǔ)架構(gòu)的建設(shè)，也愿意在這個(gè)方向投入資源。

我們?cè)趦?nèi)部會(huì)更加深入地討論這些問題。“好用”有時(shí)看起來很主觀，但其實(shí)還是有據(jù)可循的，它的關(guān)鍵點(diǎn)是能不能真正地提高用戶的效率：開發(fā)、調(diào)試、維護(hù)都要考慮到，如果用戶效率真的被提高了，用戶會(huì)想著你的，靠吹噓或政令推廣的東西得不了人心。我們創(chuàng)建brpc的初衷是解決百度業(yè)務(wù)所面臨的實(shí)際挑戰(zhàn)，同時(shí)也希望成為百度同學(xué)最喜愛的工具，哪怕離開百度也會(huì)懷念brpc。我們希望在提供了一個(gè)好用框架的同時(shí)，也展現(xiàn)了一種工作方法：注釋怎么寫，日志怎么打，ChangeLog怎么寫，版本怎么發(fā)布，文檔怎么組織，甚至對(duì)未來不在百度的同學(xué)的工作也有幫助，所以從這點(diǎn)來說brpc從一開始就是擁抱開源的。事實(shí)上，我們?cè)诳诒献龅眠€不錯(cuò)，brpc的wiki可能是百度內(nèi)被點(diǎn)贊最多的內(nèi)容之一。

Q：與其他的一些開源的RPC框架相比，brpc的優(yōu)勢(shì)是什么？

戈君：brpc主打的是深度和易用性。一方面我們沒有精力像gRPC那樣攤大餅，什么都做。另一方面我們也注意到gRPC（包括更早的Thrift）的深度和易用性并不夠。技術(shù)方面的東西就是這樣，看示例程序，文檔非常牛逼，但實(shí)戰(zhàn)中可能就是另一回事了，為什么各個(gè)公司都要造自己的輪子，一個(gè)隱藏原因就是表面高大上的東西在一些細(xì)節(jié)上讓你無法忍受。

RPC真正的痛點(diǎn)是什么？是可靠性、易用性和定位問題的便利性。服務(wù)中不要出現(xiàn)不可解釋的長(zhǎng)尾，程序的可變項(xiàng)要盡量少，各種詭異問題要有工具支持快速排查。而這些在目前開源的RPC框架中做的并不好，它們大多看著很牛，但就是無法在自己組織中推廣開來。回到前面那三點(diǎn)，brpc是如何做的呢？

可靠性。這一方面是代碼質(zhì)量問題，通過為brpc團(tuán)隊(duì)設(shè)立很高的招聘門檻，以及在團(tuán)隊(duì)中深入的技術(shù)討論，我們確保了穩(wěn)固的代碼基礎(chǔ)。另一個(gè)問題是長(zhǎng)尾問題，這是設(shè)計(jì)問題，brpc其實(shí)包含了很多模塊，其中的bthread是一個(gè)M:N線程庫，就是為了更好地提高并發(fā)避免阻塞。brpc中的讀和寫都是wait-free的，這是最高程度的并發(fā)。技術(shù)細(xì)節(jié)請(qǐng)點(diǎn)擊鏈接查看。
易用性。有種設(shè)計(jì)是什么選擇都做成選項(xiàng)丟給用戶，號(hào)稱功能都有，但一旦出問題，則是用戶“配置錯(cuò)了”。而且這樣用戶還非常依賴開發(fā)團(tuán)隊(duì)，沒有開發(fā)團(tuán)隊(duì)的支持基本用不了，開發(fā)團(tuán)隊(duì)有足夠的理由擴(kuò)充團(tuán)隊(duì)。這么做其實(shí)非常不負(fù)責(zé)任，用戶面對(duì)海量的選項(xiàng)也很難受。brpc對(duì)于增加選項(xiàng)非常謹(jǐn)慎，框架能自己做判斷的絕不扔給用戶，所有用戶選項(xiàng)都有最合理的默認(rèn)值，不設(shè)也能用。我們認(rèn)為這對(duì)用戶體驗(yàn)來說非常重要。
定位問題的便利性。這點(diǎn)其它開源框架目前做的都不好，正常使用是可以的，但出問題就麻煩了。這個(gè)問題在百度內(nèi)部其實(shí)也很嚴(yán)重，brpc之前用戶排查問題都要拉RPC同學(xué)一起排查，RPC框架對(duì)用戶是個(gè)黑盒，用戶根本不知道里面發(fā)生了什么。按我們的經(jīng)驗(yàn)，基本每天都有幾個(gè)用戶在群里問server卡頓，client超時(shí)之類的問題，排查問題是常態(tài)，人手必然不夠。時(shí)間長(zhǎng)了用戶就覺得你這個(gè)框架各種問題，人還拽的不行很少回他們消息。brpc的解決辦法是給server內(nèi)加入各種HTTP接口的內(nèi)置服務(wù)，通過這些服務(wù)，用戶可以很快看到server的延時(shí)、錯(cuò)誤、連接、跟蹤某個(gè)RPC、CPU熱點(diǎn)、內(nèi)存分配、鎖競(jìng)爭(zhēng)等信息，用戶還可以使用bvar來自定義各類統(tǒng)計(jì)信息，并在百度的運(yùn)維平臺(tái)NOAH上匯總。這樣大部分問題用戶可以自助解決。其實(shí)我們?nèi)タ匆彩强催@些，只是會(huì)更加專業(yè)。內(nèi)置服務(wù)的具體說明可以看這里。

Q：作為公司內(nèi)部的RPC框架，在服務(wù)治理方面有什么考慮？

戈君：百度內(nèi)部RPC使用非常廣泛，基本都是RPC調(diào)用，一些產(chǎn)品線還會(huì)通過local RPC隔離工程框架和策略代碼。這么多年下來，服務(wù)周邊的系統(tǒng)也比較全面了：編譯是BCLOUD，發(fā)布是Agile，服務(wù)注冊(cè)和發(fā)現(xiàn)是BNS，認(rèn)證是Giano，監(jiān)控和運(yùn)維是NOAH。在百度內(nèi)部，brpc和這些系統(tǒng)做了比較緊密的綁定，用戶體驗(yàn)是一站式的。雖然在開源版本中，這些結(jié)合大都刪掉了，但用戶可以根據(jù)自己組織中的基礎(chǔ)設(shè)施來進(jìn)行定制：交互協(xié)議，名字服務(wù)，負(fù)載均衡算法都可以定制。對(duì)于其中一些特別通用的，我們希望用戶反饋到開源版本中來以方便所有人。

Q：之前百度還開源過sofa-pbrpc，brpc與它的區(qū)別是什么？

戈君：sofa-pbrpc也是百度開發(fā)的一個(gè)比較早期的RPC框架，屬于sofa編程框架的一部分，在搜索有應(yīng)用。brpc相比sofa-pbrpc有如下優(yōu)點(diǎn):

對(duì)協(xié)議的抽象更一般化，并統(tǒng)一了全百度的通信架構(gòu)。bprc能容納非常多的協(xié)議，基于Protobuf的，基于HTTP的，百度內(nèi)的nshead/mcpack，開源的Redis/Memcached，甚至RTMP/FLV/HLS直播協(xié)議，brpc能逐漸地嵌入現(xiàn)有系統(tǒng)，而不需要徹底重構(gòu)，但sofa-pbrpc則不具備擴(kuò)展協(xié)議的能力。類似的，sofa-pbrpc也無法定制負(fù)載均衡算法，brpc默認(rèn)提供round-robin、隨機(jī)、一致性哈希，Locality-aware（局部性感知）四種算法，用戶還能定制。
多線程質(zhì)量更好。多線程編程是非常困難的，看起來簡(jiǎn)單的RPC遍布多線程陷阱，比如處理超時(shí)的代碼可能在RPC還沒發(fā)出去時(shí)就運(yùn)行了；發(fā)送函數(shù)還沒結(jié)束，處理回復(fù)的回調(diào)就被運(yùn)行了；一個(gè)回復(fù)還在被處理另一個(gè)回復(fù)回來了，諸如此類。另外，一個(gè)異步RPC的回調(diào)里發(fā)起一個(gè)同步RPC會(huì)發(fā)生什么，帶著鎖做同步RPC會(huì)發(fā)生什么。這些問題我們都不能在sofa-pbrpc中找到滿意的答案。
完備的調(diào)試和運(yùn)維支持。解決這個(gè)問題的本質(zhì)還在可擴(kuò)展性，你如何讓用戶參與進(jìn)來定制他們感興趣的指標(biāo)，為此我們?cè)O(shè)計(jì)了bvar，讓用戶能用比原子變量代價(jià)還小的方式自由地定制各種指標(biāo)，用戶能在瀏覽器上看到指標(biāo)的變化曲線，或在運(yùn)維平臺(tái)NOAH看到匯總的監(jiān)控?cái)?shù)據(jù)。brpc還加入了大量?jī)?nèi)置服務(wù)方便用戶調(diào)試程序，查看連接，在線修改gflags，追蹤RPC，分析CPU熱點(diǎn)，內(nèi)存分配，鎖競(jìng)爭(zhēng)等一應(yīng)俱全。

無需諱言，brpc在誕生之初和sofa-pbrpc在百度內(nèi)部是有競(jìng)爭(zhēng)關(guān)系的，但就像其他地方一樣，這種競(jìng)爭(zhēng)帶來了活力。類似的，brpc和其他已經(jīng)開源的RPC框架也是良性的競(jìng)爭(zhēng)關(guān)系，在比拼誰能真正提高用戶效率的過程中共同進(jìn)步。每個(gè)用戶都可以去對(duì)比代碼、文檔質(zhì)量，接口設(shè)計(jì)，易用程度，擴(kuò)展能力等，投出自己的一票。

Q：談?wù)刡rpc的整體架構(gòu)？

戈君：技術(shù)棧無外乎是從傳輸層壘到應(yīng)用層，就略過不講了，具體可以去看下開源出來的文檔。brpc在架構(gòu)上強(qiáng)調(diào)“在不犧牲易用性的前提下增強(qiáng)可擴(kuò)展性”，比如brpc支持非常多的協(xié)議，在百度內(nèi)部一個(gè)brpc server同端口可以支持二十幾種協(xié)議，這對(duì)于服務(wù)的平滑遷移就非常好用。

Client端的協(xié)議也非常多，用戶用brpc和bthread用得很爽，所以希望我們最好能統(tǒng)一所有的客戶端，像對(duì)Redis和Memcached的客戶端支持也是在這個(gè)背景下做的，這兩個(gè)客戶端比官方Client好用多了，感興趣的讀者可以去嘗試一下。但這么多協(xié)議的配置非常簡(jiǎn)單，填個(gè)字符串就行了，比如HTTP就是把ChannelOptions.protocol設(shè)為“http”，Redis就是“redis”。Server端甚至不用設(shè)，它會(huì)自動(dòng)判斷每個(gè)client的協(xié)議，怎么做到的開源文檔里也有。

名字服務(wù)、負(fù)載均衡也都可以定制。但為了對(duì)用戶負(fù)責(zé)，我們也不鼓勵(lì)“太自由”的定制，比如一點(diǎn)點(diǎn)需求的變化就要搞個(gè)新的，這時(shí)更需要想清楚本質(zhì)區(qū)別是什么。這個(gè)事情我們?cè)诎俣葍?nèi)的支持群里每天都在做，我們是開放的”乙方”，但我們也是嚴(yán)厲的”乙方”。

Q：brpc的性能如何？這么高的性能是怎么做到的？

戈君：性能是我們非常看中的一點(diǎn)，它和用戶體驗(yàn)也是緊密聯(lián)系的。好用但性能不行，或不好用但性能很牛，用戶會(huì)很難受，我們不希望用戶糾結(jié)。從另一個(gè)角度來看，在推廣初期，我們要說服產(chǎn)品線用brpc靠什么？最直觀的就是性能提升。而且這兒的性能不能停留在benchmark的圖片上，而是能在真實(shí)應(yīng)用中體現(xiàn)出來。開放出來的案例文檔中或多或少都包含了性能提升，具體如下：

百度地圖API入口
聯(lián)盟DSP
ELF學(xué)習(xí)框架
云平臺(tái)代理服務(wù)

Q：為什么要將brpc開源？接下來在開源項(xiàng)目的迭代方面有什么計(jì)劃嗎？

戈君：因?yàn)轳R上還有不少依賴RPC的百度系統(tǒng)要開源啊。RPC作為最基礎(chǔ)的組件，開源不僅僅是為了自身，也是為其它開源項(xiàng)目鋪路，比如說我們馬上還會(huì)開源基于brpc的RAFT庫，搭建高可用分布式系統(tǒng)非常方便；以及使用brpc的bigflow，讓流式計(jì)算變得很順手。這些年百度對(duì)開源的認(rèn)識(shí)也在不斷加深，開源看似曝光了百度的核心技術(shù)，但帶來的生態(tài)影響力更重要。從Apollo、PaddlePaddle開始，百度真的開始擁抱開源了。brpc的開源版和內(nèi)部版很接近，只是去掉了對(duì)百度內(nèi)部獨(dú)有的一些基礎(chǔ)設(shè)施的支持，我們?cè)趦?nèi)網(wǎng)寫的深入分析RPC技術(shù)細(xì)節(jié)的文檔也都一并開源了，后續(xù)也會(huì)及時(shí)推送改動(dòng)，請(qǐng)大家放心。這是一個(gè)活項(xiàng)目，不會(huì)拉個(gè)開源分支就不管了。

標(biāo)簽：

本站文章除注明轉(zhuǎn)載外，均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載，但請(qǐng)務(wù)必注明出處、不得修改原文相關(guān)鏈接，如果存在內(nèi)容上的異議請(qǐng)郵件反饋至chenjj@fc6vip.cn

上一篇：數(shù)據(jù)分析其實(shí)就是這么簡(jiǎn)單下一篇：都說自己是搞云計(jì)算的，一起來看云計(jì)算必須的6大成本