API 通常被称为应用程序从后端服务访问数据和业务逻辑的前门。API 本质上是一个软件向其他人或程序提供的接口,允许他们与该软件进行交互。
在创建 API 时,需要选择编程语言(Java、Python、PHP 等)来编写 API 逻辑,还需要将 API 部署到服务器上,并监控 API,以确保基础设施有足够的能力处理大量请求。
API网关将这些步骤抽象出来,你不需要编写太多代码,也不用担心管理底层基础设施,你只需要创建客户端可以发送请求的API端点。
主要的云提供商都提供完全托管的API网关服务:
本文将解释为什么应该使用 API 网关,它们是如何工作的,我们将查看实际应用中的 API 网关示例。
我们将介绍的内容:
API网关(API Gateway)是一种完全托管的服务,它使开发人员能够更轻松地创建、发布、维护、监控和保护几乎任何规模的API。
在云计算环境中,“完全管理”是指服务的维护和管理责任由云提供商负责,这意味着底层基础设施、软件更新、安全、可扩展性、可用性和灾难恢复都由云提供商管理。
这种抽象主要让开发人员的工作变得更容易,因为他们只需专注于开发服务,而不必担心管理它。
在这种情况下,这种抽象的代价是灵活性的损失,大多数云提供商提供的API网关对每秒处理的请求数量(RPS)有一个硬限制。
使用 API 网关等托管服务的云成本也较高,必须与从头开始构建 API 所需的较高开发人员天数(开发人员数量 * 工作天数)进行权衡。
为了真正理解使用 API Gateway 的好处,让我们来看看设计、编写和部署传统 API 所需遵循的步骤:
步骤1:定义需求和范围
步骤2:设计API
步骤3:开发API
步骤4:部署API
步骤5:监控和维护API
使用 API 网关,您主要需要关注步骤 1、步骤 2 和步骤 3 的部分内容,其他步骤大多被抽象出来并由 API 网关处理。
使用 API 网关的主要原因是简化开发和维护 API 的过程。
API网关同时做很多事情。
为了理解 API 网关的工作原理,我们来打个比方。
API网关就像maître d’(法语,意思是领班服务员),maître d’通常出现在高档餐厅,尽管这是一个正在慢慢消失的职业。
领班是客人和餐厅员工之间的联络人,负责:
简而言之,领班是餐厅里一个拥有多种才能和职责的人,从下面的图片中,我们可以看到领班是如何作为顾客和他们可能需要的沟通者。
API网关的工作方式类似,它充当客户机与其可能需要访问的许多服务之间的通信器。
让我们更详细地研究一下API网关能做什么。
这包括检查传入的请求,以确认它们在转发到后端服务之前符合预定义的标准。
这可能包括检查请求的结构、验证数据类型、确保存在所需的参数,以及根据模式验证查询参数、头和请求体。
通过这样做,API网关作为第一道防线,防止格式不规范或恶意请求到达后端系统。
用餐厅的比喻,这类似于在餐厅门口等待迎接客人的领班,但记住,这是一个高档餐厅,所以领班要确保客人的着装符合餐厅的着装规范 —— 类似于根据预定义的模式验证传入的 API 请求。
身份验证是验证发出请求的用户或服务的身份的过程,通常通过用户名和密码、令牌或 API 密钥等凭据进行验证。
通过身份验证后,授权将决定已通过身份验证的实体有权访问或执行哪些资源或操作。
API网关通常与身份提供者集成,并支持各种身份验证和授权机制,如OAuth、JWT、API密钥等。它们确保只有合法的、授权的请求才能通过后端服务。
身份验证关注的是“谁”,而授权关注的是“权限”。
对于迎接客人进入餐厅的领班来说,身份验证涉及到客人证明他们就是自己所说的那个人,通常是通过出示某种形式的身份证件,其中的照片可以与他们的脸匹配。
授权将涉及检查他们是否有预约,也就是说他们有权进入餐厅点餐。
速率限制涉及到控制用户或服务在指定时间范围内可以发出的请求数量,通常定义为每秒请求数量的限制(RPS)。
速率限制有助于避免后端服务的过载,确保它们仍然可用。速率限制也被用作成本控制策略的一部分,因为您将为发送到 API 网关的每个请求付费。
API网关可以根据访问的用户、服务或端点实施不同的速率限制策略。
以我们的餐厅类比为例,想象一下我们的餐厅里有客人,他们都经过了验证、认证和授权进入餐厅。但是这些客人特别饥饿和口渴,不断点餐和饮料。在某个时刻,这对餐厅来说变得难以管理。厨师和服务员过度劳累,没有能力接受任何新的订单,盘子和餐具都用完了,厨房里的食物也快用完了。
主厨可以介入并限制顾客的订单数量,例如,限制每小时可以点的主菜或葡萄酒的数量,限额限制可以确保餐厅不会超负荷,仍然能够为新顾客服务。
API 网关根据 URL 路径、HTTP 方法、标头或查询参数等各种条件管理传入请求到适当后端服务的路由。它是微服务架构不可或缺的一部分,其中不同的服务处理 API 的不同部分。
回到我们之前的餐厅比喻,根据客人的目的,领班会将他们引向合适的人或地方——用餐者引向服务员,只想喝酒的客人引向吧台,询问预订餐厅活动的人引向活动协调员。
这涉及到在请求和响应通过 API 网关时对其进行修改。
对于请求,这可能意味着添加、删除或修改头部、重写 URL,甚至更改请求体。对于响应,这可能涉及更改状态代码、修改头部或转换体。
这种功能允许 API 网关作为一个中介,可以转换请求和响应,以满足客户机和后端服务的需求。
后端服务也可以执行这种请求和响应转换。关于哪个组件(API网关或后端服务)进行转换的决定是主观的。但是,API网关通常是一个理想的地方,以最小的努力集中这种转换,而不是在每个后端服务中进行自定义转换。
例如,如果餐厅的客人不耐麸质,那么他们的订单就必须改变,以确保餐点不含任何麸质。
这种订单转换的逻辑可以通过领班在把订单发给主厨之前明确地指出哪些食材应该被排除在菜单之外来实现,也可以在厨房里通过领班简单地告诉主厨客人点了一道无麸质菜肴,并让他相应地修改订单来实现。
微服务架构是一种开发软件的方法,它将大型应用程序分解为更小的、独立的组件,称为微服务。每个微服务都是一个自包含的单元,在更广泛的应用程序中具有特定的功能或责任。
下图显示了一个基本的电子商务应用程序的简单微服务架构。
在这个例子中,API网关是:
API网关是一种完全托管的服务,它使开发人员能够更轻松地创建、发布、维护、监控和保护几乎任何规模的API,由于是完全托管的,它抽象了管理和维护底层基础设施所需的工作——这由提供服务的云提供商处理。
API网关充当客户机和许多需要访问的服务之间的中间人,它处理请求验证、身份验证和授权、速率限制、请求路由和请求/响应转换。
它在微服务架构中特别有用,作为管理、处理和将传入请求路由到适当微服务的中心入口点,在简化客户端交互和为一组微服务提供中心接口方面发挥着至关重要的作用。