本文转载自微信公众号《我的大脑是炸鱼》，作者陈建宇。转载本文请联系脑筋急转弯公众号。《微服务之战》是一系列关于微服务设计思维的主题，主要针对微服务后出现的一些矛盾/冲突点，并不涉及具体的知识点深入。如果您有任何问题或建议，欢迎随时交流。在《微服务的战争：统一且标准化》，经过数周的跨部门与不同业务组、不同业务部门的讨论，最终给出了初步的标准化方案。大家愉快地使用着内部统一的框架，疯狂地创造着新的服务。一段时间后，服务调用链变成了下图：服务之间有多个内部调用，服务A="服务B="服务C="服务D，服务E="服务B，服务F="服务E，也就是有多个流量入口，依赖同一个服务，在后台服务和服务中，总有业务服务，公共服务，基础服务的类型。但是一晚上，突然发现BFF的调用到后台服务逐渐不正常，客户给你截图反映问题，你发现不对：单从性能上看，你发现BFF调用服务A的速度极慢，你不不知道为什么，没了。。。刚想到服务A有问题，就想到重启Universal，看日志平台和链接跟踪系统，发现错误日志很多，速度慢，这让你有点震惊，你不知道从哪儿开始。如何才能做到这一点？级联故障和雪崩其实这是一个非常经典的级联故障，最终导致系统雪崩的再现。单从上面的拓扑来看，问题之一出在服务B上：服务B本身作为服务A和服务F的两个流量入口，必须经过。它必须至少是一个公共服务，但它还依赖于其他多个服务。所以，如果服务C和服务D其中一个出现问题，没有熔断措施，就会出现级联故障，系统会逐渐崩溃，最后雪崩：服务D所依赖的对外接口失效，他不doanything因此，控制权扩散到所有调用他的服务，其中自然包括服务B，所以系统雪崩最终发生。其中最经典的就是Gohttp客户端调用默认是没有设置Timeout的，所以只要有失败，记住这种“坑”就够了。毕竟崩溃是“慢”的，错误日志也很多。一种常见的解决方案是根据特定的规则/模式进行融合和降级，以避免请求堆积：超时控制。呼叫率慢。比例错误。自适应（例如：负载条件等）。当然，这只是壮士断腕，后续的措施还包括监控告警，通知相应的开发人员进行处理。并且需要提前对降级模块的业务逻辑进行处理，这样才能轻而易举地度过这场危机。综上所述，在分布式应用中，级联故障和雪崩是非常常见的。一些开发者在模块设计时可能没有意识到这个问题。该链条变得非常长且数量众多。所以建议配套设施和限流熔断措施及时跟上，不然面对一大堆错误日志还是很无奈。
