高并发场景下网关作为流量的入口非常重要，下面我重点详解Spring Cloud Gateway如何抗住百万性能@mikechen
异步非阻塞百万并发的基石
Spring Cloud Gateway 内部采用的是 NIO（非阻塞 I/O）模型，这是 Spring Cloud Gateway 能够成为 高并发网关 的底层支撑。
与传统的阻塞式 I/O 模型不同，NIO 不会因为某个请求的处理而阻塞整个线程。
由于没有线程阻塞，请求的处理更加流畅，减少了不必要的等待时间，从而降低了请求的延迟。
一个线程可以处理成千上万个并发连接，而不是像传统模型那样一个线程只能处理一个连接。
这极大地减少了线程切换的开销，提高了系统的整体吞吐量。
Reactor异步机制
Spring Cloud Gateway构建于Spring WebFlux和Project Reactor之上，采用响应式编程模型，实现非阻塞的请求处理。
reactor:
netty:
ioWorkerCount: 16 # 根据 CPU 核心数调整
tcp:
maxConnections: 1000000 # 支持百万并发连接
Reactor Netty，基于 Reactor 响应式编程 + NIO，少量线程即可处理大量连接。
这种设计极大降低了线程资源占用，让系统能够高效地处理海量并发请求。
集群化水平扩展
单机再强，也难以扛下持久百万并发，必须 集群化部署。
Spring Cloud Gateway 的高可用部署和分布式架构设计是抗住百万并发的基石。
通过集群化和容器化部署，Gateway 可水平扩展，处理海量请求。
Gateway 实例可无状态部署，借助 Nginx、LVS、K8s Ingress 做前置负载均衡。
限流（Rate Limiting）
在百万并发场景中，自保护策略是保证系统稳定性的最后屏障，比如：限流等场景。
常见的方式，包括：令牌桶（Token Bucket）、漏桶（Leaky Bucket）、固定窗口/滑动窗口…等等。
令牌桶（Token Bucket）是一种常用的网络流量整形和速率限制算法。
如下图所示：
它的核心思想是，系统以一个恒定的速率往一个桶里放入“令牌”。
每个请求想要被处理，都必须先从桶里获取一个令牌。
如果桶里没有令牌，请求就必须等待，直到有新的令牌被放入。
可以限制API调用频率，既能保证整体调用量不超标，又能允许用户在短时间内进行多次调用。
熔断
熔断的作用就像一个电路中的保险丝：当电流过大时，保险丝会熔断，保护整个电路不被烧毁。
当一个服务的失败率达到某个阈值时，它会自动“熔断”对该服务的调用，从而保护整个系统。
Spring Cloud Gateway 本身不提供熔断功能，但它无缝集成了 Resilience4j 这样的流行熔断库。
Resilience4j 是一个轻量级、响应式的故障容忍库，专为函数式编程和响应式应用设计，非常适合 Spring Cloud Gateway 的底层技术栈。