F5 首席技术官办公室团队已在 API 相关技术领域探索一年多了。 这份最新的白皮书是我们努力了解不断发展的 API 生态系统的延续。
我们详述的管理 API 蔓延的挑战将导致 API网关蔓延的挑战,而解决这些挑战的传统方法是不够的。 虽然 GraphQL 等图形技术在解决 API 复杂性方面前景看好,但它只是解决方案的一部分,因为挑战不仅仅局限于连接性、安全性和路由。 正确的方法基于近三十年的扩展系统和applications专业知识,它基于分布式(而非联合式)架构,采用 GraphQL 但并不完全依赖于它。
本文探讨了一种分布式架构方法来解决 API 网关蔓延的挑战。
数字经济将通过 API 来推动,让我们实现API 驱动的经济。 按照API 蔓延白皮书,我们的追求是了解如何消除或减轻 API 蔓延的影响。 虽然 GraphQL 似乎有望减少 API 蔓延的影响,但它往往会让开发人员承担重写大部分 API 代码库的责任。 然而,围绕 GraphQL 的一个新兴观点是它可以用作有效的网关参与者。 网关参与者是在发起 API 请求的客户端附近创建的函数或进程。 该网关参与者充当终止 API 请求的初始 API 网关。 它也可以是短暂的,这样可以在服务请求后被销毁。
除了开发人员和运营团队优先考虑 API 管理而不是 API 网关之外,我们还发现了由于 API 蔓延而导致的 API网关蔓延问题。 从开发人员的角度来看,主要关注点是确保 API 正确且及时地运行。 另一方面,运营团队更加关注发现、安全性、可用性和访问控制等方面。 由于 API 网关如今已成为 API 基础设施的关键组件,因此很明显,API 的激增会增加 API 网关的部署,从而导致 API 网关蔓延。
API 架构的未来需要不断发展以接受 API 蔓延,同时简化部署和操作。 所提出的架构是 API 网关设计模式的下一步发展。 虽然 GraphQL 不是架构的核心,也不是必需品,但它有能力增强网关参与者模式。
API 管理生态系统必须从管理 API 网关整体转向更现代的系统设计方法。 这将带来更加灵活、有效的 API 管理生态系统。
API 蔓延已经成为 API 经济中的一个挑战,它也导致了API 网关蔓延,由于 API 网关供应商技术多样,以及管理 API 网关的团队各执一词,API 管理变得难以控制。 我们正处于 API 架构的转折点,因为传统的 API 网关(API-GWs)(充当 API 调用入口点的专用软件层)已不足以管理新兴 API 生态系统的规模和复杂性。
图 1 说明了我们如何从管理 API 蔓延转向管理 API 网关蔓延。
上述设计模式指的是集中式控制平面,API 网关形成分布式数据平面,如图 2 所示。
API 网关是现代软件架构的重要组成部分,为 API 提供中央控制点和安全。 然而,随着 API 网关提供的功能数量的增长,它们变得越来越复杂和难以管理。 在许多情况下,这些网关已经发展成为单一系统,将各种功能捆绑在一个包中。
虽然管理多个网关可能看起来是一种分布式设计,但事实上它并没有达到真正的分布。 这是因为网关仍然紧密耦合,共享难以分离的资源和配置。 结果,许多企业最终管理分布式整体架构以及由此产生的所有挑战。
图3给出了现有API网关的架构。 来自客户端的 API 请求首先通过共享或专用网络传输,穿过防火墙后才到达 API 网关。 充当反向代理的 API 网关随后将流量转发到 API 工作负载。
当 API 网关部署在整个企业中时,或者当 API 工作负载在跨区域、跨地区、跨云或跨边缘移动并同时应对 API 蔓延时,传统的 API-GW 将成为 API 管理的瓶颈。 多个 API-GW 由不同的团队启动,没有单一的企业管理和控制点。 如果单个或一组 API 服务转移到不同的基础设施(云或其他),运营团队必须有一种方法来迁移 API 管理的所有方面——注册、发现、身份验证、网络、安全和治理风险与合规 (GRC) 政策。
因此,图 3 中所示的架构不可扩展或不实用,因为随着时间的推移,它会导致管理分布式整体(图 2)。
创建 API 网关瓶颈存在两个问题: (1)API 网关供应商扩张,(2)当企业在更多地方运行更多applications时进行扩展。
图 4 描绘了一个分布式网关参与者模式,用于解决 API 网关蔓延问题。 虽然分布式模式本身并不新鲜,但本文在 API 网关的背景下对其进行了形式化。 客户端发起 API 请求。 分布式网关参与者是短暂的,并根据需要尽可能靠近客户端实例化。 API 传输层的职责是将 API 请求从网关参与者发送到简化的 API 网关,然后将请求路由到适当的 API 工作负载。 虽然在分布式参与者中使用 GraphQL 支持更多的是一种细节,而不是这种模式发挥作用的要求,但它确实支持服务编排等功能。 因此,GraphQL 可以提供该支持,而不必创建新的服务编排层。
需要澄清的是,交通模式是从右到左。 即客户端在右边,由客户端发起API请求,如图5所示。
有一种新兴的部署模式,使用网关参与者来取代或减少对 API 网关的过度依赖,以管理企业内部和跨企业的 API。 虽然 GraphQL 对于架构来说不是必需的,但它的引入是及时的,因为网关参与者是支持 GraphQL 的正确工具。
为了更深入地了解网关参与者作为潜在的解决方案,有必要仔细检查 API 基础设施(特别是 API 网关)的当前状态。 这是因为我们已经发现网关蔓延是造成 API 基础设施运营和扩展挑战的重要因素。
为了更好地理解 API 网关,首先需要检查现代 API 管理基础设施的各个组件。
图 6 以全面的视觉方式展现了 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 网关的激增。 不同的团队或业务部门通常会创建自己的 API,这会导致创建多个独立的 API 网关来处理这些不同的 API。 不同的团队也可能使用来自不同供应商或解决方案的 API 网关来处理不同类型的 API。
这导致部署多个 API 网关,所有网关都具有不同的功能集。
API 网关扩张带来了几个额外的挑战:
企业应努力集中其 API 管理和治理,并使用单一类型的 API 网关。 虽然这将减轻 API 网关蔓延的上述挑战,但 API 网关的同质化策略绝非易事。
随着企业有机增长或通过收购发展,与特定业务部门 (BU) 保持一致的内部团队在选择 API 网关技术或供应商时会产生分歧。 造成这种情况的原因如下:
因此,如果现有应用拥有完善且有主见的团队,则该团队将不愿意转向不同的部署模式,以免导致服务中断。
因此,我们可以得出结论,需要一种新的方法,该方法要考虑现有 API 基础设施的多重限制,同时强调 API 网关蔓延是更重要的考虑因素之一。
以下并非详尽的列表,但总结了我们认为在构建解决方案时应纳入的一些高级设计考虑因素:
根据这些设计考虑可以得出具体要求,我们已将其纳入我们的分布式网关参与者(DGA)解决方案中。
现在已经充分探索了 API 网关,我们可以解释分布式网关参与者解决方案。
分布式网关参与者 (DGA) 设计模式从边缘计算和靠近客户端的计算中汲取灵感。 这个想法的关键在于将每个网关参与者尽可能地分布在靠近客户端的地方,并且让网关参与者仅在交易持续期间存在,直到最后被清除。
以下是该解决方案的一些基本假设。
边缘计算已变得更加普遍,我们现在可以找到地理位置上更靠近客户端的某种类型的计算。 网关参与者可以在这些边缘计算节点上实例化。 目的是实现一个非常轻量且短暂的 DGA,以便它可以在任何边缘计算上实例化。
API 传输是基础设施的一个重要组成部分,因为它涉及在网关参与者和 API 网关之间建立网络。 所需的基础设施类型取决于供应商或企业,并且可能有所不同。 例如,大型公共云可能使用自己的主干网来运行 API 传输。 另一种实现方式可能是在企业数据中心内现有的高带宽和低延迟网络之上构建低延迟消息总线。
重申一下,API 网关本质上是一个反向代理,其主要功能是将 HTTP 流量路由到适当的 API 工作负载。 这种方法在所有 API 都共置的情况下很有意义,例如在本地内部部署网络中或在可用区域内的虚拟私有云 (VPC) 中。 但是,随着 API 数量的扩大、跨混合基础设施的移动或移动化,这种 API 网关设计方法变得效率低下、操作复杂且成本高昂。
虽然对于如何对图 6 中描述的所有功能进行分类可能会有不同的看法,但我们可以同意API 管理基础设施已经成为需要精心协调的许多组件的复杂部署。
图 7 将图 6 中的 API 管理的各种特性和功能映射到分布式网关参与者架构。 该映射直观地说明了每个特性和功能如何与 DGA 方法保持一致,突出了架构内 API 管理组件的无缝集成。
上面列出的大多数功能都有一些可以在逻辑上集中的管理组件。 我们的目标不是重新设计管理平面,而是如果可能的话,删除某些功能。
这些是数据平面功能,因此最好在 API 中实现并与应用工作负载共置。 API 网关是现代微服务架构的重要组成部分,是所有外部流量的入口点。 我们将其核心功能分类为路由、负载平衡、动态路由、健康检查、重试和回退。
API 网关将传入的请求定向到适当的微服务,在多个实例之间分配流量,支持动态路由,监视微服务及其实例的运行状况,重试失败的请求,并在微服务不可用或失败时提供回退响应。 其他功能(如身份验证、授权、速率限制、缓存和日志记录)可以根据系统的具体要求分布到边缘或集中功能。
这种模块化方法可以实现更加灵活和优化的架构,也是我们简化、现代化和扩展企业 API 基础设施的建议的核心。
API 网关和 API 管理经常被供应商错误地混为一谈,被认为是 API 网关功能的一部分,但它们实际上是两个不同的功能,应该分别处理。 API 网关负责将请求从客户端路由到后端服务,而 API 管理包含更广泛的功能,例如访问控制、速率限制、分析和开发者门户管理。
虽然一些供应商可能在单个产品中同时提供 API 网关和 API 管理功能,但了解这些功能之间的差异并根据特定要求分别评估它们非常重要。 结合这些功能可能会导致混乱,并可能限制组织 API 基础设施的灵活性和可扩展性。 这对于理解我们分发 API 网关功能的立场也至关重要。
这里列出的功能是需要内联到数据路径的核心功能。 在分布式网关模式中,API网关的一些内联函数也变得分布式。 这些功能包括访问控制、速率限制、请求验证、API 分析、使用情况报告、错误率监控、警报和事件、身份验证集成、第三方集成、监控和日志记录集成、边缘缓存和压缩。
将这些功能移至分布式网关模式具有以下好处:
例如,访问控制、速率限制和请求验证可以由部署在更靠近客户端的边缘网关参与者处理。 这有助于减少集中式 API 网关需要处理的请求数量,从而提高其性能和可扩展性。 类似地,API 分析、使用情况报告、错误率监控、警报和事件以及监控和日志集成可以由边缘网关处理,边缘网关可以收集和聚合来自多个微服务的数据。
如今,API网关支持的一项重要功能是服务组合和编排。 虽然这可能变得相当复杂,但如果简化的 API 网关不支持此功能,就会成为一个问题。 我们相信 GraphQL 可以成为一种有趣的服务组合方法,充当现有 API 的一种中间件。
由于所有 API 的可见性,API 网关成为执行服务组合的逻辑位置,使开发人员能够组合网关后面的 API 来增强业务逻辑,而无需编写可以在服务组合层中更轻松地组合的新服务。
GraphQL 中的服务组合是通过使用强类型模式实现的,它定义了客户端可用的数据的形状。 客户端可以使用此模式来构建查询,指定他们所需的精确数据,而不管哪些服务或来源提供该数据。 解析器是将查询映射到数据源的函数,用于从适当的服务或源检索数据。 然而,虽然 GraphQL 承诺提供更好的安全性,但它的安全性完全取决于编写代码的开发人员。
仍有一些剩余的特征未在图 6 中突出显示: API 管理和基础设施功能。 这些剩余的特性和功能可以转移到单独的管理和操作或数据平面功能。
我们特意选择使用“参与者”这一术语,以避免暗示特定的实施或供应商技术。 网关参与者的实现可以基于方法、函数、工作器、线程和进程,使用基于虚拟机、容器、无服务器或特定于供应商的其他方法的基础设施来实现。
分布式网关参与者 (DGA) 架构所采用的方法简化了 API 网关功能并将其他内联功能移至边缘或控制平面。
除了 API 网关功能之外,DGA 架构还建议确定一些功能,这些功能可以在控制平面中作为逻辑集中的组件更好地服务,而不是在单片 API 网关中实现。 已经存在的 API 基础设施的管理和控制可以扩展和扩大以包含此附加功能。
因此,API 网关的简化成为一项练习,以获得一组标准的核心功能,所有 API 网关供应商都可以通过一组通用的配置参数进行管理。
想要进行这种转变的企业可以一次推出一个应用的 DGA 架构,而不会干扰现有部署,也不需要进行叉车操作。
DGA 的一个重要方面是每个网关参与者都是短暂的,仅在 API 会话期间实例化(即一个客户端进行一次 API 调用)。
分布式网关参与者比传统的 API 网关更加灵活、可扩展且经济高效。 网关参与者允许开发人员为更靠近网络边缘的每个 API 指定和部署单独的网关实例,而不是依赖来自不同供应商的多个单片 API 网关来聚合和处理 API 流量。 API 本身可以根据他们的特定需求提供更好的控制和定制。
这种新方法还具有更高的可扩展性,因为开发人员可以根据需要轻松启动网关参与者实例来处理增加的流量,而不必担心管理大型集中式网关的开销。
除了技术优势之外,网关参与者还比传统 API 网关节省成本,因为企业只需为其使用的临时网关参与者实例付费。 这种部署模型可以为额外的收入模式创造机会。
通过利用 API 传输层,DGA 本质上将 API 入口位置与 API 网关分离。 DGA 可以移动到边缘,即更靠近发出 API 调用的客户端。 API 可以在 DGA 中终止,然后通过任何方式进行传输。 这与图 3 不同: 传统 API 网关架构中,客户端流量在拓扑上与 API 网关相邻进入。
因此,我们的目的是提出一种与供应商和部署无关的方法,因为不同的供应商可能拥有自己的知识产权来构建这些组件,以实现如上所述的类似目标。
在本文中,我们总结了从多个方面研究API 蔓延、 Edge 2.0架构、 API 经济和 GraphQL 调查的经验教训。 尽管对于遗留 API 基础设施尚无定论,但我们认为需要一种新的方法。
仅仅是承诺在全球范围内释放每个单独的设备或实体内的价值就为探索新方法提供了足够强大的理由。 我们今天需要摆脱传统的 API 基础设施,因为虽然它看起来是分布式的,但在本质上却是整体的。
我们提出了基于分布式 GraphQL 的网关参与者方法,作为一种与供应商无关的方式来释放新兴 API 经济的全部潜力。