用开源API网关实现可伸缩API

用开源API网关实现可伸缩API

本文为你详解用开源API网关实现可伸缩API的内容，下面IT袋网为您详细介绍

API 网关是一个单一节点，提供对 API调用入口

。网关聚合了所请求的服务，并相应传回合适的响应信息。

为了令你的 API 网关有效地工作，设计一个可靠、高效且简洁地 API 至关重要。

本文介绍一种设计风格，但只要你理解其中的重点内容，它就能解决你的相关问题。

由 API 主导的方法

API 主导的方法是将 API 置于应用程序和它们需要访问的业务能力之间的通信核心，从而在所有数字通道上一致地交付无缝功能。API 主导的连接是指使用一种可重用、且设计得当的 API 来连接数据和应用程序的方法。

API 主导的架构

API 主导的架构是一种架构方法，它着眼于实现重用 API 的最佳方式。它能解决以下问题：

• 保护 API，使外界无法在未授权情况下访问 API
• 确保应用程序能找到正确的 API 端点
• 限制对 API 的请求次数，从而确保持续的可用性
• 支持持续集成、测试、生命周期管理、监控、运维等等
• 防止错误在栈间传播
• 对 API 的实时监测和分析
• 实现可伸缩和灵活的业务能力（例如支持 微服务架构）

API 资源路由

实现一个 API 网关，把它作为与所有服务通信的单一入口点，意味着使用者只需要知道 URL 就能使用 API。将请求路由到相应的服务端点，并执行相应的功能是 API 网关的职责。

由于客户端应用程序不需要从多个 HTTP 端点调用功能，这个办法就减少了 API 使用者的操作复杂度。对每个服务来说，也不需实现一个单独的层级去实现认证、授权、节流和速度限制。大多数API 网关，如开源的 Apache APISIX，已经包含了这些核心功能。

API 基于内容的路由

基于内容的路由机制也使用 API 网关根据请求的内容进行路由调用。例如，一个请求可能是基于 HTTP 请求的头部内容或消息体被路由，而不只基于它的目标 URI。

考虑这样一个场景：为了将负载在多个数据库实例间均分，需要对数据库进行分区。当记录总数较大，单个数据库实例难以管理负载时，常常会用这个办法。

还有一个更好的办法，就是把记录在多个数据库实例间分散开来。然后你实现多个服务，每个不同的数据库都有一个服务，把一个 API 网关作为访问所有服务的唯一入口。然后，你可以配置你的 API 网关，根据从 HTTP 头或有效载荷中获得的密钥，将调用路由到相应的服务。

在上面的图表中，一个 API 网关向多个客户服务暴露一个单一的/customers资源，每个服务都有对应的不同数据库。

API 地理路由

API 地理路由解决方案根据 API 调用的来源将其路由到最近的 API 网关。为了防止地理距离导致的延迟问题（例如一个位于亚洲的客户端调用了位于北美地区的 API），你可以在多个地区部署 API 网关。对于一个 API 网关，你可以在每个区域使用不同的子域名，让应用程序基于业务逻辑选择最近的网关。因此 API 网关就提供了内部负载均衡，确保进入的请求分布于可用的实例之间。

通常使用 DNS 流量管理服务和 API 网关，针对该区域的负载均衡器解析子域名，定位到距离最近的网关。

API 聚合器

这项技术对多个服务执行操作（例如查询），并向客户端服务以单个 HTTP 响应的形式返回结果。API 聚合器使用 API 网关在服务器端代表使用者来执行这项工作，而非让客户端程序多次调用 API。

假定你有一款移动端 APP，对不同的 API 发起多次调用。这增加了客户端代码的复杂性，导致网络资源的过度使用，而且由于延迟性，用户体验也不好。网关可以接收所有需要的信息，可以要求认证和验证，并理解来自每个 API 的数据结构。它也可以传递响应的有效载荷，因此它们也会作为一个用户需要的统一负载传回移动端。