API 之旅的三个阶段

阶段 1：起步

在第一个阶段，企业刚刚开始涉足 API 领域。在大多数情况下，技术团队以临时使用的方式用 API 来连接外部系统，以引入更高效的外部服务，或者满足合作伙伴和客户希望通过 API 连接和交换信息的需求。

API 采用第一阶段的特点是 API 实践不一致，有时甚至杂乱无章，企业可能只是应需采用 API。在这一阶段，工程师的工作重点是处理南北向 API 流量、建立连接和实现外部系统之间的通信。设计重点是将 API 与现有系统（比如第三方服务或外部合作伙伴）相集成，以促进数据交换并实现跨不同平台的功能。通常，架构师尚未部署微服务或 Kubernetes，而且可能没有使用完全分布式系统。

在这个不成熟的阶段，工程师通常没有标准化的 API 设计原则——不同的团队可能在没有决策协调的情况下构建自己的基础设施（部署网关、基本安全防护等）。这往往会导致临时抱佛脚，只为满足即时的集成需求，却造成了长期的技术债务。

阶段 2：设定发展路线

在迈向完整 API 堆栈的进程中，API 采用的第二个阶段是制定企业级 API 策略。通常，这意味着公司已经认识到 API 将成为其架构的重要组成部分，于是在规划和资源方面，API 开始像应用开发、数据库、网络和安全防护一样被严肃对待。此时，利益相关者（开发人员、DevOps、SRE、平台运维以及安全和网络团队）认识到，需要在整个企业内采用结构化、协调一致的 API 管理方法。

在这一阶段，南北向 API 是应用堆栈的重要组成部分，同时东西向 API 越来越受到关注。公司可能会采用一些（或许多）云原生应用的构建方式，包括微服务或无服务器架构并有可能采用分布式容器编排系统。随着公司不断朝着 API 优先架构的方向迈进，标准化需求悄然产生。一个日益受到关注的问题是如何管理内部 API，并为开发人员提供工具，从而以一种松散耦合的方式设计、构建、部署、管理和保护内部 API 。

微服务通常是这一阶段的催化剂。团队将单体应用分解成可独立开发、部署和扩展的小型应用，并通过 API 进行链接和管理这些微服务。这种分解可提高系统的可维护性、可扩展性和敏捷性。在这一阶段，工程师专注于根据企业总体架构目标设计 API，提高可重用性，并对 API 开发、文档编制、安全防护和版本控制实施标准化实践。

阶段 3：腾飞

此时，企业已经有了一套日渐成熟的 API 策略和方法。利益相关者已经从承认 API 优先的重要性转变为将 API 优先作为首要运维任务。在这一阶段，工程师们采用 API 优先的方法来开发新应用或升级现有应用。API 被设计和开发为应用和架构规划流程的一部分，以便与底层系统、基础设施和后端或数据应用紧密集成。该方法强调了定义明确、记录完善且可重用的 API 的重要性，旨在将这些 API 部署为可扩展、可互操作系统的基础。

在第三个阶段，团队要为各种 API（包括内部、合作伙伴、第三方和（如适用）公共 API）制定全面的方法和治理实践。这些治理实践可确保整个企业的 API 设计、安全防护、版本控制和生命周期管理保持一致，从而实现与外部利益相关者的高效协作和紧密集成。理想情况下，得益于 API 创建的基线模式和针对不同 API 类别设置的策略类型，这在很大程度上这部分工作可以实现自动化。

由于 API 堆栈具有灵活性和松散耦合性，因此在这一阶段，平台运维团队应评估可帮助企业改进 API 系统的新技术，例如 GraphQL 等新格式、用于自动更新文档的生成式 AI 工具，以及可生成 API 友好代码的即购即用型 Denon 等语言。

API 技术栈从成熟走向敏捷

API 项目进入第三个阶段后，通常已积蓄了巨大的发展惯性。API 不仅是关键任务组件，而且还是企业的基础技术架构。开发人员、DevOps、SRE、安全和网络团队都已成为利益相关者，并参与其中。平台运维团队现在将 API 视为其职责的重要组成部分，以及持续取得成功的关键因素。

新 API 堆栈的优点在于支持轻松更换组件或修改方法，而不会造成重大中断或停机。所有云原生的敏捷性实践都可应用于 API，包括 A/B 部署、蓝绿部署和灰度部署。到达第三个阶段后，您将具备足够的敏捷性，可应对未来 API 旅程中的任何波折。