微博：春節日活躍用戶超一億，探祕如何實現服務器分鐘級擴容

本次由微博研發中心技術經理及高級技術專家陳飛分享了微博利用阿里雲實現分鐘級服務器規模成倍擴容的技術體系，包括Docker與虛機結合的使用經驗、網絡架構以及負載均衡、緩存架構的跨IDC服務部署的一些經驗。本次視頻直播的整理文章、視頻、幻燈片整理完畢，以下內容。

直播視頻：http://click.aliyun.com/m/6360/

幻燈片下載地址： http://click.aliyun.com/m/6360/

DCP設計「初心」

圖一 DCP設計初心

 

DCP是微博容器化的混合雲彈性調度運維平臺，其誕生初衷是以最低成本實現彈性能力。DCP系統對外提供的功能包括集羣管理、服務池之間的調度。目前使用DCP系統的業務方涵蓋微博的核心業務，主要包括微博平臺、紅包飛、手機微博等。

DCP最初的設計目標主要有三點：

1. 要具備彈性能力，當時預估在春晚峯值時，須要10分鐘16000核，25600GB的計算資源彈性能力；
2. 可以節約成本，設計之時但願2016年春晚的整體成本不超過2015年，且經過阿里雲等公有云按需付費模式，將來可大幅下降單位成本；
3. 能提供一個標準的技術平臺，拉通不一樣語言、運行環境差別，向微博各個業務系統提供標準的彈性能力。

DCP混合雲架構設計

圖二 DCP混合雲架構設計原則

 

當具體去設計這樣一個系統架構時，因爲涉及到不一樣的業務方、不一樣的部門，各個環節協調仍是比較複雜的。所以在架構設計時必須遵循幾個具體的原則。

1. 在使用公有云時，不只要單單使用公有云，要將公有云和專有云結合使用，最大程度利用公有云按需付費的特色，下降單位成本，例如在2016年春晚，微博與阿里雲合做，在流量峯值到來的前幾個小時才部署了相應的公有云資源。同時業務須要在公有云與專有云之間無差別化部署；
2. 服務化，系統各組件之間經過Restful API而不是原來的運維干預方式進行通訊。這裏要求各組件應具備良好的擴展性，實現機制可插拔；
3. 可伸縮，各系統組件能夠根據管理集羣的規模，實現自身的自動伸縮。各組件應無狀態、無單點。運維操做自動化。

圖三 DCP架構分層

 

DCP架構具體分爲四層。第一層是不可變基礎設施，Docker的出現很大程度上改變了原有的運維方式，下文將具體介紹在容器化、系統初始化、鏡像分發、帶寬監控方面的實踐經驗。第二層主要完成彈性調度，包括業務跨雲調度、調度機制的創建、容量評估。在已有基礎設施資源前提下，動態合理的分配給各個業務節點。第三層主要完成服務發現，在業務彈性部署後，調用方須要快速發現服務集羣分佈的節點，經過配置中心、負載均衡、RPC協同快速實現發現機制。第四層主要完成容器編排，包括自動擴容和監控報警。

圖四 DCP總體架構

 

上面這張圖是DCP總體架構。架構的最下層是私有云和阿里雲的計算資源。各個系統之間經過API相互通訊，利用阿里雲的Open API動態建立所需的計算節點。再上一層是基礎設施管理系統，負責虛機的建立、鏡像的分發等服務抽象和實現，對外提供和專有云相同的計算環境。再上一層經過Swarm、Mesos實現了業務容器動態調度框架。最上面一層是業務系統。最左邊是一套服務發現框架，該框架是基於Consul集羣創建配置中心，實現服務發現機制。

接下來，對各個層的實現進行詳細剖析。

 

不可變基礎設施

 

微博在15年春晚就開始嘗試Docker技術，當時目的是讓業務與宿主機的運行環境解耦。Docker解決了業務對運行軟件的版本、組件需求，將這些依賴關係封裝到Docker Image中，統一了私有云、公有云之間及不一樣業務線之間的交互標準。

圖五 容器化

DCP對業務層提供了十分標準的基礎運行環境。底層選用ECS的CentOS7.1.1503的鏡像，在此之上是Docker的Devicemapper-direct-lvm文件承接系統，版本選擇是Docker 1.6.2版本。中間層是調度框架的實現，使用的是Mesos 0.25和Swarm 1.0.0版本，以及一些容器級別的監控，如貢獻給開源社區的cAdvisor 0.7.1.fix。PHP和Java對應不一樣的後端應用，微博的核心Feed、用戶關係等基礎服務都是用Java實現，偏業務性的系統是用PHP來實現。對應於Java和PHP的Docker體系是一致的，只是其中使用的版本不一樣，在Docker 1.3.2版本中須要兼容一些離線計算平臺。目前Java和PHP底層運行環境已經實現歸一化。

圖六 初始化

 

有了容器化的無差別運行環境以後，在阿里雲上分鐘級完成上千個計算節點的彈性擴容還須要進行性能優化。首先各Stage儘量並行化，目前可實現4分鐘內初始化上百臺能力。同時經過Ansible的Callback機制，把耗時操做異步化。此外，使用Ansible自動伸縮功能，根據初始化需求規模自動伸縮，可支持分鐘內千萬級別初始化能力。

圖七 鏡像分發

 

在Docker環境和ECS計算資源準備充分以後，以後的工做就是將業務鏡像進行快速部署。因爲單個鏡像的大小在GB級別，若是採用動態拉取的方式，須要幾百臺ECS專門作這個任務，大大增長了擴容成本。

微博將整個鏡像進行分層，不變基礎鏡像放到雲服務鏡像環境裏面，經過本地Load方式實現鏡像的加載，大大減小了鏡像分發的帶寬需求，同時速度也有必定的提高；另外的一種操做就是反向緩存，忽然之間在公有云上大規模彈性擴容時會面臨冷啓動的問題，即公有云上不存在相應的業務鏡像，拉去業務變動的鏡像會佔用大量專線帶寬。爲了應對這種狀況，在公有云上常態化部署對專有云Registry反向緩存，對專有云Registry內部變動和推送、配置都會同步到公有云的反向緩存節點上。此外也實現分發網絡可自動伸縮。將來應對超過千萬級別規模，微博正在嘗試採用P2P進行分發。

 

圖八 混合雲網絡架構

 

在混合雲中，最核心的就是整個網絡架構。打通公有云和私有云時，網絡環境、IP規劃等問題都應該慎重考慮。目前微博採用阿里雲的VPC服務，構建公有云與專有云一致的網絡環境。另外，採用多專線確保網絡高可用。路由方面，經過在覈心交換上配置路由轉發規則，採用就近原則，最大程度減小路由跳數，保證網絡低延遲，當網絡故障時，自動啓動備份路由。

同時基於原有的帶寬監控，實現跨雲專線監控，細化到IP級別，根據每臺ECS的IP自動匯聚到對應的產品線，監控其總體帶寬消耗狀況，確保各個業務產品線實際單寬佔用不會影響。

更多內容及QA環節，請前往>> http://click.aliyun.com/m/6360/

 

關於分享者

 

陳飛，微博研發中心技術經理及高級技術專家。目前在微博負責Feed用戶關係和容器化相關工做，致力於Docker技術在生產環境中的規模化應用。

 

微博在2016年的春晚動態建立了1000多個ECS實例，分流了微博60%核心流量，總體平均一次擴容的時間小於10分鐘，以超過1億/天的數量新增。