关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。

本文将从 API 网关在企业计算中解决的问题入手，深入研究 API 网关

API 网关是一种架构模式，用于创建一个外观，将内部系统的数据暴露给解耦层中的外部客户端，从而减少前端和后端组件之间的依赖性。如今，该模式广泛应用于计算领域，用于大中小型企业的业务应用程序和集成解决方案。打破客户端和后端实现之间的依赖关系的价值是非常巨大的。现代分布式系统的许多重要功能都可以在 API 网关中实现。函数列表非常大，将在本文的下一节中进行说明。

目前，我们看到 API 网关在关键任务应用程序和用例中的使用，例如微服务架构、遗留单体、整体迁移到微服务项目和集成层。此外，API 网关涉及不同的部署模型，因为在本地运行的裸机服务器、Amazon EC2 等虚拟机以及 Amazon EKS 上的 Kubernetes 等容器化解决方案，甚至在现代无服务器计算平台中，涵盖所有可能的今天可用的部署频谱。第 2 节探讨了使用 API 网关模式解决的问题。

目前可用的 API 网关实现的功能差异很大；一方面，一些实现只有几个特性，但另一方面，它们被完全覆盖。这些函数也称为边缘函数。它们需要在某个地方实现，它们可以像单体应用程序一样在业务层中实现，或者最终在 API 网关中实现，或者最终，它们可以在其他外部额外组件中实现。例如，可以在业务层而不是在API网关中实现认证功能；然而，如本文第 3 节所示，将此类功能解耦到 API 网关中有很多优点。

Amazon API Gateway 是 API 网关模式的 Amazon Web Service (AWS) 实现；它是一个完全托管的解决方案，可轻松与其他 AWS 服务集成。Amazon 实施是一项非常强大的服务，它提供易于使用的图形用户界面，并且可以使用 CLI 或基础架构即代码 (IaC) 方法实现自动化。第 4 节探讨了 AWS 上可用的 API 网关的当前 Amazon 实现所实现的功能（边缘功能）。

本文将对 API 网关进行深入研究，从 API 网关在企业计算中解决的问题开始，然后对整个计算领域已知的功能或特性进行规范研究，呈现、描述和探索它们的细节. 最后，将介绍 Amazon 实施，对比研究的 API 网关功能和目前在 Amazon 实施中发现的内容。

为什么使用 API 网关模式？

需要清楚的是，为什么需要 API 网关作为我们数据中心、本地或云中已经存在的庞大计算基础架构中的一个新组件，因为设计、实施、部署和部署的成本很高。管理一个新的高度可扩展和可用的组件，例如必须包含在那个大生态系统中的网关。引入网关有两个主要原因，首先是解耦软件以将内部业务功能暴露给外部世界——提高软件组件的重用率并加快上市时间。其次，路由和控制入站流量以提高安全性和管理。

解耦软件

好吧，这些公司曾经处于内部流程自动化的发展阶段，一般来说，他们的流程在一个大型应用程序中自动和自主地执行（这就是我们所说的遗留和现在的后端应用程序）。但是，该应用程序只是为了使这些内部流程自动化而生成的，而不是将外部利益相关者引入自动化。因此，为了在瞬息万变的市场中保持竞争，这些公司希望公开其在后端系统中存储和运行的内部数据和功能，以供外部应用程序使用，从而创建更具交互性和生产力的生态系统。为了应对这些新要求，在 20 世纪 90 年代后期，企业对客户 (B2C) 和企业对企业 (B2B) 这两个术语在互联网电子商务繁荣时期变得非常流行。IT 团队通过开发所谓的三层 Web 应用程序来处理该解决方案，这些应用程序是具有点对点连接的集成系统，可将他们自己的应用程序与合作伙伴链接起来。Web 层的引入在公司、他们的客户和合作伙伴之间建立了连接。请参见图 1，其中显示了该三层解决方案中使用的 Web 层和整个模型的高级图片。

图 1：三层架构解决方案

图 1 显示了用于将后端系统暴露给在 Internet 浏览器中运行的前端 Web 层的三层解决方案。浏览器应用程序是由运行在中间件中的动态 Web 应用程序提供的瘦静态页面 (HTML)。这个 Web 应用程序通常是一个巨大的整体集成层，是前端和后端之间的粘合剂，它提供来自后端系统的数据并可能与合作伙伴的系统集成。它是通过创建许多点对点集成来执行的，这些集成不是最佳实践，因为缺乏可重用性和必要的大量基础设施工作，因为通信协议基于 Internet 标准，因此对防火墙不友好。

此外，中间件中的 Web 应用程序今天被称为分布式“大泥球”，这意味着它具有 Sam Newman [1] 描述的单体地狱的症状：难以维护（开发困难），难以测试，增加了上市时间，受制于过时的技术堆栈，并且在扩展方面不灵活。

从业务角度来看，指出的大量技术问题几乎没有注意到使用三层应用程序架构的缺点，因为底层技术对业务人员是透明的，但最重要的复杂性在于所引用的上市时间。它在为现有应用程序创建新功能时产生延迟，影响竞争市场的动态，在创建新功能时需要高速响应，这将提高自动化并提供差异化服务来战胜竞争对手。

因此，为了明确解决该三层应用程序场景中单体地狱症状的网关的必要性，如图 1 所示，在 Web 层中与业务逻辑一起运行的被调用边缘功能已经被解耦，从而将关注点从我们的整体应用程序分离到一个具有开放标准协议的更加分布式的系统中，分解为更易于管理的独立组件，参见图 2，它也与后端交互，但它打破了内部的功能将单体 Web 应用程序集成到微服务中，并放置一个网关以将 API 公开给外部消费者，一种新的基础架构设计诞生了。API 网关研究的第一步是弄清楚哪些边缘功能可以从整体中分解并集成网关解决方案，这是在研究该领域的 API 网关文档后得出的，将在本节中进行探讨3.

图 2：API 网关打破 Web 应用单体

注意到图中首先：合作伙伴应用变成了解决方案中松耦合的API参与者，而不是后端的点对点集成。其次，以前集中客户端直接调用的 Web App 现在受到在 Intranet 网络中安全运行的网关的保护，而不是危险的 DMZ 层。最后，Web App 被分解为一个微服务，带来了本文未涵盖的微服务架构的所有优势（如果您想更深入地了解微服务架构，请参阅 [2]）。

控制入站流量

入站流量（通常是 HTTP 协议）需要从消费者路由到正确的服务，以实现 API 消费者所需的功能或数据资源公开。消费者或客户端可以是在浏览器丰富的客户端应用程序（React、Angular 或带有 Ajax 调用的简单 HTML 等）、本机或 Web 移动应用程序或使用底层 API 的第三方应用程序中运行的 JavaScript。API 网关中的流量路由是一种证明目的的手段，因为它需要执行边缘功能并充当中间人，以处理向暴露的后端系统发出的所有请求，这使其能够进行拦截并在其上添加功能.

让我们看看在没有 API 网关的情况下通过 RESTful API 公开后端的非常常见的场景，消费者将发送细粒度的同步 HTTP REST 请求，后端系统将直接接收该请求，计算并返回处理后的响应. 它在功能上运行良好；然而，在处理现实生活中的应用程序时，它并不只需要一个请求就可以获取所需的信息。例如，要在 Web 仪表板中检索客户信息，需要针对后端中的许多服务发出许多请求。一个电话询问基本信息，另一个电话询问客户的相关账户、客户的余额等。在那种非常细粒度的场景下，将这些信息合并在一起会很费力，需要在客户端完成，增加代码库和资源利用率，

图 3：没有 API 网关的数据处理

图 3 显示了三个蓝色的消费者，向每个橙色的后端组件发送了三个细粒度的调用。消费者负责在自己的代码中编写客户信息，然后将收集到的数据呈现给应用程序用户。那些细粒度的调用通常是通过 Internet 进行的远程调用。这增加了在前端呈现数据的延迟，此外，他们可以直接访问服务，而无需在到达核心业务软件组件和底层基础设施之前采取任何身份验证或授权机制；它很容易受到攻击。

细粒度访问问题有一个设计模式，称为 Façade；Façade 模式由 Eric Gamma 等人描述。[3]; 这里是由API Gateway实现的，结果如下图所示：

图 4：API 网关作为公开计算服务的外观。

图 4 带来了 API 网关，它将 API 组合与客户端分离，带来了一个集中入站调用并控制出站调用路由的解决方案。现代计算体系结构中一个重要的，可以说是强制性的管理集中器组件。还要注意基础设施已经改变，创建了一个非军事区（DMZ），为了安全起见，其部署应该在不同的子网中，网关可以提供到 Internet 的接口，在对消费者进行身份验证之前不暴露业务组件. DMZ应该是公有子网，服务必须部署在一个叫做私有子网（访问非常少，一般只能通过堡垒服务访问）；这些服务会在其配置中将网关地址列入白名单，

请注意，流量路由所提升的安全和控制级别是巨大的，这足以证明对具有高可用性和可扩展性的 API 网关等组件的投资是值得的，这肯定会增加设计、开发、部署和运营 IT 成本. 此外，请注意图 3 中的流程与图 4 中的流程对比；您会发现它显着改善了客户端和后端系统之间的往返。

在网关实现中，它将专注于本节中提到的功能，并添加许多其他称为边缘功能的功能。下一节将探讨这些边缘功能或特性的 API 网关。

API 网关功能

API Gateway 的研究成果是对其可能遇到的功能（也称为边缘功能）有一个整体的看法，导致有 22 个功能可能会在 API 网关解决方案中实现。这些功能分为六类：核心、桥接、性能、安全、服务质量和运营。

核心功能是每个网关实施必不可少的功能。桥接是一种功能，可以拦截消费者的请求并进行一些处理，然后转发给服务，在客户端和暴露的后端系统之间架起一座桥梁。性能是关于改进解决方案的响应时间。安全性提供了禁用未经授权访问的机制，避免了潜在的攻击者。服务质量与服务水平协议 (SLA) 相关。操作功能是那些在运行时操作和故障排除中有用的功能。

Mulesoft Anypoint 是一个全面的集成平台，它使用他们所谓的“策略”来实现其中的一些功能，这些策略是通过他们的 API 代理实现的。它们不调用 API 网关，但 API 代理和部署模型与此处公开的略有不同。有关更多信息，请参阅 [3] 中的 Anypoint 文档。

具有特定类别的边缘函数可以在下面的图 5 中看到。边缘函数的分类细节将在以下小节中描述。

图 5：边缘函数

流量路由

如 2.2 节所述，流量路由是 API 网关必须实现的功能。它与反向代理解决方案中的功能相同，后者为每个特定请求端点在要请求的端点和要转发的端点之间进行映射。

解耦

正如第 2 节所述，与“大泥球”脱钩是适应全球市场快速变化的关键点。API 网关是让后端系统完全公开以供不同客户端安全使用的方向的核心参与者。解耦是 API 网关最重要的职责之一。网关现在专门化并减轻了本节中研究的功能的其他中间件节点。

协议翻译

在网络术语中，网关是一种能够在不同协议之间进行转换的软件。API 网关专门工作在开放系统互连 (OSI) 参考模型的第 7 层，使用 HTTP，通常是 RESTful API，将后端系统的接口暴露给外部公共互联网，并且在内部可以处理不同的协议，例如 REST（与网关公开接口）、gRPC、WebSocket、JMS（在异步用例中）、AMQP、SOAP 等。

API组成

API 组合模式是创建 Façade 的结果。实现Façade的API Gateway接收远程客户端粗粒度数据请求，然后将相邻层不同服务的业务数据一起组成响应并返回响应，而不是直接向客户端发送访问这些服务，在后端对这些服务执行许多细粒度的请求。

当使用 API 网关执行 API 组合时，网络延迟将减少，因为从客户端到 API 网关的互联网流量（延迟贡献较大）将只计算一次，而不是与请求的数量成正比涉及特定业务流程的服务。

GraphQL 支持

GraphQL 是一种用于 API 的查询语言，它为客户端提供了灵活性，可以从后端系统中选择合适的信息，这意味着合适大小的合适信息。作为 API 网关功能的 GraphQL 支持是一个重要的点，因为它将提供前端后端模式 [5] 的实现，使客户端能够获取他们需要和负担得起的准确信息量。将其想象成一个 SQL 查询，您可以只选择所需的字段和表。GraphQL 的工作方式类似，它通过选择客户端希望作为对其查询的响应的 JSON 属性来减少负载，从而减少客户端的内存和 CPU 使用率。深入了解 GraphQL 访问 [6]。

标题操作

标头操作包括在 API 网关级别更改状态代码和标头操作。它在需要包含或删除 HTTP 标头数据以满足 API 消费者或中间件服务的特定场景中很有用，有时出于身份验证和/或授权原因。

负载均衡

API 网关由于其在体系结构中的战略地位，在用作底层服务层节点的负载平衡器时，是提高系统可扩展性的潜在点。

以最大容量跟踪列表中节点的实例，网关将能够促进自动扩展，在必要时扩展新实例，并扩展终止未使用的节点。尽管负载均衡功能通常在专用负载均衡器（如 Amazon Elastic Load Balancing Services (ELB)）中完成，但仍有可能在 API 网关中实现它，从而减少到达服务节点所需的跃点数。

缓存

缓存在 API 查询中用于将响应存储到本地或分布式节点中的快速内存中。然后，在使用相同查询的下一次调用中，使用这些缓存数据作为响应，而不是与后端系统进行新的往返。它减少了从网关到所有下游服务的后端往返次数。此功能极大地提高了整体性能，因为它最终不仅减少了与中间件中许多服务的交互，而且还减少了与后端应用程序和数据库的交互。

HTTP 基本认证

Basic Authentication 是客户端在 HTTP 协议中提供身份验证凭据的一种流行机制。它使用授权 HTTP 标头以及在其上编码的用户 ID 和密码。这种机制从 Internet 使用之初就开始使用。有关详细信息，请参阅：[6]。HTTP 基本身份验证也可用于发送客户端 ID 和客户端机密以用于 OAuth 2 安全性，稍后描述。

OAuth 2.0 认证与授权

这是一个广泛使用的功能，它通过使用 OAuth 2.0 来启用安全的 API 客户端检查，OAuth 2.0 是一种授权和授权的开放标准。有关此标准的更多详细信息，请参阅 [8]。

智威汤逊检查

此功能要求 API 网关验证入站请求的授权标头中是否存在 Bearer 令牌。找到它后，它将使用身份提供者验证令牌，然后传播委托人在 JWT 令牌声明中的角色。

基于 IP 的验证

IP白名单和IP黑名单是抵御攻击的利器。它允许控制 IP 网络中的哪台主机可以访问特定端点或整个节点。一方面，白名单是允许访问服务的IP地址列表；另一方面，您可以有一个禁止访问的黑名单。

治疗防御

虽然上一节中介绍的基于 IP 的验证是网络级别（OSI 第 3 层）的重要防御，但威胁防御是应用程序级别（OSI 第 7 层）的另一种应用。Treat Defense 功能可以保护基于 XML 或 JSON 的应用程序匹配应用程序级别预期的模式，避免超大、恶意和超出预期的有效负载。

API 密钥执行

该边缘功能允许针对不同用例以不同方式发送身份验证 API 密钥和秘密凭证：作为查询参数、自定义标头或标准授权标头作为基本身份验证（请参阅第 3.9 节）。该功能对于管理不同的设备和用例很重要，例如，它们无法发送负载中包含数据的 POST，而是需要发送 GET 并使用查询参数来提供凭据（强烈不建议将秘密作为查询参数传递）。

启用 TLS 流量

使用 TLS 通过加密保护通信通道是当今使用的任何计算服务中的常见模式。因此，网关将能够实现简单的 TLS，并且应该能够实现相互身份验证。TLS 提供通信通道的节点身份验证、机密性和完整性。

跨源资源共享 (CORS)

CORS 是一种访问控制功能，使网关能够仅允许指定源域的流量。此控制通常使用 Origin 请求标头在基于 Web 浏览器的应用程序上执行，其中它必须与配置的源域匹配。有关 CORS 的更多信息，请参阅 [9]。

服务冗余

可以在 API 网关中实施称为健康检查的模式以提供更高的可用性，从而增加系统的弹性。正如上一节中所建议的那样，它会保留一个节点列表，并对节点进行定期健康检查。它将使 API 网关能够仅为健康节点路由流量。这提供了一个可以由网关提供的强大的故障转移解决方案，显着提高了服务质量 (QoS)。

服务冗余也可以通过服务发现机制使用动态服务发现来实现，例如 Netflix Eureka 开源项目，它动态注册节点而不是将它们放在静态配置文件中。如果您对 Eureka 的实现感兴趣，请参阅 [10]。

断路器

使用断路器模式实现来监控与客户请求相关的节点并避免跨特定客户请求的灾难性级联故障对于 API 集成层和微服务等关键任务应用程序至关重要（有关断路器模式的更多信息，请参阅 Martin Fowler 的网站这里 [11])。

由于 API 网关是在部署基础设施边缘工作的基础组件，因此它是放置断路器的绝佳场所。它将通过实现以远程调用为键的映射以及与该远程调用相关的后端服务列表来提供故障保护。然后它必须监视该列表以查找故障和潜在的导致连接超时的长往返，从而导致系统破裂。当检测到这些中断时，断路器会打开整个路径的电路，并保持该状态，直到服务恢复正常或响应更快。此外，故障转移机制应该到位，以在发生故障时重新路由流量，以保持系统的弹性工作。

速率限制

速率限制控制通过网关的数据流，在达到指定的吞吐量时拒绝请求。该控制是通过 HTTP 标头实现的。

尖峰控制

尖峰控制类似于速率限制，但不是在达到阈值时简单地拒绝请求，而是将它们排入队列，延迟和限制它们的处理。

指标收集

对于一些公司来说，例如，根据 API 请求调用向客户收费，有必要有一个计费程序。其他公司需要一种机制来捕获指标以进行分析。因此，指标收集是任何网关实现中的一个重要特征。

记录

故障排除或审计非常重要，因此必须在所有计算系统或平台中实现创建日志记录并能够执行日志聚合模式 [12] 来对系统中的分布式节点进行故障排除。

这些都是研究中涵盖的边缘功能。下一节将介绍如何在当今市场上最著名的 API 网关之一 Amazon API 网关中实现这些边缘功能。

亚马逊 API 网关实施

Amazon API Gateway 是一种实现 API 网关模式的托管服务。它用于通过 RESTful API 公开后端系统或服务。被管理意味着 AWS 有责任按照约定的服务质量维护底层基础设施。见下表 1。它介绍了上一节中研究的功能，并公开了由 Amazon API Gateway 实现的功能：

表 1：在 AWS API Gateway 上实现的边缘功能

该表显示了实现大多数边缘功能的 Amazon 实现，只有七个功能未实现。在这七项服务中，它具有涵盖以下内容的外部服务：使用 Elastic Load Balancing 的负载平衡、使用 AWS AppSync 的 GraphQL 支持，以及可以部署在 AWS Lambdas 上的 API 组合。

因此，尽管没有包含在 AWS API Gateway 中，但它们提供了三个单独的服务来为其添加此类功能，这将只缺少以下四个功能：Treat Defense、Service Redundancy、Circuit Breaker 和 Spike Control。

结论

API 网关对于分解单体应用程序以公开企业内部业务应用程序并应对它们所需的当前集成级别至关重要。

通过研究现代 API 网关可能实现的边缘功能，得出了六个类别，其中包含 22 个特性或边缘功能，涵盖了当前所需的范围。

Amazon API Gateway 实现覆盖了大约 68% 的边缘功能，这对于 AWS 将其服务解耦为更小的部分并单独提供它们来说可以认为是一个很好的数量。换句话说，他们已经涵盖了其他产品中的许多边缘功能，而不是将它们全部集中在 API 网关上。另一方面，它有更多分布式组件执行边缘功能的缺点，其中最相关的问题是服务间通信带来的延迟增加。

参考书目

[1] S. Newman，构建微服务：设计细粒度系统，加利福尼亚州塞瓦斯托波尔：O'Reilly Media，2015 年。

[2] C. Richardson，“微服务架构”，[在线]。可用：https://microservices.io/patterns。[2021 年 6 月 20 日访问]。

[3] E. Gamma、R. Helm、J. Vlissides 和 G. Booch，“设计模式：可重用面向对象软件的元素”，Addison-Wesley Professional，1994 年。

[4] M. LLC，“Mulesoft Anypoint 文档”，[在线]。可用：https://docs.mulesoft.com/api-manager/2.x/policies-ootb-landing-page。[2021 年 6 月 20 日访问]。

[5] C. Richardson，微服务模式，谢尔特岛，纽约：曼宁，2018 年。

[6] GraphQL，“GraphQL 规范”，[在线]。可用：https://graphql.org/learn。[2021 年 6 月 20 日访问]。

[7] IETF，“RFC7617”，[在线]。可用：https://datatracker.ietf.org/doc/html/rfc7617。[2020 年 6 月 20 日访问]。

[8] “OAuth 2.0 规范”，[在线]。可用：https://oauth.net/2/。[2021 年 6 月 20 日访问]。

[9] Mozilla，“跨源资源共享”，Mozilla 公司，[在线]。可用：https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS。[2021 年 6 月 20 日访问]。

[10] I. Netflix，“尤里卡源代码”，[在线]。可用：https://github.com/Netflix/eureka。[2021 年 6 月 20 日访问]。

[11] M.福勒。[在线的]。可用：https://martinfowler.com/bliki/CircuitBreaker.html。[2020 年 6 月 20 日访问]。

[12] C. Richardson，“微服务架构”，[在线]。可用：https://microservices.io/patterns/observability/application-logging.html。[2021 年 6 月 20 日访问]。