微博紅包：大規模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集群的技術棧：

• 宿主機：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集群。

來自：http://www.infoq.com/cn/articles/large-scale-docker-cluster-practise-experience-share