springcloud3.记一次网关优化

Posted cutter_point

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了springcloud3.记一次网关优化相关的知识,希望对你有一定的参考价值。

今天早上过来突然被告知我们提供给外系统的接口服务出问题了,失败率高达20%

很奇怪,昨天周末,今天也没做什么处理,怎么突然变成这样了

 

1.接口测试

第一反应是接口是不是出问题了,然后我立马打开jmeter调20次接口

 

 

问题是全部成了???

这就很奇怪了,让对端提供截图证据,是不是别人搞我???

 

2.定位问题服务

 

 

根据对端反馈的视频,可以看到反馈的报错是zuulexception

那么就可以确定,问题抛出的地方在zuul

然后打开日志一看,这一看直接爆炸。。。。

日志疯狂报错,timed-out and no fallback available.

因为当时部署的4个节点,这个机器上的2个节点疯狂报这个错,但是只有20%的的失败率,这个就很奇怪了,

于是我打开第二台机器的日志。。。。

哔了狗。。。。。第二天机器居然毫无波动???

啥意思?就瞧不起前面这台机器咯,到这里我就懵逼了,百思不得起解,然后我第一反应就是看源码。。。

3.源码定位问题

那么要通过源码定位问题,就要准备类似的环境了,生产肯定是不能乱动的

因为之前说过,有台机器是好的,我就先把第一台机器的服务关闭,先把第二台机器的2个节点顶一下了

那么现在生产先抛到一边,我们准备一下环境

1.eureka,2.zuul 3.demo服务

先起eureka

 

 吧对应的服务注册上去

 

 

 

准备接口请求,然后我准备在原来的服务上打个断点,卡一会再过去看看效果

然后我发现卡半天,毫无波动。。。。

几分钟后。。。

终于报错了,但是报的错确不是之前的那个错了

 

 

为了模拟那种情况

调试zuul网关参数

设置熔断超时时间:150毫秒,够少了吧

 

 

 测试一波

 

 

 

终于问题得到复现,很显然是在熔断超时的时间内没有得到返回导致的

但是我们对接口响应时间有要求,3s之内没有返回就应该算超时

那么这个值默认是多少呢??

 

 

 

这也太短了,1s不返回就当超时,我们这个接口涉及到的子接口就有6个,更不用说自己还有部分逻辑了,又不能直接把原子接口直接给外系统用

那这边只能改参数了

 

 

 

调整之后,调整之后,我们再试试效果

效果确实得到改观

测试请求时间:16点26分26s

 

 

我们报错时间:16:26:29.

 

 

跟我们设置的参数吻合,很好

那是不是吧这个调大就把这个问题解决了呢???

 

4、压测

我们再试试再大量请求的情况下是否还是会出现这种情况,或者是等待

为了更好的测试,我们设置进程池最大数量为2个

 

单请求没问题

 

 

 

我们接下来直接模拟8个线程同时请求接口,并在服务中添加线程等待的方法模拟业务繁忙

 

 

接下来我们测试一下

 

 

 随着时间的推移,我们发现失败的数量越来越多,前面的未执行完,后面的继续堆积

 

 

 

总结:

说白了就是调整熔断返回超时的时间,这个default可以手动设置为对应的服务id

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds

 

最后注意一点:

这个值要比:ribbon.ReadTimeout 与 ribbon.ConnectTimeout两个参数的值之和要大

 

以上是关于springcloud3.记一次网关优化的主要内容,如果未能解决你的问题,请参考以下文章

Unity记一次Profiler补捉到的粒子性能优化

记一次centos7主机名变bogon导致ORACLE无法远程访问的经历(原创)

记一次 webpack 打包体积优化

记一次mysql性能优化过程

记一次数据库性能优化

记一次springcloud并发优化