阿里大厂可以这么做，我们小厂肿么办？事实上 dubbo 作者 梁飞大神 考虑到了这种情况，在dubbo中也引入了”warmup”特性（注意，虽然都叫warnup， 但是dubbo的warmup和阿里JVM的jwarmup原理还是完全不一样的 ），核心源码在 “com.alibaba.dubbo.rpc.cluster.loadbalance.AbstractLoadBalance. Java ” 中：
protected int get weight (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的预热特性了。
问题
既然，dubbo有预热功能，为什么每次重启，还会有那么多的超时呢？后来咨询小伙伴 黄晓峰VIVO ，他们的dubbo是基于dubbox的自建分支，dubbox2.8.4和dubbo原生分支的代码是有一点出入的：
笔者查找Github上dubbo更新，从 AbstractLoadBalance.java 的提交记录发现有过一次fix，记录如下：
修改记录为如下所示：
fix来源：
#diff-c5cb2df641f0a7d0553343c757425d2b
真相
真相原来如此，由于dubbox基于dubbo比较老的分支，而这个bug fix是committed on 10 Oct 2017，所以dubbox分支的bug依然存在。我相信很多使用老版本dubbo或者dubbox的公司，都存在这个问题！
既然提到dubbo预热问题，另外一个优化点也可以参考一下（和warmup没有关系），dubbo官方称之为 延迟暴露 ：
# 这个申明的含义是等spring容器启动后过5s再暴露dubbo服务：
<dubbo:provider delay="5000"/>
或者延迟暴露某个接口：
<dubbo:service delay="5000" interface="com.alibaba.dubbo. demo .DemoService" ref="demoService" version="1.0.0"/> 验证日志如下–可以看到”Dubbo service server started”即dubbo服务启动后，过了5s才暴露服务：
[28/04/18 05:40:59:059 CST] main INFO support.DefaultListableBean factory : 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分支，请升级dubbo版本，或者merge这个PR修复warmup特性时间戳的问题；
- 配置dubbo:provider delay=”5000″延迟暴露所有dubbo服务；
注意 ：按照dubbo参数等价转换特性，可以用-Ddubbo.provider.deplay代替，我自己是一名从事了多年开发的Java老程序员，辞职目前在做自己的Java私人定制课程，今年年初我花了一个月整理了一份最适合2019年学习的Java学习干货，从最基础的 JavaSE 到Spring各种框架都有整理，送给每一位Java小伙伴，想要获取的可以关注我的头条号并在后台私信我：Java，即可免费获取。
