API 网关与反向代理专家
配置和优化 API 网关与反向代理，用于路由、认证、限流和流量管理。
决策点
认证策略选择
流量模式与需求
├── 仅内部服务
│ └── API 密钥认证
│ ├── 低复杂度，快速验证
│ └── Kong: key-auth 插件, Traefik: forwardAuth
├── 面向客户的 API，有会话需求
│ └── JWT 认证
│ ├── 无状态，包含用户声明
│ └── Kong: jwt 插件, Nginx: lua-resty-jwt
├── 企业 B2B 集成
│ └── mTLS 认证
│ ├── 基于证书，最高安全性
│ └── Kong: mtls-auth, Nginx: ssl_verify_client
└── 第三方 SaaS 集成
└── OAuth2 流程
├── 令牌交换，委托认证
└── Kong: oauth2 插件, AWS API Gateway: 授权器
网关技术选择
需求 → 选择
├── 需要插件生态和图形界面
│ └── Kong Enterprise/OSS
├── 原生集成 Kubernetes，自动发现
│ └── Traefik v3 或 Ingress-NGINX
├── 最大性能，最少功能
│ └── Nginx 或 Envoy
└── 云托管，无服务器弹性扩缩
└── AWS API Gateway 或 Azure Application Gateway
上游路由策略
服务架构 → 路由方法
├── 微服务，含服务发现
│ └── 动态上游目标
│ ├── Consul/Eureka 集成
│ └── 基于健康检查的负载均衡
├── 静态后端服务
│ └── 固定的上游池
│ ├── 轮询或最少连接
│ └── 加权路由用于金丝雀部署
└── 多区域部署
└── 地理路由
├── 基于延迟或地理 IP
└── 回退到辅助区域
故障模式
网关超时级联
症状： 负载下 API 响应缓慢（>10秒）
检测： 响应时间飙升，但上游服务报告正常延迟
根因： 网关超时大于上游超时，导致请求排队
修复： 设置网关读取超时 < 上游超时（网关：30秒，上游：25秒）
认证绕过
症状： 未经授权的请求到达后端服务
检测： 后端日志显示请求缺少预期的认证头
根因： 路由顺序允许宽松规则在认证规则之前匹配
修复： 将认证中间件移至全局级别，或确保特定路由在配置中优先
熔断器抖动
症状： 流量高峰期间间歇性出现 503 错误
检测： 熔断器快速打开/关闭（每分钟多次）
根因： 阈值过于敏感或健康检查配置错误
修复： 调整故障阈值（5次以上）和恢复时间（至少30秒）
SSL 证书过期
症状： HTTPS 握手失败，浏览器证书警告
检测： SSL 证书检查显示30天内到期
根因： 手动证书管理，没有自动续期
修复： 实施 cert-manager（K8s）或带有自动续期的 ACME 客户端
资源耗尽
症状： 网关停止接受连接，内存/CPU 达到 100%
检测： 连接被拒绝错误，网关健康检查失败
根因： 未设置连接限制或插件内存泄漏
修复： 设置 worker_connections（Nginx）或连接池限制（Kong），重启网关
实际案例
场景：电商 API 网关设置
背景： 为处理订单、库存和支付的微服务部署 Kong，并使用 JWT 认证
第1步：路由定义
# 首先标识服务端点
services:
- orders: /api/v1/orders/* → http://orders:8080
- inventory: /api/v1/inventory/* → http://inventory:8080
- payments: /api/v1/payments/* → http://payments:8080
第2步：应用决策树
- 流量模式：面向客户的 API → JWT 认证
- 架构：微服务 → 动态上游目标
- 需求：需要插件生态 → 选择 Kong
第3步：插件排序
# 按正确顺序应用插件
plugins:
1. cors（认证前）
2. jwt（认证）
3. rate-limiting（认证后）
4. request-transformer（最后）
专家 vs 新手：
- 新手错误： 在认证前应用限流（匿名用户消耗配额）
- 专家做法： 先认证，然后对每个已认证用户进行限流
- 新手错误： 使用全局 CORS 策略
- 专家做法： 每条路由使用不同的 CORS（orders 允许管理员源，payments 限制为前端）
故障场景：金丝雀部署出错
情况： 将 20% 的流量部署到新的订单服务版本，看到 500 错误
检测过程：
- 检查网关指标：500 错误率与部署时间同步飙升
- 上游健康检查：新版本健康检查失败
- 网关日志：上游连接超时
回滚步骤：
# 第1步：立即切换流量
kong:
routes:
- service: orders-v1
weight: 100 # 之前为 80
- service: orders-v2
weight: 0 # 之前为 20
# 第2步：验证回滚
curl -H "Authorization: Bearer $JWT" \
https://api.company.com/orders/health
# 第3步：移除失败的上游
kubectl scale deployment orders-v2 --replicas=0
根因分析： 新版本数据库连接池配置错误，导致负载下超时
质量检查
- 所有路由都有显式路径匹配（没有捕获所有 /* 路由）
- 认证中间件配置在业务逻辑插件之前
- 健康检查在5秒内对健康上游返回 2xx
- 熔断器阈值已设置：60秒窗口内5次故障，30秒恢复
- TLS 证书在到期前30多天自动续期
- 限流按已认证用户应用，而非全局
- CORS 策略将源限制为仅必要的域名
- 网关超时（30秒）< 上游超时（25秒）以防止级联
- 访问日志包含关联 ID，用于请求追踪
- 网关部署最少2个副本以实现高可用
不适用边界
此技能处理： 网关配置、路由规则、认证中间件、反向代理设置
不适用于：
- 限流算法设计 → 请使用
api-rate-limiting-throttling-expert - 服务网格数据平面配置 → 请使用
service-mesh-microservices-expert - API 规范和设计 → 请使用
api-architect - 数据库连接池 → 请使用
database-performance-expert - 容器编排 → 请使用
kubernetes-expert或docker-expert - SSL 证书生成 → 请使用
security-infrastructure-expert
委托规则：
- 对于自定义限流算法："我将配置限流插件，但有关自定义算法，请使用 api-rate-limiting-throttling-expert"
- 对于服务发现设置："我将配置上游目标，但有关服务网格设置，请使用 service-mesh-microservices-expert"