springcloud3.记一次网关优化

Posted 2020-11-23 cutter_point

今天早上过来突然被告知我们提供给外系统的接口服务出问题了，失败率高达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两个参数的值之和要大