架构模式：API网关
什么是 API 网关？
API 网关是一种工具，充当客户端从服务器或微服务寻求资源的请求的中介。它管理、路由、聚合和保护 API 请求。
与我们之前探索的模式一样，这通常被描述为“微服务上下文”模式，但情况不一定如此。它可能值得在许多“非微服务”情况下使用，但有时不应该在微服务中使用。
让我们更深入地了解细节。
请求路由
这涉及接受客户端的请求并确定哪个或哪些服务应处理该请求。它可能有不同的方面：
-
动态路由：API 网关可以根据 URL 路径、HTTP 方法、HTTP 标头等动态路由请求。注意：这在多租户上下文的情况下可能很有用。（请参阅架构模式：使用 Keycloak、Angular 和 Spring Boot 进行多租户）
-
服务版本控制：允许服务的多个版本共存；客户可以指定他们想要与之交互的版本。注意：这在微服务中非常有用，而且在 SOA 或任何需要允许不同版本的公开 API 中也非常有用。
-
负载分配：某些网关可以将负载分配到服务的多个实例，通常与负载均衡器结合使用。
API成分
将多个服务请求合并为单个响应以简化客户端通信。这可以通过以下方式完成：
-
聚合：例如，客户可能需要有关用户及其订单的详细信息。网关不再进行单独的调用，而是进行单个调用，然后网关从用户和订单服务中获取数据，然后聚合结果。
-
转换：将来自多个服务的数据转换为客户端期望的格式
注意：这部分也可以通过另一种称为前端后端（BFF）的模式来实现。根据您的需要，它也可以与网关结合使用。
速率限制
限制用户或服务在给定时间范围内可以发出的请求数量。这对于保护您的 API 非常有用，并且可以有多种用途：
-
特定于客户的限制：不同的客户可以根据其角色、订阅级别等有不同的速率限制。
-
突发限制与持续限制：允许短时间的流量突发或在较长时间内限制请求
-
防止系统过载：确保服务不会因过多请求而不堪重负，从而导致性能下降或故障
安全
确保只有授权的请求才能到达服务还可以提供特定于客户端的身份验证。
-
身份验证：使用 JWT、OAuth 令牌、API 密钥等方法验证客户端的身份。
-
授权：确定允许经过身份验证的客户端执行哪些操作
-
威胁检测：某些网关可以识别并阻止潜在的安全威胁，例如 DDoS 攻击、SQL 注入等（与上一点相关）
缓存
缓存是暂时存储经常使用的数据，以加快后续请求的速度。这取决于您想要实现的缓存策略。也可以在 BFF 中完成，也许根本就不行。
-
响应缓存：存储常见请求的服务响应，避免冗余处理。
-
TTL（生存时间）：确保缓存数据不会太旧，定义应存储多长时间
-
缓存失效：删除过时或不正确数据的机制
服务发现
这是指自动查找服务实例的网络位置。
-
动态位置：在 Kubernetes 这样的动态环境中，服务可能会四处移动。网关会跟踪它们的位置，因此消费者不必担心；这是一种将可扩展性影响与客户端解耦的方法。
-
健康检查：如果服务实例未通过健康检查，网关将不会将请求路由到它。它可以防止消费者请求中断服务，从而提高故障管理的质量，还可以防止某些类型的漏洞利用。
-
与服务发现工具集成：通常与 Consul、Eureka 或 Kubernetes 服务发现等工具集成
分析和监控涉及收集 API 使用情况和系统运行状况的数据。DevOps 会对这个功能非常感兴趣，特别是因为它使他们能够很好地了解整个系统上的活动，无论其复杂性如何。
-
日志记录：捕获有关每个请求和响应的数据
-
指标：跟踪请求率、响应时间、错误率（按 HTTP 代码分类）等关键指标。
-
可视化：与 Grafana 或 Kibana 等工具集成以可视化数据
-
警报：如果出现问题或指标超出阈值，则通知系统操作员
这可能是一个表示：
好处和权衡
好处
简化客户端
通过拥有统一的接入点，客户端可以在不了解后端服务复杂性的情况下进行通信。这简化了客户端开发并保持一致的体验，因为它们不需要直接处理不同的端点和协议。
集中管理
API 网关的一个主要优点是速率限制或安全检查等常见功能可以在单个位置处理。这减少了冗余代码并确保规则和策略的一致应用。
跨领域的关注点
适用于多种服务的问题（例如日志记录或监视）可以在网关级别处理。这确保了一致性并减少了在每个服务中实现这些功能的开销。
优化的请求和响应
根据客户端的需求（例如，移动、网络、桌面），API 网关可以修改请求和响应。这可确保客户端以最佳格式接收数据，减少不必要的负载并提高速度。
提高安全性
通过集中身份验证和授权机制，网关提供一致且强大的安全屏障。它还可以加密流量，提供额外的数据保护层。
稳定
断路等功能可防止服务过载，确保系统平稳运行。如果服务变得无响应，网关可以快速重新路由或暂停请求，从而保持整体系统的健康状况。
权衡
单点故障 (SPOF)
如果没有适当的高可用性和故障转移策略，API 网关可能会成为系统的致命弱点。如果发生故障，所有对后端服务的访问都可能被切断。这对于生产环境来说成为一个非常具有战略意义和敏感的点，但不仅如此，当在给定环境中的网关上工作时，所有依赖于该访问的服务都会受到影响，因此在生产环境中都必须考虑这一点。和发展方面。
复杂
引入API网关添加了另一个组件来管理和操作。这会增加部署复杂性并需要额外的配置和维护。我同意埃隆·马斯克的观点，“最好的部分就是没有部分”——对于航空航天开发和软件工程来说都是如此。
潜伏
由于所有请求和响应都通过网关，因此可能会增加延迟，特别是在涉及大量处理或转换的情况下。与上一点相同，通常事务路径上的组件越多意味着时间越长。
扩展问题
高流量会给 API 网关带来压力。正确的垂直和水平扩展策略对于确保网关能够处理峰值负载而不降低性能至关重要。
潜在的低效率
如果不仔细设计，网关可能会导致效率低下，例如冗余的 API 调用或不必要的数据转换。适当的优化和持续监控至关重要。
结论
与许多架构模式一样，API 网关提供了一套强大的功能，可以满足现代软件系统的一系列需求。通过为客户端请求提供统一的入口点，它可以简化、保护和优化客户端和服务之间的交互，尤其是在基于微服务的系统中。然而，与任何工具或模式一样，它也面临着一系列独特的挑战。延迟增加的可能性、特殊扩展考虑的需要以及引入单点故障的风险强调了仔细规划、设计和持续监控的重要性。如果明智地使用 API 网关，并充分了解其优点和权衡，那么 API 网关在实现可扩展、安全和高效的系统交互方面可以发挥无价的价值。与往常一样，架构师和开发人员必须权衡利弊，以确定 API 网关在其特定环境中的适合度，确保他们利用其功能，同时减少潜在的陷阱。
作者：Pier-Jean MALANDRINO
更多技术干货请关注公号【云原生数据库】
squids.cn，云数据库RDS，迁移工具DBMotion，云备份DBTwin等数据库生态工具。
irds.cn，多数据库管理平台（私有云）。