你正在开发的 ASP.NET Core Web API是不是也遇到过这样的场景线上流量高峰时某个实例突然崩溃导致所有请求失败或者数据库连接池耗尽整个服务响应时间飙升又或者一次简单的部署因为健康检查没做好直接把新版本推成了线上事故。这些问题的根源往往不在于代码逻辑本身而在于我们构建服务时只关注了“功能实现”却忽略了“高可用性”这个系统工程。高可用性不是某个框架的特性也不是配置几个负载均衡器就能解决的。它是一套从代码设计、到部署架构、再到运维监控的完整实践体系。很多人以为用了云服务商的负载均衡和自动伸缩就自然实现了高可用。这是一个典型的认知误区。真正的挑战在于如何让你的 ASP.NET Core 应用本身具备“弹性”能够优雅地应对故障、平滑地处理流量、并且为外部的运维手段如负载均衡、自动伸缩提供准确的“健康信号”。如果应用本身不健康或者无法告知外部系统自己的状态那么再强大的基础设施也无能为力。本文将彻底拆解构建高可用性 ASP.NET Core Web API 的核心要素。我们不只讲“是什么”更会深入“为什么”和“怎么做”。你会看到从内置的健康检查、到智能的熔断降级、再到精细化的监控指标每一个环节都是环环相扣的。我们将从一个最小可用的 API 项目出发逐步为其注入高可用基因最终形成一个能抵御常见故障、具备自愈能力的生产级服务模板。无论你是正在将单体应用改造为微服务还是从零开始构建一个需要承载关键业务的新系统这篇文章提供的思路和代码都能让你避开那些只有踩过坑才知道的“雷区”。1. 高可用性超越“不宕机”的工程实践在讨论具体技术之前我们必须先统一对“高可用性”的理解。对于 Web API 而言高可用性远不止是“服务器不宕机”。它是一个多维度的质量属性核心目标是保证服务在预设的容错范围内持续对外提供可用的、正确的响应。这具体意味着什么我们可以从以下几个层面来拆解面向故障的韧性当依赖的数据库、缓存、或其他下游服务出现故障或响应缓慢时你的 API 不能“雪崩”。它需要具备熔断、降级、重试等能力隔离故障保护核心链路。面向流量的弹性当突发流量来袭如秒杀活动系统应能通过水平扩展加机器或垂直优化提升单机性能来承载压力避免因资源耗尽而崩溃。面向变更的稳定性在进行部署、配置更新、数据迁移时系统应支持蓝绿部署、滚动更新等策略实现无缝切换保证服务不间断。可观测性与快速恢复当问题发生时完善的日志、指标和链路追踪能让你快速定位根因。同时健康检查等机制能让负载均衡器自动剔除故障节点或触发告警加速恢复。对于 ASP.NET Core 开发者来说构建高可用 API 的挑战在于框架本身提供了许多强大的基础设施如依赖注入、配置、中间件、健康检查但如何正确地组合、配置并理解它们之间的相互作用才是关键。接下来的内容我们将围绕这些挑战构建一套完整的解决方案。2. 环境与项目准备在开始编码之前确保你的开发环境就绪。本文基于 .NET 8长期支持版本进行演示其理念和代码同样适用于 .NET 9 及未来的版本。环境要求SDK: .NET 8.0 SDK 或更高版本。可通过dotnet --version命令验证。IDE: Visual Studio 2022, VS Code, 或 Rider。任选其一即可。额外工具可选但推荐: Docker Desktop用于容器化部署和模拟故障场景。让我们从一个干净的 Web API 项目开始。打开终端执行以下命令# 创建一个名为 HighAvailabilityApi 的新 Web API 项目 dotnet new webapi -n HighAvailabilityApi -f net8.0 # 进入项目目录 cd HighAvailabilityApi # 使用 VS Code 打开或其他你喜欢的编辑器 code .创建完成后你的项目结构大致如下HighAvailabilityApi/ ├── Controllers/ │ └── WeatherForecastController.cs ├── Program.cs ├── appsettings.json ├── HighAvailabilityApi.csproj └── ...这是一个标准的 ASP.NET Core Web API 模板。接下来我们将以此为画布逐步添加高可用特性。3. 基石一实施全面的健康检查健康检查是高可用系统的“眼睛”。它让外部系统如负载均衡器、容器编排平台知道你的应用实例是否健康从而做出路由决策。ASP.NET Core 内置了强大的健康检查中间件但默认模板并未启用。3.1 添加基础健康检查首先添加必要的 NuGet 包。编辑HighAvailabilityApi.csproj文件或在终端运行dotnet add package Microsoft.AspNetCore.Diagnostics.HealthChecks然后在Program.cs中配置健康检查// Program.cs var builder WebApplication.CreateBuilder(args); // 添加服务到容器中 builder.Services.AddControllers(); builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen(); // 1. 添加健康检查服务 builder.Services.AddHealthChecks(); var app builder.Build(); // 配置 HTTP 请求管道 if (app.Environment.IsDevelopment()) { app.UseSwagger(); app.UseSwaggerUI(); } app.UseHttpsRedirection(); app.UseAuthorization(); app.MapControllers(); // 2. 映射健康检查端点 // 访问 /health 即可查看应用健康状态 app.MapHealthChecks(/health); app.Run();现在运行应用 (dotnet run)并访问https://localhost:PORT/health。你会看到一个简单的Healthy状态响应。这只是一个“存活”检查表示进程在运行。3.2 添加自定义健康检查以数据库为例真正的健康检查需要探测关键依赖。假设我们的 API 依赖一个 SQL Server 数据库和一个 Redis 缓存。首先添加针对这些外部依赖的健康检查包dotnet add package AspNetCore.HealthChecks.SqlServer dotnet add package AspNetCore.HealthChecks.Redis在appsettings.json中添加连接字符串配置{ Logging: { LogLevel: { Default: Information, Microsoft.AspNetCore: Warning } }, ConnectionStrings: { DefaultDatabase: Serverlocalhost;DatabaseMyAppDb;User Idsa;PasswordYourStrongPassword;TrustServerCertificatetrue;, Redis: localhost:6379 }, AllowedHosts: * }然后在Program.cs中注册更丰富的健康检查// Program.cs using Microsoft.Extensions.Diagnostics.HealthChecks; var builder WebApplication.CreateBuilder(args); // ... 其他服务注册 ... // 添加并配置健康检查 builder.Services.AddHealthChecks() // 基础存活检查内存、磁盘等 .AddCheck(self, () HealthCheckResult.Healthy(), tags: new[] { live }) // 检查 SQL Server 数据库连接 .AddSqlServer( connectionString: builder.Configuration.GetConnectionString(DefaultDatabase), name: sql, failureStatus: HealthStatus.Unhealthy, tags: new[] { db, ready } ) // 检查 Redis 连接 .AddRedis( redisConnectionString: builder.Configuration.GetConnectionString(Redis), name: redis, failureStatus: HealthStatus.Degraded, // Redis 故障可能只是性能下降不一定是完全不可用 tags: new[] { cache, ready } ) // 模拟一个可能失败的自定义检查例如检查第三方API .AddCheckExampleHealthCheck(example, HealthStatus.Degraded, new[] { custom }); var app builder.Build(); // ... 中间件配置 ... // 映射不同用途的健康检查端点 app.MapHealthChecks(/health/live, new HealthCheckOptions { Predicate check check.Tags.Contains(live) // 仅包含存活检查 }); app.MapHealthChecks(/health/ready, new HealthCheckOptions { Predicate check check.Tags.Contains(ready), // 包含所有就绪检查数据库、缓存等 ResponseWriter WriteResponse // 自定义响应格式 }); app.MapHealthChecks(/health); // 默认端点检查所有 app.Run(); // 自定义健康检查响应格式JSON static Task WriteResponse(HttpContext context, HealthReport report) { context.Response.ContentType application/json; charsetutf-8; var result new { status report.Status.ToString(), duration report.TotalDuration, checks report.Entries.Select(e new { name e.Key, status e.Value.Status.ToString(), duration e.Value.Duration, description e.Value.Description, exception e.Value.Exception?.Message, data e.Value.Data }) }; return context.Response.WriteAsJsonAsync(result); }你需要创建一个自定义健康检查类ExampleHealthCheck// ExampleHealthCheck.cs public class ExampleHealthCheck : IHealthCheck { public TaskHealthCheckResult CheckHealthAsync( HealthCheckContext context, CancellationToken cancellationToken default) { // 这里模拟一个检查逻辑例如调用一个外部服务 var isHealthy Random.Shared.NextDouble() 0.5; // 模拟50%失败率 if (isHealthy) { return Task.FromResult( HealthCheckResult.Healthy(外部服务检查正常。)); } return Task.FromResult( HealthCheckResult.Unhealthy(外部服务响应失败。)); } }为什么这样设计/health/live: 用于 Kubernetes 的livenessProbe。如果失败容器会被重启。它应该非常轻量只检查进程本身。/health/ready: 用于 Kubernetes 的readinessProbe。如果失败Pod 会从服务端点中移除停止接收流量。它检查所有关键依赖数据库、缓存等确保实例已准备好处理请求。自定义响应: 为运维人员提供详细的 JSON 报告便于集成到监控系统如 Prometheus Grafana。4. 基石二实现弹性通信与故障处理当你的 API 调用下游服务如另一个微服务、数据库、第三方 API时网络波动、服务过载或临时故障是常态。粗暴的重试或等待会导致线程池耗尽、响应延迟激增最终引发级联故障雪崩。我们需要引入Polly一个 .NET 弹性和瞬态故障处理库。4.1 集成 Polly 策略添加 Polly 相关的 NuGet 包dotnet add package Microsoft.Extensions.Http.Polly假设我们有一个IUserService需要调用外部用户信息服务。首先定义接口和实现// Services/IUserService.cs public interface IUserService { TaskUserInfo GetUserInfoAsync(int userId, CancellationToken cancellationToken default); } public record UserInfo(int Id, string Name, string Email);// Services/UserService.cs public class UserService : IUserService { private readonly HttpClient _httpClient; public UserService(HttpClient httpClient) _httpClient httpClient; public async TaskUserInfo GetUserInfoAsync(int userId, CancellationToken cancellationToken) { // 这里模拟调用一个可能不稳定的外部 API var response await _httpClient.GetAsync($https://api.example.com/users/{userId}, cancellationToken); response.EnsureSuccessStatusCode(); return await response.Content.ReadFromJsonAsyncUserInfo(cancellationToken); } }现在在Program.cs中使用 Polly 为HttpClient配置弹性策略// Program.cs using Polly; using Polly.Extensions.Http; using System.Net; var builder WebApplication.CreateBuilder(args); // ... 其他服务注册 ... // 1. 配置一个命名的 HttpClient并应用 Polly 策略 builder.Services.AddHttpClientIUserService, UserService(UserServiceClient) .AddPolicyHandler(GetRetryPolicy()) // 重试策略 .AddPolicyHandler(GetCircuitBreakerPolicy()) // 熔断器策略 .AddPolicyHandler(GetTimeoutPolicy()); // 超时策略 // ... 其他代码 ... static IAsyncPolicyHttpResponseMessage GetRetryPolicy() { // 处理瞬态故障如网络抖动、HTTP 5xx 错误 return HttpPolicyExtensions .HandleTransientHttpError() // 处理 5xx 和 408请求超时 .OrResult(msg msg.StatusCode HttpStatusCode.TooManyRequests) // 也处理 429太多请求 .WaitAndRetryAsync( retryCount: 3, // 重试3次 sleepDurationProvider: retryAttempt TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)), // 指数退避2, 4, 8秒 onRetry: (outcome, timespan, retryAttempt, context) { // 记录重试日志便于监控 Console.WriteLine($请求失败正在进行第 {retryAttempt} 次重试。等待 {timespan.TotalSeconds} 秒后重试。错误: {outcome.Exception?.Message}); }); } static IAsyncPolicyHttpResponseMessage GetCircuitBreakerPolicy() { // 熔断器当下游服务持续故障时快速失败避免资源耗尽 return HttpPolicyExtensions .HandleTransientHttpError() .CircuitBreakerAsync( handledEventsAllowedBeforeBreaking: 5, // 连续5次故障 durationOfBreak: TimeSpan.FromSeconds(30), // 熔断30秒 onBreak: (outcome, breakDelay) { Console.WriteLine($熔断器打开停止调用下游服务 {breakDelay.TotalSeconds} 秒。原因: {outcome.Exception?.Message}); }, onReset: () { Console.WriteLine(熔断器关闭恢复调用下游服务。); }, onHalfOpen: () { Console.WriteLine(熔断器半开尝试放行一个请求以探测下游是否恢复。); }); } static IAsyncPolicyHttpResponseMessage GetTimeoutPolicy() { // 单个请求超时策略 return Policy.TimeoutAsyncHttpResponseMessage(TimeSpan.FromSeconds(10)); // 10秒超时 }4.2 在控制器中使用弹性服务在控制器中注入IUserServicePolly 策略会自动生效。// Controllers/UsersController.cs using Microsoft.AspNetCore.Mvc; [ApiController] [Route(api/[controller])] public class UsersController : ControllerBase { private readonly IUserService _userService; private readonly ILoggerUsersController _logger; public UsersController(IUserService userService, ILoggerUsersController logger) { _userService userService; _logger logger; } [HttpGet({id})] public async TaskActionResultUserInfo GetUser(int id, CancellationToken cancellationToken) { try { _logger.LogInformation(开始获取用户 {UserId} 的信息, id); var user await _userService.GetUserInfoAsync(id, cancellationToken); return Ok(user); } catch (HttpRequestException ex) // 可能由 Polly 策略抛出 { _logger.LogError(ex, 获取用户 {UserId} 信息时发生网络错误, id); // 根据业务需求可以返回降级内容如缓存数据、错误码或直接抛出 return StatusCode(StatusCodes.Status503ServiceUnavailable, 用户服务暂时不可用请稍后重试。); } catch (TaskCanceledException ex) when (cancellationToken.IsCancellationRequested) { _logger.LogWarning(用户 {UserId} 的请求被客户端取消, id); return StatusCode(StatusCodes.Status499ClientClosedRequest); } catch (TimeoutException ex) { _logger.LogError(ex, 获取用户 {UserId} 信息超时, id); return StatusCode(StatusCodes.Status504GatewayTimeout, 请求超时请稍后重试。); } // 注意Polly 的 CircuitBreaker 会抛出 BrokenCircuitException也需要处理 catch (BrokenCircuitException ex) { _logger.LogError(ex, 用户服务熔断无法处理对用户 {UserId} 的请求, id); return StatusCode(StatusCodes.Status503ServiceUnavailable, 服务暂时过载请稍后重试。); } } }策略组合的威力重试应对短暂的网络故障或下游服务重启。熔断当下游服务完全不可用时快速失败保护自身资源并给下游服务恢复的时间。超时防止一个慢请求永远占用线程导致线程池饥饿。降级在catch块中你可以返回缓存数据、默认值或友好的错误信息保证主流程不中断。5. 基石三确保应用的可观测性无法观测的系统其高可用性无从谈起。你需要知道系统内部发生了什么。ASP.NET Core 通过日志、指标和分布式追踪提供了强大的可观测性支持。5.1 结构化日志与集中收集默认的控制台日志在分布式系统中难以分析。我们需要结构化日志如 JSON并发送到集中式日志系统如 Seq, ELK Stack。首先添加合适的日志提供程序。这里以控制台输出结构化 JSON 为例生产环境应接入 Seq 或类似服务dotnet add package Serilog.AspNetCore dotnet add package Serilog.Sinks.Console dotnet add package Serilog.Sinks.Seq # 可选用于发送到Seq服务器在Program.cs中配置 Serilog// Program.cs using Serilog; // 在 CreateBuilder 之前配置 Serilog以便捕获启动过程中的日志 Log.Logger new LoggerConfiguration() .MinimumLevel.Information() .MinimumLevel.Override(Microsoft.AspNetCore, Serilog.Events.LogEventLevel.Warning) // 减少框架噪音 .Enrich.FromLogContext() // 丰富日志上下文 .WriteTo.Console( outputTemplate: [{Timestamp:HH:mm:ss} {Level:u3}] {SourceContext} {Message:lj}{NewLine}{Exception} // 或者使用 JSON 格式 // formatter: new Serilog.Formatting.Json.JsonFormatter() ) //.WriteTo.Seq(http://localhost:5341) // 如果本地运行了Seq可以启用 .CreateLogger(); try { Log.Information(启动 HighAvailabilityApi 主机...); var builder WebApplication.CreateBuilder(args); // 使用 Serilog 作为日志提供程序 builder.Host.UseSerilog(); // ... 其他服务注册和中间件配置 ... app.Run(); } catch (Exception ex) { Log.Fatal(ex, 主机意外终止); } finally { Log.CloseAndFlush(); }在控制器或服务中使用依赖注入的ILoggerT它会自动记录结构化数据。5.2 暴露应用指标指标Metrics是监控系统健康状态、性能瓶颈和业务趋势的关键。ASP.NET Core 8 原生支持使用System.Diagnostics.Metrics暴露指标。首先在Program.cs中启用指标并暴露一个端点通常与健康检查端点分开// Program.cs using System.Diagnostics.Metrics; var builder WebApplication.CreateBuilder(args); // ... 其他服务注册 ... // 创建一个全局的 Meter计量器 var meter new Meter(HighAvailabilityApi); // 创建计数器Counter用于统计请求次数 var requestCounter meter.CreateCounterlong(api.requests.total, description: 总API请求次数); // 创建直方图Histogram用于记录请求耗时分布 var requestDuration meter.CreateHistogramdouble(api.request.duration, unit: ms, description: API请求耗时); builder.Services.AddSingleton(meter); builder.Services.AddSingleton(requestCounter); builder.Services.AddSingleton(requestDuration); var app builder.Build(); // ... 中间件配置 ... // 创建一个中间件来收集请求指标 app.Use(async (context, next) { var stopwatch Stopwatch.StartNew(); try { await next(context); } finally { stopwatch.Stop(); // 记录请求指标 requestCounter.Add(1, new KeyValuePairstring, object?(path, context.Request.Path)); requestDuration.Record(stopwatch.ElapsedMilliseconds); } }); // 映射指标端点通常使用 /metrics遵循 OpenMetrics 标准 // 注意生产环境应保护此端点或使用专门的监控代理来拉取 app.MapGet(/metrics, () { // 在实际项目中这里应返回聚合的指标数据。 // 更常见的做法是使用如 OpenTelemetry 或 prometheus-net 库来自动暴露指标。 return Results.Text(# 这是一个指标端点占位符。建议集成 prometheus-net。, text/plain); }); app.Run();生产环境建议使用prometheus-net.AspNetCore库它可以自动将 ASP.NET Core 的指标转换为 Prometheus 格式。安装后只需一行代码app.UseHttpMetrics();和app.MapMetrics();即可。5.3 分布式追踪在微服务架构中一个请求可能穿越多个服务。分布式追踪能帮你还原完整的调用链路快速定位延迟或错误的根源。这通常通过集成OpenTelemetry来实现。由于 OpenTelemetry 配置较为复杂涉及导出器如 Jaeger, Zipkin、采样率等本文不展开详细代码。但其核心思想是在每个服务的入口和出口处自动生成和传播唯一的追踪标识TraceId, SpanId并将这些信息记录到日志和指标中。6. 部署与运维层面的高可用实践代码层面的准备就绪后我们需要在部署和运行时环境上落实高可用。6.1 容器化与编排将应用容器化Docker是实现弹性伸缩和故障恢复的基础。创建一个Dockerfile# 使用官方 .NET 运行时镜像作为基础 FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base WORKDIR /app EXPOSE 8080 EXPOSE 8081 # 使用 SDK 镜像来构建 FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build WORKDIR /src COPY [HighAvailabilityApi.csproj, ./] RUN dotnet restore HighAvailabilityApi.csproj COPY . . RUN dotnet build HighAvailabilityApi.csproj -c Release -o /app/build FROM build AS publish RUN dotnet publish HighAvailabilityApi.csproj -c Release -o /app/publish # 最终运行镜像 FROM base AS final WORKDIR /app COPY --frompublish /app/publish . # 设置健康检查使用我们定义的 /health/live 端点 HEALTHCHECK --interval30s --timeout3s --start-period30s --retries3 \ CMD curl -f http://localhost:8080/health/live || exit 1 ENTRYPOINT [dotnet, HighAvailabilityApi.dll]使用 Kubernetes 或类似的容器编排平台你可以轻松实现多副本部署运行多个 Pod 实例由 Service 负载均衡。自动伸缩根据 CPU、内存或自定义指标如每秒请求数自动增减 Pod 数量。滚动更新逐步用新版本替换旧版本 Pod实现零停机部署。自我修复通过livenessProbe和readinessProbe对应我们的/health/live和/health/readyKubernetes 能自动重启不健康的容器或将其从流量池中剔除。一个简化的 Kubernetes Deployment 配置示例如下# deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: high-availability-api spec: replicas: 3 # 至少3个副本以实现基本的高可用 selector: matchLabels: app: high-availability-api template: metadata: labels: app: high-availability-api spec: containers: - name: api image: your-registry/high-availability-api:latest ports: - containerPort: 8080 resources: requests: memory: 256Mi cpu: 100m limits: memory: 512Mi cpu: 500m livenessProbe: httpGet: path: /health/live port: 8080 initialDelaySeconds: 10 periodSeconds: 30 timeoutSeconds: 3 failureThreshold: 3 readinessProbe: httpGet: path: /health/ready port: 8080 initialDelaySeconds: 30 # 给应用更长的启动准备时间 periodSeconds: 10 timeoutSeconds: 3 failureThreshold: 36.2 配置与密钥管理硬编码的连接字符串和密钥是安全和高可用性的噩梦。务必使用外部配置源。开发环境使用appsettings.Development.json和用户机密User Secrets。生产环境使用环境变量、Azure Key Vault、HashiCorp Vault 或 Kubernetes Secrets/ConfigMaps。在Program.cs中ASP.NET Core 的配置系统已经很好地支持了这些源。var builder WebApplication.CreateBuilder(args); // 默认已加载 appsettings.json, appsettings.{Environment}.json, 环境变量命令行参数等。 // 可以继续添加其他源如 Key Vault // builder.Configuration.AddAzureKeyVault(...);7. 常见问题与排查思路在构建和运行高可用 API 的过程中你可能会遇到以下典型问题问题现象可能原因排查方式解决方案健康检查端点/health返回Unhealthy1. 数据库/缓存连接失败。2. 自定义健康检查逻辑失败。3. 应用启动未完成。1. 检查appsettings.json中的连接字符串。2. 查看应用日志特别是健康检查相关的错误。3. 访问/health/ready和/health/live分别确认。1. 修正连接配置或确保依赖服务可用。2. 检查自定义健康检查ExampleHealthCheck的逻辑。3. 增加健康检查的启动延迟 (InitialDelaySeconds)。Polly 熔断器频繁打开即使下游服务正常1. 熔断阈值 (handledEventsAllowedBeforeBreaking) 设置过低。2. 超时时间 (TimeoutPolicy) 过短导致请求被误判为失败。3. 下游服务响应慢但未达到超时。1. 查看日志中熔断器打开/关闭的记录。2. 监控下游服务的响应时间P95, P99。3. 使用分布式追踪分析链路延迟。1. 根据实际容错能力调整熔断阈值和熔断时间。2. 适当增加超时时间或为不同接口设置差异化超时。3. 优化下游服务性能或在本服务实现降级逻辑。Kubernetes Pod 不断重启1.livenessProbe检查失败。2. 应用内存或 CPU 超限被系统 OOM Kill。3. 应用启动时发生不可恢复错误。1.kubectl describe pod pod-name查看事件和最后一次状态。2.kubectl logs pod-name --previous查看前一个容器的日志。3. 检查 Pod 的资源请求和限制。1. 确保/health/live端点轻量且稳定调整failureThreshold。2. 合理设置resources.requests/limits并监控资源使用率。3. 检查应用启动代码确保能处理配置缺失等异常。日志量巨大难以定位问题1. 日志级别设置过低如Information。2. 缺乏结构化字段无法有效过滤。3. 没有集中式日志收集。1. 检查appsettings.json中的LogLevel配置。2. 查看日志输出格式是否为非结构化的文本。1. 生产环境将默认日志级别设为Warning关键业务操作使用Information。2. 使用 Serilog 等库输出 JSON 格式日志。3. 集成 ELK、Seq 或 DataDog 等日志聚合系统。突发流量下API 响应变慢甚至超时1. 线程池或连接池耗尽。2. 数据库连接数达到上限。3. 未启用水平扩展。1. 监控应用指标线程数、活动请求数、GC 频率。2. 监控数据库连接数和慢查询。3. 查看负载均衡器流量分布。1. 优化异步代码避免阻塞调用。2. 调整数据库连接池大小优化查询。3. 配置 Kubernetes HPA 或云服务的自动伸缩策略。8. 最佳实践与工程建议将高可用性内化为开发习惯以下建议供你在实际项目中参考设计阶段考虑故障在架构设计时就假设网络会延迟、依赖会失败、磁盘会写满。采用“防御性编程”思想。区分健康检查严格区分Liveness存活和Readiness就绪。Liveness失败应重启实例Readiness失败应从负载均衡中剔除实例。合理配置超时与重试超时为所有外部调用设置合理的超时时间并采用分层超时如整体请求超时 下游调用超时。重试仅对幂等操作GET、PUT、DELETE或可安全重试的 POST 操作进行重试。使用指数退避和抖动Jitter避免重试风暴。实施优雅关闭ASP.NET Core 支持IHostApplicationLifetime。在收到终止信号时应停止接收新请求完成正在处理的请求再关闭资源数据库连接等。app.Lifetime.ApplicationStopping.Register(() { Console.WriteLine(应用正在停止清理资源中...); // 清理 HttpClient, 数据库连接等 });监控一切可监控的除了系统指标CPU、内存更要监控业务指标每秒订单数、平均响应时间、错误率。设置明确的告警阈值如错误率 1% 持续 5 分钟。容量规划与压力测试在上线前通过压力测试如使用 k6, JMeter了解系统的极限容量并据此设置自动伸缩的阈值。制定并演练故障恢复预案文档化常见故障的处理流程并定期进行故障演练Chaos Engineering确保团队在真实故障发生时能快速、正确地响应。构建高可用性的 ASP.NET Core Web API 是一个贯穿设计、开发、部署和运维全周期的持续过程。它没有银弹而是由一系列经过验证的模式、工具和严谨的工程实践组合而成。本文为你搭建了一个坚实的起点从健康检查、弹性策略到可观测性覆盖了核心的内功心法。真正的挑战在于如何将这些模式与你团队的具体业务逻辑、技术栈和运维环境深度融合。建议你从当前正在开发或维护的一个非关键服务开始逐步引入这些实践观察效果积累经验。当你习惯了以“高可用”的视角来审视每一行代码和每一个配置时你所构建的系统自然会具备更强的韧性和可靠性。