API Gateway 与负载均衡器：主要区别与用例

想象一座机场航站楼和一名空中交通管制员。API Gateway 就像航站楼，乘客（客户端请求）首先到达此处，办理登机手续，通过安检，并根据其目的地被引导至正确的登机口。作为前端入口点，API Gateway 处理身份验证、请求路由、协议转换以及决定请求应去向何方的任何规则。它决定如何路由流量，并将请求路由到适当的后端服务。

而负载均衡器则如同空中交通管制员，确保一旦飞机准备起飞，就为其分配跑道，以保证交通流安全高效。它（在大多数情况下）将传入的工作负载分发到多个后端服务器或同一服务的多个实例。

两者协同工作时，API Gateway 确定每个请求的需求以及应由哪个服务来处理，而负载均衡器则确保所选服务实例不会过载。了解这些不同的角色以及它们如何相互补充，有助于团队设计出更清晰、更具弹性、更可扩展且更契合其系统特定需求的架构。

要了解 API Gateway 和负载均衡器在分布式系统中的运作方式，从开放系统互连 (OSI) 模型入手会很有帮助。OSI 模型是一个概念性的七层框架，用于标准化网络通信的组织方式，从物理的比特传输一直到产生用户可读响应的应用层交互。

在此模型中，API Gateway 主要在第 7 层（应用层）运行，在此层解释请求并应用程序感知应用场景的策略，如身份验证、路由规则和协议转换。负载均衡器可以在第 4 层（传输层）运行，基于 IP 和端口做决策，也可以在第 7 层运行，以做出基于内容的路由选择。

明确了这些角色后，当传入流量从客户端流向后端服务时，API Gateway 和负载均衡器负责引导和处理流量的不同阶段。鉴于这些角色在某些方面可能重叠，尤其是当较新的网关加入轻量级路由或分发功能时，这些组件会因系统结构的不同而出现在不同的架构布局中。一些常见模式包括：

协同工作：在微服务架构中，API Gateway 可以对请求进行身份验证、应用速率限制并规范化协议，然后转发到由负载均衡器（通常是应用程序负载均衡器 (ALB)）前置的服务端点，由负载均衡器选择可用的服务器。在这种安排下，网关提供应用程序感知的控制，而负载均衡器优化分发和弹性。微服务只是一个例子；API Gateway 也用于单体、多应用程序和混合环境中，以协调跨不同系统的传入 API 流量。 

独立使用（仅负载均衡器）：对于统一的无状态 Web 层，团队可以将负载均衡器直接置于相同的服务器之前，以平滑流量峰值并维持正常运行时间，而无需 API 层级的编排。除此之外，负载均衡器还可以在以下场景中独立运行：在只读数据库副本之间引导流量、在地理上分布的端点之间转移负载、处理多区域部署中的故障转移，或对不需要网关级别逻辑的旧版系统进行请求均衡。 

独立使用（仅网关）：在某些托管平台中，网关可以直接终止客户端流量、执行策略，并路由到已具备内置分发能力的服务，从而在无需单独负载均衡层的情况下保留策略和开发者体验方面的优势。

许多现代网关还可以执行某些负载均衡功能，例如加权、轮询或基于路径的路由，但团队仍可能在前面放置一个专用的第 4 层负载均衡器来进行连接处理，或分担高吞吐量的传输层问题。

API Gateway 层的可观测性通常包括请求量、延迟分布、策略评估、身份验证结果以及与特定路由或消费者相关的错误率等指标。网关还会生成详细的日志，捕获请求和响应负载特征、头部转换以及安全事件，例如令牌验证失败或速率限制触发。这一层的链路追踪通常会突出显示请求如何流经路由规则、转换、响应聚合和后端调用，使诊断 API 行为或合约执行问题变得更加容易。

负载均衡器呈现的运营指标侧重于连接数、目标运行状况检查、后端实例的响应时间以及路由算法行为，同时还有显示流量分发决策和故障转移事件的日志。当结合分析时，网关层和负载均衡器层的洞察能更完整地揭示流量如何流经系统以及问题可能出现在何处。

例如，网关的高延迟可能与下游负载均衡器层的不均衡或故障目标相关，而负载均衡器故障转移的激增可能追溯到仅在网关处可见的格式错误或异常重的请求。

具有成熟可观测性实践的组织通常将这些视角合并到统一仪表板或链路追踪中，使团队能够跟踪请求从客户端边界经路由逻辑一直到后端实例行为。成熟度较低的团队可能会单独检查每一层，但即使是日志和指标的基本关联，也有助于区分网关处的策略相关问题与负载均衡器背后的性能或可用性问题。 随着时间推移，整合跨层的洞察可以实现更快的故障排除、更清晰的职责边界，以及更深入地理解整体系统运行状况。

从在平台中所处的位置来看，API Gateway 和负载均衡器的职责会在 Kubernetes 中、在 Ingress/Gateway API 控制器与服务负载均衡之间转移，具体取决于流量的准入、保护和调度方式。

• Ingress、Gateway API 或 Service 对象如何映射到网关及负载均衡器类型的角色
  
  在 Kubernetes 中，Ingress 和较新的 Gateway API 为主机/路径路由、传输层安全 (TLS) 配置以及应用层的策略附加提供了类似网关的控制平面。许多实现这些规范的控制器（如 Envoy、NGINX、Traefik）是广泛使用的开源项目，同时也作为反向代理运行，在将流量路由到集群之前处理流量整形和转换。
  
  这些组件通常充当 Web 应用的首个应用程序感知跳，执行诸如 JSON Web 令牌 (JWT) 验证或请求头重写等任务，然后再将请求转发给后端服务。
  
  相比之下，类型为 LoadBalancer 的 Kubernetes Service（或与外部负载均衡器配对的 NodePort）公开工作负载，并将流量分发到底层 Pod（通过节点）。这一层的行为类似于传统 Web 服务器集群前使用的负载均衡器，选择健康实例以确保顺畅交付。实践中，网关决定请求应如何处理以及以哪个后端为目标，而 Service 及其负载均衡机制决定哪个实例实际接收请求。

• 控制器和平台差异
  
  职责的具体划分取决于控制器和平台。某一供应商的控制器可能捆绑更多网关功能（身份验证、Web 应用程序防火墙 (WAF) 集成），而另一供应商则将这些功能委托给边车或外部服务。某些环境在策略表达上严重依赖 Gateway API，而其他环境仍使用经典 Ingress 加上自定义资源定义来实现高级路由。
  
  云提供商 还可能注入专有的负载均衡功能，如全球任播 VIP（单个全球通告 IP，将用户路由到最近的健康端点）和跨区域故障转移（当某个区域受损时自动将流量转移到另一可用区），这会改变某些任务的执行位置。因此，团队应预期不同发行版在配置界面、支持的功能和可观测性方面存在差异。

• 网格何处终止，边缘何处开始
  
  服务网格有助于管理系统内服务之间的通信方式。它确保这些连接安全、可靠，并在出现问题时自动调整。入口或边缘网关通常位于网格边界，其作用类似于感知策略的反向代理，在将流量交给内部服务之前终止外部连接并应用 API 层规则。在此上游，负载均衡器或全局流量管理器可能将传入连接分发到多个网关实例或地理区域。
  
  
• 组织如何安排网关和负载均衡器
  
  有些组织将 API Gateway 置于网格之外以最小化耦合，而另一些组织则运行网格感知网关，以便策略和遥测保持一致。某些团队将全局负载均衡器前置以实现基于地理位置的流量路由；其他团队则依赖基于 DNS 的调度或 CDN 边缘逻辑。正确的组合往往反映延迟预算、合规区域和运营经验等约束，而非通用最佳实践。关键的是每一层都有清晰的职责，且不会在技术栈中重复承担责任。

• gRPC、WebSocket、事件流或长连接注意事项
  
  当处理 gRPC 的系统组件能够完全支持其基于流的通信方式时，gRPC (HTTP/2) 往往运行得更有效，这意味着保留 HTTP/2 的优势、正确解释其元数据并避免回退到旧协议。因此，网关或七层负载均衡器应当能够顺畅管理流式流量，包括在数据双向快速流动时处理超时和压力。
  
  WebSocket 和服务器发送事件通常涉及长连接，这些连接可能对空闲超时、保活行为和连接限制等因素敏感，尤其是当大量客户端长时间保持连接时。对于事件流，例如 Kafka 风格或自定义流式 API，系统可能遇到大负载、间歇性故障，或在部署期间需要排空和重建连接。
  
  对于这类长时运行协议，围绕身份验证、可观测性以及连接如何保持与特定后端关联所做的架构选择，会影响整体可靠性，并有助于避免队头阻塞或意外会话中断等问题。

团队在架构演进的不同阶段通常会遇到 API Gateway 和负载均衡器，但出现的顺序并不固定。哪个组件先出现（以及两者是否都需要）取决于应用程序或更广泛的 IT 环境的需求，以及指导该环境的系统设计原则。

可能会早期引入负载均衡器，以提高可用性并将流量分发到多个服务器实例，但它不提供某些系统从一开始就需要的授权、策略执行或 API 级别的控制。这些需求通常属于更广泛的 API Management 范畴。

同样，有些环境会首先引入 API Gateway，因为最初的需求集中在身份验证、请求路由、速率限制或管理不断增长的 API 目录上。随着流量增长和系统扩展，无论扩展发生在单个应用程序内还是企业内的许多应用程序之间，API Gateway 通常变得更加重要。

它们提供了一个结构化的层，用于管理 API 的公开、安全和治理方式。在某些组织中，网关充当众多内部和外部应用程序的统一“前门”，而在其他组织中，网关可能作为单个产品内微服务的路由和策略层。

简而言之，随着 API 流量增加和 IT 环境变得更加复杂，API Gateway 和负载均衡器都扮演着更为关键的角色。它们的重要性日益增长，是因为它们解决了规模、可靠性、安全性和运营清晰度等不同维度的问题。