微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實踐總結(jié)
1、前言
微信朋友圈包括圖片和視頻兩套業(yè)務(wù)架構(gòu)組成,朋友圈圖片的特點是請求量大、消耗計算資源較多,視頻則主要消耗帶寬。
朋友圈的數(shù)據(jù)是永遠存儲的,而且隨著業(yè)務(wù)的快速發(fā)展,存儲容量、帶寬和設(shè)備的消耗大量增加,尤其重大節(jié)日帶來的使用量增長,更加劇了消耗,也給運維人員的保障帶來了巨大壓力。
在重在節(jié)假日節(jié)點,技術(shù)保障主要由三方面組成:
- 1)軟件保障指通過程序、業(yè)務(wù)邏輯層面的優(yōu)化和評估,減輕負載;
- 2)硬件保障主要指帶寬、機器負載的評估和擴容;
- 3)柔性措施指的是通過業(yè)務(wù)調(diào)整,降低一些不重要特性的資源,來保障重點特性的正常運行。
2、軟件架構(gòu)方面的保障
朋友圈整體情況如下圖所示:
朋友圈的架構(gòu)主要分為OC和IDC兩種:
- IDC指的是數(shù)據(jù)中心,即數(shù)據(jù)最終落地存儲的地方;
- OC指的是帶外網(wǎng)的獨立機房,SOC指規(guī)模較大的OC。
每個IDC都有一整套接口機/邏輯設(shè)備/存儲設(shè)備用以支撐用戶的上傳下載、及文件落地存儲的需求。
OC點的主要作用是提供外網(wǎng)訪問,承載用戶的下載流量。每個OC內(nèi)的設(shè)備,一起組成一個緩存池,用戶下載時,本地OC中緩存不***,才到IDC去回源拉取文件。每個OC的功能都是相同的,用戶一般到就近的OC點下載,當單個OC點故障時,會通過重試或者切換讓用戶到其他OC點下載,確保下載成功。
3、容災(zāi)及重試機制
朋友圈的模塊容災(zāi)主要是實現(xiàn)單機故障時的自動剔除,主要形式是通過master管理服務(wù)器的ip列表,通過心跳探測等方式找到異常設(shè)備,并屏蔽故障ip,不返回給前端使用。
以front層的單機剔除為例:
如果整個OC或IDC點碰到故障,由于變動較大,一般依賴運維人員手工切換來恢復(fù),或者通過模塊之間的重試機制來保障。
朋友圈下載的重試:
不管是用戶到OC的下載過程,還是OC到IDC的回源過程,默認都會進行2次失敗后的重試,并且重試一定會選擇異地的接入點,避免繼續(xù)重試到故障的節(jié)點。實現(xiàn)的原理是每一層master都會返回給前端至少兩組ip列表,并保證兩組ip列表為異地節(jié)點,前端失敗時才可以實現(xiàn)異地重試。
但重試由于會造成請求的增加,所以是把雙刃劍,節(jié)日高峰期間由于請求本身漲幅已經(jīng)很高,重試更容易引發(fā)問題,需要進行調(diào)整:
- 1)通過master路由下發(fā),關(guān)閉重試。在元旦/春節(jié)這種請求有數(shù)倍增長的節(jié)日實行;
- 2)值班人員嚴密監(jiān)控,如果IDC失敗率超過20%,則緊急手工關(guān)閉重試。這種在中秋/國慶這種增長并不高的節(jié)日實行。
Front模塊的重試控制界面:
4、硬件方面的保障
4.1 容量評估和設(shè)備擴容
重要節(jié)日前運維人員會連同資源組,根據(jù)業(yè)務(wù)預(yù)算和業(yè)務(wù)增長的需求及實際負載,進行各個機房、模塊的設(shè)備擴容。預(yù)算以外的請求上漲,則通過柔性或者過載的方式,進行降低或者拒絕。
評估方法:
- 1)機房容量主要根據(jù)交換機帶寬的上限評估;
- 2)接入層設(shè)備容量主要根據(jù)CPU、內(nèi)存的負載比例、網(wǎng)卡的流量/包量占比來評估;
- 3)存儲層設(shè)備容量主要根據(jù)CPU、內(nèi)存的負載比例、磁盤IO的讀寫次數(shù)來評估。
4.2 春節(jié)朋友圈上傳負載
業(yè)務(wù)側(cè)春節(jié)要求的增長比例,是上傳支持9倍增長,下載支持1倍增長,超過這個比例的請求可以拒絕掉,但根據(jù)預(yù)算擴容后,達到上圖的效果,還是有部分模塊無法支持這個漲幅,尤其是壓縮compress模塊,該模塊每支持一倍增長就需要大量虛擬機擴容,預(yù)算內(nèi)無法支持,這樣就需要使用柔性策略來解決。
5、柔性策略簡介
朋友圈的柔性策略分為兩層:
- ***層是粗暴柔性:即按比例、接業(yè)務(wù)直接限制上傳下載的請求,被限制的請求會返回給用戶失敗,與微信C2C相同,這種一般用于超過系統(tǒng)預(yù)估的負載能力,造成系統(tǒng)故障時用于快速恢復(fù)業(yè)務(wù)時使用;
- 第二層是按業(yè)務(wù)特性柔性:即從業(yè)務(wù)層面通過降低圖片視頻清晰度、延遲用戶更新等方向降低系統(tǒng)的負載。下面主要詳述業(yè)務(wù)柔性。
朋友圈業(yè)務(wù)的主要增長與瓶頸:從前文的設(shè)備負載評估圖看,在預(yù)算范圍內(nèi),接入層和邏輯層都只能支撐5倍增長,而壓縮compress模塊只能支撐1倍增長。
6、柔性實踐之:壓縮compress柔性
Compress模塊的作用是將客戶端上傳來的原始圖片按需求壓縮成各種格式和尺寸,以支持特定的業(yè)務(wù)場景,并且節(jié)省存儲空間和帶寬。由于壓縮技術(shù)的不斷發(fā)展,使用更先進的壓縮格式,同等清晰度的圖片壓縮比例越高,需要消耗的壓縮計算資源就越多。
所以如果反向操作,將當前使用的hevc格式替換回jpeg格式存儲的話,就可以節(jié)省壓縮資源,實測compress的cpu負載可以降為20%,即支持5倍增長。但圖片的平均大小也會上漲,造成下載流量上漲。
所以采用的折衷方法,是在上傳圖片換回jpeg格式的同時,將圖片的清晰度從70降為50,這樣可以減小文件平均大小,從而抵消換回jpeg格式帶來的流量上漲效果。實際測試中,發(fā)現(xiàn)用戶對降清晰度的感知并不明顯,在節(jié)假日短暫開啟不會影響用戶體驗。
7、柔性實踐之:小視頻碼率柔性
小視頻的帶寬平時會超過1TB,節(jié)日效應(yīng)增長明顯。所采取的降流量方法與圖片類似,即降低上傳視頻的碼率,通過降低文件平均大小的方法來節(jié)省帶寬。
柔性: 小視頻碼率1800 -> 1200 平均大小 2.1MB -> 1.3MB
經(jīng)測試,降碼率后基本不會影響用戶體驗,但由于是對新上傳視頻生效,要體現(xiàn)到下載帶寬的下降中,就有相當程度的延遲,大約需要4小時完全生效。所以這一柔性措施在節(jié)日之前就需要開啟,不能用于應(yīng)付緊急情況。
降碼率生效期間流量變化:
8、柔性實踐之:上傳TSSD緩沖池柔性
由于上傳preupload接口機及后層的邏輯模塊等,都無法支持10倍漲幅。所以在架構(gòu)中另外搭建了兩套TSSD緩沖池,緩沖池用于臨時存儲新上傳的文件,可以支持讀寫。按上圖所示,在zone模塊處增加了緩沖池一,在上傳preupload處,增加了緩沖池二。兩個緩沖池的作用是有區(qū)別的:
zone模塊如果過載,主動過載掉的上傳請求,不會直接返回失敗,而是將請求寫入到緩沖池一中,緩沖池一中的文件并不能被下載到,但會按比較慢的速度將文件下發(fā),寫入到后端模塊。所以緩沖池一的主要作用是減緩短時間內(nèi)大量的上傳請求,而不是完全抵消上傳請求,并且緩沖池一中的文件是不能被下載到的。
在preupload模塊處增加了緩沖池二,preupload模塊中對存儲TFS的寫請求次數(shù)做了限制,如果上傳請求數(shù)超過了存儲TFS的能力,則preupload會將請求寫入緩沖池二。用戶下載時,會根據(jù)文件標識進行判斷,如果發(fā)現(xiàn)文件存儲在緩沖池二而不是TFS中,則會到緩沖池二中去獲取文件。所以緩沖池二可以替代TFS的功能,起到保護底層模塊的效果。等到緩沖池二下架時,需要將其中的文件人工寫入到TFS中。
9、柔性實踐之:朋友圈timeline按比例柔性
timeline指的是微信朋友圈更新的時間戳,這一柔性的原理是將通知用戶好友朋友圈更新的時間戳先緩存起來,不下發(fā)給用戶的微信終端,這樣微信上就看不到朋友圈更新的內(nèi)容了,也就不會產(chǎn)生下載圖片/視頻的請求,可以直接減少下載流量。
timeline柔性后這里不會更新了:
但也有幾點注意事項:
- 1)容易引起用戶投訴,用戶一般會明顯感知到朋友圈內(nèi)容變少了;
- 2)如果緩存timeline的時間過久,將緩存下發(fā)的過程就必須很慢,否則會引起下載流量的進一步暴漲。