分布式应用存在的问题：
- 复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某个时候不可避免地失败。多个微服务调用时，如果出现某个微服务响应时间过长或者不可用，顶级服务就会占用越来越多的资源，进而引起“雪崩效应”。
- 高流量时，可能瞬间或者几秒钟使得服务器资源饱和，进而导致服务之间延迟增加、线程和其他资源紧张，整个服务不可用。
这些都需要对故障和延迟进行隔离和管理，以到达单个服务的失败，不会导致整体系统的崩溃。
断路器：Hystrix客户端
较低级别的服务中的服务故障可能导致用户级联故障。当对特定服务的呼叫达到一定阈值时（Hystrix中的默认值为5秒内的20次故障），电路打开，不进行调用。在错误和开路的情况下，开发人员可以提供后备。
开放式电路会停止级联故障，并允许不必要的或失败的服务时间来愈合。Fallback 可以是另一个Hystrix保护的调用，静态数据或一个正常的空值。回退可能被链接，所以第一个 Fallback 使一些其他业务调用又回到静态数据。
服务熔断
集成在提供方。
引包：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
@EnableCircuitBreaker //开启，对hystrixR熔断机制的支持
一个服务出现异常，向调用方法返回一个符合预期的、可处理的备选响应（Fallback），而不是长时间的等待或者抛出无法处理的异常。
Hystrix 会进行服务降级，进而熔断该节点的微服务调用，快速返回“错误”的响应信息。
@Component
public class StoreIntegration {
@HystrixCommand(fallbackMethod = "defaultStores")
public Object getStores(Map<String, Object> parameters) {
//do stuff that might fail，throw exception
}
public Object defaultStores(Map<String, Object> parameters) {
return /* something useful */;
}
}
服务降级
将一些服务先关掉，等资源空余，再启动对应服务。
为什么要降级？
上面的例子，有缺点：处理逻辑放到提供者，硬编码，高耦合，且容易出现方法膨胀。
另外，我们将主逻辑的额外逻辑放到主逻辑中，不合适，应该使用面向切面编程思想，将熔断逻辑抽出来。
集成在消费端。一个实现 FallbackFactory 接口的类，记得加上 @Component，重写对应接口的降级处理逻辑。客户端设置 feign.hystrix.enabled=true。
@Component // 不要忘记添加，不要忘记添加
public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService> {
@Override
public DeptClientService create(Throwable throwable) {
return new DeptClientService() {
@Override
public Dept get(long id) {
return new Dept().setDeptNo(id)
.setDeptName("该ID：" + id + "没有没有对应的信息,Consumer客户端提供的降级信息,此刻服务Provider已经关闭")
.setDbSource("no this database in MySQL");
}
@Override
public List<Dept> list() {
return null;
}
@Override
public boolean add(Dept dept) {
return false;
}
};
}
}
这样，服务降级逻辑集成到了消费端，把提供者暂停服务或者熔断后，也能立即返回 Fallback，而不会出现故障、占用资源、雪崩。
断路器：Hystrix仪表板
Hystrix的主要优点之一是它收集关于每个HystrixCommand的一套指标。Hystrix仪表板以有效的方式显示每个断路器的运行状况。
/hystrix.stream 监控单个实例端点，/turbine stream 监控相关的实例端点。比如 a 调用 b，b 调用 c等等，监控 a/turbine stream，会将 a、b、c 相关的端点运行情况都展示出来。
