API 之旅的三个阶段

产品营销经理

2023-08-08

本文转载自 The New Stack。

近 20 年来，每家使用软件的企业都逐步踏上了 API 采用之旅。这条路径已经成为应用开发领域的大势所趋，API 也已是技术交互和交易的主要方式。

正如我在最近的一篇文章中所述，谈起 API 采用挑战，很多人就急着介绍其单体式、一体化平台，殊不知这种大而无当的技术方案早已过时。受云原生应用发展趋势的影响，在安全防护“左移”的推动下，开发人员、网站可靠性工程师（SRE）、DevOps 和平台工程团队已与这种自上而下的 API 解决方案渐行渐远。

云原生技术人员更倾向于选择构建适合自己需求的 API 堆栈。这些堆栈结合使用开源、专有和内部产品来打造一套可持续且可扩展的解决方案集，用于管理日益增长的 API，同时加速 API 开发进程。

企业的 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 等语言。