描述

负责的应用正式环境发版期间，下游应用调用服务告警，查看监控发现这个时间段内偶发下游调用查询接口超时，服务耗时波动如下图：

并且当应用的所有节点服务发布完成后，偶发的接口超时告警自动恢复，因此盲猜是服务发布时的抖动导致该问题，于是有以下几个猜测：

1. 服务注册发现流程问题：节点下线后未及时从注册中心剔除下线节点，导致下游调用到了下线节点
2. 服务注册发现流程问题：节点上线后先在注册中心注册节点，再开放服务端口，导致中间的时间差服务无响应
3. 资源初始化问题：节点上线后资源未初始化完成，下游调用服务后资源首次初始化耗时长导致服务超时

排查

每个请求都对应一个唯一的traceId做链路追踪，通过下游服务调用超时错误日志中对应的traceId，找到该请求路由到的具体容器节点后，查看日志发现，应用于2021-07-16 11:41:42启动完成，而超时请求于2021-07-16 11:41:47路由到该节点，也就是节点先启动注册完成后，再出现服务响应超时的情况，因此猜想1排除。

接着排查该节点启动后的接口响应耗时情况，于是查看日志数据，前10条记录。该几个请求链路均为查询接口，请求的流程图如下：

由日志可得，该节点应用启动完成后，前3次服务响应耗时正常，第4-7次的响应耗时明显过长，但从第8次起响应耗时又恢复正常。于是通过以上几个链路的traceId查看每个请求的调用链路情况：

1. 第1次请求直接命中tair缓存，响应耗时正常。
2. 第2次请求直接命中堆内缓存，响应耗时正常。
3. 第3次请求直接命中堆内缓存，响应耗时正常。
4. 第4次请求缓存命中失败，请求数据库查询，数据库执行耗时超长。
5. 第5次请求缓存命中失败，请求数据库查询，数据库执行耗时超长。
6. 第6次请求缓存命中失败，请求数据库查询，数据库执行耗时超长。
7. 第7次请求缓存命中失败，请求数据库查询，数据库执行耗时超长。

很明显超时的原因是因为缓存命中失败后请求数据库查询而导致，但排查后续中的链路即使出现查询数据库也未出现服务响应耗时过长的情况，因此怀疑是数据库连接未初始化的问题：应用刚启动完成后，请求查询数据库前需要额外请求配置中心初始化相关配置并且创建数据库连接，导致的耗时超长的情况。

咨询同事后得知应用在已经配置开启了数据库连接预热，于是去查看预热配置说明：是否预热最小连接数。然后再查看连接池配置，发现当前的连接池配置的最小连接数为0。也就是说应用启动时预热了个寂寞，导致应用启动后数据库连接池数量为0，当请求到该应用后前几次请求均需要创建新数据库连接因而耗时较长，而后续请求直接复用连接池连接因此后续请求处理耗时恢复正常。

解决

配置中心平台修改应用的连接池配置，最小连接数从0修改为5，保证应用在启动完成后数据库连接池已经初始化完成。等待下次应用迭代发布时监控新发布应用的请求耗时情况。