运行状况检查是否应调用其他应用程序运行状况检查

如果服务A可以服务于业务请求,那么它就准备好了。所以如果能够达到B是它的一部分 需要

检查B的一个优点是你可以 fail fast on a bad rolling upgrade . 假设您的A配置错误,因此升级中B的连接细节错误-可能B的服务名称被作为环境变量注入,而新版本有输入错误。如果您的A实例在启动时检查Bs,那么您可以更轻松地确保升级失败,并且没有流量流向新的错误配置的POD。有关这方面的更多信息,请参阅 https://medium.com/spire-labs/utilizing-kubernetes-liveness-and-readiness-probes-to-automatically-recover-from-failure-2fe0314f2b2e

checking B's readiness probe for you anyway 因此,A可以到达的任何B实例都是现成的。调用B的活动性端点而不是就绪性端点可以带来不同,如果B readiness endpoint performs more checks than the liveness one . 请记住,kubernetes将定期调用这些探测器- readiness as well as liveness - they both have a period end-to-end transaction checks ,您希望这些检查包含最少的逻辑,并且不会占用太多的负载。

如果A的就绪性实现中的代码进行检查,而不是在k8s级别(在Pod规范本身中)进行检查,则更可取。最好是在k8s级别执行此操作,因为理想情况下,您希望知道容器中运行的代码确实可以连接。

另一种检查依赖服务的方法是可用的 is with a check in an initContainer . 使用initContainers可以避免在启动过程中看到多次重启(通过确保正确的顺序),但是通过探测检查依赖关系可能会更深入(如果在应用程序代码中实现的话),并且探测将在启动后继续定期运行。因此,两者都使用可能是有利的。

引用微软的 Implementing Resilient Applications 教程。特别是 Health monitoring ,建议如果当前服务的总体状态取决于依赖项的状态,则只有在依赖项正常的情况下,服务的正常状态才应为正常

然而,eShopContainers的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 .

活动意味着服务只是响应。e、 g.能够响应200/OK。

例如,在启动阶段,服务可能处于活动状态,但尚未就绪,因为依赖组件/服务尚未处于活动状态或就绪状态。(例如,数据库尚未连接)。 因此,我想说是的,为了准备就绪,您可能需要确保其他基本组件处于活动状态或也准备就绪。你所要做的就是决定哪些是需要检查准备情况的基本要素。

当我在一个应用程序中实现健康端点时,我会按照最佳实践检查应用程序工作所需的所有依赖关系。

如果其中一个依赖项不起作用,我的应用程序将无法工作,因此它将被标记为不健康。