架构设计系列文章，请参见连接。
故障为什么发生？
从单体服务发展到微服务之后就会发现故障是不可避免的了。从分布式计算的故障问题也会相应的加入到系统中。所以从单体服务到微服务之后就变成了不可避免的事情。具体可以从以下几个方面说明。
故障无处不在
《微服务设计》-11.规模化微服务
从统计学上来看，规模化之后故障将成为必然事件。
《生产微服务》-18.更多失效的可能性
大型分布式微服务系统包含大量持续变化的小型服务。对于这种复杂系统，我们要接受系统里的组建必然会失效的事实，而且它们经常的失效。
上面是两本书中说明的故障不可避免的问题。另外一个方面也会有软件的规模化的问题。从敏捷的角度看敏捷规模化成为问题才出现了SAFe，Less这种规模化问题解决方案。那么微服务规模化也是有类似的问题，规模化之后和之前几个服务的情况有质的区别。
微服务特点
而本质上，单体应用到微服务应用的转型就是应用的内部的高风险依赖转化为外部的低风险依赖的过程。是内部复杂度向外部复杂度的转换。因此，微服务架构改造所花费的成本大部分都在处理服务间的通信。
墨菲定律
事情往往会向你所想到的不好的方向发展，只要有这个可能性。即：你越害怕的事情越可能发生。
故障怎么发生？
从上一节看我们没有办法从事前确定故障并解决故障，那怎么在事中解决问题。就变成必须要做的事情。
惊群效应
连锁故障是由于正反馈循环（positive feedback）导致的不断扩大规模的故障。连锁故障可能由于整个系统的一小部分出现故障而引发，进而导致系统其他部分也出现故障。例如，某个服务的一个实例由于过载出现故障，导致其他实例负载升高，从而导致这些实例像多米诺骨牌一样一个以全部出现故障。
同质化问题
之前看过一种理论，同一个磁盘阵列中不能购买同一品牌，同一批次的磁盘组成磁盘阵列。原因是：从理论上来说，同一批次，又是同一使用环境，一起出问题的概率总要比不同批次的概率大点。
也就是在相似的初始条件下，又进行了相似的器件损耗的。造成同样问题的可能性也比较高。将这个问题推广到我们的软件系统中，会发现问题更加严重。因为我们的软件系统中服务都是同一个服务多实例部署的，这样就会发现服务不是相似的那么简单的了，服务是一样的。那么推导下去多实例中每一个服务对于同一件事情的处理方式，响应方式都是一样的。那么一个服务遇到一个错误，这类错误就会发生在所有的实例上。
资源共享
现在都在使用微服务进行服务的业务的管理与调度工作。对于服务来说服务的共享资源就成为不同业务抢占的资源，例如CPU资源，内存资源，数据库连接资源，线程资源，文件描述符资源等等。简单的说就是如果一个业务处理时间较长或卡住那么整体业务就可能被卡住，导致系统假死问题。
分布式系统故障
http://www.xumenger.com/the-eight-fallacies-of-distributed-computing-20180817/
分布式系统相关挑战：https://aws.amazon.com/cn/builders-library/challenges-with-distributed-systems/
故障的定位过程
SRE俗语
不能将碰运气当成战略。
使用grafana+prometheus+alertmanager做可视化。使用apm这样的工具去做详细故障定位。
故障解决办法
故障注定会发生，那该怎么应对与解决？对于业界已经有了很多线程的解决方案。
优雅的服务降级 Graceful Service Degradation
变更管理 Change management
自愈 Self-healing
故障切换缓存 Failover Caching
重试机制 Retry Logic
限流与降级 Rate Limiters and Load Shedders
快速且独立地失败 Fail Fast and Independently
舱壁 Bulkheads
断路器 Circuit Breakers
但对于作者个人来说下面的这些方法也可以有效的解决故障问题。
- 间接依赖
向稳定依赖：通过中间件的方式拆分依赖。例如使用MQ通信，使用Redis作为黑板模式中心仓库。
- 故障隔离
讲故障隔离在笼子中。减少故障的传播过程。使用FF4j这种特性开关解决问题
- 减少共享
Hystrix线程隔离技术解析-线程池，数据库连接隔离。
- 故障注入
混沌工程
