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

fix来源:https://github.com/apache/incubator-dubbo/commit/ed66afd9a38d80f839f0381fbd1dc1d3c068bc1c#diff-c5cb2df641f0a7d0553343c757425d2b

真相

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

既然提到dubbo预热问题,另外一个优化点也可以参考一下,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.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特性还是延迟暴露服务,对生产环境都有很大的帮助,所以,赶紧做如下的优化吧:

  1. 如果是dubbox分支,或者旧的dubbo分支,请修复warmup特性时间戳的问题;
  2. 配置<dubbo:provider delay="5000"/>延迟暴露所有dubbo服务;

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 141,621评论 1 298
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 60,780评论 1 254
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 93,376评论 0 211
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 40,770评论 0 174
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 48,482评论 1 252
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 38,637评论 1 172
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 30,297评论 2 267
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,094评论 0 165
  • 想象着我的养父在大火中拼命挣扎,窒息,最后皮肤化为焦炭。我心中就已经是抑制不住地欢快,这就叫做以其人之道,还治其人...
    爱写小说的胖达阅读 28,855评论 6 228
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 32,420评论 0 213
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,200评论 2 213
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 30,521评论 1 224
  • 白月光回国,霸总把我这个替身辞退。还一脸阴沉的警告我。[不要出现在思思面前, 不然我有一百种方法让你生不如死。]我...
    爱写小说的胖达阅读 24,181评论 0 31
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,065评论 2 213
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 31,424评论 3 202
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,590评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 25,947评论 0 163
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 33,406评论 2 230
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 33,509评论 2 229

推荐阅读更多精彩内容