熔断和降级

大家看一下下面的服务调用场景。C服务和D服务调用B服务，B服务调用A服务。在下面情况1中，服务正常调用。服务在运行过程中，A服务发生故障(网络延时，服务异常，负载过大无法及时响应)，系统变成了情况2由于B服务调用A服务， A服务出故障，导致B服务调用A的代码处也出故障，此时B服务也出故障了，系统变成了情况3 。以此类推，系统最终发展成A、B、C、D所有的服务都出错了，整个系统崩塌了。 这就是雪崩 ，如图所示。 雪崩效应 微服务系统之间通过互相调用来实现业务功能，但每个系统都无法百分之百保证自身运行不出问题。在服务调用中，很可能面临依赖服务失效的问题(网络延时，服务异常，负载过大无法及时响应)，导致服务雪崩，这对于个系统来说是灾难性的。因此需要一个组件，能提供强大的容错能力，当服务发生异常时，能提供保护和控制，把影响控制在较小范围内，不要造成所有服务的雪崩。 熔断开关： 开（走降级的方法，返回一个错误）关闭（正常的调用）半开（测试服务有没有恢复，将半开转为关闭） 从两方面来阐述。 (1)相似性: ①== 目的一致 ==:都是从 可用性和可靠性 着想，为防止系统的整体响应 缓慢甚至崩溃 ，而采用的 技术手段 。 ②== 最终表现类似 ==:对于两者来说，最终让用户体验到的是 某些功能暂时不可达或不可用。 ③ 粒度一致 :都是 服务级别 的。 ④ 自治性要求很高 :熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段。 (2)区别: ①触发原因不一样: 服务熔断一般是某个服务(下游服务)故障引起 ，而 服务降级一般是从整体负荷考虑 ，某些并发量非常大的时期，可以将 某些不核心的服务暂时性 的关闭或者使用静态方法替代，就是牺牲一些服务而使得性能提高。 ②管理目标的层次不一样:熔断是一个框架级的处理，每个服务都需要，而降级一般有业务层级之分，例如，降级一般在服务调用的上层处理。