当我们查看 .NET Aspire 仪表板的“资源”选项卡时,我们会在显示的表中找到“状态”列。此列显示 .NET Aspire 管理的每个服务的当前状态。理想情况下,我们希望这些服务中的每一个都显示为**“正在运行**”,旁边有绿色勾号,如以下屏幕截图所示:
我们可以通过使其中一个服务在启动期间抛出异常来检查此过程是否正常工作。如果我们这样做,那么仪表板将如下所示:
因此,您可能会问的问题是 .NET Aspire 如何知道特定服务是否正在运行?嗯,这很容易。因为 Aspire 托管这些服务,所以它知道其中是否有任何服务仍在运行。
但是,“状态”一栏的范围非常有限。它将显示服务正在运行,但不会告诉您是否处于不可用状态。例如,它可能正在运行,但它对资源的限制如此之大,以至于没有任何东西可以访问它。
要查看服务是否不仅在运行,而且恰好处于运行状况状态,您需要一种机制来执行所谓的运行状况检查。标准运行状况检查机制将显示你的应用是否恰好处于以下任一状态:
幸运的是,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"]);
这是正在发生的事情:
这是我们能实现的最简单的健康检查逻辑。运行状况检查终结点将始终在应用程序运行时返回正常状态。如果应用程序出现问题,则终结点将变得不可访问,并且不会返回此类状态。
现在,要使其正常工作,我们只需要映射适当的运行状况检查端点。
为了将运行状况检查映射到适当的 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 应用程序添加已知共享服务的标准方法。这些组件可能包括数据库、缓存和消息代理连接。