服务发布后接口超时？两个注解带你起飞

不知道大家有没有碰到这样的问题：每次服务发布，在启动之后的一小段时间内，各种接口出现一些或多或少的超时，就像下图所示，凸起的线条是刚发布的机器的接口耗时，不同颜色代表不同机器：

直到一段时间后，接口耗时才逐渐回到正常水位。往往在一些比较敏感的业务场景下，这种发布时的耗时突刺带来的影响，就不是那么可以简单容忍了。就拿实时风控场景来打个比方，黑灰产分子逐渐摸索到，你页面某个营销抢券活动，每个月底凌晨0点左右会出现小概率点击超时，掐指一算，哦，哥们儿你发布呢；好，一波突袭。

而刚好这部分超时的服务，就是上图中那一批正在发布的风控规则引擎服务。

因为发布后服务还在初始化一些资源，这部分黑产的抢券请求，到了风控规则引擎后出现了规则执行超时，网关层在接口限定的时间内没有拿到风控结果；网关层就会返回兜底的响应码，以示放行；而营销系统侧就会认为这是一笔合法的抢券请求：

好了，游戏结束。黑产分子的钱捞到了，你的年终奖也打水漂了。

到目前为止，大家应该可以想到，这是一个关于服务预热的问题；而正如标题所说，我将试图通过本篇文章，帮助你改善服务启动时，接口耗时飙升的问题。

问题分析

启动后出现耗时抖动的原因是什么？相信不少技术人脑海里立马就会闪现出这些名词：类加载、对象创建、GC、连接池初始化、缓存的加载、JIT编译优化......

我们的应用中有很多代码和基础组件，都是基于懒加载的机制，在流量到达之后，再进行对应的资源加载，以保证应用本身可以尽可能快速启动。同时在JVM的运行过程中，对我们所写出来的代码进行一定手段的优化，例如C2编译、内存空间动态调整等，以便让应用启动后逐渐达到一个最佳的性能状态。而这些动作一般都会耗费一定的机器资源，甚至全局的停顿。

我们目前的风控规则引擎服务，是基于dubbo对风控网关提供服务的，而dubbo框架自身是带有启动预热功能的，先让我们来看一看dubbo源码中的预热逻辑（版本2.7.9）：

（1）消费者先从url中拿到服务提供者的权重配置，默认是100。

（2）再从url中拿到服务提供者的上线时间戳，计算得到服务提供者的上线时间毫秒数。

（3）再从url拿到服务提供者预热的时间配置，默认10分钟。

（4）再通过(上线时间毫秒数 / 10分钟毫秒数) * 100，就计算出了一个当前服务提供者的真实权重。

这里计算方式其实很简单，简单的说，服务运行时间越久，权重越高，直到达到配置的权重100。

如果服务提供者已运行 1 分钟，那么得到权重的结果为 10 ；如果服务提供者已运行 5 分钟，那么得到权重的结果为 50 ；如果服务提供者已运行 11 分钟，超过配置的预热时间阈值 10分钟，那么将不会再计算，直接返回配置的权重100。

这样在客户端进行加权负载均衡路由的时候，选择到这台服务提供者的请求流量，在前10分钟内，就会基本呈现一个线性直线：

这种随着服务端上线时间，逐步给服务端增加流量权重的预热方案，对大部分后端服务来说没什么毛病，在服务端还没完全达到最佳性能的时候，先给予小比例的流量让服务端完成预热；等预热完成后，再恢复到正常流量。

但是还是存在对于风控这种敏感场景下的一个致命问题：刚启动的时候，放入的那些请求流量，因为受制于服务端本身一些JIT编译、连接池准备等预热工作没准备好，导致这部分流量显得 “很慢” ，会出现一些超时的case，进而导致一些资损。

解决思路

dubbo的预热机制是面向真实流量的，那我们完全可以在dubbo端口对外暴露之前，自己mock一部分压力流量来完成预热，那是不是就不会有上面影响真实流量的问题？

在基础组件中提供统一的注解和监听器，来自动完成这部分工作，这样对于不同的业务代码的侵入性就很低。
通过注解中不同的参数配置，来控制预热的强度和时间，从而满足不同业务接口的需要；同时这套预热组件，也能顺理成章地成为一个平台内部所有微服务的通用能力。

落地方案

1、我们在内部通用技术组件april中提供了一个新的注解：@Warmup，可以作用于接口方法上，属性列表：

concurrent：并行线程数，多少个线程发起压力预热，默认是1，单线程执行预热；如果大于1，采用多线程执行。
targetLatency：期待目标执行毫秒数，如果配置了就会达到目标延迟才停止。
maxCounts：接口最大预热次数，默认100次。
mockArgs：预热使用的模拟传入的参数列表，因为每次预热都是用的这些同样的参数列表，所以使用的参数数据建议是测试用的数据。
clusters：生效集群环境，取项目系统参数配置项app.cluster的值。如果值不为空，则预热只会在该集群生效。

其中targetLatency和maxCounts参数任意一个达到了阈值，就停止预热。

为什么基于注解来实现预热：

（1）对服务模块的代码侵入性低，只需要在原业务代码上添加注解。

（2）相对来说比较灵活，能做到方法级别预热。

（3）通用性强，能适配所有业务接口。

2、april组件中提供一个新的Spring application监听器：WarmupApplicationListener，优先级是 LOWEST_PRECEDENCE -2 ,在dubbo的启动类监听器DubboBootstrapApplicationListener之前执行。

这样就能保证预热发生在dubbo对外提供服务之前，被Spring自动触发自动预热。

3、底层执行流程：

（1）在Spring进行实例化bean阶段，通过一个自定义的PeacefulTargetPostProcessor，完成对于所有bean的方法上的@Warmup注解的扫描，把每个带有@Warmup注解的方法，包装成一个带有预热目标方法、对象、参数列表、预热次数等信息的WarmTarget对象，收集到一个List集合。

（2）Spring容器实例化完所有的Bean对象后，发布容器刷新完成事件，WarmupApplicationListener监听到这个事件后，遍历List集合，并根据注解的concurrent参数创建对应的临时线程池。

（3）通过反射，基于注解传入的mockArgs参数，丢到临时线程池中，并发执行目标对象的目标方法。

（4）并在执行过程中，不断判断是否达到配置的预期方法执行耗时targetLatency，以及最大执行次数

maxCounts。

（5）所有方法预热完毕后，销毁预热临时线程池；随后Spring最后触发dubbo启动监听器，完成dubbo服务发布，正式对外接流。

效果检验

出于稳定性和当时的紧急程度等相关因素考虑，我们首先选取了另一个服务：数据特征执行服务，作为我们初次实验预热组件的对象。

未接入预热组件前，服务启动后，特征读取接口耗时：

选择单台机器实验，接入预热组件后，启动后接口耗时：

可以直观的看出来，接口耗时从原来的2.7s，降到了330ms左右，降低了将近一个数量级！

这个效果，看上去是不是还是很nice的？

但是转念一看，这个330ms，距离服务常稳运行时候的10ms左右的耗时，似乎还是有很大的距离。