如今的企业通常由分散在全球各地的团队组成，这些团队往往在多个部署环境中构建和部署 API 和微服务。F5 的《应用策略现状报告》显示，81% 的企业跨三个或更多环境运行，包括公有云、私有云、本地和边缘节点等。
对于负责维护这些复杂的多云架构的平台运营团队而言，确保其可靠性和安全性是一个重大挑战。F5 报告中的受访软件工程负责人表示，在平台运营团队面临的多云挑战中，可视性 (45%) 和一致的安全性 (44%) 排在前两位。
随着当今 API 和微服务的数量不断增加，API 治理正迅速成为规划和实施企业级 API 策略的最重要议题之一。那么，什么是 API 治理，为何它对 API 策略至关重要呢？
什么是 API 治理？
从根本上讲，API 治理包括创建策略以及运行检查和验证，以确保 API 具有可发现性、可靠性、可观测性和安全性。它有助于您了解应用背后复杂系统和业务流程的状态，以便您把握 API 基础架构的未来演进。
为何需要 API 治理？
API 治理的战略意义不可小觑：它是实现企业整体 API 策略的手段。如果没有实施恰当的治理，您将永远无法在 API 的设计、运营和产品化方面实现一致性。
如果实施不当，治理便会徒增一些繁琐的需求，给团队拖后腿。但如果实施得当，API 治理能够减少工作量、简化审批，并支持企业中的不同团队独立运作，同时实现 API 策略的总体目标。
您需要治理哪些类型的 API？
在执行 API 策略的过程中，制定有效的 API 治理计划首先要确定生产环境中的 API 类型，以及管理它们所需的工具、策略和指导。如今，大多数企业团队都在使用四种主要的 API 类型：
- 外部 API — 提供给外部使用者和开发人员，以实现与数据和功能的自助集成
- 内部 API — 用于连接内部应用和微服务，仅供企业的开发人员使用
- 合作伙伴 API — 与合作伙伴企业的开发人员共享数据或应用的访问权限，以深化战略业务关系
- 第三方 API — 由第三方厂商作为服务使用，通常用于处理支付或对访问数据、应用提供支持
企业中每种类型的 API 都必须实施治理，以确保其安全、可靠，并可供需要访问它的团队和用户进行访问。
您可以使用哪些 API 治理模型？
定义和应用 API 治理的方法有很多。NGINX 客户通常采用以下两种模型之一：
- 集中式 — 由一个中央团队进行审查并审批变更；该团队可能会成为阻碍进展的瓶颈，取决于运营规模
- 分散式 — 各个团队拥有构建和管理 API 的自主权；这可以缩短上市时间，但可能影响整体安全性和可靠性
然而，随着各公司快速推进 API 优先策略，生产环境中的 API 数量不断增加，这两种模型都遇到了问题。集中式模型通常尝试采用一刀切的方法，这种方法需要进行各种审查和签核。这会拖慢开发团队的工作速度，并产生割裂 — 而且，开发人员有时甚至会设法绕过规定（可怕的“影子 IT”）。
另一种模型 — 分散式治理最初对 API 开发人员很有效，但随着时间的推移，复杂性会增加。除非部署 API 的不同团队之间经常沟通，否则 API 之间的整体体验就会不一致：每个 API 的设计和功能各不相同，版本变更会导致服务之间发生中断，而且不同团队和服务实施的安全防护参差不一。对于构建 API 的团队来说，额外的工作和复杂性最终会拖慢开发速度，就像集中式模型一样。
云原生应用依赖各个微服务的 API 来相互通信，并将响应发送回请求源。随着公司继续采用微服务来支持灵活性和敏捷性，API 泛滥方兴未艾。因而，您需要采用不同的方法在这些不断变化的复杂环境中治理 API。
使用自适应治理来为 API 开发人员赋能
幸运的是，我们还有更好的方法。自适应治理提供了替代模型，该模型可为 API 开发人员赋能，同时为平台运营团队提供所需的控制，有助于确保整个企业中的 API 的可靠性和安全性。
自适应治理的核心是平衡“集中控制（一致性需求）”和“自主性（制定本地决策的能力）”，以实现整个企业的敏捷性。实际上，自适应治理模型在团队之间分拆和分配决策权。
平台运营团队管理共享的基础架构（多种 API 网关和多个开发人员门户）并设置全局策略，以确保 API 之间的一致性。而构建 API 的团队则作为其服务或业务线的专家——他们有权为其 API 设置和应用本地策略（基于角色的访问控制 (RBAC)、服务的速率限制等），以满足各自业务环境的要求。
自适应治理允许每个团队或业务线定义其工作流程并平衡所需的控制级别，同时可以使用企业的共享基础架构。
使用 NGINX 对您的 API 实施自适应治理
当您开始规划和实施 API 策略时，请遵循以下最佳实践，在企业中实现自适应治理：
- 提供共享的基础架构 — 支持团队轻松访问 API 网关和开发人员门户，以便发布 API 代理和文档
- 为团队提供代理 — 帮助团队在共享工作区内添加并管理其 API 的生命周期
- 平衡全局策略与本地控制 — 在共享基础架构中设置全局策略，同时为团队提供细粒度的服务控制
接下来我们看看如何使用 F5 NGINX Management Suite 中的 API Connectivity Manager 完成相关用例。
提供共享基础架构
整个企业的团队都在构建 API，他们需要在微服务中添加类似的功能：身份验证和授权、mTLS 加密等等，而且还需向其 API 使用者（内部团队、业务合作伙伴或外部开发人员）提供文档和版本控制。
平台运营团队可提供对共享基础架构的访问，而非要求团队构建自己的解决方案。与 API Connectivity Manager 中的所有操作一样，您可以通过 UI 或完全声明式 REST API 在短短几分钟内完成设置，从而将 API Connectivity Manager 集成到 CI/CD 流水线中。在本文中，我们使用 UI 来说明一些常见的工作流程。
API Connectivity Manager 支持两种类型的工作区：基础架构和服务。平台运营团队使用基础架构工作区，以 API 网关集群和开发人员门户集群的形式添加并管理共享基础架构。API 开发人员使用服务工作区来发布并管理 API 和文档。
如需设置共享基础架构，首先要添加一个基础架构工作区。点击左侧导航栏中的 Infrastructure，然后点击选项卡右上角的 + Add 按钮。为工作区命名（此处为 team-sentence — 一个虚构团队正在构建简单的 “Hello, World!”API）。
接下来，向工作区添加一个环境。环境包含 API 网关集群和开发人员门户集群。点击您的工作区名称，然后点击 Actions（操作）列的 … 图标，从下拉菜单中选择 Add（添加）。
Create Environment（创建环境）面板打开，如图 2 所示。填写 Name（名称）字段（选填 Description（描述），选择环境类型（生产或非生产），然后点击 + Add 按钮，添加所要添加的基础架构（API 网关集群、开发人员门户集群或二者）。点击 Create （创建）按钮，完成环境设置。有关完整说明，请参见 API Connectivity Manager 文档。
为团队提供代理
在确保团队能够获得所需工具的情况下，可以根据业务线、地理区域或其他逻辑边界为团队提供逻辑分离。访问共享基础架构并不意味着团队须为全局层面活动而操心。相反，您希望让他们专注于定义自己的需求，绘制路线图，并构建其微服务。
平台运营团队可为各团队提供服务工作区，以帮助他们组织并运行其服务和文档。这会创建逻辑边界，并为开发服务提供不同的环境（例如开发、测试和生产环境）。这个过程类似于我们在上一节中创建基础架构工作区的过程。
首先，点击左侧导航栏中的 Services（服务），然后点击该选项卡右上角的 + Add 按钮。为您的工作区命名（此处为 api-sentence，用于 “Hello, World” 服务），并可选填描述和联系信息。
此时，您可以邀请 API 开发人员在您为他们创建的工作区中发布代理和文档。关于发布 API 代理和文档的完整说明，请参见 API Connectivity Manager 文档。
平衡全局策略和本地控制
自适应治理需要在执行全局策略和赋能团队决策（以提高敏捷性）之间取得平衡。您需要建立明确的职责分工，方法是定义平台运营团队执行的全局设置，并设置“护栏”来定义 API 开发人员使用的工具及其可制定的决策。
API Connectivity Manager 集成了全局策略（应用于共享基础架构）和在 API 代理层面管理的细粒度控制。
API Connectivity Manager 中提供的全局策略包括：
- 错误响应格式 — 自定义 API 网关的错误代码和响应结构
- 日志格式 — 启用访问日志记录并自定义日志条目的格式
- OpenID Connect — 使用 OpenID Connect 策略保护对 API 的访问
- 响应标头 — 在响应中添加或删除标头
- 请求字体大小 — 限制传入 API 有效载荷的大小
- 入站 TLS — 为与 API 客户端的 TLS 连接设置策略
- 后端 TLS — 使用 TLS 保护与后端服务的连接
API Connectivity Manager 中提供的 API 代理策略包括：
- 允许的 HTTP 方法 — 定义可以使用的请求方法（
GET、POST、PUT等） - 访问控制 — 使用不同的身份验证和授权技术（API 密钥、HTTP 基本身份验证、JSON Web 令牌）保护对 API 的访问
- 后台健康检查 — 运行持续健康检查，以避免对后端服务的请求失败
- CORS — 允许客户端从外部域受控地访问资源
- 缓存 — 使用缓存策略提高 API 代理性能
- 代理请求标头 — 将特定标头传递给后端服务
- 速率限制 — 限制传入请求并保护 API 工作负载
在下面的示例中，我们将使用 UI 定义一个策略，以保护 API 网关代理和后端服务之间的通信。
点击左侧导航栏中的 Infrastructure（基础架构）。点击包含要编辑的 API 网关集群的环境名称后，该选项卡将显示该环境中的 API 网关集群和开发人员门户集群。
在要应用策略的 API 网关集群的行中，点击 Actions 列中的 … 图标，然后从下拉菜单中选择 Edit Advanced Configuration（编辑高级配置）。点击左列中的 Global Policies（全局策略），显示您可配置的所有全局策略的列表。
如需应用 TLS 后端策略，点击该行右侧的 … 图标，然后从下拉菜单中选择 Add Policy（添加策略）。填写请求的信息，上传证书并点击 Add。然后点击 Save and Submit （保存并提交）按钮。现在，API 网关集群和后端服务之间的流量将通过 TLS 进行保护。有关完整说明，请参见 API Connectivity Manager 文档。
总结
规划和实施 API 治理是确保 API 策略成功的关键步骤。通过支持分布式模型，并依靠自适应治理来满足不同团队和 API 的独特要求，您可在不影响速度和敏捷性的情况下扩展并应用统一的治理，从而提高 API 和云原生环境的效率。
立即免费试用
立即开启 Management Suite 30 天免费试用，包括 API Connectivity Manager、NGINX Plus（作为 API 网关）及 NGINX App Protect（可保护 API）。
