- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
Copyright © 2026 新华三技术有限公司 版权所有，保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。
除新华三技术有限公司的商标外，本手册中出现的其它公司的商标、产品标识及商品名称，由各自权利人拥有。
本文中的内容为通用性技术信息，某些信息可能不适用于您所购买的产品。
随着信息技术的高速发展，业务系统的访问规模和复杂度呈指数级增长。互联网应用的普及、云计算的兴起、移动终端的广泛使用，使得网络流量分布更加动态且难以预测。与此同时，用户对业务连续性、响应速度和服务质量的要求不断提升，任何服务中断或延迟都可能导致重大经济损失和品牌声誉受损。
在云化、智能化的浪潮中，网络承载的业务流量和复杂性持续攀升，如何保障服务的高可用性、低延迟和灵活扩展，已成为运营商、金融机构以及各类企业网络架构的核心诉求。
负载均衡技术提供高效便捷的流量分发服务，通过对访问流量进行分析、调度和优化，将访问流量自动分配给多个数据中心、多条链路或多台服务器，从而提高业务处理能力，保证业务的高可靠性。
本白皮书围绕负载均衡技术展开系统阐述，帮助读者全面理解负载均衡技术的原理。
负载均衡技术可分为以下几种类型：
· 服务器负载均衡（SLB，Server Load Balancing）：在数据中心或企业网络中，SLB将客户端的访问请求动态分配至多台服务器进行处理，从而分担单台服务器的压力，提高整体服务的并发处理能力与可靠性。
· 链路负载均衡：当网络存在多条链路时，此技术可动态选择合适的链路转发数据流量，从而提升链路利用率和访问质量。链路负载均衡包括：
¡ 出链路负载均衡：当内网用户访问外部互联网存在多条链路时，此技术可将访问流量分担到多条链路上，实现出口流量的负载均衡。
¡ DNS透明代理：当内网用户通过外部DNS服务器解析域名时，此技术可对DNS请求进行透明代理。在不改变客户端原有DNS配置的前提下，实现出口流量的负载均衡。
¡ 入链路负载均衡：当外网用户访问内网服务器存在多条链路时，此技术可在多条链路上分担外网用户访问内网服务器的流量。入方向链路负载均衡技术又称为本地智能DNS技术。
· 全局负载均衡（GSLB，Global Server Load Balancing）：在跨地域、多数据中心部署的场景中，此技术可根据用户所在地域、网络状况、各数据中心的负载情况等，为用户选择最优的数据中心，实现跨地域业务流量的分配与调度。全局负载均衡技术又称为全局智能DNS技术。
不同的负载均衡技术需要部署在网络中的不同位置，以完成各自的流量调度任务，具体部署位置如下图所示。
图1 负载均衡技术概览图
负载均衡技术具有以下优势：
· 高性能：通过将业务较均衡地分配到多台设备或多条链路上，提高了系统的整体性能。
· 可扩展性：可以方便地增加集群中设备或链路的数量，在不降低业务质量的前提下满足不断增长的业务需求。
· 高可靠性：单个甚至多个设备或链路发生故障也不会导致业务中断，提高了系统的整体可靠性。
· 可管理性：大量的管理工作都集中在应用了负载均衡技术的设备上，集群中的设备或链路只需要进行普通的配置和维护。
· 透明性：对用户而言，集群等同于一个可靠性高、性能好的设备或链路，用户感知不到也不必关心具体的网络结构。增减集群中的设备或链路不会影响正常业务。
在企业或大型数据中心场景下，需要多台服务器同时对外提供服务。服务器负载均衡技术能将用户流量在多台服务器间进行合理分配，从而提高服务器资源利用率，提升用户访问体验。
如下图所示，通过服务器负载均衡技术，管理员可将多台真实服务器配置成一台虚拟服务器，对外发布虚拟服务器的IP地址。当用户流量访问虚拟服务器时，SLB设备根据预先配置的调度算法、负载均衡策略等为用户流量分配最优的服务器资源。
图2 服务器负载均衡简介图
在服务器负载均衡技术中，涉及以下关键概念：
· 虚服务器（Virtual Server）：对外提供服务的虚拟服务器，在SLB设备上创建，由协议类型、IP地址和端口唯一标识。外部用户的访问请求首先到达虚服务器，只有匹配虚服务器的流量才会进入服务器负载均衡处理流程，并由SLB设备分发到后端真实服务器。
· 实服务器（Real Server）：实际承载业务应用的物理服务器，部署在SLB后端，负责处理用户请求并返回响应。
· 实服务组（Server Farm）：一组业务相同或相似的实服务器组成的服务器集群。SLB根据配置的调度算法，在实服务组中的多台实服务器间分配流量，实现流量负载分担。
服务器负载均衡的工作流程如下图所示。
服务器负载均衡工作流程简述如下：
(1) 客户端向SLB设备发送访问请求，此时的源IP地址为客户端IP地址，目的IP地址为虚服务器IP地址（图中简写为VSIP，即Virtual Server's IP）。
(2) SLB设备根据健康检测方法、会话保持方法、负载均衡策略、调度算法等，综合计算出将访问请求分发给哪台实服务器，并将报文的目的IP地址转换为选中的实服务器的IP地址。
(3) 设备将访问请求转发给实服务器，此时的源IP地址为客户端IP，目的IP地址为实服务器的IP地址。
(4) 实服务器接收并处理请求报文，返回响应报文，此时的源IP地址为实服务器的IP地址，目的IP地址为客户端IP地址。
(5) 设备收到响应报文后，将其源IP地址转换为虚服务器IP地址。
(6) 设备向客户端转发响应报文，此时的源IP地址为虚服务器IP地址，目的IP地址为客户端IP地址。
从上述工作流程可以看出，服务器负载均衡的核心在于：当SLB设备接收到用户请求时，如何选择由哪一台实服务器处理用户请求。
当SLB设备收到匹配某虚服务器的请求报文时，会对该报文发起服务器负载均衡调度。此时，实服务器的选择有两种方式：
对于匹配虚服务器的流量，SLB设备会查找并调用该虚服务器关联的负载均衡策略。设备会根据预先配置的负载均衡类对请求报文进行匹配，对于命中负载均衡类的报文，执行与之关联的负载均衡动作。例如：将报文转发到指定的实服务组。在选定的实服务组中，依据预先配置的调度算法，从组内多个实服务器中选出一台作为目标服务器。
相关概念说明如下：
· 负载均衡类（LB class）：对进入设备的报文进行分类的规则，用于将不同类型的报文划分到不同的负载均衡类，便于后续执行差异化的负载均衡动作。
· 负载均衡动作（LB action）：针对被分类报文所执行的具体处理行为，如转发到指定实服务组。
· 负载均衡策略（LB policy）：将“负载均衡类”和“负载均衡动作”进行关联后形成的策略集合。虚服务器通过引用相应的负载均衡策略，实现对请求报文的精细化控制。
图4 设备上的业务处理流程图（经负载均衡策略转发）
服务器负载均衡也可以不使用负载均衡策略，而是将虚服务器直接关联到某个实服务组。
在这种方式下，虚服务器接收到请求流量后，设备直接依据该实服务组中配置的调度算法，从组内多个实服务器中选出一台作为目标服务器。
在实际调度过程中，实服务器的选择不仅受上述方式影响，还会综合考虑健康检查结果、会话保持、带宽管理等因素，对候选实服务器进行过滤，从而得到最优的目标实服务器。
根据可识别报文信息所在的协议层不同，服务器负载均衡可以分为四层服务器负载均衡和七层服务器负载均衡两类。
四层SLB工作在网络层和传输层，可识别报文的IP地址（源IP、目的IP）及传输层端口号（源端口、目的端口），并据此进行负载分配。它采用基于流的转发机制，将同一条连接（如TCP会话或UDP流）的所有报文始终分发至同一台实服务器。
四层SLB适用于高并发、大流量的业务场景。当业务对性能和延迟敏感，而对应用层负载策略依赖较低时，优先推荐采用四层SLB。
七层SLB基于应用层报文内容进行流量分发。在四层SLB的基础上，进一步解析并识别应用层特征信息，如URL路径、HTTP头部、Cookie、报文体等，再结合调度算法选择目标服务器。
七层SLB支持多种应用层协议，包括：Diameter、HTTP、HTTPS、MySQL、RADIUS、SIP等。这种广泛的协议支持，使其不仅可以服务于Web系统，还能覆盖电信计费、认证鉴权、数据库访问、IP语音通信等多类业务场景。
七层SLB适用于需要结合业务逻辑或用户信息进行精确化流量调度的场景。当业务逻辑复杂、需要内容级或用户级负载策略时，推荐采用七层SLB。
四层SLB与七层SLB可结合部署。先通过四层SLB实现高性能流量分发，再对特定业务流量引入七层SLB处理应用层需求，从而在性能与功能之间实现平衡。
如下图所示，在网关模式中，SLB设备串连部署在实服务器前端，客户端的请求流量和服务器的响应流量均会经过SLB设备处理。
当客户端的请求流量经过SLB设备时，SLB设备选出最优的实服务器，并将客户端请求的VSIP转换为选中的实服务器的IP地址，再转发至实服务器。实服务器处理完成后，将响应报文发送至SLB设备，SLB设备会将其源IP地址还原为VSIP，转发回客户端。
在网关模式下，所有往返流量都经由SLB设备转发。因此，管理员通常需要在实服务器上将默认网关指向SLB设备；或配置合适的静态路由，使发往客户端的报文能够先到达SLB设备。
网关模式将SLB设备串接在原有组网中，会改变已有的网络拓扑，仅适用于组网较为简单的部署场景。
如下图所示，在旁路模式中，SLB设备以旁挂的方式连接在核心交换机上，客户端的请求流量和服务器的响应流量均会经过SLB设备处理。
在旁路模式下，客户端访问VSIP时，请求报文经核心交换机转发至SLB设备。SLB设备选出最优的实服务器，并将客户端请求的VSIP转换为选中的实服务器的IP地址，再经核心交换机转发至实服务器。实服务器处理完成后，将响应报文发送至核心交换机。核心交换机根据路由或策略将响应报文转发给SLB设备，SLB设备将报文的源IP地址还原为VSIP，再通过核心交换机转发回客户端。
在旁路模式下，管理员通常需要在实服务器上配置默认网关或静态路由，使发往客户端的报文能够先到达与SLB设备相连的核心交换机，再由核心交换机将其转发至SLB设备。
相比网关模式，旁路模式不改变原有网络拓扑，对现有网络结构影响较小，部署更为灵活，适用于对网络拓扑改动敏感、但仍希望由SLB设备统一处理请求与响应流量的场景。
如下图所示，三角传输模式与旁路模式的网络拓扑相同，SLB设备同样旁挂部署在核心交换机上，但不同的是，SLB设备与实服务器之间通过二层传输，且只有客户端的请求流量会经过SLB设备处理，实服务器的响应流量不会经过SLB设备处理。
在三角传输模式下，客户端访问VSIP时，请求报文经核心交换机转发至SLB设备。SLB设备选出最优的实服务器，并对报文进行二层改写后转发给选中的实服务器。此时，请求报文的源IP地址为客户端的IP地址，目的IP地址仍为VSIP，目的MAC地址为实服务器的MAC地址。实服务器接收并处理请求报文后，直接向客户端返回响应报文，响应报文不再经过SLB设备处理。此时，响应报文的源IP地址为VSIP，目的IP地址为客户端IP地址。
在三角传输模式中，管理员需要在实服务器上配置默认网关或静态路由，将发往客户端的报文发送到核心交换机上。此外，管理员还需要在实服务器上将VSIP配置为本地地址（通常配置在Loopback接口上），以便正确接收并处理目的IP为VSIP的请求报文。
相比网关模式，三角传输模式不改变原有网络拓扑，部署更为灵活；相比旁路模式，三角传输模式的回程流量不经过SLB设备，更适用于诸如视频、下载等业务流量较大的场景。
在最常见的服务器负载均衡工作流程中，SLB设备会对客户端请求报文的目的IP地址进行转换，将VSIP转换为实服务器IP地址，这种转换通常称为目的地址转换（DNAT）。在此基础上，管理员也可以按需配置源地址转换（SNAT）功能。
本节所述DNAT和SNAT，主要适用于SLB设备对请求报文进行IP地址转换，并且实服务器响应报文会经SLB设备转发的组网方式，比如网关模式和旁路模式。
对于SLB设备不对目的IP地址做转换，且实服务器响应报文直接通过自身出口返回客户端的组网方式，如果需要进行地址转换，通常需要在服务器上游的路由器、边界网关或防火墙设备上实现相应的NAT策略控制，比如三角传输模式。
配置SNAT后，客户端的请求报文到达SLB设备，并选中某台实服务器后，SLB设备不仅会转换报文的目的IP，还会转换报文的源IP：将客户端真实IP转换为指定的SNAT地址。对于响应报文，SLB设备会将其源IP还原为VSIP，目的IP还原为客户端IP，并将报文发回客户端。
配置SNAT后，实服务器收到报文的源IP，不再是客户端的真实IP，而是SLB设备使用的SNAT地址。因此，与源IP相关的策略（例如：基于源IP的访问控制、日志审计、统计分析等）需要在SLB设备侧或应用层进行相应的配置调整（例如，在HTTP Header中插入真实客户端IP地址）。
管理员可以根据实际组网需求，灵活选择是否配置SNAT功能。下面列举几种典型的需要配置SNAT的场景：
· 场景一：实服务器的默认网关未指向SLB设备，且不便修改。
若实服务器的默认网关指向核心或汇聚设备，而不是SLB设备，则在仅采用DNAT的情况下，实服务器可能根据默认路由，直接将响应报文发往核心或汇聚设备，从而绕过SLB设备。
在这种场景下，管理员可以配置SNAT功能，将客户端请求报文的源IP地址转换为SNAT地址（通常为SLB设备的业务地址或SNAT地址池中的地址）。这样，实服务器在返回响应报文时，只需发往其默认网关，再由默认网关根据路由将报文转发回SLB设备，即可在不修改服务器默认网关的前提下，简化后端路由配置，并保证回程路径可控。
· 场景二：服务器存在多出口或复杂路由，容易出现三角路由。
在仅进行DNAT时，请求经SLB设备转发到实服务器，但实服务器的响应报文可能根据默认路由或其他出口策略，从另一条链路或出口设备发回客户端，形成“三角路由”，导致会话路径不对称，SLB设备无法完整感知整个会话。
配置SNAT功能后，客户端请求的源IP地址被转换为SLB设备的SNAT地址，实服务器视角中对端地址统一为该SNAT地址。实服务器只需将响应报文发往默认网关，再由上联网关设备根据路由将报文统一转发回SLB设备，从而保证会话路径对称，避免三角路由问题。
· 场景三：希望所有回程流量经过SLB设备，进行统一管理和统计。
在某些场景中，管理员希望所有业务流量都经过SLB设备，以便统一实施管理和统计，例如：在SLB设备上实施统一的带宽管理或限速策略；在SLB设备上进行精细化的流量统计与监控；结合安全策略，对入/出方向的流量进行统一的访问控制和审计。
配置SNAT功能后，实服务器视角中的对端地址被统一为SLB设备的SNAT地址，服务器的响应流量将集中返回SLB设备，便于SLB设备对流量进行统一管理和统计。
在仅部署单台SLB设备的组网中，一旦该设备发生故障，客户端将无法继续访问实服务器，业务将因单点故障而中断。通过部署高可靠性组网，可以有效消除单点故障，保证业务的连续性。
SLB的高可靠性机制通常支持以下几种工作模式：主备模式、双主模式和集群模式。
如下图所示，主备模式由两台SLB设备在一个内网（或数据中心）中组建成双机热备环境。正常情况下，仅由主设备处理业务流量，备设备处于待命状态。
当主设备的接口、链路或整机故障时，备设备会立即接替主设备处理业务，从而保证业务不中断。
如下图所示，双主模式由两台SLB设备在一个内网（或数据中心）中组建成双机热备环境。与主备模式不同，双主模式下两台设备同时处理业务，各自承担部分业务流量，既实现冗余备份，又充分利用设备资源，从而提高系统整体负载能力。
当其中一台设备发生故障或检测到关键链路异常时，另一台设备会立即接管其承载的业务，保证业务不中断。
集群模式由多台SLB设备组建成一个统一的可靠性系统，对外作为一个逻辑整体提供服务。根据业务部署范围不同，集群既可以在同一内网/同一数据中心内部构建，支撑单数据中心的多业务场景；也可以跨内网/跨数据中心构建，支撑多活数据中心场景。
在集群模式下，多台SLB设备不仅可以形成主备或双主组网，还可以形成多主组网，进一步提高了系统的处理能力和扩容能力。
如图10所示，在同一数据中心多业务集群模式组网中，正常情况下，数据中心的不同SLB设备可以对外发布不同的业务，这样每台SLB设备可以集中高效地处理某一种业务，同时SLB设备之间又可以相互备份配置信息和业务信息。
如图11所示，当其中一台SLB设备故障时，其他设备可以立即接手这些流量，保证用户业务不中断。
如图12所示，在多活数据中心集群模式组网中，正常情况下，多个数据中心同时对外提供服务，充分利用现有的网络资源和应用服务资源等，不同数据中心SLB设备之间的配置信息和业务信息可以相互备份。
如图13所示，当其中一个数据中心的某台SLB设备故障不能对外提供服务时，首先让同一数据中心的其他SLB设备立即接手这些流量，保证用户业务不中断；同理，当整个数据中心故障不能对外提供服务时，再由其他数据中心的SLB设备立即接手这些流量，保证用户业务不中断。
在企业或数据中心等场景中，常常会部署多条上行链路接入多个ISP（Internet Service Provider，互联网服务提供商），以满足扩展出口带宽和提升网络可靠性的需求。
然而，多链路环境也会带来一些挑战，例如，链路利用率可能严重不均衡，部分链路长期处于拥塞状态，而其他链路则相对闲置；仅依靠路由策略引导出方向流量的方式缺乏足够的灵活性，难以根据业务类型、目的地址或链路运行状况灵活调整出口路径；同时，由于缺乏链路健康检查与自动切换机制，当某条链路发生故障时，业务流量仍可能继续转发至故障链路，从而造成访问中断，直接影响用户体验。
出链路负载均衡技术可以将内网用户访问互联网的流量智能分配到多条出口链路上，从而提高链路资源利用率并优化用户访问体验。
完成相关配置后，设备会根据内网用户流量特征，结合链路健康状况、会话保持方法和调度算法等，将不同业务流量合理分配到各条出口链路上。
如下图所示，根据管理员的配置，LB设备可将带宽较大的链路优先用于承载视频等大流量业务，将带宽较小的链路用于承载其他业务。当某条链路发生拥塞或故障时，流量会自动切换到其他可用链路。通过这种智能调度机制，既避免了出链路间的流量分配不均，又提升了整体转发效率和网络响应速度。
图14 出链路负载均衡简介图
在出链路负载均衡技术中，涉及以下关键概念：
· 虚服务器（Virtual Server）：设备上面向用户业务的虚拟出口，出链路负载均衡的虚服务器为LINK-IP类型，由IP地址和端口唯一标识。内网用户的访问请求首先到达LINK-IP类型的虚服务器，只有匹配上虚服务器的报文才会进行出链路负载均衡处理。VSIP（Virtual Server's IP）为虚服务器的IP地址，即为内网用户发送报文的目的地址。
· 链路（Link）：运营商提供的物理链路。
· 链路组（Link group）：由若干条链路组成的集合。设备根据预先配置的调度算法，在链路组内的多条链路之间调度流量，实现出口流量的负载分担。
出链路负载均衡的工作流程如下图所示。
出链路负载均衡工作流程简述如下。
(1) 负载均衡设备接收来自内网用户的流量。
(2) 负载均衡设备依次根据负载均衡策略、会话保持方法、就近性算法、调度算法（通常使用带宽算法或最大带宽算法）来选择最佳链路。
(3) 负载均衡设备通过选定的最佳链路将流量转发给外网服务器。
(4) 负载均衡设备接收来自外网服务器的应答流量。
(5) 负载均衡设备将流量转发给内网用户。
从上述工作流程可以看出，出链路负载均衡的核心在于：当LB设备转发用户访问外部网络的流量时，如何选择由哪条出口链路来承载该流量。
当LB设备收到与某虚服务器（LINK-IP类型）匹配的报文时，会对该报文发起出链路负载均衡调度。此时，出口链路的选择有两种方式：
对于匹配虚服务器的流量，LB设备会查找并调用该虚服务器关联的负载均衡策略。设备会根据预先配置的负载均衡类对请求报文进行匹配，对于命中负载均衡类的报文，执行与之关联的负载均衡动作。例如：将报文转发到指定的出口链路组。在选定的链路组中，依据预先配置的调度算法，从组内多条出口链路中选出一条作为实际转发链路。
相关概念说明如下：
· 负载均衡类（LB class）：对进入设备的报文进行分类的规则，用于将不同类型的报文划分到不同的负载均衡类，便于后续执行差异化的负载均衡动作。
· 负载均衡动作（LB action）：针对被分类报文所执行的具体处理行为，如转发到指定出口链路组。
· 负载均衡策略（LB policy）：将“负载均衡类”和“负载均衡动作”进行关联后形成的策略集合。虚服务器通过引用相应的负载均衡策略，实现对请求报文的精细化控制。
图16 设备上的业务处理流程图（经负载均衡策略转发）
服务器负载均衡也可以不使用负载均衡策略，而是将虚服务器直接关联到某个出口链路组。
在这种方式下，虚服务器接收到出向流量后，设备直接依据该出口链路组中配置的调度算法，从组内多条出口链路中选出一条作为实际转发链路。
在实际调度过程中，出口链路的选择不仅受上述两种方式影响，还会综合考虑链路健康检查结果、会话保持、带宽管理等因素，对候选出口链路进行过滤，从而得到最优的目标出口链路。
DNS透明代理主要应用在拥有多条ISP出口链路的网络中。内网用户可以通过不同的ISP链路，访问提供相同服务的外网服务器。
如下图所示，企业内网用户可以通过运营商ISP 1的链路Link 1和ISP 2的链路Link 2分别访问提供相同网络服务的外网服务器External server A和External server B。企业内网用户通过域名访问外网服务器时，内网用户的所有DNS请求报文会发往同一DNS服务器。DNS服务器收到DNS请求报文后，将其解析为同一运营商网络内外网服务器的IP地址，这将使内网用户的所有流量都通过一条链路转发，导致一条链路拥塞，而其他链路闲置。
图17 DNS透明代理简介图
DNS透明代理技术可以用来解决由于客户端的DNS服务器地址配置不均导致的流量分配不均的问题。
通过DNS透明代理功能可以使DNS请求报文发往不同运营商网络内的DNS服务器，从而使内网用户访问外网服务器的流量较为均匀地分配到多条链路上，提高流量转发效率，提升服务质量；可以避免出现一条链路拥塞而其他链路闲置的情况；也可以在某条链路出现故障时，使用其他链路来访问外网服务器，避免因链路故障导致访问失败。
DNS透明代理通过动态改写DNS请求的目的IP地址，将DNS查询请求分发到不同的DNS服务器，使解析结果指向对应链路的外网服务器IP地址，从而控制业务流量的转发链路。具体工作流程如下图所示。
图18 DNS透明代理工作流程图
DNS透明代理工作流程简述如下（图中仅包含步骤（1）-（6））：
(1) Host向LB device发送DNS请求报文。此时，DNS请求报文的目的IP地址为DNS服务器A的IP地址。
(2) LB device收到DNS请求报文后，根据调度算法选出最佳链路对应的DNS服务器，选中DNS服务器B。
(3) LB device将DNS请求报文的目的IP地址修改为选定的DNS服务器的IP地址，即修改为DNS服务器B的IP地址。
(4) DNS服务器接收并处理DNS请求报文，返回DNS应答报文。此时，DNS应答报文的源IP地址为DNS服务器B的IP地址。
(5) LB device收到DNS应答报文后，将其源IP地址修改为DNS请求报文中的目的IP地址，即修改为DNS服务器A的IP地址。
(6) 将DNS应答报文转发给Host。此时，DNS应答报文的源IP地址为DNS服务器A的IP地址。
(7) 内网用户根据DNS应答报文中的IP地址访问外网服务器，即Web服务器B。
(8) 外网服务器应答内网用户。
从上述工作流程可以看出，DNS透明代理通过修改DNS请求报文的目的地址，实现对多条链路上的访问流量进行控制，从而为内网用户访问外网服务器选择最优链路。在设备上，DNS透明代理业务流程涉及以下关键概念：
· DNS透明代理（Transparent DNS proxy）：设备上面向用户业务的虚拟载体。只有当DNS请求报文的IP地址和目的端口号与DNS透明代理配置的IP地址与端口号匹配时，LB设备才会对该报文执行DNS透明代理处理。
· 链路（Link）：运营商提供的实体链路，用于承载用户访问外网的业务流量。
· DNS服务器（DNS server）：负责解析用户DNS请求并返回解析结果的实体。
· DNS服务器池（DNS server pool）：DNS服务器的集合。设备根据预先配置的调度算法，在DNS服务器池内调度流量，实现出口流量的负载分担。
· 负载均衡类（LB class）：对进入设备的报文进行分类的规则，用于将不同类型的报文划分到不同的负载均衡类，便于后续执行差异化的负载均衡动作。
· 负载均衡动作（LB action）：针对被分类报文所执行的具体处理行为，如转发到指定DNS服务器池。
· 负载均衡策略（LB policy）：将“负载均衡类”和“负载均衡动作”进行关联后形成的策略集合。DNS透明代理通过引用相应的负载均衡策略，实现对DNS请求报文的精细化控制。
图19 设备上的调度流程图（经负载均衡策略转发）
当LB设备收到与DNS透明代理匹配的DNS请求报文时，LB设备会对该报文执行DNS透明代理处理。设备上的流量调度可有两种方式：
LB设备查找并调用DNS透明代理关联的负载均衡策略。设备会根据预先配置的负载均衡类对请求报文进行匹配，对于命中负载均衡类的报文，执行与之关联的负载均衡动作，通常为将报文转发到指定的DNS服务器池。在选定的DNS服务器池中，依据预先配置的调度算法，选出与最优链路对应的DNS服务器。LB设备将DNS请求报文发送给选定的DNS服务器，由其解析域名并返回DNS应答报文。
DNS透明代理也可以不使用负载均衡策略，而是将DNS透明代理直接关联到某个DNS服务器池。
在这种方式下，DNS透明代理收到DNS请求后，设备直接根据DNS服务器池中配置的调度算法，从池中选择合适的DNS服务器。LB设备将DNS请求报文发送给选定的DNS服务器，由其解析域名并返回DNS应答报文。
无论采用哪条路径，内网用户在收到DNS应答报文后，即可根据应答中的外网服务器IP地址发起访问。
在实际调度过程中，DNS服务器的选择不仅受上述方式影响，还会综合考虑健康检查结果、会话保持、带宽管理等因素，对候选DNS服务器和链路进行过滤，从而得到最优链路对应的DNS服务器。
入方向链路负载均衡主要应用于拥有多条ISP入口链路的企业网络，通过智能调度，使外网用户能够经由不同的链路访问企业服务，从而提高访问的效率与可靠性。
如下图所示，企业分别租用不同运营商ISP 1、ISP 2和ISP 3的三条链路Link 1、Link 2和Link 3为外网用户提供服务。
通过配置入方向链路负载均衡，可以使外部互联网用户访问内网服务器的流量均匀地分配到多条链路上，从而提高流量转发效率，提升服务质量；可以避免出现一条链路拥塞而其他链路闲置的情况；可以在某条链路出现故障时，使互联网用户使用其它链路来访问内网服务器，避免因链路故障导致流量转发失败。
图20 入方向链路负载均衡原理图
入方向链路负载均衡技术又叫本地智能DNS解析技术，是基于DNS解析实现的。LB设备作为权威DNS服务器，对外网用户访问内网服务器的DNS请求报文进行智能解析，为外网用户选择最佳入方向链路。具体工作流程如下图所示。
入方向链路负载均衡工作流程简述如下：
(2) Host向Local DNS服务器发起DNS请求（若请求域名为example_a）。
(3) Local DNS服务器向指定域名（example_a）的权威DNS服务器LB device发起DNS请求。
(4) LB device根据调度算法、健康检测结果、带宽限制策略等来选择最佳入方向链路。
(5) LB device将选定入方向链路对应的虚服务器IP地址通过DNS响应报文发送给发起请求的Local DNS服务器。管理员可为每条入方向链路绑定其对应的虚服务器。
(6) Local DNS服务器把获取的虚服务器IP地址发送给Host。此步骤即完成了将Host请求域名（example_a）智能解析为指定IP地址（最优入链路对应的虚服务器IP地址）。
(7) Host向虚服务器IP地址发起访问请求（请求通过选定入链路进入LB device）。
(8) LB device向内网服务器发起访问请求。
(9) 内网服务器发送响应至LB device。
(10) LB device发送响应至Host。
在入方向负载均衡工作流程中，LB设备承担指定域名的权威DNS解析职责。因此，管理员需要联系运营商，在Local DNS中将该域名的权威解析服务器配置为 LB设备的地址，以确保DNS请求能够由LB设备处理。
从上述工作流程可见，入方向链路负载均衡是通过智能DNS解析实现的。
核心机制是：当设备接收到访问特定域名的DNS请求报文后，通过智能解析选择最优入链路，并返回该链路对应的虚服务器IP地址，从而引导用户流量进入最佳链路。
要实现这一过程，使设备具备智能DNS解析能力，我们需引入以下关键概念：
· DNS监听器（DNS listener）：用于监听DNS请求。只有当DNS请求的目的地址与DNS监听器的IP地址匹配时，该DNS请求报文才会进入入方向链路负载均衡处理流程。
· DNS映射（DNS mapping）：用于关联域名与虚服务器池。设备通过DNS映射查找域名对应的虚服务器池。
· 虚服务器池（Virtual server pool）：用于在虚服务器池下关联虚服务器与链路。链路和虚服务器的可用性共同决定链路是否可参与调度。
· 链路（Link）：运营商提供的实体链路。
· 虚服务器：面向用户业务的虚拟载体，需与链路绑定，通过在智能DNS解析过程中返回虚服务器IP地址，从而引导用户流量通过指定链路进入网络。如果用户网络同时部署了服务器负载均衡与入链路负载均衡，则虚服务器IP地址既是入链路负载均衡的DNS解析结果，也是服务器负载均衡的入口地址。
设备上的入方向链路负载均衡业务处理流程如下图所示。
当设备收到了目的地址匹配DNS监听地址的DNS请求报文时，首先在DNS映射中查找域名所关联的虚服务器池。设备依据虚服务器池中配置的调度算法选出最佳链路所对应的虚服务器IP地址，将选定的虚服务器IP地址通过DNS应答报文发送给用户，用户得到虚服务器IP地址后将其作为目的地址，通过该虚服务器关联的链路访问内网服务器。
全局负载均衡（GSLB）技术主要应用于多数据中心场景，可在多个数据中心之间对用户访问流量进行智能调度，引导用户接入最优的数据中心，从而提升访问体验。同时，GSLB还能实现跨数据中心的远程灾备。当某个数据中心发生故障时，GSLB可将流量平滑切换至其他数据中心，确保业务流量不中断。
图23 全局负载均衡简介图
GSLB技术又叫全局智能DNS解析技术，是基于DNS解析技术实现的。主要解决普通DNS服务器在流量分配与故障感知方面的不足。
· 普通DNS服务器通常采用简单的轮询方式分配流量，无法根据用户的地理位置、运营商线路或实时网络状况动态调整解析结果，例如，来自地区A、运营商ISP1的用户请求，可能被解析到地区B、运营商ISP2的服务地址，导致跨地区、跨运营商访问，增加网络时延，进而影响用户体验。
· 普通DNS服务器缺乏健康检查和故障感知机制，无法在后端服务器或数据中心发生故障时自动排除异常节点。当某数据中心发生故障时，普通DNS仍可能将域名解析结果指向该故障节点，导致用户访问失败，严重影响业务可用性。
在GSLB架构中，设备充当智能DNS服务器，对接收到的DNS请求进行智能解析。GSLB设备根据预先配置的调度算法，对各数据中心中承载同一业务的链路进行全局评估，择优选取最适合当前用户访问的链路，并将该链路对应的虚服务器IP地址作为解析结果返回给用户，从而实现跨地域的访问加速与优化。
同时，GSLB设备还通过健康检测机制持续监控各数据中心的链路状况和设备状态。一旦发现某条链路或某个服务节点发生故障，即刻将其从调度池中剔除，确保用户访问始终被引导至可用、健康的服务节点。
在实际应用中，全局负载均衡通常与服务器负载均衡协同工作。全局负载均衡负责在多个数据中心之间进行全局调度，选择最优数据中心及其最佳入口链路；服务器负载均衡则在选定的数据中心内部进行本地调度，从实服务组中选择最优的实服务器。
GSLB设备和本地SLB设备支持集中部署和分布部署两种部署模式，根据实际需求灵活选择。
在GSLB设备上同时配置全局负载均衡和服务器负载均衡功能。该设备既提供全局负载均衡服务，又提供服务器负载均衡服务。
图24 集中部署模式组网图
在不同设备上分别配置全局负载均衡和服务器负载均衡功能。由GSLB设备提供全局负载均衡服务，本地SLB设备提供服务器负载均衡服务。
图25 分布部署模式组网图
如下图所示，以分布部署模式为例，说明全局负载均衡的典型工作流程。集中部署模式工作流程基本类似，此处不再赘述。
图26 全局负载均衡工作流程图（分布部署）
全局负载均衡工作流程简述如下：
(1) Host向Local DNS发送DNS请求。
(2) Local DNS根据运营商DNS的配置，将DNS请求转发至某一数据中心的GSLB设备，本例为数据中心B的GSLB设备。
(3) GSLB设备收到DNS请求后，根据预先配置的调度算法进行智能解析。假定其为Host选择了与其相同运营商的链路Link_A1接入数据中心A，并将解析结果确定为与链路Link_A1绑定的虚服务器地址VSIP_A1。
(4) GSLB设备将解析结果VSIP_A1返回给Local DNS。
(5) Local DNS将解析结果VSIP_A1返回给Host。
(6) Host根据智能DNS解析结果，向VSIP_A1对应的虚服务器发起访问请求，进入服务器负载均衡工作流程。
(7) 数据中心A的SLB A设备接收到请求报文后，根据服务器负载均衡配置，选择一台最优的实服务器响应用户请求。
(8) SLB A设备将用户请求转发给选定的实服务器。
(9) 实服务器处理完成后，将响应报文返回给SLB A设备。
(10) SLB A设备再将响应报文发送回Host。
在全局负载均衡工作流程中，GSLB设备作为指定域名的权威DNS服务器。因此，管理员需要联系运营商，在该域名的权威DNS服务器设置中，将权威DNS服务器地址配置为GSLB设备的地址，以确保针对该域名的DNS查询都由GSLB设备进行解析与调度。
从上述工作流程可见，全局负载均衡是通过智能DNS解析实现的。
其核心机制是：当设备接收到访问特定域名的DNS请求报文后，通过智能解析选出最优数据中心的最优链路，并返回该链路对应的虚服务器IP地址，从而将用户流量引导至最佳入口。
要实现这一过程，使设备具备智能DNS解析能力，我们需引入以下关键概念：
· 全局DNS监听器（Global DNS listener）：用于监听DNS请求。当DNS请求报文的目的IP地址与全局DNS监听器的地址匹配时，该DNS请求报文才会进入全局负载均衡处理流程。
· 全局DNS映射（Global DNS mapping）：用于将域名与全局虚服务器池关联。GSLB设备通过全局DNS映射，将域名映射到指定的全局虚服务器池，并根据调度算法先选出最优的全局虚服务器池。
· 全局虚服务器池（Global virtual server pool）：即虚服务器的集合，在全局虚服务器池下，将虚服务器与链路进行关联。链路和虚服务器的可用性共同决定链路是否参与调度。
· 链路（Link）：运营商提供的实体链路，用于承载业务流量。
· 虚服务器：面向用户业务的虚拟载体，需要与链路绑定，在智能DNS解析过程中，设备通过返回虚服务器IP地址，引导用户流量通过指定链路进入数据中心。虚服务器本质上是各数据中心内SLB设备的虚服务器。通过在同一全局虚服务器池中，对来自不同数据中心、不同SLB设备的虚服务器进行统一调度，GSLB能在多个数据中心之间实现跨站点的最优选择。
设备上的全局负载均衡业务处理流程如下图所示。
图27 设备上的业务处理流程图
当GSLB设备收到目的地址匹配全局DNS监听地址的DNS请求报文时，首先根据全局DNS映射中配置的调度算法，选择一个合适的全局虚服务器池。再根据全局虚服务器池中配置的调度算法，从池中选出最合适的虚服务器。将选定虚服务器的IP地址封装在DNS应答报文中返回给用户。用户在收到解析结果后，将该虚服务器IP地址作为目的地址，通过该虚服务器绑定的链路，访问内网服务器，实现从最优链路进入最优数据中心。
在全局负载均衡环境中，配置信息和运行数据的一致性对保障服务的高可靠性和高效率至关重要。通过建立同步组，GSLB设备之间可以相互同步以下信息：
同步配置信息：当管理员在某一台GSLB设备上修改配置时，这些变更会自动同步到同步组内的其他GSLB设备。配置信息同步确保各GSLB设备配置一致，降低了人工配置的错误风险，并显著简化运维管理。
同步运行数据：运行数据的同步是系统做出正确负载均衡决策的关键。例如，当服务器或链路的健康状态在GSLB设备之间同步后，任意一台GSLB设备检测到服务器或链路故障，都会将该信息快速通知给其他GSLB设备，从而使它们能够及时将流量重定向到其他健康的服务器或链路，保障业务连续性。
调度算法是负载均衡技术的核心机制之一，用于按照预先设定的规则，将用户请求在多个可用资源之间进行合理分配。其作用对象是一组候选资源，如多台实服务器、多条链路或多台DNS服务器等，每当有新的用户请求到来时，调度算法会根据当前资源的处理能力、网络的运行状况或请求流量的特征等因素，从资源池中选择合适的目标节点进行处理。从而在保障业务稳定性的前提下，实现资源利用最大化和用户访问体验优化。
在不同类型的负载均衡技术中，调度算法的核心目标是一致的：从一个“资源池”中，依据特定策略选出一个“目标节点”。“资源池”与“目标节点”在不同的负载均衡类型中有不同的含义。对应关系如下表所示：
表1 不同负载均衡类型的资源池与目标节点对应关系表
负载均衡类型 | 资源池 | 目标节点 | 调度目标 |
服务器负载均衡 | 实服务器组 | 一台实服务器 | 将用户请求分发至最合适的实服务器 |
出链路负载均衡 | 链路组 | 一条出站链路 | 为内部访问外部的流量选择最佳出口 |
DNS透明代理 | DNS服务器池 | 一台DNS服务器 | 将DNS查询请求导向与最优链路对应的DNS服务器 |
入链路负载均衡 | 入站虚服务器池 | 一个虚服务器（通常关联一条入站链路） | 为外部用户访问内部服务器的入口流量选择最佳入口 |
全局负载均衡 | 第一级调度：全局DNS映射 第二级调度：所选全局虚服务器池 | 第一级调度：一个全局虚服务器池 第二级：该池中的一台虚服务器 | 实现跨地域、跨数据中心的两级智能调度，为用户流量选出最优数据中心的最优入口链路 |
为便于统一阐述，后文在描述各类调度算法时，将使用通用术语“资源池”指代各类逻辑资源集合（如实服务器组、链路组、DNS服务器池或虚服务器池等），使用“目标节点”指代经调度算法选出的承载业务的实体（如某台实服务器、某条链路、某台DNS服务器或某个虚服务器等）。
在不同业务场景中，流量调度的关注重点有所差异。有的强调连接数与处理能力，有的侧重带宽与流量分布，有的更看重会话一致性或就近访问。因此，围绕不同决策依据形成了多种调度算法。
本白皮书将调度算法划分为基于静态规则的调度算法和动态与状态感知调度算法，下面分别展开说明。
此类算法基于简单、确定的规则进行调度，不依赖对业务系统实时负载或性能状态的感知。
它们实现复杂度低、运行开销小、调度行为稳定且可预测，适合作为基础调度策略，适用于环境相对稳定或业务对实时负载自适应性要求不高的场景。
但这类算法无法根据节点的实时负载和性能波动等动态因素调整分配结果，需要依赖合理的权值配置、哈希字段选择及前期资源容量规划，来尽量实现流量的相对均衡分配。
随机算法通过随机选择的方式，将每个新的请求分配给资源池中的任意一个可用节点。
在请求量足够大的前提下，各节点被选中的概率基本相同，其承载的连接数在统计意义上趋于均衡。
当资源池中的所有节点（如实服务器、链路、DNS服务器等）在处理能力、网络带宽、硬件配置和软件性能等方面大体一致，且整体运行状态长期稳定时，随机算法能够提供一种简单、近似公平的分配机制。该算法隐含的前提假设是：任一节点处理任一请求的成本与效果基本相同，即不存在明显的性能差异和负载波动。
随机算法无需维护复杂状态信息，也不需要额外监控节点负载或计算权重，调度逻辑简单、实现成本和运行开销都较低。但它无法结合当前连接数、CPU/内存占用或链路利用率等动态指标进行自适应调整，当各节点性能不均衡时，可能导致流量分布不够合理。
因此，随机算法更适用于规模较小、各节点性能较为均衡的场景，或作为一种通用的缺省调度策略使用。
在服务器负载均衡、出链路负载均衡、DNS透明代理、入链路负载均衡以及全局负载均衡技术中，均可采用随机算法从资源池中选取目标节点。
加权轮转算法是一种基于静态权重的调度算法。管理员需为资源池中的每个节点预先配置权值，用于表示节点的相对处理能力或期望其承担的流量占比。调度时，负载均衡设备按照配置的权值比例，将新请求依次分配给各节点：权值越大，被分配的请求越多。
图28 加权轮转算法流量调度示意图
加权轮转算法适用于资源池中各节点之间存在已知且相对稳定的性能差异的场景，例如：内存配置不同的服务器、带宽大小不同的链路等。同时要求单个请求的资源消耗大致均衡，即不同请求在带宽、处理时长等方面的差异不大。
在上述前提下，按权值比例分配请求数量，可以在统计意义上接近按处理能力分配流量的效果。既能充分利用高性能节点的资源，同时避免低性能节点过载。
加权轮转算法能体现节点性能的差异，使高性能节点承担更多请求。仅依赖预配置权值即可完成调度，无需实时采集节点性能或进行复杂计算，实现简单、开销较小。但权值通常需要人工配置和维护，若实际性能或带宽发生变化而权值未及时调整，可能导致分配不合理。当不同请求在资源消耗上差异较大时，即便请求数量满足权值比例，实际负载也无法做到真正均衡。
在服务器负载均衡、出链路负载均衡、DNS透明代理、入链路负载均衡以及全局负载均衡技术中，均可采用加权轮转算法从资源池中选取目标节点。
哈希算法是一种基于报文字段进行静态映射的调度算法。它从请求报文中选取一个或多个关键字段（如源IP地址、目的IP、端口或者HTTP载荷），将这些字段作为输入通过哈希函数计算出哈希值，再根据该哈希值将请求调度到资源池中的某个节点。
由于哈希函数对相同输入总会产生相同的输出，只要报文字段的取值不变，其哈希值就保持不变。这样一来，关键字段取值相同的报文就会被持续调度到同一个节点，从而实现流量的稳定分配。
图29 哈希算法流量调度示意图（以源IP地址哈希算法为例）
哈希算法无需维护复杂的会话表，就能在指定维度上实现会话一致性。实现方式相对简单，调度决策仅依赖固定字段和哈希函数，运行时开销较低。
但其局限也较为明显：负载均衡效果高度依赖哈希字段的选择及请求的实际分布，当基于特定哈希字段的请求流量分布不均时，容易导致部分节点过载；同时，哈希算法对节点的实时状态不敏感，无法主动规避已处于高负载状态的节点。
在服务器负载均衡、出链路负载均衡、DNS透明代理以及入链路负载均衡技术中，均可采用哈希算法从资源池中选取目标节点。
根据参与哈希计算的报文字段不同，哈希算法分为：
将报文的源IP地址作为哈希输入，同一源IP的请求会被调度到同一目标节点。适用于需要确保同一客户端的访问始终调度到同一目标节点的场景。
源IP地址哈希算法提供基于源IP地址的会话一致性，便于保持会话状态。但是在少数源IP地址产生大量请求的情况下，容易导致流量集中到个别节点；同时，在大规模NAT或代理场景下，多个真实客户端共享同一源IP地址，会进一步加剧负载不均衡问题。
将报文的“源IP地址+源端口”组合作为哈希输入，同一“源IP地址+源端口”组合的请求会被调度到同一目标节点。适用于需要区分不同连接、确保同一客户端在同一端口上的访问始终调度到同一目标节点的场景。
相较于源IP地址哈希算法，源IP地址+端口哈希算法粒度更细，能够在一定程度上缓解因源IP相同而导致的流量集中问题。但在某些客户端源端口频繁变化的场景下，同一用户的多次访问可能被分配到不同节点，不利于依赖长生命周期会话状态的业务。
将报文的目的IP地址作为哈希输入，将发往同一目的IP的请求调度到同一目标节点。适用于客户端需要频繁访问某一逻辑地址（如，虚服务器地址），并期望其流量稳定调度到同一目标节点的场景，尤其适合需要与单一节点保持稳定通信的业务。
该算法能够保证发送到相同目的IP地址的流量由固定节点处理。但当某个目的IP地址所承载的业务流量显著高于其他IP地址时，容易导致该节点负载过高，从而造成整体负载不均衡。因此，目的IP地址哈希多用于特定网络或链路的调度场景。
在七层服务器负载均衡场景下，从HTTP请求报文中提取特定应用层字段（如URL、Host、Cookie、Header等），对该字段进行哈希，将具有相同特征字段的请求调度到同一目标节点。适用于需要基于HTTP七层报文内容进行调度的场景，如按用户ID、租户标识、URL路径等进行精细化流量分配。
HTTP载荷哈希算法能够根据报文的应用层载荷进行调度，粒度更细，业务感知能力强。但是，该算法对七层报文解析和字段提取有依赖，处理开销相对IP地址哈希算法较大。若选取的调度字段分布不均衡（如某些用户的流量高于其他用户），仍可能导致流量分配不均衡。
仅七层服务器负载均衡技术可采用HTTP载荷哈希算法从资源池中选取目标节点。
当资源池中的节点发生变化（新增或删除节点）时，普通哈希算法会导致大量请求的调度结果发生变化，严重影响会话稳定性。为减小这种变更带来的影响，可以采用CARP（Cache Array Routing Protocol，缓存阵列路由协议）哈希算法。
CARP哈希算法在普通哈希算法的基础上进行了改进：在实服务器故障和实服务组扩容时，相比普通哈希算法，能使当前所有可用实服务器的调度结果变动最小，更好地保持流量调度的持续性。
当某台实服务器因故障无法提供服务时：
· 采用普通IP地址哈希算法时，原本发往未故障实服务器的请求也会被重新调度，根据源IP地址、源IP地址+端口或目的IP地址在实服务组内所有实服务器间进行重新调度。导致几乎所有访问流量重分布，用户会话大面积中断，影响用户体验。
· 采用CARP IP地址哈希算法时，原本发往未故障实服务器的请求仍继续被分配到原实服务器，仅原本发往故障实服务器的那部分流量会被重新分配到其余可用服务器上，对整体访问体验影响最小。
当在现有实服务组中新增实服务器时：
· 采用普通IP地址哈希算法时，将根据源IP地址、源IP地址+端口或目的IP地址，将所有请求在所有实服务器之间重新分配，包括新增实服务器和已有实服务器。所有访问流量均需要重新分配，用户会话大面积中断，影响用户体验。
· 采用CARP IP地址哈希算法时，仅有一部分调度至原有实服务器的请求，会被迁移至新增实服务器；大部分请求仍保持原有调度结果，从而在引入新节点的同时，最大程度保持会话连续性和访问体验。
仅服务器负载均衡技术支持CARP哈希算法。
静态就近性算法是一种基于预先配置映射关系的调度算法。它根据客户端IP地址所属的地理区域或网络位置，将请求调度到预定义的就近节点，所有调度决策完全依赖管理员预先配置的映射规则。
该算法可将某一地区的用户请求优先调度到就近区域的节点，也可将某一运营商的用户请求优先调度到同运营商的节点。该算法调度规则固定、行为可预测，有助于降低跨地域或跨运营商访问带来的时延和带宽消耗；实现复杂度较低，无需实时网络质量探测或复杂计算。
但该算法完全依赖管理员维护的拓扑信息。当网络路由、运营商策略或IP归属发生变化时，需要及时更新映射配置；同时由于不感知实时网络质量，在网络状态波动较大时，实际最优访问路径未必与预设的就近路径一致。
该算法仅应用于入链路负载均衡和全局负载均衡场景，通常用于跨地域、多运营商环境下，作为一种基于策略的就近访问控制手段。在不引入复杂实时探测机制的前提下，尽可能将用户调度至拓扑结构上预期的最近目标节点。
首个可用算法是一种基于固定优先级的静态调度算法。设备会先从资源池中选出一个目标节点，只要该节点可用，所有请求流量始终分发到这一节点上，只有当其不可用时，才切换到下一个优先级节点。
该算法仅用于全局负载均衡的第二级调度，即：在某个全局虚服务器池内选择虚服务器。首次调度时，优先选择优先级最高（即权值最大）的虚服务器；若存在多个权值相同且最大的虚服务器，则在其中随机选出一个。此后，所有DNS请求都会持续解析为该虚服务器的IP地址。
首个可用算法访问路径稳定，行为可预测。在高优先级节点可用时，所有请求固定调度至同一节点，便于简化故障定位和容量规划。但在首选节点可用期间，其他节点几乎不承担流量，仅在首选节点故障或下线时才接管流量，无法实现多节点并行负载分担。因此，需要配合可靠的健康检测机制，及时发现首选节点故障并进行流量切换，以避免业务长时间中断。
动态与状态感知调度算法在进行调度决策时，会主动感知业务节点或网络的实时状态，并据此动态调整流量分配。这类算法通常通过探测各节点的实时能力或网络质量，将更多流量分配给表现更优的节点，从而实现更精细的调度。
相较于基于静态规则的算法，这类算法能够随节点负载、性能和网络质量的变化自动调整调度结果，更好地利用系统资源，避免节点过载，提升整体响应速度与稳定性，特别适用于跨链路、跨地域、多运营商等复杂环境。但这类算法实现与配置更为复杂，依赖报文探测和权值计算机制，会引入一定的探测和计算开销，调度结果也可能随网络波动而变化。因此，动态与状态感知调度算法通常用于对性能和体验要求较高、网络和负载波动明显的场景，多与基于静态规则的调度算法结合使用。
加权最小连接算法是一种基于实时连接数的动态调度算法。
管理员为每个参与调度的节点配置权值，表示其相对处理能力或期望承担的负载比例。权值越大，表示该节点越适合多分担流量。在实际调度时，设备为每个节点计算加权活动连接数（加权活动连接数=当前活动连接数/权值），始终将新请求分配给加权活动连接数最小的节点。在当前活动连接数相同的情况下，权值越大越容易获得新的请求；在权值相同的情况下，当前活动连接数越少越容易被选中。
图30 加权最小连接算法流量调度示意图（假设已有连接均未断开）
在业务负载差异大、长短连接并存的场景中，简单按请求数量分配（如加权轮转算法）难以准确反映实际负载。而加权最小连接算法通过同时考虑当前负载（活动连接数）和节点能力（权值），实现更符合节点能力差异的动态负载分配。该算法只需维护每个节点的活动连接数，无需监控CPU、内存等细粒度指标，适合作为动态调度的基础选择。
该算法更适用于具有明确连接/会话的四层或部分七层业务；对完全无连接的业务，可结合请求统计或其他指标一并使用。
服务器负载均衡、出链路负载均衡和入链路负载均衡技术可采用加权最小连接算法从资源池中选取目标节点。
动态反馈算法是一种基于节点资源利用率的状态感知调度算法。仅用于服务器负载均衡。
动态反馈算法依赖SNMP-DCA类型的NQA探测模板定期采集实服务器的CPU、内存、磁盘等资源使用率，并据此计算出每台实服务器的负载能力权值。资源使用率越低，表示负载越小，负载能力权值越大，可分配的新连接越多；资源使用率越高，越接近饱和，负载能力权值越小，分配的新连接相应较少。
图31 动态反馈算法流量调度示意图
若未配置SNMP-DCA类型的NQA探测模板，设备无法获取实服务器的实时资源使用情况，动态反馈算法不生效，系统采用非加权的轮转算法进行调度。
动态反馈算法适用于以下场景：实服务器性能差异明显，单条业务流的负载强度和处理时长无明显规律，难以通过连接数或请求数估算负载，并且希望能够根据CPU、内存、磁盘等资源使用率的变化实时自适应调整调度策略。
相比基于连接数或固定权值的算法，动态反馈算法通过直接感知资源利用率来调整权值，能及时反映各节点的真实负载水平，且无需依赖人工估算权值，更有利于整体资源利用的均衡。
动态反馈算法在使用时需正确配置SNMP-DCA类型NQA探测模板，并结合业务特性合理设置探测周期和相关参数。
最快响应算法是一种基于服务器实时响应时间的状态感知调度算法。仅用于服务器负载均衡。
该算法通过采集实服务器对业务请求的响应时间来评估当前负载能力，并据此计算权值。响应时间越短，表明节点越空闲，其权值越高，获得的新连接也越多。由于直接以响应时间作为调度依据，该算法对处理时长较长、负载较重的请求变化更为敏感。
图32 最快响应算法流量调度示意图
最快响应算法适用于各实服务器性能相近，但单条流的业务负载较大、处理时间较长，且不同请求之间的响应时延差异能较好反映当前负载情况的场景。
该算法的优势在于可以较好反映用户体验，响应时间是用户直接感知的性能指标，基于此进行调度有利于提升整体响应速度；当某台服务器因处理复杂请求而变慢时，其响应时间会迅速拉长，从而自动减少新连接的分配，实现自适应的负载调节。
需要注意的是，实服务器响应时间依赖探测报文获取。如果探测路径质量波动较大，或探测模板配置不合理，可能导致对实服务器负载状态的误判，从而影响调度效果。
链路质量算法是一种基于链路质量的调度算法。仅用于出链路负载均衡。
该算法综合考虑链路的网络延迟、路由跳数和丢包率，对每条链路计算出一个链路质量值，并据此决定新连接的分配比例。链路质量越好，分配的新连接越多。
图33 链路质量算法流量调度示意图（仅以丢包率示意）
配置该算法时，需要管理员同时配置就近性探测方法，并通过周期性探测获取各条链路到目标网络的关键指标，如：网络延迟、路由跳数或丢包率等。
该算法适用于各条链路带宽大致相近，但路径在时延、稳定性、路径长短等网络质量方面存在明显差异的场景。
链路质量算法能够根据链路质量的实时变化，自动将更多新连接分配到质量更优的链路上，从而提升整体可用性和用户体验。链路质量不佳的链路会被自动降低分配比例，避免影响业务访问质量。
需要注意的是，该算法与就近性探测方法及各探测指标的权值强相关。管理员应结合实际网络状况、业务对时延和稳定性的要求，合理配置各个探测指标的权值。
动态就近性算法通过实时探测网络状态（如网络时延、路由跳数、路径开销等），动态计算出客户端到各节点的“距离”，并将请求调度至当前距离最近的节点。
动态就近性算法主要适用于跨地域、多运营商、多链路的复杂网络环境中，特别适合对访问时延和稳定性要求较高且网络质量波动明显的场景。通过持续探测网络状况，该算法可以为客户端选择在当前网络拓扑下真正最近的节点，而不仅仅依赖地理位置或静态配置。
在实际应用中，当某个节点的网络质量下降时，会被视为与客户端的距离变远，算法会依据实时探测结果，将客户端请求优先调度到在当前网络拓扑中更近的节点，从而显著提升用户的访问体验。
需要注意的是，该算法对就近性探测方法及各类探测指标的权值配置高度敏感。由于调度结果可能随网络波动而频繁变化，管理员应结合实际网络状况，以及业务对时延和稳定性的要求，合理选择探测方法并配置各项指标的权值。
仅入链路负载均衡和全局负载均衡支持动态就近性算法。
带宽算法是一种基于可用带宽进行调度的算法。设备根据各节点“权值×剩余带宽”的比例来分配请求，乘积越大，获得的流量比例越高，从而使带宽更充裕、权值更高的节点承担更多流量。例如，对于节点A和节点B，若剩余带宽分别为150kbps和250kbps，权值分别为5和6，则两者的流量分配比例为150×5:250×6，即1:2。
图34 带宽算法流量调度示意图
带宽算法适用于对带宽资源高度敏感的场景，例如多出口链路环境、服务器带宽能力差异较大的集群，以及大流量下载、音视频分发等业务。在这些场景中，按节点的可用带宽进行流量分配，更能匹配各节点的实际承载能力。
该算法能够根据剩余带宽动态调整流量分配，避免个别节点因带宽耗尽而过载，使整体带宽利用更加均衡。同时，在大流量场景下可以一定程度上缓解链路拥塞和数据包丢失，从而提升传输质量。
然而，带宽算法主要关注带宽维度，对CPU、内存、连接数等其他资源的压力感知不足，可能出现带宽仍有余量，但节点在计算或连接数方面已接近过载的情况。
服务器负载均衡、出链路负载均衡、DNS透明代理和入链路负载均衡技术均可采用带宽算法在资源池中选取目标节点。
最大带宽算法是一种优先使用剩余带宽最大节点的调度算法。设备总是尽量将新请求分配给当前处于空闲状态且剩余带宽最大的节点，当其可用带宽被用到一定程度后，再将后续流量分散到其他节点。例如，对于节点A和节点B，剩余带宽分别为150kbps和250kbps，两者带宽差值为100kbps：当新请求带来的流量小于100kbps时，全部分配给节点B；当请求流量为130kbps时，其中100kbps分配给节点B，剩余30kbps再平均分配给两个节点。
最大带宽算法适用于多链路或多服务器场景中，希望优先使用带宽更充裕节点的情况。如多出口链路、大流量下载或音视频业务场景中，部分节点带宽明显更高，希望其优先承担主要流量。在这类场景下，最大带宽算法能够快速将大量流量导向带宽能力最强的节点，显著提升主力节点的利用率。
该算法的优势在于策略简单、行为直观。通过优先使用当前空闲带宽更大的节点，可以在较短时间内获得更高的整体吞吐效率。但最大带宽算法的缺点也较为突出：一方面，流量会阶段性集中在少数大带宽节点上，其他节点的利用率偏低，整体资源使用较不均衡；另一方面，该算法只关注带宽维度，未综合考虑CPU、内存、连接数等其他负载指标，可能出现带宽仍有余量，但节点在计算或连接数方面已接近过载的情况。
相比按“权值×剩余带宽”进行比例分配的带宽算法，最大带宽算法更倾向于优先占满带宽最大的节点，更适合以吞吐量优先为目标的场景。
服务器负载均衡、出链路负载均衡、DNS透明代理和入链路负载均衡技术均可采用最大带宽算法在资源池中选取目标节点。
流量观察算法通过持续观察各节点当前及过去一段时间内的连接数情况，统计分析其负载水平，选出当前负载最小的节点，并将新到达的客户端连接优先调度到该节点。
在这一过程中，设备会监控现有连接的流量模式和变化趋势，尽量把新连接导向当前压力较小的节点，以实现更均衡的负载分担。
仅服务器负载均衡可采用流量观察算法在资源池中选取目标节点。
流量预测算法在持续观察各节点当前及一段时间内历史连接数的基础上，进一步分析负载变化趋势，用于判断各节点的性能是在提升还是下降。调度时，会优先将新连接分配给性能排名靠前且当前性能趋势向好的节点。
与仅关注当前负载的流量观察算法不同，流量预测算法不仅看现在，还尝试预测未来，对未来短时间内的流量和负载情况做出预判，从而进行更具前瞻性的调度。
仅服务器负载均衡可采用流量预测算法在资源池中选取目标节点。
健康检测是负载均衡中的关键机制，用于实时感知节点的运行状态和服务可用性。通过对节点进行持续探测，设备可以及时判断各节点是否正常工作：对于探测失败的节点，会将其自动从调度池中剔除，不再分配新的请求，从而避免继续向故障节点转发流量。在后续检测中，如果该节点的探测结果恢复正常，系统会自动将其重新加入调度池，使其再次参与流量分担。
健康检测为负载均衡提供了持续、细粒度的状态感知能力，使系统能够在不依赖人工干预的情况下完成节点的自动剔除与恢复，从而显著提升系统整体可用性与弹性。同时，健康检测结果也是后续节点调度和策略选择等功能的基础数据来源。
在不同类型的负载均衡技术中，健康检测的探测对象各不相同，但目标都是判定相关节点是否可用、性能是否可接受。下表给出了本白皮书涉及的几类负载均衡技术的探测对象。后续章节不再分别区分这些技术类型，而是将探测对象统称为节点。
表2 健康检测探测对象表
负载均衡技术 | 健康检测探测对象 |
服务器负载均衡 | 实服务器 |
出链路负载均衡 | 出口链路及其下一跳 |
DNS透明代理 | · DNS服务器 · 出口链路及其下一跳 |
入链路负载均衡 | 入口链路及其通往外网方向的下一跳 |
全局负载均衡 | · 虚服务器 · 入口链路及其通往外网方向的下一跳 |
下文以服务器负载均衡技术为例，介绍健康检测的原理。其他负载均衡技术原理类似，不再赘述。
如下图所示，当探测到实服务器状态均为正常时，SLB设备根据调度算法将客户端的流量依次分配给每台实服务器（以实服务器权值相同的加权轮转算法为例）。
图35 健康检测示意图（正常状态）
如下图所示，当探测到某台实服务器发生故障时，SLB设备立即停止向其分配流量，并将流量调度给其他处于正常状态的实服务器。
图36 健康检测示意图（故障状态）
一段时间后，若故障的实服务器状态恢复正常，设备会修改该实服务器的健康检测状态，使其重新参与调度。
整体来看，健康检测是一个“探测模板配置、周期探测、健康状态判定、调度决策”的过程。管理员先在设备上创建健康检测模板，约定采用何种方式探测、探测哪些内容以及按何种规则判断，然后将模板应用到资源池或具体节点上。之后，负载均衡设备会按照模板设定的周期，对各节点发起探测并收集返回结果，再结合事先配置的成功条件等，判断节点当前是否处于健康状态。该判断结果会直接影响流量分配：健康节点继续参与调度，异常节点则被自动隔离。同时健康检测功能还可以和告警、监控等功能联动，将节点状态变化及时反馈给运维人员。
探测模板是进行健康检测配置的基本载体，所有探测参数（如探测类型、目标地址、探测周期等）都在探测模板中定义，便于统一管理和重复使用。管理员可以根据不同的探测需求创建相应的模板，并按需将其绑定到资源池或节点。设备会按照模板中设定的周期自动向节点发起探测请求，从而判断节点是否处于健康状态。常见的健康检测方式包括：网络连通性检测（如ICMP）、端口可用性检测（如TCP探测）、协议与内容检测（如HTTP状态码或响应内容检查）、以及更深入的应用层与自定义脚本检测等。通过不同粒度的检测，可以从主机宕机、端口不可用，到应用异常、性能严重下降等多个层级精准识别故障。
健康检测通常包含以下核心要素：
· 检测对象：节点IP、端口、URL、特定业务接口等；
· 检测方式：ICMP、TCP握手、HTTP状态码检查、关键字匹配、自定义脚本等；
· 判定条件：连续探测成功/失败次数阈值、超时时间、状态码或返回内容判断规则等；
· 处置动作：在判定节点异常后，执行节点下线、流量切换、节点状态标记或恢复检测等操作。
通过合理规划和配置健康检测模板，在节点宕机、端口不可用、应用卡死、资源耗尽或性能严重下降等情况下，实现快速发现、自动处置与及时恢复，从而显著提升整体业务的可用性与稳定性。
从配置粒度上看，健康检测通常分为资源池级和节点级。
资源池级健康检测适用于同一组节点运行同类服务的场景，管理员只需为该资源池配置一个统一的探测模板即可，模板中的所有参数会自动应用到资源池内所有节点。这种方式配置简单、维护成本低，适合大部分一致性较高的集群，比如一组提供相同HTTP服务的Web服务器。
节点级健康检测则提供更细粒度的控制。当某些节点的运行环境或角色与其他节点不同时，就可以为其单独绑定独立的探测模板。相比于资源池级探测模板，节点级探测模板通常具有更高优先级。比如，某个节点上承载了不同的端口与业务，需要用不同的URL或端口进行探测。通过为该节点指定探测模板，管理员可以针对单个节点的特性调整超时时间、探测间隔或探测内容，避免统一的探测模板带来误判。
在协议层面，探测模板需要指定探测类型，例如ICMP探测、TCP探测、HTTP/HTTPS探测、DNS探测或者数据库协议探测等。对于网络层或传输层探测，模板主要关注目标IP地址和端口、探测间隔、超时时间以及连接是否能成功建立；对于应用层探测，模板中可以进一步定义请求方法、URL路径、请求头或请求报文内容，以及用于判定成功的状态码和响应内容关键字等参数。
在应用层健康检测中，HTTP和HTTPS是最常见的类型。一个典型的HTTP探测模板会使用GET或HEAD方法访问专门的健康检查路径，例如/health。模板中可以配置Host头，使设备在访问时模拟真实业务流量中的域名；也可以附加特定请求头，便于节点区分健康检查请求与普通业务请求。在结果判定方面，最基础的是检查HTTP状态码是否在指定范围内，例如200-299；在此基础上，还可以对响应体进行关键字匹配，例如要求响应中包含OK、UP或某个特定字段。对于HTTPS探测，除了HTTP协议参数外，还需在模板中考虑TLS/SSL相关配置。
对于非HTTP类应用，同样可以单独定制基于应用层的健康检测模板，使检测逻辑更加贴合具体应用。以MySQL为例，健康检测不必停留在端口可用，而是可以在建立TCP连接后，使用探测账号执行一条简单查询语句，仅当查询成功且响应在设定的超时时间内返回时，才将该节点判定为健康。相比网络层或传输层探测，这类应用层探测能够更真实地反映数据库的处理能力和整体服务状态。在此基础上，健康检测还可以结合脚本能力，对查询内容、校验逻辑等做进一步扩展，用于覆盖关键对象的检查。
在实际应用中，网络层和传输层的探测可提供基本的连通性保障，但在关键业务场景中，应当尽量辅以应用层探测，以保证业务真实可用。
在实际部署中，一个资源池或节点往往不只绑定一个健康检测模板，而是可以同时引用多个模板。例如，可以同时配置端口连通性检测和应用接口检测：前者用于确认服务端口是否可达，后者用于验证核心业务接口是否正常响应。此时，设备需要综合多个模板的探测结果，给出一个统一的健康状态判定结论。
为此，管理员可以通过配置健康检测的成功条件来定义在多模板场景下的判定规则，包括：
· 全部成功：只有当绑定的所有健康检测模板都返回成功结果时，才认为节点可用。此方式适用于对各项检测结果都高度敏感的关键业务场景，例如只有在节点同时满足端口连通、应用接口可用且依赖服务正常等条件时，才允许其参与流量调度。
· 至少部分成功：只要在多个健康检测模板中，有至少一定数量的探测结果为成功，就可以将节点视为可用。此方式适用于对部分检测项允许一定容错的场景，在某些非关键探测失败时，节点不必立刻整体下线。
在单个健康检测模板内部，还可以通过配置连续探测次数来平滑健康检测结果。只有在连续多次探测失败后才将节点判定为故障，在连续多次探测成功后才将节点判定恢复正常，从而避免因瞬时抖动导致节点状态在“可用”与“不可用”之间频繁切换。
通过同时合理规划多模板成功条件与连续探测次数，设备可以在检测项的完整性和检测结果的稳定性之间取得平衡，实现更加准确、可控的健康状态判定。
探测周期和超时时间是健康检测的关键参数。
探测周期决定设备多长时间对节点发起一次探测。周期过短会增加探测流量和节点负载；周期过长则会延迟故障发现时间，降低业务切换的及时性。
超时时间定义了每次探测等待响应的最长时长，一旦超过该时间仍未收到有效响应，就将本次探测判定为失败。超时时间应结合业务的正常响应时延进行配置，一般略高于正常响应时延的95%，这样既能容忍偶发的响应变慢，又不至于等待时间过长。对于缓存探测这种交互简单、响应很快的健康检测，超时时间可以设置得较短；对于数据库探测这种包含一定业务逻辑的健康检测，超时时间则应适当放宽。
在实际应用中，探测周期和超时时间需要结合业务要求、网络环境稳定性和节点处理能力进行综合权衡，避免因为配置过于激进引起误判或探测本身成为额外负担。
负载均衡策略用来决定设备在收到客户端请求后，应如何分配和处理流量。通过选择合适的负载均衡策略，并结合前文介绍的调度算法，可以在不同业务之间实现更加精细的流量控制。
将负载均衡类和负载均衡动作关联起来就构成了负载均衡策略。通过负载均衡策略，用户可以为匹配特定负载均衡类的流量指定执行的负载均衡动作。设备首先通过负载均衡类对流量进行分类，明确流量属于哪一类业务或处理范围；再为各类流量分别指定负载均衡动作，定义应如何处理这些流量。负载均衡类与负载均衡动作的绑定关系即为策略条目，多个策略条目按照配置顺序组织在一起，构成完整的负载均衡策略。
同一个负载均衡策略中可以包含多条基于“类+动作”的策略条目。流量进入设备后，将按照策略中负载均衡类的配置顺序进行匹配：设备依次检查各条负载均衡类，当流量满足某一负载均衡类的匹配条件时，即认为匹配成功，执行与之关联的负载均衡动作，不再继续匹配后续的负载均衡类；如果未匹配成功，则继续按顺序匹配下一策略条目。为避免出现无法判定如何处理的情况，还可以为未匹配任何负载均衡类的报文配置缺省负载均衡动作，在所有负载均衡类均未命中的情况下执行。
由于策略匹配是按顺序进行的，当不同负载均衡类之间存在包含或交叉关系时，策略条目的顺序尤为关键。一般建议将匹配条件更精细、作用范围更小的负载均衡类放在前面，将匹配条件较宽泛、覆盖范围较大的负载均衡类放在后面，以确保细粒度规则优先生效，而不会被大范围规则所遮盖。
为了适配不同的业务协议和负载均衡场景，设备支持多种类型的负载均衡策略，并对各类型策略可以引用的负载均衡类和负载均衡动作做了约束。这既保证了配置的正确性，也体现了不同应用层协议在解析与调度逻辑上的差异。
在服务器负载均衡场景中，四层负载均衡策略被定义为通用类型，只能引用通用类型的负载均衡类和负载均衡动作，适用于基于IP和端口的多种四层业务；七层负载均衡策略则根据具体应用协议划分为HTTP、MySQL、RADIUS、Diameter等类型，可以引用同类型和通用类型的负载均衡类与动作。这种设计使得七层策略在保持协议特定能力的同时，仍然能够复用通用负载均衡类和动作。
在出链路负载均衡场景中，策略类型为链路类型。链路类型的负载均衡策略只能引用链路类型的负载均衡类和负载均衡动作，确保策略所匹配和调度的对象始终是出方向链路。
在DNS透明代理场景中，策略类型为DNS类型。DNS类型的负载均衡策略只能引用DNS类型的负载均衡类和负载均衡动作，以保证策略能够基于DNS报文特征进行准确匹配，并根据DNS业务特性进行调度和处理。
在所有场景中，策略在创建时都必须明确指定其类型，确保策略始终在合理的协议和业务边界内生效。
从配置角度看，各类负载均衡策略都包含三类核心内容：针对特定负载均衡类为其绑定负载均衡动作、设置缺省负载均衡动作以及若干策略条目的顺序组织。
在策略内部，为某个负载均衡类指定负载均衡动作，就形成了一条策略条目。当报文匹配该类时，设备执行相应的动作——通常是将报文调度到指定的资源池，在该资源池内根据健康检测和调度算法选择节点进行转发；也可以是对报文进行丢弃、绕过负载均衡或转发到指定下一跳等。多个不同的负载均衡类可以引用同一个负载均衡动作，这使得管理员能够在不重复配置动作的前提下，对多个类采用相同的处理方式，例如将多类业务统一调度到同一个资源池，或统一执行相同的控制策略。
策略匹配过程遵循自上而下、逐条检查的原则。策略配置中，负载均衡类的顺序可以通过插入控制参数进行调整，例如在为负载均衡类绑定动作时，支持将其插入到某个已有类之前或之后，精细控制策略条目的生效顺序。这样在需要新增一条更精细的策略条目而又不想打乱整体结构时，可以将其插入到适当位置，实现对部分流量的优先处理。
如果策略中配置了缺省负载均衡动作，当报文未命中任何配置的负载均衡类时，将执行这一缺省动作。通过缺省动作，可以为不在任何特定类中的流量提供一个统一的处理方式，常见做法是调度到一个通用资源池或按既定路径转发，从而保证所有流量都有明确的处理结果。
负载均衡类用于对进入设备的报文进行分类，是负载均衡策略的基础。管理员可以在一个负载均衡类中配置多条匹配规则，设备根据这些规则判断报文是否属于该类，从而实现复杂业务场景下的精细化分类。
同一个负载均衡类内部可以包含多条匹配规则，设备按照规则的配置顺序对报文进行检查。创建负载均衡类时可以指定匹配方式，用于决定多条规则之间的逻辑关系：
· 当匹配方式为匹配任意一条规则时，只要报文与其中任一匹配规则匹配成功，即认为命中该负载均衡类，并执行与该类关联的负载均衡动作；如果所有匹配规则都未匹配成功，则该负载均衡类不生效，设备继续匹配其他负载均衡类。
· 当匹配方式为匹配所有规则时，只有在报文同时满足该类下配置的所有匹配规则时，才认为命中该负载均衡类，并执行相应的负载均衡动作；只要有任一规则未匹配成功，该类即不生效。
此外，匹配规则可以配置为其他负载均衡类，即在一个类中引用另一个已配置的负载均衡类，从而对常用匹配逻辑进行复用，或通过分层方式构建更清晰的流量分类结构。例如，可先按用户或区域进行粗粒度划分，再在子类中按应用协议或业务特征进行细粒度区分；也可以将常用的匹配逻辑定义为独立类，在多个策略中共享使用。
在负载均衡技术中，负载均衡类所支持的匹配维度有所差异，具体如下。
在服务器负载均衡中，负载均衡类既可以按通用四层属性划分流量，也可以按具体应用协议做更细的区分：
· 通用类型负载均衡类
主要面向各类四层业务，按网络与用户维度对流量分类，例如基于源IP地址、ACL、入接口、用户或用户组等进行匹配，也可以匹配TCP载荷内容，用于识别携带特定特征的TCP流量。典型场景包括：按来源网段将访问请求分配到不同实服务组，或对特定用户群体指定专用的实服务组等。
· HTTP 类型负载均衡类
主要面向Web业务，可根据URL、HTTP方法、版本、首部字段、Cookie及实体内容等进行匹配，实现对不同站点、不同业务接口或不同类型请求的分类，例如将静态资源请求与动态请求分配到不同的实服务组，将特定URL的访问引导到专用实服务组等。
· MySQL类型负载均衡类
面向数据库访问流量，可根据SQL语句内容进行分类。例如将查询类语句和更新类语句分别调度到只读库与主库，或者将涉及敏感表的访问引导至特定数据库实例，以实现读写分离或按业务数据划分后端资源。
· RADIUS类型负载均衡类
面向认证和计费业务，可根据RADIUS属性对报文进行分类。例如为不同用户群体选择不同认证服务器组，或将特定业务的计费请求分配到专用计费服务器。
· Diameter类型负载均衡类
面向运营商核心网等信令场景，可根据应用ID、目的域名等Diameter报文特征区分不同业务应用。例如将不同业务（如计费、策略控制）对应的Diameter会话分配到不同实服务组，保证各类信令业务独立调度和扩展。
通过上述类型的负载均衡类，设备在服务器负载均衡场景下，既能按IP和端口等通用特征分流，也能结合具体协议和业务内容进行更精细的分类。
在出链路负载均衡中，匹配规则主要根据出方向流量的来源和去向对流量进行划分，用于决定不同流量应通过哪条出口链路或链路组转发。设备既可以基于源、目的IP地址、ACL、入接口等网络属性对流量进行匹配，也可以结合用户和用户组信息，以及域名、ISP和应用类型等信息，对流量进行更精细的区分。
通过综合运用这些匹配规则，管理员可以根据来源网络、目标地址、访问的域名、所属运营商或应用类型等，将不同类别的流量引导至合适的出口链路或链路组上。例如，可以将关键业务流量调度到质量更高的链路，将大流量视频或下载业务分配到带宽更充足的链路，从而在保证业务体验的同时，提高多条出口链路的整体利用效率。
在DNS透明代理中，负载均衡类用于对DNS流量进行分类。设备可以根据源、目的地址及ACL对DNS请求做基础划分，也可以直接读取报文中的域名，将不同域名的请求归入不同的负载均衡类。
在实际应用中，可以根据访问的域名，选择不同的DNS服务器或不同的出口链路。例如，将企业内部业务的域名解析请求固定转发到内网DNS，将公网常用域名转发到运营商DNS，或将特定域名的解析流量引导到指定链路上，以优化访问速度和可靠性。
负载均衡动作用于定义在报文命中负载均衡类之后，设备对该报文应执行的处理行为。负载均衡类负责对流量进行分类，负载均衡动作负责对已分类的流量进行转发、修改或代答，两者配合构成完整的负载均衡策略。
从功能上看，负载均衡动作主要分为三大类：
· 转发类动作：决定是否转发以及转发目的地。
· 修改类动作：转发前或转发过程中，对报文内容及相关属性进行修改。
· 代答类动作：由设备直接对客户端请求进行本地应答，通常用于HTTP类型的七层服务器负载均衡场景。
如果在某个负载均衡动作中未配置任何具体处理行为，则匹配到该动作的报文将缺乏明确的处理路径，最终被丢弃。因此，负载均衡动作既可以承载复杂处理逻辑，也可以通过空动作的方式显式实现丢弃策略。
会话保持的作用是根据某会话保持方法将具有一定相关性的会话都分配给同一节点处理，这个分配规则就称为会话保持表项。在一个会话中，当其首包通过会话保持方法选择了同一节点之后，后续包都会沿用这个选择结果，减少了调度算法的重复运算，提升了转发效率。
会话保持组的详细处理流程如下：
(1) 当设备首次收到具有某种特征的请求时，会根据调度算法将请求分发给某个节点，同时根据管理员配置的会话保持方法生成会话保持表项。
(2) 在会话保持表项老化之前，若设备再次收到具有相同特征的请求，则不再根据调度算法进行计算，而是依据已生成的会话保持表项，选择对应的节点进行转发。
支持
