1、前言

微信朋友圈包括圖片和視頻兩套業務架構組成，朋友圈圖片的特點是請求量大、消耗計算資源較多，視頻則主要消耗帶寬。

朋友圈的數據是永遠存儲的，而且隨著業務的快速發展，存儲容量、帶寬和設備的消耗大量增加，尤其重大節日帶來的使用量增長，更加劇了消耗，也給運維人員的保障帶來了巨大壓力。

在重在節假日節點，技術保障主要由三方面組成：

• 1)軟件保障指通過程序、業務邏輯層面的優化和評估，減輕負載;
• 2)硬件保障主要指帶寬、機器負載的評估和擴容;
• 3)柔性措施指的是通過業務調整，降低一些不重要特性的資源，來保障重點特性的正常運行。

2、軟件架構方面的保障

朋友圈整體情況如下圖所示：

朋友圈的架構主要分為OC和IDC兩種：

• IDC指的是數據中心，即數據最終落地存儲的地方;
• OC指的是帶外網的獨立機房，SOC指規模較大的OC。

每個IDC都有一整套接口機/邏輯設備/存儲設備用以支撐用戶的上傳下載、及文件落地存儲的需求。

OC點的主要作用是提供外網訪問，承載用戶的下載流量。每個OC內的設備，一起組成一個緩存池，用戶下載時，本地OC中緩存不***，才到IDC去回源拉取文件。每個OC的功能都是相同的，用戶一般到就近的OC點下載，當單個OC點故障時，會通過重試或者切換讓用戶到其他OC點下載，確保下載成功。

3、容災及重試機制

朋友圈的模塊容災主要是實現單機故障時的自動剔除，主要形式是通過master管理服務器的ip列表，通過心跳探測等方式找到異常設備，并屏蔽故障ip，不返回給前端使用。

以front層的單機剔除為例：

如果整個OC或IDC點碰到故障，由于變動較大，一般依賴運維人員手工切換來恢復，或者通過模塊之間的重試機制來保障。

朋友圈下載的重試：

不管是用戶到OC的下載過程，還是OC到IDC的回源過程，默認都會進行2次失敗后的重試，并且重試一定會選擇異地的接入點，避免繼續重試到故障的節點。實現的原理是每一層master都會返回給前端至少兩組ip列表，并保證兩組ip列表為異地節點，前端失敗時才可以實現異地重試。

但重試由于會造成請求的增加，所以是把雙刃劍，節日高峰期間由于請求本身漲幅已經很高，重試更容易引發問題，需要進行調整：

• 1)通過master路由下發，關閉重試。在元旦/春節這種請求有數倍增長的節日實行;
• 2)值班人員嚴密監控，如果IDC失敗率超過20%，則緊急手工關閉重試。這種在中秋/國慶這種增長并不高的節日實行。

Front模塊的重試控制界面：

4、硬件方面的保障

4.1 容量評估和設備擴容

重要節日前運維人員會連同資源組，根據業務預算和業務增長的需求及實際負載，進行各個機房、模塊的設備擴容。預算以外的請求上漲，則通過柔性或者過載的方式，進行降低或者拒絕。

評估方法：

• 1)機房容量主要根據交換機帶寬的上限評估;
• 2)接入層設備容量主要根據CPU、內存的負載比例、網卡的流量/包量占比來評估;
• 3)存儲層設備容量主要根據CPU、內存的負載比例、磁盤IO的讀寫次數來評估。

4.2 春節朋友圈上傳負載

業務側春節要求的增長比例，是上傳支持9倍增長，下載支持1倍增長，超過這個比例的請求可以拒絕掉，但根據預算擴容后，達到上圖的效果，還是有部分模塊無法支持這個漲幅，尤其是壓縮compress模塊，該模塊每支持一倍增長就需要大量虛擬機擴容，預算內無法支持，這樣就需要使用柔性策略來解決。

5、柔性策略簡介

朋友圈的柔性策略分為兩層：

• ***層是粗暴柔性：即按比例、接業務直接限制上傳下載的請求，被限制的請求會返回給用戶失敗，與微信C2C相同，這種一般用于超過系統預估的負載能力，造成系統故障時用于快速恢復業務時使用;
• 第二層是按業務特性柔性：即從業務層面通過降低圖片視頻清晰度、延遲用戶更新等方向降低系統的負載。下面主要詳述業務柔性。

朋友圈業務的主要增長與瓶頸：從前文的設備負載評估圖看，在預算范圍內，接入層和邏輯層都只能支撐5倍增長，而壓縮compress模塊只能支撐1倍增長。

6、柔性實踐之：壓縮compress柔性

Compress模塊的作用是將客戶端上傳來的原始圖片按需求壓縮成各種格式和尺寸，以支持特定的業務場景，并且節省存儲空間和帶寬。由于壓縮技術的不斷發展，使用更先進的壓縮格式，同等清晰度的圖片壓縮比例越高，需要消耗的壓縮計算資源就越多。

所以如果反向操作，將當前使用的hevc格式替換回jpeg格式存儲的話，就可以節省壓縮資源，實測compress的cpu負載可以降為20%，即支持5倍增長。但圖片的平均大小也會上漲，造成下載流量上漲。

所以采用的折衷方法，是在上傳圖片換回jpeg格式的同時，將圖片的清晰度從70降為50，這樣可以減小文件平均大小，從而抵消換回jpeg格式帶來的流量上漲效果。實際測試中，發現用戶對降清晰度的感知并不明顯，在節假日短暫開啟不會影響用戶體驗。

7、柔性實踐之：小視頻碼率柔性

小視頻的帶寬平時會超過1TB，節日效應增長明顯。所采取的降流量方法與圖片類似，即降低上傳視頻的碼率，通過降低文件平均大小的方法來節省帶寬。

柔性： 小視頻碼率1800 -> 1200 平均大小 2.1MB -> 1.3MB

經測試，降碼率后基本不會影響用戶體驗，但由于是對新上傳視頻生效，要體現到下載帶寬的下降中，就有相當程度的延遲，大約需要4小時完全生效。所以這一柔性措施在節日之前就需要開啟，不能用于應付緊急情況。

降碼率生效期間流量變化：

8、柔性實踐之：上傳TSSD緩沖池柔性

由于上傳preupload接口機及后層的邏輯模塊等，都無法支持10倍漲幅。所以在架構中另外搭建了兩套TSSD緩沖池，緩沖池用于臨時存儲新上傳的文件，可以支持讀寫。按上圖所示，在zone模塊處增加了緩沖池一，在上傳preupload處，增加了緩沖池二。兩個緩沖池的作用是有區別的：

zone模塊如果過載，主動過載掉的上傳請求，不會直接返回失敗，而是將請求寫入到緩沖池一中，緩沖池一中的文件并不能被下載到，但會按比較慢的速度將文件下發，寫入到后端模塊。所以緩沖池一的主要作用是減緩短時間內大量的上傳請求，而不是完全抵消上傳請求，并且緩沖池一中的文件是不能被下載到的。

在preupload模塊處增加了緩沖池二，preupload模塊中對存儲TFS的寫請求次數做了限制，如果上傳請求數超過了存儲TFS的能力，則preupload會將請求寫入緩沖池二。用戶下載時，會根據文件標識進行判斷，如果發現文件存儲在緩沖池二而不是TFS中，則會到緩沖池二中去獲取文件。所以緩沖池二可以替代TFS的功能，起到保護底層模塊的效果。等到緩沖池二下架時，需要將其中的文件人工寫入到TFS中。

9、柔性實踐之：朋友圈timeline按比例柔性

timeline指的是微信朋友圈更新的時間戳，這一柔性的原理是將通知用戶好友朋友圈更新的時間戳先緩存起來，不下發給用戶的微信終端，這樣微信上就看不到朋友圈更新的內容了，也就不會產生下載圖片/視頻的請求，可以直接減少下載流量。

timeline柔性后這里不會更新了：

但也有幾點注意事項：

• 1)容易引起用戶投訴，用戶一般會明顯感知到朋友圈內容變少了;
• 2)如果緩存timeline的時間過久，將緩存下發的過程就必須很慢，否則會引起下載流量的進一步暴漲。