之前微博曾披露過他們已經遷移到基于Docker容器的混合云平臺DCP,那對于這樣的突發熱點,DCP是如何應對的?Docker容器可以進行秒級擴容,那為什么還會有短暫的服務被打死情況發生?DCP整個的彈性伸縮流程是怎么樣的?帶著這些問題,InfoQ記者采訪了微博Container平臺彈性伸縮負責人王關勝.

奧運期間熱點事件對微博服務的沖擊

奧運期間因為王寶強的離婚事件,讓微博的流量大增,甚至部分服務被短暫打死.詳細情況是怎樣的?

王關勝：自16年里約奧運會開幕式開始,微博整體流量增幅明顯,相較于往常增長數倍,造成了白天跟日常晚高峰一樣的持續峰值場景.更甚的是,奧運期間還有賽事的熱點及明星事件的沖擊,給微博平臺的服務帶來數倍于日常峰值的流量請求.

其中在孫楊PK霍頓、奧運網紅傅園慧的“洪荒之力”、王寶強事件、女排奪冠等熱點中,尤以寶強事件的影響最為巨大.大家可以去看一下寶強發布離婚聲明的微博互動數據,非常驚人；再來看看流量數據：

圖1：微博,評論及Feed業務量

圖2：話題業務量

可以看到,這次事件對微博的核心服務如Feed、評論、話題等帶來的壓力都是成倍的,已經超過16年春晚,為歷史新高點.仔細分析一下,可以發現這種事件基本可以分為：發生期、發酵期、暴漲期、緩解期.

而暴漲期一般都是內部運營部門的push引來爆點,此時對于服務的容量冗余要求極高,雖然DCP已經彈性擴容了大批Container,但Java的服務初啟動,會有線程池及連接資源預熱的過程,此時會有一點慢的現象,也可以理解為瞬時流量短暫打死.

微博目前用戶基數龐大,DAU和MAU均為數億.從整個技術體系來看,微博核心總體分為端和后端平臺,端上主要是PC端,移動端,開放平臺以及企業開放平臺.后端平臺主要是Java編寫的各種接口層、服務層、中間件層及存儲層.除此之外,微博搜索、推薦、廣告、大數據平臺也是非常核心的產品.從業務角度看,整體架構圖如下：

我們團隊主要負責的微博平臺的業務與保障,平臺在2015年的部署架構如下：

就平臺前端來說,每日超過千億次的API調用、超過萬億的RPC調用,產生的日志就達百T+.對于這么大體量的業務系統,對于運維的要求也很嚴格；就接口層來說,SLA必須達到4個9,且接口平均響應時間不能高于50ms.因此我們會面臨各種各樣的挑戰.

當時面對這樣的突發情況,新浪微博是如何應對的?有哪些是沒有考慮的的情況?

王關勝：微博對于服務的穩定性要求很高,在奧運開始前,微博平臺已經啟動了線上服務保障相關的準備工作,也建立了奧運期間的早晚班值班機制,以防止突發情況出現.在日常的峰值場景中,微博的混合云DCP平臺可以做到無人值守的進行服務的彈性伸縮.

從熱點事件的業務流量圖可以看出：到達爆點之前一般會有發酵期,而我們的容量決策系統會實時的監測業務量變化,根據服務冗余情況決定是否自動伸縮,再根據一定的配比去彈性擴容,

縮容.當寶強事件爆點出來時,DCP已經提前擴容了一批業務container,但是讓我們沒想到的是業務量來的是如此之快,如此之高,加上瞬間的流量請求對于后端資源的預熱,需要一點時間,部分服務出現短暫的超時,我們迅速對于非核心功能啟動了無損降級,服務很快恢復.

當然,在應對這種熱點事件時,我們已經很嫻熟了,都會準備很多的預案,比如降級、限流、切流量等干預手段.

王關勝：微博平臺大概14年開始研究Docker,14年底就Docker化了一些服務,并基于內部的基礎設施上線了第一版的Docker工具平臺,在15年春晚也發揮了作用.

但是這版的工具平臺有很大的限制：我們內網的物理機設備冗余比較少,自動擴容的能力有限.基于此,我們開始探索公有云,并于2015年基于公有云的彈性能力加上私有云一起構建混合云DCP.通過與阿里云的合作,微博實現了從提前部署擴容到實時擴容的升級,并能達到10分鐘彈性擴容上千節點的能力.

如果要說DCP的優勢的話,我覺得最核心的就兩點：

首先,微博平臺的業務已經完全Docker化,基于Docker的特性,解決了環境差異性問題,使得標準化變得容易.其次,基于公有云,使得我們的服務的彈性能力大大加強,再也不用提前購買服務器,進行漫長的部署過程了.

DCP混合云系統的設計理念,總共包含4個核心概念：彈性伸縮、自動化、業務導向以及專門為微博訂制.混合云系統必須有彈性調度的運算能力.而DCP混合云系統并不是對外公開的產品化服務,必須以業務需求出發,因此會有包含許多微博定制的功能.

DCP系統最核心的3層架構：主機層、調度適配層及編排層：

1) 主機層

主機層的核心是要調度運算資源.目前設計了資源共享池、Buffer資源池,配額管理,及多租戶管理機制,借此實現彈性調度資源.

2)調度層：

而調度層則通過API,把調度工具用API進行包裝,而微博4種常用的調度工具組合包含：原生Docker、Swarm、Mesos及微博自主開發的Dispatch.

最上層的則是負責業務編排及服務發現.目前,微博的后端服務95%是Java環境,而PC端則是使用PHP編寫,移動端則是通過調用API服務.這些業務方都將會接入DCP.編排層也包括了大數據工具Hadoop,進行大數據分析的業務場景.

我們知道,對于調度來說,最重要的就是資源管理,Mesos處理這個是最合適不過了,很多公司就專用其做資源管理,比如Netflix寫了一個Titan的調度服務,其底層資源管理則是通過Mesos.當然我們的調度組件中,使用最多的還是Swarm、Dispatch.

我們可以看下面這個場景：這也是私有云內部資源流轉的最佳實踐：

當業務A多余的運算資源導入混合云共享池時,此時流量暴漲的業務C,可從共享池調度業務A的運算資源；峰值事件后,便可以把多余的運算資源歸還至共享池.

3)業務編排層

這層主要根據業務場景模型,通過主機層、調度層的API,創建可編排的任務模型,如集群管理、服務管理、服務池管理、鏡像管理、構建管理、負載均衡管理、擴縮容管理等.

從使用角度出發,我們主要劃分了集群、服務池、設備Buffer等層次,以IP+Port唯一標識服務.如下圖：

其中：在DCP下可以創建多個集群,每個集群為獨立平臺或產品線,如微博平臺、紅包飛、手機微博等.集群間相互獨立,集群內各自的服務可自由調度,集群外的調度則設置了配額機制.在集群下,可以創建服務池,一般為同一業務的同構服務.主機只有進了集群的Buffer中,才可能被用來部署服務.

DCP對于物理主機的流轉,基于資源共享池、Buffer資源池、配額管理,及多租戶管理機制,還是非常復雜的,這里我們可以看一下一臺物理主機的生命周期(狀態流轉圖)

王關勝：DCP系統最核心的是彈性伸縮,能根據容量情況進行自動的彈性伸縮,以此來解決明顯的早晚高峰及熱點事件的峰值問題.

DCP第一版時,我們做到了擴縮容的自動化,但未能自動伸縮,需要人的參與,而且也會有幾個操作步驟,人本身是懶惰的且是易犯錯的,且還會存在人力成本,這還沒達到我們的目標,離無人值守還差一段距離,于是,我們又開發了兩個模塊：

• 容量決策系統：可以每周在線壓測服務,評估出每個服務的容量數據,以供決策；
• 調度框架：在任務之上,采用基于時間段的調度策略,在業務訪問低峰時執行縮容策略, 高峰來臨前執行擴容策略.

整個自動伸縮框架如下：

其核心的特性：如支持各種調度策略,根據業務流量及服務冗余情況,提供基于時間的調度方式,類似crontab觸發機制,Chronos、 Quartz提供可借鑒的任務調度實現機制；支持服務的依賴,A服務依賴B,B在自動彈性擴容時,需擴容好服務B.

這樣,整個服務就可以彈性伸縮了.

王關勝：目前微博混合云DCP平臺包含很多核心功能,如服務管理、多云對接、鏡像市場、彈性調度、彈性擴縮容、服務發現、監控、容量決策等,這些已經可以全部聯動,自動的去彈性來做.而應對峰值事件時,對于準備的預案,如降級,切流量這些,還需要人工的參與.

一般而言,面對瞬間高壓,系統會采用“降級非核心及周邊業務”.那么微博有沒有對哪些業務進行降級呢?在突發熱點事件的這種情況下,“核心應用”和“周邊業務”分別是哪些?微博是否準備的降級策略?

王關勝：首先介紹一下微博的架構,微博主要分為后端和前端；前端主要是各種端(PC端和移動端)以及內部第三方(搜索、推薦、廣告等),而后端則是提供各種各樣的API,即所謂的微博平臺,大部分的業務邏輯及存儲資源均在后端部署.

在面對瞬時高壓時,由于調用鏈比較深,當某些依賴業務容量不足時,也可能會采取降級非核心的功能以保證核心服務的正常.像王寶強事件時,也做過針對非核心的無損降級.

文章出處：InfoQ