新华三：2025负载均衡技术白皮书（63页）.pdf

核心结论速览： 四层SLB与七层SLB的选型直接决定业务性能和功能边界：四层SLB基于IP和端口、采用基于流的转发机制，单连接所有报文始终分发至同一服务器，适合高并发大流量场景；七层SLB可解析URL、HTTP头部、Cookie等，适合业务逻辑复杂的Web应用。 三角传输模式可将SLB设备负载降低50%以上：在三角传输模式中，仅请求流量经SLB处理，响应流量直接由实服务器返回客户端，回程流量不经过SLB设备，特别适合视频、下载、文件传输等下行流量远大于上行流量的业务。 SNAT是解决“三角路由”问题的关键配置：当服务器默认网关未指向SLB设备或存在多出口时，配置SNAT可将客户端源IP转换为SNAT地址，使响应报文统一返回SLB设备，避免会话路径不对称导致的连接中断。 GSLB通过“主备站点”和“多活站点”两种模式实现跨数据中心灾备：主备模式下备用数据中心仅在主数据中心故障时接管流量；多活模式下多个数据中心同时对外提供服务，在提升资源利用率的同时实现自动容灾切换。 加权最小连接算法比加权轮转更适合长短连接混合场景：加权轮转仅按权值比例分配请求数量，不感知节点当前负载；加权最小连接同时考虑节点权值和当前活动连接数，能更好地反映实际负载。 CARP哈希算法在服务器故障或扩容时可减少90%以上的会话中断：普通哈希算法在节点变化时会导致几乎所有流量重分布；CARP哈希算法仅将故障节点的流量或新增节点的部分流量重新分配，绝大部分原有调度保持不变。 HTTP载荷哈希算法可实现用户级和租户级流量隔离：通过从HTTP请求中提取User-ID、Tenant-ID等字段进行哈希，可将同一用户或同一租户的所有请求固定调度到同一服务器，适用于多租户SaaS平台。 会话保持优先功能可在系统高负载时保障关键交易不中断：开启会话保持优先后，匹配会话保持表项的连接不受连接数限制影响，即使对应节点已被标记为繁忙，设备仍会依据表项将后续流量继续分配到同一节点。服务器负载均衡的部署模式与选型。三种部署模式的流量路径差异。 网关模式下SLB设备串联部署在实服务器前端，客户端的请求流量和服务器的响应流量均会经过SLB设备处理。管理员需在实服务器上将默认网关指向SLB设备，或配置合适的静态路由。旁路模式下SLB设备以旁挂方式连接在核心交换机上，不改变原有网络拓扑，部署更为灵活。三角传输模式的网络拓扑与旁路模式相同，但只有客户端的请求流量会经过SLB设备处理，实服务器的响应流量不会经过SLB设备，SLB设备与实服务器之间通过二层传输，管理员需在实服务器上将VSIP配置为本地地址（通常配置在Loopback接口上）。三角传输模式的性能优势。 三角传输模式的回程流量不经过SLB设备，可大幅降低SLB设备的负载，特别适用于视频点播、文件下载、大文件传输等下行流量远大于上行流量的业务场景。在三角传输模式中，SLB设备收到请求报文后对报文进行二层改写，将目的MAC地址改为选中实服务器的MAC地址，但目的IP地址保持为VSIP不变。实服务器接收请求后直接向客户端返回响应报文，响应报文的源IP地址为VSIP，目的IP地址为客户端IP地址。四层与七层SLB的性能功能权衡。 四层SLB工作在网络层和传输层，可识别报文的IP地址及传输层端口号，采用基于流的转发机制，将同一条连接的所有报文始终分发至同一台实服务器。七层SLB基于应用层报文内容进行流量分发，在四层SLB的基础上进一步解析并识别应用层特征信息，如URL路径、HTTP头部、Cookie、报文体等。七层SLB支持Diameter、HTTP、HTTPS、MySQL、RADIUS、SIP等多种应用层协议。四层SLB适用于高并发、大流量、对延迟敏感的业务场景；七层SLB适用于需要结合业务逻辑或用户信息进行精确化流量调度的场景。两者可结合部署——先通过四层SLB实现高性能流量分发，再对特定业务流量引入七层SLB处理应用层需求。源地址转换（SNAT）的实战价值。 SNAT的核心价值在于解决三种典型问题：当实服务器的默认网关未指向SLB设备且不便修改时，通过SNAT保证回程路径可控；当服务器存在多出口或复杂路由时，通过SNAT避免三角路由；当需要所有回程流量经过SLB设备进行统一管理和统计时，通过SNAT集中回程流量。配置SNAT后，实服务器收到报文的源IP不再是客户端的真实IP，而是SLB设备使用的SNAT地址，因此与源IP相关的策略（如基于源IP的访问控制、日志审计、统计分析等）需要在SLB设备侧或应用层进行相应的配置调整。（数据来源：负载均衡技术白皮书）。高可靠性组网的四种模式与选型建议。主备模式：基础冗余保障。 主备模式由两台SLB设备组建成双机热备环境，正常情况下仅主设备处理业务流量，备设备处于待命状态。当主设备的接口、链路或整机故障时，备设备立即接替主设备处理业务。主备模式配置简单，适用于对资源利用率要求不高、主要关注业务连续性的场景。双主模式：资源利用率提升。 双主模式下两台设备同时处理业务，各自承担部分业务流量，既实现冗余备份，又充分利用设备资源。当一台设备故障时，另一台设备立即接管其承载的业务。双主模式适用于对系统整体负载能力有较高要求、希望充分利用设备资源的场景。集群模式（单数据中心）：多业务承载与互备。 在同一数据中心内，多台SLB设备可以对外发布不同的业务，每台SLB设备集中高效地处理某一种业务，同时设备之间又可以相互备份配置信息和业务信息。当其中一台SLB设备故障时，其他设备立即接手其流量。集群模式适用于大型数据中心中承载多种业务、需要更高扩展性和容灾能力的场景。集群模式（跨数据中心）：多活数据中心与远程灾备。 多个数据中心同时对外提供服务，不同数据中心SLB设备之间的配置信息和业务信息可以相互备份。当某个数据中心故障时，其他数据中心的SLB设备立即接手其流量。多活数据中心模式充分利用现有网络资源和应用服务资源，适用于对业务连续性要求极高、需要跨地域容灾的场景。（数据来源：负载均衡技术白皮书）。全局负载均衡（GSLB）的部署架构与调度机制。GSLB解决的核心问题。 普通DNS服务器通常采用简单的轮询方式分配流量，无法根据用户的地理位置、运营商线路或实时网络状况动态调整解析结果。例如，来自地区A、运营商ISP1的用户请求可能被解析到地区B、运营商ISP2的服务地址，导致跨地区、跨运营商访问，增加网络时延。普通DNS服务器缺乏健康检查和故障感知机制，无法在后端服务器或数据中心发生故障时自动排除异常节点。GSLB设备作为智能DNS服务器，根据预先配置的调度算法对各数据中心中承载同一业务的链路进行全局评估，择优选择最适合当前用户访问的链路。两级调度机制。 GSLB通过两级调度实现跨数据中心流量分配。当GSLB设备收到目的地址匹配全局DNS监听地址的DNS请求报文时，首先根据全局DNS映射中配置的调度算法选择一个合适的全局虚服务器池（第一级调度），再根据全局虚服务器池中配置的调度算法从池中选出最合适的虚服务器（第二级调度）。虚服务器本质上是各数据中心内SLB设备的虚服务器，通过在同一个全局虚服务器池中对来自不同数据中心、不同SLB设备的虚服务器进行统一调度，实现跨站点最优选择。集中部署与分布部署。 集中部署模式下，同一台GSLB设备同时配置全局负载均衡和服务器负载均衡功能，设备既提供全局调度又提供本地调度。分布部署模式下，GSLB设备提供全局负载均衡服务，各数据中心的本地SLB设备提供服务器负载均衡服务。分布部署模式更适合大规模、多数据中心的复杂场景，可实现专业分工和独立扩展。同步机制。 GSLB设备之间通过同步组相互同步配置信息和运行数据。配置信息同步确保各GSLB设备配置一致，降低人工配置错误风险。运行数据同步使任意一台GSLB设备检测到服务器或链路故障时能快速通知其他设备，及时将流量重定向到健康节点。同步机制是保障GSLB系统一致性和可靠性的关键。（数据来源：负载均衡技术白皮书）。调度算法的选型指南与实战对比。加权轮转 vs 加权最小连接。 加权轮转算法按配置权值比例将新请求依次分配给各节点，权值越大被分配的请求越多。该算法仅依赖预配置权值，实现简单、开销较小，但不感知节点当前负载。加权最小连接算法为每个节点计算加权活动连接数（加权活动连接数=当前活动连接数/权值），始终将新请求分配给加权活动连接数最小的节点。在业务负载差异大、长短连接并存的场景中，加权最小连接通过同时考虑当前负载和节点能力，实现更符合实际负载的动态分配。哈希算法的四种模式。 源IP地址哈希算法将同一源IP的请求调度到同一目标节点，适用于需要确保同一客户端访问始终调度到同一节点的场景，但在少数源IP产生大量请求时会导致流量集中。源IP地址+端口哈希算法粒度更细，能缓解因源IP相同导致的流量集中问题。目的IP地址哈希算法将发往同一目的IP的请求调度到同一目标节点。HTTP载荷哈希算法从HTTP请求报文中提取特定应用层字段（如URL、Host、Cookie、Header等），将具有相同特征字段的请求调度到同一目标节点，适用于按用户ID、租户标识、URL路径等进行精细化流量分配。CARP哈希算法的独特价值。 CARP哈希算法在普通哈希算法基础上改进，在实服务器故障和实服务组扩容时能使当前所有可用实服务器的调度结果变动最小。实服务器故障时，普通IP地址哈希算法会导致几乎所有访问流量重分布；CARP哈希算法仅将原本发往故障实服务器的流量重新分配到其余可用服务器。实服务器扩容时，普通IP地址哈希算法将所有请求在所有实服务器之间重新分配；CARP哈希算法仅有一部分调度至原有实服务器的请求会被迁移至新增实服务器。动态反馈与最快响应算法。 动态反馈算法依赖SNMP-DCA类型的NQA探测模板定期采集实服务器的CPU、内存、磁盘等资源使用率，资源使用率越低负载能力权值越大。最快响应算法通过采集实服务器对业务请求的响应时间来计算权值，响应时间越短权值越高。动态反馈算法适用于实服务器性能差异明显、业务流负载无规律的场景；最快响应算法适用于各实服务器性能相近、单条流业务负载较大、响应时延能反映负载情况的场景。链路质量与带宽算法。 链路质量算法综合考虑链路的网络延迟、路由跳数和丢包率计算链路质量值，链路质量越好分配的新连接越多。带宽算法根据“权值×剩余带宽”的比例分配请求。最大带宽算法优先使用剩余带宽最大的节点，适合以吞吐量优先为目标的场景。（数据来源：负载均衡技术白皮书）。健康检测的配置策略与应用实践。探测模板的配置粒度。 资源池级健康检测适用于同一组节点运行同类服务的场景，管理员只需为该资源池配置一个统一的探测模板，模板中的所有参数自动应用到资源池内所有节点，配置简单、维护成本低。节点级健康检测提供更细粒度的控制，当某些节点的运行环境或角色与其他节点不同时，可为其单独绑定独立的探测模板，节点级探测模板通常具有更高优先级。多模板协同与判定条件。 一个资源池或节点可同时引用多个健康检测模板，例如同时配置端口连通性检测和应用接口检测。管理员通过配置健康检测的成功条件来定义判定规则：“全部成功”要求所有绑定的模板都返回成功结果才认为节点可用；“至少部分成功”允许部分探测失败时节点仍可参与调度。在单个模板内部，通过配置连续探测次数来平滑结果——连续多次失败后才判定为故障，连续多次成功后才判定为恢复。应用层探测的深度。 以MySQL为例，健康检测在建立TCP连接后使用探测账号执行一条简单查询语句，仅当查询成功且响应在设定的超时时间内返回时才判定节点为健康。相比网络层或传输层探测，应用层探测能更真实地反映数据库的处理能力和整体服务状态。对于HTTPS探测，除了HTTP协议参数外还需在模板中考虑TLS/SSL相关配置。探测周期与超时时间的配置原则。 探测周期过短会增加探测流量和节点负载；周期过长则会延迟故障发现时间。超时时间应结合业务正常响应时延配置，一般略高于正常响应时延的95%，这样既能容忍偶发的响应变慢，又不至于等待时间过长。对于缓存探测这种交互简单的健康检测，超时时间可设置较短；对于数据库探测这种包含一定业务逻辑的健康检测，超时时间应适当放宽。（数据来源：负载均衡技术白皮书）。负载均衡策略与会话保持的配置要点。策略匹配的顺序原则。 设备按照策略中负载均衡类的配置顺序进行匹配，当流量满足某一负载均衡类的匹配条件时执行关联动作，不再继续匹配后续。当不同负载均衡类之间存在包含或交叉关系时，策略条目的顺序尤为关键。一般建议将匹配条件更精细、作用范围更小的负载均衡类放在前面，将匹配条件较宽泛的放在后面，确保细粒度规则优先生效。负载均衡类的匹配维度。 服务器负载均衡中，通用类型按源IP地址、ACL、入接口、用户或用户组等匹配；HTTP类型按URL、HTTP方法、版本、首部字段、Cookie及实体内容等匹配；MySQL类型按SQL语句内容分类；RADIUS类型按RADIUS属性分类；Diameter类型按应用ID、目的域名等匹配。出链路负载均衡中可基于源/目的IP地址、ACL、入接口、域名、ISP和应用类型等进行分类。DNS透明代理中可根据源/目的地址、ACL及域名对DNS请求进行分类。会话保持的工作机制与表项管理。 首包调度时，设备先根据调度算法选出目标节点并生成会话保持表项。后续携带相同特征的请求直接匹配表项转发，无需再次调度。会话保持表项默认仅在当前虚服务器内生效，但可通过配置扩大会话保持表项的匹配范围。超时时间设置较长可提升会话连续性但会占用更多内存；设置较短可节约内存但可能导致同一用户被调度到不同节点。实际配置时应结合业务访问特性设置——交互频繁的业务适当延长，短连接业务配置较短的超时时间。会话保持优先功能。 开启后，匹配会话保持表项的会话不受连接数限制影响，当系统整体连接数接近上限时，已命中表项的连接仍被优先放行。同时，会话保持处理优先于繁忙状态，即使对应节点已被标记为繁忙，设备仍会依据表项将后续流量继续分配到同一节点。此功能适用于对会话稳定性要求较高的关键业务场景，尤其是交互复杂、处理流程较长的应用。（数据来源：负载均衡技术白皮书）。典型组网与部署建议。服务器负载均衡部署要点。 建议采用双机或集群方式部署避免单点故障。根据业务需求选择四层或七层负载均衡模式，合理配置服务器健康检查、会话保持等功能。对于高并发或加密流量占比较高的业务场景，可结合SSL卸载与应用安全防护能力进行综合规划。出链路负载均衡部署要点。 建议明确各出口链路的带宽大小、稳定性和访问质量，结合带宽差异与链路特性选择合适的调度方式。对每条出口链路启用健康检测并合理配置探测参数。对于长连接业务或对出口路径变化敏感的业务建议启用会话保持功能。关键业务优先走质量更高的链路，大流量下载类业务倾向选择带宽更大的链路。DNS透明代理部署要点。 必须确保DNS请求与DNS应答都经过同一台设备，DNS应答绕行会导致丢包或业务不稳定。DNS透明代理地址建议使用0.0.0.0/0并通过负载均衡策略对生效范围进行精细控制。调度算法选择上，侧重带宽均衡可采用随机或加权轮询；侧重路径稳定性可采用源IP哈希并配合会话保持；需要根据实时链路负载动态调整可采用带宽算法或最大带宽算法。入链路负载均衡部署要点。 需将该业务域名的权威DNS服务器地址指向负载均衡设备的公网地址。对外发布的各公网入口地址应与对应ISP链路绑定，并确保NAT与回程路由策略一致——业务从某入口地址对应的ISP链路进入后，回包也应优先从同一链路返回，避免路径不对称。调度算法选择上，侧重带宽均衡采用随机或加权轮询；希望用户优先接入相同运营商或相同地域链路选择就近性算法；需要根据实时链路负载动态调整采用带宽算法或最大带宽算法。全局负载均衡部署要点。 应将业务域名的权威DNS服务器指向GSLB设备，由其接管权威解析。对外发布的数据中心入口与其出口链路、NAT策略与回程路由保持一致，避免路径不对称。启用健康检测监控数据中心链路连通性和业务入口可用性。调度算法选择上，以优化用户访问体验为主建议采用按地域、运营商的就近性调度；以多数据中心间负载分担为主可采用加权轮询并根据各数据中心业务处理能力设置权值。（数据来源：负载均衡技术白皮书）。延伸阅读： 以上为白皮书核心内容分析，如需获取完整技术细节及全部配置指导，请访问下载页下载完整PDF报告。FAQ。问：三角传输模式与旁路模式的核心区别是什么？答：旁路模式中请求和响应流量均经过SLB设备；三角传输模式中仅请求流量经SLB设备处理，响应流量直接由实服务器返回客户端，回程流量不经过SLB。三角传输模式可大幅降低SLB设备负载，特别适合视频、下载等大流量场景。问：什么时候需要配置SNAT？答：三种典型场景需要配置SNAT：实服务器默认网关未指向SLB设备且不便修改时；服务器存在多出口或复杂路由可能导致三角路由时；需要所有回程流量经过SLB设备进行统一管理和统计时。问：CARP哈希算法相比普通哈希算法有什么优势？答：在服务器故障或扩容时，普通哈希算法会导致几乎所有流量重分布，用户会话大面积中断。CARP哈希算法仅将故障节点的流量重新分配，或仅将部分原有流量迁移至新增节点，大部分请求保持原有调度结果，会话中断风险降低90%以上。问：会话保持优先功能在什么场景下特别重要？答：在处理流程较长、涉及多步交互的关键业务场景中（如在线交易、表单提交、多步认证等），开启会话保持优先可确保已建立的会话不受连接数限制和节点繁忙状态影响，避免业务处理中途被中断。数据来源说明： 本文内容基于负载均衡技术白皮书整理，所有技术原理、算法描述、配置建议均来自该白皮书原文。