左耳听风_042_41_弹力设计篇之认识故障和弹力设计
你好，我是陈浩网名英，做我的house.前面写的分布式系统架构的本质系列的文章呢，从分布式系统的业务层、中间件层，还有数据库层等等。
各个层面介绍了高并发架构、异地多活架构、高器化架构、微服务架构、高可用架构，还有弹性化架构等等。
啊，也就是所谓的刚。
那通过这个纲呢，你就能够按图索骥，掌握分布式系统中每个部件的用途和总体的架构思路。
那为了让你能够更深入的了解分布式系统啊，在接下来的几析中呢，我想谈一谈分布式系统中一些比较关键的设计模式，那其中呢就包括容错性能和管理等等几个方面。
那容错设计呢又叫做弹力设计，它着眼于分布式系统的各种容忍能力，包括容错能力、可伸缩性一致性，还有应对大流量的能力。
可以看到，在确保系统正确性的前提下，系统的可用性是弹力设计保障的重点。
那管理篇呢我会讲述一些管理分布式系统架构的一些设计模式，比如网关方面的编车模式，还有一些刚刚开始流行的，还比如service matsh相关的设计模式。
而性能设计篇呢，我会讲述一些缓存CQRS、缩引表、优先级队列啊，还有业务分片等相关的架构模式。
我相信啊你在掌握了这些设计模式之后呢，无论是部署一个分布式系统开发一个分布式的业务模块啊，还是研发一个新的分布式系统的中间件，都会很有帮助。
那我今天分享的呢就是分布式系统模式系列文章中的第一篇弹力设计篇之认识故障和弹力设计。
那首先呢我们来讲一讲系统可用性的测量。
对于分布式系统的容错设计呢，在英文中啊又叫做resilluancy啊，也就是弹力。
意思呢就是系统啊在不健康不顺甚至出错的情况下，还有能力hold得住，挺得住。
还有能在这种逆境下力挽狂澜的能力。
那要做好一个设计，我们需要一个设计目标啊或者一个基准线，通过这个基准线或者目标啊来指导我们的设计。
那如果没有明确的基准线的指导设计呢，就会变得非常不明确，而且呢也不可预测，不可测量，可测试和可测量性是软件设计中非常重要的事情。
我们知道容错呢主要是为了可用性。
那么我们怎么计算一个系统的可用性呢？这里呢有一个工业界使用的一个公式，availability等于MTTF除以MTTF,加上MTT二。
在这个公式中呢，MTTF是meantime to failure.意思呢是平均故障前的时间，也就是系统啊平均能够正常运行多长时间才发生一次故障，那系统的可靠性越高啊，MTTF就越长。
那MTTR呢，是meantime to recovery,意思呢是平均修复时间，也就是从故障出现到故障修复的这段时间。
那这段时间呢越短越好。
那这个公式呢就是计算系统可用性能，也就是我们常说的多少个九。
那具体的内容呢，你可以参考文中的这张表格。
那根据刚刚这个公式呢，我们知道为了提高可用性，我们要么提高系统的无故障时间，要么呢减少系统的故障恢复时间。
但是呢我们要明白，我们运行的是一个分布式系统，对于一个分布式系统来说呢，要不出故障简直是太难了。
那接着呢我们就来分析一下故障的原因。
老实说呢，我们很难计算我们设计的系统啊有多少的可用性。
因为影响一个系统的因素实在是太多了，除了软件的设计，还有硬件，还有第三方的服务。
呃，当然呢也包括建筑施工队的挖掘机。
所以呢正如SLA的定义，这个不只是一个技术指标，而是一种服务提供商和用户之间的contract契约。
那这种工业级的玩法就像飞机一样，并不是把飞机造出来就好了。
还有大量的无比专业的配套设施、工具、流程管理和运营。
那简单来说呢，SLA的几个九就是能持续提供可用服务的级别。
不过在工业中呢会把服务不可用的因素啊分成两种，一种是有计划的，一种呢是无计划的。
我在文中呢给你放了两张图，第一张啊表示的是无计划的宕机原因。
而第二张图表示的呢是有计划的宕机原因。
那这两张图呢都来自oracle的high availability concepts and best practice.从这两张图我们可以看到无计划的宕期，原因呢有三个方面。
第一呢是系统级故障，包括主机、操作系统、中间件、数据库、网络电源以及外围的设备。
那第二呢是数据和中介的故障，包括人员误操作、硬盘故障和数据混乱。
那第三呢是自然灾害人为破坏啊，还有供电问题等等。
而有计划的宕机原因呢同样也有三个方面。
那第一呢是日常任务，包括备份啊、容量规划用户和安全管理，后台批处理应用等等。
那第二呢是运维相关，包括数据库维护、应用维护、中间线维护、操作系统维护，还有网络维护。
那第三呢是升级相关，包括数据库升级、应用升级，还有中间件、操作系统、网络和硬件的升级。
我们啊再给它归个类。
那总结起来啊有这样的六类问题。
那第一呢是网络问题，比如网络链接出现问题，网络带宽啊，出现拥塞等等。
那第二呢是性能问题，比如数据库mysql、 java负GC、硬盘、IO过大，CPU飙高，还有内存不足等等。
那第三呢是安全问题，比如被网络攻击了，比如d dos等等。
那第四呢是运维问题，比如系统啊总是在更新和修改架构啊，也在不断的被调整，还有监控问题等等。
那第五呢是管理问题，比如没有梳理出关键服务和服务的依赖关系，运行信息啊没有和控制系统同步等等。
那第六类呢是硬件问题，包括硬件损坏、网卡出问题、交换机出问题、机房掉电，还有挖掘机问题啊等等。
那如果你看过我写的分布式系统架构的本质和故障，处理这两个系列的文章，就会知道要管理好一个分布式系统啊，是一件非常难的事儿。
对于大规模的分布式系统啊，出现故障基本上就是常态，甚至还有一些你根本就不知道会出问题的地方。
在今天来说呢，一个分布式系统的故障已经非常复杂了，因为故障是分布式的，多米诺骨牌式的。
就像我在分布式系统架构的本质中展示过的这张图一样，我在文中呢又贴了一次。
那如果你在云平台上啊或者使用的微服务，面对大量的LT设备和不受控制的用户流量，那么系统的故障会更为复杂和变态。
因为上面这些因素啊增加了整个系统的复杂度，所以呢我们要充分的意识到这两个事儿。
那第一呢，故障是正常的，而且啊是常见的那第二呢，故障是不可预测突发的，而且啊相当难缠。
所以呢亚马逊的AWS才会把design for failure作为它的七大design principle的重点。
这就告诉我们，不要尝试着去避免故障，而是要把处理故障的代码当成正常的功能做在架构里，写在代码里。
因为我们要干的事儿啊，就是想尽一切手段来降低MTTR啊，也就是故障的修复时间。
这就是为什么我们把这个设计啊叫做弹力。
那一方面呢，在好的情况下，这个事儿对于我们的用户和内部运维来说是完全透明的。
系统的自动修复啊，不需要人的干预。
那另一方面呢，如果修复不了系统啊，能够做自我保护而不让事态啊变得更糟糕。
那这个呢就是所谓的弹力能上能下。
这就让我想到三国杀里赵云的技能能进能退乃真正法器哈。
好了，今天的内容呢就到这里。
相信通过今天的学习啊，你应该已经明白了弹力设计的真正目的，并且对系统可用性的衡量指标和故障的各种原因啊都有所了解。
那下节课呢我们会开始罗列一些相关的设计模式。
在这节课的最后呢，我很想听一听大家在设计一个分布式系统的时候，设定了多高的可用性指标，实现的难点在哪里？又踩过什么样的坑，你呢？又是如何应对的那文末呢给出了分布式系统设计模式系列的文章的目录啊，希望你能在这个列表里啊找到自己感兴趣的内容。