对健康检查协议的困惑

Question

我已经阅读了下面的文档、源代码和发行版：

• https://github.com/grpc/grpc/blob/master/doc/health-checking.md
• https://github.com/grpc/grpc-node/blob/master/packages/grpc-health-check/test/health_test.js
• https://github.com/grpc/grpc/issues/10428

我举了一个例子，并试图解释：

// Import package
let health = require('grpc-health-check');

// Define service status map. Key is the service name, value is the corresponding status.
// By convention, the empty string "" key represents that status of the entire server.
const statusMap = {
  "ServiceFoo": proto.grpc.health.v1.HealthCheckResponse.ServingStatus.SERVING,
  "ServiceBar": proto.grpc.health.v1.HealthCheckResponse.ServingStatus.NOT_SERVING,
  "": proto.grpc.health.v1.HealthCheckResponse.ServingStatus.NOT_SERVING,
};

// Construct the service implementation
let healthImpl = new health.Implementation(statusMap);

// Add the service and implementation to your pre-existing gRPC-node server
server.addService(health.service, healthImpl);

我不清楚以下几点：

1. ，statusMap中的服务名称是否需要与协议缓冲区文件中的服务名称相同？或者可以任意指定服务名称。如果是，服务名称如何映射到协议缓冲区中定义的服务？

根据健康检查协议：

服务器应该手动注册所有服务并设置单个状态

1. 为什么我们需要手动注册？如果可以生成服务代码，为什么grpc不帮助我们在statusMap中自动注册服务名称？(想象一下逐一设置100个服务的状态)

1. 服务状态是硬代码，不能在应用程序运行时更改。如果我的服务由于配置错误等原因在运行时不可用，则下游服务不可用，但服务的状态总是服务(因为它是硬代码)，如果是，那么健康检查的意义是什么？

？

对于RESTful API，我们可以提供一个/health-check或/ping API来检查整个服务器是否正常运行。

Answer 1

关于服务名称，第一个链接文档如下：

建议的服务名称格式为package_names.ServiceName，例如grpc.health.v1.Health。

这确实与Protobuf定义中定义的包名称和服务名称相对应。

服务需要“手动”注册，因为状态是在应用程序级别确定的，grpc库不知道这一点，注册的服务名称与相应的状态一起只有意义。此外，上面提到的命名格式只是一种约定；健康检查服务用户不受约束，服务器上的实际服务也不受使用标准/package_names.ServiceName/MethodName方法命名方案的限制。

关于第三点，服务状态不应该硬编码，可以在运行时更改。问题中的代码中使用的HealthImplementation类有一个setStatus方法，可以用来更新状态。

此外，正如问题中的代码中的注释所提到的，

按照约定，空字符串“

”键表示整个服务器的状态。

可以作为/health-check或/ping REST的等价物使用。