问题描述
我已阅读以下文档，源代码和问题：
- 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);
我不清楚以下几点：
根据运行状况检查协议：
服务器应手动注册所有服务并设置各自的状态
-
为什么我们需要手动注册？如果可以生成服务代码，为什么grpc不能帮助我们在
statusMap中自动注册服务名称？ （想象一下，一站式设置100个服务的状态） -
服务状态为硬代码，无法在应用程序运行时更改。如果由于某种原因（例如配置错误）在运行时我的服务不可用，则下游服务不可用，但是该服务的状态始终为服务状态（因为它是硬代码），如果是，则运行状况检查的含义是什么？>
对于RESTful API，我们可以提供/health-check或/ping API，以检查整个服务器是否正常运行。
解决方法
关于服务名称，第一个链接的文档说：
建议的服务名称格式为
package_names.ServiceName，例如grpc.health.v1.Health。
这确实与Protobuf定义中定义的软件包名称和服务名称相对应。
服务需要“手动”注册，因为状态是在应用程序级别确定的，grpc库不知道该状态，并且注册的服务名称仅与相应的状态一起有意义。另外，上面提到的命名格式只是一个约定；健康检查服务用户不受此限制，服务器上的实际服务也不受约束，无法使用标准的/package_names.ServiceName/MethodName方法命名方案。
关于第三点，服务状态不应硬编码，可以在运行时更改。问题代码中使用的HealthImplementation类具有一个setStatus方法，可用于更新状态。
此外，如问题代码中的注释中所述，
按照惯例，空字符串“”键代表整个服务器的状态。
它可以与/health-check或/ping REST API等效。