Skip to main content

为什么应该将 API 网关放在一切事物的前面

作者 吉耶·奥赫达

2023 年 12 月 18 日

关注点分离。说真的，标题不是点击诱饵，这就是答案。我以前从未使用过点击诱饵策略，以后也不会再使用它们。

每个 API 都有一些需要解决的问题，例如身份验证、输入验证、速率限制、访问数据库等。其中一些问题与代码应该为业务执行的操作有关，例如将数据存储在数据库中。其中一些问题与将代码公开为 API 有关，例如身份验证。API 网关的整个想法是将这些问题分为源于增加业务价值的问题和源于将业务价值公开为 API 的问题，并配置一个名为 API 网关的组件来处理与将代码公开为 API 相关的所有问题。这个想法并不是完全原创的，Spring（Java）、Flask（Python）或 Nest.js（JavaScript）等框架正是这样做的，只不过是在代码级别。API 网关组件（例如 Amazon API Gateway（AWS 的 API 网关服务））在基础设施级别执行此操作，从而进一步解耦这些问题。

还是不相信？这里有 3000 字的解释。

什么是 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 的职责集中在一个地方，针对所有服务的所有以 API 形式公开的行为。

管理 API 是一个复杂的问题，我想说清楚这一点。API 网关并不能自动解决这个问题，但它确实将所有这些责任集中在一个地方，使问题更易于管理。

Amazon API Gateway 的功能​

Amazon API Gateway 是 AWS 的托管 API 网关服务。它提供以下功能：

  • 支持 RESTful API 和 WebSocket API

  • 与 AWS 服务集成

  • 高可用性和弹性

  • 轻松创建和部署 API

  • API 操作监控

  • 身份验证和授权

让我们深入了解一下它们，看看 Amazon API Gateway 是如何工作的。

支持 RESTful API 和 WebSocket API​

Amazon API Gateway 将对 RESTful API 的支持分为两种方式：HTTP API 和 REST API。HTTP API 是易于使用且经济高效的方式。它们针对无服务器工作负载和 HTTP 后端系统进行了优化，与 REST API 相比，成本可以降低 70%，延迟可以减少 60%。不过，它们的功能比较有限。

REST API 专为需要更多功能（而不仅仅是 API 代理）的工作负载而设计，例如使用计划、API 密钥、缓存、日志记录或跟踪。它们的设置稍微复杂一些，因为它们功能更强大，而且比简单的 HTTP API 更昂贵。建议：查看此处的差异，然后如果您需要 HTTP API 未提供的至少一个功能，请使用 REST API。如果您不需要任何这些很酷的功能，请使用 HTTP API。

最后，我们有 WebSocket API。这里的一般建议是，当您使用 WebSocket 时，请使用 WebSocket API。很简单，对吧？仅供参考，websockets 是一种双向通信协议，可在前端和后端之间保持轻量级连接，允许后端将信息发送到前端，而无需前端发送请求。最明显的用例是通知：您无需让前端每隔 X 秒轮询一次新消息，只需打开 websocket，当新消息到达时，后端就可以通知前端。

与 AWS 服务集成​

显然，API Gateway 可以与 HTTP 后端集成。但它也与许多 AWS 服务进行了本机集成。Amazon API Gateway 的集成类型如下：

AWS：此类型允许您公开 AWS 服务操作。您已配置集成请求和集成响应，并设置了从方法请求到集成请求以及从集成响应到方法响应的必要数据映射。

AWS_PROXY：借助此功能，您可以通过灵活、多功能且简化的集成设置将 API 方法与 Lambda 函数调用操作集成。此集成依赖于客户端与集成 Lambda 函数之间的直接交互。它也称为 Lambda 代理集成。您无需设置集成请求或集成响应。相反，API Gateway 将传入的客户端请求作为输入传递给后端 Lambda 函数。集成的 Lambda 函数接受此格式的输入并从所有可用源解析输入，包括请求标头、URL 路径变量、查询字符串参数和适用正文。该函数按照此输出格式返回结果。此集成类型是与 AWS Lambda 集成的最佳方式。

HTTP：这可让您通过 API 网关在后端公开 HTTP 端点。您需要配置集成请求和集成响应，并设置从方法请求到集成请求以及从集成响应到方法响应的必要数据映射。此集成也称为 HTTP 自定义集成。顺便说一句，不要将其与 HTTP API 混淆，它们是不同的概念，只是恰好共享名称。

HTTP_PROXY：此集成类型的工作方式与 HTTP 非常相似，允许您在后端公开 HTTP 端点，但更加精简。您无需设置集成请求或集成响应，API Gateway 将客户端的传入请求传递到 HTTP 端点，并将 HTTP 端点的传出响应传递到客户端。当然，这会带来较少的灵活性，但大多数时候您不需要 HTTP 集成的灵活性。

MOCK：通过 MOCK 集成，您可以让 API Gateway 返回响应，而无需将请求发送到任何后端。这样，您就可以设置和测试带有模拟响应的 API，而无需为其设置模拟后端。如果您正在进行 API 驱动的开发，这将非常有益。

高可用性和弹性​

API Gateway 旨在实现大规模扩展。事实上，根据 AWS 文档：“API Gateway 可处理 API 收到的任何级别的流量”。显然，它具有高可用性（意味着多个可用区域），并且由于它是一种托管服务，因此您无需执行任何工作即可实现这一点，只需创建一个 API 并享受其好处即可。现在，即使您知道 API Gateway 不会成为瓶颈，您仍然需要保护您的后端。API Gateway 可以通过两种方式提供帮助：缓存和速率限制。

缓存意味着请求和响应都保存在键值存储中，当相同的请求再次出现时，API Gateway 将使用存储的响应值进行响应，而不是将请求发送到后端以重新计算该值。您可以为缓存设置生存时间 (TTL)，当它过期时，API Gateway 将表现得像没有缓存响应一样，如果相同的请求再次出现，它将把它发送到后端。

速率限制允许您强制限制每分钟发送到后端的最大请求数，这有助于避免后端不堪重负。不接受超出您处理能力的流量是一种称为负载削减的策略，使用 API 网关可以减轻后端和开发人员的负担，因为他们不需要手动实现它。此外，如果您使用 API 密钥，则可以对每个密钥应用限制。这在 SaaS 应用程序中尤其有用，因为您需要避免单个客户使用过多资源并影响其他客户的性能（这称为嘈杂邻居问题）。

轻松创建和部署 API​

像 Amazon API Gateway 这样的服务的核心点之一是易于使用。现在，简单总是相对的，而且由于具有如此多功能的 API 管理是一个复杂的问题，因此解决方案本身也会很复杂。但是使用 Lambda 代理集成和 HTTP 代理集成等集成类型，您无需担心那么多事情。

API 操作监控​

API Gateway 为您提供了一个仪表板来监控 API 中的活动。API Gateway 控制台与 Amazon CloudWatch 集成，因此它还将显示后端指标，如 API 调用、延迟和错误率。由于 API Gateway 使用 CloudWatch 作为自己的指标，因此您可以为来自 API Gateway API 的指标设置 CloudWatch 警报。API Gateway 还可以将 API 执行错误记录到 CloudWatch Logs，这对调试非常有帮助。

身份验证和授权​

正如我之前提到的，使用 API 网关的最好之处之一是您可以将身份验证和授权等职责转移给它。以下是您可以在 Amazon API Gateway 中使用的身份验证和授权机制：

您可以创建基于资源的策略来允许或拒绝访问 API 和 API 方法，并且可以包含源 IP 地址或 VPC 端点等条件。

您还可以使用AWS IAM 角色和策略来控制谁可以创建和管理 API 以及谁可以调用它们。查看我之前关于 IAM 的文章，以更好地了解 IAM 权限的工作原理。

您还可以使用Lambda 授权程序，它们是使用持有者令牌身份验证控制对 REST API 方法的访问的 Lambda 函数。您还可以使用标头、路径、查询字符串、阶段变量或上下文变量请求参数。如果您使用除Amazon Cognito以外的任何身份提供商，则可以使用这些。

最后，如果您使用的是Amazon Cognito 用户池，则可以使用 API Gateway 与 Cognito 的直接集成来创建Cognito 授权者。 它将实现与创建调用 Cognito API 的 Lambda 授权者相同的结果，但无需创建调用 Cognito API 的 Lambda 授权者。

AWS 无服务器架构中的 Amazon API Gateway​

Amazon API Gateway 是 AWS 无服务器架构中的关键组件。它允许您通过可以像 AWS Lambda 函数一样快速扩展的服务来公开 AWS Lambda 函数，并且允许您添加 API 安全性、身份验证、监控以及我们在本文中讨论过的所有其他功能。

此外，Amazon API Gateway 本身是无服务器的：作为托管服务，您只需创建一个 API 并从那里管理配置，而不必担心最终执行这些配置的底层服务。

通过 API Gateway 与 AWS 服务的集成，您甚至可以直接访问 DynamoDB 或 Amazon Kinesis，并包含身份验证功能和 API 密钥来控制这些访问，但无需创建仅传递信息的 Lambda 函数。

总体而言，API Gateway 允许您为应用程序构建多项服务，并以可控、功能丰富且可管理的方式公开它们。

API 网关和微服务架构​

微服务由其有界上下文定义，其中包括数据。使服务成为微服务的关键点在于，访问数据和功能的唯一方法是通过微服务公开的 API。这样，服务只依赖于其他服务的 API，而不依赖于代码或数据的实现细节（甚至不依赖于数据存储或数据结构）。这一点，加上独立部署服务，就是您应该使用微服务的全部原因（如果这不是问题，您不应该使用微服务）。

希望这足以说明 API 管理在微服务架构中的重要性。如果没有，让我们歌颂它。当我说微服务时，你说的是 API。微服务！（这是你说 API 的部分）。

任何微服务架构，只要能做点有用的事，可能至少有十几个微服务，也就是说至少有十几个 API。这应该很难维护，但微服务中 API 网关的最大好处不是让 API 更容易使用。它实际上集中了这些功能和更改，因此您可以允许不同的团队拥有每个微服务的行为和 API，但不必担心协调多个团队如何实现速率限制等 API 功能。每个 API（和每个微服务）都可以有自己的身份验证、授权、速率限制、API 密钥、缓存等配置。但配置会发生变化，您如何在所有微服务（和所有团队）中实现这些配置保持一致。这是最大的价值。

如果您想了解有关微服务的更多信息，请查看AWS 中的微服务：从整体迁移。

结论​

总结：为什么应该将 API 网关放在一切的前面？将与交付业务价值相关的责任和与通过 API 公开该业务价值相关的责任分开，这样您就可以集中后者并 DRY（不要重复自己）。如果您只公开几个 API，这不是一个大问题，但随着系统的增长，它们变得越来越难以管理，您会梦想拥有一个 API 网关。在整体中，常见的编程框架将允许您在代码级别分离这些职责。当您构建分布式系统（包括但不限于微服务）时，您不希望在所有服务中重复该配置，并且您希望将 API 的部署和扩展与实现行为的后端的部署和扩展分开。

此外，如果组件仅依赖于 API，并且 API 网关封装了 API，那么您可以自由更改实现 API 的后端。在使用落后者模式从整体迁移到服务时，这种情况非常常见：您将要移动的行为隔离到单独的服务，在其前面放置一个指向整体的 API 网关，创建一个实现与整体不同的行为的服务，然后将 API 网关指向新服务。

source: Why You Should Put API Gateway In Front Of Everything