线程隔离和信号量隔离
Hystrix 里面核心的一项功能，其实就是所谓的资源隔离，要解决的最最核心的问题，就是将多个依赖服务的调用分别隔离到各自的资源池内。避免说对某一个依赖服务的调用，因为依赖服务的接口调用的延迟或者失败，导致服务所有的线程资源全部耗费在这个服务的接口调用上。一旦说某个服务的线程资源全部耗尽的话，就可能导致服务崩溃，甚至说这种故障会不断蔓延。
资源隔离主要分为如下两种方式
- 线程池
- 信号量
信号量机制
信号量的资源隔离只是起到一个开关的作用，比如，服务 A 的信号量大小为 10，那么就是说它同时只允许有 10 个 tomcat线程来访问服务 A，其它的请求都会被拒绝，从而达到资源隔离和限流保护的作用。
线程池机制
线程池隔离技术，并不是说去控制类似 tomcat 这种 web 容器的线程。更加严格的意义上来说，Hystrix 的线程池隔离技术，控制的是 tomcat 线程的执行。Hystrix 线程池满后，会确保说，tomcat 的线程不会因为依赖服务的接口调用延迟或故障而被 hang 住，tomcat 其它的线程不会卡死，可以快速返回，然后支撑其它的事情。
信号量机制与线程池机制的区别
线程池隔离技术，是用 Hystrix 自己的线程去执行调用；而信号量隔离技术，是直接让 tomcat 线程去调用依赖服务。信号量隔离，只是一道关卡，信号量有多少，就允许多少个 tomcat 线程通过它，然后去执行。
适用场景
- 线程池技术，适合绝大多数场景，比如说我们对依赖服务的网络请求的调用和访问、需要对调用的 timeout 进行控制（捕捉 timeout 超时异常）。
适用于请求并发量大，并且耗时长（一般是计算量大或者读数据库）：采用线程池隔离，这样的话，可以保证大量的容器线程可用，不会由于服务原因，一直处于阻塞或者等待状态，快速失败返回。 - 信号量技术，适合说你的访问不是对外部依赖的访问，而是对内部的一些比较复杂的业务逻辑的访问，并且系统内部的代码，其实不涉及任何的网络请求，那么只要做信号量的普通限流就可以了，因为不需要去捕获 timeout 类似的问题。适用于请求并发量大，并且耗时短（一般是计算量小，或读缓存）：采用信号量隔离：因为这类服务的返回往往非常快，不会占用容器线程太长时间，并且减少了线程切换的一些开销，提高了缓存服务的效率。
Hystrix请求命令 HystrixCommand、HystrixObservableCommand
- HystrixCommand用在依赖服务返回单个操作结果的时候。又两种执行方式
-execute():同步执行。从依赖的服务返回一个单一的结果对象，或是在发生错误的时候抛出异常。
-queue();异步执行。直接返回一个Future对象，其中包含了服务执行结束时要返回的单一结果对象。
- HystrixObservableCommand 用在依赖服务返回多个操作结果的时候。它也实现了两种执行方式
-observe():返回Obervable对象，他代表了操作的多个结果，他是一个HotObservable
-toObservable():同样返回Observable对象，也代表了操作多个结果，但它返回的是一个Cold Observable。
Soul中配置失败降级URL
soul中Hystrix的CallBackUri()需要写在soul-boostrap项目中，因为集成网关之后，http请求的本体项目是没有集成Hystrix的，所以网关只能进入自己的uri中，当然我们如果需要获取本体项目的一些信息或者数据，那么我们可以在boostrap中通过某种方式向本体服务拿到数据或请求再返回。
可以类比的是，其他的限流插件可能CallBackUri()都必须写在soul-boostrap中了
疑问
HystrixObservableCommand,HystrixCommand与隔离机制之间的对应关系的具体原因？
参考博客https://www.imooc.com/article/296565 , https://www.cnblogs.com/pretttyboy/p/13519823.html ,https://cloud.tencent.com/developer/article/1600695 ,https://www.cnblogs.com/happyflyingpig/p/8079308.html
欢迎搜索关注本人与朋友共同开发的微信面经小程序【大厂面试助手】和公众号【微瞰技术】，以及总结的分类面试题https://github.com/zhendiao/JavaInterview
