每逢重要節日，微網誌流量會出現暴漲，<b>2016年春晚，微網誌日活躍使用者達到1.34億，比去年除夕增長31%</b>。在如此大通路量的情況下，後端服務的穩定性和性能保障任務艱巨。面對如此這樣的挑戰，以最低成本實作彈性能力成為了擺在新浪微網誌運維面前的重大挑戰，DCP系統應運而生，DCP系統對外提供的功能包括叢集管理、服務池之間的排程。目前使用DCP系統的業務方涵蓋微網誌的核心業務，主要包括微網誌平台、紅包飛、手機微網誌等。而DCP系統正是通過借助阿裡雲的力量，幫助新浪微網誌實作分鐘級伺服器規模成倍擴容。
<b>“在使用公有雲時，不僅要單單使用公有雲，要将公有雲和專有雲結合使用，最大程度地利用公有雲按需付費的特點，降低機關成本，例如在2016年春晚，微網誌與阿裡雲合作，在流量峰值到來的前幾個小時才部署了相應的公有雲資源。同時業務需要在公有雲與專有雲之間無差異化部署。”</b>
<b>——陳飛</b>
新浪微網誌研發中心技術經理及進階技術專家
<b>新浪微網誌在2016年的春晚通過阿裡雲動态建立了1000多個ECS執行個體，分流了微網誌60%核心流量，整體平均一次擴容的時間小于10分鐘，以超過1億/天的數量新增。</b>
<b>采用的阿裡雲産品</b>
阿裡雲雲伺服器 ECS
阿裡雲彈性伸縮服務 ESS
阿裡雲負載均衡 SLB
阿裡雲對象存儲 OSS
阿裡雲内容分發網絡 CDN
阿裡雲專有網絡 VPC
阿裡雲雲監控
阿裡雲DDoS高防IP (雲盾)
阿裡雲雲資料庫 Memcache
阿裡雲雲資料庫 Redis版
<b>為什麼使用阿裡雲</b>
阿裡雲的規模能夠滿足新浪微網誌峰值流量的需求。
阿裡雲具有值得信賴的高可靠性保障。
阿裡雲的技術人員可以進行支援配合，幫助微網誌的架構的更新。
<b>關于 新浪微網誌</b><b><b>DCP</b>系統</b>
微網誌混合雲平台DCP的核心設計思想，主要是借鑒銀行的運作機制，在内部設立一個計算資源共享池外，既然内部私有雲的需求，又引入了外部公有雲，使其在裝置資源的彈性能力大大提升。而要微網誌實作高彈性排程資源的混合雲架構，其中實作的關鍵則是Docker。剛開始我們思考該使用裸機還是VM架構，發現如果要采用VM，内部機房架構要進行許多改造，這樣成本會更高。是以，目前微網誌的内部私有雲使用裸機部署，而外部公有雲則采用阿裡雲彈性計算服務（ECS）的VM架構。
<b>為什麼選擇阿裡雲？</b>
<b>新浪微網誌DCP混合雲彈性運維排程平台設計概覽</b>
<b>新浪微網誌DCP設計“初心”</b>
DCP是微網誌容器化的混合雲彈性排程運維平台，其誕生初衷是以最低成本實作彈性能力。DCP系統對外提供的功能包括叢集管理、服務池之間的排程。目前使用DCP系統的業務方涵蓋微網誌的核心業務，主要包括微網誌平台、紅包飛、手機微網誌等。
DCP最初的設計目标主要有三點：要具有彈性能力，當時預估在春晚峰值時，需要10分鐘16000核，25600GB的計算資源彈性能力；能夠節約成本，設計之時希望2016年春晚的總體成本不超過2015年，且通過阿裡雲等公有雲按需付費模式，未來可大幅降低機關成本；能提供一個标準的技術平台，拉通不同語言、運作環境差異，向微網誌各個業務系統提供标準的彈性能力。
<b>新浪微網誌DCP混合雲架構設計</b>
當具體去設計這樣一個系統架構時，由于涉及到不同的業務方、不同的部門，各個環節協調還是比較複雜的。是以在架構設計時必須遵循幾個具體的原則：
<b>混合雲政策，</b>在使用公有雲時，不僅要單單使用公有雲，要将公有雲和專有雲結合使用，最大程度利用公有雲按需付費的特點，降低機關成本，例如在2016年春晚，微網誌與阿裡雲合作，在流量峰值到來的前幾個小時才部署了相應的公有雲資源。同時業務需要在公有雲與專有雲之間無差異化部署；
<b>服務化，</b>系統各元件之間通過Restful API而不是原來的運維幹預方式進行通信。這裡要求各元件應具有良好的擴充性，實作機制可插拔；
<b>可伸縮，</b>各系統元件可以根據管理叢集的規模，實作自身的自動伸縮。各元件應無狀态、無單點。運維操作自動化。
<b>DCP架構分層</b>
DCP架構具體分為四層。第一層是不可變基礎設施，Docker的出現很大程度上改變了原有的運維方式，下文将具體介紹在容器化、系統初始化、鏡像分發、帶寬監控方面的實踐經驗。第二層主要完成彈性排程，包括業務跨雲排程、排程機制的建立、容量評估。在已有基礎設施資源前提下，動态合理的配置設定給各個業務節點。第三層主要完成服務發現，在業務彈性部署後，調用方需要快速發現服務叢集分布的節點，通過配置中心、負載均衡、RPC協同快速實作發現機制。第四層主要完成容器編排，包括自動擴容和監控報警。
<b>DCP整體架構設計</b>
上面這張圖是DCP整體架構。架構的最下層是私有雲和阿裡雲的計算資源。各個系統之間通過API互相通信，利用<b>阿裡雲的Open API</b>動态建立所需的計算節點。再上一層是基礎設施管理系統，負責虛機的建立、鏡像的分發等服務抽象和實作，對外提供和專有雲相同的計算環境。再上一層通過Swarm、Mesos實作了業務容器動态排程架構。最上面一層是業務系統。最左邊是一套服務發現架構，該架構是基于Consul叢集建立配置中心，實作服務發現機制。
<b>不可變基礎設施</b>
微網誌在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環境和<b>ECS計算資源</b>準備充分之後，之後的工作就是将業務鏡像進行快速部署。由于單個鏡像的大小在GB級别，如果采用動态拉取的方式，需要幾百台<b>ECS</b>專門做這個任務，大大增加了擴容成本。
微網誌将整個鏡像進行分層，不變基礎鏡像放到雲服務鏡像環境裡面，通過本地Load方式實作鏡像的加載，大大減少了鏡像分發的帶寬需求，同時速度也有一定的提升；另外的一種操作就是反向緩存，突然之間在公有雲上大規模彈性擴容時會面臨冷啟動的問題，即公有雲上不存在相應的業務鏡像，拉去業務變更的鏡像會占用大量專線帶寬。為了應對這種情況，在公有雲上常态化部署對專有雲Registry反向緩存，對專有雲Registry内部變更和推送、配置都會同步到公有雲的反向緩存節點上。此外也實作分發網絡可自動伸縮。未來應對超過千萬級别規模，微網誌正在嘗試采用P2P進行分發。
<b></b>
<b>DCP的混合雲網絡架構</b>
在混合雲中，最核心的就是整個網絡架構。打通公有雲和私有雲時，網絡環境、IP規劃等問題都應該慎重考慮。目前微網誌采用<b>阿裡雲的VPC</b>服務，建構公有雲與專有雲一緻的網絡環境。另外，采用多專線確定網絡高可用。路由方面，通過在核心交換上配置路由轉發規則，采用就近原則，最大程度減少路由跳數，保證網絡低延遲，當網絡故障時，自動啟動備份路由。
同時基于原有的帶寬監控，實作跨雲專線監控，細化到IP級别，根據每台<b>ECS</b>的IP自動彙聚到對應的産品線，監控其整體帶寬消耗情況，確定各個業務産品線實際單寬占用不會影響。
<b>彈性排程</b>
不可變基礎設施的部署完成後，就已經具備了在公有雲上建立大規模<b>ECS</b>計算節點的能力。接下來面臨的問題就是如何将業務合理排程到計算節點上。跨雲業務部署時，應該使得業務以最小規模部署，在公有雲上通過預付費方式，常态化部署業務的最小規模，并提供線上服務。另外應該盡量減少跨雲專線的調用，保持帶寬在可控範圍之内，需要将業務後端資源Memory Cache等Loacl化，減少跨專線請求；一旦發生跨專線請求時，需要開啟一些流量壓縮的協定。同時，微網誌内部通過WMB緩存資料雙向同步機制，基于消息分發政策，在專有雲内部對緩存的讀寫以消息的方式同步到公有雲的緩存上，延遲一般在毫秒級，同時在專線出現異常時，消息不會丢失，做到高可用。
<b>新浪微網誌業務混合雲部署形态</b>
上圖是2016年春晚上典型的業務混合雲部署形态。内部是典型的後端網際網路服務技術站，通過四層的負載，通過Nginx實作七層負載，再往後是一些WEB層的計算和RPC服務，最下面是緩存層的資源、資料庫。由于資料庫的請求量和資料安全要求比較高，是以暫時沒有将DB層放到公有雲上。架構的最右側是采用了<b>SLB</b>服務、之下的RPC、WEB、Nginx都是部署在<b>ECS</b>上的。
<b>彈性排程機制</b>
在具體的彈性排程架構上采用了開源的解決方案，例如Swarm、Mesos等。在它們的基礎上封裝了統一排程的API，将原來專有雲内分散的各個應用平台統一到一起，大大節省在基礎運維上的時間成本。
通過線上容量評估，決策某一個服務是否需要在公有雲上擴容。通過選取服務的多個業務上的名額來綜合評價某一個業務是否存在流量突增或者性能的瓶頸。比如采集平均響應時間和QPS、内部計算資源線程池，最終計算出總體資源池的備援百分比，用于決策是否需要動态擴容。
<b>編排與容器發現</b>
業務部署到阿裡雲之後，需要快速地将業務提供方與調用方快速地銜接起來，就需要編排和容器發現的機制。在實作DCP系統環節内部可能存在微網誌内部其他的系統，比如原有的運維系統、釋出系統、監控系統等等。這些原有的系統内部需要打通，這也是業務編排的核心任務。另外一個問題就是實作自動化，擴容一台完整的微網誌後端業務大概需要上百步的操作，通過自動化操作避免了資料不一緻問題的出現。還有一些服務發現的機制，原來通過管理者配置的服務發現機制對上千規模的彈性業務節點管理起來成本較高。
上面這張圖是微網誌自動擴容的具體流程。首先預測流量到來時，向DCP系統發出指令進行擴容。DCP平台首先向共享池或公有雲申請資源，進行資源配額子產品後，在經過初始化，進入排程中心。在排程中心中根據服務之間的依賴關系，在公有雲上啟動該服務，比如需要先啟動緩存的服務，才能再啟動RPC服務，再啟動WEB前端的服務，最後再啟動應用的PHP服務。服務啟動後需要向Consul叢集進行服務注冊和服務健康的檢查。
對于服務發現，業界通用服務發現機制是基于Nginx Reload本地檔案來實作服務發現。這種服務發現實作管理成本高，并且不支援并發注冊，會帶來性能損耗。目前微網誌采用基于Consul配置中心實作自動發現服務，解決了Reload的性能問題。
對于資源的動态發現，原有的方式是将後端緩存、Redis等資源的配置放在配置架構中進行，在增加<b>阿裡雲RDC</b>時會導緻配置檔案快速膨脹。現在，微網誌采用将配置同步到Consul叢集的方式，通過域名動态解析阿裡雲上資源IP變更，無需變更業務代碼，對整體的彈性伸縮帶來了很大的便利。
原文釋出日期：2016-04-05
雲栖社群場景研究小組成員：賈子甲，仲浩。