聊聊流式計算吧 , 那一段經歷于我而言很精彩，很有趣，想把這段經歷分享給大家。

1 背景介紹

2014年，我在藝龍旅行網促銷團隊負責紅包系統。

彼時，促銷大戰如火如荼，優惠券計算服務也成為藝龍促銷業務中最重要的服務之一。

而優惠券計算服務正是采用當時大名鼎鼎的流式計算框架 Storm。

流式計算是利用分布式的思想和方法，對海量“流”式數據進行實時處理的系統，它源自對海量數據“時效”價值上的挖掘訴求。

優惠券計算服務的邏輯是：每個城市每個酒店的使用優惠券的規則并不相同，當運營人員修改規則之后，觸發優惠券計算服務，計算完成之后，用戶下單時在使用優惠券時會呈現最新的規則。

優惠券計算服務是我們團隊的明星項目，很多研發的同學都對 Storm 特別感興趣 , 因為 Storm 的核心開發語言是 clojure ， 比較小眾。

于是，在團隊內部，發現一個很有趣的現象：很多同學的辦公桌上放著《clojure in Action 》這本書。

彼時，藝龍開始發力移動互聯網，業務量的激增，優惠券計算服務開始遇到了瓶頸。

比如運營人員修改全量規則時，整個計算流程要耗時一上午，也就談不上實時計算了。

CTO 幾次找團隊負責人，并嚴厲批責成他盡快優化。經過一個半月幾次優化，系統的瓶頸依然明顯，時不時運營同事會走到我們的工位附近，催促我們：“系統生效了么？ ”

我并不負責計算服務，每當同事被質疑時，我都感到很疑惑：“優惠券計算服務真的那么復雜嗎？ ” ， 同時也躍躍欲試：“ Storm 真有那么難搞嗎？”

我心中暗暗下定了決心，一定要弄清楚優惠券計算服務的邏輯 。

2 國圖學習

北京有很多景點都讓我流連忘返，比如史鐵生小說里的地壇，滿山楓葉的香山，如詩如畫的頤和園，美侖美奐的天壇 。

在我心里，有一處很神圣的地方，它是知識和希望的象征，那就是國家圖書館 。

中國國家圖書館位于北京市中關村南大街33號，與海淀區白石橋高粱河、紫竹院公園相鄰。它是國家總書庫，國家書目中心，國家古籍保護中心，同時也是世界最大、最先進的國家圖書館之一 。

每到周末，當我想安靜下來，專注思考時，我就會背著筆記本電腦來到國家圖書館。

選擇自己喜歡的書，然后將筆記本電腦打開，一邊看書，一邊在電腦上寫點筆記。

偶爾抬起頭，望著那些正在閱讀的讀者，心里面感覺很陽關，覺得生命充滿了希望。

我并不負責流式計算服務，但想要揭開 Storm 神秘面紗的探索欲，同時探尋優惠券計算服務為什么會這么慢的渴望，讓我好幾天晚上沒睡好。

于是周六上午9點半， 我來到國家圖書館 ，想讓自己安靜下來，思考如何解決這個問題。解決問題的快感，是我一直追求的。

當我把筆記本電腦放平在桌上，我很興奮，同時靈臺一片澄清：優惠券計算服務的核心是 Storm ，那么我需要先了解 Storm 的整體概念。

打開官網，瀏覽官網的文檔，第一次看到 Storm 的邏輯流程圖時， 做為程序員，我第一次竟然感受到抽象之美：從源頭流下來的水通過水龍頭（ Spout ），再經過層層轉接頭( Bolt )過濾，不就是我們想要的純凈水嗎？

其實我們原來都是 CRUD boy ，機械的使用那些框架，只會做增刪改查，并不會思考框架背后的設計思路。 但框架到底是什么？從來沒有思考過。 我一直覺得我很笨拙，學什么都很慢，但那一刻我突然恍然大悟：框架本身是將解決問題的思路抽象化，從而便于研發人員使用，把復雜的問題抽象成有美感，是需要功底的。

了解完 Storm 整體概念 ， 下一步也就是大家熟知的寫 Hello World 階段了 。

我參考教程寫了一個簡單的 Storm 應用（簡稱：拓撲），在部署后，程序正常跑了起來。

我腦海里一直有一個疑問：“是不是優惠券計算服務的 storm 集群的配置沒有調優，才導致計算的性能太差 ? ” 所以我必須去理解 storm 的并發度是如何計算的。

整個下午，我一直在查閱相關的資料，并結合下圖思考：Nimbus， Supervisor ，Worker ，Task 這些名詞到底是什么概念，以及他們之間是如何交互的。

進而思考：拓撲到底會啟動幾個進程，每個進程內部線程模型是怎樣的，頗有些庖丁解牛的味道。

這個習慣一直保持到現在，當我看到一個系統，我會下意思的去思考：“這個系統的線程模型如何，每次操作有哪些線程參于，他們之間如何交互”。我知道有更厲害的大牛，運行一行代碼就知道 CPU 會運行的哪些指令，我做不到，但我覺得那就更加深刻了。

不管怎樣，這一天，我的思緒經過多次的變化，興奮，猶疑，放棄，陽光，激動，畏難心理一直存在，很多次想放棄，但好奇心一直鼓勵著我。

等天色已黑，我走出國圖的大門，腦子里全部都是 Storm 進程，線程模型，內心里面，有了莫名的自信。感覺自己就像仙劍奇俠傳里的酒劍仙，伴隨著激昂的 BGM ，拔劍四顧，斬妖除魔。

御劍乘風來，除魔天地間，有酒樂逍遙，無酒我亦癲。

一飲盡江河，再飲吞日月，千杯醉不倒，唯我酒劍仙。

3 找到瓶頸

當我理解了 Storm 的整體概念，接下來我需要去找到優惠券計算服務的性能瓶頸。這個時候，梳理計算服務整體流程非常關鍵。

計算服務整體流程分為三個步驟 ：

1. 抽取數據：酒店信息拉取服務拉取酒店信息，并存儲到水源頭( Redis A/B 集群 ) ;
2. 計算過程：Storm 拓撲從水源頭獲取酒店數據，通過運營配置的規則對數據進行清洗 ，將計算好的數據存儲到水存放池 ( Redis C 集群) ；
3. 入庫階段：入庫服務從水存放池獲取數據，將計算結果存儲到數據庫 。

當我們把整個計算的過程拆分成 抽取-->計算 --> 存儲 三個階段的時候，計算服務的架構就變得異常清晰，那到底在哪個階段最耗時 ，也成為我追查的目標。

優惠券計算服務當時沒有詳細的性能監控體系，所以我只能先從日志著手。 在運營同事觸發全量計算后，分別觀察三個階段對應服務的日志：

• 抽取數據：酒店信息拉取服務
• 計算過程: Storm 拓撲
• 入庫階段: 入庫服務

令人驚訝的現象：一次全量計算需要耗時4個多小時，但抽取數據的任務竟然跑了2個多小時，和我預期完全不一樣。

假如我把酒店信息拉取服務比作抽水泵，那么整個系統最大的問題竟然是抽水泵抽水馬力不足。

4 推進重構

為什么抽水泵抽水馬力不足 ？

通過閱讀源碼，我發現因為線程模型不夠好，應用在部署多個節點后，每個節點只能有兩個線程執行拉取酒店信息。

怎么處理呢？ 在原有代碼上優化可行嗎？ 好像也不太容易，因為老代碼最初是一個 C# 研發同事寫的，他當時也不熟悉 JAVA ，從設計層面來講，有很多冗余且不合理的代碼，而且經過3年左右的維護，代碼老化嚴重，于是我只能想到重構。

當我把想法和團隊負責人溝通后，他有點半信半疑，他認為我的判斷沒有問題，但不確定我是否可以將系統重構好。 我那時候信心爆棚，主動請纓，打包票不會出問題的。可能是由于 CTO 逼的太緊了，他同意了。

在重構之間，梳理好系統的整體邏輯。

重構的重點原則有兩條：

1. 拉取服務可水平擴展，若性能不足時，增加服務節點即可提升性能；

2. 配置文件可配置 worker 線程數量。

那思想層面，我已經做好準備了，那硬實力層面我有沒有做好準備嗎？ 非常自信的講，準備好了，因為我遇到了 RocketMQ 。

我在《我與消息隊列的8年情緣》這篇文章寫到：

2014年，我搜羅了很多的淘寶的消息隊列的資料，我知道MetaQ的版本已經升級MetaQ 3.0，只是開源版本還沒有放出來。

大約秋天的樣子，我加入了RocketMQ技術群。誓嘉(RocketMQ創始人)在群里說：“最近要開源了，放出來后，大家趕緊fork呀”。他的這句話發在群里之后，群里都炸開了鍋。我更是歡喜雀躍，期待著能早日見到阿里自己內部的消息中間件。

終于，RocketMQ終于開源了。我迫不及待想一窺他的風采。

因為我想學網絡編程，而RocketMQ的通訊模塊remoting底層也是Netty寫的。所以，RocketMQ的通訊層是我學習切入的點。

我模仿RocketMQ的remoting寫了一個玩具的rpc，這更大大提高我的自信心。正好，藝龍舉辦技術創新活動。我想想，要不嘗試一下用Netty改寫下Cobar的通訊模塊。于是參考Cobar的源碼花了兩周寫了個netty版的proxy，其實非常粗糙，很多功能不完善。后來，這次活動頒給我一個鼓勵獎，現在想想都很好玩。

在重構酒店信息拉取服務時，我將 RocketMQ 如何創建線程的知識點正好也用了上去，并學習如何將模塊拆分得更加合理。同時在重構過程中，不斷 Review 新老代碼的差別，確保核心邏輯正確。

非常幸運，大概一周時間，我就重構完了。

重構完成并不意味著結束，怎么驗證呢 ？ 我當時采取了兩種方式：

• 代碼評審

  我拉著優惠券計算服務的同事，一起 review 代碼 。整個過程，大家也并沒有提出異議，并對我創建線程的技巧感到很好奇。我心中竊喜：”那是學習 RocketMQ 的“。

• 測試環境數據驗證

  我們將新舊兩版服務同時觸發，比對兩個版本的數據的異同，將比對結果輸出到日志文件，然后從中找到差異的地方，修復重構版的 BUG 。 然后在測試環境部署重構版，觀察一段時間，確保無異常。

從編寫第一行代碼，三周時間，重構版終于上線了。 我將原來的老服務替換后，部署了3個節點， 每個節點8個 worker 并行拉取酒店信息 。

令人開心和激動的是，重構是非常成功的。 因為業務給我們的時間需求也是1個小時左右。一次全量計算從原來4個小時急速縮減到1小時15分鐘，整個酒店拉取服務耗時40分鐘左右。

我心里長舒一口氣，內心吟誦李白的詩："十步殺一人，千里不留行。事了拂衣去，深藏身與名。"

5 向前一步

前 Facebook COO 謝麗爾·桑德伯格 寫了一本書《向前一步》，我特別喜歡這本書的書名 。

在優化優惠券計算服務的前期，團隊經過一個多月的時間，也沒有什么成效。 我自己也猶豫：”我能不能解決這個問題？“ ，但最終我還是向前一步，并幫助團隊大大提升了服務的性能，負責人也有了信心，他也敢投入資源優化Storm 拓撲和入庫流程。

在閱讀優惠券計算服務的代碼中，我發現兩個問題：

1. 流式計算邏輯中有大量網絡 IO 請求，主要是查詢特定的酒店數據，用于后續計算；
2. 每次計算時需要查詢基礎配置數據，它們都是從數據庫中獲取。

對于Storm 拓撲優化，我提了兩點建議：

1. 流式計算拓撲和酒店拉取服務各司其職，將流式計算中的網絡 IO 請求挪到酒店拉取服務，將數據前置準備好；
2. 基礎配置緩存化，引入讀寫鎖（也是 RocketMQ 名字服務的技巧）。

對于入庫流程，一位研發同學將原來的單條數據入庫修改成批量入庫。

經過大家一起努力 ，優惠券計算服務的整體性能大大提升了，全量計算耗時已經變成40分鐘了，再也不會有運營同事在我們的工位附近吐槽系統慢了。

6 寫到最后

2014年，我向前一步推動了公司流式計算服務的優化，并取得了一點點進步。

時光荏苒，我已中年，生命中遇到越來越多的挫折，有的時候也會讓人低落，但每當想起這個故事，我會深深感動于當時的一往無前。

當再次面臨選擇時，我希望自己也能夠向前一步，想著如何幫助讀者成長，或是實現一個產品幫助更多的人。

如果我的文章對你有所幫助，還請幫忙點贊、在看、轉發一下，你的支持會激勵我輸出更高質量的文章，非常感謝！