grpc - 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 中的其他服务器之间共享端口。我不确定你在想什么设置，但上面的一般想法适用。