网站高可用架构怎么搭？一次真实故障后的改造记录
这是一个真实场景的改造记录：一个单机部署的工具类网站，因为服务器硬件故障宕机了近4小时，之后团队用负载均衡SLB重新搭建了高可用架构。记录下整个问题发现、方案设计到效果验证的过程。
场景描述：单点故障的代价
网站此前只有一台ECS跑应用和数据库，日均访问量约2万次。某天凌晨服务器所在物理机出现硬件故障，实例无法启动，运维人员凌晨3点才收到告警，恢复花了近4个小时，期间网站完全不可访问，损失了一批正在进行中的订单。
遇到的问题
⚠️ 问题暴露
单台服务器架构下，任何一次硬件故障、系统崩溃或误操作都可能导致整站不可用，而且没有自动切换机制，必须人工介入才能恢复。
复盘后确认了两个核心问题：没有冗余节点，故障时无法自动转移；没有健康检查机制，问题发现依赖人工告警，响应慢。
解决方案：从单机到SLB+多ECS
改造前后对比
| 项目 | 改造前 | 改造后 |
|---|---|---|
| 架构 | 单台ECS | SLB + 2台ECS + 独立RDS |
| 故障恢复方式 | 人工重启，耗时数小时 | 自动切换，30秒内恢复 |
| 月成本增加 | - | 约增加350元 |
效果验证
改造完成后，团队主动做了两次故障演练：手动停止一台ECS实例，SLB在健康检查周期内（约20秒）将其标记为异常并把流量全部切到另一台，期间前端用户几乎无感知，没有出现明显的请求失败。
💡 经验总结
高可用改造的成本远低于一次长时间宕机造成的业务损失，对有稳定访问量的站点来说，这笔投入是值得的。
常见问题
小网站访问量不大，有必要上SLB吗？
如果业务对可用性要求不高、宕机影响小，单机也可以接受。但如果涉及实际交易或对外服务承诺，建议至少做两台机器的冗余，成本增加不多但能大幅降低风险。
SLB健康检查失败后多久能完成切换？
通常在设置的检测周期（可设置为几秒到几十秒）内就能识别异常并切换流量，具体时间取决于健康检查间隔和失败阈值的配置。
总结
单点故障的代价往往比高可用改造的成本高得多，这次真实的宕机事故也印证了这一点。如果网站对可用性有要求，SLB加多台ECS的组合是性价比很高的改造方向。