始於阿里，迴歸社群｜阿里巴巴的開源之路

破土而出的生命力，源自理想主義者心底對技術的信念。

開源曾經幫助 Redhat 在傳統軟體市場奠定了其行業地位。無獨有偶，作為雲端計算時代的趕超者，谷歌也拿起了開源的武器，試圖打亂 AWS 和 Azure 的節奏。

目前，這一策略似乎正在奏效。

如今雲原生技術正席捲全球，雲原生基金會在去年 KubeCon +CloudNativeCon NA 的現場宣佈：

其正在孵化的專案已達 14 個，入駐的廠家或產品已超過 300 家，並吸引了 2.2 萬開發者參與專案程式碼貢獻，其明星產品 Kubenetes 的 GitHub 上 Authors 和 Issues 量已排行開源領域的第二名。 而 Kubenetes 正是 Google 開源的一個容器編排引擎。

今年，KubeCon + CloudNativeCon 首次來到中國。

在2018 KubeCon + CloudNativeCon的現場，阿里雲研究員伯瑜向在場的開發者們宣佈， CNCF 已將阿里巴巴雲原生映象分發系統 Dragonfly 接納為其沙箱專案（Sandbox）， 並有機會成為國內首個從  CNCF  畢業的開源專案。目前已經畢業的兩個專案，一個是 Kubernetes，另一個是 Prometheus。

據悉，目前阿里巴巴已經有 8 個專案進入 CNCF 雲原生全景圖，分別是分散式服務治理框架 Dubbo、分散式訊息引擎 RocketMQ、流量控制元件Sentinel、企業級富容器技術 PouchContainer、服務發現和管理 Nacos、分散式訊息標準 OpenMessaging、雲原生映象分發系統 Dragonfly 和高可用服務 AHAS。

 時間回到 2016 年。

2016 年的那屆雙11，RocketMQ 創始人馮嘉和他的團隊首次將低延遲儲存解決方案應用於雙11的支撐，經受住了流量的大考，整個大促期間，99.996%的延遲落在了 10ms 以內，完成了保障交易穩定的既定目標。

對於讀寫比例幾乎均衡的分散式訊息引擎來說，這一技術上的突破，即便是放在全球範圍內，也絕對是值得稱讚的。

RocketMQ 團隊和社群開發者們

另一邊，在歷時3個月的開源重塑後，馮嘉和他的團隊啟動了 RocketMQ 向Apache 軟體基金會的捐贈之路，但邁出這一步並不容易。

“當時國內的開源氛圍還沒有現在那麼活躍，開源之後，很多設計、原始碼和文件的維護工作還不夠理想，但我們就是想證明國內的開源專案和開源社群也可以在世界的開源舞臺上發揮價值。”

經過近一年的努力，在2017年9月25日，Apache 軟體基金會官方宣佈，阿里巴巴捐贈給 Apache 社群的開源專案 RocketMQ 從 Apache 社群正式畢業，成為 Apache 頂級 專案（TLP），這是國內首個非 Hadoop 生態體系的Apache 社群頂級專案。

值得一提的是， 根據專案 畢業前的統計，RocketMQ 有百分八十的新特性與生態整合來自於社群的貢獻。

 2017 年，訊息領域出現一件里程碑事件。

分散式訊息領域的國際標準 OpenMessaging 開源專案正式入駐 Linux 基金會，這是國內首個在全球範圍發起的分散式計算領域的國際標準。

訊息通訊已經成為現代資料驅動架構的關鍵環節，但在全球範圍內，訊息領域仍然存在兩大問題：

一是缺乏供應商中立的行業標準，導致各種訊息中介軟體的高複雜性和不相容性，相應地造成了公司的產品低效、混亂和供應商鎖定等問題。

二是目前已有的方案框架並不能很好地適配雲架構，即非雲原生架構，因此無法有效地對大資料、流計算和物聯網等新興業務需求提供技術支援。

這也是馮嘉和他的團隊在開源 RocketMQ 過程中，開發者和合作夥伴經常會提到的問題：“在訊息領域，市場上出現了各類不同的開源解決方案，這導致了使用者更高的接入和維護成本，為了確保各個訊息引擎間能正常通訊，還要投入大量的精力去做相容。”

這時候，建立一套供應商中立，和語言無關的訊息領域的事實標準，成為各社群成員共同的訴求。

感謝大家，是馮嘉參加社群獲得最常說的一句話

此後，在 2017 年 9 月，阿里巴巴發起 OpenMessaging 專案，並邀請了雅虎、滴滴出行、Streamlio共同參與，一年後，參與 OpenMessaging 開源標準社群的企業達10家之多，包括阿里巴巴、Datapipeline、滴滴出行、浩鯨科技、京東商城、青雲 QingCloud、Streamlio、微眾銀行、Yahoo、中國移動蘇州研發中心（按首字母排序），此外，還獲得了 RocketMQ、RabbitMQ 和 Pulsar 3 個頂級訊息開源廠商的支援。

相比於開源一個分散式訊息專案，一套開源標準能被各家廠商所接受，對整個國內開源領域而言，是更具有里程碑意義的事件。

 2017 年 9 月，Dubbo 重啟開源。

Dubbo 是阿里巴巴於 2012 年開源的分散式服務治理框架，是國內影響力最大、使用最廣泛的開源服務框架之一，在 2016 年、2017 年開源中國發起的最受歡迎的中國開源軟體評選中，連續兩年進入 Top10 名單。2017 年 9 月 7 日，在 Github 將版本更新至 2.5.4，重點升級所依賴的 JDK 及其元件，隨後連續釋出了 11 個版本。

並於2018年2月捐獻給 Apache 軟體基金會，希望藉助社群的力量來發展 Dubbo，打消大家對於 Dubbo 未來的顧慮。

  Dubbo 團隊和社群開發者們

專案重啟半年後，Dubbo 專案負責人阿里巴巴高階技術專家北緯在接受媒體採訪的時候，從戰略、社群、生態和回饋四個方面談了 Dubbo 重啟開源背後的原因。

“集團近幾年開始將開源提到了新的戰略高度，這次投入資源重啟開源，核心是希望讓開源發揮更大的社會價值， 並和廣大開發者一起，建立一個繁榮的 D ubbo 生態，普惠所有使用 Dubbo 的人和 Dubbo 本身。 ”

Dubbo專案組成員朱勇在今年上海的技術沙龍上分享Dubbo未來發展的過程中提到，其後續的規劃是要解決好兩個問題。

第一個問題是重點關注技術趨勢，例如雲原生對 D ubbo開源現狀的影響。

第二個問題是 Dubbo 本身定位的問題，除了保持技術上的領先性，還需要圍繞 Dubbo 核心發展生態，和社群成員一起將 Dubbo 發展成一個服務化改造的整體解決方案。

 2017 年 11 月，阿里自研容器技術 PouchContainer 開源。

在開源不到一年的時間裡，PouchContainer 1.0 GA 版本釋出，達到可生產級別。今年 8 月，PouchContainer 被納入開源社群開放容器計劃 OCI；9 月，被收錄進高校教材《雲端計算導論》；11 月，PouchContainer 團隊攜螞蟻金服容器團隊、阿里雲 ACS 團隊，與容器生態 Containerd 社群 Maintainer進行技術交流， 有望發展成 Containerd 社群 M aintainer 席位，代表國內企業在世界容器技術領域發聲。

  PouchContainer 發展速度之快，超出了宏亮的想象。

宏亮是 Docker Swarm 容器叢集專案的核心程式碼維護者（Maintainer），並於2015 年 8 月出版了《Docker 原始碼分析》一書，對 Docker 架構和原始碼進行了深入的講解，該書在  D ocker 領域迅速成為暢銷書籍。2017 年，宏亮承擔起阿里自有容器技術的對內支援和對外技術佈道的工作，秉承初心，希望在競爭激烈的容器開源領域能搶下屬於國內容器技術的一席之地。

在團隊的努力下，阿里集團內部已實現 100%的容器化， 並已經開始涉及離線業務，實現在、離線業務的混合排程與部署。

整個集團能實現 100%的容器化，離不開阿里內部自研的 P2P 分發技術，該專案取名為 Dragonfly，寓意點與點之間的檔案分發能如蜻蜓般輕盈和迅速，解決傳統檔案釋出系統中的大規模下載、遠距離傳輸、頻寬成本和安全傳輸的問題。

日前， Dragonfly 正式進入 CNCF， 併成為國內第三個被列為沙箱級別（Sandbox Level Project）的開源專案 ，可見，CNCF 在其雲原生的技術版圖中正希望藉助Dragonfly等優秀的映象分發技術，以提升企業微服務架構下應用的交付效率。

 始於阿里，迴歸社群。

今年夏天，國內開源領域，迎來了兩位新成員。

作為微服務和雲原生生態下的兩款重要開源框架/元件，Nacos主打雲原生應用中的動態服務發現、配置和服務管理，Sentinel 則是聚焦在限流和降級兩個方面。

Nacos 和 Sentinel 均是在阿里近 10 年的核心業務場景下沉澱所產生的，他們的開源是對微服務和元原生領域開源技術方案的有效補充，同時也非常強調融入開源生態，除了相容 Dubbo和Sentinel，也支援對Spring Cloud 和  Kubenetes 等生態，以增強自身的生命力。

“阿里巴巴早在 2007 年進行從 IOE 集中式應用架構升級為網際網路分散式服務化架構的時候，就意識到在分散式環境中，諸如分散式服務治理，資料來源容災切換、異地多活、預案和限流規則等場景下的配置變更難題，因為在一個大型的分散式系統中，你沒有辦法把整個分散式系統停下來，去做一個軟體、硬體或者系統的升級。” 阿里巴巴高階技術專家坤宇在 2017 QCon 的現場分享到。

Nacos 團隊成員在雙11支援現場

在配置變更領域，我們從2008年的無 ConfigServer 時代，借用硬體負載裝置 F5 提供的 VIP 功能，透過域名方式來實現服務提供方和呼叫方之間的通訊，逐步經歷了  ConfigServer  單機版、叢集版的多次迭代，不斷提高其穩定性。

曾寫下 支付寶錢包服務端第一行程式碼 的阿里高階技術專家慕義，在今年深圳的技術沙龍現場回憶了阿里註冊中心自研的 10 年路：

“這期間，集團業務經歷了跨越式的發展，每年翻番的服務規模，不斷的給 ConfigServer 的技術架構演進帶來更高的要求和挑戰，使得我們有更多的機會在生產環境發現和解決一個個問題的過程中，實現架構的一代代升級。 Nacos 便是在這樣的背景下，經過幾代技術人的技術攻堅所產生的。”

我們希望  N acos 可以幫助開發者獲得有別於原生或其他第三方服務發現和動態配置管理解決方案所提供的能力，滿足開發者們在微服務落地過程當中對工業級註冊中心的訴求，縮短想法到實現的路徑。

巧的是，一邊是 Nacos宣佈開源，另一邊是 Spring Cloud 生態下的服務註冊和發現元件 Netflix Eureka 宣佈閉源， 勇敢者的遊戲充滿了變數，但在坤宇和他的團隊看來，這場遊戲自己可以走到最後，因為我們並不是一個人在戰鬥，Nacos 只是阿里眾多開源專案中的一員，隨後還會有更多的開源專案反哺給社群，形成生態 ，例如輕量級限流降級元件 Sentinel。

Aliware Open Source•深圳站現場  

7月29日，Aliware Open Source•深圳站現場，只能容納 400 人的場地，來了 700 多位開發者。阿里巴巴高階技術專家子矜在現場宣佈了輕量級限流降級元件  S entinel 的開源。

作為阿里巴巴“大中臺、小前臺”架構中的基礎模組， S entinel 經歷了 10 年雙 11 的考驗覆蓋了阿里的所有核心場景，也因此積累了大量的流量歸整場景以及生產實踐。

S entinel 的出現，離不開阿里歷屆高可用架構團隊的共同努力。

“在雙11備戰中，容量規劃是最重要也是最具挑戰的環節之一。從第一年開始，雙11的 0 點時刻就代表了我們的歷史最高業務訪問量，它通常是日常流量的幾十倍甚至上百倍。

因此，如何讓一個技術和業務持續複雜的分散式站點去更平穩支撐好這突如其來的流量衝擊，是我們這 10 年來一直在解的題。”阿里巴巴高 可用架構團隊資深技術專家遊驥在今年的雙11結束後分享道。

這 10 年，容量規劃經歷了人工估算、線下壓測、線上壓測、全鏈路壓測、 全鏈 路壓測和隔離環境、彈性伸縮相結合的 5 個階段。2013 年雙11結束後，全鏈路壓測的誕生解決了容量的確定性問題。

作為一項劃時代的技術， 全鏈路壓測的實現， 對整個集團而言，都是一件里程碑事件。

 2 014 年，高可用架構團隊獲得集團 CTO 大獎

隨後，基於全鏈路壓測為核心，打造了一系列容量規劃相關的配套生態，提升能力的同時，降低了整個環 節的成本、提升效率。隨著容量規劃技術的不斷演進，2018 年起，高可用架構團隊希望可以把這些年在生成環境下的實踐，貢獻給社群，之後便有了  S entinel 的開源。

一邊是作為發起者。

將自己生產環境實踐下沉澱出來的架構和技術貢獻給社群。

另一邊是作為參與者。

基於一些開源專案或雲平臺，輸出可以解決開發者當前工作中存在的痛點的解決方案，例如近期新開源的專案 Spring Cloud Alibaba 和 開發者工具  Alibaba Cloud Toolkit。

相同的是，技術理想主義者都希望技術可以為讓世界變得更好，這才是技術人的興奮點。

“讓世界的技術因為阿里巴巴而變得更美好一點點”。

這是阿里巴巴系統軟體、中介軟體、研發效能事業部負責人畢玄郵件簽名中的一句話。他正和一群技術理想主義者，與太平洋另一邊的技術高手們正面PK，在這場躲不開的戰役中，一起認真一把。

本文部分素材參考自：InfoQ/ 開源中國/ 養碼場/ 阿里技術/雲棲社群