BRPC系列一、編譯及簡單示例的運行與分析

原創 likewind1993 2020-07-04 15:05

2020年03月22日00:13:34， 待完善…

前言

如果你要學BRPC，強烈建議查看官方文檔https://github.com/apache/incubator-brpc/blob/master/README_cn.md，裏面的內容很詳細。

寫BRPC系列博客的原因並不是要把源文檔抄一遍搬到博客上來，而是在看源文檔的過程中記錄一些重要的點，自己實際寫相關代碼時候遇到的問題，思考一些流程的必要性。對應部分我都會貼上源文檔的鏈接，便於查詢。

BRPC編譯問題

在按照官方頁面進行編譯時（Mac），出現“gnu-getopt must be installed and used“錯誤，

按照https://www.jianshu.com/p/c28e050955fb的解決方法，將getopt加入環境變量。

gnu-getopt must be installed and used
用brew install gnu-getopt安裝即可，並加入路徑
export PATH="/usr/local/opt/gnu-getopt/bin:$PATH"

EechoService示例

client端的流程

以https://github.com/apache/incubator-brpc/blob/master/example/echo_c++/client.cpp爲例，

流程

  1. 定義channel（負責連接）， 以及相關的ChannelOption（設置使用的協議、延時等）進行初始化。
  2. 實例化Server_Stub對象對channel進行封裝。
  3. 實例化Request和Response類型的對象，填入Request信息
  4. 實例化Controller對象，並設置相關的參數（controller負責管理此次連接的信息，比如狀態位顯示當前調用是否成功，比如此次連接延時等等）
  5. 使用stub.RPCMethod(&controller, & request, & response, done)即可完成RPC方法的調用。
  6. 調用成功，則response對象中已經返回RPCMethod的調用結果。

client代碼如下， 可以自行對應。

#include <gflags/gflags.h>
#include <butil/logging.h>
#include <butil/time.h>
#include <brpc/channel.h>
#include "echo.pb.h"

DEFINE_string(attachment, "", "Carry this along with requests");
DEFINE_string(protocol, "baidu_std", "Protocol type. Defined in src/brpc/options.proto");
DEFINE_string(connection_type, "", "Connection type. Available values: single, pooled, short");
DEFINE_string(server, "0.0.0.0:8000", "IP Address of server");
DEFINE_string(load_balancer, "", "The algorithm for load balancing");
DEFINE_int32(timeout_ms, 100, "RPC timeout in milliseconds");
DEFINE_int32(max_retry, 3, "Max retries(not including the first RPC)"); 
DEFINE_int32(interval_ms, 1000, "Milliseconds between consecutive requests");

int main(int argc, char* argv[]) {
    // Parse gflags. We recommend you to use gflags as well.
    GFLAGS_NS::ParseCommandLineFlags(&argc, &argv, true);
    
    // A Channel represents a communication line to a Server. Notice that 
    // Channel is thread-safe and can be shared by all threads in your program.
    brpc::Channel channel;
    
    // Initialize the channel, NULL means using default options.
    brpc::ChannelOptions options;
    options.protocol = FLAGS_protocol;
    options.connection_type = FLAGS_connection_type;
    options.timeout_ms = FLAGS_timeout_ms/*milliseconds*/;
    options.max_retry = FLAGS_max_retry;
    if (channel.Init(FLAGS_server.c_str(), FLAGS_load_balancer.c_str(), &options) != 0) {
        LOG(ERROR) << "Fail to initialize channel";
        return -1;
    }

    // Normally, you should not call a Channel directly, but instead construct
    // a stub Service wrapping it. stub can be shared by all threads as well.
    example::EchoService_Stub stub(&channel);

    // Send a request and wait for the response every 1 second.
    int log_id = 0;
    while (!brpc::IsAskedToQuit()) {
        // We will receive response synchronously, safe to put variables
        // on stack.
        example::EchoRequest request;
        example::EchoResponse response;
        brpc::Controller cntl;

        request.set_message("hello world");

        cntl.set_log_id(log_id ++);  // set by user
        // Set attachment which is wired to network directly instead of 
        // being serialized into protobuf messages.
        cntl.request_attachment().append(FLAGS_attachment);

        // Because `done'(last parameter) is NULL, this function waits until
        // the response comes back or error occurs(including timedout).
        stub.Echo(&cntl, &request, &response, NULL);
        if (!cntl.Failed()) {
            LOG(INFO) << "Received response from " << cntl.remote_side()
                << " to " << cntl.local_side()
                << ": " << response.message() << " (attached="
                << cntl.response_attachment() << ")"
                << " latency=" << cntl.latency_us() << "us";
        } else {
            LOG(WARNING) << cntl.ErrorText();
        }
        usleep(FLAGS_interval_ms * 1000L);
    }

    LOG(INFO) << "EchoClient is going to quit";
    return 0;
}

劃重點，上面的代碼中，核心是stub.RPCMethod(&controller, & request, & response, done），必須要懂裏面的參數。

其中的request和response很容易理解，就是調用service的Request信息（可能包含了需要處理的數據或者參數信息），以及service返回的Response信息（Service處理完的返回結果）。

比較難理解的是第一個參數controller，以及最後一個參數done。

Controller

// A Controller mediates a single method call. The primary purpose of
// the controller is to provide a way to manipulate settings per RPC-call 
// and to find out about RPC-level errors.

這是src/brpc/controller.h中Control類的註釋，大意是"一個Controller對象對應一次RPC方法調用，用於管理RPC調用的選項以及查找RPC層面的錯誤"。

我們可以看看Controller類裏有啥（感興趣的讀者可以看源文件，這裏只截取部分）：

.....
149     // ------------------------------------------------------------------
150     //                      Client-side methods
151     // These calls shall be made from the client side only.  Their results
152     // are undefined on the server side (may crash).
153     // ------------------------------------------------------------------
154 
155     // Set/get timeout in milliseconds for the RPC call. Use
156     // ChannelOptions.timeout_ms on unset.
157     void set_timeout_ms(int64_t timeout_ms);
158     int64_t timeout_ms() const { return _timeout_ms; }
159 
160     // Set/get the delay to send backup request in milliseconds. Use
161     // ChannelOptions.backup_request_ms on unset.
162     void set_backup_request_ms(int64_t timeout_ms);
163     int64_t backup_request_ms() const { return _backup_request_ms; }
164 
165     // Set/get maximum times of retrying. Use ChannelOptions.max_retry on unset.
166     // <=0 means no retry.
167     // Conditions of retrying:
168     //   * The connection is broken. No retry if the connection is still on.
169     //     Use backup_request if you want to issue another request after some
170     //     time.
171     //   * Not timed out.
172     //   * retried_count() < max_retry().
173     //   * Retry may work for the error. E.g. No retry when the request is
174     //     incorrect (EREQUEST), retrying is pointless.
175     void set_max_retry(int max_retry);
176     int max_retry() const { return _max_retry; }
......

如上，有設置time_out時間以及重試次數等等選項。我們可以這麼理解，controller對底層socket設置進行了進一步的封裝，這樣用戶在使用BRPC時，對一個RPC方法調用，只需要關心延時，調用是否成功等信息，而無需考慮相關的如何重傳等底層邏輯。

註釋中出現” Client-side methods“的字樣，相對的，當Client進行RPC方法調用將controller對象傳到server端後，server端也可以調用裏面的方法，比如主動關閉連接等。

...
395     // Tell RPC to close the connection instead of sending back response.
396     // If this controller was not SetFailed() before, ErrorCode() will be
397     // set to ECLOSE.
398     // NOTE: the underlying connection is not closed immediately.
399     void CloseConnection(const char* reason_fmt, ...);
400 
401     // True if CloseConnection() was called.
402     bool IsCloseConnection() const { return has_flag(FLAGS_CLOSE_CONNECTION); }
...

要注意的是（一些方法只能在Client端或Server端進行調用，比如set_timeout_ms只能在client端進行調用，如果在服務端再進行調用，會出現不可預測的錯誤）

另一個參數涉及到了BRPC調用方式（1. 同步 2. 異步 3. 半同步）

簡單來說，同步類似簡單的函數調用，發起調用RPC後，Client一直阻塞等待，收到Server端返回Response（即完成RPC調用後）後，繼續執行。

異步則是，發起RPC調用後，Client端繼續執行（此時RPC調用正在執行…），在RPC調用結束返回Rsponse後，此時調用Client端註冊的回調函數，進行進一步的處理（如對Response結果進行處理）

在上面EchoService的例子中，是同步方式的RPC調用，因此done只需設爲NULL即可。

若要進行異步方式的RPC調用，則需要藉助NewCallback生成done函數，註冊相應的回調函數。

更加詳細的代碼實例，可以參考這篇博客：https://blog.csdn.net/u012414189/article/details/84573786

Server端的流程

以https://github.com/apache/incubator-brpc/blob/master/example/echo_c%2B%2B/server.cpp爲例

Server流程

  1. 實例化Server對象
  2. 註冊自定義的服務（如EchoServiceImpl）
  3. 實例化ServerOptions對象，在裏面設置Server的選項（如time_out的時間）
  4. 啓動Server

相關代碼如下：

#include <gflags/gflags.h>
#include <butil/logging.h>
#include <brpc/server.h>
#include "echo.pb.h"

DEFINE_bool(echo_attachment, true, "Echo attachment as well");
DEFINE_int32(port, 8000, "TCP Port of this server");
DEFINE_int32(idle_timeout_s, -1, "Connection will be closed if there is no "
             "read/write operations during the last `idle_timeout_s'");
DEFINE_int32(logoff_ms, 2000, "Maximum duration of server's LOGOFF state "
             "(waiting for client to close connection before server stops)");

// Your implementation of example::EchoService
// Notice that implementing brpc::Describable grants the ability to put
// additional information in /status.
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) {
        // This object helps you to call done->Run() in RAII style. If you need
        // to process the request asynchronously, pass done_guard.release().
        brpc::ClosureGuard done_guard(done);

        brpc::Controller* cntl =
            static_cast<brpc::Controller*>(cntl_base);

        // The purpose of following logs is to help you to understand
        // how clients interact with servers more intuitively. You should 
        // remove these logs in performance-sensitive servers.
        LOG(INFO) << "Received request[log_id=" << cntl->log_id() 
                  << "] from " << cntl->remote_side() 
                  << " to " << cntl->local_side()
                  << ": " << request->message()
                  << " (attached=" << cntl->request_attachment() << ")";

        // Fill response.
        response->set_message(request->message());

        // You can compress the response by setting Controller, but be aware
        // that compression may be costly, evaluate before turning on.
        // cntl->set_response_compress_type(brpc::COMPRESS_TYPE_GZIP);

        if (FLAGS_echo_attachment) {
            // Set attachment which is wired to network directly instead of
            // being serialized into protobuf messages.
            cntl->response_attachment().append(cntl->request_attachment());
        }
    }
};
}  // namespace example

int 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;

    // Add the service into server. Notice the second parameter, because the
    // service is put on stack, we don't want server to delete it, otherwise
    // use brpc::SERVER_OWNS_SERVICE.
    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;
}

疑問（未解決）

BRPC支持各種協議，但各種協議有適用的場景麼？

包的定義（以baidu_std協議分析爲例）

鏈接： https://github.com/apache/incubator-brpc/blob/master/docs/cn/baidu_std.md

釋義 說明
包頭 4字節（Magic number ： BRPC） + 4字節（包體長度）+4字節（包體中元數據的長度）
包體（元數據） 用於描述請求/響應，可設置各種參數。可在元數據上進一步拓展
包體 （數據） 自定義的Protobuf Message。用於存放參數或返回結果。
包體 （附件） 某些場景下需要通過RPC來傳遞二進制數據，例如文件上傳下載，多媒體轉碼等等。將這些二進制數據打包在Protobuf內會增加不必要的內存拷貝。因此協議允許使用附件的方式直接傳送二進制數據。

附件總是放在包體的最後，緊跟數據部分。消息包需要攜帶附件時，應將RpcMeta中的attachment_size設爲附件的實際字節數。|

常用鏈接

（來自BRPC文檔）
總體介紹：https://github.com/brpc/brpc
Client：https://github.com/brpc/brpc/blob/master/docs/cn/client.md
Server：https://github.com/brpc/brpc/blob/master/docs/cn/server.md
內置服務：https://github.com/brpc/brpc/blob/master/docs/cn/builtin_service.md
protobuf：https://developers.google.com/protocol-buffers/

Ref：

  1. https://zhuanlan.zhihu.com/p/101008345
  2. https://blog.csdn.net/breaksoftware/article/details/81564405
  3. https://github.com/apache/incubator-brpc/blob/master/README_cn.md
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章