百万并发下，Spring Cloud Gateway凭什么不崩？

高并发场景下网关非常重要，下面我重点详解Spring Cloud Gateway如何抗住百万并发@mikechen

异步非阻塞模型：百万并发的基石

Spring Cloud Gateway 基于 Spring WebFlux 和 Reactor Netty，天生适合处理大量并发连接。

因为，它不是“一个请求占一个线程”那种模式。

server:
  netty:
    threads: 16                  # EventLoop线程数（推荐CPU核数*2）
    max-connections: 1000000     # 最大连接数，支持百万并发
    idle-timeout: 30s            # 空闲超时
spring:
  cloud:
    gateway:
      httpclient:
        max-connections: 100000   # 后端HTTP连接池
        max-idle-time: 30s

它在处理请求时会把路由匹配、过滤器链、转发响应都放在响应式流水线里执行，这样线程不会被同步 I/O 长时间卡住。

这就是它能在高并发下比传统阻塞式网关更稳的根本原因。

此模型避免了传统同步阻塞线程，在高并发下的线程耗尽问题，使单个节点能够承载更多并发连接与请求。

高性能核心技术

在百万并发的真实生产环境下，操作系统的调优是不可忽视的“隐形技术”。

比如：零拷贝（Zero-Copy）。

Netty 提供的 CompositeByteBuf 允许在网关转发请求包时，直接在内核空间进行内存操作。

避免了数据从内核态到用户态的多次拷贝，极大地减轻了 CPU 负担。

以及，内核参数支撑。

抗住百万并发还需要调整操作系统的 ulimit（最大文件句柄数）。

以及， TCP 相关的 somaxconn 等参数，确保底层网络栈能够容纳海量的并发连接。

限流（Rate Limiting）

在秒杀、活动、抢购这类场景里，接入层限流几乎是必选项，否则后端服务和数据库很容易被拖垮。

“防雪崩”是高并发的生命线，SCG原生集成RequestRateLimiter（令牌桶/漏桶）和Resilience4j / CircuitBreaker。

spring:
  cloud:
    gateway:
      routes:
      - id: my_route
        uri: lb://my-service
        predicates:
        - Path=/api/**
        filters:
        - RequestRateLimiter=redisRateLimiter,10,20  # 每秒10个请求，突发20
        - name: CircuitBreaker
          args:
            name: myCircuitBreaker
            fallbackUri: forward:/fallback

限流：基于Redis分布式限流，精确到IP/用户/接口，防止瞬时流量击穿。

熔断：下游超时/错误率超阈值时自动熔断，快速失败，返回兜底响应。