序言
今年的雙十一對阿里巴巴中間件消息團隊來說，註定是個不平凡的日子。在這一天，穩定性小組重點攻克的低延遲存儲解決方案成功地經受住了大考。整個大促期間，99.996%的延遲落在了10ms以內，極個別由於GC引發的停頓在50ms以內，對於讀寫比例幾乎均衡的分佈式消息引擎來說，這一結果無不令人興奮。甚至可以毫不誇張地講，即便拿到明年的Java one大會上，也必定是場非常吸睛的技術乾貨分享。接下來，團隊同學會把相關的經驗提煉總結出來，期待能在接下來全球Qcon大會上為小夥伴們帶去儘可能多的乾貨分享。
除此之外，更讓大家倍感欣慰是我們終於為贏得世界的尊重，擁抱世界走出了第一步，這一步走的著實不易，每走一步，回頭看看，都是記憶滿滿。正所謂，橋曾堅固，但已坍塌；路雖滄桑，但已破舊；街曾繁華，但已被拆；巷雖深遠，但已變舊。唯一不變的，是那生命裡留下的深深腳印。
初衷
捐贈最好的項目給Apache~ 這個想法，最早是14年中旬，在開發maven dependency mediator這個開源組件的時候冒出來的。當時，為了解決中間件組件依賴問題，我研究分析了業界最主流的開源方案，有Maven官方的，也有民間的，甚至研究了Gradle的解決方案，很可惜，不知道是不是我們寫代碼相比老外比較隨意，還是說我們的規模達到了讓組件依賴熵混亂不堪的境界，必須自己著手擼這麼個輪子（平心而論，這些年為各類國際開源社區沒少貢獻ISSUE或者PR。但即便如此，心中那種擼輪子的”惡念”時不時會浮現）。於是乎，著手寫了這麼一個組件。接下來問題來了，怎麼去維護，怎麼做能夠持久的去演進這款組件？相信喜歡擼輪子的童鞋都有這樣的經歷，產品從0到1容易，再從1再到0可就難了去了。放眼望去，這方面做的最棒的無非就是FastJson了，這麼些年的堅持，為大家帶來了極盡優化的性能（不僅性能，功能方面也不落後於同類產品）體驗。能夠持久專注，不斷演進才應是我輩應該追求的開源情懷啊。
回過頭來，我們再來看這個maven組件項目，為了能夠吸引更多的外籍朋友反饋，專門寫了一個長篇E文，系統化介紹怎麼做二進制兼容依賴，從最初的設計編碼，到運維部署都有一套相對體系化的方案探索出來，為此還曾想過發表專利來保護下這塊，不過後來因為事情多也就擱淺了。到此，我們發現，上面提出的讓人糾結的問題還是沒有解決，這個項目怎麼發展？因為之前的調研過程中，從maven的Codehaus，也就是maven最大“非法”（非官方）插件集散地得到了一些靈感 - 捐贈給它。Okay，接下來，結果大家也看到了。這個小項目發展到1.0.2版本的時候，被我擱淺了（說實話，這個項目的代碼質量在當時那種情況，算是不錯了。但我要吐槽一下Maven自身的單測框架和集成測試框架，問題還是挺多的。不管如何，如果有童鞋希望展這個項目，可以聯繫我，截止目前，放眼望去，業界還是缺少這麼一個好用的兼容檢測組件，這裡面還是有一些非常好玩的想法我沒有精力落地掉：-））。為什麼擱淺？因為當時自己的工作重心主要在分佈式消息引擎、消息推送這塊，並且也是公司這塊幾個中間件的貢獻者以及負責人。能不能聚焦一下，那些工具擼起來固然爽快，但後續的發展著實讓人操心。俗話說，眾人拾材火焰高。能不能找幾個技術好手把分佈式領域的精髓都體現在某個產品中，和當時消息團隊的負責人誓嘉（非常低調的厲害傢伙:)）閒暇時間聊起來，聊到這塊，聊到開源，聊到分佈式技術，聊到業界分佈式消息引擎，聊到它們未來的發展。隨後，再隨後，方向漸漸明晰了，於是便有了捐贈Apache這個現在看來最最基礎的一步。
我個人是比較喜歡聆聽批評，尤其是足球和開源這塊，等等，姑且先拋開中國男足，今天只談開源。有很多人講，國內的開源氛圍不好，很多都是隻談績效，沽名釣譽，尤其是幾個大廠甚至把風氣都帶歪了。即便開源了，設計、源碼、文檔、社區也是很難持續跟進。不可否認，這樣的事實也許存在。但今天，我們把RocketMQ放出來，就是想給大家一個證明，一起來看看由內而外，然後再由外而內這種模式到底能不能行得通。我們彼此心裡非常清楚，開源與商業化相輔相成，水可以載舟，也可以覆舟。產品、技術、商業如何能夠打好配合，激發出1+1+1大於3的價值來，這也是我們今年思考最多的問題。
MQ簡介
RocketMQ是阿里巴巴在2012年開源的第三代分佈式消息中間件，不僅在傳統高頻交易鏈路有著低延遲的出色表現，在實時計算等大數據領域也有著不錯的吞吐。開源至今，社區參與度非常高，國內擁有超大規模的活躍交流群，ISSUE上更是收錄了來自全球數百個高質量的話題交流以及問題沉澱。除此之外，在產權保護、知識輸出這塊，有著接近20篇專利的沉澱。去年，RocketMQ獲得了中日韓開源論壇CJK OSS大獎，今年早些時候又進入歐美主流開源門戶網站Awesome-java視野，意味著RocketMQ正式走出國門。也正是基於如此卓越的表現，為後續Bruce，Brian等歐美大拿引路Apache奠定了良好的群眾基礎。
在它之上，我們構建了自己的內部版本MetaQ，還有云產品MQ。經歷了幾年線上近乎苛刻的場景驗證，在雙十一當天消息容量達到萬億級的體量。這中間，有不少小夥伴默默地付出著（這裡面還有一個小插曲，社區的朋友為感謝RMQ項目，捐贈了近500 RMB，不過我們把這些錢一次性捐贈給公司的公益事業啦:) ）。而今天，我們將這些毫無保留的開源出來，就是為了讓更多人受益。阿里巴巴是個很講究感恩的公司，我們取之於開源不在少數，是時候體系化地反哺社區了。什麼樣的社區能讓Alibaba的產品走上更健康的道路呢，思考來思考去，還真只有Apache。相信在Apache這個平臺上，沒有人會去偷懶，沒有會想著走捷徑。今天也只是一個孵化項目，想不想畢業，能不能畢業，完全取決於我們對於開源精神的理解和詮釋。我想，應該沒有人會拿名族大義開玩笑吧（呸呸呸，扯到這上面來了。其實就是要給公司以及國內的同行們帶個好頭，做個表率，爭口氣:) ）。畢竟，我們代表中國，代表中國最先進，最執著的那批技術探路者。
捐贈歷程
接下來，進入重點。一起看看Apache的整個捐贈歷程吧。整個歷程始於2014年，終於2016年（這裡用終於不是很妥當，我們只是剛開始走上正路而已）。想法可能天天有，但怎麼落地，尤其是這個想法的落地，非常具有挑戰。在研究Apache官網關於捐贈流程的文章後，我們甄選了幾位MQ方面非常有經驗的老美，和他們聊聊吧。在很誠懇的給他們講述了我們希望捐贈給Apache的訴求，Brian（ActiveMQ PMC member，Groupon CTO）率先答應了會幫助我們。接下來，開始準備Proposal唄。很快，初稿就出來了。經過和Brian反反覆覆幾次溝通，不斷修改，算是有點模樣了。這時，問題來了，我們失去了和Brian的聯繫。雖然說老外非常喜歡度假式放鬆，但這次回來可真聯繫不上了。就像斷線的風箏那樣，我們無所是從。接下來，大家也看到了，這件事情基本上被擱淺了。在John（JCP專家組成員）的郵件裡，他也用folded out這個詞來問我，到底是什麼原因讓你們中途擱淺了呢。Okay，擱淺的原因講清楚了。接下來，時間來到了2015年。通過朋友的引薦，結識了Kylin的總架構師蔣旭（技術上任何牛逼的詞都可以往上貼，非常低調的榜樣）以及在Apache上的主推手Luke（非常Nice的一位GG，Kyligence聯合創始人）。又在Apache 亞洲路演北京站和他以及後來也是我們的Mentor之一的姜寧（Apache多個項目的PMC member,committer）進行了交流，請教了一些禁忌事項。至此，我們捐贈進程又活躍了起來。再後來呢，Luke和姜寧也成為阿里巴巴RocketMQ IPMC國內的兩位mentor。不僅如此，他們也欣然接受了阿里巴巴weex團隊的邀請（具體牽線人應該是我們可敬的JStorm負責人紀君祥:)），繼續在Apache進程中為我們“保駕護航”。說到這裡，最最重量的小夥伴要等登場了。除了mentor，我們還需要徵集最最重要的champion候選人。Brian這條線斷了，需要我們再挖掘一位貴人相助。這個時候“大拿“Bruce（ActiveMQ in Action的作者，這裡我不想過多描述他在開源領域的傑出貢獻，感興趣的童鞋可自行google）出現了。給我印象最深的是Bruce一上來就問了我5個“究極”的問題：
- 是否瞭解Apache 孵化進程，是否知曉ASF 項目的一些基本要求
- 是否聯繫過其他Champion
- 是否聯繫過其他Mentor
- 是否聯繫過Apache ASF Membe
- 進入Apache後，RocketMQ會怎麼發展
當然，回答這些問題應該不成問題。但從這幾問題看得出來，Bruce非常有經驗，也非常有心的在嘗試幫助我們。此後的歲月裡，我們保持著高頻度的郵件來往，前前後後大概接近100封吧。考慮到時差，這一來一去，也就2個月過去了。期間又恰逢Bruce金婚19年（由衷的祝福），中間出去旅行了一陣子。很快，一個重要的日子來了。一天，Burce問我”準備好了嗎，我們即將開啟Apache之旅“。我的回答也毫無猶豫，”Let’s Go~“一切都在平穩的向前推進著。雙十一當天，迎來了投票。預料之中的是，社區非常活躍的John對我們提出了幾個犀利的問題，對我們的社區數據提出了疑問。本著實事求是的原則，我公開郵件加私信的方式將事情的原委和他一一道來，疑慮擔心算是打消了。這裡面還有一個小插曲，在大家”交涉“期間，來自Apache董事會的President和Vice chirman也來幫我們說話，用文化差異，包容性等幫我們解困。真的要非常非常感謝他們。
現在回想起來，John為什麼會問那幾個犀利的問題，主要原因來自他也是ActiveMQ PMC成員，要知道我們網羅了3位ActiveMQ的VP來幫助我們。而且按照Bruce的建議，Proposal里加入了和Apache ActiveMQ和Kafka的客觀對比。我的媽媽呀，這一舉，為我們帶來了這麼多不必要的麻煩。在諮詢了Bruce之後，我們的Proposal並沒有刪除這個對比，但是稍微聚焦了一下我們的優勢。就這樣，看似平穩的投票朝著非常好的方向發展了。
這還沒完。接下來，更有意思的事情出現了，Apache Trafodion項目的Release Manager開了一個專題，題目為 - China Contribution. (was: RocketMQ Incubation Proposal)。我的媽媽呀，這跟RocketMQ有毛線關係，實在看不下去了，適時地發表了我的見解。在這個討論裡，大家主要聚焦的問題是Trafodion項目裡，來自中國的contributors喜歡用QQ，而不是郵件進行溝通，這讓他們很是頭疼。說到這，大家想必也看到了，國內其實還是有很多非常樂於開源的同學活躍在Apache社區的。另外，由於標題太過於刺眼，好玩的事情出現了。中國人嘛，看到有人扯到跟中國開源相關的事情，大家不樂意了。Luke，姜寧，陳亮（華為Apache Carbondata孵化項目負責人），包括Databricks那個華人GG，都發表了防禦性“聲明”。由於各種原因，中國人無法郵件，無法google，所以才。。。最後的結果大家想必也猜到了，不可能有結果，沒有結果可能就是最好的結果。所以這裡給大家的建議就是，如果希望讓國外的小夥伴參與進來，就試著把自己的英語拾起來吧，註釋，討論以及一些必要的文檔嘗試用英語，本地化社區可以有非英語支持頻道！
經過了這麼多折騰，投票結果總算出來了，還不算壞 - 10票帶binding的+1，無反對票，正式進入孵化期。孵化成功後有望成為國內首個互聯網中間件在Apache上的頂級項目，成為全球繼ActiveMQ，Kafka之後，分佈式消息引擎家族中的重要成員。此次捐贈，也意味著以MQ為代表的互聯網中間件在新興物聯網，大數據領域會發揮著越來越大的作用。另外，我必須提一下，雖然目前大數據技術”橫行當道“，尤其以Spark和Hadoop為陣營的各大開源平臺層出不窮（看看近些年那些最活躍的那些Apache產品）。小夥伴要當心，大數據背後的那些分佈式技術都是相通的，看問題學技術要掌握本源，只有掌握了最根本的，在技術廣袤的海洋裡，你才不會迷失。另外，也正是通過這次Apache之旅，讓我深刻意識到在社區裡面，有著大量的MQ 愛好者，如果能激起這些久經沙場的國外大拿的共鳴，那麼這勢必將是一個充滿競爭力的社區。
從這些經歷中，大家可以清晰地看到，捐贈從想法醞釀到成型，再到落地，前前後後接近一年半。中間也經歷了各種曲折。回過頭來看，這些都是寶貴的財富，團隊也在不斷反思和總結。整個投票過程，團隊核心Committer全程參與，很好的近距離體驗了Apache Way，為後續其它產品的輸出奠定了堅實基礎。
MQ未來
再接下來，也是我最想分享的。Apache RocketMQ接下來如何發展。大家知道，我們在雲上圍繞著RMQ做了雲端版本的消息引擎MQ，像發送者事務，消息軌跡這些功能都是集成在MQ中的。一個初具規模的軟件產品，一般都會有社區版和商業版兩種授權。RocketMQ和MQ兩者之間，也是這樣的關係。所以也請大家理解我們在開源版本和商業版本之間的不同發展路線。這兩者如何能夠相互配合，互相補充，共同繁榮，在全球都是一個不易解的問題。不過，我們可以承諾，只要是團隊開源出來的，一定是在阿里久經考驗的臻品，而且質量會越來越好，越來越趨向標準化。除此之外，為了更透徹的響應Apache社區關於多元社區文化的理念，在新的contributor和committer這塊，我們會加大力度扶持、甄選具有開源情懷的童鞋，無論國籍，靠譜即可:) 能在大數據技術林良滿目的今日，國內自主研發的互聯網中間件從中殺出一條血路，向著擁抱全球規範的道路前行。這條路不容易走，但方向對了，就不怕遠~
心動不如行動
到這裡，希望那些有志於打造世界頂級互聯網中間件的同學加入我們，幫助我們，監督我們，讓我們一起打造全球最棒的消息引擎（不僅如此，我們還有更好玩的產品在後面），攜手擁抱分佈式領域最值得期待的規範體系。
路才剛剛開始，如果還有夢想，那就帶著靈魂出發吧~
方向，節奏，專注，激情~
閱讀更多 RexSd 的文章
