什么是 API 网关？

什么是网关？它是一个入口点。所有东西都从这里进入。人员、流量、 请求等等。如果你曾经接触过微服务，你可能听说过“API 网关”这个术语。

虽然 API 网关并非微服务独有，但自其兴起以来，它的受欢迎程度与日俱增。那么，API 网关到底是什么呢？

基础知识

API 网关是位于客户端与其所依赖服务之间的一层。有时也称为“反向代理”，它们充当从客户端到其服务的单一入口点。

它们就像办公楼前的接待台，负责转接电话、拦截不速之客、确保包裹送达正确地点。

如果您以前使用过第三方 API，则可能您正在与网关进行通信，而网关又与服务的内部 API 进行通信。

正如我们将在下面的优势部分讨论的那样，这允许提供商将其 API 的部分内容公开给外界，并在一个中心位置处理版本控制、安全性、区域本地化等问题。想象一下 Google 公开日历 API，或者 Twitter 对外提供其时间线 API 的不同版本。

API 网关最常见的用例是路由。它如下所示：

1. 客户端向网关发送请求。
2. 网关处理并将请求发送给服务。
3. 服务响应网关。
4. 网关处理响应并将其发送给客户端。

客户端可以是很多东西。在上面提到的原始实现中，客户端是 API 提供商的客户，但 API 网关也可以将内部 API 暴露给您自己的客户端。在许多现代 Web 应用程序中，“客户端”是单页应用程序 (SPA)，但它也可以是 Web 应用程序的后端服务器、原生移动应用，甚至是智能电视、媒体播放器和物联网设备。无论客户端是由您控制的还是由您的客户拥有的，网关都会管理和暴露 API 接口。

这些服务通常是应用程序控制的内部服务，例如数据库或微服务。网关还可以位于任何第三方 API 和应用程序客户端之间。这使得您的客户端能够以访问内部服务的方式访问第三方数据。

网关不会强制客户端了解每个 API 或服务的工作原理，而是公开一个统一的 API 供客户端交互。客户端的开发可以独立于服务端可能发生的任何变更。如果业务需求发生变化，只要将新服务映射到现有接口，就可以更换服务。例如，如果应用程序使用第三方 API 进行用户身份验证，并希望将其更改为内部服务，只要新服务映射到实现，客户端就不会受到影响。

传统与“后端为前端”

API 网关主要有两种变体：传统网关和“前端后端”。两者的用途相同，但实现方式不同。

传统的 API 网关会处理来自应用程序所有客户端的请求。例如，流媒体视频服务的网关会处理来自 Web、电视、手机和平板电脑的请求。

不要误以为这种变体很简单。在很多情况下，它会根据客户端的需求为其提供独特的 API。例如，语音界面可能不需要像传统 Web 界面那样获取完整的数据。这样一来，最终的客户端 API 会更加精简。GraphQL试图解决同样的问题，但不同的是，它让客户端可以自行控制所需的数据量。

同一流服务网关的“前端后端”变体为每个客户端设置了单独的 API 网关。与路由客户端请求的大型网关不同，每个较小的网关都独立于其他客户端网关与所有必要的服务进行交互。

API 网关的主要优势

前面我提到过，核心用例是路由。路由的诸多好处都集中在将实现细节从客户端抽象出来，并将它们集中在一个地方——网关。网关可以处理各种共享任务，例如：

• 身份验证和授权：这可以像确保用户有权访问资源一样简单，也可以像处理完整的身份验证流程一样复杂。
• 处理和验证输入：在将客户端数据发送到服务之前，可以对其进行验证和处理。这避免了客户端处理数据带来的开销。
• 转换响应：正如网关可以在将数据发送到第三方 API 或微服务之前对其进行处理一样，它也可以在将响应发送到客户端之前对其进行转换。在上面的示例中，这可以确定特定客户端需要哪种数据形状。
• 遥测：网关充当管理所有日志记录和指标收集的中心点。由于所有请求和响应都经过这个中心点，因此它成为引入遥测工具的宝贵场所。
• 服务混淆：通过将服务与客户端分离，API 网关不仅可以保护服务免受客户端问题的影响，还能允许客户端和服务彼此独立存在。服务的更改或替换不会直接影响客户端。

API 网关的缺点

从优点来看，API 网关似乎是一个简单的选择，但它也有缺点。

与任何堆栈扩展一样，API 网关也需要额外管理。它们需要像其他软件一样进行托管、扩展和管理。由于所有请求和响应都必须经过网关，因此它们会额外增加故障点，并通过在网络上增加几个额外的“跳数”来增加每次调用的延迟。

由于网关的集中位置，很容易逐渐增加网关内部的复杂性，直到它变成代码的“黑匣子”。这使得代码维护更加困难。

这种“把所有东西放在一起”的方法违背了使用微服务将应用程序拆分成更小部分的核心思想，并消除了它们的部分自主性。

这些问题大多是可以避免的，但需要付出一些努力。

API 网关与服务网格的关系

网关允许客户端访问服务，但是当服务之间需要通信时会发生什么呢？这时服务网格就派上用场了。服务网格是一个专注于服务间通信的层。网关通信通常被描述为南北向（从客户端到网关），而服务网格通信通常被描述为东西向（服务之间）。

传统上，将服务网格和 API 网关结合使用是合理的。网关是客户端请求的入口点，服务网格则允许服务相互依赖，然后将响应传递回网关。Kong 是一个流行的 API 网关，它发布了一个开源网格来与其网关产品配套。

过去几年，服务网格已扩展其功能以处理外部通信。其中一个流行的网格Istio现在包含一些网关功能。预计随着时间的推移，许多服务网格产品将采用网关的许多核心功能。

第三方 API 在哪里发挥作用？

我们之前提到过，第三方 API 的访问也可以通过网关进行。这非常适合您直接从客户端使用第三方 API，但又不想引入其他依赖项和新的 API 接口的情况。

缺点是什么？现在您需要处理依赖第三方时不可避免的中断和停机。如果像Bearer这样的主动监控工具发现现有 API 存在问题，它可以直接响应网关。可以通过切换到备用资源、提供缓存数据、重试或任何其他弹性措施来响应。

您的应用在使用第三方服务时是否面临弹性问题？立即试用Bearer并通过@BearerSH联系我们

📢什么是 API 网关最初发布在 Bearer 博客上。