.NET Aspire 如何进行运行状况检查及其重要性

当我们查看 .NET Aspire 仪表板的“资源”选项卡时，我们会在显示的表中找到“状态”列。此列显示 .NET Aspire 管理的每个服务的当前状态。理想情况下，我们希望这些服务中的每一个都显示为**“正在运行**”，旁边有绿色勾号，如以下屏幕截图所示：

我们可以通过使其中一个服务在启动期间抛出异常来检查此过程是否正常工作。如果我们这样做，那么仪表板将如下所示：

因此，您可能会问的问题是 .NET Aspire 如何知道特定服务是否正在运行？嗯，这很容易。因为 Aspire 托管这些服务，所以它知道其中是否有任何服务仍在运行。

但是，“状态”一栏的范围非常有限。它将显示服务正在运行，但不会告诉您是否处于不可用状态。例如，它可能正在运行，但它对资源的限制如此之大，以至于没有任何东西可以访问它。

要查看服务是否不仅在运行，而且恰好处于运行状况状态，您需要一种机制来执行所谓的运行状况检查。标准运行状况检查机制将显示你的应用是否恰好处于以下任一状态：

• Healthy： 该应用程序正在执行其所有预期功能。

• Unhealthy： 应用程序无法按预期运行，可能无法执行其主要功能。

• Degraded： 应用程序可运行，但性能低于最佳水平。可能存在一些问题，这些问题不会完全停止功能，但会损害性能或用户体验。

幸运的是，Aspire 有一个内置的机制来执行此类运行状况检查。但在我们研究它之前，让我们首先检查一下为什么健康检查很重要。

分布式应用中运行状况检查的重要性

评估微服务的运行状况对于维护分布式系统的整体稳定性、可靠性和性能至关重要。下面是业务流程协调程序参与此评估的重要原因：

• 自动恢复：通过持续监视分布式应用程序中服务的运行状况，业务流程协调程序可以自动检测服务何时变得不正常或不可用。这使业务流程协调程序能够采取主动措施，例如重新启动故障实例或将工作负载重新分配给正常运行的实例，而无需手动干预。

• 容错：在分布式架构中，服务通常相互依赖来满足请求，一个服务的故障可能会级联并影响整个系统。通过评估单个服务的运行状况，编排器可以识别和隔离故障服务，防止大范围系统故障并保持容错能力。

• 服务级别协议 （SLA） 实施：许多分布式系统在特定的 SLA 下运行，这些 SLA 定义了可接受的服务可用性和性能级别。业务流程协调程序通过监视微服务的运行状况，可以确保满足这些 SLA，并在必要时采取纠正措施来避免违反这些 SLA。

• 动态扩展：运行状况评估在动态扩展决策中起着至关重要的作用。当业务流程协调程序检测到需求增加或性能下降时，它可以自动纵向扩展正常服务的实例以处理负载，并在需求减少时缩减未充分利用的实例。

• 优化资源分配：通过持续评估微服务的健康状况，业务流程协调器可以根据各服务的实际需求和性能优化资源分配。这确保了资源得到有效利用，最大限度地降低了成本，并最大限度地提高了系统的整体效率。

• 增强的可观测性：运行状况评估提供了对系统整体状态的宝贵见解。通过聚合来自各个微服务的运行状况指标和状态信息，业务流程协调程序可以提供全面的可观测性和监视功能，从而促进故障排除和性能优化。

现在，让我们看看如何在 Aspire 托管的应用程序中进行运行状况检查。

在 Aspire 应用程序中启用运行状况检查

运行状况检查由 Aspire 业务流程协调程序通过向特定应用程序终结点发送 HTTP 请求来完成。这些终结点会生成对这些请求的特定响应。

我们不需要手动创建这些终结点。我们只需注册相关的依赖项即可为我们完成此操作。

.NET Aspire 初学者项目在其服务器默认库中具有扩展方法。此方法的实现如下所示：AddDefaultHealthChecks()

builder.Services.AddHealthChecks()  
            // Add a default liveness check to ensure app is responsive  
            .AddCheck("self", () => HealthCheckResult.Healthy(), ["live"]);

这是正在发生的事情：

• 我们通过对对象的属性调用该方法来添加运行状况检查逻辑。

• 我们将通过调用该方法添加特定的运行状况检查。AddCheck()

• 在此方法中，我们有一个 Lambda 表达式，该表达式返回指示我们的应用程序运行正常的响应。

• 我们还将标签添加到响应中，稍后我们会回来。live

这是我们能实现的最简单的健康检查逻辑。运行状况检查终结点将始终在应用程序运行时返回正常状态。如果应用程序出现问题，则终结点将变得不可访问，并且不会返回此类状态。

现在，要使其正常工作，我们只需要映射适当的运行状况检查端点。

映射运行状况检查终结点

为了将运行状况检查映射到适当的 HTTP 端点，我们有了这种方法。此方法在 Aspire 托管的所有启用 HTTP 的应用程序的中间件中调用。它用于向应用程序添加任何默认终结点，包括运行状况检查终结点。通过在对象上调用该方法来添加运行状况检查终结点。这是它的调用方式：

app.MapHealthChecks("/health");

这是将路径注册为运行状况检查终结点的一种非常标准的方法。但还有另一个运行状况检查端点注册，如下所示：/health

app.MapHealthChecks("/alive", new HealthCheckOptions  
    {  
        Predicate = r => r.Tags.Contains("live")  
    });

这一次，我们将注册业务流程协调程序知道的路径。此终结点更为复杂。我们不仅检查我们是否收到正确的回复。我们还在验证响应是否包含标记。/alivelive

之前注册运行状况检查逻辑时，我们考虑了这两种情况。当我们返回有效响应时，我们也会返回标签。live

监视生产中的应用运行状况

如果我们仔细查看 Aspire 入门项目中的代码，我们将在注册任何端点之前看到以下条件：

if (app.Environment.IsDevelopment())

这是否意味着我们只在开发环境中进行健康检查？好吧，答案是否定的。

我们必须在任何环境中进行健康检查，尤其是生产环境。此外，我们需要使用具有相同路径的相同端点。但是，生产环境会有注意事项。

由于运行状况检查终结点可以像任何其他公共 HTTP 终结点一样访问，因此开发人员需要对其生产版本应用适当的保护。此类示例未包含在标准项目模板中的原因是，每个方案都将根据特定要求有自己的实现。

另一方面，由于运行状况检查终结点通常不共享任何敏感信息，而仅指示应用程序处于活动状态，因此开发人员可以选择在生产环境中启用与在开发环境中相同的运行状况检查逻辑。

以上概述了如何在 .NET Aspire 应用中注册运行状况检查终结点。下周，我们将通过查看所谓的 Aspire 组件来继续我们的 .NET Aspire 之旅，这是向 Aspire 应用程序添加已知共享服务的标准方法。这些组件可能包括数据库、缓存和消息代理连接。

如果你喜欢我的文章，请给我一个赞！谢谢