ASP.NET Core 请求管线性能与可观测性实战，为，如何优化？
摘要：很多团队做性能优化时，第一反应是改 SQL、加缓存、扩机器。结果接口还是慢，而且慢得不稳定。 这类问题里，有一部分根因并不在业务代码，而在请求进入业务之前就已经产生了: 中间件顺序、重复序列化、过重日志、异常处理位置不当，都会把每个请求的固
很多团队做性能优化时，第一反应是改 SQL、加缓存、扩机器。结果接口还是慢，而且慢得不稳定。
这类问题里，有一部分根因并不在业务代码，而在请求进入业务之前就已经产生了: 中间件顺序、重复序列化、过重日志、异常处理位置不当，都会把每个请求的固定成本悄悄抬高。
这篇文章我们不讲抽象概念，直接从一个真实工程场景出发，拆开 ASP.NET Core 请求管线，回答三个问题:
请求管线到底是怎么执行的
哪些中间件写法会稳定拉低吞吐
如何在不牺牲可观测性的前提下，把链路成本控制住
1. 问题背景: 为什么明明 CPU 不高，RT 却在抖
先看一个常见现象:
峰值时段 P95 从 35ms 涨到 90ms
CPU 只到 45%
数据库监控正常
线程池没有明显爆满
像商场收银台排队: 收银员速度没变，库存系统也没卡，但每位顾客在真正结账前都要先填两张表、复印一次小票、走一段绕路。单人多花 10 秒，队伍就会在高峰时段整体失控。
在 Web 服务里，这段“真正结账前的绕路”就是请求管线上的固定开销。
典型问题包括:
将高成本日志中间件放在链路最前面，且对所有请求都做完整 Body 记录
鉴权、异常处理、路由等中间件顺序错误，导致重复执行或额外分支判断
在中间件中做同步阻塞 I/O
将一些本该按采样写出的指标，变成了每请求都完整打点
2. 原理解析: IApplicationBuilder 如何变成 RequestDelegate
ASP.NET Core 启动时，IApplicationBuilder 会把你注册的中间件构造成一个 RequestDelegate 链。
关键点只有两个，但经常被忽略:
中间件按“注册顺序”进入，按“逆序”包裹执行。每个中间件把后续链路作为自己的 next，形成嵌套闭包。
任意中间件都可以不调用 next()，从而短路后续链路。
一个简化模型如下:
RequestDelegate app = context => Task.CompletedTask;
app = MiddlewareC(app);
app = MiddlewareB(app);
app = MiddlewareA(app);
// 实际执行顺序: A -> B -> C -> Endpoint -> C -> B -> A
这意味着:
前置中间件越重，所有请求都要付出这笔成本
末端短路逻辑的位置决定了多少中间件能被跳过
可观测性埋点放在不同层，看到的是不同粒度与成本
常见顺序误区
在 UseRouting() 之前做基于 Endpoint 元数据的判断: 信息还没解析出来
在全局异常处理中间件之后再包一层局部 try/catch: 导致异常路径重复记录
在静态资源请求也走完整业务日志链路: 无效开销
3. 示例代码: 从“能跑”到“跑得稳”
下面先看一个“看起来没问题，但成本偏高”的写法。
using System.Diagnostics;
using Microsoft.AspNetCore.HttpLogging;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHttpLogging(options =>
{
options.LoggingFields = HttpLoggingFields.All;
});
var app = builder.Build();
app.UseHttpLogging(); // 对所有请求做重日志，静态文件也不例外
app.Use(async (ctx, next) =>
{
var sw = Stopwatch.StartNew();
await next();
sw.Stop();
// 每请求都写详细日志，高并发下会有明显写放大
app.Logger.LogInformation("{Path} took {Elapsed}ms", ctx.Request.Path, sw.Elapsed.TotalMilliseconds);
});
app.UseRouting();
app.MapGet("/ping", () => Results.Ok("pong"));
app.Run();
再看一版更适合线上场景的写法。
using System.Diagnostics;
using Microsoft.AspNetCore.RateLimiting;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOpenApi();
builder.Services.AddRateLimiter(options =>
{
options.AddFixedWindowLimiter("api", limiter =>
{
limiter.Window = TimeSpan.FromSeconds(1);
limiter.PermitLimit = 200;
limiter.QueueLimit = 100;
limiter.AutoReplenishment = true;
});
});
var app = builder.Build();
app.UseExceptionHandler("/error");
app.UseRouting();
app.UseRateLimiter();
// 仅对 API 路径做轻量计时，并且避免记录敏感/大体积内容
app.UseWhen(
ctx => ctx.Request.Path.StartsWithSegments("/api"),
branch =>
{
branch.Use(async (ctx, next) =>
{
var start = Stopwatch.GetTimestamp();
await next();
var elapsedMs = (Stopwatch.GetTimestamp() - start) * 1000d / Stopwatch.Frequency;
if (elapsedMs > 50)
{
app.Logger.LogWarning(
"slow request {Method} {Path} {StatusCode} {ElapsedMs:F2}ms",
ctx.Request.Method,
ctx.Request.Path,
ctx.Response.StatusCode,
elapsedMs);
}
});
});
app.MapGet("/error", () => Results.Problem("unexpected error"));
app.MapGroup("/api")
.RequireRateLimiting("api")
.MapGet("/orders/{id:int}", (int id) => Results.Ok(new { id, status = "Paid" }));
app.MapGet("/health", () => Results.Ok("ok"));
app.Run();
这版改动的核心不是“少写几个中间件”，而是:
明确将异常处理放在统一入口
将高成本观测从“全量”调整到“有条件采样/告警”
让非 API 请求不走完整业务观测链
将限流作为入口保护，避免高峰把后端拖垮
4. 工程实践建议: 性能和可观测性不是二选一
4.1 给中间件分层，而不是平铺
建议按职责分为三层:
入口治理层: 异常处理、限流、基础安全
路由与授权层: 路由、认证、授权
业务观测层: 业务日志、慢请求告警、特定埋点
这样做的好处是顺序稳定，审查成本低，新人也不容易“插错位置”。
4.2 指标全量，日志分级
指标(如请求总量、P95、错误率)建议全量
明细日志建议按状态码、耗时阈值、采样率输出
全量日志在中高流量场景会迅速放大 I/O 成本，最后变成“为了观测而损失性能”。
4.3 用工具验证，不靠体感
至少建立这套最小验证闭环:
压测: bombardier 或 wrk
运行时计数器: dotnet-counters monitor --process-id <pid>
分布式追踪: OpenTelemetry + Jaeger/Tempo
先拿到基线，再改顺序，再对比 P95/P99 和吞吐，不要只看平均值。
4.4 中间件评审清单(可直接落地)
每次新增中间件前，团队至少回答 4 个问题:
是否必须作用于所有请求
失败时是否会影响主链路可用性
是否涉及同步阻塞 I/O
观测收益是否大于新增成本
5. 总结
ASP.NET Core 请求管线的优化，本质上是控制“每个请求必须支付的固定成本”。
IApplicationBuilder 到 RequestDelegate 的构建机制决定了中间件顺序就是性能策略。把顺序理顺、把观测做轻、把入口治理做实，通常比“盲目微优化业务代码”更快见效。
如果你线上也出现过“CPU 不高但接口发抖”的情况，建议先做两件事:
把现有中间件按执行顺序画出来
按慢请求阈值重新设计日志输出策略
很多时候，系统的稳定性拐点，就在这两步里。