mcpField
A
api-gateway-patterns

api-gateway-patterns

github.com/nickcrew开发6298 次安装18 周前更新
代码仓库

关于 api-gateway-patterns

为微服务系统中的 API 网关提供设计与实施指导，涵盖路由、安全、流量控制和服务组合，并附常见模式与实现的参考资料。

主要功能

  1. 01路由策略指导
  2. 02身份验证与授权模式
  3. 03速率限制、重试与熔断器
  4. 04BFF 与网关架构模式
  5. 05服务组合与转换
  6. 06实现参考资料

适用场景

  1. 01设计微服务 API 网关
  2. 02添加网关层访问控制
  3. 03规划弹性流量策略
  4. 04选择网关架构或实现方案

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/nickcrew/claude-cortex --skill api-gateway-patterns

安装后在 Claude Code 中输入/api-gateway-patterns确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
authentication.md
bff-pattern.md
composition.md
implementations.md
routing-patterns.md
service-discovery.md
traffic-management.md
transformation.md

详细介绍

API 网关模式

为微服务架构大规模实现 API 网关提供专家指导，涵盖路由、身份验证、流量管理和服务组合模式。

何时使用此技能

  • 为微服务实现 API 网关基础设施
  • 设计 Backend for Frontend（BFF）层
  • 在网关层添加身份验证和授权
  • 实现速率限制、熔断器和重试逻辑
  • 设置服务发现和动态路由
  • 构建 API 组合与聚合层
  • 管理横切关注点（日志记录、监控、CORS）
  • 评估网关解决方案（Kong、Nginx、Envoy、AWS API Gateway）

核心概念

网关职责

路由：根据路径、标头或主机将请求转发到相应的后端服务 安全：集中处理身份验证、授权和 API 密钥验证 流量管理：速率限制、熔断器、重试逻辑 组合：聚合多个服务调用，生成统一响应 转换：修改请求/响应，以优化客户端体验或适配旧系统

架构模式

单网关：所有客户端共用一个网关（简单，但可能成为瓶颈） BFF 模式：为每种客户端类型（移动端、Web、管理端）单独设置网关，并针对各自需求进行优化 GraphQL 网关：跨服务拼接 Schema，由客户端驱动数据获取 服务网格：使用 Sidecar 代理实现分布式网关模式（Istio、Linkerd）

快速参考

任务加载参考文档
路由策略（基于路径、标头、主机）skills/api-gateway-patterns/references/routing-patterns.md
请求/响应转换skills/api-gateway-patterns/references/transformation.md
API 组合与聚合skills/api-gateway-patterns/references/composition.md
身份验证与授权（JWT、OAuth、RBAC）skills/api-gateway-patterns/references/authentication.md
流量管理（速率限制、熔断器）skills/api-gateway-patterns/references/traffic-management.md
Backend for Frontend（BFF）模式skills/api-gateway-patterns/references/bff-pattern.md
服务发现集成skills/api-gateway-patterns/references/service-discovery.md
网关实现（Kong、Nginx、Envoy、AWS）skills/api-gateway-patterns/references/implementations.md

实施工作流

阶段 1：需求分析
  1. 识别客户端类型：移动端、Web、管理端、合作伙伴
  2. 梳理服务全貌：列出后端服务和端点
  3. 定义横切关注点：身份验证、日志记录、监控、CORS
  4. 确定组合需求：哪些端点需要聚合？
  5. 制定 SLA：延迟、吞吐量和可用性目标
阶段 2：网关设计
  1. 选择架构：单网关、BFF 还是 GraphQL
  2. 选择实现方案：Kong、Nginx、Envoy、AWS API Gateway
  3. 设计路由规则：基于路径、标头或主机
  4. 规划身份验证：JWT、OAuth 2.0、API 密钥或混合方案
  5. 定义流量策略：速率限制、熔断器、超时
阶段 3：实施
  1. 搭建基础设施：部署网关实例，配置负载均衡器
  2. 实现路由：配置服务发现和路由定义
  3. 添加身份验证：JWT 验证、OAuth 集成、API 密钥管理
  4. 应用流量管理：速率限制、熔断器、重试逻辑
  5. 启用可观测性：分布式追踪、指标、结构化日志记录
阶段 4：测试与优化
  1. 负载测试：验证预期负载和峰值负载下的性能
  2. 故障注入：测试熔断器和重试逻辑
  3. 安全测试：验证身份验证流程、令牌验证和 RBAC 策略
  4. 延迟优化：缓存策略、连接池
  5. 监控与调优：根据实际流量调整超时和限制

最佳实践

  1. 集中处理横切关注点：在网关处理身份验证、日志记录和监控
  2. 保持网关轻量：避免复杂的业务逻辑，将其委托给服务
  3. 实施健康检查：监控上游服务的健康状况，移除不健康的实例
  4. 使用熔断器：防止故障级联，快速失败
  5. 实施速率限制：保护服务免受过载影响，设置分级限制
  6. 启用可观测性：分布式追踪、指标和结构化日志
  7. 对 API 进行版本管理：支持多个 API 版本，规划弃用策略
  8. 保障通信安全：全程使用 TLS，服务间通信使用双向 TLS
  9. 合理使用缓存：缓存响应，但要妥善失效
  10. 测试韧性：混沌工程、故障注入、负载测试

常见错误

  1. 在网关中实现业务逻辑：让网关专注于路由和安全，而非业务规则
  2. 频繁调用多个服务进行组合：上游调用过多（使用 BFF、GraphQL 或缓存）
  3. 单点故障：采用冗余部署，使用负载均衡器
  4. 未配置超时：始终设置连接和读取超时，防止请求挂起
  5. 忽视背压：设置队列上限，实现优雅降级
  6. 过度聚合：不要让网关承担过多工作（计算密集型转换）
  7. 监控不足：必须在网关层跟踪延迟、错误和吞吐量
  8. 未实施速率限制：如果不加保护，服务最终会不堪重负
  9. 所有操作都采用同步方式：对非关键操作使用异步模式
  10. 没有版本策略：破坏性变更会同时影响所有客户端

资源

评论

支持 Markdown