使用hystrix来保证服务的高可用性

先介绍一下什么时候不可用，可以画图来介绍，比如服务之间的依赖，下面的服务卡住了，不能导致上面的服务也卡住，然后一直连环的导致很多地方卡住，然后系统直接不可用。
然后就用资源隔离来做到服务之间的高可用性。
介绍一下线程池隔离和信号量隔离，他们的区别，使用场景
然后还有timeout啥的，错误快速返回的机制等

最近在看hystrix相关的一些机制，因为网上示例代码都比较多，就不去做那些代码的记录了，我在这里就谈一下自己对hystrix的理解

• 一般来说，一个项目，当它的并发量慢慢变大，数据量变大的时候，原来的小的springboot项目就可能需要做一个分布式的或者微服务的这样一个项目，将整个项目拆分为多个服务模块，然后增加服务器，将其部署在多个服务器上，以此来应对单台服务器到性能瓶颈的压力。
• 并且这样做的拆分的好处，不仅是将单台服务器的压力分担到多台服务器这么简单，主要的是可以去通过它来实现服务的高可用性，而不是单点故障了就直接不可用了。
• 同一个服务，可以去部署多个实例来保证即使有一个服务挂了也有其他的服务可以去对外提供访问。而有时候如果这个服务出现故障了或者真的直接挂掉了，我们也不能去影响整个系统的运行，那么，这里就会用到hystrix来进行服务治理。
• 首先我们需要知道的一点就是，一个服务器，它所能创建的线程数是有限的，并且也不是越多越好，因为创建一个线程是需要一定的开销的，它主要体现在两个方面：

1. 每创建一个线程大概需要1M的内存空间，那么如果说线程数过多的话，就会占用大量的内存资源
2. 可以看看CPU的调度机制，所有的线程都是在CPU的各个核心上运行的，他有各种各样的机制，如果说你的线程数越多，那么你每个线程排队的时间就会越长，它的响应时间就越长，然后还有一个重要的一点，CPU在进行线程切换的时候，是需要保存和切换每一个线程的当前上下文的，这样才能够保证线程在切换回来执行的时候依然能够恢复切换出来时候的状态，所以CPU频繁的进行上下文的切换，它会花费大量的时间在这个上面，而不是真正的任务的处理。

• 就依据这两点，我们需要控制一台服务器的合理的线程数，所以可以看到，springboot中可以指定tomcat的最大并发数。

• 而在一个分布式系统中，每个服务都可能会调用很多其他服务，被调用的那些服务就是依赖服务，有的时候某些依赖服务出现故障也是很正常的。这个时候有意思的现象就出现了，由于每个服务的最大并发数都是有限制的，如果说一个下游的服务挂掉了，或者说访问的时间太长了，那么调用用它的上游服务就会一直被阻塞在这里，如果说这个接口的并发量还比较高的话，它就可能直接把tomcat的线程资源给耗尽了，不仅这个接口不能得到访问，还会使得到这个服务的所有请求都得不到线程资源，整个服务相当于挂掉了，然后再影响上层服务，直到整个系统挂掉。

• 为了应对这样的情况，首先我们需要做的就是对线程资源的隔离

资源隔离

那么使用hystrix来进行资源隔离有两种方式，一种是线程池隔离技术，一种是信号量隔离技术

1. 线程池隔离技术
   一般用于对外部服务的访问，因为访问外部服务一般不稳定性因素比较高，很容易发生超时的情况，那么使用线程池隔离技术的话，因为线程池隔离技术支持超时机制，它内部会自己创建一个线程池来执行这个任务，所以调用线程和真正执行任务的不是一个线程，我们可以给这个线程池设定最大并发数量和队列大小，如果队列也满了，就会执行拒绝策略，调用fallback降级机制，所以大多数情况下，我们使用的都是线程池隔离
2. 信号量隔离技术
   信号量隔离一般用于对内部一些比较耗时的算法等的访问，它不支持超时机制，由于其使用的是信号量，支持指定数量的线程同时执行这段代码，所以相对于使用线程池来说，它的效率会更高一点，但是很少会用到这种隔离方法。

限流

其实使用资源隔离就是已经达到了限流的目的了，比如说使用线程池隔离技术去访问某一个外部服务，调用这个服务需要50ms的时间，然后设置的线程池的最大并发量是10，那么它每秒能够处理的请求数量就是200个，这就相当于对其进行了限流了。

短路器

配置短路器可以使得如果在这个调用服务在一定时间内出现一定的故障数或者故障率的时候就直接短路，认为这个服务已经故障了，触发降级机制，后面的请求过来的时候也直接短路，然后在指定时间后进行重试，这样的话能够更大的降低依赖服务故障导致上游服务故障的情况。

• 计划任务
  还没写完，先差不多写个思路，写完之后，再多花个几天，整理一下，排个版，或者想到什么新的内容再改一改