微服务架构--SpringCloud（7）
Hystrix
*断路器、熔断器 Hystrix 避免单口调用导致全局宕掉
*Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
*“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是及长时间的等待或者抛出调用方法无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
*分布式系统面临的问题：
*复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败.
*服务雪崩：
*多个为服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。
*对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序号可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
*Hystrix的功能：
*服务降级
*服务熔断
*服务限流
*接近实时的监控
*。。。
*官网资料：https://github.com/Netflix/Hystrix/wiki/How-To-Use
*服务熔断：
*熔断机制是应对雪崩效应的一种微服务链路保护机制。
*当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的应用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。
1.新建microservicecloud-provider-dept-hystrix-8001
2.复制8001工程
3.修改pom 添加
4.修改yml
service-url:
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
# 单机版 defaultZone : http://localhost:7001/eureka
instance:
instance-id: microservicecloud-provider-dept-hystrix-8001
prefer-ip-address: true #访问路径可以显示IP地址
5.修改DeptController
@RestController
public class DeptController {
@Autowired
private DeptService deptService = null;
@RequestMapping(value = "/dept/get/{id}",method = RequestMethod.GET)
//一旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法
@HystrixCommand(fallbackMethod = "processHystrix_Get")
public Dept get(@PathVariable("id") Long id){
Dept dept = this.deptService.get(id);
if(null == dept){
throw new RuntimeException("该ID:" + id + "没有对应的信息");
}
return dept;
}
public Dept processHystrix_Get(@PathVariable("id") Long id){
return new Dept().setDeptno(id).setDname("该ID：" + id + "没有对应的信息，" +
"null--@HystrixCommand").setDb_source("no this database in MySQL");
}
}
*6.修改主启动类 加上
@EnableCircuitBreaker //对hystrix熔断机制的支持
*服务降级：
*整体资源容量不足，忍痛将某些服务先关闭掉，待度过难关，再开启
*服务降级处理是在客户端实现完成的，与服务端没有关系
*不想让HystrixCommand一个方法添加一个，要实现解耦，用Spring的面向切面编程的置入+异常通知，避免代码膨胀、业务逻辑和异常处理分离
*1.新建DeptClientServiceFallbackFactory类 实现FallbackFactory
*为了与主程序Controller解耦，在接口层进行服务的降级处理
*千万不要忘记在类上面新增@Component注解*
*2.编写DeptClientServiceFallbackFactory类
@Component
public class DeptClientServiceFallbackFactory implements FallbackFactory
@Override
public DeptClientService create(Throwable throwable) {
return new DeptClientService() {
@Override
public boolean add(Dept dept) {
return false;
}
@Override
public Dept get(Long id) {
return new Dept().setDeptno(id).setDname("该ID：" + id + "没有对应的信息，" +
"Consumer客户端提供的降级信息，此刻服务Provider已经关闭"
).setDb_source("no this database in MySQL");
}
@Override
public List
return null;
}
};
}
}
*3.修改DeptClientService 注解替换为
@FeignClient(value = "MICROSERVICECLOUD-DEPT",fallbackFactory = DeptClientServiceFallbackFactory.class)
*4.clean+install项目api
*5.修改microservicecloud-consumer-dept-feign的yml
feign: #供api中@FeignClient使用
hystrix:
enabled: true
*服务降级熔断总结：
*服务熔断：一般是某个服务故障或者异常引起，类似现实世界中的“保险丝”，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时。
*将分散的fallback方法，集中起来，统一放到一个接口里面
*如遇异常问题，就找负责fallback的类，统一管理
*服务降级：
*所谓降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然服务水平下降，但好歹可用。比直接挂掉要强。
*重要的事情多说几遍：服务降级处理实在客户端实现完成的，与服务端没有关系。
*服务监控hystrixDashboard 豪猪
*除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转换成可视化界面。
所有Provider依赖配置
1.Delay：该参数用来控制服务器上轮询监控信息的延迟时间，默认为2000毫秒，可以通过配置该属性来降低客户端的网络和CPU消耗。
2.Title：该参数对应了头部标题Hystrix Stream之后的内容，默认会使用具体监控实例的URL，可以通过配置该信息来展示合适的标题。
*实心圆：共有两种含义。它通过颜色的变化代表了实例的健康程度，它的健康度从绿色<黄色<橙色<红色递减。该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圆就越大。所以通过该实心圆的展示，就可以在大量的实例中快速的发现故障实例和高压力实例
