Soul网关Hystrix插件相关知识点扫盲

线程隔离和信号量隔离

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