1、前言

微信朋友圈包括圖片和視頻兩套業(yè)務(wù)架構(gòu)組成，朋友圈圖片的特點(diǎn)是請求量大、消耗計(jì)算資源較多，視頻則主要消耗帶寬。

朋友圈的數(shù)據(jù)是永遠(yuǎn)存儲的，而且隨著業(yè)務(wù)的快速發(fā)展，存儲容量、帶寬和設(shè)備的消耗大量增加，尤其重大節(jié)日帶來的使用量增長，更加劇了消耗，也給運(yùn)維人員的保障帶來了巨大壓力。

在重在節(jié)假日節(jié)點(diǎn)，技術(shù)保障主要由三方面組成：

1）軟件保障指通過程序、業(yè)務(wù)邏輯層面的優(yōu)化和評估，減輕負(fù)載；

2）硬件保障主要指帶寬、機(jī)器負(fù)載的評估和擴(kuò)容；

3）柔性措施指的是通過業(yè)務(wù)調(diào)整，降低一些不重要特性的資源，來保障重點(diǎn)特性的正常運(yùn)行。

學(xué)習(xí)交流：

- 即時(shí)通訊開發(fā)交流3群：185926912[推薦]

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

（本文同步發(fā)布于：http://www.52im.net/thread-1569-1-1.html）

2、相關(guān)文章

《微信朋友圈海量技術(shù)之道PPT [附件下載]》

《架構(gòu)之道：3個(gè)程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》

3、軟件架構(gòu)方面的保障

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

朋友圈的架構(gòu)主要分為OC和IDC兩種：

IDC指的是數(shù)據(jù)中心，即數(shù)據(jù)最終落地存儲的地方；

OC指的是帶外網(wǎng)的獨(dú)立機(jī)房，SOC指規(guī)模較大的OC。

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

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

4、容災(zāi)及重試機(jī)制

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

以front層的單機(jī)剔除為例：

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

朋友圈下載的重試：

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

但重試由于會造成請求的增加，所以是把雙刃劍，節(jié)日高峰期間由于請求本身漲幅已經(jīng)很高，重試更容易引發(fā)問題，需要進(jìn)行調(diào)整：

1）通過master路由下發(fā)，關(guān)閉重試。在元旦/春節(jié)這種請求有數(shù)倍增長的節(jié)日實(shí)行；

2）值班人員嚴(yán)密監(jiān)控，如果IDC失敗率超過20%，則緊急手工關(guān)閉重試。這種在中秋/國慶這種增長并不高的節(jié)日實(shí)行。

Front模塊的重試控制界面：

5、硬件方面的保障

5.1 容量評估和設(shè)備擴(kuò)容

重要節(jié)日前運(yùn)維人員會連同資源組，根據(jù)業(yè)務(wù)預(yù)算和業(yè)務(wù)增長的需求及實(shí)際負(fù)載，進(jìn)行各個(gè)機(jī)房、模塊的設(shè)備擴(kuò)容。預(yù)算以外的請求上漲，則通過柔性或者過載的方式，進(jìn)行降低或者拒絕。

評估方法：

1）機(jī)房容量主要根據(jù)交換機(jī)帶寬的上限評估；

2）接入層設(shè)備容量主要根據(jù)CPU、內(nèi)存的負(fù)載比例、網(wǎng)卡的流量/包量占比來評估；

3）存儲層設(shè)備容量主要根據(jù)CPU、內(nèi)存的負(fù)載比例、磁盤IO的讀寫次數(shù)來評估。

5.2 春節(jié)朋友圈上傳負(fù)載

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

6、柔性策略簡介

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

第一層是粗暴柔性：即按比例、接業(yè)務(wù)直接限制上傳下載的請求，被限制的請求會返回給用戶失敗，與微信C2C相同，這種一般用于超過系統(tǒng)預(yù)估的負(fù)載能力，造成系統(tǒng)故障時(shí)用于快速恢復(fù)業(yè)務(wù)時(shí)使用；

第二層是按業(yè)務(wù)特性柔性：即從業(yè)務(wù)層面通過降低圖片視頻清晰度、延遲用戶更新等方向降低系統(tǒng)的負(fù)載。下面主要詳述業(yè)務(wù)柔性。

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

7、柔性實(shí)踐之：壓縮compress柔性

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

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

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

8、柔性實(shí)踐之：小視頻碼率柔性

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

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

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

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

9、柔性實(shí)踐之：上傳TSSD緩沖池柔性

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

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

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

10、柔性實(shí)踐之：朋友圈timeline按比例柔性

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

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

但也有幾點(diǎn)注意事項(xiàng)：

1）容易引起用戶投訴，用戶一般會明顯感知到朋友圈內(nèi)容變少了；

2）如果緩存timeline的時(shí)間過久，將緩存下發(fā)的過程就必須很慢，否則會引起下載流量的進(jìn)一步暴漲。

春節(jié)人工執(zhí)行柔性的步驟：

（原文鏈接：https://cloud.tencent.com/developer/article/1006591）

附錄1：有關(guān)IM架構(gòu)設(shè)計(jì)的文章

《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》

《簡述移動端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》

《一套海量在線用戶的移動端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》

《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》

《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》

《蘑菇街即時(shí)通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》

《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》

《微信后臺基于時(shí)間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計(jì)實(shí)踐》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》

《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》

《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》

《移動端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》

《IM開發(fā)基礎(chǔ)知識補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲架構(gòu)？》

《IM開發(fā)基礎(chǔ)知識補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫讀寫分離原理及實(shí)踐建議》

《IM開發(fā)基礎(chǔ)知識補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》

《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》

>> 更多同類文章 ……

附錄2：QQ、微信團(tuán)隊(duì)分享的文章匯總

[1] QQ、微信團(tuán)隊(duì)原創(chuàng)技術(shù)文章：

《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》

《微信團(tuán)隊(duì)分享：微信移動端的全文檢索多音字問題解決方案》

《騰訊技術(shù)分享：Android版手機(jī)QQ的緩存監(jiān)控與優(yōu)化實(shí)踐》

《微信團(tuán)隊(duì)分享：iOS版微信的高性能通用key-value組件技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)分享：iOS版微信是如何防止特殊字符導(dǎo)致的炸群、APP崩潰的？》

《騰訊技術(shù)分享：Android手Q的線程死鎖監(jiān)控系統(tǒng)技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)原創(chuàng)分享：iOS版微信的內(nèi)存監(jiān)控系統(tǒng)技術(shù)實(shí)踐》

《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》

《iOS后臺喚醒實(shí)戰(zhàn)：微信收款到賬語音提醒技術(shù)總結(jié)》

《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》

《微信團(tuán)隊(duì)分享：視頻圖像的超分辨率技術(shù)原理和應(yīng)用場景》

《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時(shí)音視頻聊天背后的技術(shù)解密》

《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（上篇）》

《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（下篇）》

《騰訊團(tuán)隊(duì)分享：手機(jī)QQ中的人臉識別酷炫動畫效果實(shí)現(xiàn)詳解》

《騰訊團(tuán)隊(duì)分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》

《微信團(tuán)隊(duì)分享：微信Android版小視頻編碼填過的那些坑》 

《微信手機(jī)端的本地?cái)?shù)據(jù)全文檢索優(yōu)化之路》 

《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實(shí)戰(zhàn)》

《微信團(tuán)隊(duì)披露：微信界面卡死超級bug“15。。。。”的來龍去脈》

《QQ 18年：解密8億月活的QQ后臺服務(wù)接口隔離技術(shù)》

《月活8.89億的超級IM微信是如何進(jìn)行Android端兼容測試的》

《以手機(jī)QQ為例探討移動端IM中的“輕應(yīng)用”》

《一篇文章get微信開源移動端數(shù)據(jù)庫組件WCDB的一切！》

《微信客戶端團(tuán)隊(duì)負(fù)責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化》

《微信后臺基于時(shí)間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計(jì)實(shí)踐》

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信的臃腫之困與模塊化實(shí)踐之路》

《微信后臺團(tuán)隊(duì)：微信后臺異步消息隊(duì)列的優(yōu)化升級實(shí)踐分享》

《微信團(tuán)隊(duì)原創(chuàng)分享：微信客戶端SQLite數(shù)據(jù)庫損壞修復(fù)實(shí)踐》 

《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》 

《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（下篇）》 

《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（上篇）》 

《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫，即將開源》 

《如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》 

《開源libco庫：單機(jī)千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》 

《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺保活實(shí)戰(zhàn)分享(進(jìn)程保活篇)》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺保活實(shí)戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》 

《Android版微信從300KB到30MB的技術(shù)演進(jìn)(PPT講稿) [附件下載]》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信從300KB到30MB的技術(shù)演進(jìn)》 

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(PPT講稿) [附件下載]》 

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》

《微信海量用戶背后的后臺系統(tǒng)存儲架構(gòu)(視頻+PPT) [附件下載]》

《微信異步化改造實(shí)踐：8億月活、單機(jī)千萬連接背后的后臺解決方案》 

《微信朋友圈海量技術(shù)之道PPT [附件下載]》 

《微信對網(wǎng)絡(luò)影響的技術(shù)試驗(yàn)及分析（論文全文）》 

《一份微信后臺技術(shù)架構(gòu)的總結(jié)性筆記》 

《架構(gòu)之道：3個(gè)程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》 

《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》

《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（二）》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android內(nèi)存泄漏監(jiān)控和優(yōu)化技巧總結(jié)》 

《全面總結(jié)iOS版微信升級iOS9遇到的各種“坑”》 

《微信團(tuán)隊(duì)原創(chuàng)資源混淆工具：讓你的APK立減1M》 

《微信團(tuán)隊(duì)原創(chuàng)Android資源混淆工具：AndResGuard [有源碼]》 

《Android版微信安裝包“減肥”實(shí)戰(zhàn)記錄》 

《iOS版微信安裝包“減肥”實(shí)戰(zhàn)記錄》 

《移動端IM實(shí)踐：iOS版微信界面卡頓監(jiān)測方案》 

《微信“紅包照片”背后的技術(shù)難題》 

《移動端IM實(shí)踐：iOS版微信小視頻功能技術(shù)方案實(shí)錄》 

《移動端IM實(shí)踐：Android版微信如何大幅提升交互性能（一）》

《移動端IM實(shí)踐：Android版微信如何大幅提升交互性能（二）》

《移動端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》 

《移動端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》 

《移動端IM實(shí)踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》

《移動端IM實(shí)踐：iOS版微信的多設(shè)備字體適配方案探討》 

《信鴿團(tuán)隊(duì)原創(chuàng)：一起走過 iOS10 上消息推送(APNS)的坑》

《騰訊信鴿技術(shù)分享：百億級實(shí)時(shí)消息推送的實(shí)戰(zhàn)經(jīng)驗(yàn)》

>> 更多同類文章 ……

[2] 有關(guān)QQ、微信的技術(shù)故事：

《技術(shù)往事：微信估值已超5千億，雷軍曾有機(jī)會收編張小龍及其Foxmail》

《QQ和微信兇猛成長的背后：騰訊網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的這些年》

《閑話即時(shí)通訊：騰訊的成長史本質(zhì)就是一部QQ成長史》

《2017微信數(shù)據(jù)報(bào)告：日活躍用戶達(dá)9億、日發(fā)消息380億條》

《騰訊開發(fā)微信花了多少錢？技術(shù)難度真這么大？難在哪？》

《技術(shù)往事：創(chuàng)業(yè)初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》 

《技術(shù)往事：史上最全QQ圖標(biāo)變遷過程，追尋IM巨人的演進(jìn)歷史》 

《技術(shù)往事：“QQ群”和“微信紅包”是怎么來的？》 

《開發(fā)往事：深度講述2010到2015，微信一路風(fēng)雨的背后》 

《開發(fā)往事：微信千年不變的那張閃屏圖片的由來》 

《開發(fā)往事：記錄微信3.0版背后的故事（距微信1.0發(fā)布9個(gè)月時(shí)）》 

《一個(gè)微信實(shí)習(xí)生自述：我眼中的微信開發(fā)團(tuán)隊(duì)》

《首次揭秘：QQ實(shí)時(shí)視頻聊天背后的神秘組織》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-1569-1-1.html）