目录
服务雪崩相关概念简述
服务的雪崩效应
造成服务雪崩的原因
服务雪崩最终的结果
防止服务雪崩的方法
一、服务降级
1、 引入Hystrix服务保护依赖；
2、 基于注解@HystrixCommand使用Hystrix；
2、 1、在需要进行服务保护的方法上添加注解@HystrixCommand，并指定降级方法名称；
2、 2、编写降级方法；
2、 3、通过注解@EnableHystrix开启服务保护机制；
2、 4、重启服务、访问超时接口；
二、服务熔断
1、 关键参数/指标：；
1、 1、统计周期；
1、 2、统计周期内的请求数阈值；
1、 3、统计周期内的错误请求比例阈值；
1、 4、熔断恢复时长；
三、服务隔离
3、 1、线程池隔离；
3、 1.1、groupKey--分组命名；
3、 1.2、commandKey--Hystrix中的命令命名；
3、 1.3、threadPoolKey--线程池命名；
3、 1.4、threadPoolProperties--用于为线程池设置的参数；
3、 1.5、常用的线程池设置参数；
3、 2、信号量隔离；
3、 3、两种隔离方式的优缺点；
3、 3.1、线程池隔离：（实现原理：各个服务独立的线程池）；
3、 3.2、信号量隔离：（实现原理：共用线程池，使用计数器进行限流）；
3、 4、两种隔离方式的使用选择；
3、 4.1、线程池隔离；
3、 4.2、信号量隔离；
服务雪崩相关概念简述
服务的雪崩效应
简单来说就是因为项目中的某一个或多个服务不可用造成整个项目都不可用。
造成服务雪崩的原因
可以简单归纳为以下三种：
1、 服务提供者不可用如：硬件故障、程序BUG、缓存击穿、并发请求量过大等；
2、 重试加大流量如：用户重试、代码重试逻辑等；
3、 服务调用者不可用如：同步请求阻塞造成的资源耗尽等；
服务雪崩最终的结果
服务链条中的某一个服务不可用，导致一系列的服务不可用，最终造成服务逻辑崩溃。
防止服务雪崩的方法
服务降级、服务熔断、服务隔离、限流、请求缓存、请求合并等
一、服务降级
当请求超时、资源不足等情况发生时进行服务降级处理，不调用真实的服务逻辑，而是使用快速失败（fallback）方式直接返回一个兜底数据，快速响应客户端，保证服务链条的完整，避免服务雪崩。
Hystrix的使用
1、引入Hystrix 服务保护依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
2、基于注解@HystrixCommand使用Hystrix
2.1、在需要进行服务保护的方法上添加注解@HystrixCommand，并指定降级方法名称
2.2、编写降级方法
注意目标方法（需要服务保护的方法）与降级方法的参数列表和方法返回值要保持一致
2.3、通过注解@EnableHystrix开启服务保护机制
2.4、重启服务、访问超时接口
由于超时并没有返回success,而是返回了fallback方法的兜底数据
底层实现原理：使用AOP切面代理技术
二、服务熔断
当一定时间内，异常请求比例（请求超时、网络故障、服务异常等）达到阈值时，启动熔断器，熔断器一旦启动，则会停止调用具体的服务逻辑，不调用真是服务逻辑，通过fallback快速返回托底数据，保证服务链的完整。
熔断自动恢复机制，如：当熔断器启动后，每隔5s尝试将新的请求发送给服务提供者，如果服务可正常执行并返回结果，则关闭熔断器，服务恢复，如果仍旧调用失败，则继续返回托底数据，熔断器持续保持开启状态。
1、关键参数/指标：
1.1、统计周期
滑动窗口时长
1.2、统计周期内的请求数阈值
当前请求数达到该阈值，就会开启熔断机制（熔断前提条件）
1.3、统计周期内的错误请求比例阈值
当错误比例达到阈值后将开启熔断（真正开启熔断器）
1.4、熔断恢复时长
当过了恢复时长后，熔断器进入半熔断状态
服务熔断需要配合服务降级，两者配合完成对服务的保护
HystrixPropertiesManager有很多参数配置熔断器的指标
@HystrixCommand(fallbackMethod = "circuitBreakerFallback",commandProperties = {
//统计周期，滑动窗口时长5s,单位ms
@HystrixProperty(name= HystrixPropertiesManager.METRICS_ROLLING_STATS_TIME_IN_MILLISECONDS,
value = "5000"),
//熔断器开启前提条件，当达到这个阈值时，熔断器进入就绪状态
@HystrixProperty(name=HystrixPropertiesManager.CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD,value = "4"),
//统计周期内的错误率，当达到该阈值后，将开启熔断，如5秒内错误请求率达到30%就开启熔断器
@HystrixProperty(name=HystrixPropertiesManager.CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE,value="30"),
//熔断恢复时长设置，10s后进入半熔断状态
@HystrixProperty(name=HystrixPropertiesManager.CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS,value = "10000")
})
@GetMapping("/circuitBreaker")
public String circuitBreaker() throws Exception{
Thread.sleep(10000);
return "success";
}
public String circuitBreakerFallback(){
return "circuitBreaker server ";
}
三、服务隔离
当服务发生问题时，使用技术手段隔离请求，保证服务调用链的完整，隔离分为线程池隔离和信号量隔离两种实现方式。
3.1、线程池隔离
它的目的是为每个微服务设置各自的线程池，互不影响，这样，如果某个微服务的线程池满了，不会影响其他微服务的线程池，而是调用fallback方法返回。引入线程池势必会造成一定的系统压力，因为线程池的上下文切换，调度，排队等会增加系统开销，但是hystrix在设计之初，认为它提供的好处远远可以忽略这些开销。
@HystrixCommand配置服务隔离参数
3.1.1、groupKey--分组命名
在application client 中会为每个application service服务设置一个分组，同一个分组下的服务调用同一个线程池。默认值为this.getClass().getSimpleName();
3.1.2、commandKey--Hystrix中的命令命名
默认为当前方法的方法名，可省略。用于标记当前要触发的远程服务是什么。
3.1.3、threadPoolKey--线程池命名
要求一个应用中全局唯一。多个方法使用同一个线程池命名，代表使用同一个线程池。默认值是groupKey数据。
3.1.4、threadPoolProperties--用于为线程池设置的参数
其类型为HystrixProperty数组。
3.1.5、常用的线程池设置参数
1、 coreSize--线程池最大并发数（核心线程数），建议设置标准为：每秒最大支持请求数*（99%平均响应时间+一定量的缓冲时间（99%平均响应时间的10%-20%））如：每秒可以处理的最大请求数为1000，99%的平均响应时间为60ms，自定义的缓冲时间为60*20%=12ms，则最大并发数=1000*（0.060+0.012）=72；
2、 maxQueueSize--BlockingQueue的最大长度，默认值为-1，即不限制如果设置为正数，等待队列将从同步队列SynchronousQueue转换为阻塞队列LinkedBlockingQueue；
3、 queueSizeRejectionThreshold--设置拒绝请求的临界值，默认值为5此属性是配合阻塞队列使用的，也就是不适用maxQueueSize=-1(为-1时此设置无效)用于设置阻塞队列限制的，如果超出限制，则拒绝请求此参数的意义在于服务启动后，可以通过Hystrix的API调用configAPI动态修改而不用重启服务，不常用；
代码设置示例：
@HystrixCommand(fallbackMethod = "threadPoolFallback",commandKey = "testThreadPool",
groupKey = "testThreadPool", threadPoolKey = "testThreadPool",threadPoolProperties = {
//核心线程数，线程池最大并发数
@HystrixProperty(name=HystrixPropertiesManager.CORE_SIZE,value = "10"),
//最大线程数，默认为-1，即不限制，如果设置为正数
//等待队列将从同步队列synchronousQueue转换为阻塞队列LinkedBlockingQueue
@HystrixProperty(name=HystrixPropertiesManager.MAX_QUEUE_SIZE,value = "100"),
//设置拒绝请求的临界值，默认值为5，此属性是配合阻塞队列使用的
@HystrixProperty(name=HystrixPropertiesManager.QUEUE_SIZE_REJECTION_THRESHOLD,value = "80"),
})
@GetMapping("/threadPool")
public String threadPool() throws Exception{
Thread.sleep(10000);
return "success";
}
public String threadPoolFallback(){
return "threadPoolFallback server down";
}
3.2、信号量隔离
它的目的是为每个微服务限流，能够限制并发的请求数。信号量隔离使用的其实就是并发框架中的semaphore信号量类，我们通过设定semaphore的信号数，相当于设置了此微服务的并发请求数，每一个微服务进来，都会执行semaphore的acquire方法来获得信号量，同时，返回结果后执行release方法释放信号量。
所谓信号量隔离，就是设置一个并发处理的最大极值。当并发请求数超过极值时，通过fallback返回托底数据，保证服务的完整性
简单来说信号量的资源隔离是一个开关的作用（也可以理解为一个计数器），比如：服务A的信号量大小为10，那同时只允许有10个tomcat线程来访问服务A，其他请求都会被拒绝，从而达到资源隔离和限流保护的作用。
代码设置示例：
@HystrixCommand(fallbackMethod = "semaphoreFallback",commandProperties = {
//设置隔离方式，默认为线程池隔离
@HystrixProperty(name=HystrixPropertiesManager.EXECUTION_ISOLATION_STRATEGY,value = "SEMAPHORE"),
//设置最大并发数
@HystrixProperty(name=HystrixPropertiesManager.EXECUTION_ISOLATION_SEMAPHORE_MAX_CONCURRENT_REQUESTS,value = "10"),
})
@GetMapping("/semaphore")
public String semaphore() throws Exception{
if(System.currentTimeMillis()%2==0){
Thread.sleep(10000);
}
return "success";
}
public String semaphoreFallback(){
return "semaphore server down";
}
3.3、两种隔离方式的优缺点
3.3.1、线程池隔离：（实现原理：各个服务独立的线程池）
优点：线程是独立的，与其他服务接口线程互不影响，独立的线程也有并发处理的能力
支持超时设置、支持异步处理
缺点：占用CPU的资源开销较大，每个命令涉及到调度、CPU计算、队列、上下文切换等， 这些操作都是在独立的线程上完成的，所以性能较低。
3.3.2、信号量隔离：（实现原理：共用线程池，使用计数器进行限流）
优点：资源开销相对较小（共用web容器里的线程池）
缺点：不支持超时设置，依赖于系统/socket连接超时。也不支持异步
3.4、两种隔离方式的使用选择
3.4.1、线程池隔离
业务复杂，请求并发量大，并且服务耗时长（一般是计算量大或者访问数据库或者RPC远程调用）：采用线程池隔离，这样的话，可以保证大量的容器线程可用，不会由于服务原因，一直处于阻塞或者等待状态，快速失败返回。
3.4.2、信号量隔离
业务简单，请求并发量大，并且服务耗时短（一般是计算量小，或访问缓存，或者不涉及远程调用和第三方请求）：采用信号量隔离：因为这类服务的返回往往非常快，不会占用容器线程太长时间，并且减少了线程切换的一些开销，提高了缓存服务的效率
版权声明：本文不是「本站」原创文章，版权归原作者所有 | 原文地址: