Apache RocketMQ 頂級項目之路
序言
2016年11月，阿里將RocketMQ捐獻給Apache軟件基金會，正式成為孵化項目。至此，RocketMQ 開啟了邁向全球頂級開源軟件的新征程。通過社區(qū)半年多的努力。9 月 25 日，Apache 軟件基金會官方宣布，阿里巴巴捐贈給 Apache 社區(qū)的開源項目 RocketMQ 從 Apache 社區(qū)正式畢業(yè)，成為 Apache 頂級項目(TLP)。
在通向Apache頂級項目的這些時間里，團隊走了很多路，也經歷了很多事。
- 第一次按照Apache Way走通Apache軟件發(fā)布流程，完成了在整個IPMC都極為罕見的Rc3發(fā)布壯舉，體現(xiàn)了中國團隊的嚴謹、高效，贏得了社區(qū)的贊譽。
- 第一次吸納外籍Committer - 日本博士Roman。2個月時間里，他提交近20個Pull Request，推動RocketMQ跟Apache其它頂級社區(qū)項目合作，對社區(qū)起步做出了卓越貢獻。
- 第一次面向社區(qū)舉辦編程馬拉松。PMC成員全程跟進，幫助參賽選手評審設計、Review代碼。
- 第一次吸納PMC成員。在RocketMQ社區(qū)，PMC是對Committer持續(xù)貢獻的進一步Merit。
- 第一次向Apache社區(qū)昭告OpenMessaging標準的愿景。緊接著, ASF Director Jim毛遂自薦，加入到RocketMQ超強豪華的全球Mentor陣營中。
- 第一次面向國內社區(qū)舉辦了大型MeetUp。全球圖文現(xiàn)場直播，5場純技術Messaging & Streaming干貨分享，傳達了團隊誓將做好社區(qū)，搞好生態(tài)的決心。
- 第一次......
人生就是一場跋涉，走久了，才知心酸，才知艱難，才有堅韌，才有渴望。前方的路，盡管遙遠，盡管顛簸。但腳步依然，追求依然，方向依然。
2017年8月3號，經過了半年多的發(fā)展，團隊正式發(fā)起了沖擊TLP的討論。接下來的一個月時間里，討論和投票，幾乎成了每天的必修課。終于，搶在Java 9發(fā)布之前，RocketMQ 正式通過董事會決議，結束了在Apache上的孵化，正式成為Apache 340多個頂級項目中的一員。這一刻，完全出自中國團隊，來自阿里巴巴的分布式消息引擎成為全球互聯(lián)網中間件、大數(shù)據(jù)領域璀璨的新星。下一站，等待它的將是在國際舞臺上與世界頂級老牌消息中間件的激烈角逐。相信在Apache先進的社區(qū)理念指引下，RocketMQ社區(qū)生態(tài)會繼續(xù)蓬勃發(fā)展，完成我們所賦予它的光榮使命。
接下來，我們從產品、社區(qū)、生態(tài)這三個維度，分別回顧一下RocketMQ這半年多的Apache孵化歷程。
產品篇章
與Apache大多數(shù)頂級項目不同，RocketMQ在進入Apache之前，Open Source之路已經走過了3個春秋。歷經多次雙十一洗禮，在國內積累了一定的口碑，社區(qū)也有不錯的Active Contributors，但這些還遠遠不夠。在正式開啟捐贈之前，團隊對RocketMQ甚至包括社區(qū)做了大量重塑工作。如國際化方面，在Github上利用sidebar特性重新設計編排了文檔。如今，User Guide, Quick Start, Architecture & Design, How to contribute, Community, FAQ 這些幾乎成為了團隊新產品標配的文檔結構。
代碼層面更是進行了比較“激進”地優(yōu)化。如去除GBK字符，全面擁抱UTF-8。重寫API JavaDoc。清理代碼，優(yōu)化代碼結構。利用JDepend優(yōu)化組件之間的抽象依賴關系。利用Findbugs掃描代碼漏洞，指導規(guī)范編碼。交付方面，規(guī)范Release流程，New Features、Improvement and Bug 分類Release note。社區(qū)層面則開啟了全英式互動，發(fā)布問問題的技巧。
經過這些精心的準備，RocketMQ完成了從3.0到4.0的悄然升級。而4.0是個過渡版本(和3.0相比，架構層面沒有較大的改變)，也是在Apache開啟孵化的版本。通過孵化，團隊重新認識了軟件研發(fā)流程的重要性，尤其是像精細設計，代碼Review，編碼規(guī)約，分支模型，發(fā)布規(guī)約等容易被忽略的過程。無以規(guī)矩不成方圓，尤其是當你置身于并領導一個全球協(xié)作的開源項目時，這些都顯得是尤為重要。
編碼規(guī)約
RocketMQ的編碼規(guī)約是比較寬松的，至少在4.0這個版本上。與其它Apache頂級項目不同，我們并沒有從編碼細節(jié)上去做過多約束，如靜態(tài)變量如何使用，日志怎么打，異常怎么捕獲、處理。而主要通過Code Style, Copyright, Code Template 3塊來進行一些大方向上的約束。為了防止不遵循規(guī)約的代碼合并倉庫，我們通過PR Checklist, checkstyle和持續(xù)集成來自動化校驗行為。因為我們相信，凡是有人介入的地方，就存在check的必要。凡是有人介入的地方，就存在自動化的可能。
研發(fā)流程
RocketMQ的開源模式不是傳統(tǒng)意義上的開放內核模式，而是和Apache Hadoop和OpenStack這一類開源平臺模式類似，我們嘗試把開源世界和專有世界最好的結合起來，在真正意義上的協(xié)作平臺上生產專有產品。我們希望Redhat，CentOS和Fedora這樣的產品簇協(xié)同發(fā)展效應也能體現(xiàn)在RocketMQ未來的演進中。為了迎接這樣的挑戰(zhàn)，團隊必須從軟件研發(fā)流程方面做出改變，構建能夠同時支撐內部、開源社區(qū)以及商業(yè)化的生態(tài)體系。
分支模型
RocketMQ在設計之初就曾設想過未來One Kernel這樣的產品形態(tài)。這些年下來，圍繞著它，團隊打造了AliwareMQ、MetaQ、以及Notify 3.0等內部、商業(yè)化產品。隨著RocketMQ進入Apache，代碼的演進變得愈加復雜，而傳統(tǒng)的Master分支模型很難滿足開源、商業(yè)化、集團內部和公有云、私有云共用一個RocketMQ內核這樣的需求。通過不斷的思考與實踐，我們通過引入鏡像倉庫機制解決了這一難題。具體講，就是通過在每個倉庫配置master和develop分支，不同的倉庫直接由鏡像節(jié)點進行轉換和特性緩沖。這樣下來，在Apache上孵化的特性可以一路合并至內部甚至輸出到公有云、私有云，在內部孵化的特性也能以PATCH的方式反哺到開源社區(qū)。如下圖所示：
?? 
持續(xù)集成、持續(xù)壓測，持續(xù)交付
借助Travis和Jenkins，我們搭建了兩套基礎設施。在Github上，Travis會對所有commit，所有PR觸發(fā)持續(xù)集成，這是它的一個強大之處。除此之外，它還支持跨JDK，跨平臺的Matrix驗證(不過很可惜，OSX平臺似乎一直都有問題)。在內部，利用Jenkins 2.0的Pipeline實現(xiàn)了持續(xù)集成，持續(xù)壓測，持續(xù)交付(Docker，Pandora以及AWS Cloud，Azure Cloud)。如下圖所示：
?? 
由上圖可知，整個持續(xù)集成分為代碼靜態(tài)檢測，單元測試，集成測試，Sonar質量評測這個幾個Stage。對于單元測試，不僅要覆蓋核心邏輯，而且要快(內置3分鐘閾值，超過就報錯和發(fā)郵件)。無數(shù)實踐告訴我們，如果不夠快，就會有更多的同學在本地編譯時選擇跳過單測，久而久之，單測就慢慢失去了意義，變得愈發(fā)不可維護。要全，要快，還要可維護性。這對單測編寫者來說無疑是個巨大挑戰(zhàn)，這就要求多線程之間的交互盡量避免依賴sleep，自底向下的盡可能Mock依賴，動賓狀結構的優(yōu)雅命名，斷言異常而不是拋出異常。
發(fā)布規(guī)約
進入Apache后，尤其在孵化階段，學習并遵循Apache發(fā)布流程顯得尤為重要。
?? 
上面這幅圖描述的是Apache孵化項目的發(fā)布流程。快、穩(wěn)，這是RocketMQ團隊第一次發(fā)布傳達給社區(qū)的信息?？v觀所有Apache孵化項目，能夠在這么短的時間內，用這么少的次數(shù)(RC3)學習并走完發(fā)布，用行動證明中國人同樣具備嚴謹且專業(yè)地做事態(tài)度。當然，我們也是幸運地，幸運地碰到了Justin和Bruce這兩位熱心、專業(yè)的Mentor。這里，需要強調下Release生成的幾個重要文件，如下圖：
?? 
源碼(src)和二進制文件(bin)被分別打包。asc是一個簽名文件，committer使用自己的私鑰對分發(fā)包進行簽名，任何人可以用我們對外公布的512位的公鑰進行驗證。
另外，還有一個不得不提的事情。Apache對License進行了嚴格的分類，比如Apache License 2.0/1.1，BSD，MIT/X11等屬于Category A，這些協(xié)議與Apache License是兼容的，可以放心地引入。對于Category B中的License，比如EPL 1.0，MPL 1.0/1.1/2.0等能夠以binary的形式引入。對于Category X中的License如GPL，LGPL則不能引入到產品當中。
針對License的問題，RocketMQ在首次發(fā)布的時候，在社區(qū)里進行了充分討論。如何處雙重License的依賴，如何區(qū)分Source和Binary Release依賴的License問題，如何處理NOTICE。這些知識被我們“現(xiàn)學現(xiàn)賣”的用在了指導社區(qū)貢獻上面，既加強了記憶，又很好地傳承給了社區(qū)。
PR & Jira處理
這是一個RocketMQ way的具體體現(xiàn)。針對PR，我們設計了一套Checklist，如下圖所示：
?? 
所有PR必須有3+ Committer Review，Committer提交的PR，盡量不要自己Merge。另外，PR的合并是個費時費力的工作，團隊成員通過研究，編寫了一個自動化Python腳本，巧妙地將原先幾分鐘的常態(tài)工作縮減到了幾秒鐘，一定程度上體現(xiàn)了中國工程師“懶中求勝”的匠心精神。而Jira，我們強調component，每個component都有2到3位committer or maintainer把持。Jira的處理一般是需要經過Resolve階段，最后才是Close，并且詳細標明受影響的版本，在哪個版本修復掉。
社區(qū)篇章
在產品篇章里，我們主要從編碼規(guī)約，分支模型，持續(xù)交付，發(fā)布規(guī)約等環(huán)節(jié)回顧了這半年來可喜的變化。接下來的社區(qū)篇，我們將聚焦社區(qū)，重點介紹Apache Way，RocketMQ Way，以及社區(qū)成熟度模型。至于品牌&社區(qū)的Building，業(yè)界也有很多實踐，如DevRel，JUG等。這里，放張圖感受一下。
?? 
Apache Way
在Apache社區(qū)，一個很重要的理念，Community over Code。社區(qū)是判斷一個孵化項目能否畢業(yè)的重要考核標準。但這并不意味著Code就不重要。仔細回想一下，在你接觸過的所有Apache頂級項目中，有沒有給你留下深刻印象的Code(請允許我拿代碼來說事，代碼就像一面鏡子，是工程師的門面，也是工匠榮辱的最直接體現(xiàn))。相信那些研究過大量Apache頂級項目的同學，一定有和我一樣的感受。Apache在大力強調社區(qū)的今天，很容易給大家讓大家誤解 - 設計不重要了，代碼不重要了。試想下，如果產品的設計，產品的質量不過硬，又怎么指望會有一個健康多元的社區(qū)呢?所以，我們重視社區(qū)，但也重視設計，重視代碼質量，重視產品帶給用戶的體驗。
?? 
上面這幅圖節(jié)選自之前MeetUp上的分享，是我們對于Apache Way的理解。
· Community - Over Code，首先要認識社區(qū)，社區(qū)包羅萬象，有Developers，Writers，Testers，Sysadmins，Devops，Users等等，但不需要Employee。由Employees打造的社區(qū)是不健康的，不可持續(xù)的，缺乏多元化。國際上一些大公司，早期參與Apache項目，一味想著控制社區(qū)，殊不知Apache社區(qū)理念的精髓在于與社區(qū)，與其它企業(yè)，其它個人貢獻者，培養(yǎng)協(xié)作，加速項目與個人的成長。社區(qū)不會憑空產生，不是把項目往Github上一丟就是開源了，然后社區(qū)就會自動產生。一個社區(qū)的經營是需要花費心思的，發(fā)展一個社區(qū)成員，爭取一個國際貢獻者，這些都是一個長期經營的過程。RocketMQ社區(qū)的第一個國際貢獻者，我們整整跟進、鼓勵了近2個月。當然，還有不少老外也表達出了貢獻社區(qū)的興趣，萬丈高樓平地起，先從最基本的工作做起，讓社區(qū)看到你的努力，看到你持續(xù)跟進、貢獻社區(qū)的決心，Apache Committer(認證程序員)自然離你不遠。
- Merit - Recognizing Your Work，參與社區(qū)的建設能獲得什么，一個Contributor在社區(qū)的所有努力是有目共睹和有跡可循的，提交了多少Issue和PR?參與了多少Code Review，郵件列表里是否總有真知灼見冒出來，這一切都在Github、JIRA、和郵件列表里進行了沉淀，在得到社區(qū)的認可后，Contributor變成為了Committer，Committer變成為了PMC Member。一步一步，社區(qū)認可了你的貢獻，你也獲得了不錯的成長。
- Open Development - For Everything，社區(qū)一切都是開放的，特別是對于開發(fā)，每個人都可以參與到每行代碼中，從開發(fā)前的DISCUSS，再到Pull Request中的Code Review，甚至作為User使用方面的Feedback。所有的討論，思想的碰撞，甚至是爭論，都是Public的。對于國內社區(qū)，我們一直在鼓勵所有線下(包括QQ)的重要討論，在郵件列表里都能有所體現(xiàn)，一切都是開放與透明的，沒有私下的決定。
- Decision Making - Consensus & Votes，絕對的開放也會帶來一定的弊端，如流程上的繁瑣與拖沓。在社區(qū)做決議，首先需要通過在郵件列表中發(fā)起討論，達成一致后，需要再發(fā)起一次投票，并至少等待72小時(考慮全球時區(qū))后才能宣布投票結果。流程雖繁，但決議一旦通過，就堅決執(zhí)行，這也是一種社區(qū)執(zhí)行力的體現(xiàn)。
在學習和實踐Apache Way的過程中，團隊也摸索出了一套我們稱之為RocketMQ Way的最佳實踐。
- International Collaboration - 禁止中文注釋，允許User郵件列表使用中文提問，但Dev郵件列表必須使用英文。關于幾個郵件列表的用途，請參考官方說明。
- PR Management - Pull Request提交、合并需遵循一定的規(guī)約(checklist);每個PR必須有足夠的單元測試，集成測試，有增量的代碼覆蓋率要求;PR的合并有3+ +1，Committer提交的PR不要自己Merge。
- Diversity Review - 對于Committer代碼實施CTR(Commit then Review)策略，對于Contributor則是RTC(Review then Commit)策略。
- Branch Model - 采用雙主干模式(Master與Develop)，秉持One kernel的理念。
- Community CodeMarathon - 不定期的編程馬拉松，挖掘社區(qū)活躍的貢獻者，培養(yǎng)并輔導社區(qū)的深度參與者。
- Ecosystem Assemble - 獨立倉庫，為社區(qū)項目安營扎寨。每個個體在貢獻之前，首先要提交Apache的ICLA。
- One contributor, One Mentor - 每位PMC成員都有義務幫助社區(qū)Contributor，輔導并帶領他們熟悉Apache Way，成為Committer甚至是PMC Member。
網站流量的變化
半年多的時間里，我們陸續(xù)在云棲社區(qū)，CSDN，InfoQ中文站、國際站發(fā)表了多篇技術文章，撰寫國際論文，在ApacheCon、LinuxCon等國際頂級開源峰會發(fā)表主題演講，全球圖文同步直播Meetup。通過這一系列國際輸出，網站流量迎來了可喜變化。
通過這幅圖可以看到，美國現(xiàn)在已經是RocketMQ全球第2大訪問國。這對團隊即將開展的Aliware MQ國際戰(zhàn)略，奠定了良好的基礎。同時，這種持續(xù)走高的流量也在不斷鞭策著我們，寫高質量代碼，做高質量產品，向全球輸出中國智(質)造。
成熟度評估
坦白說，RocketMQ進入Apache之初，并沒有針對這個模型做任何學習(討厭應試教育)。我們希望通過自己的理解和踐行，完成全球社區(qū)的構建，完成畢業(yè)。令人驚喜的是，當團隊8月份開始正式審視畢業(yè)TODO List時，發(fā)現(xiàn)Apache的理論指導和我們的實踐驚人的一致。理解萬歲!下圖是RocketMQ的社區(qū)成熟度評估。
?? 
生態(tài)篇章
作為國內首個非Hadoop、Spark大數(shù)據(jù)生態(tài)下的Apache頂級項目，我們在打造多元化社區(qū)的同時，也在努力構建以Messaging為Core的生態(tài)體系。之前提到過的，我們?yōu)樯鐓^(qū)生態(tài)貢獻者提供了單獨的Apache代碼倉庫。這一做法，現(xiàn)在也在紛紛被其它Apache頂級項目所效仿。截止目前為止，來自社區(qū)貢獻的RocketMQ-Console, RocketMQ-JMS, RocketMQ-Flume，RocketMQ-CPP 等生態(tài)項目已經在諸多公司內部進行了線上驗證，像RocketMQ-Druid，RocketMQ-Ignite，RocketMQ-Storm等項目，代碼更是被合并進對方倉庫，這也使RocketMQ和其它頂級開源項目、社區(qū)之間有了更多連接。更多的生態(tài)項目介紹，請參考官網介紹。
?? 
Messaging生態(tài)
?? 
上面這幅圖是團隊圍繞著OpenMessaging 標準而努力打造的生態(tài)體系。OpenMessaging是團隊多年來從事Messaging領域研究的一個經驗提煉。經過半年多的發(fā)展，這套標準已經進入Linux基金會，接下來會進入到CNCF，成為云計算不可或缺的標準之一。而這套API級的跨平臺，跨語言標準，會嘗試解決之前我們遇到但未曾徹底解決的所有問題。如下圖所示，分布式事務，我們內部的產品MateQ和Notify也有類似的特性，但這種分布式事務更多的是發(fā)送者分布式事務，并不是真正意義上的分布式事務。負載均衡，在拉模式和推模式下策略會有所不同，消息本身的sharding也會因業(yè)務場景不同而不同。分布式追蹤，主要是考慮Linux CNCF中的opentracing。協(xié)議橋接，主要是考慮如何和現(xiàn)有的標準，如JMS進行無縫橋接。流計算，通過引入流計算算子，在消息投遞過程中針對內容進行計算。Benchmark，類似SPECJMS，把所有Messaging Engine拉到同一基調上做性能測試。
?? 
總結一下，基于OpenMessaging的下一代的消息引擎RocketMQ 5.0主要會在四個領域持續(xù)發(fā)力：電子商務，高并發(fā)下削峰填谷。物聯(lián)網領域，海量連接同時在線。大數(shù)據(jù)領域，吞吐為王。金融領域，重要的是高可靠，數(shù)據(jù)冗余。
結束語
和其它國際頂級開源項目略有不同(如Hadoop，Spark等)，除了在開源社區(qū)的努力外，團隊在阿里集團也支撐著非常有挑戰(zhàn)的內部業(yè)務(萬億級消息體量)。此外，RocketMQ商業(yè)版Aliware MQ已經對外云輸出2年之久，服務了國內外上千家企業(yè)。除了這些，團隊也在積極打造消息流計算生態(tài)，在Kafka，RabbitMQ，中繼和數(shù)據(jù)同步等產品上持續(xù)耕耘。最近，OpenMessaging標準項目也正式入駐Linux基金會，這也是國內首個在全球范圍內發(fā)起的分布式消息領域國際標準。所有這一切，對團隊來說都極具挑戰(zhàn)，我們希望在分布式、大數(shù)據(jù)、多語言架構領域有較高造詣，有追求的同學加入團隊，而團隊也會努力提供極具挑戰(zhàn)的施展空間。我們重視成長，關注可持續(xù)發(fā)展。Apache RocketMQ頂級項目的畢業(yè)只是一個開始。前路漫漫，未來可期!
作者簡介：馮嘉，阿里巴巴高級技術專家，Aliware MQ負責人、主架構師，Apache RocketMQ聯(lián)合創(chuàng)始人，LInux OpenMessaging 標準創(chuàng)始人。具有豐富的分布式軟件架構、高并發(fā)網站設計、性能調優(yōu)經驗，擁有國內外多項分布式、推薦領域的專利。開源愛好者，專注分布式、大數(shù)據(jù)領域，關注 Hbase/Hadoop/Spark/Flink 等大數(shù)據(jù)技術棧。
【本文為51CTO專欄作者“阿里巴巴官方技術”原創(chuàng)稿件，轉載請聯(lián)系原作者】
