做為目前最火的國内社交app，微網誌常常在特定時間或特定事件發生時迎來流量高峰。通過對近五年時間應對的峰值進行總結，可以抽象為三種常見的峰值：
第一種是日常的晚高峰；
第二種是各種營運活動以及明星、大v的熱門微網誌所帶來的流量高峰；
第三種是非常極端的突發事件導緻的核心服務數倍的流量增長。
之是以需要關注這三類場景，主要是因為：
第一，盡管微網誌的功能衆多，但備援是非常少的，是以早晚高峰需要彈性擴容；
第二，活動、大v的熱點事件能夠提前預知，可以提前準備所需資源；
第三，極端事件是最需要關注的，它對系統的自動化程度要求非常高。
這三類場景可以簡單總結為兩大特點：瞬間峰值高、互動時間短。
在應對流量峰值時，微網誌面臨着以下三點挑戰：
産品疊代快，目前微網誌的現狀是功能多，依賴複雜，導緻釋出和變更頻繁；
營運上，站内外，活動、營運、大v均有push場景，導緻全量極速下發，互動時間短；
技術上存在突發的極端流量，目前熱點多，“馬航”、“王寶強”等事件十分考驗服務的彈性伸縮。
那麼在應對流量峰值時，應該主要關注哪些方面呢？
第一點是快速擴容、及時回收，這考驗的是系統的彈性擴容、峰值應對的能力，這也是系統設計的最核心的目标；
第二點要注意成本優化，可伸縮的業務利用公有雲，私有雲内彈性部署；
第三點是運維标準化，微網誌流量來源主要是pc端和移動端，但兩者的開發語言是不同的，是以系統需要打通多語言環境，通過docker實作全公司統一平台；
第四點，由于業務疊代快速疊代，是以基礎設施需要标準化，以供公有雲和私有雲使用。
傳統的峰值應對手段第一步需要裝置申請，項目評審；第二步需要入cmdb，上架裝機；之後需要裝置錄入資源池，機器初始化；第三步需要運維人員進行服務部署，包括環境、監控、服務部署和流量引入；當流量峰值下降時，還需要服務自動下線以及裝置置換或下架。整個鍊路十分冗長，大部分操作需要人工介入，而且依賴于企業内不同部門互相配合，在業務快速發展的今天，傳統應對峰值的手段顯然已經過時。
目前，微網誌采用的是dcp的彈性伸縮方案來應對流量峰值，具體架構如上圖所示。架構内部主要采用私有雲，早期采用實體機部署，通過化零為整建立備援池；此外通過openstack+kvm的虛拟化方式進行資源整合，建立vm池。在公有雲方面，通過采用阿裡雲等設施進行多雲對接。
建立統一的裝置資源管理池後，下一步需要考慮的是服務部署、資源排程等問題。目前，微網誌采用的是基于docker的雲化架構：
業務上，由于部分業務并非無縫遷移到該架構上，這時需要對業務進行微服務化、消息化等改造；
平台上，需要部署靈活基礎設施，打通持續內建平台以及實作多租戶隔離、彈性伸縮、故障自愈等能力。
除了公有雲具有彈性伸縮能力之外，私有雲也可以具有彈性。公司内某個部門可能就有很多業務，如果每個業務都保留很多備援則會導緻資源的大量閑置浪費。微網誌采用的是将每個業務的備援拿出來放到共用的共享池内，當業務有需求時，從共享池内申請備援；使用完成後歸還申請的伺服器，通過這種方式實作私有雲的彈性伸縮。
在應對流量峰值時，除了上面提到的彈性伸縮系統，還需要統一的監控平台、核心鍊路服務自動伸縮、預案&幹預手段互相配合，以保障峰值服務正常運作。
下面是微網誌的dcp整體架構圖。
最底層是實體主機資源；第二層是資源排程層；第三層是編排層，主要包括一些常見的自動化操作；最上層是業務層，由多種語言混合開發；架構的右側是主要的基礎設施。
在架構設計中面臨的核心挑戰主要包括以下三點。
鏡像分發，包括鏡像優化和分發速度的優化；
隔離設計，包括平台層隔離和部署/執行個體隔離；
彈性伸縮，包括自動擴縮容和故障轉移。
下面分别進行說明。
鏡像分發的挑戰，主要有鏡像優化和分發速度的優化。
鏡像優化主要從兩點入手：一是鏡像制作優化；二是倉庫部署優化。在鏡像制作時，采用鏡像分層，逐層複用，其次制作一些微鏡像，用于分發速度提高。倉庫部署優化，當業務叢集通路registry時，從早期的本地存儲鏡像改進為分布式存儲，同時在阿裡雲上部署大量鏡像緩存mirror。
由于彈性伸縮大部分是在公有雲上實作的，是以對鏡像請求最大的也是在阿裡雲上，通過在阿裡雲上以級聯的方式部署大量的mirror，加快鏡像分發速度。
正常情況下，部署幾台mirror即可，當彈性擴縮容時，将registry橫向擴容，作為業務擴容的依賴，業務擴容根據一定的配比關系，先将registry進行擴容以及鏡像的預熱。這其中優勢在于：
将registry進行分級部署，常時隻部署一部分，擴容時進行大批量橫向部署；
将每一個registry的帶寬優化，這是因為mirror是部署在ecs上，而ecs單機的pps和帶寬都是有一定限制的。
整體架構的目标是實作分發速度千台規模分鐘級，未來的方向是在擴容層面支援p2p的鏡像拉取方式。
隔離設計的挑戰，主要有平台層隔離和部署/執行個體隔離。我們主要做了如下幾個方面的工作。
隔離又分為平台上隔離、部署上隔離和執行個體上隔離三種。平台上隔離是指一個叢集對應一個部門，例如微網誌平台、紅包飛等有各自對應的大叢集，内部的業務在下一級進行隔離；部署上隔離是指同一業務需要在不同機房部署，例如一個feed業務在幾個内部機房都有部署；執行個體上隔離主要是指cpu、mem等通用的資源上進行隔離。隔離模型的右側是資源共享池，作為全局共享池和叢集buffer池。
在隔離模型中，平台層設計如上圖所示。最上層用于接入業務，根據業務模型去定制一類的擴縮容、job操作，如java類、php類、大資料類；其次對外提供了豐富的gui頁面以及rest api用于使用者操作。
接入層之下是平台層設計的最核心的部分。如上文所講，一個産品線對應一個叢集，将産品線上的業務場景抽象成定制化的模闆、原子型api、任務執行個體和環境變量，然後再進行隔離設計，形成産品線的擴縮容流程。在底層的單個節點上采用根容器存放業務中通用的部分，如系統資源的監控。
由于對平台進行了隔離設計，為不同的管理者規定了不同的操作範圍。在系統中，管理者主要分為超級管理者、叢集管理者、服務池管理者三種，三種管理者的操作權限如上圖所示，這裡不再一一叙述。
彈性伸縮的挑戰，主要有自動擴縮容和故障轉移。我們做了如下幾個方面的工作。
在應對流量峰值時，單單依靠管理者進行人工操作是遠不夠的，是以“無人值守”的自動化擴縮容顯得十分必要。要實作“無人值守”的擴縮容，首先内部的工具系統需要實作自動化，各系統之間通過api打通，實作全部系統間的關聯。
運維自動化包含業務名額和容量名額監控，将産生的資料提供給容量決策系統，在容量決策系統的決策下，實作從運維自動化進化為無人值守的擴縮容。
“無人值守”的三個核心在于彈性伸縮、故障遷移和服務自動回收，與之對應的是模闆中原子型api（平台提供了第一版可用的原子型api，業務方也可以自定義所需的原子型api）。
如上圖所示，在平台擴容時管理者需要向混合雲平台發起請求；平台進行資源評估，如果配額足夠，可以按照配額量申請；如果配額不夠時，需要申請配額，防止資源濫用。
當申請到裝置之後，需要調用系統内部的基礎設施、配管系統等進行初始化操作，然後在排程中心發起容器排程、部署服務，服務部署之後會注冊到consul叢集中。如果服務想對外提供服務，還需要将其接入統一負載均衡系統中，進行服務發現。最後一步需要添加監控中心。
要将上述步驟自動化，需要将這些步驟抽象成原子型api任務，然後在這些任務之上進行自動化模闆設計。
原子型api任務是通過原子型api任務系統dispatch完成的，它是由新浪自主研發的，采用c++編寫，它在每個機器上都有一個agent，在中心化元件dispatch端根據任務模闆定義任務，具體的任務細節在任務腳本中設計，最終對外提供成api。
目前有兩種容量決策方式：第一種是定時觸發，根據自動壓測的名額、資料、經驗值觸發進行；第二種是自動進行，通過分析業務名額，對容量預估，進行同比、環比分析自動進行擴縮容操作。
上圖是定時觸發和自動觸發的排程編排圖，所有的資料存入consul叢集，通過crontrigger子產品定時檢測是否有新任務産生，當有新任務産生時，通過scheduler元件進行詳細操作，最終對接服務發現系統。系統的輸入是容量決策的資料，輸出是擴容之後的業務池。
業務上雲時，需要考量以下四點：
安全上，如何解決敏感資料的存儲問題；
部署上，如何解決業務依賴問題；
資料上，如何實作資料同步；
自動化，如何實作彈性伸縮。
目前的上雲标準姿勢有兩種：一是混合雲；二是xaas。
在混合雲架構中，核心關鍵是專線，它是實作内部與公有雲之間彈性的核心。目前微網誌和阿裡雲之間已經拉通了多條專線，日常的核心消息通過多機房的消息元件同步到阿裡雲緩存中，實作前端層面和緩存層面的彈性伸縮。
在混合雲的模式下，微網誌目前采用了兩種部署方案。
第一種，除db不在阿裡雲部署，其他整個鍊路全部部署在阿裡雲上。
第二種部署方案無需在阿裡雲上啟用slb、nginx等服務，直接把阿裡雲中啟用的容器放在内部的四/七層服務中。目前在微網誌中，主要使用第二種部署方案。