当前位置：首页 > news >正文

从 IApplicationBuilder 到 RequestDelegate：ASP.NET Core 请求管线的性能与可观测性实战 - ryan

news 2026/3/27 4:28:53

很多团队做性能优化时，第一反应是改 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();

这版改动的核心不是“少写几个中间件”，而是: