前端扫盲：什么是API网关？为什么它有用？

API 通常被称为应用程序从后端服务访问数据和业务逻辑的前门。API 本质上是一个软件向其他人或程序提供的接口，允许他们与该软件进行交互。

在创建 API 时，需要选择编程语言(Java、Python、PHP 等)来编写 API 逻辑，还需要将 API 部署到服务器上，并监控 API，以确保基础设施有足够的能力处理大量请求。

API网关将这些步骤抽象出来，你不需要编写太多代码，也不用担心管理底层基础设施，你只需要创建客户端可以发送请求的API端点。

主要的云提供商都提供完全托管的API网关服务：

AWS API 网关
GCP API网关
Azure API管理

本文将解释为什么应该使用 API 网关，它们是如何工作的，我们将查看实际应用中的 API 网关示例。

我们将介绍的内容：

文章目录

- 1.为什么要使用API网关？
- 2.API网关的工作原理
- - 2.1 请求验证
  - 2.2 授权和认证
  - 2.3 速率限制
  - 2.4 请求路由
  - 2.5 请求和响应转换
- 3.真实世界的例子
- End

1.为什么要使用API网关？

在这里插入图片描述

API网关（API Gateway）是一种完全托管的服务，它使开发人员能够更轻松地创建、发布、维护、监控和保护几乎任何规模的API。

在云计算环境中，“完全管理”是指服务的维护和管理责任由云提供商负责，这意味着底层基础设施、软件更新、安全、可扩展性、可用性和灾难恢复都由云提供商管理。

这种抽象主要让开发人员的工作变得更容易，因为他们只需专注于开发服务，而不必担心管理它。

在这种情况下，这种抽象的代价是灵活性的损失，大多数云提供商提供的API网关对每秒处理的请求数量(RPS)有一个硬限制。

使用 API 网关等托管服务的云成本也较高，必须与从头开始构建 API 所需的较高开发人员天数（开发人员数量 * 工作天数）进行权衡。

为了真正理解使用 API Gateway 的好处，让我们来看看设计、编写和部署传统 API 所需遵循的步骤：

步骤1：定义需求和范围

了解目标用户或系统的需求。
确定API将公开的数据和功能。

步骤2：设计API

定义API端点和方法(GET、POST、PUT、DELETE)。
设计请求和响应格式(通常是 JSON 或 XML)。
指定API将与之交互的数据模型和资源。
计划错误处理和状态代码。

步骤3：开发API

选择编程语言和框架。
按照设计阶段定义的 API 端点进行实现。
根据需要与数据库或其他服务集成。
确保安全实践得到实施，如输入验证和速率限制。

步骤4：部署API

选择托管解决方案(云提供商，现场服务器)。
设置部署环境。
将 API 部署到服务器。

步骤5：监控和维护API

监控 API 的正常运行时间、性能和错误。
定期更新API以修复错误和补丁安全漏洞

使用 API 网关，您主要需要关注步骤 1、步骤 2 和步骤 3 的部分内容，其他步骤大多被抽象出来并由 API 网关处理。

使用 API 网关的主要原因是简化开发和维护 API 的过程。

2.API网关的工作原理

API网关同时做很多事情。

为了理解 API 网关的工作原理，我们来打个比方。

API网关就像maître d’(法语，意思是领班服务员)，maître d’通常出现在高档餐厅，尽管这是一个正在慢慢消失的职业。

领班是客人和餐厅员工之间的联络人，负责：

问候和安排座位：领班通常是客人到达餐厅时遇到的第一个人。他们热情地欢迎客人，询问预订情况，并协助客人就座，考虑到偏好和特殊要求。
预订：领班负责管理预订，确保桌子被有效分配。他们跟踪可用的桌子和预订时间，做出必要的调整以满足客人的需求。
管理等待时间：在繁忙时期，领班通过提供预计等待时间和提供替代方案，如在酒吧或等候区为客人安排座位，来管理客人的等待时间。
解决问题：如果客人用餐期间出现任何问题或顾虑，领班应及时介入并解决问题，确保客人满意。
处理特殊要求：如果客人有特殊要求或饮食限制，领班会将这些信息传达给厨房，并确保客人的需求得到满足。

简而言之，领班是餐厅里一个拥有多种才能和职责的人，从下面的图片中，我们可以看到领班是如何作为顾客和他们可能需要的沟通者。

领班是顾客和他们可能需要的任何东西之间的沟通者

API网关的工作方式类似，它充当客户机与其可能需要访问的许多服务之间的通信器。

API网关充当客户机和它们可能需要访问的许多服务之间的中间人

让我们更详细地研究一下API网关能做什么。

2.1 请求验证

这包括检查传入的请求，以确认它们在转发到后端服务之前符合预定义的标准。

这可能包括检查请求的结构、验证数据类型、确保存在所需的参数，以及根据模式验证查询参数、头和请求体。

通过这样做，API网关作为第一道防线，防止格式不规范或恶意请求到达后端系统。

用餐厅的比喻，这类似于在餐厅门口等待迎接客人的领班，但记住，这是一个高档餐厅，所以领班要确保客人的着装符合餐厅的着装规范 —— 类似于根据预定义的模式验证传入的 API 请求。

2.2 授权和认证

身份验证是验证发出请求的用户或服务的身份的过程，通常通过用户名和密码、令牌或 API 密钥等凭据进行验证。

通过身份验证后，授权将决定已通过身份验证的实体有权访问或执行哪些资源或操作。

API网关通常与身份提供者集成，并支持各种身份验证和授权机制，如OAuth、JWT、API密钥等。它们确保只有合法的、授权的请求才能通过后端服务。

身份验证关注的是“谁”，而授权关注的是“权限”。

对于迎接客人进入餐厅的领班来说，身份验证涉及到客人证明他们就是自己所说的那个人，通常是通过出示某种形式的身份证件，其中的照片可以与他们的脸匹配。

授权将涉及检查他们是否有预约，也就是说他们有权进入餐厅点餐。

2.3 速率限制

速率限制涉及到控制用户或服务在指定时间范围内可以发出的请求数量，通常定义为每秒请求数量的限制(RPS)。

速率限制有助于避免后端服务的过载，确保它们仍然可用。速率限制也被用作成本控制策略的一部分，因为您将为发送到 API 网关的每个请求付费。

API网关可以根据访问的用户、服务或端点实施不同的速率限制策略。

以我们的餐厅类比为例，想象一下我们的餐厅里有客人，他们都经过了验证、认证和授权进入餐厅。但是这些客人特别饥饿和口渴，不断点餐和饮料。在某个时刻，这对餐厅来说变得难以管理。厨师和服务员过度劳累，没有能力接受任何新的订单，盘子和餐具都用完了，厨房里的食物也快用完了。

主厨可以介入并限制顾客的订单数量，例如，限制每小时可以点的主菜或葡萄酒的数量，限额限制可以确保餐厅不会超负荷，仍然能够为新顾客服务。

2.4 请求路由

API 网关根据 URL 路径、HTTP 方法、标头或查询参数等各种条件管理传入请求到适当后端服务的路由。它是微服务架构不可或缺的一部分，其中不同的服务处理 API 的不同部分。

回到我们之前的餐厅比喻，根据客人的目的，领班会将他们引向合适的人或地方——用餐者引向服务员，只想喝酒的客人引向吧台，询问预订餐厅活动的人引向活动协调员。

2.5 请求和响应转换

这涉及到在请求和响应通过 API 网关时对其进行修改。

对于请求，这可能意味着添加、删除或修改头部、重写 URL，甚至更改请求体。对于响应，这可能涉及更改状态代码、修改头部或转换体。

这种功能允许 API 网关作为一个中介，可以转换请求和响应，以满足客户机和后端服务的需求。

后端服务也可以执行这种请求和响应转换。关于哪个组件(API网关或后端服务)进行转换的决定是主观的。但是，API网关通常是一个理想的地方，以最小的努力集中这种转换，而不是在每个后端服务中进行自定义转换。

例如，如果餐厅的客人不耐麸质，那么他们的订单就必须改变，以确保餐点不含任何麸质。

这种订单转换的逻辑可以通过领班在把订单发给主厨之前明确地指出哪些食材应该被排除在菜单之外来实现，也可以在厨房里通过领班简单地告诉主厨客人点了一道无麸质菜肴，并让他相应地修改订单来实现。

3.真实世界的例子

微服务架构是一种开发软件的方法，它将大型应用程序分解为更小的、独立的组件，称为微服务。每个微服务都是一个自包含的单元，在更广泛的应用程序中具有特定的功能或责任。

下图显示了一个基本的电子商务应用程序的简单微服务架构。

电子商务网站微服务架构中使用的API网关

客户端：这些是与电子商务平台交互的不同客户端。它们可以是移动应用程序、网页浏览器或任何其他第三方应用程序。
API网关：作为所有类型客户机的单一入口点，它根据请求的性质(与用户相关、与产品相关、与订单相关)将请求路由到适当的微服务。
服务：这些是电子商务网站特定的微服务示例。每个服务处理业务逻辑的不同方面，如用户配置文件、产品目录和订单处理。
数据库：每个微服务都有自己的专用数据库，确保数据隔离和服务独立性。

在这个例子中，API网关是：

确保每个客户的请求都经过验证
确保客户在进行一些操作(如订购或撰写产品评论)之前得到身份验证和授权。
速率限制请求，以确保服务不会因发送大量请求的恶意行为而关闭。
根据不同的条件(如 URL 路径、HTTP 方法、头部或查询参数)将客户机请求路由到适当的后端服务。
处理请求和响应转换。例如，来自 Product Service 的响应可能具有复杂的格式和广泛的细节。API 网关将此响应转换为更适合移动应用程序的格式。这可能涉及简化数据，将其转换为更轻的格式，或仅提取移动应用程序所需的基本信息。