弹力设计简介

弹力设计又叫容错设计，其中着眼于分布式系统的各种“容忍”能力，包括容错能力（服务隔离、异步调用、请求幂等性）、可伸缩性（有 / 无状态的服务）、一致性（补偿事务、重试）、应对大流量的能力（熔断、降级）。可以看到，在确保系统正确性的前提下，系统的可用性是弹力设计保障的重点。

系统可用性测量

对于分布式系统的容错设计，在英文中又叫 Resiliency（弹力）。意思是，系统在不健康、不顺，甚至出错的情况下有能力 hold 得住，挺得住，还有能在这种逆境下力挽狂澜的能力。

要做好一个设计，我们需要一个设计目标，或是一个基准线，通过这个基准线或目标来指导我们的设计，否则在没有明确基准线的指导下，设计会变得非常不明确，并且也不可预测，不可测量。可测试和可测量性是软件设计中非常重要的事情。

我们知道，容错主要是为了可用性，那么，我们是怎样计算一个系统的可用性的呢？下面是一个工业界里使用的一个公式：

                                Availability= MTTF / (MTTF+MTTRMTT)

其中，

MTTF 是 Mean Time To Failure，平均故障前的时间，即系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高，MTTF 越长。（注意：从字面上来说，看上去有 Failure 的字样，但其实是正常运行的时间。）

MTTR 是 Mean Time To Recovery，平均修复时间，即从故障出现到故障修复的这段时间，这段时间越短越好。

这个公式就是计算系统可用性的，也就是我们常说的，多少个 9。

根据上面的这个公式，为了提高可用性，我们要么提高系统的无故障时间，要么减少系统的故障恢复时间。

然而，我们要明白，我们运行的是一个分布式系统，对于一个分布式系统来说，要不出故障简直是太难了。

故障原因

老实说，我们很难计算我们设计的系统有多少的可用性，因为影响一个系统的因素实在是太多了，除了软件设计，还有硬件，还有第三方服务（如电信联通的宽带 SLA），当然包括“建筑施工队的挖掘机”。

所以，正如 SLA 的定义，这不只是一个技术指标，而是一种服务提供商和用户之间的 contract 或契约。这种工业级的玩法，就像飞机一样，并不是把飞机造出来就好了，还有大量的无比专业的配套设施、工具、流程、管理和运营。

简而言之，SLA 的几个 9 就是能持续提供可用服务的级别。不过，工业界中，会把服务不可用的因素分成两种：一种是有计划的，一种是无计划的。

无计划的

系统级故障，包括主机、操作系统、中间件、数据库、网络、电源以及外围设备。
数据和中介的故障，包括人员误操作、硬盘故障、数据乱了。
还有自然灾害、人为破坏，以及供电问题等。

有计划的

日常任务：备份，容量规划，用户和安全管理，后台批处理应用。
运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护。
升级相关：数据库、应用、中间件、操作系统、网络，包括硬件升级。

我们再给它们归个类。

1、网络问题。网络链接出现问题，网络带宽出现拥塞……
2、性能问题。数据库慢 SQL、Java Full GC、硬盘 IO 过大、CPU 飙高、内存不足……
3、安全问题。被网络攻击，如 DDoS 等。
4、运维问题。系统总是在被更新和修改，架构也在不断地被调整，监控问题……
5、管理问题。没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步……
6、硬件问题。硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题……

故障不可避免

管理好一个分布式系统是一件非常难的事。对于大规模的分布式系统，出现故障基本上就是常态，甚至还有些你根本就不知道会出问题的地方。在今天来说，一个分布式系统的故障已经非常复杂了，因为故障是分布式的、多米诺骨牌式的。

所以，要充分地意识到下面两个事。

故障是正常的，而且是常见的。
故障是不可预测突发的，而且相当难缠。

因为我们要干的事儿就是想尽一切手段来降低 MTTR——故障的修复时间。

这就是为什么我们把这个设计叫做弹力（Resiliency）。

一方面，在好的情况下，这个事对于我们的用户和内部运维来说是完全透明的，系统自动修复不需要人的干预。

另一方面，如果修复不了，系统能够做自我保护，而不让事态变糟糕。

这就是所谓的“弹力”——能上能下。