- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
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地址、端口和VPN实例唯一标识。外部用户的访问请求首先到达虚服务器，只有匹配虚服务器的流量才会进入服务器负载均衡处理流程，并由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设备集群既可以在同一内网/同一数据中心内部构建，支撑单数据中心的多业务场景；也可以跨内网/跨数据中心构建，支撑多活数据中心场景。
在集群模式下，多台SLB设备不仅可以形成主备或双主组网，还可以形成多主组网，进一步提高了系统的处理能力和扩容能力。
如图10所示，在同一数据中心多业务集群模式组网中，正常情况下，数据中心的不同SLB设备可以对外发布不同的业务，这样每台SLB设备可以集中高效地处理某一种业务，同时SLB设备之间又可以相互备份配置信息和业务信息。
如图11所示，当其中一台SLB设备故障时，其他设备可以立即接手这些流量，保证用户业务不中断。
如图12所示，在多活数据中心集群模式组网中，正常情况下，多个数据中心同时对外提供服务，充分利用现有的网络资源和应用服务资源等，不同数据中心SLB设备之间的配置信息和业务信息可以相互备份。
如图13所示，当其中一个数据中心的某台SLB设备故障不能对外提供服务时，首先让同一数据中心的其他SLB设备立即接手这些流量，保证用户业务不中断；同理，当整个数据中心故障不能对外提供服务时，再由其他数据中心的SLB设备立即接手这些流量，保证用户业务不中断。
在企业或数据中心等场景中，常常会部署多条上行链路接入多个ISP（Internet Service Provider，互联网服务提供商），以满足扩展出口带宽和提升网络可靠性的需求。
然而，多链路环境也会带来一些挑战，例如，链路利用率可能严重不均衡，部分链路长期处于拥塞状态，而其他链路则相对闲置；仅依靠路由策略引导出方向流量的方式缺乏足够的灵活性，难以根据业务类型、目的地址或链路运行状况灵活调整出口路径；同时，由于缺乏链路健康检查与自动切换机制，当某条链路发生故障时，业务流量仍可能继续转发至故障链路，从而造成访问中断，直接影响用户体验。
出链路负载均衡技术可以将内网用户访问互联网的流量智能分配到多条出口链路上，从而提高链路资源利用率并优化用户访问体验。
完成相关配置后，设备会根据内网用户流量特征，结合链路健康状况、会话保持方法和调度算法等，将不同业务流量合理分配到各条出口链路上。
如下图所示，根据管理员的配置，LB设备可将带宽较大的链路优先用于承载视频等大流量业务，将带宽较小的链路用于承载其他业务。当某条链路发生拥塞或故障时，流量会自动切换到其他可用链路。通过这种智能调度机制，既避免了出链路间的流量分配不均，又提升了整体转发效率和网络响应速度。
图14 出链路负载均衡简介图
在出链路负载均衡技术中，涉及以下关键概念：
· 虚服务器（Virtual Server）：设备上面向用户业务的虚拟出口，出链路负载均衡的虚服务器为LINK-IP类型，由IP地址、端口和VPN实例唯一标识。内网用户的访问请求首先到达LINK-IP类型的虚服务器，只有匹配上虚服务器的报文才会进行出链路负载均衡处理。VSIP（Virtual Server's IP）为虚服务器的IP地址，即为内网用户发送报文的目的地址。在实际配置中，可以将虚服务器的IP地址配置为0.0.0.0（或IPv6的::），掩码/前缀长度配置为0，端口号配置为0，用于表示该虚服务器匹配所有目的地址和端口的流量。
· 链路（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请求报文进行智能解析，为外网用户选择最佳入方向链路。具体工作流程如下图所示。
入链路负载均衡工作流程简述如下：
(1) Host向Local DNS服务器发起DNS请求（若请求域名为example.com）。
(2) Local DNS服务器向指定域名（example.com）的权威DNS服务器LB device发起DNS请求。
(3) LB device根据调度算法、健康检测结果、带宽限制策略等来选择最佳入方向链路。
(4) LB device将选定入方向链路对应的虚服务器IP地址通过DNS响应报文发送给发起请求的Local DNS服务器。管理员可为每条入方向链路绑定其对应的虚服务器。
(5) Local DNS服务器把获取的虚服务器IP地址发送给Host。此步骤即完成了将Host请求域名（example.com）智能解析为指定IP地址（最优入链路对应的虚服务器IP地址）。
(6) Host向虚服务器IP地址发起访问请求（请求通过选定入链路进入LB device）。
(7) LB device向内网服务器发起访问请求。
(8) 内网服务器发送响应至LB device。
(9) 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类型的七层服务器负载均衡场景。
如果在某个负载均衡动作中未配置任何具体处理行为，则匹配到该动作的报文将缺乏明确的处理路径，最终被丢弃。因此，负载均衡动作既可以承载复杂处理逻辑，也可以通过空动作的方式显式实现丢弃策略。
转发类动作决定报文是否转发以及如何转发，不仅包括是否转发、转发到哪个资源池，还包括在目标节点不可用或过载时的处理行为。
在转发类动作中，实现负载均衡的核心动作为“转发到指定资源池”。设备通过将命中某一负载均衡类的报文调度到指定的资源池（如实服务组、链路组或DNS服务器池），由资源池内部的健康检查与调度算法在多个节点之间分配流量，从而完成负载均衡决策。
其他转发类动作则作为对这一核心转发动作的补充，用于控制报文在特殊场景下的处理路径，例如保持现有转发关系不变或在检测到异常时快速终止连接等。
通过“转发到指定资源池”动作，设备可以将命中负载均衡类的报文转发给指定的资源池处理，再由该资源池内的调度算法完成具体节点的选择。资源池支持配置主用和备用：系统会优先使用主用资源池，当主用资源池不存在或无可用节点时，设备会自动切换到备用资源池，确保服务连续性。
当管理员希望在动作中明确指定命中某负载均衡类的流量由哪个资源池处理，而不是沿用虚服务器或DNS透明代理中配置的默认资源池时，应选择“转发到指定资源池”动作。典型适用场景包括：
· 对特定流量精确指定资源池。例如，对特定用户群、特定网段或特定业务请求，将流量固定转发到某个指定资源池，用于满足性能优化、合规要求或访问控制等需求。
· 将不同业务请求转发到不同的资源池进行处理。例如，将API请求转发到API实服务组，将Portal接入/认证相关请求转发至认证或接入实服务组，将业务访问请求转发至业务实服务组，在同一虚服务器/DNS透明代理下，实现对不同请求类型的资源隔离与差异化处理。
“直接转发”动作是指，设备对命中负载均衡类的报文，在执行该动作时不再重新选择目标资源池，而是沿当前已确定的转发路径直接转发。设备只负责允许报文继续转发，至于转发到哪里，由虚服务器引用的实服务组、虚服务器引用的链路组、DNS透明代理引用的DNS服务器池，或系统中既有的转发路径（如路由配置）决定，动作本身不对调度过程做额外干预。
在未配置任何失败处理机制时，如果当前转发路径上不存在可用的转发目标，相应报文将被直接丢弃。例如，虚服务器引用的默认资源池中无可用节点，且未配置备用资源池或其他兜底路径。
“直接转发”动作适用于处理逻辑简单、且可以通过虚服务器、DNS透明代理或路由等其他配置完成目标节点选择的场景。在此类场景中，它的作用是允许报文按现有规则继续转发，而不是在动作执行阶段重新进行一次调度决策。
对于匹配同一负载均衡类的流量，“直接转发”和“转发到指定资源池”通常是互斥的：当管理员希望流量沿用虚服务器或DNS透明代理配置的默认资源池或系统中既有的转发路径时，可选择“直接转发”动作；当需要在动作中显式指定新的资源池时，则应选择“转发到指定资源池”动作。
“关闭TCP连接”动作是指，当报文命中负载均衡类时，设备主动向客户端发送TCP FIN或TCP RST报文，直接关闭当前TCP连接。
选择FIN方式关闭连接时，设备按照TCP标准的挥手流程与客户端正常结束会话，适合希望相对平滑地释放TCP连接的场景。选择RST方式关闭连接时，设备会立即向客户端发送TCP RST报文，中断当前连接，客户端通常会立刻收到连接被重置的反馈，有利于快速关闭连接并触发连接重试。
“关闭TCP连接”动作常用于对已建立连接进行策略阻断，例如在应用识别、内容检测或认证过程中发现异常、违规或不满足访问条件的请求时，在负载均衡动作中直接终止连接，避免继续占用资源。当管理员希望在动作中明确结束当前TCP会话，而不是仅丢弃报文或让连接长时间等待超时时，可选择“关闭TCP连接”动作。
“跳过当前DNS透明代理”动作是指，当DNS请求命中某个DNS透明代理及其负载均衡类时，设备不按照当前DNS透明代理的配置对该请求进行应答或转发，而是让该请求跳过当前DNS透明代理处理流程，重新回到整体转发流程中，由后续策略决定如何继续处理该请求。
该动作适用于精确排除某类DNS请求不由当前DNS透明代理处理，而是交给后续的DNS透明代理、虚服务器或普通路由去决定下一步如何转发。对于不适合采用当前DNS透明代理处理、但又不希望简单丢弃的DNS请求，可以通过该动作将其交由其他处理逻辑继续判断和转发。例如，在条件分流场景下，对特定源地址或域名的DNS请求，不采用当前DNS透明代理的处理逻辑，而是交由其他处理流程或普通转发路径完成解析。当管理员希望在负载均衡动作中明确指定当前DNS透明代理不再处理某类请求时，可选择“跳过当前DNS透明代理”动作。
当报文匹配到某个负载均衡类并开始执行其对应的负载均衡动作时，设备需要从相应的资源池中查找可用节点进行转发。当由于健康检查失败、资源耗尽或其他原因，导致在当前动作引用的资源池中未能找到可用节点时，就触发查找可用节点失败的处理逻辑。此时，设备可以根据预先配置的查找可用节点失败时的处理动作，决定是继续匹配后续策略条目，还是直接终止连接。
· 继续匹配下一条引用规则
当查找可用节点失败时，设备不会立即中断处理流程，而是继续匹配同一策略下的下一条策略条目（即下一个负载均衡类），由后续负载均衡类决定是否采用其他资源池进行转发。
· 关闭TCP连接
当查找可用节点失败时，直接关闭当前TCP连接。此时，设备会向客户端发送TCP FIN或TCP RST报文，终止本次连接处理，不再继续匹配后续策略条目，也不再尝试其他转发路径。该方式通常用于在节点不可用时，希望立即向客户端反馈失败结果的场景。
通过合理选择查找可用节点失败时的处理动作，管理员可以在尽可能利用后续策略条目进行容错处理，和在失败时快速、明确地终止连接之间灵活取舍，从而对查找可用节点失败时的行为进行控制。
节点是否处于繁忙状态，由其实际带宽占用与带宽繁忙相关配置共同决定。当某方向的实际带宽超过“带宽繁忙比×最大期望带宽”时，节点在该方向被判定为处于繁忙状态；如果资源池内所有节点均被判定为繁忙状态，则认为该资源池整体处于繁忙状态。
当负载均衡动作配置为“转发至指定资源池”时，设备会在该资源池中选择目标节点。如果资源池整体繁忙，且未将繁忙处理动作配置为“继续匹配下一条引用规则”，设备会采用强制调度行为：即使资源池中所有节点都处于繁忙状态，仍从中选取一个节点，将新建流量分发到该节点。这样可以保证请求得到处理，但会继续加重已繁忙节点的负载，存在进一步放大拥塞风险的可能。
当将繁忙处理动作配置为“继续匹配下一条引用规则”时，在资源池整体繁忙的情况下，设备不再进行强制调度，而是继续匹配负载均衡策略下的下一条策略条目（即下一个负载均衡类），由后续负载均衡动作决定是否选择其他资源池或其他转发方式。
若需要在某个资源池整体进入繁忙状态后，切换到其他资源池承载新建流量，建议将繁忙处理动作配置为“继续匹配下一条引用规则”。例如，为同一类业务配置了多个资源池，希望优先使用某个资源池，当该资源池整体繁忙时，不再向其强制分配新流量，而是由后续策略条目选择其他资源池继续转发。通过这种方式，可以在资源未真正故障但已接近承载上限时，主动将新增流量分流到其他可用资源池，避免单一资源池过载，提升整体系统的承载能力和稳定性。
修改类动作用于在报文转发前或转发过程中，对命中负载均衡类的报文内容进行调整或重写。设备可对报文的IP首部、TCP载荷以及各类应用层数据进行修改，以实现业务标记、内容改写、协议适配，以及与上下游设备的协同处理。
修改类动作可应用于多种负载均衡场景，具体可用的修改类动作取决于负载均衡动作的协议类型。
该动作用于修改发往目的端的IP报文中ToS（Type of Service）字段的值。通过在负载均衡设备上统一设置ToS字段，可使后端网络设备或目的端根据该字段进行差异化处理，如队列调度、带宽保障或特定转发策略优化。该动作仅修改IP首部中的 ToS字段，不改变报文的转发路径。
在实际应用中，该动作常用于区分业务重要程度。例如，为核心业务流量设置较高的ToS值，为普通访问流量设置较低的ToS值，从而在服务器或网络资源紧张时优先保障关键业务。在出方向链路负载均衡场景中，可对发往不同出口或不同类型的流量打上不同的ToS标记，使后续网络中的QoS策略可以识别并优先处理特定流量。在DNS透明代理场景下，则可以为DNS请求报文设置特定ToS值，以提升域名解析流量在网络中的优先级，从而提高解析响应速度和稳定性。
未配置该动作时，设备保持报文原有ToS字段不变；配置后，所有命中指定负载均衡类的报文将按配置的ToS值进行统一标记。
该动作用于对指定方向TCP报文的载荷内容进行重写。对于命中指定负载均衡类的报文，设备可以对TCP载荷中的部分内容进行替换或插入，在不影响连接建立过程和转发目标的前提下，对会话内容进行调整和优化。通过在报文转发至后端服务器前修改其中的TCP载荷，可以满足业务侧对报文内容的定制化需求，例如补充或改写特定字段，以便更好地适配现网应用或对端系统。
在实际应用中，该动作常用于适配旧系统与新业务之间的协议差异。例如，在请求报文中插入或重写特定字段，使后端服务器能够识别新的业务标识；在应答报文中调整部分会话信息，使上游设备或客户端能够正确解析和处理返回结果。对于基于TCP承载自定义私有协议的场景，也可以通过重写载荷，对部分字段内容进行调整，以保持与既有应用的兼容性。
该动作适用于需要对TCP会话内容进行精细控制、但又不便修改客户端或服务器应用的场景，为业务升级和协议演进等场景提供灵活的改写能力。
该动作用于对HTTP报文首部进行删除、插入或重写。对于命中指定负载均衡类的HTTP请求或应答报文，设备可以灵活调整首部字段，例如补充新的首部、修改已有首部的取值或删除不需要的首部，在不改变转发路径的前提下，实现对应用层行为的精细控制与优化。
在实际应用中，该动作常用于在客户端与后端服务器之间传递额外信息或隐藏内部实现细节。例如，在请求报文中插入用于标识真实客户端IP地址的首部字段（如X-Forwarded-For），便于后端服务器进行审计、统计和访问控制；在对接第三方服务时，可通过重写某些首部字段，使请求满足对端接口规范。同时，还可删除暴露后端信息的敏感首部（如部分Cookie或调试用首部），以减少信息泄露风险并提升整体安全性。
该动作用于在后端服务器返回HTTP应答后，对应答报文中的指定内容进行改写。设备可以对HTTP应答报文的Location首部以及应答报文体中满足匹配条件的内容进行重写。
重写HTTP应答报文Location首部中的URL，主要用于隐藏后端真实地址，并适配对外发布的域名和访问路径。典型场景包括：后端返回的是内部域名或内网路径，而客户端实际应访问对外统一域名时，可在负载均衡设备上将Location中的URL整体改写为外部可见地址，避免暴露内部域名结构，同时保证客户端感知到的访问URL前后一致。
重写HTTP应答报文Location首部中的指定内容，主要用于对跳转地址做细粒度调整，而非整体替换。设备通过匹配Location首部中的指定字符串，对路径前缀、端口、协议或查询参数等部分字段进行局部插入或修改，其余内容保持不变，从而在不改变整体跳转逻辑的前提下，使跳转链接满足前端页面或第三方接口的要求。典型应用场景包括：在统一接入网关后，为不同环境或租户插入/test、/beta等路径前缀；在跳转URL上补充版本号、渠道号等参数，以兼容新旧接口或实现精细化流量标记。在多域名统一接入、跨地域访问或HTTP/HTTPS改造等场景中，也可通过仅调整Location中的协议、主机名或路径，将后端返回的跳转地址统一为对外规范的访问地址。
重写HTTP应答报文体中指定内容，主要用于对返回的应答内容进行二次加工。当应答体为HTML、JSON、XML等明文格式时，设备可以根据配置的匹配条件，将其中的链接、图片地址、脚本引用路径、接口调用地址等内容替换为指定值，以实现前端资源重定向或内部信息隐藏等目的。例如，可将应答内容中指向内网资源的URL统一替换为公网可访问地址，将其中的内部IP、主机名、调试信息等敏感信息替换为通用提示，避免对外泄露内部细节。
HTTP重定向用于对匹配指定负载均衡类的HTTP请求执行重定向。当请求命中指定负载均衡类并触发重定向动作后，设备不再将该请求转发至后端服务器，而是直接返回带有Location首部的3xx重定向响应，引导客户端访问预先配置的目标URL。重定向响应状态码可配置为301、302或307，未配置时默认使用302。
该动作可用于在入口侧统一实现HTTP到HTTPS的跳转，将HTTP访问自动引导至HTTPS加密通道；在业务域名或访问路径调整时，将旧URL的访问透明重定向到新URL，保证历史链接仍可访问；在多入口整合场景中，将不再承载业务的入口统一跳转到新的访问地址。通过在设备侧集中配置HTTP重定向，可将相关重定向处理从后端服务器中剥离，实现域名切换、协议升级及业务迁移过程的统一管理。
SSL客户端加密动作用于在负载均衡设备与后端服务器之间启用加密通信。当在Diameter或HTTP类型的负载均衡动作中引用某个SSL客户端策略后，设备在作为客户端访问后端服务器时，将按照SSL客户端策略中预先定义的协议版本、加密套件、证书与密钥等参数发起SSL/TLS握手，对业务流量进行加密传输。
通过配置SSL客户端加密，可以在设备与后端服务器之间建立安全隧道，防止传输过程中数据被窃听或篡改。设备在发起连接时统一按照SSL客户端策略与后端进行加密协商，有利于在设备侧集中控制加密参数，便于后续的协议升级和加密配置调整。
该动作通过引用预先配置的参数模板，将发往指定实服务组的流量按模板中定义的规则进行统一处理与优化。目前支持引用Diameter-Session类型和TCP类型的参数模板。
· 引用Diameter-Session类型参数模板时，设备会根据参数模板对Diameter会话的协商参数和数据转发行为进行统一控制。例如，在会话建立阶段集中配置CER/CEA协商相关参数和协商超时时间，在数据转发阶段统一启用并调整数据报文重传策略，从而提升Diameter会话处理的可靠性和一致性。
· 引用TCP类型参数模板时，设备会根据模板对设备与服务器之间建立的TCP连接进行统一的性能优化和行为控制。例如，调整窗口大小、空闲和重传超时时间、MSS及保活等连接参数，并可按需插入、清除或重写特定TCP选项，以在不同网络条件下提升业务访问的稳定性和转发效率。
通过集中定义参数模板并在负载均衡动作中引用，可避免重复配置，确保同类业务在会话与连接参数上的一致性。当业务特性或网络环境变化时，只需修改参数模板，即可对所有引用该模板的动作统一生效，显著提升整体配置的灵活性和可维护性。
代答类动作用于在HTTP类型服务器负载均衡场景下，由设备直接向客户端返回预先准备好的应答内容，而不是将请求转发给后端服务器。通过配置代答动作，可以在特定业务请求或异常情况下，快速向客户端返回合适的HTTP响应，提高用户体验并减轻后端服务器压力。
管理员可以为匹配特定URL的HTTP请求配置代答文件。当客户端请求的资源路径满足配置条件时，设备将直接使用指定文件对客户端请求进行应答，而不再访问后端服务器。
该动作常用于返回固定页面或本地维护页面等内容，实现对部分请求的本地快速响应，减少对后端服务器的访问。
当设备无法找到可用的实服务器，或虽为指定HTTP请求配置了代答但未找到对应代答文件时，设备不会直接丢弃HTTP请求，而是使用预先配置的代答文件对客户端请求进行应答。
通过该动作，可以在后端服务器故障或资源不可用等异常情况下，向客户端返回错误页或维护提示页，从而提升整体服务可用性和用户体验。
会话保持是一种在负载均衡场景下优化流量分配、保障业务连续性的机制。其核心作用是：根据预先定义的会话保持方法，将具有相同特征的一类请求持续分配到同一目标节点处理，包括同一实服务器、同一出口链路或同一DNS服务器等。这样既能保证会话的连续性，又能减少每次调度时的算法计算开销，提升整体转发效率。
会话保持的工作机制如下：
(1) 首包调度与会话保持表项生成
当设备首次收到具有某种特征的请求时，先根据调度算法选出一个目标节点，并据此生成一条会话保持表项。表项中记录用于识别该会话的关键特征（如源/目的IP地址、应用层标识等）以及对应的目标节点。
(2) 后续请求复用会话保持表项
在会话保持表项尚未老化之前，后续携带相同特征的请求流量无需再次通过调度算法选择目标节点，而是直接匹配已有的会话保持表项，并将请求转发到表项中记录的同一目标节点，从而确保会话访问路径的一致性与连续性。
设备通过会话保持组来承载会话保持配置。会话保持组中可以包含一个或多个会话保持方法，管理员可在虚服务器、负载均衡动作或DNS透明代理中按需引用相应的会话保持组，以便针对不同业务调用合适的会话保持规则。
为适应不同业务类型和协议特征，设备支持以下几类会话保持方法：
根据源/目的IP地址和端口生成会话保持表项，适用于四层服务器负载均衡、出链路负载均衡和DNS透明代理等场景。例如：按源IP将来自同一客户端或同一网段的访问固定到同一节点，避免流量在多个节点间来回切换，影响会话连续性。
管理员在会话保持方法中预先定义需解析的TCP/UDP载荷范围，设备在收到报文后从指定的载荷范围中提取相应字段，并据此生成会话保持表项。该方法适用于业务标识承载在传输层载荷中的场景。例如，部分私有协议，或需要依赖报文中特定标识来区分不同用户、会话的应用。通过基于载荷字段进行匹配，可以实现更精细的会话绑定。
通过解析HTTP报文，从请求首部、请求行（如URL、Host）、请求实体、Cookie、HTTP载荷，或以HTTP passive方式从应答报文中提取关键信息，用于生成会话保持表项。管理员可以按需指定用于会话保持的字段。例如：基于Cookie信息将同一登录用户的后续访问固定到同一实服务器，避免会话在多台实服务器间漂移；基于 URL、Host或自定义首部，将特定业务的请求固定到指定实服务器，便于业务隔离。
该方法适合需要精确识别用户、租户、业务类型的Web应用负载均衡场景。
通过解析特定应用层协议报文，设备可根据其中的关键标识字段生成会话保持表项，例如RADIUS属性、Diameter属性、SIP Call-ID、SSL会话ID等。典型应用场景包括：在AAA认证和计费场景中，基于RADIUS User-Name或Diameter Session-Id等字段，对同一用户或同一会话的请求进行会话保持；在信令控制场景中，基于SIP Call-ID字段，将同一呼叫过程的信令消息固定调度到同一信令服务器处理；在加密会话场景中，基于SSL会话ID，将同一加密会话相关的连接固定调度到同一服务器处理。
通过利用这些协议自身携带的用户标识或会话标识，可以在不同类型的业务中实现更精确的会话保持。
会话保持表项在创建后会保留一段时间，如果在此期间没有新的匹配流量，表项就会被老化删除。管理员可以通过配置超时时间来控制老化时间的长短。
超时时间设置得较长，可以在用户多次访问间隔较长的情况下，仍然命中原有表项，提升会话连续性；但同时会导致表项数量增多，占用更多内存资源，并增加查表开销。超时时间设置得较短，有助于减少无效表项、节约内存资源，不过当用户访问间隔较长时，就可能频繁重新建立表项，导致同一用户被调度到不同节点。
实际配置时，应结合业务访问特性设置会话表项的超时时间：对于交互频繁、会话时长较长的业务，可适当延长超时时间，以提高会话稳定性；对于大量短连接或偶发访问的业务，则宜配置较短的超时时间，避免会话表项过度膨胀。
会话保持表项默认仅在当前虚服务器内生效。设备收到请求后，会先在该虚服务器中查找会话保持表项：匹配成功则按照表项指定的实服务器转发；匹配失败则不再继续会话保持匹配，直接按调度算法或其他负载均衡策略转发流量。
在服务器负载均衡环境中，管理员也可以通过配置扩大会话保持表项的匹配范围，使设备在当前虚服务器未匹配到会话保持表项时，继续到其他虚服务器查找，从而实现跨服务或跨虚服务器的会话保持。
· 跨服务匹配指，若当前虚服务器无匹配的会话保持表项，设备会在“IP地址相同、端口不同”的其他虚服务器上继续匹配。该功能适用于多个IP地址相同的虚服务器共用相同实服务器资源的场景。
· 跨虚服务器匹配是指，若当前虚服务器无匹配的会话保持表项，设备会在所有其他虚服务器中继续匹配。该功能适用于多个虚服务器共用相同实服务器资源的场景。
通过合理设置匹配范围，可以让访问不同虚服务器、但共享后端实服务器资源的用户会话，尽量落到同一台实服务器上，从而提升会话连续性。若各虚服务器的后端资源和业务相对独立，则不建议开启跨服务或跨虚服务器匹配，以免不同业务之间相互抢占实服务器资源，打乱负载分布，增加故障排查的复杂度。
在高并发场景下，设备通常通过连接数限制和带宽繁忙控制来保护后端实服务器不过载。但如果已建立的会话在业务处理中途，因触发这些限制被中断或被切换到其他实服务器，用户可能会感知到明显异常，例如：交易中断、表单重填、重新登录等。为此，可以通过配置，在一定程度上优先保障已建立会话的连续性。
会话保持优先主要体现在两个功能：
· 匹配会话保持表项的会话不受连接数限制影响：当连接命中会话保持表项后，将不再受连接数上限约束。这样，当系统整体连接数已接近或达到上限时，普通新建连接可能被限制或丢弃，而已命中会话保持表项的连接仍会被优先放行，从而降低正在进行的业务会话被中断的风险。
· 会话保持处理优先于繁忙状态：在会话保持表项尚未老化之前，即使对应节点已被标记为繁忙，设备仍会依据已有的会话保持表项，将匹配该表项的后续流量继续分配到同一节点，而不会立即停止分配或切换至其他节点。若未开启该功能，则一旦节点进入繁忙状态，即使存在匹配的会话保持表项，设备也不再向该节点分配新的流量。
这类功能适用于对会话稳定性要求较高的关键业务场景，尤其是交互复杂、处理流程较长的应用。此类功能可在系统负载较高甚至局部繁忙时，尽量保障已有会话顺利完成。对于更看重整体吞吐量和资源利用率的环境，则应谨慎开启此类功能，以避免个别节点因承载过多受保护会话而长期处于高负载状态，进而影响整体系统的稳定性。
本章将结合具体网络场景，阐述各个负载均衡技术的典型组网。
服务器负载均衡主要应用于数据中心和各类业务系统中，用于解决单台服务器处理能力有限的问题。当用户访问量持续增长时，单一服务器难以承受大量并发请求。通过SLB技术将用户请求按策略分发至多台后端服务器，可实现业务横向扩展；同时结合健康检查机制对后端服务器状态进行监测，在节点故障或异常时自动切换流量，从而提升业务系统的性能、可用性与业务连续性。
服务器负载均衡技术广泛应用于互联网企业、电子商务平台、金融业务系统、政府门户网站、教育与医疗信息系统以及各类大型数据中心等高访问量场景。
服务器负载均衡设备通常部署在客户端与服务器集群之间，位于数据中心业务区入口处。典型位置为服务器区的汇聚层或接入层（接入交换机上联侧）。设备对外发布虚服务器地址（VSIP），为用户提供统一的业务访问入口。
如下图所示，客户端访问流量经互联网进入数据中心网络，经边界/核心交换设备到达负载均衡设备。负载均衡设备依据配置的调度策略将请求分发至后端服务器集群，实现访问流量的负载分担。
图37 服务器负载均衡典型组网图
建议采用双机或集群方式部署负载均衡设备，以避免单点故障对业务造成影响。在调度策略选择方面，可根据业务需求选择四层或七层负载均衡模式，以兼顾转发性能与应用层处理能力。同时，建议合理配置服务器健康检查、会话保持等功能以保障访问稳定性。对于高并发或加密流量占比较高的业务场景，可结合SSL卸载与应用安全防护能力进行综合规划，以提升整体性能与安全性。
出链路负载均衡主要应用于具有多条运营商出口链路的网络环境，用于解决单一出口带宽不足、出口拥塞以及链路故障导致的业务中断和访问体验下降等问题。通过部署出链路负载均衡，可以将用户出向流量分担至多条链路上，实现出口带宽的横向扩展和链路利用率提升；同时结合链路健康检测机制，在链路故障或质量劣化时自动切换出口链路，提升链路可用性与业务连续性。
出链路负载均衡技术广泛应用于企业园区网、分支机构互联网出口以及数据中心公网出口等场景，尤其适用于多运营商接入、关键业务上云访问，以及对公网访问质量要求较高的业务环境。
如下图所示，在多运营商链路场景下，内网用户访问互联网的出方向流量先到达负载均衡设备。设备依据配置的负载均衡策略选择合适的运营商出口链路进行转发，实现跨运营商链路的流量分担与出口带宽扩展。
如下图所示，在多运营商链路场景下，内网用户访问互联网的出方向流量先到达出链路负载均衡设备，设备依据配置的调度策略选择合适的运营商出口链路进行转发，实现跨运营商链路的流量分担与出口带宽扩展。
图38 出链路负载均衡典型组网图
建议先明确各出口链路的带宽大小、稳定性（是否易中断）、访问质量（如时延/丢包/抖动）以及业务定位（主用/均衡/备用），并结合带宽差异与链路特性选择合适的调度方式。为确保链路可用性和切换准确性，应对每条出口链路启用健康检测，并合理配置探测参数。
对于长连接业务或对出口路径变化敏感的业务，建议启用会话保持功能，并合理设置会话保持表项的超时时间，降低链路切换引发会话中断的风险。在业务调度策略上，可结合实际需求进行差异化选路：例如，关键业务优先走质量更高、时延更低的链路，大流量下载或更新类业务倾向选择带宽更大的链路；必要时对特定业务固定出口，以保障访问的连续性与稳定性。
在业务运行过程中，应持续监控各条链路的带宽利用率、时延、丢包率及切换次数。当链路长期处于高负载或频繁拥塞状态时，应及时进行带宽扩容或优化调度策略，以保证稳定、可预期的出口访问体验。
DNS透明代理技术主要适用于需要对DNS访问进行统一接管与调度的网络环境。此类环境的典型特征包括：终端侧DNS配置分散且不可控，DNS请求的目标地址可能不同（如指向多个公共DNS或运营商DNS），同时存在多条出口链路，需要按策略进行路径选择。通过在网络关键节点部署DNS透明代理技术，可对经过的DNS报文进行统一调度与转发，在无需改动终端配置的前提下，实现DNS请求的集中管理，以及出方向访问路径的智能选择。
在实际应用中，该技术常部署于企业园区网、教育与医疗行业接入网络、酒店/商场等大规模访客网络，以及终端类型复杂的办公网（含BYOD、哑终端与IoT终端）等场景。用于智能选择DNS出口，降低因终端配置不当导致的出方向流量分配不均问题。
DNS透明代理一般部署在DNS报文的必经之路上，通常位于用户侧到外部网络的出口位置，可根据网络现状选择串联部署或旁挂部署。设备在该位置对DNS查询流量进行统一识别与接管，使终端无需修改DNS配置，即可按策略将DNS解析请求转发到指定的DNS服务器。
如下图所示，园区网出口同时接入多条ISP链路，并在出口处串联部署负载均衡设备，开启DNS透明代理功能。设备会对终端发起的DNS请求进行智能调度，将域名解析请求分别转发至不同ISP的DNS服务器。各ISP的DNS服务器通常会优先返回位于其自身网络内的Web服务地址。终端获得不同的解析结果后，将业务访问流量从对应的ISP出口链路转发，从而在多ISP链路场景下实现基于DNS的跨链路智能调度。
图39 DNS透明代理典型组网图
负载均衡设备建议部署在园区网络到Internet的出口位置，必须确保DNS请求与DNS应答都经过同一台设备。一旦DNS应答绕行该设备，客户端可能会收到非预期DNS服务器返回的应答，从而引发丢包或业务不稳定。若采用旁挂部署方式，在上线前必须验证DNS请求和应答报文能稳定地被引流到负载均衡设备上处理。
DNS透明代理地址建议使用0.0.0.0/0，以避免因终端DNS配置不一致造成部分请求未被代理，同时建议通过负载均衡策略对生效范围进行精细控制：可根据源IP地址、ACL、域名等条件匹配。无需参与调度的DNS流量，可为其配置“跳过当前DNS透明代理动作”或“直接转发”动作，避免对不相关业务造成干扰。
调度算法应结合业务需求进行选择，如果侧重总体出链路的带宽均衡，可采用随机或加权轮询算法，并按各链路带宽能力设置合理权值；如果侧重访问路径的稳定性，希望同一终端尽量固定走同一出口链路，则更适合采用源IP哈希算法并配合会话保持机制；如果需要根据实时链路负载做动态调整，则可采用带宽算法或最大带宽算法，以便随链路压力变化自动调整部分解析请求。
同时，建议启用对出口链路及各DNS服务器的健康检测功能，实时监测链路和DNS服务的可用性。
入链路负载均衡主要适用于企业对外发布业务且同时接入多条运营商线路的场景。企业租用不同ISP的链路，并分别配置可访问的公网地址，希望外部用户优先通过距离更近、同运营商或同地域的链路接入，从而分担单条链路的压力，降低跨网访问时延。同时，当某条链路或对应业务入口发生故障时，入链路负载均衡可以自动将新建连接引导至其他可用链路，保障业务连续性。
该技术多用于各类对公网提供服务的系统与平台，例如企业官网、门户网站、电商平台、对外API服务、邮件系统、以及数据中心对外发布业务等。通过对外发布统一域名并结合DNS调度，可实现外部访问的就近接入。
入链路负载均衡通常部署在企业对外提供服务的网络边界位置，一般位于多条ISP链路的入口处，由负载均衡设备统一承载对外服务地址并执行智能DNS调度。该部署方式便于集中管理对外发布的业务地址，并可结合链路状态与业务健康状况进行智能调度。
如图所示，企业同时接入两条ISP链路，并在入口处部署负载均衡设备，对外仅发布一个统一的业务域名。企业在不同ISP链路上分别配置对应的公网业务访问地址（虚服务器地址）。当外部用户发起对该域名的DNS查询时，设备根据配置的策略，为同一域名返回不同的公网地址。外部用户随后访问该公网地址，业务流量由对应的ISP入链路进入企业网络，从而在多条链路之间实现入方向流量的负载分担。
图40 入链路负载均衡典型组网图
入链路负载均衡通过DNS将外部用户流量引导至不同的公网入口，因此需要完成权威DNS的规划：部署时需将该业务域名的权威DNS服务器地址指向负载均衡设备的公网地址，由负载均衡设备承担指定业务域名的权威解析，确保DNS查询由设备按策略响应。
对外发布的各公网入口地址应与对应ISP链路绑定，并确保相关NAT与回程路由策略一致：业务从某入口地址对应的ISP链路进入后，回包也应优先从同一链路返回，避免路径不对称带来的会话不匹配、源地址校验失败等问题。
建议启用健康检测功能，同时对链路连通性和业务入口的可用性进行检测，避免将新建连接引导至故障节点。
调度算法需结合业务需求进行选择：如果侧重整体入链路带宽的均衡分配，可采用随机或加权轮询，并根据各链路带宽能力设置合适权值；如果希望用户优先接入相同运营商或相同地域的链路，则宜选择就近性算法；若需要根据实时链路负载动态调整入口分配，则可采用带宽算法或最大带宽算法，根据链路压力变化自动调整入口流量。
全局负载均衡的应用场景为：同一业务分布在多个地域、多个数据中心部署，但对外只提供一个统一的访问域名。企业会在不同数据中心分别部署业务系统，并为每个数据中心配置独立的公网入口地址。在此基础上，引入全局负载均衡，由它在处理域名解析请求时，根据用户所在地域、接入运营商以及各数据中心的健康状态和负载情况，为同一个业务域名选择并返回最合适的数据中心入口地址。这样，用户会自动被引导到距离更近或网络质量更好的数据中心，各数据中心之间能够协同分担访问压力，当某个数据中心出现故障时，流量还能自动切换到其他正常的数据中心，从而在统一入口的前提下，同时实现就近接入、跨数据中心负载分担和快速容灾切换。
该技术常应用于跨地域部署的企业网络、大型电商平台、门户网站，以及“两地三中心”等多数据中心场景。
全局负载均衡设备通常部署为业务域名的权威DNS服务器，作为企业对外域名的统一调度入口。
如下图所示，企业分别部署数据中心A和数据中心B：各数据中心内部部署本地SLB设备，承载本数据中心的业务入口地址（虚服务器地址），并将进入本数据中心的业务流量分发至后端服务器集群；同时，各数据中心入口部署GSLB设备，由其作为该业务域名的权威DNS服务器，负责全局调度。GSLB根据就近性、运营商以及健康检测结果等因素，为同一域名返回最合适的数据中心业务入口地址，外部用户据此访问距离自身最近或质量最优的数据中心。
图41 全局负载均衡典型组网图
全局负载均衡以全局智能DNS调度为核心，部署时应将业务域名的权威DNS服务器指向全局负载均衡设备，由其接管指定域名的权威解析，并根据策略返回不同数据中心的入口地址。
建议对外发布的数据中心入口与其出口链路、NAT策略与回程路由等保持一致：业务从某数据中心的入口进入后，回包应优先从该数据中心对应链路返回，避免路径不对称带来的会话不匹配、源地址校验失败等问题。
建议启用健康检测功能，同时监控数据中心链路连通性和业务入口可用性。当链路或业务入口异常时，立即停止返回对应的业务入口地址，避免将新流量引导至故障节点，从而保障整体业务可用性。
调度算法需结合业务目标进行选择：若以优化用户访问体验为主，建议采用按地域、运营商的就近性调度；若以多数据中心间的负载分担为主，可采用加权轮询算法，并根据各数据中心的业务处理能力合理设置权值。
支持
