构建弹性网络之分布式负载均衡技术（二）：技术与实现

随着信息技术的飞速发展，企业对于网络的依赖程度日益加深。传统的负载均衡技术曾经是企业数据中心的“守护神”，如今却在应对现代应用的快速交付、成本效益和自动化运维方面面临前所未有的挑战。分布式负载均衡技术可为企业网络带来革命性的改变。本文将深入分析从技术层面实现分布式负载均衡的关键要素，从弹性地址、“N+1”高可用系统到数据面与管理面的通信，介绍分布式负载均衡技术如何克服传统负载均衡技术的局限性，以确保网络的高性能和高可用性。

一、二层广播域弹性地址的实现

传统负载均衡设备诞生于一个对资源成本敏感度较低、对稳定性有一定要求，但尚未普遍面临大规模并发和动态扩展需求的时代。所以，传统负载均衡设备采用双机主从架构的设计思路，仅提供基本的故障转移能力，控制面与数据面没有分离，设备也不会从组织管理层面开放给各个业务团队。传统负载均衡设备通常基于图1所示的架构实现。

1.传统负载均衡架构的主要技术细节

一是两台主机通过独立的心跳线互联，基于类似虚拟路由冗余协议（Virtual Router Redundancy Protocol,VRRP）监控状态、选举主从节点。 二是两台设备必须在一个广播域内，由选出的主设备广播免费ARP（Gratuitous ARP,GARP）消息，从设备则不回应ARP或者ICMP查询，这种实现方案依赖于交换机维护的虚拟IP（Virtual IP,VIP）与MAC地址的映射表。

传统负载均衡设备双机主从架构

2.传统双机主从架构存在的问题

• （1）资源利用率低 VIP在局域网内只能对应主设备，从设备对VIP而言处于完全闲置状态，所以资源利用率较低。
• （2）基础容量上限低 一旦虚拟服务消耗的带宽、并发连接数等超过主设备上限，必须要通过升级硬件或者迁移设备才能解决问题。
• （3）七层负载均衡功能需要分离 虽然传统负载均衡设备支持完备的OSI七层协议，然而，正则表达式匹配、ASCII码压缩等行为都很消耗CPU资源，因此，运维人员在双机CPU核心数极为有限的情况下，只能将消耗CPU的七层API网关从负载均衡设备集群上移除，将网络结构从一层分离为两层（如下图所示），从而提升了运维复杂度，增加了请求时延。

传统负载均衡集群规模上限带来的负载分层现象

• （4）容错能力有限 如果两台负载均衡设备因为某种原因停止通信，就可能发生所谓的“脑裂”（Split-brain）现象。在这种情况下，每台设备都认为自己是主设备，并且独立地处理请求，导致数据不一致。当双机集群最终恢复通信时，由于在脑裂期间两台设备可能已经独立地进行了状态更新或数据写入，这种数据不一致的问题无法通过自动化方案来解决，需要人工干预进行数据的同步和一致性校验，以确保系统的完整性和可靠性。这与当下的自动化运维DevOps方案格格不入。
• （5）网络部署结构限制性大 如果两台负载均衡设备分属不同的广播域，就无法构成高可用集群。

3.一主多辅架构的实现技术

早期网络规模有限时，网络缺乏弹性对其并没有太大影响，但在当下网络规模庞大的情况下，缺乏弹性会极大影响资源与运维效率。双机主从架构存在的上述问题，其根源在于VIP实现的技术局限性，阻碍了服务的弹性扩展和高可用性的最大化。为突破这些限制，分布式负载均衡系统分离了控制面与数据面，使其各自实现了“多活”VIP技术。 数据面分别在OSI七层协议模型的第二层（数据链路层）和第三层（网络层）实现了“多活”VIP地址。为方便区分控制面与数据面，后续涉及分布式负载均衡架构时，其数据面的设备将称为“转发引擎”，管理面的设备称为“管理节点”。分布式负载均衡架构如下图所示。

分布式负载均衡架构

在二层广播域内，分布式负载均衡架构采用了“一主多辅”架构，在处理以下场景时，该架构能够充分利用多设备的处理能力优化资源分配，即入流量小而出流量大的业务、消耗大量CPU资源的业务（如SSL卸载、实时数据压缩等），以及并发连接数超出单个转发引擎内存的限制时。一主多辅架构的实现技术如下： 一是主引擎通过向局域网内的交换机广播GARP报文，声明自己是VIP的拥有者，这样所有流向该VIP的流量都会被交换机定向到主转发引擎。 二是主引擎依据TCP/IP五元组（源IP、源端口、目的IP、目的端口和协议类型）对流量执行哈希运算，以确保来自同一客户端的连接能够被均匀且持续地分配到自身及辅转发引擎上。 需要强调的是，一旦连接建立，辅转发引擎的响应流量无需再经过主引擎返回，减少了网络延迟和主转发引擎的处理负担，提高了整体的响应速度和系统吞吐量。这种设计特别适合出流量大、大量消耗CPU和磁盘等资源、对响应时间敏感的静态资源服务，可有效缓解主从架构下的性能瓶颈问题，提升系统的扩展性和可用性。 一主多辅架构在容灾、故障恢复的平滑度上也优于主从架构。以一主三辅架构为例，此时四台转发引擎共同服务于一个VIP，当一台转发引擎发生故障时，其对整体服务的影响被限定在25%左右，即使主转发引擎发生故障，上述结论仍然成立。由于每台辅转发引擎都独立维护着连接状态表，系统可以从集群空闲转发引擎中选出新的主转发引擎，其可以通过整合连接状态表无缝接管服务，确保除了原主转发引擎处理的那部分流量受到影响外，其余流量可以被继续处理。相比主从模式中主设备故障即导致服务完全中断的情况，一主多辅架构有效缩短了故障带来的服务中断时间，缩小了服务中断范围，提升了用户体验和业务连续性。

二、三层网络层弹性地址的实现

一主多辅架构只能提升二层广播域内的性能和容灾能力，当面对更大规模的集群部署或复杂的网络架构时，仅仅局限于二层的技术无法满足业务的弹性需求，此时可以通过等价路由（Equal-Cost Multi-Path,ECMP）技术在三层网络层实现“多活”VIP。ECMP技术不仅可扩展集群的地理覆盖范围，还突破了单一广播域的容量天花板，在真正意义上实现了大规模分布式系统的无边界扩展。

1.ECMP技术的应用

ECMP的工作原理是基于路由协议（如BGP、OSPF）在多台设备之间分配等价的多条路径。当多条路径成本相同时，网络设备（如路由器或三层交换机）会利用ECMP算法自动将流入的流量按照预设规则均匀地分发到这些路径上。这样一来，每条路径上的转发引擎都可以作为主转发引擎同时处理流入的流量，并消除了单点故障和容量上限的限制。 图3中三层VIP是怎么实现的呢？每台转发引擎都会配置相同的VIP地址，并通过路由协议宣告此地址可达，路由器会根据ECMP算法，将去往这个VIP的流量均衡地分发到转发引擎上。在实际的应用中， ECMP算法通常由基于TCP/IP五元组的哈希算法实现，这样的设计具有以下四方面的显著优势。

• 一是会话保持。基于TCP/IP五元组的哈希算法能够确保属于同一会话的数据包始终被同一路径处理，这对于维持TCP连接的连贯性和避免乱序至关重要。
• 二是负载均衡。通过将TCP/IP五元组映射到不同的路径，运用哈希算法能够较为均匀地分散流量，实现有效的负载均衡，避免某条路径过载。
• 三是扩展性与灵活性。随着网络规模的增长，只需增加新的路径并确保其成本等价，即可无缝扩展网络处理能力，无需调整现有网络配置。
• 四是故障恢复。当某条路径失效时，原本通过该路径的数据包会根据哈希规则被重新分配到其他有效路径上，从而快速实现故障绕行和网络恢复。 相对于一主多辅方案，ECMP方案允许每台设备独立处理流量，无需通过单一主设备中转，减少了网络延迟，提升了数据处理效率。由于ECMP技术无法应用在广播域内，所以需要将二层广播域的一主多辅架构与三层网络层的ECMP技术相结合，才能为弹性VIP地址的实现提供完整的技术支撑，在不同的网络层次上实现负载均衡和故障转移。2.扩容和迁移策略 当VIP地址足够灵活后，就可以通过扩容、缩容、迁移实现虚拟服务的弹性。例如，当监控系统检测到某个转发引擎的CPU使用率在最近15分钟内持续超过85%，则表明该转发引擎可能需要更强的处理能力来应对当前的负载，这时系统管理员或自动化工具可以采取扩容或迁移两种策略来提升处理能力。 扩容策略是指在现有的转发引擎上纵向增加计算资源（如修改虚拟机的配置），或者横向添加新的转发引擎实例来分担负载，其中新实例既可以是所属转发引擎集群中的空闲实例，也可以直接对接IaaS层的OpenStack、Kubernetes Master以分配新的转发引擎实例。迁移策略则是指将转发引擎上的虚拟服务动态灰度地迁移到其他转发引擎上。 选择扩容还是迁移策略，要看这台转发引擎上有没有消耗CPU资源的“大户”。为此，需要监控转发引擎上每个虚拟服务的资源消耗指标，如每秒处理报文数（Packets Per Second,PPS）。如果有1个虚拟服务的PPS占比超过70%，表明迁移很难解决问题，需要为该虚拟服务扩容才可以更有效地分配资源。反之，意味着多个虚拟服务共同导致了CPU的高负载，这时迁移策略就显得更为合适。通过将其中一个虚拟服务迁移到其他空闲的转发引擎上，可以减轻当前转发引擎的负担，优化资源分配。如果虚拟服务在多个转发引擎上的CPU使用率都相对较低，则可能意味着当前的资源配置超出了需求。在这种情况下，可以采取缩容措施，自动减少转发引擎的实例数量，从而节省资源、降低成本。弹性虚拟服务的扩容、迁移策略如下图所示。

弹性虚拟服务的扩容、迁移策略示意

三、高可用管理面的实现

当转发引擎宕机后，需要将其上的虚拟服务迁移到另一台正常运行的转发引擎，为了确保服务的连续性和一致性，需要满足以下两个前提条件。 首先，数据面必须保持无状态，这意味着每个转发引擎在处理数据包时，不应该依赖于任何持久化的状态信息。转发引擎应该专注于数据的快速转发，独立地处理流量，不需要访问存储在其他引擎上的状态信息。这样不仅可以提高转发效率，也简化了故障恢复过程，即使某个转发引擎发生故障，其他引擎也能够无缝地接管服务。 其次，管理面必须具备高可用性。这意味着管理组件需要能够容忍故障，并且能够在发生故障时快速恢复。由于传统负载均衡设备的双机集群无法解决脑裂问题，一台设备宕机后集群的写入能力是无法保障的。为了解决这一问题，需要使用“N+1”高可用模型，保持至少1个冗余节点，在1个管理节点宕机时，管理面仍然能够保持服务可读可写。因此，至少要具备3个管理节点，才能在集群分成两个独立组时，通过少数服从多数的投票策略，使集群仍然可以正常提供服务。 分布式系统的CAP理论（如图5所示）指出，系统在任何时刻只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两个性能。这意味着需要存储数据的管理集群只能优先选择分区容错性和数据强一致性，而要牺牲部分可用性。

分布式系统对一致性、可用性、分区容错性的权衡

分布式负载管理面的核心功能是协调和控制，而不是处理高流量的业务数据，因此可以降低其对性能的要求。管理面主要是通过API与外部系统或转发引擎进行通信，这些操作对实时性的要求较低。 对于需要高度一致性的决策过程，可以采用Paxos之类的共识算法。这些算法通过两个阶段的提交机制来确保数据的持久化和一致性。在第一阶段，提案（数据变更）被提出并由集群中的大多数成员进行投票；在第二阶段，如果提案获得多数票，就会被提交并应用到所有成员的状态中。这样的机制确保了部分节点宕机时整个系统仍然能够就数据变更达成一致，从而实现系统的高可靠性。此外，Raft协议改进了Paxos算法，通过设计简单、直观的Leader选举、线性一致的日志复制机制，降低了数据变更时的冲突概率，在确保数据强一致性的同时提升了系统性能，是管理面的首选算法之一。

四、管理面与数据面的通信

要实现管理面与数据面之间的通信，必须解决以下四个问题。

1. 高并发通信需求 由于数据面的集群规模可能非常庞大，管理节点需要与转发引擎集群维持并发连接，同时，七层负载的功能还需要快速迭代，所以采用灵活的协程机制可以确保通信的高效和稳定。
2. 复杂网络结构下的通信安全 由于集中式的管理面需要跨越IDC、云与所有转发引擎通信，所以除网络环境的安全之外，管理面与数据面通信必须充分考虑安全认证、加密传输等因素，以保障数据传输的安全性和可靠性。
3. 多租户管理 分布式负载均衡系统同时服务于众多业务团队，这就要求系统能够通过多租户机制来隔离不同团队的管理上下文。因此，分布式负载均衡设备上配置的所有元素都需要添加租户标签，以租户为粒度管理虚拟服务及其他配置元素。 在数据面上，租户既可以通过独立部署各自的转发引擎集群实现服务隔离，也可以选择共享转发引擎资源，以提高资源利用率和降低成本，这适合规模较小或成本敏感型的应用，可在保障一定隔离性的同时优化资源分配和效率。 由于分布式负载系统涉及OSI七层协议中从物理层到应用层的网络资源，因此还必须通过定义具有不同权限的角色来控制租户内部以及跨租户的资源访问。
4. 遥测（Telemetry）数据上报 为了有效管理和分析大规模数据面集群产生的遥测数据，数据上报策略应明确将数据划分为以下三类。 一是实时上报数据。这类数据具备转发引擎的健康状态变化等关键指标，它们对于即时监控系统状态至关重要，需要实时或近实时地上报，以便快速响应可能发生的任何问题。 二是周期上报数据。这类数据包括CPU负载、内存使用率、网络流量等定期收集的性能指标数据，通常按照一定的时间间隔上报，用于长期的性能监控和趋势分析。 三是事件触发上报数据。这类数据的上报是由特定事件触发的，例如管理员对某个虚拟服务执行抓包操作，或者API调用请求拉取用户访问日志以分析故障原因。事件触发的数据上报通常按需进行，与特定的用户行为或系统事件相关。 通过这种分类方法，可以确保监控系统既能够快速响应紧急情况，又能够有效地进行长期性能分析，同时还能够灵活地处理由特定事件触发的数据收集需求。 另外，由于一台虚拟服务由多台转发引擎共同处理流量，因此需对这些遥测数据进行标签化以及结构化分层，以便进行横跨复杂网络的故障分析，这对于维护大规模分布式系统的稳定性和性能至关重要。 综上所述，管理面与数据面之间的通信需要进行系统化的全面设计，综合考虑并发处理能力、网络安全、多租户支持以及跨网络服务的监控需求，以确保整个集群的高效、安全和稳定运行。

小结

本文首先从OSI模型的数据链路层和网络层，通过”一主多辅”和ECMP技术实现了弹性虚拟服务，有效支持了大规模网络的并发处理和动态扩展。为了减少容灾场景的影响范围，介绍了传输层的会话连接表，提升了故障恢复的效率。对于七层负载在应用层的CPU消耗问题，介绍了自动缩扩容与迁移技术，以应对业务需求的波动，避免了四、七层负载集群的分层。 在数据面外，文章还讨论了通过共识算法实现高可用的管理面集群，以及数据面如何与管理面通讯，才能保障不同租户产生的大量遥测数据，能够在不影响业务的情况下，为监控、分析和管理大规模分布式系统提供高效、安全、稳定的支持。 本文为分布式负载均衡技术系列的第二篇，下一篇将通过具体的案例进一步分析这些技术在实际应用中的表现和效果。通过这一系列的深入剖析，我们期望读者能够获得必要的知识，以评估和实施分布式负载均衡解决方案，从而提升自身网络的弹性和响应能力，满足不断变化的业务需求。