架构

云原生-负载均衡与代理技术

Posted Cola🌀 
一个篮子装不下所有的鸡蛋，那么就多用几个篮子来装。

—— 分布式系统的基本思想

出于扩展服务能力或提高容错性的考虑，大多数系统通常以集群形式对外提供服务。

当以集群形式提供服务时，外部请求无论由哪台服务器处理，都应返回一致的结果。同时，集群对外应保持高度透明，内部节点的增加或移除不应被外部察觉，也无需外部进行任何配置更改。换句话说，外部在与集群交互时，应如同面对一台高性能、高可用的服务器。

为集群提供访问入口并实现上述职责的组件称为“负载均衡器”（或称代理）。负载均衡器是业内最活跃的领域之一，产品层出不穷（例如专用网络设备、软件实现等），部署拓扑多样（如中间代理型、边缘代理型、客户端内嵌型等）。无论形式或部署拓扑如何，所有负载均衡器的核心职责无外乎“选择处理外界请求的目标”（即负载均衡算法）和“将外界请求转发至目标”（即负载均衡的工作模式）。本章将围绕这两个核心职责展开，帮助你理解负载均衡器的工作原理。

　

负载均衡与代理

在讨论负载均衡时，”负载均衡器”（Load Balancer）和”代理”（Proxy）这两个术语常被混用。严格来说，并非所有代理都属于负载均衡器，但大多数代理的核心功能都涵盖负载均衡。为了简化表述，本文将这两个术语视为大致等同，不作严格区分。

图 4-1 展示了负载均衡高层架构图，客户端（Client）的请求通过负载均衡器（Load Balancer）转发至某个后端服务器（Backend）。从整体架构来看，负载均衡器承担以下职责：

  • 服务发现：识别系统中可用的后端服务器，并获取它们的地址，以便与后端进行通信。
  • 健康检查：监测后端服务器的状态，确保只有健康的服务器能够接收请求。
  • 负载均衡：根据适合的分配算法，将请求均匀分配到健康的后端服务器上，提高系统的整体性能与可靠性。

合理使用负载均衡能为分布式系统带来多方面的好处：

  • 命名抽象：客户端通过统一的访问机制（如 DNS 或内置库）连接到负载均衡器，无需关心后端服务器的拓扑结构或配置细节。
  • 容错能力：通过健康检查和负载均衡算法，将请求分配至正常运行的后端服务器。故障服务器会被自动移出负载均衡池，为运维人员提供足够的修复窗口。
  • 成本和性能收益：后端服务器通常分布在多个网络区域（Zone/Region），负载均衡器根据策略将请求保持在同一网络区域内，从而提高服务性能（减少延迟）并降低资源成本（减少跨区域带宽费用）。

从网络层次的角度来看，所有负载均衡器可以分为两类：四层负载均衡和七层负载均衡，分别对应 OSI 模型的第四层（传输层）和第七层（应用层）。

　

四层负载均衡

需要注意的是，所谓的“四层负载均衡”并非严格限定于 OSI 模型的第四层（传输层）。实际上，它的工作模式涉及多个网络层次：

  • 第二层（数据链路层）：通过修改帧头中的 MAC 地址，将请求从一个物理网络节点转发到另一个节点。这种方式通常用于同一广播域内的转发，例如交换机或桥接设备完成的二层转发操作。
  • 第三层（网络层）：通过修改 IP 地址，实现跨子网的请求路由和转发。这是路由器的核心功能，通过修改数据包的源或目的 IP 地址，实现子网之间的通信和流量转发。
  • 第四层（传输层）：通过修改 TCP/UDP 端口号或连接的目标地址，利用网络地址转换（NAT）技术隐藏内部网络结构，将请求从一个入口转发至多个后端服务。

如图 4-2 所示，上述各个网络层次的共同特点是维持了传输层协议（如 TCP、UDP）的连接特性。如果读者在其他资料中看到“二层负载均衡”或“三层负载均衡”的说法，应该理解到这是负载均衡器在不同网络层次上的工作模式。

典型情况下，四层负载均衡器处理的是 TCP、UDP 等连接协议，它并不关心传输字节所代表的具体应用内容，这些字节可能来自 Web 应用、数据库服务或其他网络服务。因此，四层负载均衡器具有广泛的应用范围，能够适应各种不同类型的网络服务。

由于建立连接的开销较大（例如 TCP 三次握手，尤其在启用 TLS 加密时），许多网络协议（如 TCP、HTTP/2、QUIC 和 WebSockets）在演进过程中逐步引入了“多路复用”（multiplexing）和“连接保持”（connection keep-alive）等特性，也就是将同一连接或会话的流量始终转发到相同的后端服务器，从而避免频繁的连接建立过程。

不过，这种“连接保持”机制也存在潜在问题。以下是一个示例场景：

  • Client A 和 Client B 两个 HTTP/2 客户端通过四层负载均衡器和后端服务器建立持久连接。。
  • Client A 的 TCP 连接每分钟发送 40 个 HTTP 请求，而 Client B 的 TCP 连接每秒发送 1 个 HTTP 请求。

四层负载均衡器将 Client A 的所有 TCP 请求转发至同一台服务器，导致该服务器过载，而其他服务器则处于闲置状态。这种资源利用不均的问题在电气工程领域被称为“阻抗不匹配”现象。

随着用户规模扩大，四层负载均衡器面临的“阻抗不匹配”问题将变得更加明显。

不过也不要担心，引用一句计算机领域内流传颇广的俚语“计算机科学中的所有问题都可以通过增加一个间接层来解决。如果不够，那就再加一层”。因此，我们在四层负载均衡器之上添加了一个二级分发器 —— 七层负载均衡：

  • 四层负载均衡器工作在传输层，根据连接特性完成初步的请求转发；
  • 七层负载均衡器工作在应用层，根据请求内容进一步优化请求转发。

通过两次分发，请求的“阻抗不匹配”问题就消失了。

　

七层负载均衡

七层负载均衡器工作在应用层，这意味着负载均衡器必须与后端服务器建立新的传输层连接，并将客户端的请求代理到后端服务器。

图 4-4 展示了七层负载均衡器的工作原理。当客户端发送 HTTP 请求（stream）时：

  • 请求 1（stream1）被代理至第一个后端服务器；
  • 请求 2（stream2）被代理至第二个后端服务器。

七层负载均衡器能够处理更复杂的操作，原因在于它工作在应用层，能够检测和处理请求内容，具体包括：

  • 安全层 TLS 协议：TLS 的归属层次在网络领域存在争议，本文为便于讨论假设属于应用层。
  • 物理 HTTP 协议：涵盖 HTTP/1、HTTP/2、HTTP/3 等版本。
  • 逻辑 HTTP 协议：包括请求的头部、主体和尾部数据。
  • 消息协议：如 gRPC、RESTful API、SOAP、AMQP、MQTT 等。

因此，七层负载均衡能够根据应用层信息做出更精细的路由决策，并支持内容缓存、压缩、TLS/SSL 卸载等高级功能。

　

负载均衡器总体功能

服务发现

服务发现是负载均衡器识别后端服务器的一种机制，不同的实现方式差异较大，以下是几种常见的实现方式：

  • 静态配置文件：通过手动维护配置来实现基础的服务发现。
  • DNS：将后端服务器的 IP 地址以 SRV 记录或 A 记录形式注册到 DNS 服务器，客户端查询 DNS 记录来获取后端服务器的 IP 地址。
  • 服务注册中心（如 Zookeeper、Etcd、Consul 等）：后端服务器启动时将服务名称、地址、端口及健康检查信息注册到这些系统中。客户端通过查询 API 获取服务信息。这些系统通常内置健康检查机制，定期监控服务状态，并自动更新服务列表。
  • 服务网格领域的数据平面 API：提供标准化的数据平面接口（xDS 协议），支持跨平台、跨环境的服务发现（详见本书第八章 8.3 节）。

　

健康检查

健康检查用于评估后端服务器是否能够正常处理请求，识别不可用的服务器并将流量重新分配。健康检查有两种方式：

  • 主动健康检查：负载均衡器定期向后端发送健康探测请求，根据响应状态判断后端服务器是否健康。例如，某些七层负载均衡器会请求特定的健康检查路径（如 /health 或 /status），通过 HTTP 状态码来判断后端服务的健康状态。
  • 被动健康检查：负载均衡器通过持续监控请求、响应和连接的状态，分析异常情况来判断后端服务器的健康状态。如果在一段时间内发现某个后端出现多次连接失败或超时等问题，负载均衡器会将该后端标记为不健康。

　

粘性会话

对于某些特定应用，确保属于同一会话的请求被路由到相同的后端服务器至关重要。

会话的定义因业务而异，可能基于 HTTP cookies、客户端地址、请求头或其他相关属性来确定。大部分七层负载均衡器支持通过配置 HTTP cookies 或 IP 哈希来实现“粘性会话”（sticky session）。

值得注意的是，粘性会话涉及缓存、临时状态管理，实现粘性会话的设计通常很脆弱（赖于特定服务器、无法动态扩展、不可预测的负载分配问题等）。一旦处理会话的后端出现故障，整个服务都会受到影响。因此，设计具有该特性的系统时，需要格外谨慎！

　

TLS 卸载

TLS 卸载（TLS Termination）是指将 TLS 加密/解密、证书管理等操作由负载均衡器统一处理。这样做的好处是：

  • 减轻后端负载：后端服务器无需处理加密/解密操作，可以专注于业务逻辑处理。
  • 减少运维负担：负载均衡器集中管理 SSL 证书的配置和更新，避免每个后端服务器单独管理证书。
  • 提升请求效率：负载均衡器通常具备硬件加速能力，并经过优化，能更高效地处理 TLS 连接（详见本书第二章 2.5.2 节）。

　

安全和 DDoS 防御

作为集群的唯一入口，负载均衡器不仅是流量的调度中心，也是系统安全的第一道防线。

负载均衡器可以作为访问控制点，拦截来自不受信任的来源的请求，防止恶意流量进入内部系统。此外，负载均衡器可以通过部署 IP 黑/白名单、流量限速、请求鉴权等功能，强化对外部攻击的防护能力。

另一方面，负载均衡器通过支持高级安全功能（如 SSL/TLS 终端加密和 Web 应用防火墙）进一步增强了系统的安全性。在面临 DDoS 攻击时，负载均衡器能够通过流量分散、智能限速等手段，有效减轻攻击压力，保护内部资源不受影响。

　

可观测性

从基本的统计信息（如流量、连接数和错误率）到与微服务架构集成的调用链追踪，不同层次的负载均衡器输出的可观测性数据各异：

  • 四层负载均衡器的观测数据集中在连接、流量、延迟等网络层面的分析。
  • 七层负载均衡器的观测数据集中在 HTTP 请求、HTTP 错误码、会话保持、路由分配等应用层面的分析。

需要注意的是，输出可观测性数据并非没有代价，负载均衡器需要进行额外处理来生成这些数据，但所带来的收益远超过那一点性能损失。

　

负载均衡

负载均衡器字面意思是，给到一组健康的后端，选择谁来处理用户请求？也就是负载均衡器的调度算法。

负载均衡调度算法是一个相对活跃的研究领域，从简单的随机选择，到更复杂的考虑各种延迟和后端负载状态的算法，笔者无法逐一展开，这里仅从功能和应用的角度简要介绍一些常见的负载均衡算法。

  • 轮询均衡算法（Round-Robin）：按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点是实现简单。轮询算法假设所有的服务器处理请求的能力都一样，调度器会将所有的请求平均分配给每个真实服务器。
  • 最小连接均衡算法（Least-Connection）：该算法中调度器需要记录各个服务器已建立连接的数量，然后把新的连接请求分配到当前连接数最小的服务器。最小连接均衡算法特别适合于服务器处理时间不一致的场景。例如，当某些请求可能占用较长时间，而另一些请求很快就会完成时，最小连接算法可以有效避免某些服务器因处理大量复杂请求而过载。
  • 一致性哈希均衡算法（Consistency Hash）：将请求中的某些特征数据（例如 IP、MAC 或者更上层应用的某些信息）作为特征值来计算需要落在的节点。一致性哈希算法会保证同一个特征值的请求每一次都会落在相同的服务器上。
  • 随机均衡算法（Random）：此种负载均衡算法类似于轮询调度，不过在分配处理请求时是随机的过程。由概率论可以得知，随着客户端调用服务端的次数增多，其实际效果趋近于平均分配请求到服务端的每一台服务器，也就是达到轮询的效果。

以上算法假设的是所有服务器处理能力均相等，并不管服务器的负荷和响应速度。如果集群内各个服务器处理能力不一致呢？如服务器 A 每秒可处理 10 个请求，服务器 B 每秒可处理 100 个请求，不考虑服务器的处理能力的负载均衡算法，实际上是一种“伪均衡”算法。

考虑各个服务器的处理能力存在差异，负载均衡算法又有了对服务器“加权”的补充。

加权负载均衡算法通过按权值高低分配请求，使权重较高的服务器处理更多连接，从而保证集群内后端服务器的负荷整体均衡。常用的加权负载均衡算法有加权轮询（Weighted Round Robin）、加权最小连接（Weighted Least-Connection）和加权随机（Weighted Random）等等，笔者就不再逐一介绍了。

　

负载均衡部署拓扑

中间代理型

第一种是中间代理型部署拓扑，如图 4-5 所示。这是最常见的负载均衡部署方式，负载均衡器位于客户端与后端服务器之间，负责将请求转发至多个后端服务器。

在这种拓扑中，负载均衡器可以分为以下三类：

  • 硬件设备：由 Cisco、Juniper、F5 Networks 等公司提供的硬件负载均衡设备；
  • 纯软件：如 Nginx、HAProxy、Envoy 和 Traefik 等开源软件负载均衡器；
  • 云服务：包括阿里云的 SLB（Server Load Balancer）、AWS 的 ELB（Elastic Load Balancer）、Azure 的 Load Balancer 和 Google Cloud 的 Cloud Load Balancing 等云平台提供的负载均衡服务。

总结中间代理型优缺点：

  • 优点：配置简便，用户只需通过 DNS 连接到负载均衡器，无需关心后端细节，使用体验简单直观；
  • 缺点：存在单点故障的风险，负载均衡器一旦出现故障，会导致整个系统无法访问。

　

边缘代理型

边缘代理型实际上是中间代理型拓扑的一个变种。

一个典型的边缘代理示例是本书第二章 2.7 节中提到的动态请求‘加速’技术。Akamai 在全球多个数据中心部署边缘节点，这些节点具备代理功能，用户请求会被路由至最近的节点。收到请求后，边缘节点会执行安全检查（如 DDoS 防护），根据缓存策略决定是返回缓存内容（CDN 技术），或者将请求转发至源服务器（请求加速技术）。

总结边缘代理型优缺点：

  • 优点：通过将负载均衡、缓存和安全策略集中在网络边缘，边缘代理显著降低延迟、提高响应速度，并增强安全性（如 DDoS 防护）；
  • 缺点：虽然边缘代理减少了单点故障的风险，但若某个边缘节点发生故障，仍会影响到该节点服务的用户。

　

客户端内嵌

为解决中间代理型拓扑的单点故障问题，出现了更复杂的解决方案，其中之一是将负载均衡器以 SDK 库形式嵌入客户端（如图 4-7 所示）。这些 SDK 库如 Finagle、Eureka、Ribbon 和 Hystrix 等，它们优缺点是：

  • 优点：将负载均衡器功能“转移”至客户端，避免了单点故障问题；
  • 缺点：需要为每种编程语言实现相应的 SDK，且在项目复杂时，处理版本依赖和兼容性问题变得棘手（微服务框架的相关问题将在本书第八章 8.2 节中详细讨论，读者可参考进一步了解）。

　

边车代理型

边车代理型拓扑近年来在微服务架构中得到广泛应用，并发展成为一种被称为“服务网格”（Service Mesh）的架构模式。

边车代理的基本原理是在应用容器或服务旁边部署一个独立的代理容器，用于实现请求的负载均衡和流量管理。目前，像 Envoy 和 Linkerd 等网络型边车代理已被广泛应用。关于服务网格的技术原理，笔者将在第八章中进行详细阐述。

总体而言，中间代理型负载均衡器正逐步演变为功能更强大的“网关”，所有请求通过单一入口（即网关）进入集群。在这种架构下，负载均衡器作为网关，不仅负责基本的请求转发，还承担更高级的请求管理与安全控制，包括 TLS 卸载、请求限制、身份验证和复杂内容路由等。同时，针对东西向流量（即服务间通信），边车代理模式“透明”地接管了服务间的通信治理，正逐渐成为主流选择。

　

四层负载均衡技术

四层负载均衡器的典型代表是 LVS（Linux Virtual Server，Linux 虚拟服务器），由中国程序员章文嵩于 1998 年开发。

当时，章文嵩正在读博士，正是能熬通宵的年纪，他发现硬件负载均衡器价格昂贵，用了几周时间开发了 LVS（最初称为 IPVS）。2004 年，LVS（IPVS）被纳入 Linux 内核 2.4。从此之后，所有 Linux 系统都具备了变身为负载均衡器的能力。

LVS 的基本原理可以用一句话概述，通过修改 MAC 层、IP 层、TCP 层的数据包，实现一部分交换机和网关的功能，将流量转发至真正的服务器上。这三种数据包修改方式分别对应 LVS 提供的三种工作模式，接下来将详细介绍它们的工作原理。

　

直接路由模式

LVS 的直接路由模式实际是一种链路层转发技术。

链路层负转发的原理是，负载均衡器（LVS）收到请求后，修改数据帧的目标 MAC 地址，再由交换机转发至某个“后端服务器”。

需要注意的是，后端服务器接收到的数据包中，IP 层的目标地址（即 VIP）并不属于后端服务器的物理网络接口，这些数据包会被丢弃。因此，必须将 VIP 地址绑定到本地回环接口（lo 接口）。

例如，若某个 VIP 地址为 1.1.1.1，可以通过以下命令将该 IP 绑定到后端服务器的 lo 接口：

$ ip addr add 1.1.1.1/32 dev lo

在直接路由模式中，请求通过负载均衡器转发至后端服务器，而后端服务器的响应无需再经过负载均衡器，请求、转发和响应之间形成“三角关系”，因此该模式也被称为“三角传输模式”，如图 4-9 所示。

直接路由模式优点在于，它特别适合响应流量远大于请求流量的场景。例如，在典型的 HTTP 请求/响应模式中，请求流量可能仅占总流量的 10%，而响应流量占 90%。通过三角传输模式，负载均衡器只需处理 1/10 的总流量。这种设计不仅显著降低了带宽成本，还提升了负载均衡器的可靠性（流量越少、负载越轻、越不容易出现问题）。

当然，直接路由模式也存在明显的缺点：

  • 监控功能受限：由于响应流量直接返回客户端，负载均衡器无法监控完整的 TCP 连接状态，这可能影响防火墙策略的实施。例如，负载均衡器只能捕获 TCP 连接的 SYN 包，而无法跟踪后续的 ACK 包。
  • 网络架构要求高：负载均衡器与后端服务器之间通过链路层通信，因此要求两者位于同一子网内，这对网络拓扑设计提出了较高的要求。

　

隧道模式

在直接路由模式中，请求通过修改链路层的 MAC 地址转发；而在网络层，当然也可以通过修改 IP 数据包实现请求转发。LVS 的隧道模式和 NAT 模式都属于网络层负载均衡，两者的区别是修改 IP 数据包的方式不同。

隧道模式的基本原理是，LVS 创建一个新的 IP 数据包，将原始 IP 数据包作为“负载”（payload）嵌入其中。新数据包随后被三层交换机路由到后端服务器，后者通过拆包机制移除额外的头部，恢复原始 IP 数据包并进行处理。

举一个具体例子，假设客户端（IP 203.0.113.5）向 VIP (1.1.1.1) 发送的数据包如下：

{
  Source IP: 203.0.113.5,
  Destination IP: 1.1.1.1,
  Payload: "Request data"
}

负载均衡器收到数据包后，根据调度算法选择一台后端服务器（172.12.1.3），并对数据包进行封装处理。

{
  Source IP: 172.12.1.2,
  Destination IP: 172.12.1.3,
  Payload: {
    Original Source IP: 203.0.113.5,
    Original Destination IP: 1.1.1.1,
    Original Data: "Request data"
  }
}

将一个 IP 数据包封装在另一个 IP 数据包内，并配合相应的解包机制，这是典型的 IP 隧道技术。在 Linux 中，IPIP 隧道实现了字面意义上的“IP in IP”。由于隧道模式工作在网络层，绕过了直接路由模式的限制，因此 LVS 隧道模式可以跨越子网进行通信。

如图 4-10 所示，由于源数据包信息完全保留，隧道模式因此也继承了三角传输的特性。

隧道模式可以视为直接路由模式的升级版，支持跨网通信。不过，由于涉及数据包的封装与解封，后端服务器必须支持相应的隧道技术（如 IPIP 或 GRE）。其次，隧道模式继承了三角传输的特性，因此后端服务器也需要处理虚拟 IP（VIP）与 lo 接口的关系。

　

网络地址转换模式

另一种对 IP 数据包的修改方式是直接修改原始 IP 数据包的目标地址，将其替换为后端服务器的地址。这种方式被称为“网络地址转换”（NAT）模式，其请求和响应的流程如图 4-11 所示。

举例一个具体的例子，假设客户端（203.0.113.5:37118）请求负载均衡器（1.1.1.1:80），四层负载均衡器根据调度算法挑选了某个后端服务器（10.0.0.2:8080）处理请求。

此时，四层负载均衡器处理请求和响应的逻辑如下：

  • 当客户端请求到达负载均衡器时，负载均衡器执行 NAT 操作：
    • 首先是 DNAT（目标地址转换） 操作：将目标 IP 和端口（1.1.1.1:80）改为后端服务器的 IP 和端口（10.0.0.2:8080），这使得请求能够被路由至指定的后端服务器处理。
    • 为了保持通信的完整性，负载均衡器还会执行 SNAT（源地址转换）操作。也就是原始源 IP 和端口（203.0.113.5:37118）改为四层负载均衡器的 IP 和端口（1.1.1.1:某个随机端口）。SNAT 操作确保后端服务器认为请求是来自负载均衡器，而不是直接来自客户端。
  • 当后端服务器返回响应时，负载均衡器执行相反的 NAT 操作:
    • 将源 IP 和端口改回 1.1.1.1:80。
    • 将目标 IP 和端口改回客户端的 203.0.113.5:37118。

最终，客户端请求/接收的都是负载均衡器的 IP 和端口，并不知道实际的后端服务器信息。

从上述可见，网络地址转换（NAT）模式下，负载均衡器代表整个服务集群接收和响应请求。因此，当流量压力较大时，系统的瓶颈就很容易体现在负载均衡器上。

　

主备模式

到目前为止，我们讨论的都是单个负载均衡器的工作模式。那么，如果负载均衡器出现故障呢？这将影响所有经过该负载均衡器的连接。为了避免因负载均衡器故障导致服务中断，负载均衡器通常以高可用模式进行部署。

图 4-12 展示了最常见的主备模式，其核心在于每台节点上运行 Keepalived 软件，该软件实现了 VRRP（Virtual Router Redundancy Protocol）协议，虚拟出一个对外提供服务的 IP 地址（VIP）。默认情况下，VIP 绑定在主节点（Master）上，由主节点处理所有流量请求。备用节点（Backup）则持续监控主节点的状态，当主节点发生故障时，备用节点会迅速接管 VIP，确保服务不中断。

主备模式的设计在现代分布式系统中非常普遍，但这种方式存在以下缺陷：

  • 在正常运行时，50% 的资源处于闲置状态，备用服务器始终处于空转状态，导致资源利用率低下。
  • 现代分布式系统更加注重高容错性。理想情况下，即使多个实例同时发生故障，服务仍应能持续运行。然而，在主备模式下，一旦主节点和备用节点同时发生故障，服务将完全中断。

　

基于集群和一致性哈希的容错和可扩展模式

近些年，业界开始设计全新四层负载均衡系统，其设计目标是：

  • 避免传统主备模式的缺点。
  • 从依赖厂商的商业硬件方案，转向基于标准服务器和网卡的通用软件解决方案。

如图 4-13 所示，这种设计被称为“基于集群和一致性哈希的容错和可扩展性”（Fault Tolerance and Scaling via Clustering and Distributed Consistent Hashing）。其工作原理如下：

  • N 个边缘路由器使用相同的 BGP 权重通告所有 Anycast VIP[1]，确保同一流（flow）的所有数据包都通过相同的边缘路由器。
  • N 个四层负载均衡器使用相同的 BGP 权重向边缘路由器通告 VIP，确保同一流的数据包始终经过相同的四层负载均衡器。
  • 每个四层负载均衡器实例通过一致性哈希算法，为每个流选择一个后端服务器。

总结该模式的优点：

  • 边缘路由器和负载均衡器实例可以根据需求动态扩展，数据流的转发不受影响。
  • 通过预留足够的突发量和容错空间，系统资源的利用率可根据实际需求优化，确保最优配置。
  • 无论是边缘路由器还是负载均衡器，都可以基于通用硬件构建，且其成本仅为传统硬件负载均衡器的一小部分。

　

从七层负载均衡到网关

早期的七层负载均衡器（如 Nginx）依赖静态配置，仅具备基本的请求代理功能。随着微服务架构兴起，负载均衡器开始承担更多职责，逐步从“流量工具”演变为“系统的边界控制层” —— 网关。

业界较流行的网关系统（高级负载均衡器）如表 4-1 所示。

称简介
OpenResty基于 Nginx 的高性能 Web 平台，集成了大量模块，用来处理 HTTP 请求，被许多企业作为内部网关的基础框架。
Kong构建在 OpenResty 上的网关平台，有丰富的插件体系，支持身份认证、限流、日志记录、监控等功能。
Spring Cloud GatewaySpring 框架下的 API 网关解决方案，与 Spring Cloud 生态（如 Eureka、Config Server）深度集成，广泛应用于 Java 技术栈的微服务项目。
Traefik专为容器化系统设计，可与 Kubernetes、Docker 无缝集成。支持自动服务发现、动态配置路由、请求限流、身份验证、可观测等。
EnvoyEnvoy 是 Lyft 开发的一款面向服务网格的高性能网络代理，支持高级的路由控制、负载均衡策略、服务发现和健康检查等。Envoy 与 Istio 紧密结合，通常作为服务网格的数据平面出现。

　

这些网关（高级负载均衡器）各有各的特点，实现的功能也非常强大，笔者不再逐一介绍，简单列举部分功能，以便读者对“强大”有个直观的感受。

  • 协议支持：负载均衡器对应用层协议了解的越多，就可以处理更复杂的事情，包括系统可观测、高级负载均衡和内容路由等。以 Envoy 为例，它支持 HTTP/1、HTTP/2、HTTP/3（QUIC）、gRPC、TCP、TLS、WebSocket、PostgreSQL、Redis、MongoDB、DynamoDB 等协议。
  • 动态配置：随着系统的动态性不断增强，需要在两个方面进行投入，一是动态控制，即实时调整系统行为；二是响应式控制，即根据环境变化做出快速反应。以 Istio 为例，它的架构分为控制平面和数据平面：
    • 数据平面：专注于动态控制，负责执行微服务之间的请求转发、负载均衡、熔断、重试、超时等流量管理策略。
    • 控制平面：专注于响应式控制，通过集中式配置和管理，为数据平面提供统一接口，用于定义和修改流量管理策略。
  • 流量治理：在分布式架构中，服务间通信治理（如超时、重试、限速、熔断、流量镜像、缓存等）是系统稳定性的重要保障。作为集群的入口，负载均衡器将服务间通信治理需求统一收敛，这极大降低了业务系统的运维难度。
  • 可观测：目前，指标监控、链路追踪和日志记录已成为高级七层负载均衡器的标配功能。如上面提到的 Envoy 和 Traefik，均支持与 Prometheus、Grafana、Jaeger 等监控系统集成。
  • 可扩展：网关系统通常是插件化的，开发者可以根据需求灵活加载特定插件。例如，在 OpenResty 上，通过编写 Lua 脚本或集成第三方插件，可实现数据缓存、身份认证、安全防护、日志监控等自定义功能。
  • 高可用及无状态设计：网关系统强调“无状态”（stateless）架构设计，即每个请求都被视为独立的，不依赖于任何先前的请求或存储在服务器上的会话信息。通过消除服务器状态依赖，系统能够轻松实现水平扩展！

　

全局负载均衡设计

近年来，负载均衡系统的发展趋势是将单个负载均衡器视为通用的标准化组件，由一个全局控制系统统一管理。

图 4-14 展示了全局负载均衡系统设计。

  • 边车代理（Sidecar Proxy）和位于三个 Zone 的后端通信。
  • 边车代理、后端定期向全局负载均衡器（Global Load Balancer）汇报请求延迟、自身的负载等状态，全局负载均衡器根据状态做出最合适的配置策略。
  • 全局负载均衡器向边车代理下发转发策略，可以看到 90% 的流量到了 Zone C，Zone A 和 B 各只有 5%。

全局负载均衡器能够实现很多单个负载均衡器无法完成的功能，比如下面这些。

  • 某个区域故障或负载过高时，全局负载均衡器自动将流量切换到其他可用区。
  • 利用机器学习、神经网络技术检测并缓解流量异常问题。比如识别并治理 DDoS 攻击。
  • 收拢边车代理配置，提供全局运维视角，帮助工程师直观理解、维护整个分布式系统。

全局负载均衡器在服务网格领域表现的形式称为“控制平面”（Control Plane），控制平面与边车代理协作的关键在于配置动态化。

　

小结

负载均衡作为分布式系统的入口，直接影响整个系统的行为。因此，这一领域的竞争异常激烈，技术创新不断涌现。

在四层负载均衡领域，传统的硬件负载均衡设备（如 F5）正逐步被基于通用服务器和专用软件（如 IPVS、DPDK、fd.io）的解决方案所取代。例如，基于 DPDK 的流量转发和数据包处理技术，即使普通的物理机，也能轻松实现每秒百万至数千万的每秒数据包处理能力。在七层负载均衡领域，随着微服务架构的快速发展，传统代理软件（如 NGINX、HAProxy）逐渐被更适应动态微服务环境的解决方案（如 Envoy、Traefik）所取代。

总体而言，随着技术架构逐步向云厂商主导的 IaaS、CaaS 和 FaaS 模式演进，工程师未来将很少需要关注物理网络的工作原理，隐藏在 XaaS 模式之下的各类网络技术，正逐渐演变为“黑科技”。