网站高可用架构方案：从单台服务器宕机到零故障的真实改造过程
去年帮一个做在线教育的朋友处理过一次事故：他的网站跑在单台云服务器ECS上，凌晨服务器突发硬件故障重启，正好撞上早读课直播，几百个学生同时打不开页面，投诉电话打爆客服。这次事故之后，他下决心做高可用改造。这篇文章记录完整的改造过程，包括遇到的坑和最终的架构方案。
事故复盘：单点故障到底有多危险
当时的架构非常简单：一台2核4G的ECS跑着网站全部服务，没有任何备份节点。故障发生后排查发现，问题出在服务器所在的物理宿主机临时重启，整个过程持续了约18分钟。
即便云服务商承诺99.95%的可用性，落到单台服务器上依然意味着每年有将近4.4小时的潜在停机时间，而且故障发生的时间完全不可控，很可能恰好撞上业务高峰。
更麻烦的是，由于只有一台服务器，运维也没办法在不中断服务的情况下做系统更新或扩容，每次维护都是提心吊胆。
改造方案：引入负载均衡的三步走
和朋友一起设计了改造方案，核心思路是把单台服务器拆成多台，用负载均衡做流量分发：
- 第一步，镜像现有服务器：把现有ECS制作成自定义镜像，确保新服务器环境完全一致
- 第二步，部署第二台ECS：用镜像在不同可用区创建第二台服务器，避免两台机器同时受同一个机房故障影响
- 第三步，接入SLB：购买负载均衡SLB实例，把两台ECS都挂载为后端服务器，设置健康检查规则
整个过程最关键的是健康检查配置，直接决定了故障切换的速度。
健康检查配置的细节
SLB的健康检查如果配置不当，故障发生时切换会很慢，等于白做了高可用。我们最终的配置是：
| 检查项 | 配置值 | 原因说明 |
|---|---|---|
| 检查间隔 | 2秒 | 默认5秒太慢，缩短能更快发现故障 |
| 超时时间 | 3秒 | 给服务器响应留一点缓冲，避免误判 |
| 连续失败阈值 | 2次 | 默认3次会延迟判定，2次更敏感 |
| 切换耗时 | 约6秒 | 相比之前18分钟的宕机，几乎无感知 |
健康检查路径不要用首页，首页往往依赖数据库和多个服务，容易因为单个环节波动导致误判。建议专门写一个轻量的健康检查接口，只检测服务进程是否存活。
改造前后成本对比
这次改造并不是免费的，多了一台服务器和一个SLB实例，成本确实上升了。但对比故障造成的损失，这笔投入很值：
| 项目 | 改造前 | 改造后 |
|---|---|---|
| 服务器成本 | 600元/年（1台2核4G） | 1200元/年（2台2核4G） |
| SLB成本 | 0元 | 约220元/年（性能保障型） |
| 年度总成本 | 600元 | 1420元 |
| 单次故障损失估算 | 退费+投诉处理约3000-5000元 | |
算下来，多花的820元成本，相当于避免一次中等规模故障损失的六分之一，而且全年故障概率不止一次，这笔账怎么算都划算。
改造后的效果验证
方案上线3个月后，我们特意做了一次演练：手动关闭其中一台ECS模拟故障，验证切换效果。
❌ 仍存在的局限
- 数据库仍是单点，如果数据库所在服务器故障依然会影响业务
- 两台服务器的会话状态需要额外处理，否则用户登录状态可能丢失
常见问题
总结
从单点故障到高可用架构，核心改造思路就是「拆分服务器+负载均衡+健康检查」三件事。多花的成本相比一次故障的损失完全值得，特别是业务已经产生实际收入或用户规模的网站，建议尽早规划这类架构升级，别等出事故了才后悔。