开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 6 天，点击查看活动详情 分布式系统中一些比较关键的设计模式，其中包括容错、性能、管理等几个方面。
定义
容错设计：系统在不健康或者出错情况下能够挺住，还有能在逆境下力挽狂澜恢复正常的能力，提高系统可用性。包括容错能力（服务隔离、异步调用、请求幂等性）、可伸缩性（分为有状态服务和无状态服务）、一致性（补偿、重试）、应对大流量的能力（熔断、降级）。确保系统正确性的前提下，系统可用性是弹力设计保障重点。
衡量
系统可用性公式：
其中：
MTTF 是 Mean Time To Failure，平均故障前的时间，即系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高，MTTF 越长。（注意：从字面上来说，看上去有 Failure 的字样，但其实是正常运行的时间。）
MTTR 是 Mean Time To Recovery，平均修复时间，即从故障出现到故障修复的这段时间，这段时间越短越好。
我们常说多少个9:
SLA 的定义，这不只是一个技术指标，而是一种服务提供商和用户之间的 contract 或契约。比如向客户保证2个9的SLA：如系统正常运行了96分钟，发生故障，那么必须在4分钟内恢复，才能达到2个9的可用性，如果未恢复是需要赔付客户的。
所以根据上面的这个公式，为了提高可用性，我们要么提高系统的无故障时间，要么减少系统的故障恢复时间。
故障因素
影响分布式系统故障因素：软件、硬件、第三方服务（运营商网络的SLA），工业界中，服务不可用的因素分为两种：一种是有计划的，一种是无计划的。
无计划宕机：
- 系统级故障，包括主机、操作系统、中间件、数据库、网络、电源以及外围设备。
- 数据和中介的故障，包括人员误操作、硬盘故障、数据乱了。
- 还有自然灾害、人为破坏，以及供电问题等。
有计划宕机：
- 日常任务：备份，容量规划，用户和安全管理，后台批处理应用。
- 运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护。
- 升级相关：数据库、应用、中间件、操作系统、网络，包括硬件升级
基础设施：
- 网络问题。网络链接出现问题，网络带宽出现拥塞……
- 性能问题。数据库慢 SQL、Java Full GC、硬盘 IO 过大、CPU 飙高、内存不足……
- 硬件问题。硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题……
人为问题：
- 安全问题。被网络攻击，如 DDoS 等。
- 运维问题。系统总是在被更新和修改，架构也在不断地被调整，监控问题……
- 管理问题。没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步……
对于大规模的分布式系统，出现故障基本上就是常态，甚至还有些你根本就不知道会出问题的地方。在今天来说，一个分布式系统的故障已经非常复杂了，因为故障是分布式的、多米诺骨牌式的。如果你在云平台上，或者使用了“微服务”，面对大量的** IoT设备以及不受控制的用户流量**，那么系统故障会更为复杂和变态。因为上面这些因素增加了整个系统的复杂度。
故障是必可避免的，所以能做的就是把能处理故障的代码当成正常功能做到架构设计里，让系统不至于因为一个故障搞宕机掉，并且想尽一切手段降低MTTR-故障修复时间。
- 可以修复故障：这个事对于我们的用户和内部运维来说是完全透明的，系统自动修复不需要人的干预。
- 不能修复故障：系统能够做自我保护，而不让事态变糟糕。
