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

摘要： 破土而出的生命力，源自理想主義者心底對技術的信念。 開源曾經幫助 Redhat 在傳統軟件市場奠基了其行業地位。無獨有偶，做爲雲計算時代的趕超者，谷歌也拿起了開源的武器，試圖打亂 AWS 和 Azure 的節奏。

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

開源曾經幫助 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 之內，完成了保障交易穩定的既定目標。

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

另外一邊，在歷時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 生態，普惠全部使用 Dubbo 的人和 Dubbo 自己。」

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

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

第二個問題是 Dubbo 自己定位的問題，除了保持技術上的領先性，還須要圍繞 Dubbo 核心發展生態，和社區成員一塊兒將 Dubbo 發展成一個服務化改造的總體解決方案。

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

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

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

宏亮是 Docker Swarm 容器集羣項目的核心代碼維護者（Maintainer），並於2015 年 8 月出版了《Docker 源碼分析》一書，對 Docker 架構和源代碼進行了深刻的講解，該書在 Docker 領域迅速成爲暢銷書籍。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 的現場分享到。

在配置變動領域，咱們從2008年的無 ConfigServer 時代，借用硬件負載設備 F5 提供的 VIP 功能，經過域名方式來實現服務提供方和調用方之間的通訊，逐步經歷了 ConfigServer 單機版、集羣版的屢次迭代，不斷提升其穩定性。

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

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

咱們但願 Nacos 能夠幫助開發者得到有別於原生或其餘第三方服務發現和動態配置管理解決方案所提供的能力，知足開發者們在微服務落地過程中對工業級註冊中心的訴求，縮短想法到實現的路徑。

巧的是，一邊是 Nacos宣佈開源，另外一邊是 Spring Cloud 生態下的服務註冊和發現組件 Netflix Eureka 宣佈閉源，勇敢者的遊戲充滿了變數，但在坤宇和他的團隊看來，這場遊戲本身能夠走到最後，由於咱們並非一我的在戰鬥，Nacos 只是阿里衆多開源項目中的一員，隨後還會有更多的開源項目反哺給社區，造成生態，例如輕量級限流降級組件 Sentinel。

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

做爲阿里巴巴「大中臺、小前臺」架構中的基礎模塊，Sentinel 經歷了 10 年雙 11 的考驗覆蓋了阿里的全部核心場景，也所以積累了大量的流量歸整場景以及生產實踐。

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

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

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

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

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

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

一邊是做爲發起者。

將本身生產環境實踐下沉澱出來的架構和技術貢獻給社區。

另外一邊是做爲參與者。

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

相同的是，技術理想主義者都但願技術能夠爲讓世界變得更好，這纔是技術人的興奮點。

「讓世界的技術由於阿里巴巴而變得更美好一點點」。

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

原文連接