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两种。
文章评论