【gRPC】C++异步服务端客户端API实例及代码解析

对于同步API而言，程序的吞吐量并不高。因为在每次发送一个gRPC请求时，会阻塞整个线程，必须等待服务端的ack回到客户端才能继续运行或者发送下一个请求，因此异步API是提升程序吞吐量的必要手段。

gRPC异步操作依赖于完成队列CompletionQueue

官网教程：https://grpc.io/docs/languages/cpp/async/

参考博客1：https://www.luozhiyun.com/archives/671

参考博客2：https://blog.miigon.net/posts/cn-so-difference-between-sync-and-async-grpc/

整体思路概述：

• 将一个完成队列CompletionQueue绑定到RPC调用
• 在客户端与服务器两端执行写入或读取之类的操作，同时带有唯一的void*标签
• 调用CompletionQueue::Next以等待操作完成。如果出现标签，则表示相应的操作完成

异步客户端：

要点

• 就像同步客户端一样，我们需要创建一个存根stub用于进行gRPC方法的调用，但是此时我们需要调用的是异步方法，需要为其绑定一个完成队列

//客户端的类实例在初始化时就需要创建Channel和Stub了，具体看官方实例代码中的greeter_async_client.cc
CompletionQueue cq;//创建完成队列
std::unique_ptr<ClientAsyncResponseReader<HelloReply> > rpc(
    stub_->AsyncSayHello(&context, request, &cq));//将完成队列绑定到存根，进而创建出客户端异步响应读取器

• rpc->StartCall()初始化RPC请求
• rpc->Finish()有三个参数，分别是gRPC响应、最终状态、唯一标签。一旦RPC请求完成，响应的结果、最终状态会被封装到前两个传入的参数中，同时会附带唯一标签。唯一标签可以使用RPC请求的地址，这样一来，当最终的响应到来时，我们可以拿着该地址进行相应处理。
• 异步处理响应，拿着唯一标签可以获取对应RPC请求的地址，进而进行相关处理。
• 为了使得请求的发出与响应的处理相互之间不阻塞，需要把响应的处理独立出一个线程

代码示例

class GreeterClient {
 public:
  explicit GreeterClient(std::shared_ptr<Channel> channel)
      : stub_(Greeter::NewStub(channel)) {}

  // 客户端SayHello
  void SayHello(const std::string& user) {
    // RPC请求数据封装
    HelloRequest request;
    request.set_name(user);

    // 异步客户端请求，存储请求响应的状态和数据的结构体等，在下方进行的定义
    AsyncClientCall* call = new AsyncClientCall;

    // 初始化response_reader
    // stub_->PrepareAsyncSayHello()创建一个RPC对象，但是不会立即启动RPC调用
    call->response_reader =
        stub_->PrepareAsyncSayHello(&call->context, request, &cq_);

    // StartCall()方法发起真正的RPC请求
    call->response_reader->StartCall();

    // Finish()方法前两个参数用于指定响应数据的存储位置，第三个参数指定了该次RPC异步请求的地址
    call->response_reader->Finish(&call->reply, &call->status, (void*)call);
  }

  // 不断循环监听完成队列，对响应进行处理
  void AsyncCompleteRpc() {
    void* got_tag;
    bool ok = false;

    // 在队列为空时阻塞，队列中有响应结果时读取到got_tag和ok两个参数
    // 前者是结果对应的RPC请求的地址，后者是响应的状态
    while (cq_.Next(&got_tag, &ok)) {
      // 类型转换，获取到的实际上是此响应结果对应的RPC请求的地址，在这个地址下保存了实际的响应结果数据
      AsyncClientCall* call = static_cast<AsyncClientCall*>(got_tag);

      // 验证请求是否真的完成了
      GPR_ASSERT(ok);

      if (call->status.ok())
        std::cout << "Greeter received: " << call->reply.message() << std::endl;
      else
        std::cout << "RPC failed" << std::endl;

      // 完成了响应的处理后，清除该RPC请求
      delete call;
    }
  }

 private:
  // 异步客户端通话，存储一次RPC通话的信息，里面包含响应的状态和数据的结构
  struct AsyncClientCall {
    // 服务器返回的响应数据
    HelloReply reply;

    // 客户端的上下文信息，可以被用于向服务器传达额外信息或调整某些RPC行为
    ClientContext context;

    // RPC响应的状态
    Status status;

    // 客户端异步响应读取器
    std::unique_ptr<ClientAsyncResponseReader<HelloReply>> response_reader;
  };

  // 存根，在我们的视角里就是服务器端暴露的服务接口
  std::unique_ptr<Greeter::Stub> stub_;

  // 完成队列，一个用于gRPC异步处理的生产者消费者队列
  CompletionQueue cq_;
};

int main(int argc, char** argv) {
  // 实例化一个客户端，需要一个信道，第二个参数表明该通道未经过身份验证
  GreeterClient greeter(grpc::CreateChannel(
      "localhost:50051", grpc::InsecureChannelCredentials()));

  // 独立的异步响应处理线程
  // 由于该方法是客户端类内的非静态方法，所以需要传入客户端类的实例表明归属
  std::thread thread_ = std::thread(&GreeterClient::AsyncCompleteRpc, &greeter);

  //发送异步的请求SayHello()
  for (int i = 0; i < 100; i++) {
    std::string user("world " + std::to_string(i));
    greeter.SayHello(user);  // The actual RPC call!
  }

  std::cout << "Press control-c to quit" << std::endl << std::endl;
  thread_.join();  //永远会阻塞，因为异步响应处理线程永远不会停止，必须ctrl+c才能退出

  return 0;
}

异步服务器

要点

• 客户端在发起请求时附带了标签（此次RPC请求会话的地址），因此服务器端也需要将该标签妥善处理再返回
• 官方API中是准备一个CallData对象作为容器，gRPC通过ServerCompletionQueue将各种事件发送到CallData对象中，然后让这儿对象根据自身的状态进行处理。处理完成后还需要再手动创建一个CallData对象，这个对象是为下一个Client请求准备的，整个过程就像流水线一样
  • CREATE：CallData对象被创建处理之前处于CREATE状态
  • PROCESS：请求到达后，转换为PROCESS状态
  • FINISH：响应完成后，转换为FINISH状态
• 整体服务器端流程
  • 启动服务时，预分配 一个 CallData 实例供未来客户端请求使用。
  • 该 CallData 对象构造时，service_->RequestSayHello(&ctx_, &request_, &responder_, cq_, cq_, this) 将被调用，通知gRPC开始准备接收恰好是一个SayHello请求。
  • 这时候我们还不知道请求会由谁发出，何时到达，我们只是告诉 gRPC 说我们已经准备好接收了，让 gRPC 在真的接收到时通知我们。
  • 供给 RequestSayHello的参数告诉了gRPC将上下文信息、请求体以及回复器放在哪里、使用哪个完成队列来通知、以及通知的时候，用于鉴别请求的 tag（在这个例子中，this 被作为 tag 使用）。
    
    HandleRpcs() 运行到 cq->Next() 并阻塞。等待下一个事件发生
  • 客户端发送一个 SayHello 请求到服务器，gRPC 开始接收并解码该请求（IO 操作）
  • 一段时间后….
  • gRPC接收请求完成了。它将请求体放入CallData对象的request_成员中（通过我们之前提供的指针），然后创建一个事件（使用指向CallData 对象的指针作为 tag），并 将该事件放到完成队列 cq_ 中.
  • HandleRpcs() 中的循环接收到了该事件（之前阻塞住的 cq->Next() 调用此时也返回），并调用 CallData::Proceed() 来处理请求。
  • CallData 的 status_ 属性此时是 PROCESS，它做了如下事情：
    • 创建一个新的 CallData 对象，这样在这个请求后的新请求才能被新对象处理。
    • 生成当前请求的回复，告诉 gRPC 我们处理完成了，将该回复发送回客户端
    • gRPC 开始回复的传输 （IO 操作）
    • HandleRpcs() 中的循环迭代一次，再次阻塞在 cq->Next()，等待新事件的发生。
  • 一段时间后….
  • gRPC 完成了回复的传输，再次通过在完成队列里放入一个以 CallData 指针为 tag 的事件的方式通知我们。
  • cq->Next() 接收到该事件并返回，CallData::Proceed() 将 CallData 对象释放（使用 delete this;）。HandleRpcs() 循环并重新阻塞在 cq->Next() 上，等待新事件的发生。
    
    整个过程看似和同步 API 很相似，只是多了对完成队列的控制。然而，通过这种方式，每一个 一段时间后.... （通常是在等待 IO 操作的完成或等待一个请求出现） cq->Next() 不仅可以接收到当前处理的请求的完成事件，还可以接收到其他请求的事件。
    
    所以假设第一个请求正在等待它的回复数据传输完成时，一个新的请求到达了，cq->Next() 可以获得新请求产生的事件，并开始并行处理新请求，而不用等待第一个请求的传输完成

代码示例

//服务器实现类
class ServerImpl final {
 public:
  ~ServerImpl() {
    server_->Shutdown();
    // 关闭服务器后也要关闭完成队列
    cq_->Shutdown();
  }

  // There is no shutdown handling in this code.
  void Run() {
    // 服务器地址和端口
    std::string server_address("0.0.0.0:50051");
    // 服务器构建器
    ServerBuilder builder;
    // 服务器IP与端口指定，第二个参数表示该通道未经过身份验证
    builder.AddListeningPort(server_address, grpc::InsecureServerCredentials());
    // 注册服务
    builder.RegisterService(&service_);
    // 为当前服务器创建完成队列
    cq_ = builder.AddCompletionQueue();
    // 构建并启动服务器
    server_ = builder.BuildAndStart();
    std::cout << "Server listening on " << server_address << std::endl;

    // 运行服务器的主流程
    HandleRpcs();
  }

 private:
  // 处理一个请求所需要保存的状态、逻辑、数据被封装成了CallData类
  class CallData {
   public:
    // 传入service实例和服务器端的完成队列，创建后status_是CREATE状态
    CallData(Greeter::AsyncService* service, ServerCompletionQueue* cq)
        : service_(service), cq_(cq), responder_(&ctx_), status_(CREATE) {
      // 立即调用服务逻辑
      Proceed();
    }

    void Proceed() {
      if (status_ == CREATE) {
        // 转换为PROCESS状态
        status_ = PROCESS;

        // 作为初始化的一部分，请求系统开始处理SayHello请求。
        // 此处的this指代此CallData实例
        service_->RequestSayHello(&ctx_, &request_, &responder_, cq_, cq_,
                                  this);
      } else if (status_ == PROCESS) {
        // 在执行当前CallData的任务时，创建一个新的CallData实例去为新的请求服务
        // 当前CallData会在FINISH阶段自行销毁
        new CallData(service_, cq_);

        // 实际的逻辑处理
        std::string prefix("Hello ");
        reply_.set_message(prefix + request_.name());

        // 在完成后将状态置为FINISH。使用当前CallData的地址作为该事件的标签
        status_ = FINISH;
        responder_.Finish(reply_, Status::OK, this);
      } else {
        GPR_ASSERT(status_ == FINISH);
        // 销毁当前CallData
        delete this;
      }
    }

   private:
    // 异步服务
    Greeter::AsyncService* service_;
    //服务器端的完成队列，是一个生产者-消费者队列
    ServerCompletionQueue* cq_;
    // 服务器端上下文信息，可以被用于向客户端传达额外信息、数据或调整某些RPC行为
    ServerContext ctx_;

    // 客户端发来的请求
    HelloRequest request_;
    // 服务端的响应
    HelloReply reply_;

    // 发送服务端响应的工具
    ServerAsyncResponseWriter<HelloReply> responder_;

    // 状态机定义
    enum CallStatus { CREATE, PROCESS, FINISH };
    CallStatus status_;  // 当前的状态
  };

  // 如果有需求的话，服务器的处理可以是多线程的
  void HandleRpcs() {
    // 创建一个新的CallData，将完成队列中的数据封装进去
    new CallData(&service_, cq_.get());
    void* tag;  // 请求特有的标签，实际上是请求的RPC会话对象在客户端的地址信息
    bool ok;
    while (true) {
      // 阻塞等待读取完成队列中的事件，每个事件使用一个标签进行标识，该标签是CallData实例的地址
      // 完成队列的Next()方法应该每次都检查返回值，来确保事件和完成队列的状态正常
      GPR_ASSERT(cq_->Next(&tag, &ok));
      GPR_ASSERT(ok);
      // 从标签转换为CallData*类型，进而访问CallData中的方法
      static_cast<CallData*>(tag)->Proceed();
    }
  }

  // 当前服务器的完成队列
  std::unique_ptr<ServerCompletionQueue> cq_;
  // 当前服务器的异步服务
  Greeter::AsyncService service_;
  // 服务器实例
  std::unique_ptr<Server> server_;
};

int main(int argc, char** argv) {
  ServerImpl server;
  server.Run();
  return 0;
}