如何通过ASP.NET Core 6框架检查应用健康状况?
摘要:现代化的应用及服务的部署场景主要体现在集群化、微服务和容器化,这一切都建立在针对部署应用或者服务的健康检查上。ASP.NET提供的健康检查不仅可能确定目标应用或者服务的可用性,还具有健康报告发布功能。ASP.NET框架的健康检查功能是通过H
现代化的应用及服务的部署场景主要体现在集群化、微服务和容器化,这一切都建立在针对部署应用或者服务的健康检查上。ASP.NET提供的健康检查不仅可能确定目标应用或者服务的可用性,还具有健康报告发布功能。ASP.NET框架的健康检查功能是通过HealthCheckMiddleware中间件完成的。我们不仅可以利用该中间件确定当前应用的可用性,还可以注册相应的IHealthCheck对象来完成针对不同方面的健康检查。(本文提供的示例演示已经同步到《ASP.NET Core 6框架揭秘-实例演示版》)
[S3001]确定应用可用状态(源代码)
[S3002]定制健康检查逻辑(源代码)
[S3003]改变健康状态对应的响应状态码(源代码)
[S3004]提供细粒度的健康检查(源代码)
[S3005]定制健康报告响应内容(源代码)
[S3006]IHealthCheck对象的过滤(源代码)
[S3007]定期发布健康报告(源代码)
[S3001]确定应用可用状态对于部署于集群或者容器的应用或者服务来说,它需要对外暴露一个终结点,负载均衡器或者容器编排框架以一定的频率向该终结点发送“心跳”请求,以确定应用和服务的可用性。演示程序应用采用如下的方式提供了这个健康检查终结点。
var builder = WebApplication.CreateBuilder();
builder.Services.AddHealthChecks();
var app = builder.Build();
app.UseHealthChecks(path: "/healthcheck");
app.Run();演示程序调用了UseHealthChecks扩展方法注册了HealthCheckMiddleware中间件,并利用指定的参数将健康检查终结点的路径设置为“/healthcheck”。该中间件依赖的服务通过调用AddHealthChecks扩展方法进行注册。在程序正常运行的情况下,如果利用浏览器向注册的健康检查路径“/healthcheck”发送一个简单的GET请求,就可以得到图1所示的“健康状态”。
图1 健康检查结果
如下所示的代码片段是健康检查响应报文的内容。这是一个状态码为“200 OK”且媒体类型为“text/plain”的响应,其主体内容就是健康状态的字符串描述。在大部分情况下,发送健康检查请求希望得到的是目标应用或者服务当前实时的健康状况,所以响应报文是不应该被缓存的,如下所示的响应报文的“Cache-Control”和“Pragma”报头也体现了这一点。
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Sat, 13 Nov 2021 05:08:00 GMT
Server: Kestrel
Cache-Control: no-store, no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Content-Length: 7
Healthy
[S3002]定制健康检查逻辑对于前面演示的实例来说,只要应用正常启动,它就被视为“健康”(完全可用),这种情况有时候可能并不是我们希望的。有时候应用在启动之后需要做一些初始化的工作,并希望在这些工作完成之前当前应用处于不可用的状态,这样请求就不会被导流进来。这样的需求就需要我们自行实现具体的健康检查逻辑。下面的演示程序将健康检查实现在内嵌的Check方法中,该方法会随机返回三种健康状态(Healthy、Unhealthy和Degraded)。在调用AddHealthChecks扩展方法注册所需依赖服务并返回IHealthChecksBuilder对象后,它接着调用了该对象的AddCheck方法注册了一个IHealthCheck对象,后者会调用Check方法决定当前的健康状态。
