健康检查（Health Checking）
解释了 gRPC 服务器如何暴露健康检查服务，以及客户端如何配置以自动检查它连接的服务器的健康状况。
概述
gRPC 指定了一个标准的服务 API（ health/v1）用于对 gRPC 服务器进行健康检查调用。提供了该服务的实现，但您需要负责更新您的服务的健康状态。
在客户端，您可以配置客户端自动与后端的健康检查服务进行通信。这样，客户端可以避免连接到被认为不健康的服务。
服务器端健康检查服务
gRPC 服务器上的健康检查服务支持两种操作模式：
-
对 Check RPC 端点的单次调用（Unary calls）
-
适用于集中式监控或负载均衡解决方案，但不适合支持大量 gRPC 客户端不断进行健康检查。
-
-
通过 Watch RPC 端点的流式健康更新（Streaming health updates）
-
被 gRPC 客户端的健康检查功能使用。
-
启用健康检查服务涉及以下步骤：
-
使用提供的健康检查库创建一个健康检查服务。
-
将健康检查服务添加到您的服务器。
-
当您的服务健康状况发生变化时，通知健康检查库：
-
如果您的服务当前无法接受请求，报告
NOT_SERVING。 -
如果您的服务可以接受请求，报告
SERVING。 -
如果您不关心单个服务的健康状态，可以使用空字符串（
""）来表示整个服务器的健康状况。 -
确保在服务器关闭时通知健康检查库，以便它可以通知所有已连接的客户端。
-
具体实现细节因语言而异，详见下面的 语言支持 部分。
启用客户端健康检查
gRPC 客户端可以通过修改通道的 服务配置 来执行健康检查，监控其连接的服务器的健康状态。例如，要监控 foo 服务的健康状况，可以使用如下 JSON 格式的配置：
{
"healthCheckConfig": {
"serviceName": "foo"
}
}|
如果您的服务器报告空字符串（ |
启用健康检查后，客户端的行为会有所变化：
-
客户端在建立连接时还会调用健康检查服务的 Watch RPC。
-
如果调用失败，客户端将进行重试（采用指数退避），除非调用失败并返回
UNIMPLEMENTED状态，此时健康检查将被禁用。
-
-
在健康检查服务返回健康状态之前，客户端不会发送请求。
-
如果一个健康的服务变为不健康，客户端将不再向该服务发送请求。
-
如果服务稍后恢复健康，请求将会恢复。
-
一些负载均衡策略如果与健康检查功能不兼容（例如
pick_first策略），可能会禁用健康检查。
更具体地说，表示服务器物理连接的子通道的状态会根据服务的健康状况经历以下变化：
启用客户端健康检查的具体方法因语言而异，详见语言支持部分的示例。