Gateway是大厂核心，下面我详解Gateway如何抗住亿级流量@mikechen
采用响应式非阻塞架构
Gateway 基于 Reactor 与 Netty，能够以较少线程处理大量并发连接。
// 反例：阻塞等待
String result = webClient.get()
.uri(authUrl)
.retrieve()
.bodyToMono(String.class)
.block();
基于 Reactor Netty（事件驱动 + NIO 多路复用）。
少量 EventLoop / Worker 线程（通常 = CPU 核数或核数 × 1.5~2）就能管理成千上万连接。
请求进来后注册回调，线程立刻释放去处理其他请求，I/O 等待不阻塞线程。
它的优势不是“线程特别多”，而是网络等待不必对应一个被阻塞的业务线程。
实施限流与过载保护
面对百万级洪峰流量，网关的首要任务是“保命”。
如果所有请求无限制地涌入下游微服务，整个微服务集群会瞬间被打垮。
限流：官方 RequestRateLimiter 基于 Redis + Lua 脚本实现令牌桶算法（replenishRate 填充速率 + burstCapacity 突发容量）。
支持按 IP、用户、路径等 Key 限流，集群级原子精确。也可接 Sentinel / Resilience4j。
熔断：集成 Resilience4j 或 Sentinel，失败率/慢调用超阈值快速失败，并支持 fallbackUri 降级。
配合隔离舱、降级开关（Nacos 动态配置），保护核心链路。
建立可观测与弹性扩容机制
水平扩展：单机有上限，Gateway 集群 + 前置负载均衡（Nginx/SLB/K8s Ingress）分摊流量。
持续监控请求量、延迟、错误率、连接池状态和 JVM 指标，借助压测发现瓶颈，并依据流量动态扩缩容。
同时，部署多个网关实例并配合负载均衡，减少单点故障风险。
做好连接与资源管理
合理配置连接池、超时、队列和线程数，避免连接过多或请求无限等待。
对下游服务设置连接超时、响应超时及并发上限，使资源使用保持在可控范围内。
以上
