网站高可用架构方案怎么设计？从单机到集群
网站运行稳定后，最怕的就是突然宕机：服务器故障、机房断网、流量激增，任何一个都可能导致业务中断。这时候就需要考虑高可用架构。
但高可用不是一步到位的，需要根据业务规模分阶段演进。本文从单机到集群，讲清楚每个阶段该做什么、怎么做、成本多少。
阶段1：单机阶段（初创期）
架构特点
- 一台服务器跑所有服务（Web + 数据库 + 缓存）
- 单点故障风险高，服务器挂了网站就挂了
- 成本低，运维简单
适用场景：日均访问5000以内，还在验证产品阶段
| 风险点 | 应对措施 | 成本 |
|---|---|---|
| 服务器宕机 | 定期快照备份，1小时内可恢复 | 免费 |
| 数据丢失 | 每天自动备份到OSS | 约5-10元/月 |
| 流量突增 | 配置CDN缓解 | 约50-100元/月 |
💡 单机阶段建议
这个阶段不要过度设计，重点做好数据备份。万一服务器挂了，能快速恢复数据到新服务器就够了。
阶段2：分离数据库（成长期）
适用场景：日均访问5000-2万，数据库成为瓶颈
| 组件 | 配置 | 价格/月 |
|---|---|---|
| Web服务器 | 2核4G | 约50-60元 |
| RDS数据库 | 2核4G（主从版） | 约300-400元 |
| OSS存储 | 200GB | 约20元 |
| CDN流量 | 100GB/月 | 约20元 |
| 总成本 | - | 约400-500元/月 |
💡 核心收益
数据库独立后自动实现主从备份，主库挂了从库自动切换，数据可靠性大幅提升。Web服务器挂了重建也很快，因为数据在RDS里。
阶段3：负载均衡（扩展期）
适用场景：日均访问2万-10万，单台服务器扛不住
| 组件 | 配置 | 价格/月 |
|---|---|---|
| SLB负载均衡 | 性能保障型 | 约150-200元 |
| Web服务器 x2 | 2核4G x2台 | 约100-120元 |
| RDS数据库 | 4核8G（主从版） | 约600-800元 |
| Redis缓存 | 2GB主从版 | 约200元 |
| OSS + CDN | - | 约50元 |
| 总成本 | - | 约1100-1370元/月 |
- 配置SLB：添加2台Web服务器到后端服务器池
- 健康检查：每10秒检查一次，3次失败自动摘除故障服务器
- 会话共享：用Redis存储session，保证用户登录状态在多台服务器间共享
- 代码部署：两台服务器代码同步，可以用Git钩子自动部署
阶段4：多可用区（高可用期）
适用场景：日均访问10万+，对可用性要求极高
| 风险 | 单可用区 | 多可用区 |
|---|---|---|
| 服务器故障 | SLB自动切换到健康服务器 | 同左 |
| 机房故障 | ❌ 整体不可用 | ✅ 自动切换到另一可用区 |
| 网络抖动 | 影响所有用户 | 只影响部分用户 |
| 可用性 | 99.9% | 99.99% |
⚠️ 成本增加
多可用区部署会增加20-30%成本（跨可用区流量费用），但可用性从99.9%提升到99.99%，即年停机时间从8.76小时降到52分钟。
核心组件配置要点
1. SLB健康检查配置
检查端口：80（HTTP）
检查路径：/health.php（返回200表示正常）
检查间隔：10秒
超时时间：5秒
不健康阈值：3次失败
健康阈值：2次成功2. 会话保持策略
方案1：SLB会话保持
- 基于IP的会话保持，简单但不够灵活
- 用户更换网络会话丢失
方案2：Redis集中存储（推荐）
- 所有服务器共享Redis存储session
- 用户请求到任何服务器都能获取session
- 更灵活，支持服务器动态扩缩容
常见问题
单台服务器什么时候该升级到负载均衡？
出现以下信号时该考虑了：
- CPU/内存持续高负载：即使优化后仍然超过70%
- 响应变慢：高峰期接口响应超过1秒
- 单点故障担忧：服务器挂了业务就中断，损失太大
- 流量持续增长：日均访问稳定在2万以上
不要等到服务器撑不住了再升级，提前1-2个月规划，避免慌乱。
负载均衡会增加多少成本？
成本增加分两部分：
| 成本项 | 价格 |
|---|---|
| SLB实例费 | 约150-200元/月 |
| 额外Web服务器 | 约50-60元/月/台 |
| Redis会话存储 | 约200元/月（主从版） |
| 总增加 | 约400-500元/月 |
相比单机架构，总成本增加约2-3倍，但可用性和性能提升明显，值得投入。
能不能用Nginx自建负载均衡，不用SLB？
可以，但不推荐：
✅ Nginx自建优点
- 成本低，一台小服务器就能跑
- 配置灵活，可以自定义规则
❌ Nginx自建缺点
- Nginx本身成为单点故障
- 需要自己配置高可用（Keepalived）
- 性能瓶颈：单台Nginx有性能上限
- 运维负担重
建议：小规模可以用Nginx，但流量上来后还是建议换SLB，省心可靠。
总结
高可用架构不是一步到位的，而是随业务发展逐步演进：
- 初创期（日均5000内）：单机 + 备份，够用
- 成长期（5000-2万）：分离数据库，用RDS保证数据可靠
- 扩展期（2万-10万）：加SLB + 多台Web服务器，解决性能瓶颈
- 高可用期（10万+）：多可用区部署，抵御机房级故障
核心原则：
- ✅ 不要过度设计，根据当前规模选方案
- ✅ 优先解决单点故障（数据库、服务器）
- ✅ 成本和可用性要平衡，不是越复杂越好
- ✅ 提前1-2个月规划下一阶段升级，避免临时抱佛脚
对于大多数网站，阶段2（分离数据库）就能覆盖90%的需求。只有当流量真正起来了，再考虑负载均衡和多可用区，这样成本最优，风险最小。