SLB负载均衡配置完全指南
在分布式架构中，负载均衡（SLB，Server Load Balancer）是保障系统高可用、高并发的核心基础设施。它通过将客户端请求合理分发至后端多台服务器，不仅能避免单点故障，还能充分利用服务器资源，提升业务处理能力。本文从负载均衡类型对比、四层与七层架构差异入手，逐步深入健康检查、会话保持、安全防护及监控配置等关键环节，结合高可用Web集群搭建实验，完整呈现SLB配置的全流程与最佳实践。
一、负载均衡类型对比：CLB vs ALB vs NLB
主流云厂商提供的负载均衡服务通常分为三类：传统型负载均衡（CLB）、应用型负载均衡（ALB）和网络型负载均衡（NLB）。三者基于不同的网络层级和技术原理，适配不同的业务场景，需结合业务需求精准选型。
1.1 核心定义与技术原理
CLB（Classic Load Balancer，传统型负载均衡）：属于多层负载均衡，同时支持四层（TCP/UDP）和七层（HTTP/HTTPS）协议转发，基于传统硬件负载均衡技术演进而来，架构成熟稳定，适用于常规业务场景。
ALB（Application Load Balancer，应用型负载均衡）：专注于七层协议转发，基于应用层信息（如HTTP头部、URL路径）进行请求分发，支持更精细的路由策略，是当前互联网业务的主流选择。
NLB（Network Load Balancer，网络型负载均衡）：聚焦于四层协议转发，基于IP地址和端口进行请求分发，转发延迟极低，支持海量并发连接，适用于高性能、低延迟的业务场景。
1.2 关键特性对比
对比维度
CLB
ALB
NLB
支持协议
TCP、UDP、HTTP、HTTPS
HTTP、HTTPS、WebSocket、HTTP/2
TCP、UDP、TCP SSL
转发延迟
中等（10-50ms）
较低（5-30ms）
极低（1-5ms）
并发连接支持
百万级
千万级
亿级
路由能力
基础路由（基于IP:端口）、简单URL路由
精细路由（URL路径、域名、HTTP头部、Query参数）、重定向、Rewrite
仅基于IP:端口路由，支持会话亲和
SSL卸载
支持
支持（支持TLS 1.3、国密算法）
仅TCP SSL协议支持，无卸载能力
适用场景
传统Web应用、混合协议业务、中小规模并发
微服务架构、API网关、高并发Web应用、需要精细路由的业务
游戏服务器、视频直播、金融交易、高性能计算、低延迟业务
成本
中等
较高
高
1.3 选型建议
若业务为常规Web应用，无复杂路由需求，追求成本与稳定性平衡，选择CLB；
若业务基于微服务架构，需要按URL路径、域名分发请求，或对HTTPS安全性要求高，选择ALB；
若业务对延迟敏感，需要支撑海量并发连接（如游戏开服、直播峰值），选择NLB；
混合场景（如同时存在Web服务和高性能TCP服务）可组合使用多种负载均衡类型，通过域名解析区分业务入口。
二、四层 vs 七层负载均衡：协议选择与场景匹配
四层与七层负载均衡是SLB的核心架构差异，前者工作在OSI模型的传输层，后者工作在应用层。两者在协议支持、转发逻辑、适用场景上差异显著，正确选择是保障业务性能的关键。
2.1 核心差异解析
2.1.1 四层负载均衡（传输层）
工作在OSI模型第4层（传输层），仅关注IP地址和端口信息，不解析应用层数据。其核心逻辑是：接收客户端请求后，根据负载均衡算法（如轮询、加权轮询）将请求转发至后端服务器，转发过程中仅修改IP头部和TCP/UDP头部信息。
核心优势：① 转发效率高，延迟低（无需解析应用层数据）；② 兼容性强，支持所有基于TCP/UDP的协议（如MySQL、Redis、SSH）；③ 抗干扰能力强，不受应用层协议变化影响。
局限性：无法根据应用层信息进行精细路由，不支持SSL卸载（需后端服务器自行处理HTTPS解密），难以应对应用层异常（如应用崩溃但端口存活）。
2.1.2 七层负载均衡（应用层）
工作在OSI模型第7层（应用层），需解析应用层协议数据（如HTTP头部、URL、Cookie），基于应用层信息进行请求分发。其核心逻辑是：接收客户端请求后，先解析应用层数据，再根据预设的路由规则和负载均衡算法转发至后端服务器，支持对请求和响应数据进行修改（如SSL卸载、HTTP重定向）。
核心优势：① 支持精细路由（如按URL路径分发至不同后端服务）；② 具备应用层优化能力（如SSL卸载、Gzip压缩、缓存静态资源）；③ 可精准监控应用层状态（如HTTP响应码），提升故障检测准确性。
局限性：转发延迟高于四层（需解析应用层数据）；仅支持特定应用层协议（如HTTP、HTTPS）；对应用层协议变化敏感，需同步调整配置。
2.2 协议选择指南
业务类型
推荐负载均衡层级
推荐协议
核心原因
Web网站、API服务
七层
HTTP/HTTPS
需按URL路径、域名路由，支持SSL卸载和静态资源缓存，提升用户体验
游戏服务器（TCP/UDP）
四层
TCP/UDP
对延迟敏感，无需解析应用层数据，需支撑海量并发连接
数据库（MySQL、Redis）
四层
TCP
基于TCP协议通信，无需应用层解析，追求低延迟和高可靠性
视频直播、文件传输
四层
TCP/UDP
大流量、低延迟需求，四层转发效率更高，可避免应用层解析瓶颈
微服务架构（多服务入口）
七层
HTTP/HTTPS、WebSocket
需按路径、请求头分发至不同微服务，支持服务发现和负载均衡联动
2.3 混合部署场景
对于复杂业务系统，可采用“四层+七层”混合部署架构：① 外层使用四层NLB，负责承接海量并发请求，实现高可用负载均衡；② 内层使用七层ALB，负责对请求进行精细路由和应用层优化；③ 后端连接不同业务的服务器集群。这种架构兼具高并发处理能力和精细路由能力，适用于大型互联网平台（如电商、社交APP）。
三、健康检查机制：TCP/HTTP检查配置与故障转移
健康检查是SLB保障业务高可用的核心机制，通过定期检测后端服务器的运行状态，自动隔离故障节点，将请求仅分发至健康节点。合理配置健康检查参数，可提升故障检测的准确性和及时性，避免业务中断。
3.1 核心检查类型：TCP vs HTTP
3.1.1 TCP健康检查
基于TCP协议的端口探测，核心逻辑是：SLB向后端服务器的指定端口发送TCP连接请求，若能成功建立连接（收到SYN+ACK响应），则判定服务器健康；若连接失败或超时，则判定服务器异常。
适用场景：所有基于TCP协议的业务（如游戏、数据库、SSH服务），无需依赖应用层状态，配置简单、检测效率高。
关键配置参数：① 检查端口（需与业务端口一致）；② 检查间隔（默认5秒，建议根据业务特性调整，如高并发业务设为3秒）；③ 超时时间（默认2秒，需小于检查间隔）；④ 不健康阈值（默认3次，连续3次检查失败则标记为异常）；⑤ 健康阈值（默认2次，异常节点连续2次检查成功则恢复为健康）。
3.1.2 HTTP健康检查
基于HTTP协议的应用层探测，核心逻辑是：SLB向后端服务器的指定URL发送HTTP请求，根据响应码判定服务器状态（如200 OK为健康，4xx/5xx为异常），支持自定义请求头和响应内容校验。
适用场景：Web应用、API服务等基于HTTP/HTTPS的业务，可精准检测应用层状态（如应用崩溃但端口存活的情况）。
关键配置参数：① 检查路径（如“/health”，建议部署专门的健康检查接口，返回200 OK）；② 检查端口（HTTP默认80，HTTPS默认443）；③ 检查间隔、超时时间、健康/不健康阈值（同TCP检查）；④ 自定义请求头（如Host、Authorization，适配需要特定头信息的应用）；⑤ 响应码匹配（默认匹配200-399，可自定义）；⑥ 响应内容匹配（可选，需返回指定字符串才判定为健康，提升检测准确性）。
3.2 故障转移机制
当SLB检测到后端服务器异常时，会触发故障转移流程：① 标记异常节点为“不健康”，停止向其分发新请求；② 已建立的连接根据会话保持配置处理（如四层会话保持会等待连接断开，七层可主动终止连接）；③ 持续对异常节点进行健康检查，待其恢复健康后，重新将其纳入负载均衡池，恢复请求分发。
关键优化点：① 避免误判：合理设置检查间隔和阈值，如对于启动慢的应用（如Java应用），可增大健康阈值（如5次），避免刚启动的节点被误判为异常；② 适配高可用架构：后端服务器建议部署在不同可用区，SLB可跨可用区分发请求，即使单个可用区故障，也能通过其他可用区保障业务连续性；③ 告警联动：配置健康检查异常告警（如后端节点不健康数量≥1时告警），及时通知运维人员排查问题。
3.3 配置注意事项
健康检查接口需轻量化：HTTP健康检查接口应避免复杂逻辑和数据库查询，确保快速响应，避免因接口本身延迟导致误判；
HTTPS业务处理：若后端服务为HTTPS，HTTP健康检查需开启“HTTPS模式”，SLB会通过SSL握手后发送HTTP请求；
批量节点异常处理：若多个节点同时被标记为异常，需优先排查负载均衡配置（如安全组、监听规则）和网络问题，而非单个节点故障；
测试验证：配置完成后，手动停止后端某台服务器的业务进程，验证SLB是否能正确标记异常节点并停止分发请求；恢复进程后，验证节点是否能正常恢复。
四、会话保持配置：基于Cookie/源IP的持久化
在部分业务场景中（如用户登录、购物车操作），需要保证同一客户端的多次请求始终分发至同一后端服务器，这种需求称为“会话保持”（也叫会话持久化）。SLB支持基于Cookie和源IP两种会话保持方式，适配不同业务场景。
4.1 基于Cookie的会话保持（七层专属）
仅适用于七层负载均衡（HTTP/HTTPS），通过Cookie标记客户端与后端服务器的关联关系，实现会话保持。核心逻辑是：① 客户端首次请求时，SLB将请求分发至后端服务器，同时在响应中插入Cookie（记录后端服务器信息）；② 客户端后续请求会携带该Cookie，SLB根据Cookie信息将请求分发至对应的后端服务器。
两种Cookie实现方式
植入Cookie：由SLB主动在响应中插入Cookie（如“SLB_SESSIONID=xxx”），无需修改后端应用代码，配置简单，适用大多数Web应用。关键配置：Cookie过期时间（默认30分钟，可根据业务调整，如登录业务设为2小时）。
重写Cookie：后端应用已生成Cookie时，SLB对Cookie进行重写，在原有Cookie中添加后端服务器标记，适用于需要保留应用原有Cookie的场景。需配置“Cookie名称”（与应用Cookie一致），SLB会自动重写该Cookie的值。
适用场景：Web网站登录、电商购物车、需要维持用户会话状态的API服务，可精准绑定客户端与后端服务器，不依赖客户端IP（适配NAT环境下的多个客户端）。
4.2 基于源IP的会话保持（四层专属）
仅适用于四层负载均衡（TCP/UDP），通过客户端IP地址进行会话绑定，核心逻辑是：SLB将客户端IP地址进行哈希计算，根据哈希结果固定分发至某台后端服务器，同一IP的所有请求都会路由至同一节点。
关键配置参数：会话保持超时时间（默认5分钟，指客户端无请求后，会话保持关系的保留时间，超时后重新哈希分配）。
适用场景：游戏服务、SSH连接、数据库访问等基于TCP/UDP的业务，无需应用层支持，配置简单。局限性：① 不适用于NAT环境（多个客户端共用同一公网IP，会被分发至同一节点，导致负载不均）；② 客户端IP变化后（如切换网络），会话会中断，需重新建立连接。
4.3 配置最佳实践
会话保持并非必需：若业务为无状态服务（如静态资源服务、查询类API），无需开启会话保持，开启后会降低负载均衡的灵活性，可能导致部分节点负载过高；
过期时间合理设置：过短会导致会话频繁中断（如用户频繁重新登录），过长会导致节点故障后会话无法快速迁移（需等待超时），建议根据业务特性设置（如非登录业务设为10-30分钟，登录业务设为1-2小时）；
NAT环境适配：若客户端存在大量NAT设备（如企业内网用户），优先选择基于Cookie的会话保持（七层），避免基于源IP的会话保持导致负载不均；
故障节点会话处理：开启会话保持后，若后端节点故障，SLB会将该节点的会话分发至其他健康节点，但客户端可能需要重新进行状态验证（如重新登录），建议业务层实现会话共享（如使用Redis存储会话），提升用户体验。
五、安全防护：WAF集成、DDoS基础防护
SLB作为业务流量的入口，是网络攻击的主要目标。云厂商的SLB通常集成了WAF（Web应用防火墙）和DDoS基础防护能力，通过多层防护体系，保障业务安全稳定运行。
5.1 WAF集成：抵御Web应用攻击
WAF（Web Application Firewall）专注于抵御Web应用层攻击，通过对HTTP/HTTPS请求进行检测和拦截，保护后端服务器免受SQL注入、XSS跨站脚本、CSRF跨站请求伪造、恶意爬虫等攻击。SLB与WAF的集成通常为“串联架构”：客户端请求先经过WAF检测，合法请求再转发至SLB，最后分发至后端服务器。
核心配置与功能
防护规则配置：① 启用默认规则集（覆盖常见Web攻击类型，适合大多数业务）；② 自定义规则（根据业务特性添加黑白名单、URL访问控制、参数校验规则，如禁止特定IP访问管理后台）；③ 爬虫防护（识别并拦截恶意爬虫，可配置爬虫速率限制、验证码验证）；
SSL卸载联动：WAF可提前对HTTPS请求进行解密，检测完成后再加密转发至SLB，减少后端服务器的解密压力；
攻击日志与告警：记录所有攻击事件（攻击类型、来源IP、请求内容），支持实时告警（短信、邮件、钉钉），便于运维人员追溯和处理。
适用场景：所有基于HTTP/HTTPS的Web应用和API服务，尤其是面向公网的业务（如电商网站、政务平台、开放API）。配置建议：优先启用默认规则集，再根据业务日志逐步优化自定义规则，避免过度防护导致正常请求被拦截。
5.2 DDoS基础防护：抵御网络层攻击
DDoS（分布式拒绝服务）攻击通过海量恶意流量占用服务器资源，导致业务无法正常响应。SLB集成的DDoS基础防护主要针对网络层DDoS攻击（如SYN Flood、UDP Flood、ICMP Flood），采用流量清洗、黑洞牵引等技术抵御攻击。
核心特性与配置
基础防护能力：默认免费提供一定的防护带宽（如10G），可抵御中小规模DDoS攻击；超大流量攻击需升级为企业级DDoS防护（付费）；
自动流量清洗：当检测到异常流量（如流量峰值超过阈值、TCP连接数暴增）时，自动将流量引导至清洗中心，过滤恶意流量后再转发至SLB；
黑洞牵引：若攻击流量过大，超过清洗能力，会自动将攻击源IP拉入黑洞，阻断其访问，避免影响整体业务；
防护阈值配置：可根据业务正常流量设置防护阈值（如SYN连接数阈值、UDP流量阈值），避免误触发防护。
5.3 多层防护体系建议
为保障业务安全，建议构建“DDoS防护+WAF+SLB+安全组”的多层防护体系：① 外层：DDoS基础防护抵御网络层攻击；② 中层：WAF抵御应用层攻击，SLB配置访问控制（如白名单）；③ 内层：后端服务器安全组仅开放SLB的访问IP，禁止直接暴露公网，同时开启服务器自身的安全防护（如防火墙、杀毒软件）。
额外优化点：① 定期更新防护规则，适配新型攻击手段；② 监控攻击态势，根据攻击日志优化防护配置；③ 核心业务建议购买企业级DDoS防护和WAF服务，提升防护能力。
六、监控指标解析：QPS、并发连接数、后端服务器健康状态
有效的监控是保障SLB稳定运行的关键，通过实时采集和分析核心监控指标，可及时发现流量峰值、性能瓶颈和异常故障，为运维决策提供数据支撑。云厂商的SLB控制台通常提供完善的监控面板，覆盖流量、连接、健康状态等多维度指标。
6.1 核心监控指标解析
6.1.1 流量相关指标
QPS（Queries Per Second）：每秒处理的HTTP/HTTPS请求数（仅七层SLB），反映Web应用的并发请求处理能力。峰值QPS超过后端服务器承载能力时，需扩容服务器或升级SLB规格；
每秒流入/流出带宽：SLB接收和发送的网络带宽，单位为Mbps。若带宽持续接近SLB规格上限（如100Mbps），需升级SLB带宽规格，避免带宽瓶颈；
包速率：每秒处理的网络数据包数量，单位为PPS。大流量、小包场景（如游戏）需关注该指标，避免包速率超过SLB处理上限。
6.1.2 连接相关指标
并发连接数：当前SLB与客户端、后端服务器之间的活跃连接总数。四层SLB需重点关注该指标，若接近SLB并发连接上限，需升级SLB规格或优化连接管理（如缩短连接超时时间）；
新建连接数：每秒新增的连接数量，反映业务的访问热度。新建连接数突增可能是流量峰值或攻击的信号；
连接超时数：因超时未建立或断开的连接数量，若数量过多，需调整连接超时配置（如四层连接超时默认900秒，可根据业务缩短）。
6.1.3 健康状态与业务指标
后端服务器健康数/不健康数：实时监控后端节点的健康状态，若不健康数持续增加，需排查服务器故障或健康检查配置；
HTTP响应码统计：仅七层SLB，统计不同响应码的数量（如200、404、500）。500响应码突增可能是后端应用故障，404响应码过多可能是URL错误或爬虫攻击；
健康检查成功率：后端服务器健康检查的成功比例，若成功率低于100%，需及时排查异常节点。
6.2 监控配置与告警策略
合理配置监控周期和告警策略，可及时发现并响应异常：① 监控周期：核心指标（如QPS、并发连接数）建议设置为1分钟，便于捕捉实时峰值；非核心指标（如带宽）可设置为5分钟；② 告警阈值设置：根据业务正常运行的指标范围，设置合理的阈值（如QPS峰值超过8000告警、并发连接数超过5万告警、不健康节点数≥1告警）；③ 告警渠道：配置短信、邮件、钉钉/企业微信告警，确保运维人员及时接收通知；④ 告警分级：根据异常严重程度分级（如预警、严重、紧急），不同级别通知不同人员，避免告警风暴。
6.3 监控数据分析与优化
定期分析监控数据，可优化SLB和后端架构：① 流量趋势分析：通过历史QPS、带宽数据，识别周期性流量峰值（如每日10点、每周五晚上），提前扩容服务器，避免峰值期性能不足；② 负载均衡效果分析：查看后端各服务器的连接数、流量分布，若分布不均，调整负载均衡算法或权重配置；③ 故障追溯：业务异常时，通过监控数据定位问题（如QPS突降可能是SLB故障，500响应码突增可能是后端应用故障），缩短故障排查时间。
实验：搭建高可用Web集群
本实验基于云厂商SLB服务，搭建高可用Web集群，实现请求负载均衡、故障自动转移和会话保持功能。实验环境：2台云服务器（ECS，CentOS 7）、1台ALB（应用型负载均衡）、弹性公网IP。
实验目标
配置ALB监听HTTP 80端口，将请求分发至2台ECS服务器；
配置HTTP健康检查，实现故障节点自动隔离；
开启基于Cookie的会话保持，确保同一客户端请求分发至同一ECS；
验证集群高可用性（停止某台ECS的Web服务，观察业务是否正常）。
实验步骤
环境准备
部署Web服务：在2台ECS上安装Nginx，创建测试页面（区分两台服务器，如ECS1页面显示“Server A”，ECS2显示“Server B”）；
# 安装Nginxyum install -y nginx
启动Nginx
systemctl start nginx
systemctl enable nginx创建测试页面（ECS1）
echo "
Server A
" > /usr/share/nginx/html/index.html创建测试页面（ECS2）
echo "
Server B
" > /usr/share/nginx/html/index.html开放80端口（安全组）
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --reload确认ECS可访问：分别访问两台ECS的公网IP，能正常显示测试页面。
配置ALB负载均衡
创建ALB实例：登录云厂商控制台，选择“应用型负载均衡ALB”，创建实例（选择与ECS相同的VPC和可用区，绑定弹性公网IP）；
创建服务器组：新建服务器组，添加2台ECS实例（选择ECS的内网IP，端口设为80，权重默认1，权重越高，接收的请求越多）；
配置监听规则：
监听端口：80（HTTP）；
后端服务器组：选择步骤2创建的服务器组；
负载均衡算法：加权轮询（默认，可根据需求调整）；
开启会话保持：选择“植入Cookie”，过期时间设为30分钟。
- 配置HTTP健康检查：
检查路径：/index.html；
检查间隔：5秒，超时时间：2秒；
健康阈值：2次，不健康阈值：3次。
功能验证
负载均衡验证：访问ALB的公网IP，多次刷新页面，观察是否交替显示“Server A”和“Server B”（未开启会话保持时）；开启会话保持后，多次刷新应始终显示同一服务器页面；
故障转移验证：停止其中一台ECS的Nginx服务（systemctl stop nginx），访问ALB公网IP，观察页面是否仅显示健康服务器的内容（故障节点被自动隔离）；重启Nginx服务后，观察是否恢复负载均衡；
健康检查验证：在ALB控制台查看后端服务器健康状态，确认故障节点被标记为“不健康”，恢复后标记为“健康”。
实验总结
本实验通过ALB搭建的高可用Web集群，实现了请求的负载均衡分发、故障节点自动隔离和会话保持功能。实际生产环境中，还需补充：① 配置HTTPS监听（集成SSL证书）；② 集成WAF和DDoS防护；③ 部署多可用区ECS，提升集群的地域高可用性；④ 配置监控告警，实时监控集群运行状态。
总结
SLB负载均衡是分布式架构的核心组件，其配置的合理性直接决定业务的高可用性和性能。本文从负载均衡类型选型、四层与七层架构差异、健康检查、会话保持、安全防护到监控配置，系统梳理了SLB配置的全流程要点，并通过实验验证了核心功能的实现。实际配置时，需结合业务特性（如协议类型、并发量、延迟需求）选择合适的SLB类型和配置参数，同时构建多层防护和监控体系，确保业务稳定运行。
