1.0 Hystrix前言：
在大中型分布式系统中，通常系统很多依赖(HTTP,hession,Netty,Dubbo等)，在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等。
当依赖阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性，在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。
1.1 下面这个例子很好的解释
=================================================================================
2.0 Hystrix原理
2.1 Hystrix能做什么
通过Hystrix可以解决雪崩效应问题，它提供了资源隔离、降级机制、融断、缓存等功能。
2.2 雪崩效应常见场景
· 硬件故障：如服务器宕机，机房断电，光纤被挖断等。
· 流量激增：如异常流量，重试加大流量等。
· 缓存穿透：一般发生在应用重启，所有缓存失效时，以及短时间内大量缓存失效时。大量的缓存不命中，使请求直击后端服务，造成服务提供者超负荷运行，引起服务不可用。
· 程序BUG：如程序逻辑导致内存泄漏，JVM长时间FullGC等。
· 同步等待：服务间采用同步调用模式，同步等待造成的资源耗尽。
2.3 Hystrix遵循的设计原则：
· 防止任何单独的依赖耗尽资源(线程)
· 过载立即切断并快速失败，防止排队
· 尽可能提供回退以保护用户免受故障
· 使用隔离技术(例如隔板，泳道和断路器模式)来限制任何一个依赖的影响
· 通过近实时的指标，监控和告警，确保故障被及时发现
· 通过动态修改配置属性，确保故障及时恢复
· 防止整个依赖客户端执行失败，而不仅仅是网络通信
2.4 Hystrix执行流程
简单的流程：
1，每次调用创建一个新的HystrixCommand，把依赖调用封装在run()方法中；
2，执行execute()/queue做同步或异步调用；
3，判断熔断器(circuit-breaker)是否打开，如果打开跳到步骤8，进行降级策略，否则继续后续步骤；
4，判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤8，否则继续后续步骤；
5，调用HystrixCommand的run方法，运行依赖逻辑；依赖逻辑调用超时，进入步骤8
6，判断逻辑是否调用成功；a 返回成功调用结果，b 调用出错，进入步骤8
7，计算熔断器状态，所有的运行状态上报给熔断器，用于统计从而判断熔断器状态；
8，getFallback()降级逻辑；
以下四种情况将触发getFallback调用：
1. run()方法抛出非HystrixBadRequestException异常，
2.run()方法调用超时
3. 熔断器开启拦截调用
4. 线程池/队列/信号量是否跑满，没有实现getFallback的Command将直接抛出异常，fallback降级逻辑调用成功直接返回，降级逻辑调用失败抛出异常
9，返回执行成功结果；
==============================================================================
3.0 Hystrix的功能
3.1 资源隔离：包括线程池隔离和信号量隔离，限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。Hystrix提供了两种隔离模式：线程池隔离模式、信号量隔离模式。
3.1.1 线程池隔离模式：使用一个线程池来存储当前请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求先入线程池队列。这种方式要为每个依赖服务申请线程池，有一定的资源消耗，好处是可以应对突发流量(流量洪峰来临时，处理不完可将数据存储到线程池队里慢慢处理)。
(线程池模式可以支持异步调用，支持超时调用，支持直接熔断，存在线程切换，开销大。)
3.1.2 信号量隔离模式：使用一个原子计数器(或信号量)记录当前有多少个线程在运行，请求来先判断计数器的数值，若超过设置的最大线程个数则丢弃该类型的新请求，若不超过则执行计数操作请求来计数器+1，请求返回计数器-1。这种方式是严格的控制线程且立即返回模式，无法应对突发流量(流量洪峰来临时，处理的线程超过数量，其他的请求会直接返回，不继续去请求依赖的服务)
(信号量模式从始至终都只有请求线程自身，是同步调用模式，不支持超时调用，不支持直接熔断，由于没有线程
3.2 服务熔断：服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。
问题产生 雪崩效应：是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程，某一服务出现异常，拖垮整个服务链路，消耗整个线程队列，造成服务不可用，资源耗尽。
融断：当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复。
Closed：关闭状态(断路器关闭)，所有请求都正常访问。
Open：打开状态(断路器打开)，所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全关闭。默认失败比例的阈值是50%，请求次数最少不低于20次。
Half Open：半开状态，Closed状态不是永久的，关闭后会进入休眠时间(默认是5S)。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全打开断路器，否则继续保持关闭，再次进行休眠计时
缓存：返回结果缓存，后续请求可以直接走缓存。
请求合并：可以实现将一段时间内的请求(一般是对同一个接口的请求)合并，然后只对服务提供者发送一次请求。
降级机制：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。
这里的降级具体来说就是服务质量的降级，需要注意的是，只有方法所属的业务场景适合降级时才采用，一般为查询场景。Hystrix通过配置fallbackMethod指定降级时的处理方法，触发降级
3.2.1 如果调用服务失败了，那么立即失败并返回。
3.2.2 如果调用服务失败了，那么调用备用服务，因为备用服务也可能失败，所以也可能有再下一级的备用服务，如此形成一个级联。例如：如果服务提供者不响应，则从缓存中取默认数据。
3.3 限流:比如我们的web系统所能承受的最大并发是500,但是在搞活动时人流量相当大，并发就可能超过我们系统的承受量,从而把系统搞崩。此时可以设置流量达到450时拒绝服务，保护系统。但是这并不友好。
================================================================================
4.0 术语介绍
==================================================================================
5.0 总结：
当服务调用者使用同步调用的时候，会产生大量的等待线程占用系统资源，一旦线程资源被耗尽，
服务调用者提供的服务也将处于不可用状态，于是服务雪崩效应产生了！怎么解决？
超时机制
如果我们加入超时机制，例如2s，那么超过2s就会直接返回了，那么这样就在一定程度上可以抑制消费者资源耗尽的问题
服务限流
通过线程池+队列的方式，通过信号量的方式。比如商品评论比较慢，最大能同时处理10个线程，队列待处理5个，那么如果同时20个线程到达的话，其中就有5个线程被限流了，其中10个先被执行，另外5个在队列中
服务熔断
这个熔断可以理解为我们自己家里的电闸。
当依赖的服务有大量超时时，在让新的请求去访问根本没有意义，只会无畏的消耗现有资源，比如我们设置了超时时间为1s，如果短时间内有大量请求在1s内都得不到响应，就意味着这个服务出现了异常，此时就没有必要再让其他的请求去访问这个服务了，这个时候就应该使用熔断器避免资源浪费
服务降级
有服务熔断，必然要有服务降级。
所谓降级，就是当某个服务熔断之后，服务将不再被调用，此时客户端可以自己准备一个本地的fallback(回退)回调，返回一个缺省值。 例如：(备用接口/缓存/mock数据)，这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景。
===========================================================================
记录学习，每天进步一点点的橘子大王