健康检查

概述

gRPC 指定了一个标准服务 API (health/v1)，用于对 gRPC 服务器执行健康检查调用。虽然提供了此服务的实现，但您需要负责更新服务的健康状态。

在客户端，您可以让客户端自动与后端的健康检查服务进行通信。这使得客户端能够避开那些被认为不健康的服务。

服务端健康检查服务

gRPC 服务端的健康检查服务支持两种操作模式：

• 对 Check RPC 端点的单次调用 (Unary call)
  • 适用于集中式监控或负载均衡方案，但无法扩展以支持大量 gRPC 客户端持续进行健康检查的场景。
• 使用 Watch RPC 端点进行流式健康状态更新
  • 由 gRPC 客户端中的客户端侧健康检查功能使用。

在服务端启用健康检查服务涉及以下步骤：

1. 使用提供的健康检查库创建一个健康检查服务。
2. 将该健康检查服务添加到您的服务器中。
3. 当您的服务健康状态发生变化时，通知健康检查库。
   • NOT_SERVING：如果您的服务当前无法接受请求。
   • SERVING：如果您的服务可以正常提供业务。
   • 如果您不关心单个服务的健康状态，可以使用空字符串 ("") 来表示整个服务器的健康状态。
4. 请确保在服务器关闭时通知健康检查库，以便它能够告知所有已连接的客户端。

具体细节因编程语言而异，请参阅下方的语言支持部分。

启用客户端健康检查

可以通过修改通道的 服务配置 (service config)，将 gRPC 客户端配置为对所连接的服务器执行健康检查。例如，要监控 foo 服务的健康状态，您可以使用（JSON 格式）：

{
  "healthCheckConfig": {
    "serviceName": "foo"
  }
}

请注意，如果您的服务器报告了针对空字符串 ("") 服务的健康状态（表示整个服务器的健康状况），您也可以在此处使用空字符串。

启用健康检查会改变调用服务器时的一些行为：

• 建立连接后，客户端会额外调用健康检查服务上的 Watch RPC。
  • 如果调用失败，系统会进行重试（采用指数退避算法），除非调用失败的状态为 UNIMPLEMENTED（未实现），这种情况下健康检查功能将被禁用。
• 在健康检查服务针对目标服务发送健康状态之前，请求不会被发送。
• 如果一个健康的服务变得不健康，客户端将不再发送针对该服务的请求。
• 如果服务后续恢复健康，调用将自动恢复。
• 如果健康检查功能不符合某种负载均衡策略的需求，某些负载均衡策略可能会选择禁用它（例如 pick_first 策略就是如此）。

更具体地说，子通道（代表到服务器的物理连接）的状态会根据其所连接的服务健康状况，经历不同的状态转换。

stateDiagram-v2
    [*] --> IDLE
    IDLE --> CONNECTING : Connection requested
    CONNECTING --> READY : Health check#colon;\nSERVING
    CONNECTING --> TRANSIENT_FAILURE : Health check#colon;\nNOT_SERVING\nor call fails
    READY --> TRANSIENT_FAILURE : Health check#colon;\nNOT_SERVING
    READY --> IDLE : Connection breaks\nor times out
    TRANSIENT_FAILURE --> READY : Health check#colon;\nSERVING
    note right of TRANSIENT_FAILURE : Allows the load balancer to choose\nanother, working subchannel 

再次重申，如何启用客户端健康检查的具体细节因编程语言而异，请参阅语言支持部分中的示例。

语言支持