Lorentz灰度发布引发业务服务异常问题分析报告.pdfVIP

Lorentz生产环境灰度在2019.06.13以及2019.06.18两次造成业

务停止响应的问题追查

现象

2019.06.13sso服务无响应(502)

上午:Lorentz提交带HTTPkeepalive功能的灰度版本，做生产发布

15:27Lorentz转发层灰度节点升级完成，接入1/1000的总体流量进行灰度

15:28sso开始出现502(部分请求)

15:33sso业务反馈出现问题，经过排查怀疑是业务服务问题

15:40左右运维重新部署sso，服务问题被解决

16:00Lorentz灰度节点回退至上一版本

当题出现时有过对于Lorentz出现问题的怀疑，因为Lorentz自身也依赖SSO，故怀疑Lorentz的灰度节点有故障回会大量请求SSO进而压垮

SSO。但是通过当天下午对于SSO接收到的请求数量，Lorentz灰度节点的流量、TCP等机器排除此可能性。

由于没有找到Lorentz导致问题的故继而排除对于Lorentz的怀疑，择机重新灰度。

2019.06.18钱包部分服务无响应(502)

当日同运维沟通，再次对于上次灰度失败的Lorentz版本

现象同06.13一样，Lorentz开始灰度后2分钟分业务服务出现502。业务服务重新部署后恢复正常

Lorentz回滚灰度节点

问题定位

初步定位

06.18问题出现后，重起对于Lorentz新版本的怀疑

1.排查业务逻辑，未发现问题。

2.开始怀疑Lorentz灰度版本HTTPkeepalive新特性导致业务服务不正常。

a.重新检查机器上的TCP连接数等指标

b.从机器上发现业务服务出现未响应的节点所在的机出现openfile统计突增现象,突增量大8000个文件描述符左右

c.从Lorentz机器上上发现Lorentz正式节点上发现在业务服务不响应的同时出现了比其他时间段的tcpfin_wait2状态

d.从上面现象判断业务服务出现了在连接处理上出现问题，故排除业务基本框架发现使用的都是tomcat8.5.15版本。

3.在下线通过QA以及QA环境模拟压测生产场景

a.模拟业务服务，使用业务服务相同的tomcat基础镜像，业务逻辑模拟30ms左右的响应延迟

b.Lorentz使用2个正常节点。

c.使用工具通过Lorentz模拟的业务服务，期间不停止

d.Lorentz新增一个灰度节点，承载总体流量的1/1000

e.通过两天时间各种模拟未复现生产环境现象

4.重头排查生产Lorentz灰度节点日志，发现在业务服务节点不可响应的初始几点，从Lorentz灰度节点的到业务服务不可响应节点的多次请

求的平均间隔需要10-30秒左右。开始怀疑在HTTP1.1下没有使用Connction:close，默认开启了keepalive机制，同时在这个被保持的连接上

短时间内并没有被复用，与此同时同一服务上有大量的HTTP1.1请求带上了Connction:close，在此场景下可能会出现问题。

5.在QA环境中发现在复现的压测场景中通过灰度的Lorentz节点(使用了keepalive机制)到业务服务的频次明显高于生产环境中灰度的量，

所以对于单一服务压测复现上的难点在于控制压测请求QPS，故改变复现策略

a.不采用3-d中的灰度方式，而是所有压测流量均通过Lorentz正常节点。同时手动触发一次通过Lorentz灰度节点的带有keepalive的

请求，自此成功复现生产环境服务无响应现象

b.同时获取了服务响应时出现了大量的TCPCLOSE_WAIT状态和JVMjstack的内容。在jstack得到信息中可以看到在APR模式下

tomcat的accept线程在一个基于计数的锁上等待。

c.从现象看来，基本确定是tomcat自身问题导致

根本

经过对于tomcat