gRPC 健康检查是否应该仅限于 gRPC 服务？

Question

关于gRPC Health Checking，如果一个gRPC服务与其他同样需要健康检查的HTTP服务托管在同一个端口上，那么对grpc.health.v1.Health.Check的响应是否应该只针对提供的gRPC服务，或者是否也合理？也回答其他服务？如果是后者，应该使用什么模型的服务名称？

我问的部分原因是已经有一个 /healthz model for Kubernetes health checking 并且我想弄清楚我们是否需要为 gRPC 健康检查提供一个连字，或者可以对现有的健康检查进行卷积，例如，

import "google.api.http";
…
rpc Check(HealthCheckRequest) returns (HealthCheckResponse) {
  option (google.api.http) = { get: "/healthz" }
}

这样就可以使用现有的 gRPC 运行状况检查监视器。

Answer 1

gRPC 健康检查与 gRPC 服务器共享命运，因为它本身就是一个 gRPC 方法。如果 gRPC 服务器比你的其他服务寿命更长或与你的其他服务共享命运，那么我认为使用 gRPC 健康检查服务来服务其他服务的状态是可以的。

我不知道官方支持在 gRPC 服务器和 C++、Java 或 Go 中的其他服务器之间共享端口。我不确定你在想什么设置，但上面的一般想法适用。