点击查看目录
每个 API 都需要一个前门，一个迎接请求与响应的门户。这个“门”不仅要坚固，能承受高流量的压力，最好还能过滤掉“蚊虫”——也就是潜在的威胁行为者和 DDoS 攻击。同时，一些额外的功能可以让整个体验更加愉快。
API 网关便是你 API 的前门，它不仅仅负责流量的调度，还包括执行安全策略、优化性能等任务。然而，涉及大规模基础设施的决策总是难以把握，特别是当你已经开始构建新的 API，可能很难判断是否在正确的轨道上前行。
受云原生计算基金会（CNCF）的 云原生成熟度模型 启发，我试图帮助你从全局视角出发，客观评估 API 前门的当前状态，并了解接下来的优化方向。
基础阶段：打好地基
在这个阶段，你正处于 API 网关的 MVP 或预生产阶段，验证工具并分配各项责任，以便正式上线。
- 决定 API 网关基础架构的基本形态（如云托管或本地部署），选择独立代理或通过 SDK 嵌入 API 网关功能，或者利用 Kubernetes 原生特性如 Gateway API。
- 实施安全基本策略，从基本认证开始，逐步升级到 JSON Web Tokens（JWT）。
- 设定速率限制和 IP 限制以防滥用。
- 实施负载均衡，探索 DDoS 保护选项。
- 利用 API 网关的功能来根据流量条件执行特定操作。
- 制定 API 管理的基础政策，即便当前还未具备技术条件或专业人员来执行。
在构建过程中，请随时记录每项决策和实施如何影响开发周期。API 开发人员是否仍然能自由地构建？DevOps、基础设施和平台工程师是否拥有适当的工具来管理此平台？
完成这些步骤后，你将拥有一个具备基本功能的 API 网关，能够顺利代理请求并具备初步的安全保护。
运行阶段：投入生产
当你的 MVP 完成测试，移至生产环境时，重点是集成、效率和为实时环境的挑战做好准备。
- 将 API 网关的配置和部署集成至 CI/CD 流程，进行安全和治理规则的集成测试。
- 以代码形式管理所有 API 相关配置，以便进行版本控制、代码审查和质量保证。
- 开始在多区域、多云和私有云环境中测试 API 网关，为未来扩展做准备。
- 将 API 网关的安全、测试和操作任务提前至开发周期中，让 API 开发人员有更多控制权。
- 为 API 的部署和操作编写详细的文档。
无论你处于此阶段的哪一步，都将受益于 API 网关对生产负载的自动化管理，并可利用早期的观测数据微调行为。如果效果不尽如人意，可能需要重新评估。
扩展阶段：准备增长
此时，API 网关不再只是一个入口，而是你管理服务、区域、用户和高负载的核心工具。
- 利用多区域和多云部署的经验提升性能和冗余性。
- 为 API 网关和 API 服务构建或采用自动化故障切换机制。
- 收集更多可观测数据，以便将流量、错误、请求和响应的趋势转化为可执行的数据。
- 基于实际使用情况制定和实施高级流量策略，如精细的速率限制或细粒度访问控制。
- 实施版本和弃用流程。
下一个阶段？API 网关将不仅仅是一个工具，而是你团队快速、敏捷部署的核心支柱。
改善阶段：强化安全与治理
这个阶段的重点在于精炼。你的 API 网关足够灵活和可扩展，但要保持持续发展，还需在不影响开发人员效率的情况下增加控制措施。
- 采用允许 DevOps 和基础设施工程师集中管理安全的工具和工作流，同时让开发人员可以高效工作。Kubernetes Gateway API 是一个不错的例子，它基于角色进行配置。
- 分析并优化 API 基础设施的整体成本。
- 实现实时监控，以便向 API 的主要用户提供服务水平协议（SLA）。
- 为开发人员提供自助开发环境，以测试 API 或网关的复杂场景或重大变更。
- 精简 API 网关的工具和供应商。
- 考虑使用 GitOps 等持续部署方式。
你几乎已经达成目标，但仍需不断努力。
适应阶段：回顾、重建与再创新
此时，你不仅要应对 API 网关的现状，还要前瞻性地调整策略，保持领先地位。基于丰富的观测数据不断改进，同时还有更多工作要做。
- 通过 API 网关测试套件实现质量控制，以减少缺陷和事故。
- 将所有 API 发布和 API 网关配置更改迁移至 GitOps 工作流。
- 启用蓝绿部署或金丝雀发布等高级部署技术。
- 提供工具和培训，让 API 开发人员从开发的早期阶段便能实现和测试高级安全功能。
- 创建自助环境，使开发人员能够在既定的安全范围内配置和管理 API 网关。
如果你已完成清单中的所有事项，恭喜你！
TheNewStack