概要：系统可用性测量、故障原因、宕机原因、故障不可避免。
高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等，也就是所谓的“纲”。通过谈谈分布式系统的设计模式，包括容错、性能、管理等。
(1)容错设计又叫弹力设计，分布式系统的各种“容忍”能力，包括容错能力（服务隔离、异步调用、请求幂等性）、可伸缩性（有 / 无状态的服务）、一致性（补偿事务、重试）、应对大流量的能力（熔断、降级）。可以看到，可用性是弹力设计保障的重点。
(2)管理分布式系统架构的一些设计模式，比如网关方面的，边车模式，还有一些刚刚开始流行的，如 Service Mesh 相关的设计模式。
(3)性能设计篇会讲述一些缓存、CQRS、索引表、优先级队列、业务分片等相关的架构模式。
一、系统可用性测量
容错主要是为了可用性，怎样计算一个系统的可用性的呢？工业界里使用的一个公式：
Availability=MTTF/(MTTF+MTTR)
MTTF 是 平均故障前的时间(Mean Time To Failure)，平均能够正常运行多长时间才发生一次故障。
MTTR 是 Mean Time To Recovery，平均修复时间。
这个公式就是计算系统可用性的(常说的多少个 9),如下表所示。
二、故障原因
难计可用性，影响因素太多了，除了软件设计，还有硬件，第三方服务（如电信联通的宽带 SLA）
所以，正如 SLA 的定义，这不只是一个技术指标，而是一种服务提供商和用户之间的 contract或契约。这种工业级的玩法，就像飞机一样，并不是把飞机造出来就好了，还有大量的无比专业的配套设施、工具、流程、管理和运营。
SLA 的几个 9 就是能持续提供可用服务的级别。不可用的因素分成两种：有计划的，无计划的。
无计划的宕机原因。下图来自 Oracle 的 High Availability Concepts and Best Practices。
有计划的宕机原因。下图来自 Oracle 的High Availability Concepts and Best Practices。
三、宕机原因:
(1)无计划的
系统级故障，包括主机、操作系统、中间件、数据库、网络、电源以及外围设备。
数据和中介的故障，包括人员误操作、硬盘故障、数据乱了。
自然灾害、人为破坏，以及供电问题等。
(2)有计划的
日常任务：备份，容量规划，用户和安全管理，后台批处理应用。
运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护。
升级相关：数据库、应用、中间件、操作系统、网络，包括硬件升级。
再归个类。
1.网络问题。网络链接出现问题，网络带宽出现拥塞……
2.性能问题。数据库慢 SQL、Java Full GC、硬盘 IO 过大、CPU 飙高、内存不足……
3.安全问题。被网络攻击，如 DDoS 等。
4.运维问题。系统总是在被更新和修改，架构也在不断地被调整，监控问题……
5.管理问题。没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步……
6.硬件问题。硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题……
四、故障不可避免
如果你在云平台上，或者使用了“微服务”，面对大量的 IoT 设备以及不受控制的用户流量，
那么系统故障会更为复杂和变态。因为上面这些因素增加了整个系统的复杂度。
不要避免故障，要处理故障的代码当成正常的功能做在架构里写在代码里。
因为我们要干的事儿就是想尽一切手段来降低 MTTR——故障的修复时间。这就是为什么我们把这个设计叫做弹（Resiliency）。
一方面，好情况下，对于用户和运维完全透明，系统自动修复不需要人。
另一方面，如果修复不了，系统能自我保护，不让事态变糟糕。
设计一个分布式系统时，设定了多高的可用性指标？实现的难点在哪里？踩过什么样的坑？你是如何应对的？
