我们让开发人员离开了门户网站：APIOps 和 IaC 如何重塑我们的 API 策略

介绍

企业 API 策略长期以来依赖于集中化的API管理门户，这些工具允许内部开发人员手动配置、发布和管理 API。虽然这些门户提供了可见性和控制，但它们常常成为操作瓶颈。随着 API 数量的增加，挑战也随之增加：配置不一致、手动部署错误、发布延迟和审计漏洞。

我们到达了这样一个点，我们的内部 API 生命周期严重依赖于这样一个门户——变得不可持续。开发人员必须登录门户以发布新 API，手动应用策略并配置路由。这不仅会带来摩擦，还会造成环境漂移和合规方面的重大风险。

为了解决这些问题，我们做出了根本性的改变：我们让开发人员离开了门户。我们不再使用 UI 来管理 API，而是采用了与基础设施即代码（IaC）相结合的 APIOps 实践和方法来自动化和简化整个 API 生命周期。

基础设施即代码（IaC）

现在，每个 API 都是完全通过自动化进行定义、版本控制和部署的。开发人员只与代码交互，而不是与门户交互。本文概述了我们如何实施这种转变，从中吸取的经验教训，以及使我们能够安全有效地进行扩展的关键架构和操作转换。

图 1：采用 APIOps 的 API 策略转变

手动 API 管理门户的问题

我们最初的模型涉及一个通过基于 Web 的门户管理的集中式 API 网关平台。开发人员会登录以配置代理、定义路由、附加策略（例如，认证、限流）和跨环境推广 API。表面上看，它似乎提供了灵活性和控制力。

但随着时间的推移，出现了几个痛点：

• 不一致的配置导致不同的团队在设置 API 时遵循自己的约定，进而导致不同的策略、命名方案和访问控制。

• 没有版本控制或可审计性意味着没有简单的方法来跟踪谁在何时做了哪些更改，因为大多数配置都是通过门户的 UI 完成的。

• 手动部署错误频发是由将 API 从一个环境提升到另一个环境需要分步进行门户操作引发的。小小的人为错误经常导致生产中的中断或误行为。

• 延迟发布和上线摩擦是由于 API 需要与平台工程师或运维人员手动协调的结果，从而造成瓶颈和延迟。

• 糟糕的安全姿态导致许多开发人员可以访问敏感的配置面板，执行最小权限和治理政策变得困难。

很明显，如果我们想要在保持速度、可靠性和合规性的同时扩展我们的 API 计划，就需要进行根本性的转变。手动的、基于 UI 的模型在团队之间引入了不一致性、操作风险和摩擦。为了应对这些挑战，我们采用了 APIOps 驱动的方法，将 API 视为代码。通过在 Git 仓库中管理 OpenAPI 定义、策略和配置，我们实现了版本控制、同行评审和通过 CI/CD 管道的自动化推广。像 GitHub Actions 和 Terraform 这样的工具使我们能够标准化部署，执行治理政策，并消除跨环境的手动错误。这种新模型提供了手动流程根本无法提供的一致性、可追溯性和可扩展性。

采用 APIOps 和基础设施即代码

我们从 DevOps 中寻找灵感。

正如 DevOps 使用管道、IaC 和版本控制消除了软件交付中的摩擦一样，我们意识到我们可以将类似的原则应用于 API。

这至使我们采用了 APIOps，即以完全自动化、管道驱动的方式来管理 API 的实践。

什么是 APIOps？

APIOps是将 DevOps 原则应用于整个 API 生命周期，从设计和测试到部署和可观测性。API 不是依赖于 UI 或基于工单的流程，而是在代码中定义并通过自动化管道管理。

基础设施即代码如何实现 APIOps

我们利用像Terraform和Helm这样的基础设施即代码（IaC）工具来定义和管理我们的基础设施组件，如 API 网关、DNS 记录和 TLS 证书，以及 API 本身的生命周期。通过这种方法，我们将自动化、一致性和可扩展性带入到了我们的 API 交付工作流中。

为什么选择 Terraform 和 Helm？

Terraform：云中立的基础设施配置

Terraform是一个声明式的 IaC 工具，它允许我们跨多个云提供商配置基础设施。我们使用 Terraform 来自动化设置 Azure API 管理（APIM）实例、虚拟网络、DNS 区域和 TLS 证书。这种模块化方法能在保持严格的版本控制的同时，跨环境重用配置逻辑。

Helm：简化的 Kubernetes 部署

Helm是一个 Kubernetes 的包管理器，它使用图表简化了应用程序和服务的部署。我们使用 Helm 部署 API 网关组件（如入口控制器和代理），管理微服务依赖关系，并协调服务配置。Helm 通过抽象 Kubernetes 清单能帮助增强集群间的一致性，并减少开发人员的认知负担，。

Terraform 和 Helm 的替代工具

虽然 Terraform 和 Helm 适合我们的用例，但根据组织需求和云架构，还有其他工具可供选择。Terraform 的替代品包括 Pulumi、AWS CloudFormation、Azure ARM Templates、Google Deployment Manager、AWS CDK、Ansible 和 Crossplane。Helm 的替代品包括 Kustomize、Jsonnet、Carvel、CDK8s 和 Tanka。

每种选择都需要在灵活性、复杂性和社区支持方面进行权衡。

通过 APIOps 管理 API 策略

手动方法（之前）

在早期模型中，API 策略（如速率限制、OAuth2 认证和 JWT 验证）是使用 Azure API Management 门户手动配置的。这些策略要求开发人员浏览用户界面，逐个应用策略，并确保跨环境的一致性，这是一个容易出错且不可扩展的过程。

代码驱动方法（现在）

有了 APIOps，策略被定义为代码，并在 Git 存储库中管理。更改要经过同行评审的拉取请求，并通过 CI/CD 管道部署。采用 APIOps 的结果是：

• 版本控制和可追溯性

• 升级前的自动验证

• 跨环境的一致性

速率限制策略的示例：

xml<rate-limit-by-key calls="100" renewal-period="60">  <key value="@(context.Subscription.Key)" /></rate-limit-by-key>

此策略将客户端限制为每分钟 100 个请求，一次定义并通过自动化统一应用。

JWT 验证策略示例：

xml<validate-jwt header-name="Authorization" require-scheme="Bearer">  <openid-config url="https://sts.windows.net/{tenant-id}/.well-known/openid-configuration" />  <audiences>    <audience>api://example-app</audience>  </audiences>  <issuers>    <issuer>https://sts.windows.net/{tenant-id}/</issuer>  </issuers></validate-jwt>

只有受信任的身份提供者发出的令牌才被接受，从而在网关层强制进行身份验证。

所有的定义都已提交到 Git，进行版本控制，并通过 CI/CD 管道进行部署，就像应用程序代码一样。通过使用 IaC 和 APIOps 原则对基础设施组件和 API 策略进行编码，我们建立了强大的技术基础。但仅实施工具是不够的。为了充分实现这些好处，我们需要重新考虑如何跨团队设计、审查和交付 API。

我们如何进行转变：关键变化

规范驱动的 API 设计

我们 APIOps 方法的基础是契约优先模型。每个 API 都以 OpenAPI 规范开始，通过拉取请求进行审查和版本控制。这个规范成为以下内容的唯一真实来源：

• 在 OpenAPI 契约中清晰定义的请求/响应格式，以标准化集成。

• 端点结构、使用的 URL 模式、HTTP 方法和参数模式都是预先记录的。

• 认证要求，指定哪些端点需要令牌作用域或自定义声明。

• 速率限制和配额，捕获预期的请求量和限流行为。

• 后端映射

CI 中的检查工具确保了规范在进入管道之前是有效和一致的。 

作为网关和策略的基础设施即代码

我们创建了一组可重用的 Terraform 模块来配置：

• API 网关实例配置使用具有区域或环境特定的 Azure API 管理（APIM）实例。

• 使用 DNS 作为代码，使用自定义域和子域设置的 DNS 记录。

• 通过密钥库和 Azure Front Door 自动配置和续订 TLS 证书。

• Kubernetes 命名空间和秘密使用 Helm 图来配置隔离的命名空间、服务帐户和 configmaps。

• 定义监控和警报（例如，Azure Monitor、DataDog）的仪表板、预警和诊断设置。

团队以最小的配置使用这些模块。环境、API 版本和认证类型等参数通过变量传入，而所有逻辑和治理规则保持集中管理。这种方法消除了开发人员了解或理解 API 网关平台内部工作的需求。他们只需要在代码中定义他们的意图。

用于生命周期管理的 CI/CD 管道

我们实现了 CI/CD 管道来处理整个 API 生命周期：

• 验证 API 规范

• 从模板生成代理配置

• 发布到 API 管理（APIM）

• 部署到非生产和生产环境

• 运行自动化冒烟测试

每个步骤都被记录并可审计。我们集成了生产部署的审批和合规性检查。因为所有变更都是 Git 驱动的，我们获得了完整的可审计性和可追溯性——谁改变了什么，何时，以及为什么——以及回滚任何部署的能力。

零开发人员访问 API 网关门户

最大胆但最具影响力的变化之一是撤销开发人员对 API 管理门户的访问。所有配置和部署操作必须通过 Git 和管道进行，这大大减少了配置错误的表面积，并使平台规则的执行保持一致。平台工程师保留了有限的访问权限，用于事故处理或紧急修复，但日常管理是不干涉的。

这种转变的影响是巨大的。在下一节中，我们将详细讨论验证了我们的 APIOps 转型的关键结果和好处。

结果和好处

提高安全性和治理

移除直接的门户访问意味着我们可以强制执行最小权限原则，并消除一次性更改。每个配置更改都是通过了同行评审的代码，受到静态分析和策略检查的约束。机密和密钥是通过保险库集成处理的，而不是复制粘贴到 UI 表单中。

跨环境的一致性

我们的 IaC 模板强制在开发、预发和生产环境中保持一致的配置。我们不再有环境漂移，同一个 API 在预发环境中部署的行为在生产环境中也是相同的。

更快的 API 交付

过去需要花费数天时间来协调开发人员、平台工程师和运维人员的工作，现在只需要数小时。开发人员可以提交一个 OpenAPI 规范和一些 Terraform 参数，API 在流水线运行中就可以通过预发环境上线。

降低运维负担

我们的平台团队不再需要手动注册 API，修复 UI 配置错误，或调试环境不匹配问题。相反，我们专注于改进模块和流水线，同时使每个团队受益。

完全可审计性

所有 API 的更改都通过 Git 历史记录进行跟踪。我们可以追溯到生产配置的确切提交和作者，简化了审计、事件响应和合规报告。

衡量影响

在采用 GitHub Actions 进行 APIOps 后，我们观察到整个 API 交付管道的显著改进。从基于门户的手动工作流程转变为自动化的代码驱动流程，帮助我们实现了更高的可靠性、一致性和速度。但为了验证这种转变，我们在实施前后跟踪了特定的指标：部署时间和人为错误的减少，部署的一致性，以及开发人员的生产力。

以前，跨环境推广 API 涉及多个手动步骤，导出定义、配置策略、验证路由和协调审批，通常每个发布周期需要四到六个小时。有了 CI/CD 自动化，整个流水线现在能在十五分钟内完成，包括规范验证、通过 Terraform 应用策略和冒烟测试。

手动部署在路由配置、认证规则和速率限制方面经常会出现错误。通过强制执行规范检查、模板化基础设施和拉取请求审查，由人为错误引起的生产问题减少了 80%以上。

可重用的 Terraform 模块和 Helm 图表确保了环境的统一供应。这种一致性消除了开发、测试和生产环境之间的差异，实现了可预测和可靠的部署。

以前，开发人员需要依赖平台工程师提供部署支持，并且必须要了解 API 管理门户的复杂性。有了 APIOps，开发人员现在只关注在代码中定义 API 行为和规范。内部调查和交付指标显示，开发人员的吞吐量提高了 40%，从而加快了新 API 的上线和市场推广速度。

这些改进表明，APIOps 不仅提高了技术性能，而且还促进了大规模的卓越运营和团队效率。

这些结果提供了明确的证据，表明我们的 APIOps 采用正在兑现其承诺。然而，这一旅程并非没有挑战和关键见解。在下一节中，我们将分享帮助塑造和完善我们方法的经验教训。

经验教训

模板和工具是关键

为了可扩展性，我们为团队创建了可重用、可组合的模块。这些模板抽象了复杂性，让开发人员专注于 API 行为，而不是网关机制。然而，构建和维护这些模块需要大量的前期投资。平台团队必须就标准达成一致，创建详细的文档，并建立治理模式以实现长期的可维护性。

验证和反馈循环很重要

静态分析工具，如 Spectral 和 OASLint，结合 CI 验证，对于及早发现错误至关重要。我们集成了模拟服务器测试，以便在部署前验证契约的有效性。虽然这些工具提高了质量并减少了生产问题，但团队需要时间来调整他们的工作流程，并完全采用左移测试和验证方法。

从一个团队开始，然后扩大规模

我们有意得从一个内部产品团队开始转型。他们的反馈帮助我们快速迭代，完善工具，并在扩展到其他团队之前识别可用性的差距。这种渐进式的推广建立了信任，并最大限度地减少了干扰。然后我们可以尽早展示切实的价值，这有助于在整个组织中获得更广泛的采用。

像对待产品一样对待 API

API 不仅仅是后端工具。它们需要清晰的所有权、文档、可观测性和生命周期管理。我们将自动化文档生成和监控集成到我们的 CI/CD 流水线中，使每个 API 在默认情况下都是可发现和可跟踪的。然而，从将 API 视为附带输出的文化转变到将它们视为产品，需要持续的倡导和赋能。

承认权衡

尽管 APIOps 的好处是显而易见的，但过渡过程中也伴随着挑战。许多开发人员最初在使用像 Terraform 和 Helm 这样的基础设施即代码工具时面临陡峭的学习曲线。习惯于基于 UI 配置的团队需要时间和培训才能适应以 Git 为驱动的工作流程。在不同的团队之间构建可重用的模块和标准化实践需要协调、耐心和强大的平台工程基础。这些权衡对于实现一致性、可扩展性和以开发者为中心的 API 平台至关重要。 

最后的想法

采用 GitHub Actions 的 APIOps 标志着 API 管理的重大转变，从手动更新转向拥抱基础设施即代码（IaC）原则。这种转变使得部署和维护 API 时实现了自动化、一致性和可靠性。通过将 APIOps 集成到 CI/CD 管道中，API 生命周期管理变得可扩展、可重复且高效，从而大大减少了更新所需的时间和努力。

这种转换不仅最大限度地减少了人为错误，还加快了部署周期，确保了环境的一致性，并加强了对企业标准的遵守。通过结合 Terraform 进行基础设施配置和 APIOps 进行 API 管理，系统变得更具弹性，且更能适应不断变化的业务需求。

在从手工流程到全自动 API 操作的过程中，APIOps 已被证明是现代 API 策略中的变革力量。随着系统的演变，对自动化和监控的持续投资将进一步加强 API 管理工作流程，提高可靠性和可扩展性。

APIOps 不仅仅是技术升级，它还使团队能够专注于创新而不是维护，推动卓越运营并提高生产力。随着 API 格局的发展，拥抱 APIOps 和自动化的组织将更好地应对未来的挑战，加速数字化转型，并在效率驱动的 API 开发中处于领先地位。

原文链接：

https://www.infoq.com/articles/apiops-iac-reshaped-api-strategy/