2

我已阅读以下文档、源代码和问题：

我提供一个例子并尝试解释：

// 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个服务的状态）

  2. 服务状态是硬代码，不能在应用程序运行时更改。如果我的服务在运行时由于配置错误等原因不可用，下游服务不可用，但服务的状态始终是服务（因为它是硬代码），如果是这样，健康检查是什么意思？

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

4

1 回答 1

1

关于服务名称，第一个链接文档是这样说的：

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

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

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

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

此外，正如问题代码中的评论所述，

按照约定，空字符串“”键表示整个服务器的状态。

这可以用作REST API/health-check或/pingREST API 的等价物。

于 2020-08-28T16:59:55.397 回答