【51CTO.com原創稿件】新浪微博在 2015 年春晚便通過 Docker 實現了私有云平臺的彈性調度能力，隨著公有云技術的成熟，我們發現原有私有云比較困難的問題在公有云上能夠比較容易的解決，例如突發峰值情況下彈性資源的成本，小業務快速試錯等場景。

[[197472]]

在 2016 年，微博完成了利用 Docker 構建混合云架構，本文將分享安全、網絡、資源管理、調度管理、跨云服務發現等方面的一些實踐經驗。

新浪微博龐大的數據背后是持續不斷的技術挑戰

微博的數據量，在國內的社交媒體中排行位居前列。如下圖：

百億級 PV、千億級數據、萬臺以上的服務器規模、數百以上服務模塊、千臺以上的 Docker 混合云集群等等，這些龐大數據背后，是持續不斷的技術挑戰。

在如此大的業務體系下，業務流量有很明顯的特征：

每年春晚當天流量會達到一年中峰值，這樣就會面臨機架位和上千臺服務器庫存不足的情況，因此采購成本巨大且周期長，運行三個月僅僅只為一晚的流量峰值。

• 白百何出軌、李晨范冰冰在一起等熱點事件，突發性強無預期、無準備，瞬時極端峰值、互動周期短，在這樣的情況下，Push 常規化，短時間內大量擴容的需求會很迫切。
• 傳統的服務擴容流程非常繁瑣，整套流程要經歷項目評審、設備申請、入 CMDB、裝機上架、初始化、服務部署和報修下架等過程。

如何在十分鐘內完成 1000 節點擴容能力

那么，如何才能快速順利的應對各種流量峰值呢?首要解決的是如何在十分鐘內完成 1000 節點擴容能力。

如下圖，是應對極端峰值問題的解決思路。

基于混合云彈性調度可伸縮的特性，可以保證成本業務快速迭代的情況下，實現彈性快速的擴縮容。選擇混合云是因為安全，具備可擴展性，成本相對較低。還有 Docker、Mesos 等容器新技術使大規模動態調度成為可能。

新浪微博 DCP 設計與實現

Docker化

在說 DCP 之前，我們先來了解一下 Docker。微博業務部署涉及 Java、PHP 等不同的語言，且存在環境差異，如依賴 OS、JDK、Nginx 等操作環境，還涉及依賴腳本、基礎環境配置(啟動腳本、定時任務)、目錄結構等。

一旦數據量來臨時，就要統一調配，導致整體的運維和研發效率在環境差異和不同語言下，非常低。這是決定做 Docker 的主要原因。

微博 DCP 技術架構演進

從 2014 年開始，新浪微博做單機容器化和在線 Docker 集群。2015 年，基于 Docker 的思維做彈性調度，服務發現與私有云建設。

2016 年，開始做混合云的部署，當下在做混合云與機器學習的支持，同時混合云 DCP 技術進行開源 OpenDCP：https://github.com/weibocom/opendcp。

混合云 DCP 技術架構

如下圖的 DCP 架構:

DCP 架構底層私有云采用的是基于 OpenStack，公有云是和阿里云合作。整個架構從上到下分為編排、調度和主機三層。

當流量來臨時，主機層通過私有云和公有云的 SDK 進行主機的創建，之后做初始化達到快速上線的目的。初始化主要做運維環境和 Docker 環境的安裝。

初始化之后，編程可運行 Docker 環境，在經過容器調度和服務編排之后，會自動被服務發現模塊引入流量，進行上線。

當然，整個大的體系還需依賴基礎設施，如鏡像中心，監控中心和容量評估等。

混合云 DCP 技術棧

如下圖，是混合云 DCP 技術棧。

Docker 為什么會用 Host 模式?因為微博高并發的特性，在最開始驗證時，性能的消耗非常大，所以選用 Host。

混合云 DCP 核心設計思想

什么是共享池?就是在私有云內部，不同的業務方，在不同的時間內，資源利用率會有所差別，把資源利用率低的共享到共享池，提供給資源利用率高的服務池進行使用。

DCP 大規模集群擴容方式有私有云彈性擴容、公有云彈性擴容和兩者同時彈性擴容。

混合云 DCP 設計的核心思想是如何解決設備從哪里來的問題，當設備到位，如何進行一體化擴容，來快速應對峰值流量。如下圖是具體的設備方案：

具體設備方案是內網共享池+公有云 = BufferPool。如下圖，是 DCP 資源共享示例。

 

混合云 DCP 擴容流程

如下圖，是混合云 DCP 整個擴容流程。

混合云 DCP 整個擴容流程分為主機申請、初始化、動態調度、服務發現和下線五大步驟。

綜上是混合云 DCP 的整個實踐流程，下面主要分享十分鐘內完成 1000 節點擴容能力所帶來的問題，主要涉及基礎設施和彈性調度兩方面。

微博 DCP 之基礎設施

統一資源管理

如下圖，是微博統一資源管理圖。

基礎設施部分，不僅包括內網集群、ECS 集群，SLB 等物理資源，還包括新建 IDC 資源時，所依賴 yum 源，鏡像倉庫、DNSServer 等，從 Docker 層以下都歸類為基礎設施。

單機部署方案

如下圖，是單機部署采用鏡像的方式。

運用 Docker 做統一化部署，把代碼、運維組件、監控組件等全部封裝到容器中，這樣一來，就打通了差異化，不管是 Openstack、還是阿里云機器都可直接使用。

這里遇到一個很大的問題，就是鏡像倉庫。假設一個鏡像是 1G，如果十分鐘之內擴容 1000 臺，那就是 1000G 都需要做鏡像拉取。

但任何一個分布式存儲或鏡像倉庫都無法滿足。微博通過鏡像分層服務、優化帶寬等方法來應對。

鏡像分層服務

把鏡像進行分層，逐層復用。底層部分放入不會變的鏡像，如阿里云、Openstack 的操作系統、JDK、Tomcat 鏡像。這樣做會使得環境構建的速度大大加快，剩下的可變代碼和配置部分只有約三百兆左右。

Docker Registry

根據多次大規模擴容經驗來看，做鏡像分層之后倉庫還是扛不住，帶寬是瓶頸。故構建私有 RegistryHub，在內網和阿里云分別搭建鏡像緩存 Mirror。

如，阿里云端用戶進行擴容時，Docker Client 就可以直接拉取鏡像，而不用穿過內網的 IDC。同時，內網和阿里云的鏡像緩存 Mirror 都支持分布式存儲。

如下圖，是 Docker Registry 部署架構：

通過這樣的架構流程，300 兆的鏡像拉取，500 臺服務器在 1-2 分鐘之內就可以完成。

DCP 中 SLB 的應用

在混合云端，經過實踐經驗，選擇使用 SLB 來做負載均衡。

如上圖，是通過 SLB 做負載均衡的流程，紅包飛業務就是通過 SLB 來做的負載均衡。

DNS 智能解析

如上圖，是 DNS 智能解析流程圖，阿里云所有域名解析都會在阿里云完成，不會穿到內網，這樣一來，加大了域名解析的性能。

專線網絡架構

如上圖，通過路由配置分散兩條專線壓力，可隨時切換。還有 VPN 做備用以及不同業務劃分網段，便于監控專線帶寬的使用情況。

DCP 的彈性擴容

第一步：主機申請

做好鏡像倉庫、SLB 和基礎網絡之后，就可以進行主機申請了。步驟如下：

首選向內網私有云進行申請，如共享池(離線集群，低負載集群，錯峰)不足，再向阿里云申請。

第二步：初始化

主機申請下來之后，進行初始化，具體操作如下圖：

初始化主要做的兩件事情就是運維環境安裝和 Docker 環境安裝。在初始化過程中，阿里云配置管理選擇的是 Ansible，因為 Ansible 并發性能差，初始化流程將需要數分鐘。

但實際情況不允許，所以針對這個問題，我們做了異步列隊、高并發下水平擴容、分布式改造等優化。

微博 DCP 的彈性調度

申請主機，經過初始化之后，批量的 Docer 資源已經進入 Docker 調度池了，接下來要做的事情就是對容器進行調度。

彈性調度是混合云 DCP 整個擴容流程的第三步，是重中之重。

新浪微博的訴求是服務池動態跨池縮容、容量評估，多機型署等，所以資源調度框架架構的設計目標是可以實現快速迭代，內網計算資源統一管理調配，公有云上獲得計算資源，快速自動化資源調度與應用部署。

彈性調度架構的選型

業界很多大會都在講 Swarm、Mosos 和 K8s 這三個彈性調度架構。我們綜合資源利用、業務壓力指標等考量后：

• 初期階段，為了快速上手，響應應用，新浪微博選用 Docker 原生的 Swarm。
• 中期階段，隨著業務發展、Swarm 調度性能、高可用及調度算法表現不足，需要做一系列改造，才能應對當時需求。同時也選擇使用 Mesos 對非容器進行管理。
• 后期階段，因為對 Swarm 的源碼改動太多，所以被放棄。之后底層選用 OpenStack，容器調度方面選用新浪自研的 Dispatch 做任務調度。

任務調度框架 Dispatch

Dispatch 調度框架的主要特點是使用任務模板，主要原因是容器啟動之后，不是簡單的上線，而是要先預熱，對整個容器按步驟進行編排之后再上線。具體編程流程，如下圖：

對每臺機器布設一個 agant，在啟動之后，進行容器編排，經過預熱、健康檢查、服務發現流量、引入等步驟。同時會向主進程進行匯報，匯報過程中進行嚴格批次，按照不同概念去執行。

彈性擴容流程

回顧整個彈性擴容的流程，如下圖：

向混合云平臺發布請求，做資源評估，如私有云資源不足，則向公有云進行申請。之后進行初始化，做容器調度、部署服務，最后進行服務注冊，整個服務要在 10 分鐘之內完成。

微博 DCP 之服務發現

完成申請、初始化、調度之后，進入第四步服務發現，這里要做的是，找到新擴容的節點，做好流量的遷移。

如何把流量快速、安全的切換到彈性節點呢?如下圖：

微博有十幾個嚴格的服務池，這些服務池按照復雜的規則進行劃分。這里涉及到很多服務器的流量調動，所以需要有服務發現體系來支持。

面對 Reload 損耗的問題，開源解決方案大多利用 Nginx 的 Reload 機制。但在請求量方面，普通 Reload 會導致吞吐量下降 10%。微博的應對方案是 nginx-upsync-module，如下圖：

當 Docker 啟動之后，支持基于 Consul 的自動服務發現。同時 Core-module 模塊會從配置中心把 Docker 節點自動拉入，做平滑 reload。這樣一來，可減少擴容時性能的波動。

新浪微博為什么要 OpenDCP?

當下，對于一些創業公司使用 Docker 相比較難，現在乃至未來，微博要把 DCP 整套技術體系進行開源。

由于微博業務的特殊性帶來很大壓力，流量成倍增長，短時間內要擴大到超大規模，會帶來很多技術問題或難點需要應對。開源是希望可以把這些經驗做輸出，使得更多人得以借鑒。

OpenDCP 地址：https://github.com/weibocom/opendcp，在這里也歡迎大家一起來建設。

以上內容由編輯王雪燕根據付穩老師在 WOTA2017 “容器技術實踐”專場的演講內容整理。

[[197474]]

付穩

新浪微博技術專家

微博混合云 DCP 項目技術負責人，借助公有云彈性計算資源平臺應對爆發式峰值流量，基于 Docker、Swarm 等容器云技術體系實現分鐘級千臺規模機器創建及服務部署自動化運維體系。參與微博混合云、Feed 混合云多機房部署改造、微博春晚保障工作、Feed 性能優化、HBase 改造等重量級架構改造項目，對高可用架構、混合云平臺建設、多機房部署、應用性能跟蹤及分析、業務技術保障等方面有深入研究。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】