API Gateway：你的微服务不知道自己需要的保镖

I’m happy to translate the article for you, but I need the actual text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line, formatting, markdown, and any code blocks exactly as you specify.

什么是 API 网关

API 网关就像入口处的工作人员：

• 检查身份证件（身份验证/授权）
• 控制流量（速率限制，节流）
• 将请求路由到正确的服务（路由）
• 偶尔阻止有人试图攻击（安全，WAF）

在实践中，网关是外部请求的单一入口点。它位于你的服务前面，处理公共事务，这样每个服务就不必自行实现它们。

为什么使用网关？

没有网关时

• 客户端必须了解每个服务的 URL。
• 每个服务自行实现身份验证、限流、日志记录等。
• 更改服务端点会迫使客户端进行修改。

使用网关时

• 一站式 URL —— 客户端只调用一个入口。
• 集中式策略（安全、限流、可观测性）。
• 后端服务可以演进而不破坏客户端。
• 在边缘统一进行身份验证/授权 → 减少重复和不一致。
• 移动端、网页和第三方客户端都通过同一网关。
• 缓存、压缩、请求整形和响应聚合可减少调用次数，平衡后端负载。
• 为指标、日志、追踪关联和全局策略提供统一位置。
• 更轻松的版本管理（/v1、/v2），无需让每个服务都携带旧版负担。

缺点与权衡

• 新增组件 → 另一个潜在的故障点。
• 如果网关宕机，整个 API 表面不可用。
• 它会引入额外的一跳，增加延迟（通常可以接受）。
• 需要良好的配置；如果插件过多，会变成“圣诞树”般的功能堆砌。
• 托管网关需要付费；自托管网关则需要工程投入。
• 某些方案会让你锁定在特定的云生态系统中。

流量类型与放置

网关可以与服务网格数据平面共存；在大型系统中它们通常会一起使用。

流行的 API 网关解决方案

• AWS API Gateway – 在无服务器设置中常见（API Gateway → Lambda）。
• Kong – 在 Kubernetes 和微服务中流行；插件驱动，极具可扩展性。
• NGINX – 可配置为网关/反向代理，提供细粒度控制。
• Traefik – 云原生路由器，具备自动发现功能。

根据您的环境、治理需求以及您希望承担的平台工程工作量进行选择。

何时使用网关

• 多个服务和多种客户端类型。
• 需要集中式安全、限流和监控。
• 希望在内部服务演进的同时，保持对外 API 的稳定性。

当你可能会跳过它

• 目前只有单个服务的微小系统。
• 还不需要跨切政策。
• 你不想运营额外的基础设施。

类比回顾

关键考虑因素

• 高可用性 – 多实例、多可用区部署。
• 可观测性 – 指标、日志、追踪。
• 安全控制 – 认证、mTLS/TLS、可选的 WAF 集成。
• 速率限制/配额 – 保护后端资源。
• 部署策略 – 蓝绿或金丝雀用于配置更改。
• 明确所有权 – 必须有人维护网关。

结论

API 网关并非魔法；它们集中责任。做得好时，它们简化了微服务环境中的路由、安全和可观测性。做得差时，它们会成为昂贵的瓶颈，并且是出现问题时大家首先指责的地方。

如果你在构建微服务，最终可能还是会有一个网关——不如有意识地做好它。

想要后续内容吗？我可以写第 2 部分，主题为“API 网关 vs. API 管理”或“Kubernetes：Ingress vs. Gateway API vs. Service Mesh”，并提供真实的部署模式。