java warmup,20. dubbo源码-预热warmup过程

阿飞Javaer，转载请注明原创出处，谢谢！

前言

今天群里小伙伴黄晓峰VIVO咨询一个问题：”dubbo接口怎么做预热呢，每次上线，都会有一小部分超时？”，熟悉JVM都知道，JVM重启后有一段预热过程，要运行一段时间，它的性能才能达到最佳状态；阿里JVM团队就针对这个缺陷进行了优化，其特性名曰：jwarmup，可以点击Alibaba JVM创新提效 获国际社区认可登台JVM圈顶会，对jwarmup稍微了解；

另外，在阿里大神你假笨那里了解到jwarmup的大概原理：针对上次JIT对应用的优化，主动去触发JIT编译优化，而不是等jvm运行一段时间自己去感知！

阿里大厂可以这么做，我们小厂肿么办？事实上dubbo作者梁飞大神考虑到了这种情况，在dubbo中也引入了”warmup”特性(和阿里的jwarmup还是完全不一样的)，核心源码在”com.alibaba.dubbo.rpc.cluster.loadbalance.AbstractLoadBalance.java”中：

protected int getWeight(Invoker> invoker, Invocation invocation) {

// 先得到Provider的权重

int weight = invoker.getUrl().getMethodParameter(invocation.getMethodName(), Constants.WEIGHT_KEY, Constants.DEFAULT_WEIGHT);

if (weight > 0) {

// 得到provider的启动时间戳

long timestamp = invoker.getUrl().getParameter(Constants.REMOTE_TIMESTAMP_KEY, 0L);

if (timestamp > 0L) {

// provider已经运行时间

int uptime = (int) (System.currentTimeMillis() – timestamp);

// 得到warmup的值，默认为10分钟

int warmup = invoker.getUrl().getParameter(Constants.WARMUP_KEY, Constants.DEFAULT_WARMUP);

// provider运行时间少于预热时间，那么需要重新计算权重weight(即需要降权)

if (uptime > 0 && uptime < warmup) {

weight = calculateWarmupWeight(uptime, warmup, weight);

}

}

}

return weight;

}

static int calculateWarmupWeight(int uptime, int warmup, int weight) {

// 随着provider的启动时间越来越长，慢慢提升权重直到weight

int ww = (int) ( (float) uptime / ( (float) warmup / (float) weight ) );

return ww < 1 ? 1 : (ww > weight ? weight : ww);

}

warnup权重计算过程：

根据calculateWarmupWeight()方法实现可知，随着provider的启动时间越来越长，慢慢提升权重直到weight，且权重最小值为1，所以：

如果provider运行了1分钟，那么weight为10，即只有最终需要承担的10%流量；

如果provider运行了2分钟，那么weight为20，即只有最终需要承担的20%流量；

如果provider运行了5分钟，那么weight为50，即只有最终需要承担的50%流量；

… …

这里需要注意的是，dubbo默认有3种负载均衡实现方式：随机，轮询，一致性哈希；其中一致性哈希是不受权重影响的，也就是说，如果选择一致性哈希负载均衡，就不支持dubbo的预热特性了；可以参考14.dubbo源码-负载均衡，有对其进行分析；

问题

既然，dubbo有预热功能，为什么每次重启，还会有那么多的超时呢？后来咨询小伙伴黄晓峰VIVO，他们的dubbo是基于dubbox的自建分支，dubbox2.8.4和dubbo原生分支的代码是有一点出入的：

dubbox&dubbo AbstractLoadBalance.java差异性

笔者查找Github上dubbo更新，从AbstractLoadBalance.java的提交记录发现有过一次fix，记录如下：

Fix warmup timestamp bug

修改记录为如下所示：

the commit

真相

真相原来如此，由于dubbox基于dubbo比较老的分支，而这个bug fix是committed on 10 Oct 2017；所以dubbox分支的bug依然存在。

既然提到dubbo预热问题，另外一个优化点也可以参考一下，dubbo官方称之为延迟暴露：

# 这个申明的含义是等spring容器启动后过5s再暴露dubbo服务：

或者延迟暴露某个接口：

验证日志如下–可以看到”Dubbo service server started”即dubbo服务启动后，过了5s才暴露服务：

[28/04/18 05:40:59:059 CST] main INFO support.DefaultListableBeanFactory: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@6b927fb: defining beans [dubbo-test,com.alibaba.dubbo.config.RegistryConfig,com.alibaba.dubbo.config.ProviderConfig,demoService,testService,com.alibaba.dubbo.demo.DemoService,com.alibaba.dubbo.demo.TestService]; root of factory hierarchy

[28/04/18 05:40:59:059 CST] main INFO container.Main: [DUBBO] Dubbo SpringContainer started!, dubbo version: 2.0.0, current host: 127.0.0.1

[2018-04-28 17:40:59] Dubbo service server started!

[28/04/18 05:41:04:004 CST] DelayExportServiceThread INFO config.AbstractConfig: [DUBBO] Export dubbo service com.alibaba.dubbo.demo.DemoService to local registry, dubbo version: 2.0.0, current host: 127.0.0.1

[28/04/18 05:41:04:004 CST] DelayExportServiceThread INFO config.AbstractConfig: [DUBBO] Export dubbo service com.alibaba.dubbo.demo.TestService to local registry, dubbo version: 2.0.0, current host: 127.0.0.1

总结

无论是dubbo的warmup特性还是延迟暴露服务，对生产环境都有很大的帮助，所以，赶紧做如下的优化吧：

如果是dubbox分支，或者旧的dubbo分支，请修复warmup特性时间戳的问题；

配置延迟暴露所有dubbo服务；

说明：按照dubbo的参数等价转换特性，可以用-Ddubbo.provider.deplay=5000代替，但是笔者跟踪源码发现这里有个bug并已经提交了issue，请戳System property dubbo.service.delay invalid，所以目标老老实实用这种xml配置吧