1.雪崩效应
在微服务架构中，服务众多，通常会涉及多个服务层级的调用，一旦基础服务发生故障，很可能会导致级联故障，进而造成整个系统不可用，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费着”的不可用并将这种不可用逐渐放大的过程。
比如在一个系统中，A是服务提供者：B是A的服务消费着，C和D又是B的服务消费者。如果此时A发生故障，则会引起B的不可用，而B的不可用又将导致C和D的不可用，当这种不可用像滚雪球一样逐渐放大的时候，雪崩效应就形成了。
2.熔断器(CircuitBreaker)
熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，就会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。熔断器模式就像是那些容易导致错误操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作维续,或者立即返回错误。熔断器是保护服务高可用的最后一道防线.
3.Hystrix特性
3.1 断路器机制
断路器很好理解， 当Hystrix Command请求后端服务失败数量超过一定比例(默认为50%) ， 断路器会切换到开路状态(Open) .这时所有请求会直接失败而不会发送到后端服务。断路器保持在开路状态一段时间后(默认为5秒) ， 自动切换到半开路状态(HALF-OPEN) .这时会判断下一次请求的返回情况， 如果请求成功， 断路器切回闭路状态(CLOSED) ， 否则重新切換到开路状态(OPEN) .Hystrix的断路器就像我们家庭电路中的保险丝， 一旦后端服务不可用，断路器就会直接切断请求链，避免发送大量无效请求，从而影响系统吞吐量，并且断路器有自我检测并恢复的能力。
3.2 fallback
fallback相当于降级操作.对于查询操作， 我们可以实现一个fallback方法， 当请求后端服务出现异常的时候， 可以使用fallback方法返回的值。fallback方法的返回值一般是设置的默认值或者来自缓存。
3.3 资源隔离
在Hystrix中， 主要通过线程池来实现资源隔离， 通常在使用的时候我们会根据调用的远程服务划分出多个线程池。例如， 调用产品服务的Command放入A线程池， 调用账户服务的Command放入B线程池， 这样做的主要优点是运行环境被隔离开了。这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽， 也不会对系统的其他服务造成影响，但是带来的代价就是维护多个线程池会对系统带来额外的性能开销.如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题， 就可以使用Hystrix的信号模式(Semaphores) 来隔离资源。
5.Hystrix Dashboard
Hystrix-dashboard是一款针对Hystrix进行实时监控的工具， 通过Hystrix Dashboard我们可以直观地看到各Hystrix Command的请求响应时间、请求成功率等数据。
6.Spring Cloud Turbine
上面我们集成了Hystrix Dashboard， 使用Hystrix Dashboard可以看到单个应用内的服务信息。显然这是不够的，我们还需要一个工具能让我们汇总系统内多个服务的数据并显示到Hystrix Dashboard上， 这个工具就是Turbine。
原文地址：https://www.cnblogs.com/xc-xinxue/p/12543555.html