brpc介紹、編譯與使用

? ? ? ? brpc又稱為baidu-rpc,是百度開發一款“遠過程調用”網絡框架。目前該項目已在github上開源——https://github.com/brpc/brpc。(轉載請指明出于breaksoftware的csdn博客)

? ? ? ? 據目前公開的資料,我們發現百度內部從2010年開始,開發過若干rpc框架:ub系列rpc(ubrpc,nova_pbrpc、public_pbrpc),hulu-pbrpc、sofa-pbrpc和本文介紹的baidu-rpc。從命名來看,我們并不太清楚ub、hulu和sofa是啥,但是可以確認的是我們知道baidu是什么意思。如果一款產品敢用公司名字來命名,可以見得該產品在公司內部的認可度——可以代表公司水平的產品。

? ? ? ? 然后從應用方面看,brpc目前被應用于百度公司內部各種核心業務上,據github上的overview.md資料,包括:高性能計算和模型訓練和各種索引和排序服務,且有超過100萬以上個實例是基于brpc工作的。

? ? ? ? 有大公司核心業務背書,我覺得這個項目還是可以玩玩的。

? ? ? ? 目前github上有原汁原味的技術文檔,似乎是直接把公司內部文件放了出來。但是我們在外網接觸不到他們的核心業務,更接觸不到什么UB、hulu或者sofa(似乎sofa-pbrpc也是開源的)等技術。所以部分文檔我們可以無視。這樣我們就可以將關注重心放在它的設計思想、性能、易用性以及和主流開源rpc的對比上。

RPC

? ? ? ? 當然在談這些前,需要知道什么是rpc。rpc全稱是Remote Procedure Call,即遠過程調用。我們先了解下“過程調用”這個概念。比如我們有如下代碼

void a() {    printf("a excuten");}void b() {    printf("b excuten");    a();}

? ? ? ? a、b函數我們可以認為它們各是一個“過程”。其中b函數調用了a函數,我們可以認為b過程調用了a過程,這個步驟我們可以稱為一次“過程調用”。這也是我們最普遍見到的“過程調用”形式。

? ? ? ? 從宏觀層面來看,a、b業務邏輯都在一臺機器的一個進程的一個線程中被執行的;從微觀層面,調用過程使用的全是本地資源——發生的變化僅限于本機的內存、CPU和顯示設備。于是這個過程我們可以稱為本地過程調用——Local Procedure Call。

? ? ? ? 然而隨著業務發展,a函數所要執行的業務越來越復雜,我們可能會讓其獨立成為一個進程而存在。這樣a、b函數將在同一臺機器不同進程中執行。此時b函數想調用a函數,就需要使用管道等技術進行跨進程通信。這種調用我們還是稱為本地過程調用。

? ? ? ? 再進一步,我們需要把a函數對應的邏輯作為一個獨立的服務。這樣承載a、b的服務可能部署于不同的機器上。此時b函數調用a函數的過程,需要跨越網絡,我們稱這種調用為“遠過程調用”。

? ? ? ? 那么b函數是如何“遠過程調用”a函數的呢?一般a函數對應的進程會開放一個網絡端口,它接受某種協議(比如HTTP)的請求,然后把結果打包成對應的協議格式返回。b函數所在的進程則發起該請求,然后接收返回結果。

? ? ? ? 但是這種設計無意增加了代碼開發者的工作量。因為本來就一個本地函數調用就能解決問題,現在卻需要:編寫a函數對應的服務、編寫b訪問網絡的邏輯。這其中摻雜了網絡、數據序列化等方面知識,開發難度直線上升。

? ? ? ? 大家開始想辦法,如果我們能降低上述開發難度,讓開發者不需要懂網絡編程、不需要懂協議解析,就像寫本地調用代碼一樣做開發就好了。于是rpc框架就被研發出來了,市面上的google出品的grpc、facebook出品的thrift以及本文介紹的百度出品的brpc就是這類產品。

易用性

? ? ? ? 以brpc為例,我們看一個遠過程調用是如何被調用的

#include <brpc/channel.h>#include "echo.pb.h"      ……    brpc::Channel channel;    brpc::ChannelOptions options;    // 設置超時、協議等信息    ……    example::EchoRequest request;    example::EchoResponse response;        // 設置參數    request.set_message("hello world");    // 設置調用樁    example::EchoService_Stub stub(&channel);      brpc::Controller cntl;      // 發起調用    stub.Echo(&cntl, &request, &response, NULL);    // 檢測并分析結果    ……

? ? ? ? 可以見得,這段代碼內容比較好的隱藏了網絡知識——本地調用也存在超時和協議的概念。我們就像調用本地過程一樣調用了Echo方法。

? ? ? ? 相應的遠過程調用的遠端——服務端代碼如下

#include <brpc/server.h>#include "echo.pb.h"……namespace example {class EchoServiceImpl : public EchoService {public:    EchoServiceImpl() {};    virtual ~EchoServiceImpl() {};    virtual void Echo(google::protobuf::RpcController* cntl_base,                      const EchoRequest* request,                      EchoResponse* response,                      google::protobuf::Closure* done) {        brpc::ClosureGuard done_guard(done);        brpc::Controller* cntl =            static_cast<brpc::Controller*>(cntl_base);        // Fill response.        response->set_message(request->message());    }};}  // namespace exampleint main(int argc, char* argv[]) {    // Parse gflags. We recommend you to use gflags as well.    GFLAGS_NS::ParseCommandLineFlags(&argc, &argv, true);    // Generally you only need one Server.    brpc::Server server;    // Instance of your service.    example::EchoServiceImpl echo_service_impl;    if (server.AddService(&echo_service_impl,                           brpc::SERVER_DOESNT_OWN_SERVICE) != 0) {        LOG(ERROR) << "Fail to add service";        return -1;    }    // Start the server.    brpc::ServerOptions options;    options.idle_timeout_sec = FLAGS_idle_timeout_s;    if (server.Start(FLAGS_port, &options) != 0) {        LOG(ERROR) << "Fail to start EchoServer";        return -1;    }    // Wait until Ctrl-C is pressed, then Stop() and Join() the server.    server.RunUntilAskedToQuit();    return 0;}

? ? ? ? 我們關注于EchoServiceImpl的實現。它主要暴露了Echo方法,我們只要填充它的業務就行了,而main函數中的套路是固定的。

? ? ? ? 可以見得使用rpc框架大大降低了我們開發的難度。

性能

? ? ? ? 在易用性相似的情況下,我們再對比一下brpc和grpc、thrift的差別。以下數據和圖片都來源于brpc在github上公布的調研結果

同機單client→單server在不同請求包大小下的QPS(越高越好)

? ? ? ? 上圖是一個Client端向一個Server端發送的數據隨著數據包大小變化而導致QPS變化的關系圖。我們看到:

• brpc隨著請求包大小變大,QPS會下降得很明顯。
• thrift隨著請求包大小變大,QPS下降不明顯。
• grpc隨著請求包大小變大,在小于8KB的場景下變化不明顯。但是8KB以上時,QPS明顯下降。
• 在數據包大小<512B時,brpc的QPS接近grpc的5倍,接近thrift的3倍多。
• 在數據包大小<8KB時,brpc的QPS還是比grpc和thrift高。
• 在數據包大小>8KB時,brpc的QPS比thrift低,但是比grpc高。

跨機多client→單server的QPS(越高越好)

? ? ? ? 上圖是多個Client向一個Server發請求時,Client端數量和Server的QPS數量之間的關系圖。我們可以看到:

• 隨著Client數量增加,grpc和thrif的QPS沒有明顯增加。這意味著請求增多,grpc和thrift就需要更多的Server端來消化。
• 隨著Client數量增多,brpc的QPS迅速增加。這意味著請求增多,brpc的Server端不需要像grpc或者thrift方案那樣增加太多。

同機單client→單server在不同線程數下的QPS(越高越好)

? ? ? ? 上圖反映出Server開啟的線程數和QPS之間的關系。隨著服務器性能越來越好,CPU核心數也越來越多,我們可以開啟更多的線程數來增加服務的處理能力,所以這個關系圖很有意義。

• grpc隨著線程數增加,QPS變化不明顯。這意味著給grpc開啟更多的線程數對QPS沒有明顯貢獻。
• thrift在線程數<=8時,QPS比grpc和brpc都高。但是在達到8個線程之后,QPS基本沒有變化,這就意味著thrift開啟超過8個線程就對QPS沒有明顯貢獻了。
• brpc隨著線程數增加,QPS變化明顯。雖然在8個線程及以下時,QPS不如thrift,但是之后隨著線程數增加,QPS增加也快速增加。這說明brpc對線程的利用率是非常高的。這也意味著讓brpc的服務部署在更多核心的機器上時,QPS會有更大的收益。

? ? ? ? ?brpc為什么會有此特性。這兒就需要介紹一下其使用的bthread庫。據公開的資料介紹,其特點是:

• 用戶可以延續同步的編程模式,能在數百納秒內建立bthread,可以用多種原語同步。
• bthread所有接口可在pthread中被調用并有合理的行為,使用bthread的代碼可以在pthread中正常執行。
• 能充分利用多核。
• better cache locality, supporting NUMA is a plus.

? ? ? ? 除了看QPS,我們還要看處理延時。如果一個服務雖然QPS很高,但是每個請求都延遲很久處理,就會導致服務的平均響應時間變大。

跨機多client→單server在固定QPS下的延時CDF(越左越好,越直越好)

? ? ? ??X軸是延時(微秒),Y軸是小于X軸延時的請求比例。這意味著變化曲線越靠近左邊(延時短),越直(請求比例變化小)越好。

• brpc的延時要優于thrift和grpc。
• thrift同樣優秀,但是grpc表現最差。

編譯

? ? ? ? 關于編譯brpc,可以參見https://github.com/brpc/brpc/blob/master/docs/cn/getting_started.md。但是一些環境問題,導致有些軟件不能安裝,就需要自己編譯了。

? ? ? ? 我把在Ubuntu Server 18版本上的編譯的過程貼出來,供大家參考。

sudo apt install makesudo apt install gccsudo apt install g++sudo apt install libleveldb-devsudo apt install libgflags-devsudo?apt?install opensslsudo apt install libssl-dev

? ? ? ? zlib是源碼編譯的

wget http://www.zlib.net/zlib-1.2.11.tar.gz .tar -xzvf zlib-1.2.11.tar.gzcd zlib-1.2.11./configure -prefix=/usrsudo makesudo make install

? ? ? ? protobuf是源碼編譯的

sudo apt-get install autoconf automake libtoolgit clone https://github.com/google/protobuf.gitcd protobuf./autogen.sh./configure --prefix=/usr -with-PACKAGE=yescd protobufsudo makesudo make install

? ? ? ? 最后還要修改下Makefile文件——增加"-std=c++11"

protoc-gen-mcpack: src/idl_options.pb.cc src/mcpack2pb/generator.o libbrpc.a        @echo "Linking $@"ifeq ($(SYSTEM),Linux)        @$(CXX) -o $@ $(HDRPATHS) -std=c++11 $(LIBPATHS) -Xlinker "-(" $^ -Wl,-Bstatic $(STATIC_LINKINGS) -Wl,-Bdynamic -Xlinker "-)" $(DYNAMIC_LINKINGS)else ifeq ($(SYSTEM),Darwin)        @$(CXX) -o $@ $(HDRPATHS) -std=c++11 $(LIBPATHS) $^ $(STATIC_LINKINGS) $(DYNAMIC_LINKINGS)endif

? ? ? ? 一切準備就緒,到brpc的目錄下執行

sh config_brpc.sh --headers=/usr/include --libs=/usr/libmake

? ? ? ? 最后切換到example/echo_c++目錄下,make出server和client,執行查看效果