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

asp,net,core · 浏览次数 : 10

小编点评

**文章简介** 文章介绍了如何在 .Net8 中使用原生 `AspNetCoreRateLimiter` 组件实现接口限流。 **配置步骤** 1. 在 `Program.cs` 中添加 `UseRateLimiter()` 方法。 2. 配置限流策略,例如使用 `FixedWindowLimiter` 等。 3. 在接口方法上使用 `EnableRateLimiting` 方法配置限流。 **限流策略** 文章展示了使用四种常用的限流策略的配置示例: * **固定窗口**:`FixedWindowLimiter` * **滑动窗口**:`SlidingWindowLimiter` * **令牌桶**:`TokenBucketRateLimiter` * **并发**:`ConcurrentRateLimiter` **示例** 假设我们使用 `FixedWindowLimiter` 配置,并设置以下参数: ```csharp services.AddRateLimiter(options => { options.AddFixedWindowLimiter(RateLimitPolicies.Fixed, opt => { opt.Window = TimeSpan.FromMinutes(1); opt.PermitLimit = 3; }); }); ``` 这将创建一个限流策略,允许 3 个请求在 1 分钟内请求,并在超过 1 分钟后拒绝请求。 **结论** 使用原生 `AspNetCoreRateLimiter` 组件可以轻松实现接口限流。该组件提供了多种策略和选项,允许您根据您的需求进行定制化配置。

正文

前言

之前介绍过使用 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 这一行,其他的都是锦上添花,可以省略。

扩展

根据IP地址进行限流

之前我使用 AspNetCoreRateLimit 组件的时候,直接使用了它提供的 IP 地址限流功能

在原生的 Microsoft.AspNetCore.RateLimiting 中,没有内置这个功能,需要自己来实现

我看了下文档里介绍的,思路是为每一个 IP 地址创建一个分区 (PartitionedRateLimiter.Create),在每个分区里再配置限流策略

详见官方文档的 limiter-with-onrejected-retryafter-and-globallimiter 部分

这种实现方式还要考虑一下,应用容易受到采用 IP 源地址欺骗的拒绝服务攻击,详见参考资料

PS: 有点复杂,我还是用回 AspNetCoreRateLimit 得了,真是折腾

根据用户进行限流

通过自定义策略,可以实现根据登录用户进行限流,比如每个用户每分钟只能请求 10 次这样子

详见官方文档的 limiter-with-authorization 部分

对了,官方文档里还提到了 dotnet user-jwts 这个工具,第一次听到,先 mark 一下,后面来看看咋样

小结

就这样吧,试用了一下,感觉还是太折腾,用回原来的 AspNetCoreRateLimit 组件得了

参考资料

与Asp-Net-Core开发笔记:使用原生的接口限流功能相似的内容:

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

前言 之前介绍过使用 AspNetCoreRateLimit 组件来实现接口限流 从 .Net7 开始,AspNetCore 开始内置限流组件,当时我们的项目还在 .Net6 所以只能用第三方的 现在都升级到 .Net8 了,当然是得来试试这个原生组件 体验后:配置使用都比较简单,不过功能也没有 A

Asp-Net-Core开发笔记:EFCore统一实体和属性命名风格

前言 C# 编码规范中,类和属性都是大写驼峰命名风格(PascalCase / UpperCamelCase),而在数据库中我们往往使用小写蛇形命名(snake_case),在默认情况下,EFCore会把原始的类名和属性名直接映射到数据库,这不符合数据库的命名规范。 为了符合命名规范,而且也为了看起

Asp-Net-Core开发笔记:使用ActionFilterAttribute实现非侵入式的参数校验

前言 在现代应用开发中,确保API的安全性和可靠性至关重要。 面向切面编程(AOP)通过将横切关注点(如验证、日志记录、异常处理)与核心业务逻辑分离,极大地提升了代码的模块化和可维护性。 在ASP.NET Core中,利用ActionFilterAttribute可以方便地实现AOP的理念,能够以简

Asp-Net-Core开发笔记:使用RateLimit中间件实现接口限流

前言 最近一直在忙(2月份沉迷steam,3月开始工作各种忙),好久没更新博客了,不过也积累了一些,忙里偷闲记录一下。 这个需求是这样的,我之前做了个工单系统,现在要对登录、注册、发起工单这些功能做限流,不能让用户请求太频繁。 从 .Net7 开始,已经有内置的限流功能了,但目前我们的项目还在使用

Asp-Net-Core开发笔记:FrameworkDependent搭配docker部署

## 前言 之前我写过一篇使用 docker 部署 AspNetCore 应用的文章,这种方式搭配 CICD 非常方便, build 之后 push 到私有的 dockerhub ,在生产服务器上 pull 下来镜像就可以直接运行了。 然而,有时需要一种更传统的部署方式,比如在本地打包可执行文件之后

Asp-Net-Core开发笔记:给SwaggerUI加上登录保护功能

前言 在 SwaggerUI 中加入登录验证,是我很早前就做过的,不过之前的做法总感觉有点硬编码,最近 .Net8 增加了一个新特性:调用 MapSwagger().RequireAuthorization 来保护 Swagger UI ,但官方的这个功能又像半成品一样,只能使用 postman c

Asp-Net-Core开发笔记:快速在已有项目中引入EFCore

前言 很多项目一开始选型的时候没有选择EFCore,不过EFCore确实好用,也许由于种种原因后面还是需要用到,这时候引入EFCore也很方便。 本文以 StarBlog 为例,StarBlog 目前使用的 ORM 是 FreeSQL ,引入 EFCore 对我来说最大的好处是支持多个数据库,如果是

Asp-Net-Core学习笔记:单元测试和集成测试

## 前言 我在使用 AspNetCore 的这段时间内,看了很多开源项目和博客,发现各种 .Net 体系的新技术很多人都有关注和使用,但却很少有人关注测试。 测试是软件生命周期中的一个非常重要的阶段,对于保证软件的可靠性具有极其重要的意义。在应用程序的开发过程中,为了确保它的功能与预期一致,必须对

Asp-Net-Core学习笔记:gRPC快速入门

## 前言 此前,我在做跨语言调用时,用的是 Facebook 的 Thrift,挺轻量的,还不错。 >Thrift是一种接口描述语言和二进制通讯协议,它被用来定义和创建跨语言的服务。它被当作一个远程过程调用(RPC)框架来使用,是由Facebook为“大规模跨语言服务开发”而开发的。它通过一个代码

Asp-Net-Core开发笔记:进一步实现非侵入性审计日志功能

前言 上次说了利用 AOP 思想实现了审计日志功能,不过有同学反馈还是无法实现完全无侵入,于是我又重构了一版新的。 回顾一下:Asp-Net-Core开发笔记:实现动态审计日志功能 现在已经可以实现对业务代码完全无侵入的审计日志了,在需要审计的接口上加上 [AuditLog] 特性,就可以记录这个接