为什么大厂服务并发高却很稳定？分布式服务熔断降级限流利器

2401_85112133

于 2024-05-28 20:12:26 发布

阅读量552

点赞数 18

分类专栏：作者\/ 文章标签： java linux 开发语言

本文链接：https://blog.csdn.net/2401_85112133/article/details/139276861

版权

作者\/ 专栏收录该内容

29 篇文章 0 订阅

订阅专栏

@HystrixCommand(

groupKey = “order-service-getPaymentInfo”,

commandKey = “getPaymentInfo”,

threadPoolKey = “orderServicePaymentInfo”,

commandProperties = {

@HystrixProperty(name = “execution.isolation.thread.timeoutInMilliseconds”,value = “1000”)

threadPoolProperties = {

@HystrixProperty(name = “coreSize” ,value = “6”),

@HystrixProperty(name = “maxQueueSize”,value = “100”),

@HystrixProperty(name = “keepAliveTimeMinutes”,value = “2”),

@HystrixProperty(name = “queueSizeRejectionThreshold”,value = “100”)

fallbackMethod = “getPaymentInfoFallback”

)

@RequestMapping(value = “/getpayment/{id}”,method = RequestMethod.GET)

public ResultInfo getPaymentInfo(@PathVariable(“id”) Long id) {

log.info(Thread.currentThread().getName());

return restTemplate.getForObject(PAYMENT_URL+“/payment/get/”+id, ResultInfo.class);

}

public ResultInfo getPaymentInfoFallback(@PathVariable(“id”) Long id) {

log.info(“已经进入备选方案了，下面交由自由线程执行”+Thread.currentThread().getName());

return new ResultInfo();

}

@HystrixCommand(

groupKey = “order-service-getpaymentTimeout”,

commandKey = “getpaymentTimeout”,

threadPoolKey = “orderServicegetpaymentTimeout”,

commandProperties = {

@HystrixProperty(name = “execution.isolation.thread.timeoutInMilliseconds”,value = “10000”)

threadPoolProperties = {

@HystrixProperty(name = “coreSize” ,value = “3”),

@HystrixProperty(name = “maxQueueSize”,value = “100”),

@HystrixProperty(name = “keepAliveTimeMinutes”,value = “2”),

@HystrixProperty(name = “queueSizeRejectionThreshold”,value = “100”)

}

)

@RequestMapping(value = “/getpaymentTimeout/{id}”,method = RequestMethod.GET)

public ResultInfo getpaymentTimeout(@PathVariable(“id”) Long id) {

log.info(Thread.currentThread().getName());

return orderPaymentService.getTimeOut(id);

}

复制代码

这里演示效果不好展示，我就直接展示数据吧。

并发量在getpaymentTimeout	getpaymentTimeout/{id}	/getpayment/{id}
20	三个线程打满后一段时间开始报错	可以正常响应；也会慢，cpu线程切换需要时间
30	同上	同上
50	同上	也会超时，因为order调用payment服务压力会受影响

如果我们将hystrix加载payment原生服务就不会出现上面第三条情况。为什么我会放在order上就是想让大家看看雪崩的场景。在并发50的时候因为payment设置的最大线程也是10，他本身也是有吞吐量的。在order#getpyament/id接口虽然在order模块因为hystrix线程隔离有自己的线程运行，但是因为原生服务不给力导致自己调用超时从而影响运行的效果。这样演示也是为了后续引出fallback解决雪崩的一次场景模拟吧。
我们可以在payment服务中通过hystrix设置fallback。保证payment服务低延迟从而保证order模块不会因为payment自己缓慢导致order#getpayment这种正常接口异常。
还有一点虽然通过hystrix进行线程隔离了。但是我们在运行其他接口时响应时间也会稍长点。因为CPU在进行线程切换的时候是有开销的。这一点也是痛点。我们并不能随心所欲的进行线程隔离的。这就引出我们的信号量隔离了。

信号量隔离

=====

关于信号量隔离这里也就不演示了。演示的意义不是很大

@HystrixCommand(

commandProperties = {

@HystrixProperty(name = “execution.isolation.thread.timeoutInMilliseconds”,value = “1000”),

@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_STRATEGY,value = “SEMAPHORE”),

@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_SEMAPHORE_MAX_CONCURRENT_REQUESTS,value = “6”)

fallbackMethod = “getPaymentInfoFallback”

)

复制代码

我们如上配置表示信号量最大为6 。表示并发6之后就会进行等待。等待超时时间未1s。

措施	优点	缺点	超时	熔断	异步
线程隔离	一个调用一个线程池；互相不干扰；保证高可用	cpu线程切换开销	√	√	√
信号量隔离	避免CPU切换。高效	在高并发场景下需要存储信号量变大	×	√	×

除了线程隔离、信号量隔离等隔离手段我们可以通过请求合并、接口数据缓存等手段加强稳定性。

服务降级

====

触发条件

====

程序发生除HystrixBadRequestException异常。
服务调用超时
服务熔断
线程池、信号量不够

为什么大厂服务并发高却很稳定？分布式服务熔断降级限流利器

在上面我们的timeout接口。不管是线程隔离还是信号量隔离在条件满足的时候就会直接拒绝后续请求。这样太粗暴了。上面我们也提到了fallback。
还记的上面我们order50个并发的timeout的时候会导致getpayment接口异常，当时定位了是因为原生payment服务压力撑不住导致的。如果我们在payment上加入fallback就能保证在资源不足的时候也能快速响应。这样至少能保证order#getpayment方法的可用性

为什么大厂服务并发高却很稳定？分布式服务熔断降级限流利器

但是这种配置属于实验性配置。在真实生产中我们不可能在每个方法上配置fallback的。这样愚蠢至极。
hystrix除了在方法上特殊定制的fallback以外，还有一个全局的fallback。只需要在类上通过@DefaultProperties(defaultFallback = “globalFallback”)来实现全局的备选方案。一个方法满足触发降级的条件时如果该请求对应的HystrixCommand注解中没有配置fallback则使用所在类的全局fallback。如果全局也没有则抛出异常。

不足

虽然DefaultProperties 可以避免每个接口都配置fallback。但是这种的全局好像还不是全局的fallback。我们还是需要每个类上配置fallback。笔者查阅了资料好像也没有
但是在openfeign专题里我们说了openfeign结合hystrix实现的服务降级功能。还记的里面提到了一个FallbackFactory这个类吗。这个类可以理解成spring的BeanFactory。这个类是用来产生我们所需要的FallBack的。我们在这个工厂里可以生成一个通用类型的fallback的代理对象。代理对象可以根据代理方法的方法签名进行入参和出参。
这样我们可以在所有的openfeign地方配置这个工厂类。这样的话就避免的生成很多个fallback。美中不足的还是需要每个地方都指定一下。关于FallBackFactory感兴趣的可以下载源码查看或者进主页查看openfeign专题。

服务熔断

====

@HystrixCommand(

commandProperties = {

@HystrixProperty(name = “circuitBreaker.enabled”,value = “true”), //是否开启断路器

@HystrixProperty(name = “circuitBreaker.requestVolumeThreshold”,value = “10”), //请求次数

@HystrixProperty(name = “circuitBreaker.sleepWindowInMilliseconds”,value = “10000”), //时间范围

@HystrixProperty(name = “circuitBreaker.errorThresholdPercentage”,value = “60”), //失败率达到多少后跳闸

fallbackMethod = “getInfoFallback”

)

@RequestMapping(value = “/get”, method = RequestMethod.GET)

public ResultInfo get(@RequestParam Long id) {

if (id < 0) {

int i = 1 / 0;

}

log.info(Thread.currentThread().getName());

return orderPaymentService.get(id);

}

public ResultInfo getInfoFallback(@RequestParam Long id) {

return new ResultInfo();

}

- 首先我们通过circuitBreaker.enabled=true开启熔断器
circuitBreaker.requestVolumeThreshold设置统计请求次数
circuitBreaker.sleepWindowInMilliseconds 设置时间滑动单位，在触发熔断后多久进行尝试开放，及俗称的半开状态
circuitBreaker.errorThresholdPercentage 设置触发熔断开关的临界条件
上面的配置如果最近的10次请求错误率达到60% ，则触发熔断降级，在10S内都处于熔断状态服务进行降级。10S后半开尝试获取服务最新状态
下面我们通过jmeter进行接口http://localhost/order/get?id=-1进行20次测试。虽然这20次无一例额外都会报错。但是我们会发现一开始报错是因为我们代码里的错误。后面的错误就是hystrix熔断的错误了。一开始试by zero 错误、后面就是short-circuited and fallback failed 熔断错误了

为什么大厂服务并发高却很稳定？分布式服务熔断降级限流利器

正常我们在hystrix中会配置fallback ，关于fallback两种方式我们上面降级章节已经实现了。这里是为了方便看到错误的不同特意放开了。

为什么大厂服务并发高却很稳定？分布式服务熔断降级限流利器

在HystrixCommand中配置的参数基本都是在HystrixPropertiesManager对象中。我们可以看到关于熔断器的配置有6个参数。基本就是我们上面的四个配置

服务限流

====

服务降级我们上面提到的两种隔离就是实现限流的策略。

请求合并

====

除了熔断、降级、限流意外hystrix还为我们提供了请求合并。顾名思义就是将多个请求合并成一个请求已达到降低并发的问题。
比如说我们order有个接个是查询当个订单信息order/getId?id=1 突然有一万个请求过来。为了缓解压力我们集中一下请求每100个请求调用一次order/getIds?ids=xxxxx 。这样我们最终到payment模块则是10000/100=100个请求。下面我们通过代码配置实现下请求合并。

HystrixCollapser

================

@Target({ElementType.METHOD})

@Retention(RetentionPolicy.RUNTIME)

@Documented

public @interface HystrixCollapser {

String collapserKey() default “”;

String batchMethod();

Scope scope() default Scope.REQUEST;

HystrixProperty[] collapserProperties() default {};

}

属性	含义
collapserKey	唯一标识
batchMethod	请求合并处理方法。即合并后需要调用的方法
scope	作用域；两种方式[REQUEST, GLOBAL] ; REQUEST : 在同一个用户请求中达到条件将会合并 GLOBAL : 任何线程的请求都会加入到这个全局统计中
HystrixProperty[]	配置相关参数

为什么大厂服务并发高却很稳定？分布式服务熔断降级限流利器

在Hystrix中所有的properties配置都会在HystrixPropertiesManager.java中。我们在里面可以找到Collapser只有两个相关的配置。分别表示最大请求数和统计时间单元。

@HystrixCollapser(

scope = com.netflix.hystrix.HystrixCollapser.Scope.GLOBAL,

batchMethod = “getIds”,

collapserProperties = {

@HystrixProperty(name = HystrixPropertiesManager.MAX_REQUESTS_IN_BATCH , value = “3”),

@HystrixProperty(name = HystrixPropertiesManager.TIMER_DELAY_IN_MILLISECONDS, value = “10”)

}

)

@RequestMapping(value = “/getId”, method = RequestMethod.GET)

public ResultInfo getId(@RequestParam Long id) {

if (id < 0) {

int i = 1 / 0;

}

log.info(Thread.currentThread().getName());

return null;

}

@HystrixCommand

public List getIds(List ids) {

System.out.println(ids.size()+“@@@@@@@@@”);

return orderPaymentService.getIds(ids);

}

上面我们配置了getId会走getIds请求，最多是10S三个请求会合并在一起。然后getIds有payment服务在分别去查询最终返回多个ResultInfo。

为什么大厂服务并发高却很稳定？分布式服务熔断降级限流利器

我们通过jemeter进行getId接口压测，日志中ids的长度最大是3 。验证了我们上面getId接口的配置。这样就能保证在出现高并发的时候会进行接口合并降低TPS。
上面我们是通过请求方法注解进行接口合并处理。实际上内部hystrix是通过HystrixCommand

工作流程

====

为什么大厂服务并发高却很稳定？分布式服务熔断降级限流利器

官网给出的流程图示，并配备流程说明一共是9部。下面我们就翻译下。
①、创建HystrixCommand或者HystrixObservableCommand对象 HystrixCommand : 用在依赖单个服务上 HystrixObservableCommand : 用在依赖多个服务上
②、命令执行，hystrrixCommand 执行execute、queue ； hystrixObservableCommand执行observe、toObservable

方法	作用
execute	同步执行；返回结果对象或者异常抛出
queue	异步执行；返回Future对象
observe	返回Observable对象
toObservable	返回Observable对象

③、查看缓存是否开启及是否命中缓存，命中则返回缓存响应
④、是否熔断，如果已经熔断则fallback降级；如果熔断器是关闭的则放行
⑤、线程池、信号量是否有资源供使用。如果没有足够资源则fallback 。有则放行
⑥、执行run或者construct方法。这两个是hystrix原生的方法，java实现hystrix会实现两个方法的逻辑，springcloud已经帮我们封装了。这里就不看这两个方法了。如果执行错误或者超时则fallback。在此期间会将日志采集到监控中心。
⑦、计算熔断器数据，判断是否需要尝试放行；这里统计的数据会在hystrix.stream的dashboard中查看到。方便我们定位接口健康状态
⑧、在流程图中我们也能看到④、⑤、⑥都会指向fallback。也是我们俗称的服务降级。可见服务降级是hystrix热门业务啊。
⑨、返回响应

HystrixDashboard

================

hystrix 除了服务熔断、降级、限流以外，还有一个重要的特性是实时监控。并形成报表统计接口请求信息。
关于hystrix的安装也很简单，只需要在项目中配置actutor和hystrix-dashboard两个模块就行了

org.springframework.cloud

spring-cloud-starter-netflix-hystrix-dashboard

org.springframework.boot

spring-boot-starter-actuator

复制代码

启动类上添加EnableHystrixDashboard 就引入了dashboard了。我们不需要进行任何开发。这个和eureka一样主需要简单的引包就可以了。

为什么大厂服务并发高却很稳定？分布式服务熔断降级限流利器

就这样dashboard搭建完成了。dashboard主要是用来监控hystrix的请求处理的。所以我们还需要在hystrix请求出将端点暴露出来。
在使用了hystrix命令的模块加入如下配置即可，我就在order模块加入

@Component

public class HystrixConfig {

@Bean

public ServletRegistrationBean getServlet(){

HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();

ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);

2401_85112133

关注

18
点赞
踩
16

收藏

觉得还不错? 一键收藏
0
评论
为什么大厂服务并发高却很稳定？分布式服务熔断降级限流利器

在order#getpyament/id接口虽然在order模块因为hystrix线程隔离有自己的线程运行，但是因为原生服务不给力导致自己调用超时从而影响运行的效果。后面的错误就是hystrix熔断的错误了。还记的上面我们order50个并发的timeout的时候会导致getpayment接口异常，当时定位了是因为原生payment服务压力撑不住导致的。这两个是hystrix原生的方法，java实现hystrix会实现两个方法的逻辑，springcloud已经帮我们封装了。这就引出我们的信号量隔离了。
复制链接

扫一扫