这篇文章详细阐述了API 网关（例如Apache APISIX）在构建API-Led Connectivity时最常见的 10 种用法。我们了解不同的解决方案，您可以利用 API Gateway 功能为其他开发人员设计可靠、高性能和简单的 API。
以下是使用 API 网关（但不是全部）的 10 种模式的摘要：
- API 资源路由。
- API 基于内容的路由。
- API 地理路由。
- API 聚合器。
- API 集中式身份验证。
- API 格式转换。
- API 可观察性。
- API 缓存。
- API 故障处理。
- API 版本控制。
API 主导的架构
首先，让我们再次修改这 3 个术语，例如：API Gateway、API-Led architecture和API-Led Connectivity。
API Gateway是通过在客户端和服务器之间添加一个层而形成的模式，该层充当将请求从客户端转发到服务器的单个入口点。它允许所有客户端通过单个 API 网关层访问他们想要访问的服务。
API-led是一种架构方法，它将 API 置于应用程序之间的通信及其需要访问的业务功能的核心，以便在所有数字渠道中始终如一地提供无缝功能。
API 主导的连接性是指使用可重用和精心设计的 API 来链接数据和应用程序的技术，这反过来又基于API 主导的架构。它是一种架构方法，着眼于重用 API 的最佳方式，以促进您的创新并在市场中快速移动。在最基本的层面上，API 主导的架构应该解决以下问题：
- 保护 API 免受未经授权的访问和重大安全威胁。
- 确保消费应用程序总能找到正确的 API 端点。
- 限制和/或限制对 API 的调用次数以确保持续可用性。
- 支持 API 设计、测试、持续集成、生命周期管理、监控和操作等功能，仅举几例。
- 错误处理和防止错误在堆栈中传播。
- 通过丰富的分析和洞察力实时监控 API。
- 一种实现可扩展和灵活业务功能的方法，例如，支持微服务架构。
让我们在后续部分中描述 API 网关的每种用法，以解决采用 API 主导的架构时出现的常见需求/挑战。
API资源路由
列表中的第一个是API 资源路由方法，它使用 API 网关根据唯一资源标识符 (URI) 路由传入调用。将 API 网关实现为所有服务的单一入口点意味着 API 使用者只需了解一个 URL 域。通过这种方式，API 网关负责将流量路由到相应的服务端点，并执行任何应用的策略，如下图所示。
它降低了 API 消费者端的复杂性，因为客户端应用程序不需要使用来自多个 HTTP 端点的功能，以防系统中有许多服务。此外，无需为每个服务单独实现所有横切关注点，例如身份验证/授权、节流和速率限制。大多数 API 网关（如Apache APISIX）已经具备这些核心功能。
API 基于内容的路由
类似地，API 基于内容的路由机制也使用 API 网关根据请求的内容（例如，基于 HTTP 标头或消息体）而不只是 URI 来路由调用。
以应用数据库分片以跨多个数据库实例分布负载为例。当存储的记录总数很大并且单个实例难以管理负载时，通常会应用此技术。相反，记录分布在多个数据库实例中。然后，您实现多个服务，每个唯一数据存储一个，并采用 API 网关作为所有服务的唯一入口点。然后，您可以配置 API 网关，以根据从 HTTP 标头或负载中获取的键将调用路由到相应的服务。
API 地理路由
API 地理路由解决方案根据 API 调用的来源将 API 调用路由到最近的 API 网关。为了防止延迟问题和其他可能因距离而出现的不可预见的问题（例如，来自亚洲的消费应用程序调用位于北美的 API），API 网关和其他服务基础设施已部署在全球多个地区作为需要。例如，为每个区域中的每个 API 网关使用不同的子域，并让消费应用程序根据应用程序逻辑确定最近的网关。然后，API 网关提供内部负载平衡，以确保传入请求分布在服务的可用实例中。
API 聚合器
此技术对多个服务执行操作（例如，查询），并通过一次HTTP request/response调用将结果返回给客户端服务。API 聚合器不是让客户端应用程序多次调用多个 API，而是使用 API 网关代表服务器端的消费者执行此操作。
例如，考虑一个移动应用程序，它多次调用不同的 API 以显示单个屏幕的数据。在这种情况下，它会增加客户端代码的复杂性、网络资源的过度利用，甚至会因为应用程序更容易受到延迟问题的影响而导致用户体验不佳。API Gateway 可以接受所有所需信息作为输入，请求身份验证和验证，了解与其交互的所有 API 的所有数据结构，并且能够转换响应负载，以便将它们作为统一负载发送回移动应用程序消费者所需要的。
API集中认证
在此设计中，API 网关充当集中式身份验证网关。作为身份验证器，API Gateway 在 - 例如，不记名令牌中查找访问凭据HTTP header，并实施业务逻辑，使用 IDP、身份提供程序（例如Okta、Cognito、Azure Active Directory或Ory Hydra）验证这些凭据，通常使用OpenID Connect (OIDC) 是一种基于OAuth 2.0的身份验证协议，用于检查他们是否有权访问。
使用 API Gateway 进行集中式身份验证可以解决许多问题并带来一些好处，因为它完全减轻了应用程序的用户管理负担，并且通过快速响应从客户端应用程序收到的身份验证请求来提高性能。
例如，Apache APISIX提供了多种插件来启用不同的 API 网关身份验证方法。我们查看了这篇博文中最常用的一些使用Apache APISIX 插件的集中式身份验证。您甚至可以为给定的 API 启用多种身份验证方法。
API 格式转换
这是指能够通过相同的传输将有效负载从一种格式转换为另一种格式。例如，从基于 HTTPS 的 XML/SOAP 到基于 HTTPS 的 JSON，反之亦然。API 网关默认提供支持 REST API 和一些专用 API 网关的功能，除了有效负载转换之外，还支持传输转换，例如从 TCP（物联网中非常流行的传输）上的消息队列遥测传输 (MQTT) 转换为HTTPS 上的 JSON。
例如，Apache APISIX 能够接收 HTTP 请求，然后将其转码并转发给 gRPC 服务，获取响应，并通过其gRPC Transcode插件将其以 HTTP 格式返回给客户端。
API 可观察性
到目前为止，我们知道 API 网关为传入各种目的地的流量提供了一个中央控制点，但它也可以作为观察的中心点，因为它具有了解客户端和我们之间移动的所有流量的独特资格。服务网络。始终可以检测 API 网关，以便收集可观察性数据（结构化日志、指标和跟踪），以便使用专门的监控工具。
例如，Apache APISIX 提供了预构建的连接器（插件），您可以轻松地将其与外部监控工具集成。您可以利用这些连接器从 API 网关获取日志数据，以进一步获取有用的指标并全面了解使用情况，您可以管理环境中 API 的性能和安全性。
API 缓存
API 缓存是另一个级别的缓存，通常在 API 网关中实现。它可以减少对端点的调用次数，还可以通过缓存来自上游的响应来改善对 API 的请求延迟。如果 API Gateway 缓存具有所请求资源的新副本，它会使用该副本直接满足请求，而不是向端点发出请求。如果未找到缓存的数据，则请求将传输到预期的上游服务（后端服务）。
API 故障处理
API 服务因多种原因而失败，例如网络问题、连接（无法打开与 SQL Server 数据库等数据源的连接）、API 性能问题或无法对依赖项进行身份验证。在这种情况下，我们的 API 服务应该有足够的弹性来处理可预测的故障。此外，我们希望确保我们拥有的任何弹性机制，例如错误处理代码、断路器、健康检查、重试、回退、冗余实例等。现代 API 网关支持上述所有错误处理功能，包括自动重试和超时。
API Gateway 充当协调器，可以使用此状态报告来决定如何管理流量、将负载平衡到健康节点、由于一些级联故障而快速失败，或者只是在它发现出现问题时提醒您。API Gateway 还确保路由和其他网络级组件成功协同工作，以将请求传递到 API 进程。它可以帮助您在早期阶段检测并更轻松地解决正在运行的应用程序的问题。或者 API 网关级别的故障注入机制可用于测试应用程序或微服务 API 对各种形式的故障的弹性，以建立对生产环境的信心。
API 版本控制
这指的是能够定义和运行 API 的多个并发版本。这一点尤其重要，因为 API 会随着时间的推移而发展，并且能够管理 API 的并发版本将使 API 使用者能够逐步切换到 API 的较新版本，因此旧版本可以被弃用并最终退役。这一点很重要，因为 API 就像任何其他软件应用程序一样，应该能够发展以支持新功能或仅仅响应错误修复。
您可以使用 API 网关来实现基于 API 版本控制（标头、查询参数或路径）。逐步发展您的 RESTful API，一篇循序渐进的方法博客文章解释了如何通过在 API Gateway 中配置两条路由来实现版本控制，一个是版本控制的，另一个是非版本控制的，通过启用Apache APISIX 的代理重写插件在它们之间切换。
概括
在整篇文章中，我们描述了 API Gateway 在设计 API-Led 架构中的一些用例，例如 API 如何处理身份验证、转换、聚合、缓存、可观察性，如何应用 API 网关以路由访问多个后端端点等。但是，人们可能会想到许多其他用例。