目录
分布式系统面临问题
Hystrix概念
Hystrix作用
降级
什么是降级
order服务导入Hystrix依赖（简单判断原则：谁调用远程谁加）
启动类添加注解
业务方法添加注解（冒号里填回调方法名，回调方法返回兜底数据）
添加回调方法（原则：回调方法与原方法的返回值和参数要一致）
示例：（回调方法：fallback）
熔断
什么是熔断
熔断具体执行过程
业务方法添加注解
示例
请求合并
什么是请求合并
使用背景
请求合并的缺点
参数介绍
设置需要被请求合并的方法
batch方法
测试
线程池隔离
什么是线程池隔离
为什么使用线程池隔离
优缺点
优点
缺点
线程池隔离参数
示例
配置线程池隔离
对应线程池隔离的方法添加注解
测试
信号量隔离
什么是信号量隔离
参数介绍
业务方法添加注解
示例
分布式系统面临问题
多个微服务之间调用的时候，假如微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的"扇出"。
如果扇出的链路上某个微服务的调用响应的时间过长或者不可用，对微服A的调用就会占用越来越多的系统资源，进而引起系统崩溃，即"雪崩效应"。
对于高流量的应用来说，单一的后端依赖可能会导致所有的服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。
Hystrix概念
①Hystrix是一个开源库，专用于处理分布式系统中的延迟和容错问题。它提供了一种机制，确保当一个服务出现故障时，不会影响整个系统，从而提高分布式系统的弹性。
②作为“断路器”，Hystrix能够通过监控来检测服务的故障情况。一旦发现故障，它会打开断路器，并返回一个可以处理的响应结果，以避免服务调用线程被长时间占用，防止故障蔓延
Hystrix作用
（1）服务降级
服务出现故障时，给故障服务降级到事先准备好的故障处理结果，将此结果返回给服务消费者（2）服务熔断
熔断机制是应对服务雪崩的一种链路保护机制，当服务出现故障时，服务会进行降级，熔断该服务节点，迅速返回错误响应信息。当检测到服务访问正常时，恢复其链路节点。(3) 请求合并
请求合并是一种优化策略，通过将多个相同类型的请求合并为一个批量请求发送给后端服务，以减少网络开销和提高性能。
(4) 线程池隔离
通过线程池隔离，可以为每个服务或模块分配独立的线程池，使它们在各自的线程池中独立运行。这样可以实现资源隔离、错误隔离和阻塞隔离，提高系统的稳定性和性能。
降级
什么是降级
降级是指，当请求超时、资源不足等情况发生时进行服务降级处理,不调用真实服务
逻辑，而是使用快速失败(fallback) 方式直接返回一个兜底数据，保证服务链条的完整,
避免服务雪崩。|
（本文章示例代码继于1.2 eureka注册中心，完成服务注册）
order服务导入Hystrix依赖（简单判断原则：谁调用远程谁加）
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>启动类添加注解
@EnableCircuitBreaker业务方法添加注解（冒号里填回调方法名，回调方法返回兜底数据）
@HystrixCommand(fallbackMethod = "")添加回调方法（原则：回调方法与原方法的返回值和参数要一致）
示例：（回调方法：fallback）
@HystrixCommand(fallbackMethod = "fallback")
正常调用情况下，请求成功，返回正常数据
停止user服务，即让远程调用失败
再次发起请求
此时，远程服务调用失败了，资源不存在，触发降级 ，Hystrix返回兜底数据
熔断
什么是熔断
熔断是当一定时间内，异常请求比例(请求超时、网络故障、服务异常等)达到阀值时,启
动熔断器，熔断器旦启动, 则会停止调用具体服务逻辑，通过fallback快速返回托底数
据，保证服务链的完整。熔断可以看作是特定的降级。熔断有自动恢复机制,如:当熔断器启动后，每隔5秒,尝试将新的远程调用,如果服务可正常执行并返回结果，则关闭熔断器，服务恢复。如果仍旧调用失败，则继续返回托底数据，熔断器持续开启状态。
熔断可以看作是于电路的跳闸功能
熔断具体执行过程
（开启与关闭是指熔断的状态）
业务方法添加注解
@HystrixCommand(fallbackMethod = ""， commandProperties = {})熔断的注解是在降级的注解上增加，commandProperties = {} 里填熔断条件，如下示例图，具体熔断条件可点击HystrixPropertiesManager类查看
示例
以下熔断条件： 20秒内出现3个请求,失败率为30%,就会触发熔断,30秒内不再发送调用
@HystrixCommand(fallbackMethod = "fallback",commandProperties = {
//20秒内出现3个请求,失败率为30%,就会触发熔断,30秒内不再发送调用
// 条件一: 请求数量达到3个
@HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD, value = "3"),
// 条件二: 每20秒一个判断单位
@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_THREAD_INTERRUPT_ON_TIMEOUT,value = "20000"),
// 条件三: 失败率30%
@HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE, value = "30"),
// 结果: 熔断后, 30秒内不再请求远程服务
@HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS, value = "30000")
})
结果：
三次远程调用都失败，返回兜底数据。第四次开始，不再远程调用，直接返回兜底数据，实现熔断
请求合并
什么是请求合并
请求合并是一种将多个独立的请求合并为一个或少数几个请求的机制。它的目的是减少网络延迟和提高系统性能效率。服务接收到请求不会立即执行，而是在一定时间内等待是否还有相同的请求到达。这个等待的时间称为合并窗口。当合并窗口结束时，服务端会执行合并后的请求。
使用背景
在微服务架构中，我们将一个项目拆分成很多 个独立的项目,这些独立的项目通过远程调用来互相配合工作。
但是,在高并发情况下,通信次数的增加会导致总的通信时间增加，同时,线程池的资源也是有限的,高并发环境会导致有大量的线程处于等待状态,进而导致响应延迟，为了解决这些问题，需要使用Hystrix的请求合并。
请求合并的缺点
设置请求合并之后，本来1个请求可能5ms就搞定了，但是现在必须再等10ms。看看还
有没有其他的请求一起的, 这样一个请求的耗时就从 5ms增加到15ms了,不过,如果要发起的命令本身就是一个高延迟的命令,那么这个时候就可以使用请求合并了,因为这个时候时间窗的时间消耗就显得微不足道了，另外高并发也是请求合并的一个非常重要的场景。
参数介绍
| 参数 | 作用 | 默认值 | 备注 |
|---|---|---|---|
| @HystrixCollapser | 被@HystrixCollapser标注的方法。返回类型必须为Future，使用异步方法,否则无法进行请求合井 | ||
| batchMethod | 合并请求的方法 | 方法只能接受 个参数。如果你需要传递多个参数，那么请将它们封装成一一个类参数。 | |
| scope | 请求方式 | REQUEST | 请求方式:分为REQUEST, GLOBA。 REQUEST范围只对一个request请求内的多次服务请求进行合并 GLOBAL是多单个应用中的所有线程的请求中的多次服务请求进行合并 |
| timerDelayInMilliseconds | 请求时间间隔在10ms之内的请求会被合并为一个请求 | 10ms | 建议尽量设置的小一点.如果并发量不大的话.其实也没有必要使HystrixCollapser来处理 |
| maxRequestsinBatch | 设置触发批处理执行之前，在批处理中允许的最大请求数量 | Integer.MAX. _VALUE |
设置需要被请求合并的方法
方法上添加注解
@HystrixCollapser(batchMethod = "batch",
scope = com.netflix.hystrix.HystrixCollapser.Scope.GLOBAL,
collapserProperties = {})
- batchMethod内添加请求合并后的执行方法
- scope一般都是使用GLOBAL方式
- collapserProperties内配置请求合并的参数，具体如下
- 这个方法的作用就是将请求参数合并，方法体不会执行，真正执行的方法是：batch
- 合并方法的返回值必须是Future类型
batch方法
batch方法上添加注解
@HystrixCommandbatch方法的的参数和返回值要和合并方法相同 ，batch方法是真正执行多个请求的方法，对应的参数需要改成例如参数，例如List
被调用的服务方法也要做出修改，将参数修改为List参数
测试
在请求接口中模拟并发操作，同时发出多次请求 ，打印返回值
在batch方法中打印合并后的参数
发送请求
查看控制台，打印出了合并后的请求，以及返回值
线程池隔离
什么是线程池隔离
为每个模块或组件分配独立的线程池，使它们在各自的线程池中独立运行
为什么使用线程池隔离
没有线程池隔离的时候可能因为某个接口的高并发导致其他接口也出现问题，当使用线程池隔离。不同接口有着自己独立的线程池
优缺点
优点
- 任何一个服务都会被隔离在自己的线程池内，即使自己的线程池资源填满也不会影响其他服务。
- 当依赖的服务重新恢复时，可通过清理线程池，瞬间恢复服务的调用。但是如
- 果是tomcat线程池被填满，再恢复就会很麻烦。
- 每个都是独立线程池。一定程度上解决了高并发问题。
- 由于线程池中线程个数是有限制，所以也解决了限流问题。
缺点
- 增加了CPU开销。因为不仅仅有Tomcat的线程池，还需要有Hystrix,线程池。
- 每个操作都是独立的线程，就有排队、调度和上下文切换等问题。
线程池隔离参数
| 参数 | 作用 | 默认值 | 备注 |
|---|---|---|---|
| groupKey | 服务名（相同服务用一个名称，如商品用户等等） | getClass0.getSimpleName0: | 在consumer里画为与个provider轻务，设置group标 读，一个oroup使用一个线程池 |
| commandKey | 接口（服务下面的接口，如购 买商品) | 当前执行方法名 | consumer的接口名称 |
| threadPoolKey | 线程池的名称﹔配置全局港一 标识线释池的名称，相同线翔 池名称的线程油是同一个。 | 新认是分组名groupKey. | 配孟全局唯一标识线程池的名称,相同线程池名称的 线程池是间一个. |
| coreSize | 线程池大小:这是最大的并发执行数量。 | 10 | 设置标准: requests per second at peak whenhealthy x 99th percentiie latency. in seconds +some breathing room 每秒锻大支撑的请求数(99%平均迪应时间＋一个缓冲值 |
| maxQueueSize | 最大队列长度﹔设置 BtockingQueue的染大长度 | -1 | 默认值:-1如果使用正数，队列将从同步队列 (SynchronousQueue】改为阻塞队列 ( LinkedBlockingQueue ) |
| queueSizeRejectionThreshold | 拒绝请求:设置拒绝请求的临界值 | 5 | 此属性不适用于maxQueuesize =-1时 没置设个值的索因是maxQueoeSze值运行时不能改 变，我们可以通过修改这个变量动态惨改允许排队的长度 |
| keepAliveTimeMinutes | 线程存活时间:设量存活时间，单位分钟. | 1分钟 | 控制一个线程从实用完成到被释放的时间 |
示例
常规
添加两个service方法，分别打印当前线程
添加接口一次性调用这两个方法
发送请求，可以看到，两个请求走的同一个线程
配置线程池隔离
对应线程池隔离的方法添加注解
@HystrixCommand(groupKey = "t1" , commandKey = "thread1", threadPoolKey = "t1", threadPoolProperties= {
// 最大的并发执行数量
@HystrixProperty( name="coreSize",value="8"),
// 最大队列长度
@HystrixProperty(name="maxQueueSize" ,value="5"),
// 拒绝请求的临界值
@HystrixProperty( name= "keepAliveTimeMinutes", value="2"),
// 线程存活时间
@HystrixProperty(name="queueSizeRejectionThreshold" , value="5")
})commandKey一般为当前方法名，groupKey和threadPoolKey 一般使用相同名称
测试
重启服务，发送请求，可以看到两个请求处于不同线程，代表线程池隔离正确实施
信号量隔离
什么是信号量隔离
信号量用来控制可同时并发的线程数。通过构造方法指定内部虚拟许可的数量。
如果采用信号量隔离技术，每接收一个请求，都是服务自身线程去直接调用依赖服务，信号量就相当于一道关卡，每个线程通过关卡后，信号量数量减1，当为0时不再允许线程通过，而是直接执行fallback逻辑并返回，说白了仅仅做了一个限流。
信号量可以理解为一个计数器，计数器统计当前正在处理的请求数量，当计数器的值达到设定值，则不接受后续请求（或降级），需要等待，直到计数器值小于设定值，后续请求才能进入处理。
信号量隔离与线程池隔离实际上属于同一种技术
参数介绍
| 参数 | 作用 | 默认值 | 备注 |
|---|---|---|---|
| execution.isolation.strategy | 隔高策略配置项 | THREAD | 只有2种THREAD和OSEMAPHORE |
| execution.isolation.thread.timeoutinMilliseconds | 超时时间 | 1000ms | 1.在THREAD模式下，达到超时时间，自动中断 2.在SEMAPHORE模式下，会等待执 行完成后，再去判断是否超时 |
| execution.isolation.thread.interruptOnTimeout | 是否打开超时线程中断 | TRUE | THREAD模式有效 |
| execution.isolation.semaphore.maxConcurrentRequests | 信号量最大并发度 | 10 | SEMAPHORE模式有效 |
| fallback.isolation.semaphore.maxConcurrentRequests | fallback最大并发度1o | 10 | SEMAPHORE模式有效 |
业务方法添加注解
@HystrixCommand(commandProperties = {
// 设置信号量隔离模式(默认为线程池隔离)
@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_STRATEGY, value = "SEMAPHORE"),
// 信号量最大并发度
@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_SEMAPHORE_MAX_CONCURRENT_REQUESTS, value = "10")
}, fallbackMethod = "fallback")设置信号量隔离模式(默认为线程池隔离)：value = SEMAPHORE
设置最大并发度： 10
设置回调降级方法：fallback
示例
因为信号量隔离等待超时时间默认1000ms，所以每个请求睡眠900ms，模拟让前10个请求占据所有信号量，后续请求等待降级。
方法内部打印：执行了信号量隔离。代表执行了请求
回调函数打印：执行降级。代表只写了回调函数
通过控制台来查看打印的数据，即可展示出信号量隔离的作用
发送请求，查看控制台，效果如预期，信号量隔离正确实施
本文章在持续更新中
参考文章文章来源：https://www.toymoban.com/news/detail-635756.html
SpringCloud——Hystrix详解_springcloud hystrix_swttws.的博客-CSDN博客文章来源地址https://www.toymoban.com/news/detail-635756.html
到了这里，关于【2.2】Java微服务：Hystrix的详解与使用的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
