Asp-Net-Core开发笔记：使用原生的接口限流功能

技术分享 3周前 (05-23) 0 999+

关注

前言

之前介绍过使用 AspNetCoreRateLimit 组件来实现接口限流

从 .Net7 开始，AspNetCore 开始内置限流组件，当时我们的项目还在 .Net6 所以只能用第三方的

现在都升级到 .Net8 了，当然是得来试试这个原生组件

体验后：配置使用都比较简单，不过功能也没有 AspNetCoreRateLimit 那么灵活

注册服务

为了保持 Program.cs 的代码简洁，依然是使用扩展方法来实现服务注册和配置

在 src/IdsLite.Api/Extensions/CfgRateLimit.cs 文件中

public static class RateLimitPolicies {   public const string Fixed = "fixed";   public const string Sliding = "sliding"; }  public static class CfgRateLimit {   public static IServiceCollection AddRateLimit(this IServiceCollection services) {     services.AddRateLimiter(options => {       options.AddFixedWindowLimiter(RateLimitPolicies.Fixed, opt => {         opt.Window = TimeSpan.FromMinutes(1); // 时间窗口         opt.PermitLimit = 3; // 在时间窗口内允许的最大请求数         opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst; // 请求处理顺序         opt.QueueLimit = 2; // 队列中允许的最大请求数       });     });      return services;   }    public static IApplicationBuilder UseRateLimit(this IApplicationBuilder app) {     app.UseRateLimiter();     return app;   } }

这里使用了 Fixed Window （固定窗口）的策略来进行限流，具体配置代码里面有注释。

PS: 关于四种常用的限流策略（固定/滑动窗口、令牌桶、并发），上一篇文章已经介绍过了

接着在 Program.cs 文件中添加

builder.Services.AddRateLimit();

配置中间件

var app = builder.Build();  app.MapHealthChecks("/healthz"); app.UseDefaultFiles(); app.UseStaticFiles(); app.UseExceptionless();  app.UseHttpsRedirection(); app.UseRouting(); // Routing should be defined before applying rate limiting app.UseRateLimiter(); // Rate limiting should be applied after routing app.UseCors(); // CORS should be applied after rate limiting app.UseAuthentication(); // Authentication should be applied before authorization app.UseAuthorization(); // Authorization should be applied after authentication  app.UseSwaggerWithAuthorize(); app.MapControllers();  app.Run();

注意这里一定要把限流中间件放在 UseRouting 之后的第一个

因为我们要在具体的接口上添加限流策略，所以要在请求已经被路由到指定的接口之后再进行限流

为接口添加限流配置

在需要限流的 Controller 或者接口方法上添加 [EnableRateLimiting(RateLimitPolicies.Fixed)] 就可以了

比如这个登录接口

[HttpPost("login/password")] [EnableRateLimiting(RateLimitPolicies.Fixed)] [ValidateClient(ClientIdSource.Body, ParameterName = "ClientId")] public async Task<IActionResult> LoginByPassword(PwdLoginDto dto) {}

测试效果

在 shell 中使用 curl 进行接口测试

for i in {1..11}; do curl http://localhost:5000/api/auth/login/password; done

按照上述的配置的话，在第11个请求的时候，触发了限流策略，应该会卡住，等到1分钟后才能返回

因为我们配置了 opt.QueueLimit = 2 即触发限流时，可以有 2 个请求在队列里排队，这 2 个请求会一直等到系统可以重新生成响应为止。

如果有第 3 个请求进来，则立刻返回 503 (Service Unavailable) ，这个组件默认就是 503 ，也可以自己配置成 429 (Too many requests)

配置

配置等待队列

把 opt.QueueLimit 设置为 0 ，可以实现触发限流立刻拒绝响应

自定义拒绝响应

前面说触发限流返回503，我们也可以自己配置成 429

services.AddRateLimiter(options => {   options.OnRejected = (context, token) => {     // 检查 context.Lease 中是否包含 RetryAfter 元数据     // RetryAfter 元数据通常指示客户端应该在多少秒后重试请求     if (context.Lease.TryGetMetadata(MetadataName.RetryAfter, out var retryAfter)) {       // 如果 RetryAfter 元数据存在，将 RetryAfter 值（以秒为单位）添加到响应头中       context.HttpContext.Response.Headers.RetryAfter =         ((int)retryAfter.TotalSeconds).ToString(NumberFormatInfo.InvariantInfo);     }      context.HttpContext.Response.StatusCode = StatusCodes.Status429TooManyRequests;     context.HttpContext.Response.WriteAsync("Too many requests. Please try again later.",                                             cancellationToken: token);      return new ValueTask();   }; });

其实这个是官方文档里的写法，最关键的就是 context.HttpContext.Response.StatusCode 这一行，其他的都是锦上添花，可以省略。