API网关简介

什么是网关？ 这是一个入口点。 事情进来了。 人，交通， 需求 。 如果您花了很多时间在微服务上，那么您可能会遇到“ API网关”一词。

自微服务兴起以来，API网关虽然不是微服务特有的，但它的普及程度却在增长。 那么API网关到底是什么？

基础

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

他们是办公大楼前的接待台。 路由呼叫，阻止意外的访客并确保包裹到达正确的位置。

如果您过去使用过第三方API，则可能与网关通信，而网关又与服务的内部API通信。

正如我们将在下面的好处部分中讨论的那样，这允许提供程序将API的某些部分暴露给外界，并在一个集中位置处理版本控制，安全性，区域本地化等。 想想Google公开日历的API或Twitter在外部提供其时间表API的版本。

API网关最常见的用例是路由。 它是这样的：

• 客户端向网关发送请求。
• 网关处理请求并将其发送到服务。
• 服务响应网关。
• 网关处理响应并将其发送到客户端。

客户可以做很多事情。 在上述原始实现中，客户端是API提供者的客户，但是API网关也可以向您自己的客户端公开内部API。 在许多现代Web应用程序中，“客户端”是单页应用程序（SPA），但它也可以是Web应用程序的后端服务器，本机移动应用程序，甚至是智能电视，媒体播放器和IoT设备。 无论是您控制的客户还是客户拥有的客户，网关都会管理并公开API界面。

这些服务通常是您的应用程序控制的内部服务，例如数据库或微服务。 网关也可以位于任何第三方API和您的应用程序的客户端之间。 这样一来，您的客户就可以像访问内部服务一样访问第三方数据。

网关没有强迫客户端知道每个API或服务的工作方式的细节，而是公开了客户端可以与之交互的单个统一API。 可以独立于服务端可能发生的任何变化来开发客户端。 只要业务需求发生变化，只要新服务映射到现有接口上，服务也可以交换进出。 例如，如果应用程序使用第三方API进行用户身份验证并希望更改为内部服务，则只要新服务映射到实现，客户端就不会受到影响。

传统与“后端的后端”

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

传统的API网关处理来自所有应用程序客户端的请求。 例如，用于流视频服务的网关将全部处理来自Web，电视，电话和平板电脑的请求。

不要将这种变化简单地误认为是。 在许多情况下，它将根据每种客户端的需求为每种客户端类型提供唯一的API。 例如，语音界面可能不需要传统Web界面所需要的全部数据。 由此产生的客户端API将更加精简。 GraphQL试图解决同样的问题，但是让客户控制他们想要多少数据。

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

API网关的主要优点

之前我提到核心用例是路由。 该好处和许多好处都围绕着抽象实现细节，而使实现细节远离客户端本身，并将其保留在一个位置（网关）中。 网关可以处理各种共享任务，例如：

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

API网关的缺点

基于优点，API网关似乎是一个容易的选择，但是也有缺点。

与堆栈中的任何其他内容一样，API网关引入了另一个要管理的部分。 与其他软件一样，它们需要托管，扩展和管理。 由于所有请求和响应都必须通过网关，因此它们会增加一个额外的故障点，并通过在网络上添加一些额外的“跳跃”来增加每个呼叫的延迟。

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

这种“全力以赴”的方法违背了使用微服务将应用程序拆分成较小部分并消除其部分自治的核心思想。

这些问题大部分是可以避免的，但需要一些工作。

API网关与服务网格的关系

网关允许客户端访问服务，但是当服务需要彼此通信时会发生什么？ 这就是服务网格的来源。 服务网格是一个专注于服务到服务通信的层。 您将看到网关通信描述为南北（从客户端到网关），服务网格通信描述为东西向（服务之间）。

传统上，将服务网格和API网关一起使用是有意义的。 网关将是客户请求的入口点，然后服务网格将允许您的服务在通过网关传递响应之前相互依赖。 一种流行的API网关Kong发行了一个开放源代码网格以与其网关产品配对。

在过去的几年中，服务网格已经扩展了其功能以处理外部通信。 一种流行的网格Istio现在包括一些网关功能。 预计随着时间的流逝，许多服务网格产品将具有网关的许多核心功能。

第三方API进入哪里？

前面我们提到过，对第三方API的访问也可以在您的网关后面进行。 对于您直接从客户端使用第三方API但又不想引入其他依赖关系和新API表面的情况，这非常有用。

不足之处？ 现在，您需要处理依赖第三方时不可避免的停机和停机时间。 如果活动监控工具（如Bearer ）注意到现有API的问题，则它可以直接响应网关。 通过交换到备用资源，提供缓存的数据，重试或任何其他数量的弹性措施。

post本文最初由 Mark Michon 在 Bearer Blog 上 撰写

From: https://hackernoon.com/introduction-to-api-gateway-rt5o3646