性能文章>高可用核心原理综述!>

高可用核心原理综述!原创

363129

导读:天天评估系统可用性,每次说5个9 、6个9,那么,可用性到底该怎么评估,几个9又是怎么算出来的呢?而我们又可以做些什么,来保障系统的高可用呢?

Part One 可用性概念一览

永不停机总归是不现实的。那么,在可操作性的范围内,怎样把影响降到最小,而影响又该怎么衡量呢?
概念一:MTBF (mean time between failure)
MTBF是指两次相邻的系统失效(服务故障)之间的工作时间长度。也可以叫它 无故障时间 或  失效间隔。这个值越大,说明系统的故障率越低,系统越可靠。因此,我们通常希望这个时间间隔越大越好。
概念二:MTTR (mean time to repair)
MTTR是指从出现故障到修复中间的时间长度。也叫做 修复时间。这个值越低,说明故障越容易恢复,系统可维护性越好。因此,我们通常希望这个时间间隔越小越好。
因此,系统可用性可以量化为:

MTBF / (MTBF + MTTR)

示例:系统的可用性要求  99.999% ,那么,按一年365天来算:
全年允许的宕机时间只有5分钟多一点。

Part Two 高可用的保障

全年宕机5分钟?从上一部分可以知道,我们的目的,是要尽可能的增大系统的无故障运行时间,同时,在发生故障时,尽可能迅速的完成恢复。
故障的发生多种多样,经过了这么多年的研发前辈的踩坑,我们可以将其分类汇总,并给出分析和对应的方案。

Level1: 配置修改出错

最不应该犯的错,但是感觉很多人都没少犯。
原因也很简单,要不就是格式错了,要不就是配置的数据不对,而且错误的配置还被直接发到了线上,直接导致业务异常,甚至宕机。
解决方案主要是两部分: 变更管控 +  配置灰度

工单+审批的方式,让配置变更流程化、正规化,提升配置变更的被重视程度。利用配置灰度发布平台功能,通过测试和灰度多环境的上线前验证加上版本可回滚的能力,减少由于配置问题造成的可用性降级。

Level2: 代码BUG

人为BUG往往是系统异常的罪魁祸首。coder? 不,请叫我buger ~ 虽然最是常见,但这一部分又是相对最容易应对的。
解决方案有两个方面:
把控 研发质量 +  测试质量

需要通过系统分析文档的撰写和评审提前分析业务问题和系统边界。通过容错设计单侧CR来完善代码的健壮性。通过测试分析来明确测试重点和影响点。通过线上请求录制回放等仿真测试来保证原有的逻辑不受影响。

Level3: 依赖服务故障

业务高速发展,系统被水平垂直拆分,越来越复杂,几乎没有哪个系统可以独立存在,总归会有依赖。
然而,依赖系统在整个业务流程中占比很重,但我们自己又无法把控,因此,服务的依赖治理,是可用性保障中的非常重要的一环。
解决方案包括:
依赖梳理+ 指标约定+ 故障解决

首先,要根据业务本身的情况,梳理出强弱依赖,不同级别的依赖区分应对。比如,弱依赖就可以剥离主链路,采用异步或离线等方式进行;而强依赖如RPC中间件,就只能增加监控,提高问题发现速率。其次,定制指标,做好指标监控和百分位预警。比如对依赖系统的调用量预估以及sla约定,达到百分位阈值时,及时报警再次,制定故障预案,如主链路的限流、弱依赖的熔断等。预案需要多次演练才能上线。

Level4: 突发流量和流量洪峰对应不足

让业务按我们预先计划的线路增长是不切实际的。吭哧瘪肚做个需求想让它涨10%,结果没涨反而掉了,当你不注意的时候,突然来了一波上涨,都是很常见的事~
应对方法有两个方面:
流量规律预估 +  异常流量防护

规律方面,要分析业务规律,合理安排策略,如请求排队,提前扩容等。如打车场景,流量高峰(上下班)和流量突发(雨雪大风天)的情况都非常典型。为啥经常遇到司机吐槽接不到单,为啥一到雨雪天就要从派单模式切换成抢单模式,真的是因为选择性突然变多了么~异常流量方面,要让上游协助减少无效重试,用缓存等策略防止底层服务雪崩。如电商商品详情系统,一到晚上流量就徒增,爬虫无疑;再如系统超时导致用户不断刷新的流量放大

Level5: 容量预估不足

上述的流量预估其实属于容量预估的一个方面,除此之外,还有缓存容量、底层数据存储容量、服务器容量、带宽容量等等。
应对方案有四个方面:
容量规划+ 限流降级+ 冗余+ 全链路压测

前期,需要做好容量规划和容量预警方案,争取把可能的突发流量都考虑在内,核心模块尽量实现冗余部署、容灾部署;同时,利用多维度的报警,尽量早和及时的发现容量问题。故障发生时,依据前面提到的依赖服务治理方案,根据重要程度的不同,进行限流、降级或熔断。减少对容量的持续冲击。故障发生后,利用冗余部署,快速切换路由,分担当前单元的容量压力。单服务压测只能摸到当前服务的高度,但是这个高度是否满足全链路的要求,就需要全链路去呀,这个时候,全局统一的路由、影子库等的基础建设就至关重要了。

Level6: 硬件甚至整个机房故障

相比于动则百万造价的大型服务器,普通计算机以及docker的稳定性要大打折扣。因此,宕机是难免的事,除了服务器,还有交换机甚至是光纤抖动都有可能发生。
而应对方案有两个方面: 分散+ 冗余:

正所谓不要把鸡蛋都装到一个篮子里,而要多分几个篮子装。这样,一个篮子打了,不至于影响全部鸡蛋。蚂蚁的单元化部署就是这个思路,不同的用户按ID分到不同的处理单元,因此,就算这个单元全宕了,最差的情况也只会影响到这个单元的用户群。冗余,则是有备无患的思想。主从互备、同城机房互备、两地三中心、三地五中心则是这个思路的具体落地。

Part Three 总结

越是重要的系统,对高可用的要求越高。而高可用的治理,会很考验整个技术团队的技术沉淀。如果后面大家遇到对系统可用性非常敏感的情况,希望本文可以对大家的思路和着手点有所帮忙。

推荐阅读

高并发垂直优化系列:

1. 高并发架构优化:万亿流量下的负载均衡实践

3. 高并发架构优化:从BAT实际案例看消息中间件的妙用

4. 高并发存储优化:细说数据库索引原理及其优化策略

5. 高并发存储优化:许是史上最详尽分库分表文章之一

6. 高并发存储优化:数据库索引优化Explain实战

7. 高并发存储番外:阿里数据中间件源码不完全解析

8. 高并发存储优化:诸多策略,缓存为王

9. 高并发存储番外:redis套路,一网打尽

10. 高并发服务优化:浅谈数据库连接池

11. 高并发服务优化:详解RPC的一次调用过程

12. 高并发服务优化:详解一次由读写锁引起的内存泄漏

13. 高并发服务优化:JVM--工程师进阶必经之路

高并发整体可用性系列:

14. 高并发整体可用性:细说历经磨难的注册中心

15. 高并发整体可用性:大规模集群下的分片管理策略

16. 高并发整体可用性:一文详解降级、限流和熔断

欢迎关注我的公众号“ Coder的技术之路”,欢迎转发分享,原创技术文章第一时间推送。
点赞收藏
Coder的技术之路

欢迎关注同名微信公众号

请先登录,查看2条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

API性能调优
9
2