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

[[197472]]

在 2016 年，微博完成了利用 Docker 構(gòu)建混合云架構(gòu)，本文將分享安全、網(wǎng)絡(luò)、資源管理、調(diào)度管理、跨云服務(wù)發(fā)現(xiàn)等方面的一些實踐經(jīng)驗。

新浪微博龐大的數(shù)據(jù)背后是持續(xù)不斷的技術(shù)挑戰(zhàn)

微博的數(shù)據(jù)量，在國內(nèi)的社交媒體中排行位居前列。如下圖：

百億級 PV、千億級數(shù)據(jù)、萬臺以上的服務(wù)器規(guī)模、數(shù)百以上服務(wù)模塊、千臺以上的 Docker 混合云集群等等，這些龐大數(shù)據(jù)背后，是持續(xù)不斷的技術(shù)挑戰(zhàn)。

在如此大的業(yè)務(wù)體系下，業(yè)務(wù)流量有很明顯的特征：

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

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

如何在十分鐘內(nèi)完成 1000 節(jié)點擴容能力

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

如下圖，是應(yīng)對極端峰值問題的解決思路。

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

新浪微博 DCP 設(shè)計與實現(xiàn)

Docker化

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

一旦數(shù)據(jù)量來臨時，就要統(tǒng)一調(diào)配，導(dǎo)致整體的運維和研發(fā)效率在環(huán)境差異和不同語言下，非常低。這是決定做 Docker 的主要原因。

微博 DCP 技術(shù)架構(gòu)演進

從 2014 年開始，新浪微博做單機容器化和在線 Docker 集群。2015 年，基于 Docker 的思維做彈性調(diào)度，服務(wù)發(fā)現(xiàn)與私有云建設(shè)。

2016 年，開始做混合云的部署，當(dāng)下在做混合云與機器學(xué)習(xí)的支持，同時混合云 DCP 技術(shù)進行開源 OpenDCP：https://github.com/weibocom/opendcp。

混合云 DCP 技術(shù)架構(gòu)

如下圖的 DCP 架構(gòu):

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

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

初始化之后，編程可運行 Docker 環(huán)境，在經(jīng)過容器調(diào)度和服務(wù)編排之后，會自動被服務(wù)發(fā)現(xiàn)模塊引入流量，進行上線。

當(dāng)然，整個大的體系還需依賴基礎(chǔ)設(shè)施，如鏡像中心，監(jiān)控中心和容量評估等。

混合云 DCP 技術(shù)棧

如下圖，是混合云 DCP 技術(shù)棧。

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

混合云 DCP 核心設(shè)計思想

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

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

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

具體設(shè)備方案是內(nèi)網(wǎng)共享池+公有云 = BufferPool。如下圖，是 DCP 資源共享示例。

混合云 DCP 擴容流程

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

混合云 DCP 整個擴容流程分為主機申請、初始化、動態(tài)調(diào)度、服務(wù)發(fā)現(xiàn)和下線五大步驟。

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

微博 DCP 之基礎(chǔ)設(shè)施

統(tǒng)一資源管理

如下圖，是微博統(tǒng)一資源管理圖。

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

單機部署方案

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

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

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

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

鏡像分層服務(wù)

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

Docker Registry

根據(jù)多次大規(guī)模擴容經(jīng)驗來看，做鏡像分層之后倉庫還是扛不住，帶寬是瓶頸。故構(gòu)建私有 RegistryHub，在內(nèi)網(wǎng)和阿里云分別搭建鏡像緩存 Mirror。

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

如下圖，是 Docker Registry 部署架構(gòu)：

通過這樣的架構(gòu)流程，300 兆的鏡像拉取，500 臺服務(wù)器在 1-2 分鐘之內(nèi)就可以完成。

DCP 中 SLB 的應(yīng)用

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

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

DNS 智能解析

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

專線網(wǎng)絡(luò)架構(gòu)

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

DCP 的彈性擴容

第一步：主機申請

做好鏡像倉庫、SLB 和基礎(chǔ)網(wǎng)絡(luò)之后，就可以進行主機申請了。步驟如下：

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

第二步：初始化

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

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

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

微博 DCP 的彈性調(diào)度

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

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

新浪微博的訴求是服務(wù)池動態(tài)跨池縮容、容量評估，多機型署等，所以資源調(diào)度框架架構(gòu)的設(shè)計目標(biāo)是可以實現(xiàn)快速迭代，內(nèi)網(wǎng)計算資源統(tǒng)一管理調(diào)配，公有云上獲得計算資源，快速自動化資源調(diào)度與應(yīng)用部署。

彈性調(diào)度架構(gòu)的選型

業(yè)界很多大會都在講 Swarm、Mosos 和 K8s 這三個彈性調(diào)度架構(gòu)。我們綜合資源利用、業(yè)務(wù)壓力指標(biāo)等考量后：

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

任務(wù)調(diào)度框架 Dispatch

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

對每臺機器布設(shè)一個 agant，在啟動之后，進行容器編排，經(jīng)過預(yù)熱、健康檢查、服務(wù)發(fā)現(xiàn)流量、引入等步驟。同時會向主進程進行匯報，匯報過程中進行嚴(yán)格批次，按照不同概念去執(zhí)行。

彈性擴容流程

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

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

微博 DCP 之服務(wù)發(fā)現(xiàn)

完成申請、初始化、調(diào)度之后，進入第四步服務(wù)發(fā)現(xiàn)，這里要做的是，找到新擴容的節(jié)點，做好流量的遷移。

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

微博有十幾個嚴(yán)格的服務(wù)池，這些服務(wù)池按照復(fù)雜的規(guī)則進行劃分。這里涉及到很多服務(wù)器的流量調(diào)動，所以需要有服務(wù)發(fā)現(xiàn)體系來支持。

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

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

新浪微博為什么要 OpenDCP?

當(dāng)下，對于一些創(chuàng)業(yè)公司使用 Docker 相比較難，現(xiàn)在乃至未來，微博要把 DCP 整套技術(shù)體系進行開源。

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

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

以上內(nèi)容由編輯王雪燕根據(jù)付穩(wěn)老師在 WOTA2017 “容器技術(shù)實踐”專場的演講內(nèi)容整理。

[[197474]]

付穩(wěn)

新浪微博技術(shù)專家

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

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】