机房着火都不怕？大白话盘透阿里云负载均衡 SLB 的抗灾级高可用

    在聊高可用架构的时候，很多兄弟有个误区，觉得：“我后端服务器搞了 10 台，数据库也搞了主备，我的架构就稳如泰山了。”

但你有没有想过，这 10 台服务器前面的那个“带路党”——负载均衡（SLB）如果挂了怎么办？不管你后端的 ECS 有多强悍，用户流量连门都进不来，整个系统瞬间瘫痪。这就是典型的单点故障（SPOF）。

作为全网流量的“总闸门”，阿里云的负载均衡 SLB（现在细分为传统型 CLB 和应用型 ALB）到底是怎么做到哪怕机房着火、骨干网断开，依然能稳如老狗地转发流量的？今天我们不扯那些虚的，直接拉开引擎盖，看看它的高可用底盘。

一、 第一层保命护甲：跨可用区（Zone）的“备胎”机制

如果你在阿里云后台购买 SLB，细心一点就会发现，系统一定会让你选两个东西：主可用区（Primary Zone） 和 备可用区（Backup Zone）。比如：主选北京可用区 A，备选北京可用区 B。

这就是 SLB 最基础、也最核心的跨机房高可用架构。

• 平时状态（主备分明）： SLB 实际上在底层机房里为你启动了至少两套硬件或虚拟机实例。平时所有的流量，都 100% 走主可用区 A 的 SLB 实例。备可用区 B 的实例处于“热备”状态，就像汽车的备胎，一边跟着转，一边默默看着。
• 极端状态（秒级切换）： 假设北京可用区 A 的机房突然断电，或者光缆被挖断。阿里云的底层健康检查系统会在 2-5 秒内 做出反应，把域名的虚拟 IP（VIP）直接漂移到备可用区 B 的 SLB 实例上。
• 用户感知： 用户的网络请求可能会因为断开重连而闪断一下，但马上就能恢复正常访问。你不需要修改任何 DNS 解析，也不需要手动去后台点切换，底层完全自动化。

二、 第二层降维打击：超大规模集群与 Anycast 的无缝容灾

“如果某个地区的两个可用区同时挂了呢？”（虽然概率极低，但技术抬杠是运维的优良传统）。

这时候，就要看 SLB 顶层的集群设计了。阿里云的 SLB 并不是单台服务器在战斗，它的背后是一个庞大的 LVS（四层）+ Tengine（七层） 物理集群。

在四层负载均衡（CLB）中，阿里云采用了 Anycast BGP（任意播） 技术：

1. 阿里云在骨干网上，让全球多个核心机房同时宣告同一个 SLB 的公网 IP 地址。
2. 用户的流量在进入阿里云网络的那一刻，是由运营商的 BGP 路由器根据网络大路的“拥堵情况”，自动分配到最近、最健康的 SLB 集群中。
3. 如果其中一个机房的 SLB 集群整体冒烟，BGP 路由协议会在几秒钟内自动把流量“绕道”发送到另一个城市的 SLB 集群。这种“多活”架构，已经超越了单地域的限制。

三、 第三层微观防线：SLB 对后端 ECS 的“生死点名”

SLB 自身高可用还不够，它还必须保证它分发过去的服务器也是活的。这就涉及到了 健康检查（Health Check）。

很多新手配置健康检查很随意，结果导致了“雪崩效应”。SLB 的健康检查是这样帮你保命的：

• 四层（TCP）点名： SLB 就像一个无情的打卡机，每隔几秒钟就去握手一下你后端 ECS 的端口（比如 80 端口）。如果握手成功，说明你活着；如果连续 3 次握手失败，SLB 会在毫秒级内把你踢出队列。新来的流量绝对不分给你。
• 七层（HTTP）深度体检： 很多时候端口是通的，但后端代码卡死了（比如抛出 500 错误）。这时候 SLB 会模拟浏览器去访问你指定的 URL（比如 /health.html）。如果返回的状态码不是 2xx 或 3xx，直接拉黑这台服务器。
• 故障自愈： 一旦你的那台 ECS 重启好了，代码恢复正常，SLB 重新体检通过后，又会自动把它拉回队列继续干活。整个过程零人工干预。

四、 实战避坑指南：怎么才能不暴殄天物？

阿里云把 SLB 的高可用做到了极致，但如果你自己在配置时犯了蠢，这套高可用就会形同虚设。请务必记住以下三条铁律：

1. 后端 ECS 必须跨可用区部署

这是最常见的错误！很多人买了跨可用区的 SLB（主区 A，备区 B），但为了图方便，把后端的 4 台 ECS 全买在了可用区 A。

结果一旦可用区 A 断电，SLB 确实成功切换到了备区 B，但备区 B 的 SLB 往后一看——空空如也，一台服务器都没有。高可用直接破功。

正确姿势： SLB 跨 A/B 区，后端的 ECS 也要均匀分布在 A/B 区。

2. 必须开启“会话保持（Session Stickiness）”吗？

如果你的业务需要用户登录（状态保存在服务器内存里），开启会话保持能让同一个用户的请求一直发给同一台 ECS。

但是！如果某台 ECS 挂了，这个用户的会话必然会断掉。为了真正的高可用，强烈建议把 Session 剥离出来，统一放到 Redis 缓存（如阿里云 Redis 版）里，让后端的 ECS 变成“无状态”的。这样任何一台 ECS 暴毙，SLB 都可以把流量无缝切给其他服务器，用户完全无感。

3. 合理设置 TTL 和健康检查阈值

健康检查的间隔不要设得太长（比如 10 秒检查一次，连续 5 次失败才确认，那意味着服务器挂了近一分钟 SLB 才会发现，这一分钟内会有大量用户报错）；但也不要设得太激进（比如 1 秒检查一次），否则在高并发时，健康检查本身的流量就会把你的服务器压垮。

黄金推荐： 响应超时 3 秒，检查间隔 2-3 秒，不健康阈值 3 次，健康阈值 2 次。

总结

阿里云 SLB 的高可用，是一套从全球 BGP 路由、到跨机房主备硬件、再到后端服务器秒级健康检查的立体防御体系。

对于运维和架构师来说，SLB 是整个系统中性价比最高的组件。你不需要去研究复杂的 Keepalived 怎么配、虚拟 IP 怎么漂移、LVS 集群怎么维护，一个月花点小钱，就能直接享受到大厂顶级架构师调教出来的抗灾级网关。把专业的事交给 SLB，你唯一需要做的，就是把后端的服务器老老实实分在不同的机房里。