如何为Quarkus RESTEasy API实现用户级并发限制抵御DoS

我当前的API已针对常规及突发流量调优了资源限制，多数场景运行正常，但偶尔会有授权用户发送数千个并发请求，触发连接池耗尽等资源限制，导致新请求返回HTTP 500，直到流量回落。虽然可以通过扩大配置限制解决，但会额外消耗内存，更合理的方式是添加用户级限制，避免单个用户耗尽系统资源。

我了解速率限制、并发限制是抵御DoS的常用方案，也知道Quarkus的SmallRye容错扩展可实现常见弹性模式，但这些模式是应用级而非用户级。直接使用@RateLimit或@Bulkhead注解仍会出现DoS问题——单个用户会占用全部限制容量，导致其他用户请求报错。虽然有编程式API可自定义限制器，但实现难度较高。

想请教：

• 是否有现成方案可为Quarkus RESTEasy API实现用户级并发限制？
• 若无现成方案，有没有简便方法扩展容错机制实现用户范围限制，或编写RESTEasy中间件？
• 该问题是否更适合在上游负载均衡器解决？

解决方案建议 #

一、现成方案：使用Quarkus扩展实现用户级限制 #

目前Quarkus生态中有几个扩展可以直接支持用户级的速率/并发限制：

• SmallRye Rate Limits 扩展：基础注解虽为应用级，但可通过@RateLimit的key参数指定用户标识（比如从JWT、请求头或SecurityContext中提取用户ID），让限制规则作用于单个用户而非整个应用。示例：

  @GET
  @Path("/protected")
  @RateLimit(value = 10, window = 1, unit = TimeUnit.MINUTES, key = "#user.id")
  public Response protectedEndpoint(@Context SecurityContext securityContext) {
      User user = (User) securityContext.getUserPrincipal();
      return Response.ok("Hello " + user.getId()).build();
  }
  

• Quarkus Redis Rate Limiting 扩展：如果需要分布式场景下的统一用户级限制，可结合Redis存储用户请求计数，避免单实例内存占用过高，同时支持跨实例的限制同步。

二、扩展SmallRye容错机制实现用户级Bulkhead（并发限制） #

若想用SmallRye的Bulkhead实现用户级并发控制，可通过自定义拦截器+缓存的方式简化实现：

1. 维护一个基于用户ID的Bulkhead实例缓存；
2. 自定义注解标记需要限制的端点；
3. 在拦截器中根据用户ID获取对应Bulkhead，执行并发控制逻辑。
   简化示例代码：

@Interceptor
@UserBulkhead(maxConcurrentCalls = 5)
public class UserBulkheadInterceptor {
    private final ConcurrentHashMap<String, Bulkhead> bulkheads = new ConcurrentHashMap<>();

    @AroundInvoke
    public Object intercept(InvocationContext ctx) throws Exception {
        String userId = extractUserIdFromSecurityContext(ctx); // 从上下文提取用户唯一标识
        Bulkhead bulkhead = bulkheads.computeIfAbsent(userId, k -> Bulkhead.of(5));
        return bulkhead.execute(ctx::proceed);
    }
}

这种方式无需复杂的编程式API，通过拦截器实现用户级的并发隔离。

三、编写RESTEasy中间件实现用户级限制 #

利用RESTEasy的ContainerRequestFilter和ContainerResponseFilter可以实现轻量的用户级并发限制：

1. 维护一个按用户ID存储的信号量（Semaphore）缓存，控制单用户并发请求数；
2. 请求到达时，若用户并发数超过限制则直接返回HTTP 429；
3. 请求结束后释放信号量资源，避免内存泄漏。
   示例代码：

@Provider
public class UserConcurrentLimitFilter implements ContainerRequestFilter {
    private final ConcurrentHashMap<String, Semaphore> userSemaphores = new ConcurrentHashMap<>();
    private static final int MAX_CONCURRENT_PER_USER = 5;

    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        String userId = extractUserId(requestContext); // 从请求头/JWT中提取用户ID
        if (userId == null) return;

        Semaphore semaphore = userSemaphores.computeIfAbsent(userId, k -> new Semaphore(MAX_CONCURRENT_PER_USER));
        if (!semaphore.tryAcquire()) {
            requestContext.abortWith(Response.status(Response.Status.TOO_MANY_REQUESTS)
                    .entity("单用户并发请求数超出限制")
                    .build());
        }
    }
}

@Provider
public class UserConcurrentReleaseFilter implements ContainerResponseFilter {
    private final ConcurrentHashMap<String, Semaphore> userSemaphores;

    public UserConcurrentReleaseFilter(ConcurrentHashMap<String, Semaphore> userSemaphores) {
        this.userSemaphores = userSemaphores;
    }

    @Override
    public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
        String userId = extractUserId(requestContext);
        if (userId != null) {
            Semaphore semaphore = userSemaphores.get(userId);
            if (semaphore != null) {
                semaphore.release();
                // 当信号量回到初始状态时移除，避免内存占用
                if (semaphore.availablePermits() == MAX_CONCURRENT_PER_USER) {
                    userSemaphores.remove(userId);
                }
            }
        }
    }
}

这种方式完全基于RESTEasy扩展机制，轻量灵活，无需依赖额外容错库。

四、上游负载均衡器方案对比 #

如果架构中有成熟的负载均衡器（如Nginx、HAProxy），也可以在负载均衡层配置用户级限制：

• 优势：无需修改应用代码，能在流量到达应用前拦截恶意请求，减轻服务器压力；
• 局限：需要负载均衡器支持基于用户标识的规则配置（如通过Cookie、请求头提取用户ID），分布式场景下需依赖Redis等共享存储同步计数；
• 适用场景：应用实例较多、或不想侵入应用代码时优先考虑。

内容的提问来源于stack exchange，提问作者oaklandcorp-jkaiser