健康检查应该调用其他应用程序健康检查吗？

Question

我有两个API的A和B，我控制，两者都有准备和活性健康检查。A依赖于B。

A
/foo - This endpoint makes a call to /bar in B
/status/live
/status/ready

B
/bar
/status/live
/status/ready

由于依赖关系，A的准备状态健康检查是否应该调用API B的就绪健康检查？

Answer 1

如果服务A能够服务业务请求，它就已经准备好了。因此，如果能够到达B是它需要做的事情的一部分(看起来是这样)，那么它应该检查B。

有一个检查B的好处是你可以然后在一次糟糕的滚动升级中快速失败。假设你的A被错误配置，所以升级功能错误的连接细节为B-也许B的服务名称被注入一个环境变量和新版本有一个错误。如果您的A实例在启动时检查到Bs，那么您可以更容易地确保升级失败，并且没有流量流向新配置错误的Pods。有关此问题的更多信息，请参见https://medium.com/spire-labs/utilizing-kubernetes-liveness-and-readiness-probes-to-automatically-recover-from-failure-2fe0314f2b2e

通常情况下，A检查B的活性端点或任何最小可用性端点就足够了，而不是B的就绪端点。这是因为kubernetes将是帮你检查B的准备状态探测器，所以A可以到达的任何B实例都是现成的。如果B的就绪端点执行比活性端点更多的检查。，调用B的活性端点而不是准备状态会产生影响。请记住，kubernetes将定期调用这些探测器- 准备状态和活力--它们都有一个时期。。区别在于Pod是从服务流量(如果准备就绪失败)还是重新启动(如果活性失败)而退出。您不是在尝试执行端到端事务检查，而是希望这些检查包含最小的逻辑，并且不会消耗太多的负载。

如果A的就绪实现中的代码执行检查，而不是在k8s级别(在Pod规范本身中)执行检查，则更好。在k8s级别上这样做是第二好的，因为理想情况下，您希望知道容器中运行的代码确实连接。

另一种检查依赖服务的方法是可用的是在initContainer中签入的。使用initContainers可以避免在启动过程中看到多次重新启动(通过确保正确的顺序)，但是通过探测对依赖项进行检查可能会变得更深(如果在应用程序的代码中实现)，并且探测将在启动后继续定期运行。因此，两者兼用是有利的。

小心检查其他服务的准备度过大，因为它可能导致级联不可用。例如，如果后端短暂下降，而前端正在对其进行探测，则前端也将变得不可用，因此无法显示良好的错误消息。您可能需要从简单的探测开始，并在执行过程中小心地添加复杂性。

Answer 2

参考微软的实现弹性应用程序教程。特别是健康监测，建议如果当前服务的总体状态依赖于依赖状态，那么只有当服务的依赖关系健康时，服务的健康状态才应该是健康的。

然而，eShopOnContainers的MVC web应用程序对其他微服务有多个依赖关系。因此，它为每个微服务调用一个AddUrlCheck方法，如下面的示例所示：

// Startup.cs from the MVC web app
public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
        services.Configure<AppSettings>(Configuration);
        services.AddHealthChecks(checks =>
        {
            checks.AddUrlCheck(Configuration["CatalogUrl"]);
            checks.AddUrlCheck(Configuration["OrderingUrl"]);
            checks.AddUrlCheck(Configuration["BasketUrl"]);
            checks.AddUrlCheck(Configuration["IdentityUrl"]);
        });
    }
}

因此，在所有检查都正常之前，微服务将不会提供“健康”状态。。

偏压地雷

所以更直接地回答你的问题

由于依赖关系，A的准备状态健康检查是否应该调用API B的就绪健康检查？

我会说是的。特别是如果依赖B的健康状况直接影响到A的稳定性。

Answer 3

有准备和有活力。我不认为有明显的答案。只是一个指南-

活着意味着服务只是简单的响应。能用200/OK来回应。做好准备意味着按预期的方式运作。(它是最常用的API)

例如，在启动阶段，当依赖组件/服务尚未激活或准备就绪时，服务可能是活动的bot。(例如DB尚未连接)。因此，我要说，是的，为了做好准备，您可能需要确保其他基本组件是活动的，或者也准备好了。你所要做的就是决定哪些是基本要素，以便于检查。