因为应用是由众多相互调用的微服务组合而成的，所以一个服务中的故障可能会蔓延到整个系统。
连锁故障是分布式应用中一种很常见的故障类型。连锁故障是一个“正反馈”的例子：某个事件对系统产生了干扰进而造成一些影响，而这个影响反过来又强化了最初的干扰程度。
设想一下发生在动物世界中的大逃亡现象：在茫茫的非洲大草原上，一只动物因为受到惊吓开始跑起来，这一跑导致其他动物也受到惊吓，最终所有动物都朝着一个方向狂奔而逃。在微服务应用中，服务过载也会导致多米诺骨牌效应：一个服务出现故障会导致上游服务的失败量增加，相应地，上上游的服务失败量也会增多，以此类推。最坏的情况就是系统大范围不可用。
假设holding服务的调用频率是1000次（QPS）。如果系统中有两个holding服务实例，那么每个复本实例会收到500QPS。
holding服务(多副本)会查询transaction服务和market-data服务来拼装自己的响应结果。每次对holding服务的调用会生成两个新的调用：分别是调用transaction服务(多副本)和调用market-data服务(多副本)。
比如说，系统出现故障导致transaction服务的一个实例不可用了。这时，负载均衡服务器就会将请求都路由到剩下的那个实例，这个实例要处理1000QPS的请求。
但是，承载力的下降会导致服务不再能处理这个水平的请求量。由于服务采用了Web服务的部署方式，使得负载上的变化会导致请求开始排队，进而响应时延越来越高。相应地，时延开始超过holding服务所期望的最大查询等待时间。或许，transaction服务开始丢弃一些请求。
在请求失败以后，服务通过重试操作来再次向协作方发起请求并不是不合理的动作。现在，设想一下，holding服务把所有发给transaction服务的超时或者失败的请求都重试一遍。这会进一步增加transaction服务仅存的资源的负载——它除了需要处理正常的请求，同时还需要处理不断增多的重试请求。holding服务的响应时间也会相应地变得更长，因为它要等待transaction服务的响应。
这种反馈循环——执行失败的请求引发更大规模的请求，导致更高的失败率——使系统进一步恶化。随着依赖于transaction服务和holding服务的其他服务也出现故障，整个系统完全停止工作。最初单个服务的故障产生多米诺效应，其他许多服务的响应时间和可用性也都开始变差。最坏的情况是transaction服务的影响不断累积，最终导致服务完全不可用。
虽然服务过载是连锁故障最常见的原因，但却不是导致连锁故障的唯一原因。一般来说，错误率增加、响应时间变慢都会导致服务出现异常，这也就增加了互相依赖的服务之间出现故障的可能性。
我们可以采用一些方法来控制微服务应用出现连锁故障，其中有包括断路器、后备方案、压力测试和容量规划、回退和重试以及适当的超时时间。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论