API 网关简化了对分布在多个 Kubernetes 集群和云中的微服务的管理。继续阅读以了解其架构、功能和优势。

一些架构师、云工程师和 DevOps 人员经常说，“微服务是小单体。” 这源于处理大量服务的复杂性，尤其是管理和配置它们的网络规则和安全方面。

当客户端向分布在分布式系统中的多个集群和云中的微服务发出请求时，跟踪每个请求以确保安全和正确的路由规则变得乏味。理想情况下，后端服务不应该这样做，因为它们应该单独提供业务逻辑。这就是 API 网关（所有请求的单一入口点）的用武之地。让我们看看什么是 API 网关以及它提供的功能和优势。

什么是 API 网关？

API 网关是客户端和微服务之间的服务器（或 L7 代理），充当所有客户端进入系统的集中入口点。它是一个反向代理，接受客户端 API 调用并将它们转发到适当的微服务（参见下图 A）。

通过为每个客户端提供 API，API 网关封装了底层系统的复杂性，让客户端与其对话，而不是调用特定的服务。他们还在流量到达服务之前执行安全检查（身份验证和授权），从而让服务专注于其核心功能。

图 A – 微服务架构的 API 网关实现概念图

微服务对 API 网关的需求

直接的客户端到微服务通信模式带来的挑战导致了 API 网关的流行。让我们来看看其中的一些。

服务发现和流量路由问题

对于客户端到微服务的直接连接，客户端必须知道服务实例的特定端点。但是由于服务的动态（去）缩放，跟踪端点增加了客户端的复杂性。此外，如果客户端与服务耦合，则扩展将成为一个问题，因为它需要在客户端更改配置。此外，当客户端直接调用服务时，很难配置基于某些属性的路由流量，例如地理（geo-routing）。

为直接的客户端到服务通信公开暴露服务端点会引起安全问题。它增加了入侵者的攻击面，并使后端服务容易受到威胁，例如数据包嗅探、中间人攻击等。此外，直接的客户端到微服务给服务增加了验证和授权 API 调用的负担而不是让他们专注于交付业务逻辑。

影响互操作性的多种协议

微服务架构提供的灵活性让开发人员可以使用他们选择的语言（Python、Java、Go）构建服务。同样，他们可以使用不同的 API 类型（例如 REST、gRPC 等）来实现这些服务。在客户端到微服务的直接通信模式中，客户端需要理解并使用不同的协议进行通信。这增加了额外的复杂性，因为客户端应用程序将需要更多代码和逻辑。

往返引起的延迟

考虑来自亚马逊网站的产品页面。产品定价、数量和评论等一些属性将在后端部署为不同的服务。如果客户端直接调用服务，它将不得不为每个服务（产品价格、评论、数量等）发出单独的请求以检索所需的信息，因为没有缓存来自上游服务的响应的机制。这些调用增加了建立多个连接的开销，并且这些网络请求引起的往返增加了延迟和次优的用户体验。
API 网关的架构在某种程度上减轻了直接客户端到微服务连接所带来的挑战，并提供了多种功能。

API 网关流量

API 网关是一个 L7 代理，它从通常由客户端请求的前端微服务中抽象出流量管理。API 网关可以读取和理解 HTTP 消息（参见下图），因此它们可以应用过滤器或对流量采取行动。

HTTP消息结构

请求在 API 网关处流经多个步骤。下图（图 B）表示位于 Kubernetes 集群边缘的 API 网关以及请求流经的阶段。

图 B – 通过 API 网关的传入 gRPC 请求的流量

• 请求验证： 首先，API 网关通过检查请求方法、标头和正文来验证传入请求，以确保它符合预定义的规则。此外，根据网关的允许列表和拒绝列表将请求列入白名单或黑名单，以执行严格的访问控制。
• 认证授权（AuthN/Z）： 网关通过验证凭据，如API密钥（认证），对经过验证的请求进行认证和授权，然后实施授权策略，如RBAC（基于角色的访问控制）。API 网关还可以使用 IdP（身份提供者）的帮助进行详尽的 authN/Z 检查，例如多因素身份验证 (MFA)。
• 服务发现： API 网关使用服务发现组件为授权请求定位适当的后端服务。它通过查询服务注册表或使用动态 DNS 来实现。
• 协议转换： API 网关可以在必要时在客户端和微服务之间转换协议。在上图中，客户端发送一个 gRPC 请求，该请求被转换为 REST 以供“购物车”服务理解。此外，网关在将响应返回给客户端之前将响应转换为面向公众的协议（此处为 REST 到 gRPC 格式）。
• 动态路由： 一旦找到后端服务并根据需要转换请求协议，API 网关就会将请求路由到适当的服务实例或负载均衡器。网关通常在其配置中定义了路由规则。

API 网关完成上述步骤后，会将服务的响应返回给客户端。但是，请注意，概述的步骤可能会有所不同，具体取决于网关的配置方式和其他功能的实现。

API网关功能

除了上面提到的关键功能外，API 网关还提供许多功能。

• 高级流量路由： API 网关可以管理和控制 API 流量在服务之间的分配方式。它们可以执行负载平衡和流量拆分，并充当反向代理和正向代理。API 网关还实现了渐进式交付，例如蓝绿部署。
• 速率限制： API 网关可以根据 IP 地址或 HTTP 标头限制请求。它有助于服务避免请求过载并防止恶意攻击，例如拒绝服务 (DoS)。速率限制还有助于 API 提供商实施不同的货币化策略（例如，分层定价模型）。
• 错误处理： API网关可以对因服务器内部错误、认证失败、无效输入等导致API请求失败的错误响应进行处理和标准化。可以为使用网关的客户端自定义错误的HTTP状态码和错误信息，帮助客户端正确理解和处理/调试。
• 断路器： API 网关可以实现断路器模式，帮助后端服务避免因请求失败而过载。熔断模式将停止向失败的服务转发请求并返回适当的错误代码。它有助于防止错误级联到健康的上游服务，并使 API 基础设施具有弹性。
• 可观察性： API 网关为操作可观察性提供日志记录、监控和分析。它有助于了解 API 基础设施的性能（API 使用）和行为，从而提高可见性、安全性并减少停机时间。
• 缓存： API 网关可以缓存和服务先前对客户端请求的响应。如果启用了 API 缓存，网关将根据缓存的响应检查请求并转发请求（如果存在），从而无需每次都向后端服务发出新的相同请求。这将显着降低服务负载和响应延迟，并改善 API 性能和用户体验。
• SSL 终止： API 网关可以执行 SSL 终止，这涉及代表后端服务解密来自客户端的传入 SSL 连接。卸载 SSL 终止以及 authN/Z 等其他安全功能将使服务专注于其主要职责。

API 网关提供的所有这些功能为管理分布式服务系统带来了巨大的好处。

API 网关的好处

API 网关实施可帮助组织获得以下好处等。

改进的应用程序安全性

作为 API 管理的集中点，网关隐藏了服务和底层基础设施，不被公开。这使得攻击者很难试图关闭应用程序，特别是通过用请求压倒服务（DoS 攻击）。由于网关在到达后端之前处理每个请求，因此它们可以对此类攻击应用速率限制。其他安全功能，如请求验证、authN/Z、断路和策略实施，再加上日志记录和监控，使 API 网关有助于应用程序的整体安全性。

增强处理和扩展微服务的灵活性

API 网关将外部客户端与内部微服务分离。这为 DevOps 和基础架构工程师提供了高度的灵活性，可以更改后端服务，而无需更新客户端应用程序中的配置。客户端仍然可以通过网关发出请求并获得响应，而无需了解后端发生的变化。许多重要的功能，例如 authN/Z 和负载平衡，将由网关负责。将这些责任卸载到网关有助于开发人员为应用程序编写更少的代码，从而促进创新并实现快速发布。

API 提供商更好的货币化

API 货币化就是为第三方消费者将 API 产品化。API 网关为公司提供了一种更好的方式来将其 API 货币化以产生收入或支付维护 API 的运营成本。网关将客户端请求连接到计费系统，从而为 API 提供商提供集中计费和计量机制。这有助于公司通过为 API 消费者实施不同的定价模型（例如现收现付、分层和基于单位）来跟踪 API 使用情况并收取服务费用。

改进的用户体验 (UX)

API 网关通过请求底层服务并聚合它们来减轻客户端发出过多请求的麻烦。也就是说，对网关的单个请求就足以满足客户端应用程序的需求，从而显着减少延迟。并且在频繁重复请求的情况下，网关可以及时提供缓存的响应，而无需将请求转发给后端。此外，借助监控和日志记录功能，API 网关可以更轻松地跟踪和排除任何性能问题，这有助于最大限度地减少应用程序停机时间。所有这些都有助于提高应用程序的性能、可靠性和用户体验。

三大开源 API 网关工具

在评估 API 网关工具时，组织可以寻找开源工具、云服务提供商或企业版。如果开源是您的首要任务，我们根据易用性、灵活性和可扩展性等因素列出了排名前三的开源 API 网关工具。

1.Tyk API网关

Tyk提供了一个完全开源的网关，支持多种协议，如 REST、GraphQL 和 gRPC。除了 Redis 之外，它没有第三方依赖项，是当今最快的网关之一。

以下是 Tyk API 网关的一些功能：

• 使用任何协议：REST、SOAP、GraphQL、gRPC 和 TCP。
• 使用 OIDC、JWT、客户端证书等的 AuthN/Z。
• 使用任何语言（Python、JS、Go）创建可扩展插件。
• Kubernetes 原生声明式 API 的Tyk 运算符。
• 通过启用 CORS 允许基于浏览器的请求。
• API 版本控制和生命周期管理。
• 带有分析日志记录的详细 API 使用数据。

2.Kong API网关

Kong API Gateway是一个适用于多云和混合云部署的云原生网关。在其自己的Kubernetes ingress controller的帮助下，网关也是 Kubernetes 原生的。Kong 以其通过模块和插件的灵活性和可扩展性而闻名。

Kong API Gateway 的一些开源功能包括：

• 端到端自动化，以推动 API 设计和执行的 GitOps 流程。
• 用于将 API 部署到 K8s 的 Kubernetes Ingress Controller。
• 基本流量控制插件，例如基本速率限制和轻量级缓存。
• 简单的数据转换
• gRPC 到后端 gRPC 服务的转换。
• AuthN/Z（HMAC、JWT 密钥验证、有限的 0Auth 2.0 和 LDAP、机器人检测、ACL。）
• 简单日志记录（文件日志记录、HTTP 日志记录、基本 StatsD、TCP/UDP 日志记录。）

3. KrakenD API网关

KrakenD是一个高性能的 API 网关，采用无服务器架构构建，可提供真正的线性可扩展性。它有助于在没有单点故障的情况下进行扩展。KrakenD 在本地、混合或云上运行，并且可以使用插件和嵌入式脚本进行扩展。

KrakenD 的开源版本提供以下功能：

• 一个名为 KrakenD Designer 的可视化工具，用于生成 KrakenD 配置。
• 多格式配置（JSON、YAML、TOML、HCL等）
• 构建自定义 Go 插件并将它们嵌入到一个随时可用的图像中。
• 数据转换、CDN 的 HTTP 缓存标头和自动输出编码。
• 零信任参数转发，防止点击劫持、嗅探和跨站脚本。
• JWT 基于声明的路由和流量镜像/镜像。
• 日志记录、跟踪和指标（Jaeger、Zipkin、ELK 堆栈仪表板、Prometheus 等）

API 网关是银弹吗？

不它不是。与任何其他工具一样，API 网关也面临着一系列挑战。这里有几个：

• 流量处理仅限于边缘。
• 无法处理南北交通。
• 缺乏对内部沟通的可见性。
• 无法控制集群内部的网络。
• 不安全的东西向流量。
• 无法实现渐进式交付（例如金丝雀）。

详细探索 API 网关的这些挑战，并理解为什么考虑像 Istio 这样的服务网格平台是理想的：API 网关与 Istio 服务网格。

此外，还有不同的场景可以使用您现有的 API 网关基础设施来实施 Istio。