分布式服务框架gRPC

什么是gRPC

gRPC是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于Protobuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。在gRPC中一个客户端能够像使用本地对象那样直接调用位于不一样机器上的服务端应用的方法(methods)。这让你可以更容易的构建分布式的应用和服务。和其余RPC系统相似，gRPC也是基于定义一个服务，指定服务能够被远程调用的方法以及他们的参数和返回类型。在服务端，实现服务的接口而后运行一个gRPC服务来处理可出端的请求。在客户端，客户端拥有一个存根（stub在某些语言中仅称为客户端），提供与服务器相同的方法。

·gRPC客户端和服务器能够在各类环境中运行并相互通讯，而且可使用gRPC支持的任何语言编写。所以，例如，您可使用Go，Python或Ruby的客户端轻松地用Java建立gRPC服务器。此外，最新的Google API的接口将拥有gRPC版本，可以让您轻松地在应用程序中内置Google功能。

使用protocol buffer

默认状况下，gRPC使用protocol buffer，用于序列化结构化数据（尽管它能够与其余数据格式（例如JSON）一块儿使用）。使用协议缓冲区的第一步是在proto文件中为要序列化的数据定义结构：proto文件扩展名为.proto的普通文本文件。protocol buffer数据被构造为消息，其中每一个消息都是信息的逻辑记录，其中包含一系列称为字段的名称/值对。这是一个简单的示例：

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

定义了数据结构后，就可使用protocol buffer编译器protoc生成你所选语言的数据访问类。访问类为每一个字段提供了简单的访问器（例如name())和set_name()），以及将整个结构序列化为原始字节或从原始字节中解析出整个结构的方法-例如，若是您选择的语言是C ++，则在上面的示例将生成一个名为Person的类。而后，您能够在应用程序中使用此类来填充，序列化和检索Person的protocol buffer消息。

除此以外你还要在.proto件中定义gRPC服务，并将RPC方法参数和返回类型指定为protocol buffer消息：

// 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;
}

gRPC使用也是使用编译器protoc从proto文件生成代码，不过编译器要首先安装一个gRPC插件。使用gRPC插件，你能够得到生成的gRPC客户端和服务器代码，以及用于填充，序列化和检索消息类型的常规protocol buffer访问类代码。

下面会更详细地介绍gRPC里的一些关键的概念。

服务定义

与许多RPC系统同样，gRPC围绕定义服务的思想，指定可经过其参数和返回类型远程调用的方法。默认状况下，gRPC使用protocol buffer做为接口定义语言（IDL）来描述服务接口和有效负载消息的结构。若是须要，可使用其余替代方法。

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse);
}

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}

gRPC容许定义四种服务方法：

• 一元RPC，客户端向服务器发送单个请求并得到单个响应，就像普通函数调用同样。

rpc SayHello(HelloRequest) returns (HelloResponse){
}

• 服务器流式RPC，客户端向服务器发送请求，并获取流以读取回一系列消息。客户端从返回的流中读取，直到没有更多消息为止。 gRPC保证单个RPC调用中的消息顺序。

rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){
}

• 客户端流式RPC，客户端使用提供的流写入消息序列而后将它们发送到服务器。客户端写完消息后，它将等待服务器读取消息并返回响应。 gRPC保证了在单个RPC调用中的消息顺序。

rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {
}

• 双向流式RPC，双方都使用读写流发送一系列消息。这两个流是独立运行的，所以客户端和服务器能够按照本身喜欢的顺序进行读写：例如，服务器能够在写响应以前等待接收完全部客户端消息，或者能够先读取一条消息再写入一条消息，或其余一些读写组合。每一个流中的消息顺序都会保留。

rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){
}

在下面的RPC生命周期章节咱们会更详细的比较这几种不一样的RPC。

使用API界面

从.proto文件中的服务定义开始，gRPC提供了protocol buffer编译器插件，插件可生成客户端和服务器端代码。 gRPC用户一般在客户端调用这些API，并在服务器端实现相应的API。

• 在服务侧，服务器实现服务中声明的方法并运行一个gRPC服务器来处理客户端的调用。gRPC的基础设施解码传入的请求，执行服务的方法，编码服务的响应。
• 在客户端，客户端拥有一个名为stub(存根)的本地对象（在有些语言中更倾向于把stub叫作客户端）该对象一样实现了服务中方法。客户端能够只在本地对象上调用这些方法，将调用参数包装在适当的protocol buffer消息类型中，gRPC会负责将请求发送给服务器而且返回服务端的protocol buffer响应。

同步vs异步

同步RPC调用会阻塞当前线程直到服务器收到响应为止，这是最接近RPC所追求的过程调用抽象的近似方法。另外一方面，网络本质上是异步的，而且在许多状况下可以启动RPC而不阻塞当前线程颇有用。

大多数语言中的gRPC编程界面都有同步和异步两种形式。能够在每种语言的教程和参考文档中找到更多信息。

RPC生命周期

如今让咱们具体看一下当一个gRPC客户端调用了一个gRPC服务器的方法后都发生了什么。咱们不会查看具体实现细节，留到后面的编程语言教程中再看实现细节。

一元RPC

首先来看一个最简单的RPC类型，客户端发送一个请求而后接受一个响应。

• 一旦客户端调用了存根/客户端对象上的方法，服务器会被通知RPC已经被调用了，一样会接收到调用时客户端的元数据、调用的方法名称以及制定的截止时间(若是适用的话)。
• 而后，服务器能够当即发送本身的初始元数据（必须在发送任何响应以前发送），也能够等待客户端的请求消息-哪一个先发生应用程序指定的。
• 服务器收到客户的请求消息后，它将完成建立和填充其响应所需的必要工做。而后将响应（若是成功）连同状态详细信息（状态代码和可选状态消息）以及可选尾随元数据一块儿返回。
• 若是状态是OK，客户端将得到响应，从而在客户端完成并终结整个调用过程。

服务器流式RPC

一个服务器流式RPC与简单的一元RPC相似，不一样的是服务器在接收到客户端的请求消息后会发回一个响应流。在发送回全部的响应后，服务器的状态详情（状态码和可选的状态信息）和可选的尾随元数据会被发回以完成服务端的工做。客户端在接收到全部的服务器响应后即完成操做。

客户端流式RPC

客户端流式RPC也相似于一元PRC，不一样之处在于客户端向服务器发送请求流而不是单个请求。服务器一般在收到客户端的全部请求后（但不必定）发送单个响应，以及其状态详细信息和可选的尾随元数据。

双向流式RPC

在双向流式RPC中，调用再次由客户端调用方法发起，服务器接收客户端元数据，方法名称和期限。一样，服务器能够选择发回其初始元数据，或等待客户端开始发送请求。

接下来发生的状况取决于应用程序，由于客户端和服务器能够按任何顺序进行读取和写入-流操做彻底是独立地运行。所以，例如，服务器能够等到收到全部客户端的消息后再写响应，或者服务器和客户端能够玩“乒乓”：服务器收到请求，而后发回响应，而后客户端发送基于响应的另外一个请求，依此类推。

截止时间/超时时间

gRPC容许客户端指定在RPC被DEADLINE_EXCEEDED错误终结前愿意等待多长时间来让RPC完成工做。在服务器端，服务器能够查看一个特定的RPC是否超时或者还有多长时间剩余来完成RPC。

如何指按期限或超时的方式因语言而异-例如，并不是全部语言都有默认期限，某些语言API按照期限（固定的时间点）工做，而某些语言API根据超时来工做（持续时间）。

RPC终止

在gRPC中，客户端和服务端对调用是否成功作出独立的基于本地的决定，并且两端的结论有可能不匹配。这意味着，好比说，你可能会有一个在服务端成功完成（“我已经发送完全部响应了”）可是在客户端失败（“响应是在我指定的deadline以后到达的”）的RPC。服务器也有可能在客户端发送全部请求以前决定RPC完成了。

取消RPC

客户端或服务器均可以随时取消RPC。取消操做将当即终止RPC，所以再也不进行任何工做。这不是“撤消”：取消以前所作的更改不会回滚。

元数据

元数据是以键值对列表形式提供的关于特定RPC调用的信息（好比说身份验证详情），其中键是字符串，值一般来讲是字符串（可是也能够是二进制数据）。元数据对gRPC自己是不透明的-它容许客户端向服务器提供与调用相关的信息，反之亦然。

对元数据的访问取决于语言。

通道

一个gRPC通道提供了一个到指定主机和端口号的gRPC服务器的链接，它在建立客户端存根（或者对某些语言来讲就是“客户端”）时被使用。客户端能够指定通道参数来更改gRPC的默认行为，好比说打开/关闭消息压缩。每一个通道都有状态，状态包括connected和idle(闲置)

gRPC怎么处理关掉的通道是语言相关的，有些语言还容许查询通道的状态。