gRPC 基本概念

声明

本篇文章是在学习gRPC框架的过程中翻译的官方文档,非作者原创,官方文档参考gRPC,学习gRPC过程中,有些概念,思想理解翻译不到位还请多多指教。


本文通过回顾gRPC整体架构和RPC的生命周期来介绍gRPC中一些重要概念。
本文假定读者已经阅读过什么是gRPC。本文不具体讲解gRPC与具体语言相关的实现细节,这个部分内容读者可以参考。

概述

服务定义

和其他RPC系统一样,服务定义也是gRPC的基础,gRPC默认使用protocol buffers作为接口定义语言(IDL)来定义服务接口和负载信息的结构,gRPC支持使用其他方法进行服务定义。一个简单的HelloService服务定义如下:

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方法:客户端发起一个请求,从服务端得到一个消息流,客户端可以一直从流中读取数据直到读取完服务端返回的所有数据。
rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){
}
  • 客户端发送流RPC方法:客户端向请求中写入流并发送给服务端,客户端发送完全部数据,客户端会使用相同的流获取服务端的返回。
rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {
}
  • 双向流RPC方法:客户端和服务端都可以使用读-写流发送一系列消息。读、写流的操作互相独立,客户端和服务端都可以按照各自的顺序读写数据。服务端响应客户端的三种方式:1、读完所有请求,然后返回响应;2、边读边发送响应;3、1和2的任意组合。读写流中数据的顺序保持不变。
rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){
}

API 使用

API

使用.proto文件定义一个服务,gRPC提供protocol buffer编译插件来生成客户端和服务端代码,服务端实现API,客户端调用API。

  • 服务端:服务端需要实现.proto中定义的方法,并启动一个gRPC服务器用于处理客户端请求。gRPC反序列化到达的请求,执行服务方法,序列化服务端响应并发送给客户端。
  • 客户都:客户端本地有一个实现了服务端一样方法的对象,gRPC中称为桩,其他语言中更习惯称为客户端。客户调用本地桩的方法,将参数按照合适的协议封装并将请求发送给服务端,并接收服务端的响应。


    gRPC 基本概念_第1张图片
    请求-响应模型

同步vs异步

在服务器返回响应前,同步RPC调用将阻塞客户端当前线程,同步RPC调用与gRPC的抽象过程调用模型最接近。从另一方面来看,网络本质上是异步的,在许多情况下,能够在不阻塞当前线程的情况下进行RPC调用非常有用。大多数编程语言对应的gRPC接口都同时支持异步和同步RPC调用。

RPC 的生命周期

更进一步,进入gRPC内部,了解客户端调用API的过程中究竟发生了什么。

一元RPC

一元RPC是最简单的RPC模型,在一元RPC中客户端发送一个请求并从服务端得到一个响应。

  • 一旦客户端调用了桩/客户端对象的方法,服务端将会收到方法被调用的通知,并从中得到客户端调用方法的元信息,方法名和最后期限(尽可能获取)
  • 服务器可以选择直接响应服务器自己的初始元信息(必须在发送响应前发送)或者等待客户端请求到达,服务器选择哪种方式,由应用配置决定的。
  • 服务器收到客户端请求,服务端就会执行创建和填充响应所需的任何工作。然后将响应(如果成功)连同状态详细信息(状态代码和可选状态消息)和可选的跟踪数据一起返回给客户端。
  • 如果请求状态是OK,客户端可以收到来自服务端的响应,整个请求-响应过程在客户端侧完成。


    gRPC 基本概念_第2张图片
    一元RPC

服务端流RPC

服务端流RPC模型和简单的一元RPC模型类似,在服务端接收到客户端请求后,服务端返回一个响应流。当服务端发送完所有数据后,服务端状态详情(状态码和可选的状态新)和可选的跟踪元数据会返回给客户端,然后RPC请求-响应在服务端完成。一旦服务端发送完所有数据,客户端即完成。

客户端流RPC

该RPC模型下,客户端发送一个请求流而不是单一请求,服务端通常在接收完客户端请求后连同状态详细信息,跟踪元数据和响应一起返回给客户端,服务端可以选择返回状态信息和跟踪信息。

双向流RPC

在双向流RPC模型中,客户端RPC调用后,服务端接收到客户端元信息、方法名和最后期限。服务端可以选择马上发送自己的元信息给客户端,或者等待客户端请求的到达。
完成以上动作后,接下来的处理动作依赖应用程序,客户端和服务端可以以任意的顺序进行读写操作,流的操作完全互相独立。举个例子,服务端可能接收完所有客户端数据后再写响应到流中,或者客户端和服务端进行“ping-pong”操作,服务端接收到一个请求,然后返回一个响应,客户端根据响应的内容选择发送下一个请求,如此反复执行。

Deadlines/Timeouts

gRPC允许客户端设置等待RPC完成的时间(RPC因发生错误而结束前),在服务端,可以查询特定的RPC是否超时,剩余时间。然而不同编程语言之间对最后期限和超时时间的描述各异,有些编程语言通过时间点控制,有写编程语言通过时间段控制。.

RPC 终止

在gRPC框架中,客户端和服务端都可以独立的、单方面决定RPC 调用是否成功,客户端和服务端对同一个RPC调用的最终结果可能不一致。这意味这,比如,一个RPC调用在服务端是成功(服务端已经发送所有响应),但是RPC调用在客户端失败(响应到达时间超时)。服务端也有可能在客户端发送完所有数据前将当前RPC调用设置为完成。

取消 RPC

客户端和服务端可以在任何时间取消RPC调用,取消会立即终止RPC调用(不会执行其他动作),所以在RPC调用取消前,不会回滚任何操作。

元数据

元数据是特定RPC调用的信息(例如鉴权信息),元信息通常是键-值对的列表,键的类型为字符串,值的类型一般也为字符串,但是值可以是二进制数据。元数据对gRPC框架本身是不透明的——它允许客户端与服务器调与RPC调用相关的信息
获取元数据的方法依赖于语言。

通道

在创建客户端桩时,gRPC通过可以提供一个连接特点地址端口的服务端的连接,客户端可以通过参数来修改通道默认行为,比如是否开启信息压缩。通道是由状态的,比如已连接,空闲。gRPC如何处理通过的关闭是与语言相关的,有些语言支持查询通道的状态。

你可能感兴趣的:(gRPC 基本概念)