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功能。
默认情况下,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 greetingsmessage 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 SayHello(HelloRequest) returns (HelloResponse){}
rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){}
rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {}
rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){}
在下面的RPC生命周期章节我们会更详细的比较这几种不同的RPC。
从 .proto
文件中的服务定义开始,gRPC提供了protocol buffer编译器插件,插件可生成客户端和服务器端代码。gRPC用户通常在客户端调用这些API,并在服务器端实现相应的API。
同步RPC调用会阻塞当前线程直到服务器收到响应为止,这是最接近RPC所追求的过程调用抽象的近似方法。另一方面,网络本质上是异步的,并且在许多情况下能够启动RPC而不阻塞当前线程很有用。
大多数语言中的gRPC编程界面都有同步和异步两种形式。可以在每种语言的教程和参考文档中找到更多信息。
现在让我们具体看一下当一个gRPC客户端调用了一个gRPC服务器的方法后都发生了什么。我们不会查看具体实现细节,留到后面的编程语言教程中再看实现细节。
首先来看一个最简单的RPC类型,客户端发送一个请求然后接受一个响应。
一个服务器流式RPC与简单的一元RPC类似,不同的是服务器在接收到客户端的请求消息后会发回一个响应流。在发送回所有的响应后,服务器的状态详情(状态码和可选的状态信息)和可选的尾随元数据会被发回以完成服务端的工作。客户端在接收到所有的服务器响应后即完成操作。
客户端流式RPC也类似于一元PRC,不同之处在于客户端向服务器发送请求流而不是单个请求。服务器通常在收到客户端的所有请求后(但不一定)发送单个响应,以及其状态详细信息和可选的尾随元数据。
在双向流式RPC中,调用再次由客户端调用方法发起,服务器接收客户端元数据,方法名称和期限。同样,服务器可以选择发回其初始元数据,或等待客户端开始发送请求。
接下来发生的情况取决于应用程序,因为客户端和服务器可以按任何顺序进行读取和写入-流操作完全是独立地运行。因此,例如,服务器可以等到收到所有客户端的消息后再写响应,或者服务器和客户端可以玩“乒乓”:服务器收到请求,然后发回响应,然后客户端发送基于响应的另一个请求,依此类推。
gRPC允许客户端指定在RPC被 DEADLINE_EXCEEDED
错误终结前愿意等待多长时间来让RPC完成工作。在服务器端,服务器可以查看一个特定的RPC是否超时或者还有多长时间剩余来完成RPC。
如何指定期限或超时的方式因语言而异-例如,并非所有语言都有默认期限,某些语言API按照期限(固定的时间点)工作,而某些语言API根据超时来工作(持续时间)。
在gRPC中,客户端和服务端对调用是否成功做出独立的基于本地的决定,而且两端的结论有可能不匹配。这意味着,比如说,你可能会有一个在服务端成功完成(“我已经发送完所有响应了”)但是在客户端失败(“响应是在我指定的deadline之后到达的”)的RPC。服务器也有可能在客户端发送所有请求之前决定RPC完成了。
客户端或服务器都可以随时取消RPC。取消操作将立即终止RPC,因此不再进行任何工作。这不是“撤消”:取消之前所做的更改不会回滚。
元数据是以键值对列表形式提供的关于特定RPC调用的信息(比如说身份验证详情),其中键是字符串,值通常来说是字符串(但是也可以是二进制数据)。元数据对gRPC本身是不透明的-它允许客户端向服务器提供与调用相关的信息,反之亦然。
对元数据的访问取决于语言。
一个gRPC通道提供了一个到指定主机和端口号的gRPC服务器的连接,它在创建客户端存根(或者对某些语言来说就是“客户端”)时被使用。客户端可以指定通道参数来更改gRPC的默认行为,比如说打开/关闭消息压缩。每个通道都有状态,状态包括 connected
和 idle
(闲置)
gRPC怎么处理关掉的通道是语言相关的,有些语言还允许查询通道的状态。