gRPC的学习和总结

gRPC的服务结构

gRPC可以运行在各种操作系统中，支持不同的编程语言。客户端和服务端通过protobuf的消息格式传递信息。protobuf有专门的数据格式：

protobuf消息标记格式

protobuf的消息格式如下图所示：

message Person {
    string name = 1;
    int32 id = 2;
    bool has_ponycpoter = 3;
}

我们也可以在protobuf中定义消息的方法, 其中的Greeter就是服务的一个方法。

// The greeter service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

Protocol buffer的消息版本

Protobuf的最新版本是proto3 ，在gRPC的官方网站上，推荐使用proto3最为标准的消息标记版本。这样才能够更好和更加完整地使用gRPC地功能。

gRPC的服务方法种类

前面已经提到过protobuf是gRPC默认地接口定义语言（IDL）用于定义消息接口和消息本省地格式。gRPC有四种不同地服务方法。他们分别是：Unary RPC，Server Streaming RPC, Client streaming RPC以及Bidirectional streaming RPC这四种。使用protobuf地定义如下：

• Unary RPC：一次发送一个请求消息，并接收一个返回消息。
• Server Streaming RPC: 发送一个请求消息，返回一个stream的消息序列。
• Client Streaming RPC：客户端发送stream的消息续列给到服务端，服务端接收后返回一个消息。
• Bidirectional streaming RPC：客户端和服务端发送和接收双向的数据

rpc HelloRPC(HelloRequest) return (HelloResponse); //Unary RPC
rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse); // Server Streaming RPC
rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);// Client Streaming RPC
rpc BidiHello(stream HelloRequest) returns (stream HelloResponse); // Bidirectional streaming RPC

同步和异步

RPC可以发起同步和异步的请求，同步请求，要求一个请求发出后，必须要等到服务器返回一个服务，才能够继续下一个请求。而异步请求则可以不等待服务器返回结果，就可以继续发起下一请求。

Deadlines/Timeouts

客户端可以设定一个特定的事件长度，作为超时时间。当客户端发送了一个请求，如果超过了一定的时间，则会报一个DEADLINE_EXCEEDED错误。

Cancelling RPC

通常，客户端和服务端都可以取消一个RPC请求。RPC请求终止后，将不会进行后续的操作。

Metadata

Metadata是指的某个RPC请求的附加信息，比如身份认证信息，这些信息以键值对的形式附加在RPC request请求中。这些数据本身对RPC消息是不透明的，而仅仅是关于客户端和服务端通信的数据。

Channels

gRPC的客户端和服务端通信连接需要首先建立一个通道，客户端可以定义通道参数以及通道的一些功能，例如消息压缩。消息通道本身是有状态的，其状态分为connected和idle两种。