高可用架构设计
双十一零点，订单量是平时的 100 倍。
你的系统稳稳地扛住了洪峰。用户下单流畅，支付秒完成，物流实时更新。
而隔壁部门的系统就没这么幸运了——数据库被打爆，支付服务宕机，用户投诉电话被打到爆。
差距在哪里？差距在于架构设计。
高可用架构不是「不宕机」，而是在故障发生时，系统还能继续提供服务。一个设计良好的高可用系统，能够在部分组件故障时自动切换、限流降级、快速恢复，让用户几乎感知不到故障的存在。
本模块从负载均衡讲起，涵盖限流熔断、降级容错、高可用架构设计，助你构建稳固可靠的系统架构。
模块速览
负载均衡
| 文档 | 简介 |
|---|---|
| 四层与七层负载均衡 | L4 vs L7 的区别与选型 |
| Nginx 负载均衡 | Nginx 配置与算法 |
| Nginx 高可用方案 | Keepalived 双机热备 |
| DNS 负载均衡 | DNS 轮询与智能解析 |
| 负载均衡算法 | 轮询、加权、最小连接、一致性哈希 |
| 客户端负载均衡 | Ribbon、Spring Cloud LoadBalancer |
限流与熔断
| 文档 | 简介 |
|---|---|
| 限流算法对比 | 计数器、滑动窗口、令牌桶、漏桶 |
| Sentinel 限流 | 流控规则与效果 |
| Sentinel 熔断降级 | 熔断策略与恢复 |
| 分布式限流方案 | Redis 令牌桶、滑动窗口 |
| 限流器实现 | 限流器的工程实践 |
高可用架构
| 文档 | 简介 |
|---|---|
| 服务降级方案 | 熔断器模式原理 |
| 服务隔离策略 | 线程池隔离、信号量隔离 |
| 健康检查机制 | 主动探测与被动上报 |
| 限流与熔断对比 | 两者区别与组合使用 |
高可用的核心指标
可用性计算
| 可用性 | 年故障时长 | 适用场景 |
|---|---|---|
| 99% | 3.65 天 | 普通系统 |
| 99.9% | 8.76 小时 | 企业级系统 |
| 99.99% | 52.6 分钟 | 金融系统 |
| 99.999% | 5.26 分钟 | 电信级系统 |
每提高一个 9，难度呈指数级增长。
故障处理的黄金时间
| 时间 | 目标 |
|---|---|
| 1 分钟内 | 发现故障 |
| 5 分钟内 | 定位根因 |
| 10 分钟内 | 止血恢复 |
| 24 小时内 | 问题根治 |
高可用的三大护法
护法一：限流
限流是系统的第一道防线。
当流量超过系统处理能力时，通过限流丢弃部分请求，保证整体可用。
限流算法对比：
| 算法 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 计数器 | 简单 | 不平滑 | 简单限流 |
| 滑动窗口 | 平滑 | 实现复杂 | API 限流 |
| 令牌桶 | 支持突发 | 实现复杂 | 流量整形 |
| 漏桶 | 恒定速率 | 不能突发 | 流量整形 |
护法二：熔断
熔断是系统的第二道防线。
当下游服务持续故障时，通过熔断快速失败，避免雪崩效应。
熔断器三状态：
Closed（关闭）——> Open（打开）——> Half-Open（半开）
| | |
| 失败率超阈值 | 超时后尝试 | 成功则关闭
v v v护法三：降级
降级是系统的最后一道防线。
当系统压力过大时，通过关闭非核心功能，保证核心功能可用。
降级策略：
| 策略 | 说明 |
|---|---|
| 页面降级 | 展示静态页面或缓存数据 |
| 功能降级 | 关闭非核心功能 |
| 读降级 | 读缓存而非数据库 |
| 写降级 | 异步写入而非同步 |
高可用架构设计原则
原则一：消除单点
每个关键组件都必须有备份：
- 负载均衡器：双机热备
- 应用服务器：集群部署
- 数据库：主从复制
- 缓存：Redis Cluster
- 消息队列：集群模式
原则二：故障隔离
通过舱壁模式，防止故障蔓延：
- 线程池隔离：不同业务用不同线程池
- 进程隔离：核心和非核心进程分离
- 机房隔离：多机房部署
原则三：快速恢复
故障不可避免，关键是快速恢复：
- 自动故障转移
- 灰度发布与回滚
- 定期演练与预案
学习路径建议
入门：理解负载均衡
建议从负载均衡基础开始，理解四层和七层负载均衡的区别。
然后学习Nginx 负载均衡配置，这是最常见的负载均衡实践。
进阶：掌握限流熔断
深入学习限流算法和Sentinel。
限流和熔断是高可用架构的核心组件。理解各种算法的优缺点，能够根据场景选择合适的方案。
高级：高可用架构实践
学习服务隔离、健康检查、故障转移等高级主题。
这是架构师必备的技能。能够设计出一套完整的高可用方案，是高级工程师和架构师的分水岭。
延伸思考
高可用架构有个「不可能三角」：
一致性、可用性、分区容错性——三者不可兼得。
在分布式系统中，我们必须在这三者之间做出权衡。大多数互联网系统，选择的是可用性和分区容错性，接受最终一致性。
所以，设计高可用系统时，要问自己三个问题：
- 哪些是核心功能，哪些可以降级？
- 故障时，用户能接受什么样的体验？
- 我们的 SLA 承诺是什么？
想清楚这三个问题，你的高可用架构设计就有了方向。
好的高可用架构，不是防止所有故障，而是让故障发生时，用户无感知。
愿你在架构设计的道路上，构建出稳如磐石的系统。