API 管理失效：基于内部开发平台的软件生命周期构建

当组织希望通过其 IT 团队实现集成、创新和数字体验时，通常会构建 API 并利用全生命周期的 API 管理系统来公开这些 API。历史上，这些 API 管理系统提供了以下工具：

• 定义 API（如 Swagger、OpenAPI Spec、RAML）
• API 测试
• API 脚手架和实施
• 配额和使用策略/计划的规格
• 文档
• API 门户

这些 API 管理系统通常作为完全集成的堆栈提供，拥有精美的 UI、基于角色的访问控制和按钮机制，实现生命周期管理功能。

尽管如此，组织在对其应用程序和 API 交付引擎进行现代化改造时，仍面临一些现实挑战。API 管理平台并非存在于真空中。DevOps 理念影响了组织结构、自动化和自助服务。任何 API 管理系统都必须适应通常为多语言、多平台和多云的现代开发环境。此外，该基础架构还必须与基于 Git 的部署工作流（GitOps）原生兼容，包括为 CI/CD 构建的系统。

避免孤岛效应（YAS）

尽管衡量开发人员的工作效率可能较为困难，但一些有用的指标包括：

• 代码更改在生产环境中的提前期
• 每周部署到生产环境的次数

传统上，开发人员编写代码、创建服务、构建 API，然后将这些交给运营部门进行部署和管理。开发、基础设施、安全和网络团队之间的孤岛往往会导致复杂的同步问题、交接和大量的等待，从而减慢代码更改和生产部署的速度。

图 1：团队之间孤立的交接导致生产环境交付速度变慢

大型整体式软件系统可能通过在每个团队的孤岛中建立自己的专属系统来进一步加剧这一问题。这些系统通常有自己的专用 UI，需要特定的技能或权限才能操作，且由特定团队管理。如果需要从这些系统中获取某些功能，通常需要提交请求，通知相关团队进行相应的更改。

在实践中，传统的全生命周期 API 管理系统通过强制用户使用一组全有或全无的工具来定义、实施、测试和公开 API，从而造成孤岛效应，即使这些工具与开发团队所需的工具不一致。这些系统往往难以自动化且与软件交付系统的其他部分集成困难，通常由专门的 API 管理团队负责配置和部署。这种技术和组织上的集中化会造成瓶颈，进而减缓现代 DevOps 驱动型组织的交付速度。

自动化优先，远离点击式界面

在现代 DevOps 实践中，自动化是用来消除手动或重复性任务的重要原则。传统的全生命周期 API 管理系统虽提供基于角色的 UI 和工具，但这样的系统常常需要用户在多个系统间切换来执行不同的任务，如运行测试、管理 API 和执行部署。

图 2：我们应该减少多个手动点击式 UI，以支持自动化

理想的情况是，许多这些步骤都能自动执行，使开发人员能够通过一个单一的自助式界面处理与软件开发和部署相关的所有事务。所有功能，包括传统 API 管理及其“完整生命周期”功能，都应是可自动化的。然而，由于许多现代 API 管理功能固定在专有界面中，实现自动化不仅具有挑战性，而且通常很脆弱。

API 生命周期即软件开发生命周期

API 生命周期通常包括设计、实现、测试、控制和使用。这些步骤听起来是否很熟悉？因为它们正是软件开发过程中必经的步骤。当开发人员创建 API 时，他们也在利用软件实现这些功能。因此，API 生命周期实际上就是软件开发生命周期。将 API 的生命周期与其他软件开发实践分开对待，往往会导致不一致、碎片化和摩擦。

例如，在创建一个 API 时，可能需要对其进行开发、测试，并在需要停用时通知用户。对内部服务、库和其他系统组件也需要提供类似的功能。尽管可能存在一些细微的差别，但这些过程是否真的应该是完全独立的？这些是否需要完全不同的工具集？试图使用特定于 API 管理的工具来模拟软件开发生命周期中的已知步骤，往往会带来采纳、治理和分叉等问题。

使用内部开发人员平台

随着组织通过将更多责任和控制权交给开发人员来提高工作效率，出现了负责构建支持自助服务的工作流程和工具链的平台团队。这些工作流程形成了开发人员可以轻松遵循的“黄金路径”，并自动执行新项目引导、软件记录、访问/安全策略执行以及部署控制等任务。

这种以开发人员为中心的自助服务平台被称为内部开发人员平台（IDP），旨在满足服务整个生命周期的运营需求。虽然许多团队已经构建了自己的平台，但一些优秀的开源框架，如 Backstage，对构建 IDP 非常有帮助。

平台工程团队通常具有很大的灵活性，可以为开发人员选择支持多种语言和框架的最佳工具。这些工具可以通过自动化进行组合，并且不依赖于专有供应商的 UI。平台工程团队也常常围绕容器技术构建平台，这些技术可以跨多个集群使用，并扩展到本地部署和公有云。这些 IDP 不受特定供应商的限制，无论是公共云还是供应商特定的技术。

例如，常见的情况是，一个组织购买了一个全生命周期的 API 管理解决方案，但发现其现代化工作以容器和 Kubernetes、GitOps 和 CI/CD 为中心。他们发现尽管 API 管理供应商提供了强大的 API 设计工具，但其运行时执行、API 门户和分析功能往往滞后、过时，且无法与 GitOps 和容器平台的其余部分自动化集成。结果，他们通常希望采用基于更现代的开源代理（如 Envoy Proxy）的 API 网关技术，但被当前供应商的过时技术所束缚。

相反，这些组织应选择使用更新的代理技术，选用对开发人员更友好的 API 测试工具，将 API 分析与现有的流和分析工作集成，并利用像 Backstage 这样的工具将所有这些功能整合在一起。这样可以减少供应商产品中心的孤岛，利用最优秀的工具，并以保持治理和规定护栏的方式自动化这些工具，从而支持复杂的部署策略，如多集群、混合和多云部署。

结论

API 管理将继续是软件开发的重要组成部分，但这并非在孤立的环境中进行。传统的大型全生命周期 API 管理堆栈已经过时，无法满足现代开发实践的需求，并且在尝试打破孤岛时可能会导致新的孤岛。选择合适的 API 开发和策略管理工具，可以帮助构建一个强大的软件开发平台（IDP），从而提高开发效率，减少供应商锁定，并支持在本地和各种公有云上的容器和云基础设施中部署 API 和服务。

原文链接：全生命周期 API 管理已死：使用内部开发人员平台按照您的软件开发生命周期构建 API – DZone