自适应治理赋予API开发人员所需的自主权

NGINX | 2022年11月10日

如今,企业通常由分布在全球各地的团队组成,这些团队往往跨多个部署环境构建和部署API及微服务。根据F5的《应用策略现状报告》,81%的组织在3个或更多环境中运营,涵盖公有云、私有云、本地环境和边缘环境。

对于负责维护复杂多云架构的平台运维团队而言,确保这些架构的可靠性和安全性是一项重大挑战。根据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进行治理,以确保其安全可靠,并可供需要访问的团队和用户使用。

可以使用哪些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策略时,请遵循以下最佳实践,在组织内实施自适应治理:

下面来看看如何使用F5 NGINX Management Suite中的API Connectivity Manager实现这些用例。

提供共享基础设施

贵组织内的各个团队都在构建API,并且需要在微服务中加入类似的功能,包括身份验证和授权、mTLS加密等。他们还需要向API使用者提供文档和版本控制功能,无论这些使用者是内部团队、业务合作伙伴还是外部开发者。

平台运维团队可以提供共享基础设施的访问权限,无需各团队自行构建解决方案。与API Connectivity Manager中的所有操作一样,只需几分钟即可通过UI或完全声明式REST API完成设置。借助该API,还可将API Connectivity Manager集成到CI/CD流水线中。本文将通过UI演示一些常见工作流。

API Connectivity Manager支持两种类型的工作区:基础设施工作区和服务工作区。平台运维团队使用基础设施工作区,以API网关集群和开发者门户集群的形式接入和管理共享基础设施。API开发者使用服务工作区发布和管理API及文档。

要设置共享基础设施,请先添加一个基础设施工作区。单击左侧导航栏中的“基础设施”,然后单击选项卡右上角的“+ 添加”按钮。为工作区命名(此处为team-sentence,代表一个正在构建简单“Hello, World!” API的虚构团队)。

图1:添加基础设施工作区

接下来,将环境添加到工作区。环境包含API网关集群和开发者门户集群。单击工作区名称,然后单击“…”图标(位于“操作”列中);从下拉菜单中选择“添加”。

如图2所示,创建环境面板随即打开。填写名称字段(也可选择填写描述字段),选择环境类型(生产或非生产),然后针对要添加的基础设施(API网关集群、开发者门户集群或两者)单击“+ 添加”按钮。单击“创建”按钮,完成环境设置。有关完整说明,请参阅API Connectivity Manager文档。

图2:创建环境并接入基础设施

赋予团队自主权

按业务线、地理区域或其他逻辑边界对团队进行逻辑隔离是合理的,前提是这不会妨碍团队使用取得成功所需的工具。使用共享基础设施不应意味着团队还要操心全局层面的事务。相反,应让团队专注于明确自身需求、制定路线图和构建微服务。

为帮助团队有序开展工作,平台运维团队可以提供服务工作区,供各团队组织和运营服务及文档。这些工作区可建立逻辑边界,并提供对不同服务开发环境(例如开发、测试和生产环境)的访问权限。此过程类似于在上一节中创建基础设施工作区。

首先,点击左侧导航栏中的“Services”,然后点击选项卡右上角的“+ Add”按钮。为Workspace命名(此处为“Hello, World”服务使用api-sentence),还可选择提供说明和联系信息。

图3:创建服务工作区

此时,可以邀请API开发人员开始在为其创建的Workspace中发布代理和文档。有关发布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 Token)保护API访问
  • 后端运行状况检查:持续执行运行状况检查,避免向后端服务发送可能失败的请求
  • CORS:允许外部域的客户端受控访问资源
  • 缓存:通过缓存策略提升API代理性能
  • 代理请求标头:将选定的标头传递给后端服务
  • 速率限制:限制传入请求并保护API工作负载

在以下示例中,我们通过UI定义一项策略,用于保护API Gateway Proxy与后端服务之间的通信。

在左侧导航栏中单击“Infrastructure”。单击包含待编辑API Gateway Cluster的Environment名称后,该选项卡将显示此Environment中的API Gateway Cluster和Developer Portal Cluster。

图4:为API Gateway Clusters和Developer Portal Clusters配置全局策略

在要应用策略的API Gateway Cluster所在行中,单击…图标(位于“操作”列),然后从下拉菜单中选择“编辑高级配置”。单击左侧列中的“全局策略”,即可显示所有可配置的全局策略。

图5:为API Gateway Cluster配置策略

要应用TLS Backend策略,请单击该策略所在行右端的“…”图标,然后从下拉菜单中选择“添加策略”。填写所需信息,上传证书,然后单击“添加”。接着,单击“保存并提交”按钮。此后,API Gateway Cluster与后端服务之间的流量将通过TLS进行保护。有关完整说明,请参阅《API Connectivity Manager文档》。

总结

规划并实施API治理,是确保API战略成功的关键一步。通过逐步采用分布式模式,并依靠自适应治理来满足不同团队和API的独特需求,可以在不牺牲API和云原生环境所具备的高效速度与敏捷性的前提下,实现规模化扩展并统一实施治理。

开始使用

开始NGINX Management Suite 30天免费试用,即可使用API Connectivity Manager、NGINX Plus作为API网关,并使用NGINX App Protect保护API。


分享

相关博客文章

NGINX Plus R26 正式发布
NGINX | 2022/02/15

NGINX Plus R26 正式发布

NGINX Plus R26通过缓存JSON Web密钥集加快JWT验证,并强化TLS握手,从而提升安全性。NGINX JavaScript的新功能包括增强对异步函数的支持,以及实现WebCrypto API。

使用NGINX App Protect DoS保护gRPC应用,抵御严重的DoS攻击
NGINX | 2022/02/10

使用NGINX App Protect DoS保护gRPC应用,抵御严重的DoS攻击

gRPC具备开发人员设计和部署现代应用所需的速度与灵活性,但其开放性也使其极易受到第7层DoS攻击。NGINX App Protect DoS可保护gRPC应用免受此类破坏性攻击。

Ingress Controller 选型指南(第 2 部分):风险与面向未来的规划
NGINX | 2021/09/13

Ingress Controller 选型指南(第 2 部分):风险与面向未来的规划

了解选择错误的Ingress控制器可能带来的风险,以及如何从关键方面着手,让您的选择更好地适应未来需求。

NGINX Plus R19 正式发布
NGINX | 2019/09/03

NGINX Plus R19 正式发布

NGINX Plus R19扩展了监控功能,不仅提供更多指标,还新增了指标分析方式;增加试运行模式,用于测试限速效果;增强键值存储,以支持IP地址范围;并使限速更加动态。

NGINX现已正式加入F5
NGINX | 2019/05/09

NGINX现已正式加入F5

NGINX现已正式成为F5的一部分。Gus Robertson现任F5 NGINX业务部门负责人。他阐述了两家公司在人才、文化和愿景方面融合的价值,以及双方将如何携手增强NGINX的开源产品和商业产品。

使用NGINX和NGINX Plus实现高性能缓存
NGINX | 2016/08/24

使用NGINX和NGINX Plus实现高性能缓存

我将介绍NGINX在内容缓存和性能方面的工作原理,并分享一些控制NGINX内容缓存方式的技巧。