1.可用性度量
什么是高可用性:系统具备较高的无故障运行能力
系统出现故障比系统性能低更损伤用户的使用体验。
MTBF:平均故障间隔,时间越长,系统稳定性越高
MTTR:故障平均恢复时间,值越小,故障对用户影响越小
可用性:Availability = MTBF / (MTBF + MTTR) 一般用几个9表示可用性
当可用性到达一定标准后,不能靠人力恢复(核心业务4个9,非核心业务到3个9)
2.高可用系统设计思路
可用性=系统设计+系统运维
2.1系统设计
“Design for failure”
failover(故障转移)、超时控制以及降级和限流
failover
1.完全对等节点做failover(所有节点承担读写流量,并且节点间不保存状态)
2.不对等节点间,系统中存在主节点和备节点
- 通过心跳进行故障监测
- 选主节点需要在多个备份节点达成一致,会使用一致性算法
- Paxos
- Raft
- 热备份
- 冷备份
完全对等节点
超时控制
会造成占用资源不释放,导致大面积的请求挂掉
怎么确定超时时间:超时时间短(造成大量超时错误)+超时时间长(不起作用)
收集系统的调用日志,并进行选择
超时控制的目的:避免资源不及时释放,通过牺牲少量的请求保证了整体的可用性
降级
目的:是为了保证核心服务的稳定而牺牲非核心服务的做法
保证核心流程的正常,牺牲非核心业务(直接返回false,避免同一时间的大量请求)
限流
同一时间内的固定访问流量,超出数量后直接返回错误
2.2系统运维
灰度发布
正常情况下
故障一般是通过上线新功能导致的,因此需要提供快速回滚恢复
灰度发布按照一定比例(机器维度)发布到线上,如果出现错误立即回滚
故障演练
对系统进行一些破坏性的手段,容易造成蝴蝶响应
3.总结
- 提升系统可用性
- 通常是以牺牲用户体验,牺牲系统性能为前提(具体业务场景下进行决策)
- 开发
- 处理故障
- 冗余 故障转移
- 取舍 超时控制、降级、限流
- 处理故障
- 运维
- 变更管理
- 灰度发布
- 故障演练
- 变更管理