Docker在春晚中的實際表現

Docker成功的為1.02億小伙伴刷微博，搶紅包提供了可靠的服務。接著上一篇文章《大規模Docker 集群助力微博迎接春晚峰值挑戰》，這里給大家分享Docker在春晚實戰中的實際表現，以及對于后續發展的的思路，由于篇幅有限這里僅點到為止，如果大家希望了解更多干貨，我在QClub：Docker專場(http://t.cn/RwIbks0)等著你。

首先介紹一下微博平臺Docker集群規模情況：

• Docker集群規模達到1000節點
• QPS峰值達到800K
• 整體服務SLA達到150ms四個9
• Docker化部署共覆蓋23個服務
• 春晚共調度近300節點完成服務動態擴容

在分享之前，先拋出一個問題：當部署規模達到萬級別的時候，最大的技術挑戰是什么？歡迎大家留言探討。下面言歸正傳，介紹一下微博平臺目前Docker部署環境采用的技術：

• 宿主機CentOS 6.5，考慮到目前生產環境現狀和CentOS 7的安全性、穩定性、兼容性等方面的問題
• Docker采用1.3.2版本，需要注意1.3.2依賴的一些lib版本與CentOS 6.5默認安裝的有沖突
• 網絡采用宿主機模式，NAT和默認Bridge方案都不能滿足平臺的訴求，OVS+Vlan的方案還在研發中，所以生產環境采用的是-host方式
• cAdvisor + Elastic Search + Kibana + Graphite作為容器監控方案
• 文件系統采用devicemapper，建議指定一個格式化的分區給devicemapper，否則建議根據根據應用情況，通過dm.basesize，dm.loopdatasize調整稀疏文件配額
• Registry用的是docker-registry 0.9.1版本，較老的版本存在壓縮時假死問題

在容器編排方面，參考業界實踐并結合自身業務特點和現有基礎設施，實現了適合平臺業務的定制化的解決方案：

• 一容器一進程，一是方便監控服務生命周期，二是方便進行資源隔離
• 日志采用數據卷掛載，一是避免容器內產生大量數據，踩devicemapper稀疏文件的坑，二是方便通過容器做數據采集與壓縮
• 容器生命周期管理，實現類似Fig/Composer的功能，同時增加了大規模并發調度的能力
• 服務發現，實現參考了Kubernates的Pods和Service概念，但是沒有采用自上而下的治理方式（Replication controllers），而是采用自主上報的方式，方便靈活調度。
• 無縫對接，重點解決Docker模式與普通進程模式并存情況下，運維管理的復雜度問題，確保Docker集群可以與其他運維子系統（例如降級子系統、上線發布子系統等）無縫對接
• 可量化，從QPS，服務SLA，系統負載，存活率等多個維度衡量各服務Docker集群的冗余情況

對于Docker在平臺的演進，也是對應上面提出的問題，個人認為當部署規模達到萬級別后，最大的技術挑戰有下面幾個，平臺也會在這幾個方面繼續探索，也希望能夠把經驗回饋給社區：

• 網絡瓶頸，萬級別的容器部署，勢必會挑戰現有的網絡基礎設施，需要通過SDN等技術來解決網絡規模問題
• 與原設施的整合，可能是大多數團隊在推進Docker落地時遇到的最頭疼的問題之一，我們希望能夠提供一些標準化的解決方案使遷移過程更加平滑
• 一切皆容器，但仍存在一些技術問題需要解決，例如在容器內管理容器的穩定性問題，短生命周期的容器管理等等
• 目前我們還處于“社會主義初級階段”，一切都還要靠“中央”下達指令，無法管理萬級別的動態集群，Kubernates、Mesos、Swarm的技術提供了可能性，但整體解決方案我們也還在摸索，我們希望能夠聽到你的聲音

來自：http://weibo.com/p/1001603816339658657489