API Connectivity Manager 助力开发和运维部门高效协作

Rajesh Bavanantham of F5

NGINX 产品管理总监

2022-11-03

云原生应用由数十、数百甚至数千个将微服务连接在一起的 API 组成。这些服务和 API 共同塑造了云原生应用的弹性、可扩展性和灵活性。

如今，这些底层 API 和微服务通常由分散在全球各地的团队构建而成，他们需要在一定程度上独立自主地运作，以便及时将功能推向市场。

与此同时，平台运维团队负责确保企业应用和基础架构（包括其底层 API）的整体可靠性和安全防护。他们需要对 API 流量进行可视化并能够设置全局安全防护，以确保一致的安全性和遵从性，同时提供出色的 API 开发人员体验。

虽然这两个群体的目标可能会有冲突，但我们认为这并非不可避免。我们构建了 API Connectivity Manager（作为 F5 NGINX Management Suite 的一部分），既支持平台运维团队确保一切安全和平稳运行，同时助力 API 开发人员轻松构建和发布新功能。

创建新架构来支持 API 互联

作为下一代管理平面，API Connectivity Manager 旨在实现和扩展 NGINX Plus 作为 API 网关的能力。如果您过去使用过 NGINX，想必已对 NGINX 作为 API 网关的可扩展性、可靠性、灵活性和高性能非常熟悉。

在设计 API Connectivity Manager 时，我们开发了一个新架构来支持平台运维团队和开发人员更好地协同工作。该架构使用以下标准行业术语来表示其组件（其中一些与 NGINX 用户所熟悉的名称不同）：

Workspace – 可供单个业务部门或团队专门管理和使用的独立基础架构集合；通常包括多个环境
环境 – NGINX Plus 实例（集群）的逻辑集合，在应用生命周期的特定阶段（如开发、测试或生产）充当 API 网关或开发人员门户
API 网关代理集群 – NGINX API 网关的逻辑表示，用于对 NGINX Plus 实例进行分组并同步实例间的状态
API 代理 – API 已发布实例的表现形式，其中包括路由、版本控制及其他策略
策略 –用于定义 API 代理特定功能（如流量弹性、安全防护或服务质量）的全局或局部抽象

下图说明了组件在 Workspace 中的嵌套方式：

该逻辑层次结构可实现各种支持企业级 API 互联的重要用例。例如，Workspace 可以整合多种类型的基础架构（如公有云和本地），以便团队对二者进行访问，并为基础架构所有者提供这两种环境中 API 流量的可见性。

我们将在后续文章中更深入地介绍这些架构组件。现在，我们来看看 API Connectivity Manager 如何为负责 API 开发和交付的不同角色提供服务。

API Connectivity Manager 如何助力平台运维团队

平台运维团队负责构建和管理每个组织的基础架构生命周期。在该团队提供的平台上，开发人员可快速构建应用和服务，从而为客户和合作伙伴提供可靠服务。开发团队通常分散各地，在多个环境中工作，并向不同的业务线报告。在满足这些分散的团队和不同的环境所提出的各种需求的同时保持企业范围内的统一标准，是平台运维团队目前面临的最大挑战之一。

API Connectivity Manager 提供了创新的方法，即，使用 Workspace 作为逻辑边界来隔离团队及其操作。它还支持平台运维团队管理基础架构生命周期，而不会干扰团队构建和部署 API。API Connectivity Manager 采用一套默认全局策略，可为 NGINX Plus API 网关和开发人员门户提供基本的安全防护和配置。然后，平台运维团队可以配置补充全局策略，选择性地要求使用 mTLS、配置日志格式或统一代理请求头。

全局策略为部署在共享 API 网关集群中的 API 提供了统一性和一致性。API Connectivity Manager 还允许企业运行分散式数据平面集群，在物理上隔离每个团队或业务线的 API 部署。