Article Directory
1. Two ways to use Hystrix
1. Use with restTemplate
1. Introduce hystrix dependency in the caller's project
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
2. Add annotations to the startup class
@EnableCircuitBreaker
Note: It is possible to use @EnableHystrix and @EnableCircuitBreaker here, and click @EnableHystrix to include @EnableCircuitBreaker.
3. Add @HystrixCommand to the called method, and the annotation will put the method in hystrix monitoring
@HystrixCommand(fallbackMethod = "selectUserInfoFallBack")
public ResponseDto selectUserInfo(RequestDto requestDto){
//正常的代码逻辑
}
4. Write the downgrade method corresponding to the called service, the input and output parameters of the method need to be consistent with the input and output parameters of the called service
public ResponseDto selectUserInfoFallBack(RequestDto requestDto){
//熔断降级后的代码逻辑
}
2. Use with feign
1. Like the first step above, add hystrix dependency first, open Hystrix in the configuration file, and it is closed by default.
feign:
hystrix:
enabled: true
2. Add @FeignClient annotation on the interface that calls the remote service
@FeignClient(name = "user",fallback = FindUserInfoFallback.class)
public interface FindUserInfo{
@RequestMapping(value="/user/selectUserInfo", method = RequestMethod.POST)
public ResponseDto selectUserInfo(RequestDto requestDto);
}
@Component
public class FindUserInfoFallback implements FindUserInfo {
@Override
public ResponseDto selectUserInfo(RequestDto requestDto){
//熔断降级后的代码逻辑
}
}
3. Add annotations to the startup class
@EnableFeignClients //开启Feign
@EnableCircuitBreaker //开启Hystrix
Attachment: Commonly used configuration data
HystrixCommandProperties related to Hystrix
/* --------------统计相关------------------*/
// 统计滚动的时间窗口,默认:5000毫秒（取自circuitBreakerSleepWindowInMilliseconds）
private final HystrixProperty metricsRollingStatisticalWindowInMilliseconds;
// 统计窗口的Buckets的数量,默认:10个,每秒一个Buckets统计
private final HystrixProperty metricsRollingStatisticalWindowBuckets; // number of buckets in the statisticalWindow
// 是否开启监控统计功能,默认:true
private final HystrixProperty metricsRollingPercentileEnabled;
/* --------------熔断器相关------------------*/
// 熔断器在整个统计时间内是否开启的阀值，默认20。也就是在metricsRollingStatisticalWindowInMilliseconds（默认10s）内至少请求20次，熔断器才发挥起作用
private final HystrixProperty circuitBreakerRequestVolumeThreshold;
// 熔断时间窗口，默认:5秒.熔断器中断请求5秒后会进入半打开状态,放下一个请求进来重试，如果该请求成功就关闭熔断器，否则继续等待一个熔断时间窗口
private final HystrixProperty circuitBreakerSleepWindowInMilliseconds;
//是否启用熔断器,默认true. 启动
private final HystrixProperty circuitBreakerEnabled;
//默认:50%。当出错率超过50%后熔断器启动
private final HystrixProperty circuitBreakerErrorThresholdPercentage;
//是否强制开启熔断器阻断所有请求,默认:false,不开启。置为true时，所有请求都将被拒绝，直接到fallback
private final HystrixProperty circuitBreakerForceOpen;
//是否允许熔断器忽略错误,默认false, 不开启
private final HystrixProperty circuitBreakerForceClosed;
/* --------------信号量相关------------------*/
//使用信号量隔离时，命令调用最大的并发数,默认:10
private final HystrixProperty executionIsolationSemaphoreMaxConcurrentRequests;
//使用信号量隔离时，命令fallback(降级)调用最大的并发数,默认:10
private final HystrixProperty fallbackIsolationSemaphoreMaxConcurrentRequests;
/* --------------其他------------------*/
//使用命令调用隔离方式,默认:采用线程隔离,ExecutionIsolationStrategy.THREAD
private final HystrixProperty executionIsolationStrategy;
//使用线程隔离时，调用超时时间，默认:1秒
private final HystrixProperty executionIsolationThreadTimeoutInMilliseconds;
//线程池的key,用于决定命令在哪个线程池执行
private final HystrixProperty executionIsolationThreadPoolKeyOverride;
//是否开启fallback降级策略 默认:true
private final HystrixProperty fallbackEnabled;
// 使用线程隔离时，是否对命令执行超时的线程调用中断（Thread.interrupt()）操作.默认:true
private final HystrixProperty executionIsolationThreadInterruptOnTimeout;
// 是否开启请求日志,默认:true
private final HystrixProperty requestLogEnabled;
//是否开启请求缓存,默认:true
private final HystrixProperty requestCacheEnabled;
HystrixThreadPoolProperties
/* 配置线程池大小,默认值10个 */
private final HystrixProperty corePoolSize;
/* 配置线程值等待队列长度,默认值:-1 建议值:-1表示不等待直接拒绝,测试表明线程池使用直接决绝策略+ 合适大小的非回缩线程池效率最高.所以不建议修改此值。 当使用非回缩线程池时，queueSizeRejectionThreshold,keepAliveTimeMinutes 参数无效 */
private final HystrixProperty maxQueueSize;
Two, two kinds of capture fuse exception information
1. When combined with restTemplate
Modify the method of fuse downgrade and add Throwable
public ResponseDto selectUserInfoFallBack(RequestDto requestDto,Throwable throwable){
log.info("异常信息："+throwable);
//熔断降级后的代码逻辑
}
2. When using the set feign
1. Modify the @FeignClient annotation on the calling remote service interface
@FeignClient(name = "user",fallback = FindUserInfoFallbackFactory.class)
2. Create a new corresponding Factory class (anonymous inner class, input and output parameters need to be consistent)
@Component
public class FindUserInfoFallbackFactory implements FallbackFactory<FindUserInfo> {
@Override
public FindUserInfo create(Throwable cause) {
return new FindUserInfo() {
@Override
public ResponseDto selectUserInfo(RequestDto requestDto){
log.info("feign异常信息："+cause);
//熔断降级后的代码逻辑
}
};
}
}
Three, circuit breaker switch
Introduce dependencies
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
You can visit http://ip:port/actuator/health. The
default circuit breaker opening condition is more than 20 requests within 10 seconds and the failure rate is more than 50%.
Attachment: Related attribute configuration
Execution相关的属性的配置：
hystrix.command.default.execution.isolation.strategy 隔离策略，默认是Thread, 可选Thread｜Semaphore
thread 通过线程数量来限制并发请求数，可以提供额外的保护，但有一定的延迟。一般用于网络调用
semaphore 通过semaphore count来限制并发请求数，适用于无网络的高并发请求
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 命令执行超时时间，默认1000ms
hystrix.command.default.execution.timeout.enabled 执行是否启用超时，默认启用true
hystrix.command.default.execution.isolation.thread.interruptOnTimeout 发生超时是是否中断，默认true
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests 最大并发请求数，默认10，该参数当使用ExecutionIsolationStrategy.SEMAPHORE策略时才有效。如果达到最大并发请求数，请求会被拒绝。理论上选择semaphore size的原则和选择thread size一致，但选用semaphore时每次执行的单元要比较小且执行速度快（ms级别），否则的话应该用thread。
semaphore应该占整个容器（tomcat）的线程池的一小部分。
Fallback相关的属性
这些参数可以应用于Hystrix的THREAD和SEMAPHORE策略
hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests 如果并发数达到该设置值，请求会被拒绝和抛出异常并且fallback不会被调用。默认10
hystrix.command.default.fallback.enabled 当执行失败或者请求被拒绝，是否会尝试调用hystrixCommand.getFallback() 。默认true
Circuit Breaker相关的属性
hystrix.command.default.circuitBreaker.enabled 用来跟踪circuit的健康性，如果未达标则让request短路。默认true
hystrix.command.default.circuitBreaker.requestVolumeThreshold 一个rolling window内最小的请求数。如果设为20，那么当一个rolling window的时间内（比如说1个rolling window是10秒）收到19个请求，即使19个请求都失败，也不会触发circuit break。默认20
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds 触发短路的时间值，当该值设为5000时，则当触发circuit break后的5000毫秒内都会拒绝request，也就是5000毫秒后才会关闭circuit。默认5000
hystrix.command.default.circuitBreaker.errorThresholdPercentage错误比率阀值，如果错误率>=该值，circuit会被打开，并短路所有请求触发fallback。默认50，即为50%。
hystrix.command.default.circuitBreaker.forceOpen 强制打开熔断器，如果打开这个开关，那么拒绝所有request，默认false
hystrix.command.default.circuitBreaker.forceClosed 强制关闭熔断器 如果这个开关打开，circuit将一直关闭且忽略circuitBreaker.errorThresholdPercentage
Metrics相关参数
hystrix.command.default.metrics.rollingStats.timeInMilliseconds 设置统计的时间窗口值的，毫秒值，circuit break 的打开会根据1个rolling window的统计来计算。若rolling window被设为10000毫秒，则rolling window会被分成n个buckets，每个bucket包含success，failure，timeout，rejection的次数的统计信息。默认10000
hystrix.command.default.metrics.rollingStats.numBuckets 设置一个rolling window被划分的数量，若numBuckets＝10，rolling window＝10000，那么一个bucket的时间即1秒。必须符合rolling window % numberBuckets == 0。默认10
hystrix.command.default.metrics.rollingPercentile.enabled 执行时是否enable指标的计算和跟踪，默认true
hystrix.command.default.metrics.rollingPercentile.timeInMilliseconds 设置rolling percentile window的时间，默认60000
hystrix.command.default.metrics.rollingPercentile.numBuckets 设置rolling percentile window的numberBuckets。逻辑同上。默认6
hystrix.command.default.metrics.rollingPercentile.bucketSize 如果bucket size＝100，window＝10s，若这10s里有500次执行，只有最后100次执行会被统计到bucket里去。增加该值会增加内存开销以及排序的开销。默认100
hystrix.command.default.metrics.healthSnapshot.intervalInMilliseconds 记录health 快照（用来统计成功和错误绿）的间隔，默认500ms
data = pd.read_csv(
'https://labfile.oss.aliyuncs.com/courses/1283/adult.data.csv')
print(data.head())
Four, monitoring
Monitoring the
caller introduces dependencies
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Visiting the page http://ip:port/actuator/hystrix.stream found that it has been monitoring through ping
Five, principle
1. Isolation strategy
The advantages of using the bulkhead mode: 1. The abnormality of the service provider will not affect the paralysis of the entire system. 2. Use an independent thread pool to control the concurrency of each caller Two isolation strategies: THREAD (thread isolation): Using this method, HystrixCommand will be executed on a separate thread, and concurrent requests are subject to the number of threads in the thread pool limit. By using different thread pools, different services will not be affected by each other, achieving an isolation effect. Hystrix will use an independent thread pool for each service provider to isolate and limit these services. Therefore, the high latency or resource constraints of a service provider will only occur in the thread pool corresponding to the service provider. SEMAPHORE (semaphore isolation): In fact, it is a counter. Using this method, HystrixCommand will be executed on the calling thread, and the concurrency of a single service provider will be limited through the semaphore. The overhead is relatively small (because there are not so many thread pools), Concurrent requests are limited by the number of semaphores. Thread isolation will bring thread overhead. In some scenarios (such as no network request scenarios), the cost of isolation may not be worth the loss. For this reason, Hystrix provides semaphore isolation. When the number of concurrent services is greater than the semaphore threshold, it will enter fallback.
In Hystrix, thread isolation (THREAD) is recommended by default and recommended. Generally speaking, semaphore isolation is required only when the call load is abnormally high (for example, hundreds of calls per second per instance), because the overhead of using THREAD in this scenario Relatively high. Semaphore isolation generally only applies to isolation of non-network calls.
Both thread pool and semaphore support circuit breaking and current limiting. Compared with thread pools, semaphores do not require thread switching, thus avoiding unnecessary overhead. But the semaphore does not support asynchronous, nor does it support timeout, that is, when the requested service is not available, the semaphore will control the request that exceeds the limit to return immediately, but the thread that already holds the semaphore can only wait for the service response or from the timeout Return, that is, a long wait may occur. In the thread pool mode, when the unresponsive service exceeds the specified time, Hystrix will notify the thread to end immediately and return by responding to the interrupt.
2. Hystrix implementation ideas
1. When the request comes, encapsulate the requested remote call logic into the HystrixCommand or HystrixObservableCommand object (and configure the parameters required for the request to be executed in the constructor). These remote calls will be executed in a separate thread. (Resource isolation, command mode).
2. Hystrix adopts an automatic timeout strategy for requests whose access time exceeds the set threshold. This strategy is effective for all commands. (If it is the semaphore isolation method, this feature is invalid), the timeout threshold can be customized through command configuration.
3. Maintain a thread pool (semaphore) for each service provider. When the thread pool (semaphore) is full, the request for the service provider will be directly rejected (fail quickly, roll back) Instead of waiting in line, reduce system waiting resources.
4. According to the request service provider, it is divided into success, failure, timeout, and thread pool being filled.
5. The circuit breaker will manually or automatically cut off the service for a period of time after the number of failures requested by the service provider exceeds a certain threshold.
6. When the requesting service provider has service rejection, timeout and short circuit (multiple service providers request sequentially, the previous service provider request fails, and the subsequent request will no longer be issued), etc., the executor fallback method, the service is degraded .
7. Provide near real-time monitoring and configuration change services.
3.Hystrix implementation process
1. Construct a HystrixCommand or HystrixObservableCommand object to encapsulate the request and configure the parameters required for the request to be executed in the constructor.
2. Execute commands, Hystrix provides 4 ways to execute commands.
3. Check whether there is a cache executed by the same command. If the cache is enabled and the cache is available, directly use the cache to respond to the request. Hystrix supports request caching, but requires user-defined activation.
4. Check whether the circuit breaker is open, if open, go to step 8.
5. Check whether the thread pool or semaphore is exhausted, if it is full, go to step 8.
6. Call the run of HystrixCommand or construct of HystrixObservableCommand to execute the encapsulated call logic. If the execution fails or times out, go to step 8.
7. Calculate the health of the link.
8. Get the fallback logic when the command execution fails.
9. Return the response.