gRPC 应用指引

一、核心概念、架构及生命周期

1、服务定义

gRPC 默认使用 protocol buffers。

gRPC 可以定义四种类型服务：

Unary RPCs：一次请求，一次回复。

服务端流式请求：客户端发送一次请求，服务端流式返回一系列数据。

客户端流式请求：客户端流式写入一系列请求，然后发送到服务端。客户端写完请求后，等待服务端接受并返回结果。

双向流式请求：客户端和服务端双向发送数据流，各自独立。可以随读随写，或者一次性读完再写。

2、API 使用

首先在 .proto 文件中定义一个服务，然后使用 gRPC 提供的 pb 编译插件来生成客户端和服务端代码。

服务端：实现定义的服务，响应客户端请求。gRPC 框架解码请求，执行服务方法，编码返回结果。

客户端：本地 stub 包含实现的服务方法，客户端可以直接调用 stub 的相应方法，以 pb 消息类型包装请求参数发送到服务器，同时返回服务器返回的结果。

3、同步和异步

同步 RPC 请求（发送请求，阻塞直到服务端返回结果）和我们通常所说的 RPC 定义最为接近。但是，在实际应用中，非阻塞异步请求更适合。

4、RPC 生命周期

a）Unary RPC

客户端发送一次请求，获取一次返回。

客户端请求本地 stub 方法，服务端获取到通知，并伴随着客户端的请求数据，包括客户端 metadata、方法名及 deadline。服务端可以直接返回自身的 metadata（必须在业务结果返回前返回）或者等待客户端的请求消息（自定义）。

服务端收到客户端请求消息，然后执行相应的方法，组装相应的数据结果，伴随着请求状态信息（状态码及可能状态消息）返回给客户端。

如果状态为 OK，则客户端可以获取到结果进行处理，完成整个调用过程。

b）服务端流式 RPC

服务端返回的是一个数据流。在服务端发送完业务数据后，会继续返回状态信息。

c）客户端流式 RPC

客户端发送的是一个请求数据流。

d）双向流式 RPC

客户端和服务端双向发送数据流，各自独立。可以随读随写，或者一次性读完再写。

5、Deadlines/Timeouts

gRPC 允许客户端声明超时（请求 DEADLINE_EXCEEDED 异常之前等待的时间）。服务端可以通过此来判定请求是否超时及剩余处理时间。

6、RPC 终止

gRPC 中客户端和服务端都可以独立终止请求。比如服务端已经成功响应请求，但是客户端超时终止；服务端在接收完客户端请求数据前限频校验终止请求流程。

7、RPC 请求取消

客户端和服务端都可以在任何时候取消 RPC 流程。

8、Metadata

RPC 请求元数据，kv 列表形式，key 为 string 类型，value 通常为string，也可以为二进制。

key 大小写敏感，不能以 grpc- 做前缀（保留），二进制 value 的 key 以 -bin 结尾。

gRPC 不会使用用户自定义的元数据。

元数据使用，不同开发语言可能不同。

9、Channels

gRPC channel 是客户端到服务端的链接。用以创建客户端 stub。

channel 提供相应的参数配置控制 gRPC 请求行为，例如交互数据压缩等。

channel 的状态包括已建立链接及空闲。

二、最佳实践

rpc 请求初始化包括：客户端负载均衡，传输层 HTTP/2 请求创建及请求服务端相应的业务接口。

1、尽量重用 stubs 和 channels。

2、提供心跳机制以确保 HTTP/2 连接即使在系统业务不活跃时段仍能保持活跃，避免因 RPC 请求初始化导致的响应延迟。

3、对于可能存续长时间的数据流请求交互，适宜使用流式处理，避免频繁的 RPC 初始化。但是流式处理也存在无法动态均衡负载的及debug 困难的问题。虽然可以在小规模请求上提升性能，但是会因为负载均衡因素及复杂性降低整体扩展性。（python 除外）

4、每一个 gRPC channel 可以使用 0 个或多个 HTTP/2 链接，每个链接可以承载一定数量的的并发数据流。当链接上活跃的 RPC 请求达到上限，新进的请求会进入调用端等待队列。因此，对于高负载或持久的流式请求会因此产生性能问题。对于此，可以使用如下两种方式处理：

对于此类业务请求使用额外的 chennel。

使用 gRPC 连接池来均衡处理请求（需要特定的处理来避免重复使用同一个 channel）

5、对于 Java 语言

使用非阻塞 stubs 来并行处理 RPC 请求。

提供自定义连接池，根据实际的业务负载来配置相关参数。