SpringCloud之Hystrix自我理解

服务雪崩
多个服务相互调用时，例如A服务调用B服务，B服务调用C服务，C服务又调用其他服务，由此服务而扇出，如果B服务调用C服务时，出现异常或者请求时间超长，甚至直接不可用，那么客户端其他线程调用A服务就会占用越来越多的系统资源（线程堆积，内存占用。。。），进而引起的服务崩溃。这种现象称之为服务雪崩。
Hystrix
处理分布式服务系统的延迟，容错的开源库。保证了在服务出现异常的情况，不会出现服务整体故障，避免级联错误产生，提高了分布式系统的稳定性。
1.服务熔断
为了应对服务雪崩的一种微服务链路保护机制。注解**@HystrixCommand**。当服务扇出的链路上出现了不可用，或者响应时间过长，失败的响应达到了默认阈值，缺省5秒内20次响应失败就会启动熔断机制。
2.服务降级
当分布式服务系统的整体资源不足，或者不够用时，忍痛暂时停掉某些服务，从而提高主要服务的性能，带用户高峰使用期度过，再开启那些停止的服务。（例如：分布式系统A/BC三个服务，每天凌晨12点到13点A服务的负载量特别大，BC服务请求的量很小，这个时候就可以先暂停BC服务，从而减少对系统资源的使用，提高A服务的响应能力，等到A服务高峰期过去，再重启BC服务）
3.资源隔离
线程池隔离：每个服务使用单独的线程池，互不影响，Hystrix单独设置线程响应时间，获取到线程的服务再去调用目标接口，调用超时Hystrix直接fallback返回。
信号量隔离：每次线程调用，线程只有获取到一个信号量时才能继续访问，访问完成后归还信号量。当前请求通过计数信号量进行限流，当信号量打到最大值（maxConcurrentRequests）时，调用fallback方法进行快速返回。
注意：信号获取是同步调用，也就是说每次都会阻碍调用信号的线程，知道信号量返回。所以信号量限流更加适用于基于内存操作的，需要快速返回的服务请求。
官方建议：通常只有在调用量非常大(每个实例每秒数百个)以致于单独线程的开销太高时，才应该对HystrixCommands使用信号量隔离;这通常只适用于非网络调用。