系统高可用



1. 指标



业界用多少个 9 来衡量网站的可用性，如 QQ 的可用性是 4 个 9，即 QQ 服务 99.99% 可用，一年中只有 0.01% 的时间不可用，也就是一年中大约 53 分钟不可用。

网站年度可用性指标 = (1 - 网站不可用时间/年度总时间) * 100%

网站不可用时间 = 故障回复时间点 - 故障发现时间点

- 两个 9 是基本可用，年度停机时间小于 88 小时

- 3 个 9 较高可用，年度停机时间小于 9 小时

- 4 个 9 是具有自动恢复能力的高可用，年度停机时间小于 53 分钟

- 5 个 9 是极高可用性，年度停机时间小于 5 分钟



2. 故障

2.1 故障分管理

根据故障影响程度，对责任人进行评分。

2.2 故障处理流程及考核

• 1. 客服报告故障或者监控系统发现故障

• 2. 提交故障给相关部门接口人

• 3. 故障接手、处理

• 4. 故障处理完毕故障归档

• 5. 确认故障归属记入绩效考核



2.3 引起故障的原因

• 硬件故障

• 软件 bug

• 系统发布

• 并发压力

• 网络攻击

• 外部灾害



3. 高可用架构策略

3.1 解耦

• 高内聚、低耦合的组件设计原则

• 面向对象基本设计原则

• 面向对象设计模式

• 领域驱动设计建模

3.2 隔离

• 业务与子系统隔离

• 微服务与中台架构

• 生产者消费者隔离

• 虚拟机与容器隔离

3.3 异步

• 多线程编程

• 反应式编程

• 异步通信网络编程

• 事件驱动异步架构

3.4 备份（冗余）



• 集群设计

• 数据库复制



3.5 失效转移

• 数据库主主失效转移

• 负载均衡失效转移

3.5.1 如何确认失效？

• 心跳检查

• 仲裁中心

3.5.2 幂等

应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假的失败。避免重复请求带来的副作用。

3.6 事务补偿

• ACID

• 分布式事务的 BASE

• 基本可用（Basic Availability）、软状态（Soft-state）、最终一致（Eventual consistency）

3.7 重试

调用者可以通过重试的方式修复单次调用的故障。

上游超时时间要大于下游调用者超时时间之和。

3.8 熔断

当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务的调用。

断路器有三种状态：关闭、打开、半开

3.9 限流

并发请求超过了系统承受能力，业务允许保证部分用户可用的情况下，丢弃一部分的用户请求。

限流算法：

• 计数器算法（固定窗口、滑动窗口）

• 令牌桶算法

• 漏桶算法

3.9.1 计数器

固定窗口：

• 使用计数器在周期内累加访问次数，当达到设定的限流值时，出发限流策略。

问题，时间间隔边界产生并发

移动窗口：

将时间周期分为 N 个小周期，分别记录每个小周期内访问次数，并组根据时间滑动删除过期的小周期。

3.9.2 令牌桶算法

3.9.3 漏桶算法

• 流入水滴流入速率任意

• 如果流入速率过快，超过了桶的容量，则直接丢弃水滴

• 按照常量速率流出水滴

3.10 自适应限流

没有提前的人工评估，实时自动评估 QPS,业务流量的不确定性与技术方案的自适应性天生一对。

3.11 降级

在系统高并发时，屏蔽非必要功能。

3.12 异地多活

如果数据中心因为不可抗因素导致不可用，部署机房异地部署策略。

4. 高可用运维

4.1 发布

发布过程中需要保证服务总体可用。

• 1. 关闭服务实例负载均衡路由

• 2. 关闭服务器

• 3. 部署服务实例

• 4. 打开负载均衡

• 5. 部署其他实例

4.2 自动化测试

需要权衡手工测试和自动化测试，早期主要投入手工测试。

4.3 CI/CD

开发测试环境场景使用

4.4 预发布验证

开发、测试环境项目正常，部署线上环境后失败。

部署内部使用服务实例，对外负载均衡不配置预发布服务器，验证线上环境。如需验证数据库，则链接线上库。

4.5 代码版本控制

4.6 网站运行监控

4.6.1 监控数据采集

4.6.2 审计日志