API 网关架构：请求处理流程与高可用机制
请求处理流程：监听、路由、过滤、转发
API 网关的核心工作，说白了就是当好“守门员”和“交通指挥员”。每次客户端请求进来，网关会走一条固定的流水线。我个人习惯把它拆成四步：监听、路由、过滤、转发。每个环节都藏着小坑。
先从监听说起。网关需要绑定一个端口（比如 8080），用 Netty 或 Undertow 这类高性能容器等待连接。我记得第一次搭建生产网关时，直接用了 Tomcat 默认线程池——结果压测时线程数飙到好几千，CPU 空转。后来换成事件驱动模型，才把吞吐量稳住。这里有个经验：监听层的超时时间一定要设，不然慢客户端会拖死整个网关。
请求一到，网关就得决定“往哪扔”。这就是路由。路由规则通常是一组 路径 + 方法 + 条件 的匹配表。比如：
GET /api/users/** → user-service
POST /api/orders → order-service
# 路由配置片段（YAML）
routes:
- id: user-route
uri: lb://user-service
predicates:
- Path=/api/users/**
filters:
- StripPrefix=1
嗯，这里要注意：路由匹配顺序很重要。我曾经遇到过因为通配符“/”和“/**”顺序写反，导致所有请求都打到了默认服务上。建议把精确路径放前面，模糊匹配放后面。
路由确定后，请求会经过一串过滤器。过滤链是网关的“灵魂”。你能在这里做鉴权、限流、日志、修改请求头……每个过滤器都按顺序执行。如果在项目中遇到需要跳过某些过滤器的场景，可以加一个条件注解，比如 @ConditionalOnExpression。
最后一步是转发。网关把包装好的请求发到目标服务。这一步最容易被忽视的是 连接池配置。默认的 HTTP 客户端连接池太小，高并发时会导致大量 TIME_WAIT。我个人习惯把最大连接数设为核心线程数的两倍，并把空闲超时设到 30 秒。
负载均衡策略：怎么选？
网关在转发时通常会集成客户端负载均衡。现在流行的方案有 Nginx 的 upstream，Spring Cloud 的 LoadBalancer，以及 Envoy 的集群配置。不同的策略适用于不同场景——你想想看，如果所有请求都打向同一台机器，那不是白搞集群了吗？
| 策略 | 特点 | 适用场景 | 避坑点 |
|---|---|---|---|
| 轮询 | 按顺序分配，实现简单 | 实例配置相同，无状态服务 | 当有机器性能不均时，慢节点会成为瓶颈 |
| 加权轮询 | 给高配机器更大权重 | 异构集群 | 权重调整需要重启网关，建议动态配置 |
| 最少连接数 | 转发给当前活跃连接最少的节点 | 长连接型服务（如 WebSocket） | 连接数统计有延迟，可能导致瞬间偏差 |
| 一致性哈希 | 相同请求永远落到同一节点 | 需要本地缓存、session 粘滞的场景 | 节点增删时会有少量请求迁移，需要配合虚节点 |
我在项目中踩过一个大坑：用轮询策略跑了一个需要本地缓存的服务。结果同一用户的请求轮流打到不同节点，每个节点都得重新查数据库——缓存形同虚设。后来改成一致性哈希，问题才解决。所以选策略一定要结合业务形态。
熔断与降级机制：别让一个故障拖垮所有
微服务依赖链一长，一个后端节点挂了就可能引发雪崩。熔断和降级就是用来“断臂求生”的。
熔断有点像电路里的保险丝。当某个后端服务的错误率超过阈值（比如 50%），网关直接短路该服务的请求，快速返回 fallback，而不是继续重试加重负载。等过一段时间（比如 10 秒），再放少量请求试探服务是否恢复。常见实现有 Hystrix（已停止维护）、Resilience4j、Sentinel。
降级相对更主动。当网关感知到整个系统压力过大（比如 CPU > 90%），它可以主动关闭一些非核心功能。例如：商品详情页中的“猜你喜欢”模块，降级后直接返回空数据，保证下单流程可用。
我建议在网关层做两层降级：
- 全局降级：通过动态开关，一键关闭所有非必要过滤链（如日志收集、灰度标签注入）。
- 接口级降级：为每个后端服务配置 fallback 方法。例如用户服务挂了，网关直接返回缓存的用户基本信息。
// Resilience4j 熔断配置示例（Java）
CircuitBreakerConfig customConfig = CircuitBreakerConfig.custom()
.failureRateThreshold(50)
.waitDurationInOpenState(Duration.ofSeconds(10))
.ringBufferSizeInClosedState(100)
.build();
核心流程图：请求在网关中的完整旅程
下面这张图展示了从客户端请求到后端响应的全链路，以及熔断降级介入的时机。
小贴士： 网关的过滤链里，尽量把耗时的过滤器（比如请求体校验、数据脱敏）放到靠后的位置。这样一旦前面的鉴权失败，就能提前返回，节省 CPU。我见过不少团队把限流放在最后，结果前面链路已经把资源消耗完了——白干活。
总结一下：网关架构的核心就是那四步流程，再加上负载均衡和熔断降级这两道“安全锁”。每一步都值得细抠，比如路由的优先级、负载均衡策略的选择、熔断阈值的调优。把这些基础打牢，网关才能成为平台的“稳定器”，而不是瓶颈。