微服务是大型架构核心，下面我详解Spring Cloud Gateway千万并发@mikechen
异步非阻塞
要达到上万 QPS，前提是整个链路都是非阻塞。
包括下游服务（WebFlux/Netty 或其他异步网关），否则网关本身会被阻塞拖垮。
Spring Cloud Gateway 基于 Spring WebFlux + Reactor Netty，是事件驱动的非阻塞网关。
Reactor Netty 事件循环（EventLoop）：少量 I/O 线程负责成千上万连接。
遇到 I/O 等待用回调继续执行，线程不被阻塞。
典型调优思路：避免在 reactor-http-* 线程里做任何阻塞操作（JDBC、RestTemplate、同步 HTTP、文件 IO 等）。
分布式扩容
单节点再强也有上限，要抗住百万并发，必须水平扩容。
通过容器化部署、与服务编排（如 Kubernetes）。
可以按需扩展 Gateway 实例，结合负载均衡器（如 Nginx、云原生 LB）实现请求分发。
状态尽量无状态化，或使用外部共享存储/会话管理，确保扩容时不会产生一致性瓶颈。
配合服务发现与自动伸缩策略，能够在流量激增时迅速扩展处理能力。
限流保护
为了防止突发流量冲垮后端，网关必须具备精准的“拦截”能力。
Redis + Lua 实现：SCG 默认提供了 RequestRateLimiter 过滤器。
底层基于 Redis + Lua 脚本 实现 令牌桶算法 (Token Bucket)。
核心逻辑：
Lua 脚本保证了“取令牌”操作的原子性。
支持多维度限流：可以根据 IP、用户 ID 或 API 路径进行维度切分。
熔断设计
最后，熔断设计确保故障隔离与快速恢复。
针对下游服务、或关键依赖引入断路器（如 Resilience4j）。
在错误率或响应延迟超限时切断请求并返回降级响应，避免级联故障。
熔断器应配合健康检查、慢启动与半开试探机制，避免过早或过久地阻断可恢复的依赖。
同时，结合后备缓存与降级逻辑，可在依赖不可用时维持核心功能。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》