04系统怎么做到高可用

224 阅读2分钟

1.可用性度量

什么是高可用性:系统具备较高的无故障运行能力

系统出现故障比系统性能低更损伤用户的使用体验。

MTBF:平均故障间隔,时间越长,系统稳定性越高

MTTR:故障平均恢复时间,值越小,故障对用户影响越小

可用性:Availability = MTBF / (MTBF + MTTR)  一般用几个9表示可用性

当可用性到达一定标准后,不能靠人力恢复(核心业务4个9,非核心业务到3个9)

image.png

2.高可用系统设计思路

可用性=系统设计+系统运维

2.1系统设计

“Design for failure”

failover(故障转移)、超时控制以及降级和限流

failover

1.完全对等节点做failover(所有节点承担读写流量,并且节点间不保存状态)

2.不对等节点间,系统中存在主节点和备节点

  • 通过心跳进行故障监测
  • 选主节点需要在多个备份节点达成一致,会使用一致性算法
    • Paxos
    • Raft
  • 热备份
  • 冷备份

完全对等节点

image.png

超时控制

会造成占用资源不释放,导致大面积的请求挂掉

怎么确定超时时间:超时时间短(造成大量超时错误)+超时时间长(不起作用)

收集系统的调用日志,并进行选择

超时控制的目的:避免资源不及时释放,通过牺牲少量的请求保证了整体的可用性

降级

目的:是为了保证核心服务的稳定而牺牲非核心服务的做法

保证核心流程的正常,牺牲非核心业务(直接返回false,避免同一时间的大量请求)

限流

同一时间内的固定访问流量,超出数量后直接返回错误

2.2系统运维

灰度发布

正常情况下

故障一般是通过上线新功能导致的,因此需要提供快速回滚恢复

灰度发布按照一定比例(机器维度)发布到线上,如果出现错误立即回滚

故障演练

对系统进行一些破坏性的手段,容易造成蝴蝶响应

3.总结

  • 提升系统可用性
  • 通常是以牺牲用户体验,牺牲系统性能为前提(具体业务场景下进行决策)
  • 开发
    • 处理故障
      • 冗余  故障转移
      • 取舍  超时控制、降级、限流
  • 运维
    • 变更管理
      • 灰度发布
    • 故障演练