微博紅包：大規模Docker叢集實踐經驗分享

每年除夕看春晚，今年除夕搶紅包。在整個羊年的春節假期裡，大家都在忙著搶各種各樣的電子紅包，網際網路用紅包的方式革新了我們的拜年方式。為此，InfoQ策劃了“春節紅包”系列文章，以期為讀者剖析各大平臺的紅包活動背後的技術細節。本文為微博篇。

羊年春晚Docker叢集成功的為1.02億小夥伴刷微博、搶紅包提供了可靠的服務。本文將為大家揭開微博平臺Docker叢集的神祕面紗，包括叢集規模，技術架構等方面情況。不過在分享前，先問兩個問題，不知道大家是否正為這兩個問題而糾結：

1. Docker技術能夠解決什麼問題？
2. Docker技術是否足夠成熟，是否可以在生產環境上大規模應用？

一個月前，微博平臺也在這兩個問題中糾結一段時間，事實勝於雄辯，先來看一下微博平臺Docker叢集的規模情況：

• Docker叢集規模達到1000+節點
• QPS峰值達到800K/s
• 4個9的服務SLA達到150ms
• 共覆蓋23個核心服務
• 春晚共排程近300節點完成動態擴容

在引入任何新技術之前，在架構決策上必須回答：我們現在有什麼問題，它能夠解決嗎。否則就變成了唯技術論，造成不必要的資源浪費。促使平臺做出決定的一個主要因素就是春晚的紅包飛活動。現在大家都知道，微博春晚紅包飛共計抽取了3.5億次，馬雲的支付寶紅包以及任性土豪的1234567元跨年紅包，在3分鐘內被搶光，帶動使用者用活躍度提升46%，達到1.02億使用者。同時廣大使用者還活躍在各種粉絲群中，為了搶到一個分組紅包手機螢幕都快點碎了。面對這種到處開花的流量峰值，傳統按照業務峰值部署叢集的方式，裝置成本將無法接受。所以平臺需要一種能夠在叢集間快速排程業務的技術方案。

Docker是目前能夠實現這一目的的最佳方案。為什麼原有的叢集管理方式，無法實現快速業務切換呢，關鍵問題是環境的差異性。程式猿都知道在程式碼執行的世界裡，拆東牆補西牆是一件不靠譜的事情，弄不好會塌方的。虛擬化可以實現隔離軟體執行環境差異性，目前虛擬化技術有以OpenStack為代表傳統VM技術，和以Docker為代表的Container技術兩大類。如何在二者中進行選擇，平臺從下面幾個維度進行了評估，供大家參考：

	Docker	OpenStack	結論
啟動速度	秒級	分鐘級	面對流量峰值，速度就是一切
複雜度	基於核心的namespace技術，對現有基礎設施的侵入較少	部署複雜度較高，並且很多基礎設施不相容	因為平臺是對已有的線上生產系統進行改造，必須選擇侵入性較小的容器化技術
執行效能	在核心中實現，所以效能幾乎與原生一致	對比核心級實現，效能較差	微博核心業務對服務SLA要求非常苛刻
可控性	依賴簡單，與程式無本質區別	依賴複雜，並且存在跨部門問題	生產系統叢集可控性是核心競爭力能力
體積	與業務程式碼釋出版本大小相當，MB級別	GB級別	當叢集大規模部署時，體積小就代表更大的併發排程量

下面先介紹目前微博平臺Docker叢集的技術棧：

• 宿主機：CentOS 6.5
• Docker：1.3.2
• Registry：docker-registry 0.9.1版本
• 組網：host模式
• 監控：cAdvisor + Elasticsearch + Kibana + Graphite
• 檔案系統：devicemapper
• 映象釋出：Jenkins Container
• 容器：容器即服務，服務即容器
• 日誌：volume掛載
• 生命週期管理：自研，類似Compose
• 服務發現：自研，類似Kubernetes的Pods和Service

那麼從無到有部署一個超過1000節點，風險和挑戰是非常大的。必須有一套方法能夠確保在改造過程中業務的穩定性，平臺也想了很多辦法，但其實宗旨就一個：可控。把這些方法可以總結為幾條原則：

• 規模化
• Stupid But Works
• 無縫對接

先來談一談規模化。乍一看，規模化與可控是對矛盾體。程式設計師都知道，如果一種新技術不在大規模環境下驗證通過，是無法證明其可靠性。從業務角度，一旦引入新技術，就要承擔出問題的風險，所以業務都希望引入的新技術是通過大規模環境驗證過的。對於這種情況，一般做法有兩種，一種是先在一個業（bei）務（cui）試點，成功後再進行推廣。但是這種方式主要問題是反覆概率較大，引用一句臺詞就是：“我吃了沒事，不代表你吃了就沒事”，結果就會出現到處打補丁的局面，不利於架構標準化。所以平臺採用的是“大鍋飯”的方式，就是所有業務同時上馬，逐步增加規模。這種方式好處顯而易見，差異性可以在第一時間得到解決，最終只有一套標準化架構。但這種方式需要非常強的專案管理能力，保證各業務組目標一致，分工明確，里程碑清晰，同時還需要專案組成員有強烈的使命感，時間意識，團隊意識。

搞定團隊之後，首要任務就是要使工作保持方向，那麼什麼是正確方向呢：Stupid But Works。新技術落地專案失敗有很多因素，其中主要一個誘因就是：完美主義，或者叫偷換目標。典型症狀如下：目前架構不夠優雅，需要XXX。例如Docker的組網能力飽受詬病，此時不應該糾結一個完美的組網方案，否則就可能專案不保。因為技術突破都依賴很多先決條件，可能是受限於基礎網路環境，受限於核心能力，所以此時最佳的策略是跟上趨勢，積累經驗，伺機突破。再比如Docker對日誌資料管理方式奇多，但最完美的並不一定適合你，如果此時決定對現有的日誌管理進行改造，就合原本的目標背道而馳了。最佳的策略是選擇認知成本最小的方案，而不是最完美的方案。

對已有叢集進行Docker化改造，最大的一個阻力就是新老結合問題，所以Docker叢集必須能與原有運維、研發系統無縫對接，才能夠使專案順利進行。例如容器化，是否改造程式碼。平臺當時遇到的一個問題是不同宿主機的容器分配的ip有可能是一樣的，原本獲取本地ip的程式碼就會取到相同的值，直接導致分散式系統跟蹤系統失效。所以要在Docker層面解決這個差異性，而儘量不修改原系統設計。

對於Docker未來部署規模達到萬級別後，還有很多技術難題有待解決，平臺也會在下面幾個方面繼續探索，希望能夠把經驗回饋給社群：

• 網路瓶頸，萬級別的容器部署，勢必會挑戰現有的網路基礎設施，交換機的轉發表項會遇到瓶頸。網路隔離可以保證服務間互不影響，但是又限制了靈活排程，SDN是大趨勢。
• 彈性排程，目前還處於“社會主義初級階段”，一切都還要靠“中央”下達指令。Kubernetes、Mesos、Swarm等技術提供在萬級別叢集規模下自動化彈性排程的可能性，但整體解決方案我們也還在摸索。

微博平臺期待你的加入，共同開始打造大規模Docker叢集。