Quarkus：如何保护Reactive REST端点免受流量雪崩影响

针对你遇到的Quarkus服务冷启动高流量下的延迟、OOM及探针超时问题，以下是针对性的解决方法，覆盖你提出的两个核心疑问：

一、限制并发请求并拒绝超额负载 #

Quarkus的quarkus.vertx.queue-size仅控制Vert.x事件循环的任务队列，对RestEasy Reactive的请求调度作用有限，需结合以下方式实现限流：

1. 使用RestEasy Reactive原生限流配置 #

Quarkus 3.x及2.16+版本支持直接配置RestEasy Reactive的活跃请求上限，无需自定义代码：

# 限制最大活跃请求数，超过后返回503 Service Unavailable
quarkus.resteasy-reactive.limits.max-active-requests=50
# 可选：设置等待队列大小，队列满后同样返回503
quarkus.resteasy-reactive.limits.max-queue-size=20

2. 自定义限流过滤器（灵活控制） #

若需更精细的规则（如排除探针请求），可实现JAX-RS过滤器，通过信号量控制并发：

import io.quarkus.vertx.http.runtime.CurrentVertxRequest;
import jakarta.annotation.Priority;
import jakarta.ws.rs.container.ContainerRequestContext;
import jakarta.ws.rs.container.ContainerRequestFilter;
import jakarta.ws.rs.core.Response;
import jakarta.ws.rs.ext.Provider;
import java.util.concurrent.Semaphore;

@Provider
@Priority(1) // 确保优先于业务过滤器执行
public class RequestThrottleFilter implements ContainerRequestFilter {

    // 允许的并发业务请求数
    private static final Semaphore CONCURRENCY_SEMAPHORE = new Semaphore(50);
    // 探针路径，需与K8s配置一致
    private static final String[] PROBE_PATHS = {"/health/readiness", "/health/liveness"};

    @Inject
    CurrentVertxRequest currentVertxRequest;

    @Override
    public void filter(ContainerRequestContext requestContext) {
        String path = requestContext.getUriInfo().getPath();
        
        // 跳过探针请求，不参与限流
        for (String probePath : PROBE_PATHS) {
            if (path.equals(probePath)) {
                // 给探针请求设置最高优先级
                currentVertxRequest.get().priority(10);
                return;
            }
        }

        // 尝试获取信号量，失败则返回503
        if (!CONCURRENCY_SEMAPHORE.tryAcquire()) {
            requestContext.abortWith(Response.status(Response.Status.SERVICE_UNAVAILABLE)
                    .entity("系统繁忙，请稍后重试")
                    .build());
        } else {
            // 请求完成后自动释放信号量
            requestContext.getRequest().asyncContext().addListener(CONCURRENCY_SEMAPHORE::release);
        }
    }
}

3. 调整Vert.x Worker池配置 #

LDAP异步回调依赖Vert.x Worker池，限制其任务队列可避免大量任务积压：

quarkus.vertx.worker-pools.default.pool-size=8
# 限制Worker池任务队列大小，满后拒绝新任务
quarkus.vertx.worker-pools.default.max-task-queue-size=100

二、优先处理Readiness/Liveness探针请求 #

通过以下两种方式确保探针请求不被业务请求阻塞：

1. 为健康检查配置独立Worker池 #

让探针请求在专属线程池执行，完全隔离业务流量：

# 启用健康检查独立Worker池
quarkus.health.worker-pool.enabled=true
# 配置池大小，满足探针请求即可
quarkus.health.worker-pool.pool-size=2

2. 设置探针请求的Vert.x优先级 #

在过滤器中为探针请求设置更高优先级，Vert.x事件循环会优先处理这类请求：

// 在上述限流过滤器中添加此逻辑（已包含在示例代码中）
currentVertxRequest.get().priority(10); // 默认优先级为5，数值越大优先级越高

额外优化：缓解JVM冷启动编译开销 #

针对你推测的C1/C2编译导致的延迟，可通过以下方式优化：

• 启用JVM分层编译降级：减少启动时的编译开销

  quarkus.jvm.args=-XX:TieredStopAtLevel=1
  

• 使用Quarkus AOT编译：提前完成字节码编译，消除启动时的JIT开销（需确保LDAP异步API支持AOT）
• GraalVM原生镜像：生成原生可执行文件，启动速度毫秒级，彻底解决JIT编译问题

综合建议 #

1. 优先使用quarkus.resteasy-reactive.limits配置限流，配合健康检查独立Worker池，快速解决核心问题；
2. 结合K8s流量预热（如Istio渐进式引流），避免冷启动时瞬间涌入大量请求；
3. 若资源紧张，可通过JVM参数调整编译策略，减少启动阶段的CPU和内存消耗。

内容的提问来源于stack exchange，提问作者Cheva