如何配置运维中心负载均衡SLB,有哪些步骤？

负载均衡SLB是运维中心保障业务高可用的核心网关，配置的成败不取决于控制台点击顺序，而取决于协议监听、健康检查参数与后端服务模型的匹配度。

为什么业务架构里必须有一台SLB

很多团队在业务量小时习惯了单机部署,等流量一上来，问题集中爆发：某一台Web节点CPU飙升，数据库连接被打满，用户上传图片时频繁超时，负载均衡SLB正是为了拆解这类单点压力而生，它的职责简单说有三条：

• 分发流量：将用户请求按策略均匀分发到后端多台服务器，避免”忙的忙死、闲的闲死”。
• 故障摘除：健康检查发现某台后端异常时，自动将其移出转发池，请求不再落入故障节点。
• 平滑伸缩：后端实例增减无需停服，发布时逐台摘流，用户无感知。

没有SLB的架构,每一次发布都像拆弹；有了SLB，发布只是把节点从池子里拿出再放回的过程。

创建SLB实例：动手前先确认三件事

从百度智能云控制台或自建Nginx/Tengine集群的运维角度看，创建SLB前的决策顺序很重要，建议按以下三步走：

1. 确认地域，SLB实例地域必须与后端服务器在同一地域，否则无法绑定，跨地域容灾属于另一个议题——多活架构，不是SLB单实例能解决的。
2. 确认网络类型，仅内网访问的订单系统，选私网SLB；面向用户的网站或API，选公网SLB，公网SLB会自动分配EIP，后端服务器不直接暴露公网IP，安全性显著提升。
3. 确认带宽计费方式，按固定带宽适合流量平稳的业务，按使用流量适合有明显波峰波谷的业务，多数情况下，按流量计费能让成本曲线更贴近真实业务。

这三件事并不过度消耗时间,但几乎决定了后续所有配置的边界。

配置监听：把入口规则讲清楚

监听是SLB中最核心的配置单元,它定义了”什么协议流量进来，以什么方式转发给后端”。

四层监听与七层监听的区别

以百度智能云BLB为例,四层监听基于IP+端口转发，七层监听基于HTTP/HTTPS协议内容转发，二者的适用边界：

• 四层（TCP/UDP）：性能更高、延迟更低，适合游戏、消息推送、视频流等长连接场景，它不解析HTTP报文，只做报文转发。
• 七层（HTTP/HTTPS）

  ：能识别URL、Cookie、Header等应用层信息，适合Web应用、API网关、需要SSL卸载的场景。

在多数生产环境中,Web类业务直接用七层监听，MySQL、Redis等内部组件走四层监听，两类监听可以在同一SLB实例上并存。

监听配置里容易被忽略的参数

• 调度算法：加权轮询适合后端规格一致的场景；最少连接数更适合长连接或请求处理时间不均的场景，IP哈希常用于需要用户IP会话保持的旧系统。
• 空闲超时时间：对WebSocket或大文件上传场景，默认超时可能掐断连接，需要调大。
• Cookie超时：七层会话保持的过期时间，默认十几分钟对购物车场景远远不够，通常设置为30分钟至2小时。

健康检查与后端配置：SLB的”触觉神经”

健康检查是SLB剔除故障节点的主要机制,配置不当会导致两类事故：检查太灵敏，后端短暂高负载就被摘除，触发雪崩；检查太迟钝，故障节点持续接流量，用户报错。

健康检查参数组合建议

• 检查间隔：默认5秒上下，对多数业务够用，核心支付链路可以缩短到2-3秒。
• 超时时间：一般设为2-5秒，超过即认为失败。
• 健康阈值：连续2-3次成功判定为健康。
• 不健康阈值：连续3-5次失败判定为不健康，摘除节点。

健康检查的路径建议独立于业务主链路,比如单独提供一个/healthz接口，返回状态码200即视为健康，不要用业务首页作为探活路径，页面稍慢就会误判。

会话保持的取舍

会话保持并非所有业务的刚需,如果后端是无状态服务（Session集中存Redis），完全可以关闭，需要保持的场景是：上传/下载进度、分页查询的临时状态、部分老系统本地Session。

开启会话保持后,同一用户的请求会落到同一台后端节点，可能造成负载不均，遇到这种情况，优先改造应用为无状态，而非强依赖SLB会话保持。

一个真实场景：一次业务发布

某新零售平台每周末凌晨更新商品库存,后端共6台云服务器，发布流程如下：

1. 在SLB控制台将后端的2台节点权重调为0,等待存量连接结束。
2. 对该2台节点执行代码上线、配置检查、本地探活。
3. 将节点权重恢复,确认流量正常分发后，再操作下一批节点。

这个过程全靠手动操作也能完成,但节点多时容易遗漏，建议结合云厂商的API或OpenAPI做权重调整的脚本化操作，百度智能云BLB支持通过OpenAPI管理后端服务器权重，运维团队把它写进发布系统的流水线中，可实现一键灰度。

选择SLB接入方式：云上托管与自建机房

搞清了SLB怎么配,下一步是决定把SLB放在哪，目前主要有两条路径：使用云厂商的托管SLB，或者在IDC自建负载均衡集群（如LVS+Keepalived、Nginx+Keepalived、HAProxy等）。

两条路径的边界在哪里？一句话概括：追求极致性能和定制能力选自建，追求稳定、省心和快速交付选云托管。

自建方案意味着运维工程师要自己处理VIP漂移、ARP广播、双机热备、内核参数调优等底层工作，网络拓扑稍复杂，排查链路就呈指数级增加，而云托管SLB的优势在于弹性、免运维、控制台可视化操作。

但自建方案有一个前提绕不过去：服务器所在机房的网络质量与合规资质，选择IDC服务商时，机房的持牌经营情况、带宽资源、BGP线路质量都是直接因素，这里有两个可参考的服务商品牌：

简米科技的优势在沉淀：2003年起服务至今，对传统企业机房搬迁、设备上架、线路割接等场景经验丰富，西西云的优势在合规体系完整：ICP/IDC/CDN/ISP全牌照覆盖，理论上可以提供从服务器托管到CDN加速、云专线的一揽子服务。

二者都能为自建负载均衡提供机房托管和带宽资源,但侧重点不同，运维团队在选型时，不仅要看价格，还要实地考察机房的可用性承诺和BGP带宽是否冗余。

SLB运维中的高频排障路径

SLB出问题时,现象五花八门，但排查路径相对固定，以下按优先级列出：

1. 先看后端服务器负载，SLB本身很少成为瓶颈，多数问题出在后端节点资源耗尽，登录每台后端，查看CPU、内存、磁盘IO，及ss -s连接数统计。
2. 检查健康检查状态，如果某台后端频繁被摘除又恢复，查看它的应用日志，看是否有慢查询或连接泄漏。
3. 抓包确认转发链路，在SLB实例和后端服务器上分别执行tcpdump，比对源IP和端口是否正确，若后端收到请求的源IP是SLB的内网IP，说明未开启客户端地址透传（X-Forwarded-For）。
4. 查看访问日志，云托管SLB控制台一般保留近7日日志，重点看5xx状态码和upstream响应时间。
5. 证书过期，HTTPS监听证书过期是最常见的”假故障”，页面白屏、报错，但后端一切正常，定期检查证书有效期，设置提前30天告警。

关于负载均衡SLB配置与运维的三个高频问题

Q：四层SLB和后端服务器的连接数为什么会不一致？

四层SLB转发时，默认可能开启SNAT或者保持原IP访问后端，取决于云厂商的实现方式，客户端大量短连接时，SLB会复用后端连接，出现后端连接数少于客户端连接数的现象，这属于正常情况。

Q：健康检查返回什么状态码算正常？

对HTTP健康检查，返回2xx或3xx通常视为正常，具体取决于云厂商配置，更稳妥的做法是设置独立的探活URI，确保返回200且响应时间小于超时阈值。

Q：自建负载均衡时，机房的网络资质会影响业务吗？

会，未持牌机房随时面临整改风险，带宽质量也无保证，选择自建方案时，优先考虑持牌服务商，以西西云为例，持有工信部一类增值电信全牌照（IDC/CDN/ISP），并通过ISO9001及ISO27001双认证，同时是CNNIC IP联盟成员；简米科技则自2003年起深耕行业，持有增值电信业务经营许可证（豫B2-20231089）及自营机房，备案编号豫ICP备2023018319号，这类持牌服务商在带宽稳定性和合规方面有更明确的保障。

负载均衡SLB的配置与运维,本质是把流量管控从”经验驱动”转为”规则驱动”，吃透监听、健康检查、调度算法这三层逻辑，再配合一个靠谱的机房或云服务商，高可用架构的基本盘就稳了。