|
王關(guān)勝，現(xiàn)任微博產(chǎn)品資深運(yùn)維架構(gòu)師，負(fù)責(zé)微博平臺(tái)的技術(shù)保障工作，7年大并發(fā)高可用分布式系統(tǒng)運(yùn)維經(jīng)驗(yàn)，對(duì)整個(gè)運(yùn)維體系，技術(shù)保障方面研究比較深入，尤其是自動(dòng)化運(yùn)維方面。2014年起專注于DevOps、Container領(lǐng)域，推進(jìn)Docker在微博平臺(tái)的落地，并基于公有云構(gòu)建混合云系統(tǒng)，具備分鐘級(jí)彈性擴(kuò)容千節(jié)點(diǎn)能力。 前言 8月14日凌晨時(shí)分，演員王寶強(qiáng)突然在微博上發(fā)出離婚聲明，直指妻子馬蓉出軌經(jīng)紀(jì)人，并宣布解除與馬蓉的婚姻關(guān)系。該消息發(fā)出后，迅速成為熱點(diǎn)話題，在微博上炸開了鍋。據(jù)小道消息稱，在這次的熱點(diǎn)事件中，微博流量相較于往常的熱點(diǎn)，增長(zhǎng)了數(shù)倍，甚至在話題高峰期，有部分服務(wù)被短暫打死。 之前微博曾披露過他們已經(jīng)遷移到基于Docker容器的混合云平臺(tái)DCP，那對(duì)于這樣的突發(fā)熱點(diǎn)，DCP是如何應(yīng)對(duì)的？Docker容器可以進(jìn)行秒級(jí)擴(kuò)容，那為什么還會(huì)有短暫的服務(wù)被打死情況發(fā)生？DCP整個(gè)的彈性伸縮流程是怎么樣的？帶著這些問題，InfoQ記者采訪了微博Container平臺(tái)彈性伸縮負(fù)責(zé)人王關(guān)勝。 奧運(yùn)期間熱點(diǎn)事件對(duì)微博服務(wù)的沖擊 奧運(yùn)期間因?yàn)橥鯇殢?qiáng)的離婚事件，讓微博的流量大增，甚至部分服務(wù)被短暫打死。詳細(xì)情況是怎樣的？ 王關(guān)勝：自16年里約奧運(yùn)會(huì)開幕式開始，微博整體流量增幅明顯，相較于往常增長(zhǎng)數(shù)倍，造成了白天跟日常晚高峰一樣的持續(xù)峰值場(chǎng)景。更甚的是，奧運(yùn)期間還有賽事的熱點(diǎn)及明星事件的沖擊，給微博平臺(tái)的服務(wù)帶來數(shù)倍于日常峰值的流量請(qǐng)求。 其中在孫楊PK霍頓、奧運(yùn)網(wǎng)紅傅園慧的“洪荒之力”、王寶強(qiáng)事件、女排奪冠等熱點(diǎn)中，尤以寶強(qiáng)事件的影響最為巨大。大家可以去看一下寶強(qiáng)發(fā)布離婚聲明的微博互動(dòng)數(shù)據(jù)，非常驚人；再來看看流量數(shù)據(jù)： 圖1：微博，評(píng)論及Feed業(yè)務(wù)量 圖2：話題業(yè)務(wù)量 可以看到，這次事件對(duì)微博的核心服務(wù)如Feed、評(píng)論、話題等帶來的壓力都是成倍的，已經(jīng)超過16年春晚，為歷史新高點(diǎn)。仔細(xì)分析一下，可以發(fā)現(xiàn)這種事件基本可以分為：發(fā)生期、發(fā)酵期、暴漲期、緩解期。 而暴漲期一般都是內(nèi)部運(yùn)營(yíng)部門的push引來爆點(diǎn)，此時(shí)對(duì)于服務(wù)的容量冗余要求極高，雖然DCP已經(jīng)彈性擴(kuò)容了大批Container，但Java的服務(wù)初啟動(dòng)，會(huì)有線程池及連接資源預(yù)熱的過程，此時(shí)會(huì)有一點(diǎn)慢的現(xiàn)象，也可以理解為瞬時(shí)流量短暫打死。 微博目前用戶基數(shù)龐大，DAU和MAU均為數(shù)億。從整個(gè)技術(shù)體系來看，微博核心總體分為端和后端平臺(tái)，端上主要是PC端，移動(dòng)端，開放平臺(tái)以及企業(yè)開放平臺(tái)。后端平臺(tái)主要是Java編寫的各種接口層、服務(wù)層、中間件層及存儲(chǔ)層。除此之外，微博搜索、推薦、廣告、大數(shù)據(jù)平臺(tái)也是非常核心的產(chǎn)品。從業(yè)務(wù)角度看，整體架構(gòu)圖如下： 我們團(tuán)隊(duì)主要負(fù)責(zé)的微博平臺(tái)的業(yè)務(wù)與保障，平臺(tái)在2015年的部署架構(gòu)如下： 就平臺(tái)前端來說，每日超過千億次的API調(diào)用、超過萬億的RPC調(diào)用，產(chǎn)生的日志就達(dá)百T 。對(duì)于這么大體量的業(yè)務(wù)系統(tǒng)，對(duì)于運(yùn)維的要求也很嚴(yán)格；就接口層來說，SLA必須達(dá)到4個(gè)9，且接口平均響應(yīng)時(shí)間不能高于50ms。因此我們會(huì)面臨各種各樣的挑戰(zhàn)。 如何應(yīng)對(duì)這種突發(fā)情況？ 當(dāng)時(shí)面對(duì)這樣的突發(fā)情況，新浪微博是如何應(yīng)對(duì)的？有哪些是沒有考慮的的情況？ 王關(guān)勝：微博對(duì)于服務(wù)的穩(wěn)定性要求很高，在奧運(yùn)開始前，微博平臺(tái)已經(jīng)啟動(dòng)了線上服務(wù)保障相關(guān)的準(zhǔn)備工作，也建立了奧運(yùn)期間的早晚班值班機(jī)制，以防止突發(fā)情況出現(xiàn)。在日常的峰值場(chǎng)景中，微博的混合云DCP平臺(tái)可以做到無人值守的進(jìn)行服務(wù)的彈性伸縮。 從熱點(diǎn)事件的業(yè)務(wù)流量圖可以看出：到達(dá)爆點(diǎn)之前一般會(huì)有發(fā)酵期，而我們的容量決策系統(tǒng)會(huì)實(shí)時(shí)的監(jiān)測(cè)業(yè)務(wù)量變化，根據(jù)服務(wù)冗余情況決定是否自動(dòng)伸縮，再根據(jù)一定的配比去彈性擴(kuò)容， 縮容。當(dāng)寶強(qiáng)事件爆點(diǎn)出來時(shí)，DCP已經(jīng)提前擴(kuò)容了一批業(yè)務(wù)container，但是讓我們沒想到的是業(yè)務(wù)量來的是如此之快，如此之高，加上瞬間的流量請(qǐng)求對(duì)于后端資源的預(yù)熱，需要一點(diǎn)時(shí)間，部分服務(wù)出現(xiàn)短暫的超時(shí)，我們迅速對(duì)于非核心功能啟動(dòng)了無損降級(jí)，服務(wù)很快恢復(fù)。 當(dāng)然，在應(yīng)對(duì)這種熱點(diǎn)事件時(shí)，我們已經(jīng)很嫻熟了，都會(huì)準(zhǔn)備很多的預(yù)案，比如降級(jí)、限流、切流量等干預(yù)手段。 基于Docker的混合云平臺(tái)DCP優(yōu)勢(shì)在哪？ 王關(guān)勝：微博平臺(tái)大概14年開始研究Docker，14年底就Docker化了一些服務(wù)，并基于內(nèi)部的基礎(chǔ)設(shè)施上線了第一版的Docker工具平臺(tái)，在15年春晚也發(fā)揮了作用。 但是這版的工具平臺(tái)有很大的限制：我們內(nèi)網(wǎng)的物理機(jī)設(shè)備冗余比較少，自動(dòng)擴(kuò)容的能力有限。基于此，我們開始探索公有云，并于2015年基于公有云的彈性能力加上私有云一起構(gòu)建混合云DCP。通過與阿里云的合作，微博實(shí)現(xiàn)了從提前部署擴(kuò)容到實(shí)時(shí)擴(kuò)容的升級(jí)，并能達(dá)到10分鐘彈性擴(kuò)容上千節(jié)點(diǎn)的能力。 如果要說DCP的優(yōu)勢(shì)的話，我覺得最核心的就兩點(diǎn)： 首先，微博平臺(tái)的業(yè)務(wù)已經(jīng)完全Docker化，基于Docker的特性，解決了環(huán)境差異性問題，使得標(biāo)準(zhǔn)化變得容易。其次，基于公有云，使得我們的服務(wù)的彈性能力大大加強(qiáng)，再也不用提前購(gòu)買服務(wù)器，進(jìn)行漫長(zhǎng)的部署過程了。 DCP的核心設(shè)計(jì)思路 王關(guān)勝：微博混合云平臺(tái)DCP的核心設(shè)計(jì)思想，主要是借鑒銀行的運(yùn)作機(jī)制，在內(nèi)部設(shè)立一個(gè)計(jì)算資源共享池外，既然內(nèi)部私有云的需求，又引入了外部公有云，使其在設(shè)備資源的彈性能力大大提升。 而要微博實(shí)現(xiàn)高彈性調(diào)度資源的混合云架構(gòu)，其中實(shí)現(xiàn)的關(guān)鍵則是Docker。剛開始我們思考該使用裸機(jī)還是VM架構(gòu)，發(fā)現(xiàn)如果要采用VM，內(nèi)部機(jī)房架構(gòu)要進(jìn)行許多改造，這樣成本會(huì)更高。 所以，目前微博的內(nèi)部私有云使用裸機(jī)部署，而外部公有云則采用阿里云彈性計(jì)算服務(wù)（ECS）的VM架構(gòu)。等平臺(tái)建設(shè)成熟后，還可以應(yīng)用其他家的公有云，如AWS，在主機(jī)之上均采用Docker來持續(xù)部署。 目前我們開發(fā)的DCP平臺(tái)，主要包含4層架構(gòu)：主機(jī)層、調(diào)度層及業(yè)務(wù)編排層，最上層則是各業(yè)務(wù)方系統(tǒng)。底層的混合云基礎(chǔ)架構(gòu)則架Dispatch設(shè)了專線，打通微博內(nèi)部私有云以及阿里云。 主要思想：三駕馬車（Machine Swarm Compose） DCP混合云系統(tǒng)的設(shè)計(jì)理念，總共包含4個(gè)核心概念：彈性伸縮、自動(dòng)化、業(yè)務(wù)導(dǎo)向以及專門為微博訂制?；旌显葡到y(tǒng)必須有彈性調(diào)度的運(yùn)算能力。而DCP混合云系統(tǒng)并不是對(duì)外公開的產(chǎn)品化服務(wù)，必須以業(yè)務(wù)需求出發(fā)，因此會(huì)有包含許多微博定制的功能。 DCP系統(tǒng)最核心的3層架構(gòu)：主機(jī)層、調(diào)度適配層及編排層： 1） 主機(jī)層主機(jī)層的核心是要調(diào)度運(yùn)算資源。目前設(shè)計(jì)了資源共享池、Buffer資源池，配額管理，及多租戶管理機(jī)制，借此實(shí)現(xiàn)彈性調(diào)度資源。 2）調(diào)度層：而調(diào)度層則通過API，把調(diào)度工具用API進(jìn)行包裝，而微博4種常用的調(diào)度工具組合包含：原生Docker、Swarm、Mesos及微博自主開發(fā)的Dispatch。 最上層的則是負(fù)責(zé)業(yè)務(wù)編排及服務(wù)發(fā)現(xiàn)。目前，微博的后端服務(wù)95%是Java環(huán)境，而PC端則是使用PHP編寫，移動(dòng)端則是通過調(diào)用API服務(wù)。這些業(yè)務(wù)方都將會(huì)接入DCP。編排層也包括了大數(shù)據(jù)工具Hadoop，進(jìn)行大數(shù)據(jù)分析的業(yè)務(wù)場(chǎng)景。 我們知道，對(duì)于調(diào)度來說，最重要的就是資源管理，Mesos處理這個(gè)是最合適不過了，很多公司就專用其做資源管理，比如Netflix寫了一個(gè)Titan的調(diào)度服務(wù)，其底層資源管理則是通過Mesos。當(dāng)然我們的調(diào)度組件中，使用最多的還是Swarm、Dispatch. 我們可以看下面這個(gè)場(chǎng)景：這也是私有云內(nèi)部資源流轉(zhuǎn)的最佳實(shí)踐：
當(dāng)業(yè)務(wù)A多余的運(yùn)算資源導(dǎo)入混合云共享池時(shí)，此時(shí)流量暴漲的業(yè)務(wù)C，可從共享池調(diào)度業(yè)務(wù)A的運(yùn)算資源；峰值事件后，便可以把多余的運(yùn)算資源歸還至共享池。 3）業(yè)務(wù)編排層這層主要根據(jù)業(yè)務(wù)場(chǎng)景模型，通過主機(jī)層、調(diào)度層的API，創(chuàng)建可編排的任務(wù)模型，如集群管理、服務(wù)管理、服務(wù)池管理、鏡像管理、構(gòu)建管理、負(fù)載均衡管理、擴(kuò)縮容管理等。 從使用角度出發(fā)，我們主要?jiǎng)澐至思骸⒎?wù)池、設(shè)備Buffer等層次，以IP Port唯一標(biāo)識(shí)服務(wù)。如下圖：
其中：在DCP下可以創(chuàng)建多個(gè)集群，每個(gè)集群為獨(dú)立平臺(tái)或產(chǎn)品線，如微博平臺(tái)、紅包飛、手機(jī)微博等。集群間相互獨(dú)立，集群內(nèi)各自的服務(wù)可自由調(diào)度，集群外的調(diào)度則設(shè)置了配額機(jī)制。在集群下，可以創(chuàng)建服務(wù)池，一般為同一業(yè)務(wù)的同構(gòu)服務(wù)。主機(jī)只有進(jìn)了集群的Buffer中，才可能被用來部署服務(wù)。 DCP對(duì)于物理主機(jī)的流轉(zhuǎn)，基于資源共享池、Buffer資源池、配額管理，及多租戶管理機(jī)制，還是非常復(fù)雜的，這里我們可以看一下一臺(tái)物理主機(jī)的生命周期（狀態(tài)流轉(zhuǎn)圖）
DCP的彈性伸縮流程
王關(guān)勝：DCP系統(tǒng)最核心的是彈性伸縮，能根據(jù)容量情況進(jìn)行自動(dòng)的彈性伸縮，以此來解決明顯的早晚高峰及熱點(diǎn)事件的峰值問題。 DCP第一版時(shí)，我們做到了擴(kuò)縮容的自動(dòng)化，但未能自動(dòng)伸縮，需要人的參與，而且也會(huì)有幾個(gè)操作步驟，人本身是懶惰的且是易犯錯(cuò)的，且還會(huì)存在人力成本，這還沒達(dá)到我們的目標(biāo)，離無人值守還差一段距離，于是，我們又開發(fā)了兩個(gè)模塊：
整個(gè)自動(dòng)伸縮框架如下：
其核心的特性：如支持各種調(diào)度策略，根據(jù)業(yè)務(wù)流量及服務(wù)冗余情況，提供基于時(shí)間的調(diào)度方式，類似crontab觸發(fā)機(jī)制，Chronos、 Quartz提供可借鑒的任務(wù)調(diào)度實(shí)現(xiàn)機(jī)制；支持服務(wù)的依賴，A服務(wù)依賴B，B在自動(dòng)彈性擴(kuò)容時(shí)，需擴(kuò)容好服務(wù)B。 這樣，整個(gè)服務(wù)就可以彈性伸縮了。 哪些環(huán)節(jié)需要人工參與？
王關(guān)勝：目前微博混合云DCP平臺(tái)包含很多核心功能，如服務(wù)管理、多云對(duì)接、鏡像市場(chǎng)、彈性調(diào)度、彈性擴(kuò)縮容、服務(wù)發(fā)現(xiàn)、監(jiān)控、容量決策等，這些已經(jīng)可以全部聯(lián)動(dòng)，自動(dòng)的去彈性來做。而應(yīng)對(duì)峰值事件時(shí)，對(duì)于準(zhǔn)備的預(yù)案，如降級(jí)，切流量這些，還需要人工的參與。 面對(duì)瞬間高壓，怎樣做降級(jí)？
一般而言，面對(duì)瞬間高壓，系統(tǒng)會(huì)采用“降級(jí)非核心及周邊業(yè)務(wù)”。那么微博有沒有對(duì)哪些業(yè)務(wù)進(jìn)行降級(jí)呢？在突發(fā)熱點(diǎn)事件的這種情況下，“核心應(yīng)用”和“周邊業(yè)務(wù)”分別是哪些？微博是否準(zhǔn)備的降級(jí)策略？ 王關(guān)勝：首先介紹一下微博的架構(gòu)，微博主要分為后端和前端；前端主要是各種端（PC端和移動(dòng)端）以及內(nèi)部第三方（搜索、推薦、廣告等），而后端則是提供各種各樣的API，即所謂的微博平臺(tái)，大部分的業(yè)務(wù)邏輯及存儲(chǔ)資源均在后端部署。 在面對(duì)瞬時(shí)高壓時(shí)，由于調(diào)用鏈比較深，當(dāng)某些依賴業(yè)務(wù)容量不足時(shí)，也可能會(huì)采取降級(jí)非核心的功能以保證核心服務(wù)的正常。像王寶強(qiáng)事件時(shí)，也做過針對(duì)非核心的無損降級(jí)。
|
|
|
