被 CTO 点名的明星服务周六,我背着电脑去了国家图书馆病根不在 Storm,在「抽水泵」主动请缨:三周,4 小时干到 1 小时 15 分写在最后
先说一个技术人都熟悉的名场面:运营同事走到你工位边上,第五次问出那句话——「系统生效了么?」
2014 年,我在一家在线旅游公司的促销团队,负责红包系统。隔壁的优惠券计算服务,就是全公司被问这句话最多的系统。
这服务干的活说起来不复杂:每个城市、每家酒店的优惠券规则都不一样,运营改完规则,它得赶紧算一遍,用户下单时才能用上最新的规则。
但它当时跑在Storm上——那两年最火的流式计算框架,核心语言还是小众的 Clojure。团队不少同学桌上都摆着一本《Clojure in Action》,书摆着,心里没底,是当时真实的众生相。
业务量一涨,它第一个扛不住。运营改一次全量规则,整个计算要跑一个上午,所谓「实时计算」成了笑话。
CTO 几次找团队负责人,措辞很严厉。优化搞了一个半月,瓶颈还在。运营同事还是会走到工位附近,问那句「系统生效了么」。
说个关键背景:我并不负责这个服务。但每次看到同事被问住,我心里都在犯嘀咕——这服务真有那么复杂吗?Storm 真有那么难搞吗?
嘀咕归嘀咕,我那几天晚上都没睡好。索性决定:自己把它弄明白。
我给自己挑了个地方:国家图书馆。周六上午九点半,我背着笔记本到了那儿,打开电脑,开始啃 Storm 的官方文档。
第一次看懂 Storm 的逻辑流程图时,我这个写了多年增删改查的程序员,居然感受到了一种「抽象之美」:数据像水一样从源头流下来,经过水龙头(Spout),再经过一层层转接头(Bolt)过滤,最后变成干净的水。
也就是那一刻我突然想通了一件事:框架本身,就是把解决问题的思路抽象化。我们平时只是机械地调用它,从没想过它背后是怎么想问题的。
那个下午,我一直在查 Storm 的并发模型:Nimbus、Supervisor、Worker、Task 到底是什么关系,一个拓扑会起几个进程,进程里的线程模型长什么样。
说真的,一天里情绪翻来覆去:兴奋、犹疑、想放弃,好几次觉得搞不动了,但好奇心一直拽着我。等天黑走出国图大门,我满脑子都是 Storm 的进程和线程,心里莫名有了底气。
回来后干的第一件事,是把整个计算流程拆开。一拆就清晰了,三个阶段:
- •抽取:酒店信息拉取服务把酒店数据放进 Redis A/B 集群,作为 Storm 的数据源
- •计算:Storm 拓扑按运营配置的规则清洗数据,结果写进 Redis C 集群
- •入库:入库服务从 Redis C 取数,写进数据库
当时没有像样的性能监控,只能靠日志。运营触发一次全量计算后,我盯着三个阶段的日志逐段看。
结果很意外:一次全量计算要4 个多小时,光「抽数据」就跑了 2 个多小时。
打个比方:如果把拉取服务当成抽水泵,那整个系统最大的问题,是抽水泵马力不足。
顺着源码往下看,病根找到了:线程模型太差——应用部署多少个节点,每个节点也只开 2 个线程拉数据。加机器没用,这才是它扩不动的原因。
病根找到了,能不能动手术?我看了一圈老代码,结论是:改造余地不大。最早这是一位 C# 同事写的,当年他也不熟 Java,设计上冗余不少,又维护了三年,老化严重。我的判断是:重构。
我找团队负责人聊,他半信半疑——认可我的判断,但不确定我能不能重构好。那阵子我信心爆棚,主动打包票。大概也是被 CTO 逼得太紧,他同意了。
重构只定了两条原则:
- • 拉取服务可以水平扩展,性能不够就加节点
- • 线程数量做成可配置,不用改代码就能调
硬实力也刚好派上用场:那段时间我一直在啃RocketMQ的源码——它还没开源时我就混在技术群里,群里都在等「放出来赶紧 fork」的那一天;我还照着它的通讯模块写过玩具 RPC。它创建线程、拆模块的那套思路,正好用在了这次重构里。
![]()
2014 年 RocketMQ 开源前夜的仓库页面
怎么验证重构没改坏?两个笨办法:
- • 拉着原团队一起评审代码,一条条过
- • 新旧两版服务同时触发,把两边数据做比对,差异逐条查、修完再跑
三周后,重构版上线:3 个节点,每个节点 8 个 worker 并行拉数据。结果出来那一刻,我长舒一口气——一次全量计算从 4 个多小时,直接降到1 小时 15 分钟,其中拉取服务只占 40 分钟左右。而业务方提的需求,是「1 个小时左右」。
![]()
优惠券计算服务整体流程
![]()
后面的事就顺了。我趁势提了两条 Storm 拓扑的优化建议:把流式计算里的网络 IO 请求前置到拉取服务,基础配置做成缓存。同事把入库从单条改成了批量。大家一起弄完,全量计算最后压到了 40 分钟。
从那以后,再也没有运营同事走到我们工位附近,问那句「系统生效了么」。
这事过去十多年了。我现在也到了中年,生活里遇到的挫折越来越多,有时候也会低落。但每次想起那个周六——在国图坐了一整天、走出大门时满脑子线程模型的样子——还是会感动于当时那股一往无前。
说实话,那活儿本来不归我管。让我上手的,说穿了就是好奇心,加一句自我怀疑:「我能不能解决这个问题?」还好,我选择了往前迈一步,而不是绕开它。桑德伯格那本《向前一步》,我一直特别喜欢这个书名。
![]()
《向前一步》——书名比书本身更早打动我
你有没有过那种「不归你管、但忍不住想弄明白」的时刻?后来呢?评论区聊聊。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.