41 | 弹力设计篇之“认识故障和弹力设计”
下载APP
关闭
渠道合作
推荐作者
41 | 弹力设计篇之“认识故障和弹力设计”
2018-02-20 陈皓 来自北京
《左耳听风》
课程介绍
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="1142" height="640"><rect fill-opacity="0"/></svg>)
讲述：杨超
时长09:24大小8.59M
你好，我是陈皓，网名左耳朵耗子。
我前面写的《分布式系统架构的本质》系列文章，从分布式系统的业务层、中间件层、数据库层等各个层面介绍了高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等，也就是所谓的“纲”。通过这个“纲”，你能够按图索骥，掌握分布式系统中每个部件的用途与总体架构思路。
为了让你更深入地了解分布式系统，在接下来的几期中，我想谈谈分布式系统中一些比较关键的设计模式，其中包括容错、性能、管理等几个方面。
容错设计又叫弹力设计，其中着眼于分布式系统的各种“容忍”能力，包括容错能力（服务隔离、异步调用、请求幂等性）、可伸缩性（有 / 无状态的服务）、一致性（补偿事务、重试）、应对大流量的能力（熔断、降级）。可以看到，在确保系统正确性的前提下，系统的可用性是弹力设计保障的重点。
管理篇会讲述一些管理分布式系统架构的一些设计模式，比如网关方面的，边车模式，还有一些刚刚开始流行的，如 Service Mesh 相关的设计模式。
性能设计篇会讲述一些缓存、CQRS、索引表、优先级队列、业务分片等相关的架构模式。
我相信，你在掌握了这些设计模式之后，无论是对于部署一个分布式系统，开发一个分布式的业务模块，还是研发一个新的分布式系统中间件，都会有所裨益。
今天分享的就是《分布式系统设计模式》系列文章中的第一篇《弹力设计篇之“认识故障和弹力设计”》。
系统可用性测量
对于分布式系统的容错设计，在英文中又叫 Resiliency（弹力）。意思是，系统在不健康、不顺，甚至出错的情况下有能力 hold 得住，挺得住，还有能在这种逆境下力挽狂澜的能力。
要做好一个设计，我们需要一个设计目标，或是一个基准线，通过这个基准线或目标来指导我们的设计，否则在没有明确基准线的指导下，设计会变得非常不明确，并且也不可预测，不可测量。可测试和可测量性是软件设计中非常重要的事情。
我们知道，容错主要是为了可用性，那么，我们是怎样计算一个系统的可用性的呢？下面是一个工业界里使用的一个公式：
其中，
MTTF 是 Mean Time To Failure，平均故障前的时间，即系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高，MTTF 越长。（注意：从字面上来说，看上去有 Failure 的字样，但其实是正常运行的时间。）
MTTR 是 Mean Time To Recovery，平均修复时间，即从故障出现到故障修复的这段时间，这段时间越短越好。
这个公式就是计算系统可用性的，也就是我们常说的，多少个 9，如下表所示。
根据上面的这个公式，为了提高可用性，我们要么提高系统的无故障时间，要么减少系统的故障恢复时间。
然而，我们要明白，我们运行的是一个分布式系统，对于一个分布式系统来说，要不出故障简直是太难了。
故障原因
老实说，我们很难计算我们设计的系统有多少的可用性，因为影响一个系统的因素实在是太多了，除了软件设计，还有硬件，还有第三方服务（如电信联通的宽带 SLA），当然包括“建筑施工队的挖掘机”。
所以，正如 SLA 的定义，这不只是一个技术指标，而是一种服务提供商和用户之间的 contract 或契约。这种工业级的玩法，就像飞机一样，并不是把飞机造出来就好了，还有大量的无比专业的配套设施、工具、流程、管理和运营。
简而言之，SLA 的几个 9 就是能持续提供可用服务的级别。不过，工业界中，会把服务不可用的因素分成两种：一种是有计划的，一种是无计划的。
可以看到，宕机原因主要有以下这些。
无计划的
系统级故障，包括主机、操作系统、中间件、数据库、网络、电源以及外围设备。
数据和中介的故障，包括人员误操作、硬盘故障、数据乱了。
还有自然灾害、人为破坏，以及供电问题等。
有计划的
日常任务：备份，容量规划，用户和安全管理，后台批处理应用。
运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护。
升级相关：数据库、应用、中间件、操作系统、网络，包括硬件升级。
我们再给它们归个类。
网络问题。网络链接出现问题，网络带宽出现拥塞……
性能问题。数据库慢 SQL、Java Full GC、硬盘 IO 过大、CPU 飙高、内存不足……
安全问题。被网络攻击，如 DDoS 等。
运维问题。系统总是在被更新和修改，架构也在不断地被调整，监控问题……
管理问题。没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步……
硬件问题。硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题……
故障不可避免
如果你看过我写过的《分布式系统架构的本质》和《故障处理》这两个系列的文章，就会知道要管理好一个分布式系统是一件非常难的事。对于大规模的分布式系统，出现故障基本上就是常态，甚至还有些你根本就不知道会出问题的地方。
在今天来说，一个分布式系统的故障已经非常复杂了，因为故障是分布式的、多米诺骨牌式的。就像我在《分布式系统架构的本质》中展示过的这个图一样。
如果你在云平台上，或者使用了“微服务”，面对大量的 IoT 设备以及不受控制的用户流量，那么系统故障会更为复杂和变态。因为上面这些因素增加了整个系统的复杂度。
所以，要充分地意识到下面两个事。
故障是正常的，而且是常见的。
故障是不可预测突发的，而且相当难缠。
所以，亚马逊的 AWS 才会把 Design for Failure 作为其七大 Design Principle 的重点。这告诉我们，不要尝试着去避免故障，而是要把处理故障的代码当成正常的功能做在架构里写在代码里。
因为我们要干的事儿就是想尽一切手段来降低 MTTR——故障的修复时间。
这就是为什么我们把这个设计叫做弹力（Resiliency）。
一方面，在好的情况下，这个事对于我们的用户和内部运维来说是完全透明的，系统自动修复不需要人的干预。
另一方面，如果修复不了，系统能够做自我保护，而不让事态变糟糕。
这就是所谓的“弹力”——能上能下。这让我想到三国杀里赵云的技能——“能进能退乃真正法器”，哈哈。
小结
好了，今天的内容就到这里。相信通过今天的学习，你应该已经明白了弹力设计的真正目的，并对系统可用性的衡量指标和故障的各种原因有所了解。下一讲，我们将开始罗列一些相关的设计模式。
在这节课的最后，很想听听大家在设计一个分布式系统时，设定了多高的可用性指标？实现的难点在哪里？踩过什么样的坑？你是如何应对的？
文末给出了《分布式系统设计模式》系列文章的目录，希望你能在这个列表里找到自己感兴趣的内容。
弹力设计篇
管理设计篇
性能设计篇
分享给需要的人，Ta购买本课程，你将得29元
生成海报并分享赞 20
提建议
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
40 | 编程范式游记（11）- 程序世界里的编程范式
下一篇
42 | 弹力设计篇之“隔离设计”
精选留言(39)
华烬2018-02-26看到挖掘机的时候我笑了，印象中真的经历过光纤被挖断的故障29
qgymje2020-06-18在听这文章的时候，我想到了可能容错这个概念，是统一分布式系统所有知识的核心，几乎所有的设计方案都是围绕着容错进行的，无论是简单的Supervisor启动服务进程，K8S里Pod的重启机制，还是应用层面的限流，熔断，降级，都是为了保证系统的可用性，也就是所谓的弹性；而幂等，补偿，以及数据复制等设计方案，是为了保证系统的正确性，也从另一方案说明了系统的容错能力。共 1 条评论12
songyy2018-02-21我觉得自己缺少解决 大规模 高可用 分布式 问题的经验，一直希望在这方面进行深挖但无奈工作范围限制，没有相关的问题可以遇到。期待能在这个系列之中看到更多的例子 😁10
迷途书童2020-06-13弹力这个词是左耳朵耗子翻译的一个词，大家应该慎用，要么直接用Resiliency，要么用容错。 因为在很多公司里，很少直接说，我们这个系统支持弹力设计。从感性的角度来说，容错这个词很难与弹力划上等号共 2 条评论9
第一装甲集群司令克莱...2020-10-26看到挖掘机挖端光纤的时候，太有意思了。有一次我们的系统不稳定，网络抖动故障，持续几天就出现那个点，上下游系统怎么查也查不出来。最后发现了，那个点下班时间，人员过多走过那条机房外面的路，通过地板砖踩踏，影响李里面的光纤网线了。共 2 条评论6
一飞2019-03-28异步调用为啥是容错设计？ 应该是提高性能的一种策略。共 1 条评论5
885912018-12-02很多公司应该支撑不到挖掘机这个阶段就倒闭了。4
蓝海2018-02-22耗子哥可否在后面出一篇有关gcc优化带来的相关问题（各种崩溃，优化选项对程序做了哪些假设，哪些"非标准"的代码会导致优化错误），如何判断崩溃是由于优化，二进制不兼容，链接错误导致，而非一般的代码错误。gcc的优化选项看了官网说明很多遍，但说明过于简洁（编译原理只停留在前端印象，优化技术生疏），想了解的感性一些。这些bug问题解决都很费力，想归纳出一条方法经验论，怎样的代码要求才能对各种优化级别不出错（gcc本身bug除外）。以上的问题以及问题本身是否成立，想请耗子哥指导展开共 2 条评论4
楊_宵夜2018-02-22耗子叔每篇文章真是干货十足。3
Geek_7b13832020-04-27故障是正常的，不可预测突发的，需要弹力（Resiliency）： 在好的情况下，这个事对于我们的用户和内部运维来说是完全透明的，系统自动修复不需要人的干预。 如果修复不了，系统能够做自我保护，而不让事态变糟糕。 我们设定可用率99.99% 实现的难点尽一切努力减少故障恢复时间 按照分类，系统无计划的系统级故障等做好智能监控和自愈能力，自然灾害、人为破坏，以及供电问题等有异地容灾，第三方规避风险。有计划的，流程加全链路监控保证，同时事前检查备份，事中双人复核操作，事后各位措施验证和人工验证，智能监控探测等，异常情况回滚方案的设计原则。展开2
业余爱好者2020-03-01服务端是一个多用户系统，从这点就可以知道对后端可用性的高要求。服务端应提供7/24的不间断服务。然而由于分布式系统由多台机器组成，出现故障就不是不可避免的。可以说分布式系统的架构就是为了解决这个矛盾。 服务调度是值一个服务有多个实例。不至于一台宕机整体服务不可用。 全栈监控是整个系统的眼睛，观察整个系统的状况，出现问题做报警。因而需要在业务逻辑中加入监控卖点，向监控系统报告自己的情况，还要做好审计日志以及异常日志，以便故障之后复现原因恢复系统运行。 流量调度是分担每个服务，进程等实例的访问压力。状态与数据调度是在多个副本之间对Ｃ,A做出权衡。展开2
高彬2020-03-22老师的课都是经验啊 赞1
slark2020-01-16弹力设计，保持系统容错性。错误不可避免，如何在错误发生后恢复或者记录关键信息便于恢复才是我们应该达到的目标。对于故障，同时也要区分可能导致故障的场景，针对性地处理1
Sdylan2019-12-23对于分布式系统，故障是不避免的。根据公式：我们程序鲁棒性越高越好，故障恢复时长越短越好。如何缩短故障恢复时长，自动化+流程化。1
疾风紫狼2019-08-08能进能退乃真正法器可还行。共 2 条评论1
edisonhuang2019-07-01分布式系统出故障是不可避免的，弹力设计的关键是要提高系统的可用性，提高MTTF，提高MTTF，一是拉长系统稳定运行时间，一是减少故障恢复时间。 由于分布式系统故障呢普遍性，因此在分布式系统设计的和开发的过程中，就要把故障当作不可或缺的一环来处理，尽可能让故障恢复过程自动化，从而真正提高系统可用1
卢俊杰 _JAY2018-02-20以前或多或少写过一些数据库, MQ自动重连的代码，不过还没有一个整体的认识，多谢作者把这个事情系统化，条理清晰多了1![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="72" height="72"><rect fill-opacity="0"/></svg>)
KK2021-08-18MTTF = MTTF/(MTTF+MTTR)- KK2021-08-18弹力设计！
刘旭2021-03-27韧性设计
