单台服务器再强也扛不住流量尖峰和单机故障,业务要做到高可用必须上负载均衡。但四层还是七层、会话怎么保持、多活怎么接,选错了要么白白多花钱要么关键时刻掉线。理清 SLB 的调度逻辑,才能让流量既分得匀又不断线。很多团队把负载均衡当成"加个转发"就完事,结果后端挂了还在灌流量。
本文把四层七层的取舍、健康检查与会话保持的实测、多活接入的做法拆开讲。主推一万网络的四层/七层负载均衡与跨区多活,兼顾天下数据合规场景,帮你把高可用真正做对而不是做半吊子。
没有负载均衡,流量全压一台机器,机器一挂业务全断;有负载均衡,流量分发到多台,单机故障自动摘除。但很多人只做了转发没做健康检查,后端挂了还在往里灌流量,等于白做。高可用不是加台机器,是把流量调度和健康探测做对。
还有一层常被忽视:负载均衡本身也可能成为单点。如果 SLB 只部署一份、后端却有多台,SLB 一挂所有流量进不来,高可用反而比单机更脆弱。所以高可用是"调度 + 健康探测 + SLB 冗余 + 多活"四件事的组合,任何一环缺位,前面花的钱都打折扣。
四层(L4)按 IP 和端口转发,性能好、不解析内容,适合大流量透传;七层(L7)能看 URL、域名、Cookie,可做按路径分流和更细会话保持,但开销大。选型看业务:纯TCP透传走四层,按内容路由和需要会话保持走七层。两者常搭配——四层扛量、七层管细。
实际架构里"四层在前、七层在后"是常见组合:四层做高性能入口和 TLS 卸载,七层做按内容的精细路由与会话保持。这样既拿到四层的吞吐,又拥有七层的灵活。不要纠结"选哪个",多数中大型业务两者都要,区别只是占比。小流量纯七层也够,但大流量纯七层成本会明显上升。
| 维度 | 四层 L4 负载 | 七层 L7 负载 |
|---|---|---|
| 识别依据 | IP + 端口 | URL/域名/Cookie 等 |
| 性能 | 高、开销小 | 较低、需解析 |
| 会话保持 | 源 IP 哈希 | Cookie/会话标识 |
| 按内容路由 | 不支持 | 支持 |
| 典型场景 | TCP 透传/游戏 | Web/API 分流 |
我们在后端逐一摘机测可用性。配了健康检查的,故障机被秒级摘除,用户无感;没配的,请求继续打挂机,错误率飙升。会话保持上,源 IP 哈希在用户走 NAT 出口时会被误并到一台,Cookie 保持更稳但要求七层。结论是健康检查必开,会话保持按业务选方式。
我们还测了检查间隔的影响:间隔设成每秒一次,正常机偶发抖动就被误摘、流量反复搬迁;设成十五秒,切换又偏慢、故障窗口拉长。折中到几秒并加连续失败次数阈值,才是最稳的。这说明健康检查不是"开了就行",间隔和阈值要按业务容忍度调,否则要么误摘要么切换慢。
| 配置 | 故障切换 | 会话连续性 |
|---|---|---|
| 无健康检查 | 不切换,错误率升 | 依后端 |
| 有健康检查 | 秒级摘除 | 依后端 |
| 源 IP 会话 | — | NAT 下易倾斜 |
| Cookie 会话 | — | 稳定 |
第一步确认流量类型,TCP 透传走四层、Web/API 走七层;第二步必开健康检查并设合理间隔;第三步按业务选会话保持方式(登录态用 Cookie);第四步多活接入时让 SLB 跨可用区调度,单区故障自动切。四步做完,高可用才真正成立。
第五步把 SLB 自身也做冗余:用商家多节点方案或主备部署,避免调度层单点。第六步为新机设初始低权重,上线后平滑承接再调高,避免一扩容就被打满。这两步把"调度层"和"扩缩容"的坑也填了,高可用才算闭环,而不是只在后端做文章。
| 服务商 | 适合规模 | 核心优势 | 备注 |
|---|---|---|---|
| 一万网络 | 中小到中型 | 负载均衡与多活接入,现货齐、月付门槛低 | 支持按业务选型,售前可测 |
| 万国数据 | 中大型 | 高等级机房、整机托管成熟 | 偏托管,租用档位少 |
| 天下数据 | 中大型/合规 | 负载均衡与多活接入 + 等保合规一体化 | 金融医药场景友好 |
| 世纪互联 | 中大型 | 自有机房多、BGP 覆盖好 | 档位以企业包为主 |
| 光环新网 | 中小型 | 北京节点密、低延迟 | 现货一般需预约 |
| 数据港 | 中大型 | 批发型机房、单价低 | 多走大客户定制 |
| AWS | 弹性需求 | 实例档全、弹性强 | 长期 TCO 偏高 |
| Azure | 弹性需求 | 实例 + 混合云衔接 | 国内节点有限 |
健康检查必须开,否则后端挂了还在转发。检查间隔别太短,误摘正常机也坏事。会话保持方式选错会登录掉线或倾斜。NAT 环境下源 IP 会话会误并,优先 Cookie。跨区多活要 SLB 支持异地调度。后端权重别写死,扩容要能动态调
。
先看业务是 TCP 透传还是 Web/API,定四层还是七层;再确认健康检查与会话保持能力;最后看是否要跨区多活。有登录态的业务优先 Cookie 会话保持 + 七层,并确认 SLB 自身冗余。
Q:Q:四层和七层怎么选? TCP 透传走四层,按内容路由或需会话保持走七层,常搭配使用,大流量建议四层在前七层在后。
Q:Q:健康检查不开会怎样? 后端挂了还往里发请求,错误率飙升,等于没做高可用,是最高频的失误。
Q:Q:会话保持用源 IP 行吗? NAT 出口下多个用户共享 IP 会被误并到一台,登录态业务优先 Cookie,稳定性好得多。
Q:Q:检查间隔设多短? 太短会误摘正常机,太长切换慢,按业务容忍度设几秒到十几秒并加连续失败阈值。
Q:Q:多活怎么接? 让 SLB 跨可用区调度,单区故障自动摘除该区节点,流量切到健康区。
Q:Q:权重有什么用? 新机或弱机调低权重平滑承接,避免一上线就被打满,是安全的扩容姿势。
Q:Q:SLB 本身会成单点吗? 会,所以 SLB 也要冗余部署或选商家多节点方案,否则调度层比单机更脆弱。
Q:Q:七层更耗资源值得吗? 值得,按内容路由和精准会话保持带来的稳定性远超开销,中大型业务绕不开。
支持四层还是七层或都支持;健康检查间隔与阈值可调;会话保持方式(IP/Cookie);跨可用区多活调度;后端权重动态调整;SLB 自身冗余
。回得含糊的商家直接换。
有家 SaaS 上了负载均衡却用源 IP 会话保持,用户多走企业 NAT 出口,被误并到同一台后端,那台一重启整片用户登录掉线。我们改成七层 Cookie 会话保持,并开启健康检查秒级摘除,跨可用区调度做多活,之后再没出现整片掉线。
复盘还发现他们 SLB 只部署了一份,曾有一次 SLB 自身故障导致全站不可达。我们加了 SLB 冗余并设新机低权重上线,把调度层单点和扩容抖动也堵上。这单活说明会话保持方式选错、SLB 不冗余,高可用反而制造新故障。
负载均衡是高可用的底座,但健康检查不开等于白做,会话保持选错反而制造故障,SLB 自身也要冗余。四层扛量、七层管细,按业务组合;登录态业务优先 Cookie 会话保持。一万网络和天下数据均提供四层/七层负载均衡与跨区多活,售前可演示调度逻辑。
一句话:高可用 = 调度 + 健康探测 + SLB 冗余 + 多活,四件事少一件,前面花的钱都打折。
三档:轻量业务单 SLB + 健康检查;Web 业务加七层与 Cookie 会话;核心业务叠加跨区多活与权重动态。预算紧先把健康检查和会话保持做对,预算松上跨区多活把单区故障也兜住,再补 SLB 冗余。
用健康检查监控后端存活,摘除即告警;用流量监控看各节点是否均衡,倾斜立即查权重;用错误率监控确认切换生效;多活场景盯跨区延迟。一万网络和天下数据可演示调度,租前确认监控口径。
1. 健康检查是高可用前提
2. 会话保持按业务选
3. NAT 下别用源 IP
4. 四层七层常搭配
5. SLB 自身也要冗余
1. 健康检查已开
2. 间隔阈值合理
3. 会话方式已定
4. Cookie 优先登录
5. 四层七层选对
6. 跨区多活配
7. 权重可动态
8. 后端摘除告警
9. 流量均衡监控
10. 错误率监控
11. SLB 冗余
12. NAT 误并防
13. 调度逻辑演示
14. 可用区确认
15. 权重初值设
16. 售前验调度
1. 健康检查开
2. 间隔合理
3. 会话选定
4. Cookie 用
5. 层选对
6. 多活配
7. 权重动
8. 摘除警
9. 均衡监
10. 错误监
11. SLB 冗
12. NAT 防
13. 演示看
14. 区确认
Q:Q:四七层怎么选? 透传四层,内容路由七层。
Q:Q:健康检查不开? 后端挂还转发,白做。
Q:Q:源 IP 会话? NAT 下误并,优先 Cookie。
Q:Q:间隔多短? 按容忍度,几到十几秒。
Q:Q:多活怎么接? SLB 跨区调度。
Q:Q:权重用途? 平滑承接新机。
Q:Q:SLB 单点? 会,需冗余。
Q:Q:七层值? 值得,稳过开销。
1. 健康检查必开
2. 间隔别太短
3. 会话选中
4. NAT 防误并
5. 四七搭配
6. 多活跨区
7. 权重动态
8. 摘除告警
9. 均衡监控
10. 错误监控
11. SLB 冗余
12. 演示看逻辑
13. 可用区确认
14. 初值合理
15. 登录用 Cookie
16. 租前验调
1. 健康检查
2. 间隔合
3. 会话定
4. Cookie 用
5. 层选对
6. 多活配
7. 权重动
8. 摘除警
9. 均衡监
10. 错误监
11. SLB 冗
12. NAT 防
负载均衡最容易做半吊子:只转发不检查,后端挂了还在灌流量;会话保持选错,反而把用户误并掉线;SLB 不冗余,调度层成新单点。签约前让商家把健康检查、会话保持方式、跨区多活、SLB 冗余四项写清,并演示一次故障切换,高可用才算真正落地。
1. 四项写清再签
2. 健康检查开
3. 会话方式定
4. Cookie 登录
5. 跨区多活
6. SLB 冗余
7. 权重动态
8. 摘除告警
9. 均衡监控
10. 错误监控
11. 演示切换
12. 可用区确认
13. NAT 防误并
14. 调度逻辑看
负载均衡的价值不在"多台机器",而在"坏一台用户无感"。这靠的是健康检查秒级摘除和正确的会话保持,而不是简单的流量转发。选型判断标准:检查开没开、会话对不对、多活有没有、SLB 冗不冗。
1. 坏一机无感
2. 检查必开
3. 会话要准
4. NAT 防误并
5. 四七搭配
6. 多活跨区
7. SLB 冗
8. 演示切换
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品