API Connectivity Manager助力开发与运维团队更高效地协作

NGINX | 2022年11月03日

云原生应用由数十、数百甚至数千个API组成，这些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用户熟悉的名称不同）：

工作区：一组相互隔离的基础设施，供单个业务部门或团队专门管理和使用；通常包含多个环境
环境：由一组逻辑归类的NGINX Plus实例（集群）组成，在应用生命周期的特定阶段（如开发、测试或生产阶段）充当API网关或开发者门户
API网关代理集群：NGINX API网关的逻辑表示形式，用于对NGINX Plus实例进行分组，并在这些实例之间同步状态
API Proxy：表示API的已发布实例，包括路由、版本控制及其他策略
策略：一种全局或局部抽象，用于定义API代理的特定功能，例如流量韧性、安全性或服务质量

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

API Connectivity Manager管理对象嵌套关系图。从外到内依次为：Workspace、Environment、API Gateway Proxy Cluster、API Proxy、Policies。

这种逻辑层次结构支持多种重要用例，可实现企业范围内的API连接。例如，Workspace可以整合多种类型的基础设施（如公有云和本地部署基础设施），让团队能够访问这两类基础设施，同时让基础设施所有者能够查看这两种环境中的API流量。

我们将在后续文章中深入介绍这些架构组件。现在，先来看看API Connectivity Manager如何满足参与API开发和交付的不同角色的需求。

面向平台运维的API Connectivity Manager

平台运维团队负责为各组织构建和管理基础设施的整个生命周期。他们提供平台，供开发人员构建面向客户和合作伙伴的应用及服务。开发团队通常分散在不同地点，跨多个环境开展工作，并向不同的业务部门汇报。既要满足这些分散团队和环境的需求，又要维持企业级统一标准，是当今平台运维团队面临的主要挑战之一。

API Connectivity Manager以Workspaces作为逻辑边界，提供创新方式来隔离各团队及其运维活动。它还支持平台运维团队管理基础设施生命周期，同时不干扰负责构建和部署API的团队。API Connectivity Manager内置一组默认全局策略，可为NGINX Plus API网关和开发者门户提供基本安全保护和配置。平台运维团队随后可以配置补充全局策略，以便根据需要强制使用mTLS、配置日志格式或统一代理标头。

全局策略可对部署在共享API网关集群中的API实施统一规范，确保一致性。API Connectivity Manager还支持组织运行分散式数据平面集群，从物理层面隔离各团队或业务线部署API的位置。