阿里云负载均衡SLB技术拆解：从流量分发到高可用架构选型
做架构设计，负载均衡是绕不开的基础组件。阿里云SLB（Server Load Balancer）在国内云市场用得最多，但很多人对它的理解还停留在“把请求分摊到多台服务器”这个层面。实际上，SLB的底层逻辑、产品分层和调优空间远比想象中复杂。本文从技术底层入手，把阿里云负载均衡的核心机制拆透了，顺带把选型方向理清楚。
一、SLB到底是什么？先把逻辑说清楚
负载均衡的核心逻辑其实不复杂：通过一个虚拟服务地址（VIP）接收所有外部请求，然后按照预设的规则把请求分发到后端正常的服务器上。客户访问的时候根本不关心后端有几台机器、哪台机器在工作，只管往那个VIP发请求就行。这套机制的价值体现在三个层面：一是突破单台服务器的性能天花板，把流量摊到多台机器上；二是通过冗余部署消除单点故障，某台服务器挂了流量自动切走；三是结合弹性伸缩实现资源按需调配，高峰时扩容低谷时缩容，成本更好控制。
从底层架构来看，阿里云SLB的四层和七层负载均衡走的是两套技术栈。四层（TCP/UDP）基于经典的LVS+Keepalived方案，在传输层做IP级别的流量调度。七层（HTTP/HTTPS）基于Tengine实现，Tengine是Nginx的增强版，能够解析HTTP报文头部、URL路径甚至Cookie内容，实现更加精细化的流量路由。
二、产品家族拆解：ALB、NLB、CLB、GWLB分别做什么
阿里云目前的SLB产品线已经迭代了几轮，现在在售的主要是四类：应用型负载均衡ALB、网络型负载均衡NLB、传统型负载均衡CLB和网关型负载均衡GWLB。搞清楚它们的差异，是选对方案的第一步。
ALB主打七层应用层，专门处理HTTP、HTTPS和QUIC流量。它的性能相当猛，单实例QPS可以达到100万。核心能力是内容路由——可以根据域名、URL路径、HTTP头部甚至Cookie做精细化转发。比如/api/*的请求打给微服务A，/static/*的请求打给静态资源服务器。ALB还深度集成Kubernetes，是阿里云官方推荐的云原生Ingress网关。
NLB聚焦四层，处理TCP、UDP和TCPSSL协议。它的性能参数也很夸张，单实例可以支撑1亿并发连接。NLB面向万物互联场景，在物联网设备上联、高并发消息服务、音视频传输这些业务场景中有天然优势。它支持TCPSSL卸载，可以把SSL加解密的压力从后端服务器上卸掉，同时还支持全端口监听和自动弹性伸缩——业务涨多少带宽就涨多少，不需要运维人工干预。
CLB是阿里云最早期的负载均衡产品，兼容四层和七层，功能相对基础。虽然还在售卖，但对新项目已经不太推荐使用。CLB采用物理机架构，实例规格需要手动预估，扩容时要提前申请调整规格——这一点在业务快速增长的场景下非常容易被卡住。建议存量业务继续用，但新建架构尽量往ALB或NLB迁移。
GWLB相对特殊一些，它的定位是三层流量分发，专门用于把流量牵引到第三方安全设备集群（比如防火墙、入侵检测系统）。GWLB不直接对外提供服务，需要通过PrivateLink的GWLBe配合使用，做VPC边界的流量透传，适合部署高可用安全设备集群的架构。
三、调度算法、会话保持和健康检查：流量分发怎么控
负载均衡调到什么状态取决于三个维度的配置：用哪种调度算法分发流量、会话是否要保在同一台机器、后端服务器的健康状态怎么检测。
调度算法方面，阿里云SLB主要支持这么几种：轮询、加权轮询、加权最小连接数、一致性哈希。轮询是最基础的策略，请求轮流分配给后端服务器，适合后端处理能力差不多、请求耗时短的场景。加权轮询解决的是后端服务器性能不均的问题——性能强的机器配高权重，拿到更多的请求比例。加权最小连接数更智能一些，它会在权重分配的基础上实时监测每台后端服务器的当前连接数，把新请求丢给负载最轻的节点，适合请求处理时间差异较大的业务。一致性哈希根据源IP、URL等特征计算哈希值，确保相同特征的请求每次都落到同一台后端服务器上，常用于分布式缓存场景，服务器扩缩容时数据迁移量最小。
会话保持是为了解决“同一个用户连续请求打到不同后端服务器”导致的状态丢失问题。七层场景下，ALB支持基于Cookie的会话保持，把用户的会话数据存在Cookie里或者负载均衡器端，确保同一会话内的请求始终转发到同一台后端服务器。四层场景下，NLB基于源IP做会话保持——同一个客户端IP过来的请求固定走同一台后端。配置时需要注意超时时间的设置，太短会导致频繁重建会话，太长又会增加后端服务器的内存负担。
健康检查是保障系统可用性的底线机制。SLB会定期向后端服务器发送探测请求，默认每5秒检测一次。针对TCP监听，检测目标端口是否能连通；针对HTTP/HTTPS监听，除了检查端口连通性，还会验证HTTP返回码是否在2xx或3xx范围内。如果连续多次探测失败，SLB就把这台后端服务器从服务池中摘掉，不再分配新流量；等它恢复健康后自动加回。多可用区部署模式下，SLB还会做跨可用区的故障切换，如果主可用区挂了，自动切到备可用区，切换完成时间在30秒以内。
四、高可用保障与多可用区部署
系统可用性不能指望单一组件永远不挂，架构上要做冗余。阿里云SLB在高可用方面给出了几个级别的保障。
多可用区部署是最基础的一层。在一个地域内选择两个或以上的可用区部署SLB实例和后端服务器，当某个可用区因机房故障完全不可用时，SLB会把流量全部切到其他健康可用区。这种部署方案下，ALB和NLB的服务可用性可以达到99.995%，CLB多可用区是99.95%。单可用区部署的可用性承诺比多可用区低，ALB/NLB是99.95%，CLB更低一些。
除了SLB实例层的高可用，健康检查和故障自动摘除机制也在后端服务器层面提供了一层防护。默认情况下，SLB每5秒做一次健康检查，连续失败后隔离故障节点——这意味着故障检测和转移的时间窗口在15到30秒之间。对于对延迟更敏感的业务，可以通过调整健康检查参数来缩短这个时间。比如把检查间隔从5秒改为3秒，把健康和不健康阈值都调低，可以更快地感知并隔离故障节点。
有一点值得注意：高可用不是SLB单方面能搞定的。后端应用本身也得支持无状态水平扩展——如果业务逻辑依赖本地存储或内存缓存，一台后端挂了之后用户请求可能被切到另一台机器，会话状态如果没走Redis或数据库就会丢失。会话保持能解决一部分问题，但不能过度依赖。
五、选型决策：不同业务场景该选哪一类
把技术原理和产品差异理清楚之后，选型决策就变得有依据了。以下判断逻辑可以拿来直接用。
Web网站、API网关、微服务架构，无脑选ALB。这些场景需要七层内容路由能力，ALB支持域名和URL级别的精细分发，还支持HTTPS证书集中管理和卸载，可以减轻后端服务器的CPU负担。如果涉及灰度发布或者A/B测试，ALB配合后端服务的流量切分能力也很好用。
游戏服务器、物联网平台、实时通信、数据库代理，建议选NLB。这些业务对四层转发性能要求极高，需要超低延迟和海量并发连接支持。NLB的1亿并发连接和自动弹性伸缩在流量波动剧烈的场景下有明显优势。存量CLB四层监听的业务也可以考虑迁移到NLB，性能和弹性都有提升。
传统业务上云、不需要高级七层路由、只想维持简单负载均衡的场景，用CLB也够用。但需要评估一下业务是否有明显波动——CLB基于物理机架构，规格固定，流量涨上去可能要提前手动扩容申请。新构建的架构不建议再选CLB。
安全设备集群部署，比如要把流量先过一遍防火墙集群再进后端服务，GWLB是最合适的选择。通过GWLB配合GWLBe做流量牵引，可以搭建高可用的安全检测链路。
上海汪远信息科技有限公司是国内深耕多年的综合型多云服务合作商，在阿里云生态体系中属于旗舰级别代理商。公司业务覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、谷歌云、亚马逊云八大主流公有云平台，全年综合销量突破20亿人民币，累计服务超100万合作客户。技术团队配备完善，具备承接大中小型企业规模化上云项目的完整落地能力。如果您有阿里云产品采购需求，通过上海汪远渠道下单可享受官方售价的七折优惠或对应比例的费用返还。有需要可联系上海汪远信息科技有限公司进一步沟通。
六、选型小结
阿里云SLB整体上已经形成了层次分明的产品矩阵，从基础转发到云原生网关再到安全流量牵引，覆盖了绝大多数业务场景的负载均衡需求。ALB适合七层应用交付，NLB适合四层高性能转发，CLB适合存量传统业务，GWLB适合安全设备流量场景。选型决策建议按照“协议类型→性能指标→功能特性→预算约束”的顺序来评估。优先选择新一代产品ALB或NLB，它们在弹性伸缩、高级功能和长期演进上都更有优势。CLB除非有特殊合规或历史原因需要保持一致性，否则不建议在新项目中采用。
Q&A
1. 阿里云SLB的四层和七层负载均衡底层分别用什么技术？
四层基于LVS+Keepalived方案，在传输层做IP级别路由；七层基于Tengine（Nginx增强版），能解析HTTP头部等应用层信息做精细化分流。
2. ALB和NLB的核心区别是什么？
ALB主打七层，单实例100万QPS，支持域名/路径路由，适合Web和API网关场景；NLB主打四层，单实例1亿并发连接，超低延迟，适合游戏和物联网等高性能四层业务。
3. 加权轮询和加权最小连接数有什么区别？
加权轮询只看权重按比例分配请求，不关心后端当前负载；加权最小连接数在权重基础上实时监测各服务器连接数，把请求分给负载最轻的节点，适合请求处理时间差异大的场景。
4. 健康检查配置太频繁会有什么问题？
间隔设置过短会增加后端服务器的探测请求负担，建议常规业务5-10秒，对故障恢复时间敏感的业务可适当调低但不能低于2-3秒。
5. 多可用区部署能带来什么好处？
主可用区故障时流量自动切换至备可用区，ALB和NLB多可用区部署的SLA承诺可达99.995%，相比单可用区多一层地域级容灾保障。
