1、前言
微信朋友圈包括圖片和視頻兩套業務架構組成，朋友圈圖片的特點是請求量大、消耗計算資源較多，視頻則主要消耗帶寬。
朋友圈的數據是永遠存儲的，而且隨著業務的快速發展，存儲容量、帶寬和設備的消耗大量增加，尤其重大節日帶來的使用量增長，更加劇了消耗，也給運維人員的保障帶來了巨大壓力。
在重在節假日節點，技術保障主要由三方面組成：
1）軟件保障指通過程序、業務邏輯層面的優化和評估，減輕負載；
2）硬件保障主要指帶寬、機器負載的評估和擴容；
3）柔性措施指的是通過業務調整，降低一些不重要特性的資源，來保障重點特性的正常運行。
學習交流：
- 即時通訊開發交流3群：185926912[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-1569-1-1.html）
2、相關文章
《微信朋友圈海量技術之道PPT [附件下載]》
《架構之道：3個程序員成就微信朋友圈日均10億發布量[有視頻]》
3、軟件架構方面的保障
朋友圈整體情況如下圖所示：
朋友圈的架構主要分為OC和IDC兩種：
IDC指的是數據中心，即數據最終落地存儲的地方；
OC指的是帶外網的獨立機房，SOC指規模較大的OC。
每個IDC都有一整套接口機/邏輯設備/存儲設備用以支撐用戶的上傳下載、及文件落地存儲的需求。
OC點的主要作用是提供外網訪問，承載用戶的下載流量。每個OC內的設備，一起組成一個緩存池，用戶下載時，本地OC中緩存不命中，才到IDC去回源拉取文件。每個OC的功能都是相同的，用戶一般到就近的OC點下載，當單個OC點故障時，會通過重試或者切換讓用戶到其他OC點下載，確保下載成功。
4、容災及重試機制
朋友圈的模塊容災主要是實現單機故障時的自動剔除，主要形式是通過master管理服務器的ip列表，通過心跳探測等方式找到異常設備，并屏蔽故障ip，不返回給前端使用。
以front層的單機剔除為例：
如果整個OC或IDC點碰到故障，由于變動較大，一般依賴運維人員手工切換來恢復，或者通過模塊之間的重試機制來保障。
朋友圈下載的重試：
不管是用戶到OC的下載過程，還是OC到IDC的回源過程，默認都會進行2次失敗后的重試，并且重試一定會選擇異地的接入點，避免繼續重試到故障的節點。實現的原理是每一層master都會返回給前端至少兩組ip列表，并保證兩組ip列表為異地節點，前端失敗時才可以實現異地重試。
但重試由于會造成請求的增加，所以是把雙刃劍，節日高峰期間由于請求本身漲幅已經很高，重試更容易引發問題，需要進行調整：
1）通過master路由下發，關閉重試。在元旦/春節這種請求有數倍增長的節日實行；
2）值班人員嚴密監控，如果IDC失敗率超過20%，則緊急手工關閉重試。這種在中秋/國慶這種增長并不高的節日實行。
Front模塊的重試控制界面：
5、硬件方面的保障
5.1 容量評估和設備擴容
重要節日前運維人員會連同資源組，根據業務預算和業務增長的需求及實際負載，進行各個機房、模塊的設備擴容。預算以外的請求上漲，則通過柔性或者過載的方式，進行降低或者拒絕。
評估方法：
1）機房容量主要根據交換機帶寬的上限評估；
2）接入層設備容量主要根據CPU、內存的負載比例、網卡的流量/包量占比來評估；
3）存儲層設備容量主要根據CPU、內存的負載比例、磁盤IO的讀寫次數來評估。
5.2 春節朋友圈上傳負載
業務側春節要求的增長比例，是上傳支持9倍增長，下載支持1倍增長，超過這個比例的請求可以拒絕掉，但根據預算擴容后，達到上圖的效果，還是有部分模塊無法支持這個漲幅，尤其是壓縮compress模塊，該模塊每支持一倍增長就需要大量虛擬機擴容，預算內無法支持，這樣就需要使用柔性策略來解決。
6、柔性策略簡介
朋友圈的柔性策略分為兩層：
第一層是粗暴柔性：即按比例、接業務直接限制上傳下載的請求，被限制的請求會返回給用戶失敗，與微信C2C相同，這種一般用于超過系統預估的負載能力，造成系統故障時用于快速恢復業務時使用；
第二層是按業務特性柔性：即從業務層面通過降低圖片視頻清晰度、延遲用戶更新等方向降低系統的負載。下面主要詳述業務柔性。
朋友圈業務的主要增長與瓶頸：從前文的設備負載評估圖看，在預算范圍內，接入層和邏輯層都只能支撐5倍增長，而壓縮compress模塊只能支撐1倍增長。
7、柔性實踐之：壓縮compress柔性
Compress模塊的作用是將客戶端上傳來的原始圖片按需求壓縮成各種格式和尺寸，以支持特定的業務場景，并且節省存儲空間和帶寬。由于壓縮技術的不斷發展，使用更先進的壓縮格式，同等清晰度的圖片壓縮比例越高，需要消耗的壓縮計算資源就越多。
所以如果反向操作，將當前使用的hevc格式替換回jpeg格式存儲的話，就可以節省壓縮資源，實測compress的cpu負載可以降為20%，即支持5倍增長。但圖片的平均大小也會上漲，造成下載流量上漲。
所以采用的折衷方法，是在上傳圖片換回jpeg格式的同時，將圖片的清晰度從70降為50，這樣可以減小文件平均大小，從而抵消換回jpeg格式帶來的流量上漲效果。實際測試中，發現用戶對降清晰度的感知并不明顯，在節假日短暫開啟不會影響用戶體驗。
8、柔性實踐之：小視頻碼率柔性
小視頻的帶寬平時會超過1TB，節日效應增長明顯。所采取的降流量方法與圖片類似，即降低上傳視頻的碼率，通過降低文件平均大小的方法來節省帶寬。
柔性： 小視頻碼率1800 -> 1200 平均大小 2.1MB -> 1.3MB
經測試，降碼率后基本不會影響用戶體驗，但由于是對新上傳視頻生效，要體現到下載帶寬的下降中，就有相當程度的延遲，大約需要4小時完全生效。所以這一柔性措施在節日之前就需要開啟，不能用于應付緊急情況。
降碼率生效期間流量變化：
9、柔性實踐之：上傳TSSD緩沖池柔性
由于上傳preupload接口機及后層的邏輯模塊等，都無法支持10倍漲幅。所以在架構中另外搭建了兩套TSSD緩沖池，緩沖池用于臨時存儲新上傳的文件，可以支持讀寫。按上圖所示，在zone模塊處增加了緩沖池一，在上傳preupload處，增加了緩沖池二。兩個緩沖池的作用是有區別的：
zone模塊如果過載，主動過載掉的上傳請求，不會直接返回失敗，而是將請求寫入到緩沖池一中，緩沖池一中的文件并不能被下載到，但會按比較慢的速度將文件下發，寫入到后端模塊。所以緩沖池一的主要作用是減緩短時間內大量的上傳請求，而不是完全抵消上傳請求，并且緩沖池一中的文件是不能被下載到的。
在preupload模塊處增加了緩沖池二，preupload模塊中對存儲TFS的寫請求次數做了限制，如果上傳請求數超過了存儲TFS的能力，則preupload會將請求寫入緩沖池二。用戶下載時，會根據文件標識進行判斷，如果發現文件存儲在緩沖池二而不是TFS中，則會到緩沖池二中去獲取文件。所以緩沖池二可以替代TFS的功能，起到保護底層模塊的效果。等到緩沖池二下架時，需要將其中的文件人工寫入到TFS中。
10、柔性實踐之：朋友圈timeline按比例柔性
timeline指的是微信朋友圈更新的時間戳，這一柔性的原理是將通知用戶好友朋友圈更新的時間戳先緩存起來，不下發給用戶的微信終端，這樣微信上就看不到朋友圈更新的內容了，也就不會產生下載圖片/視頻的請求，可以直接減少下載流量。
timeline柔性后這里不會更新了：
但也有幾點注意事項：
1）容易引起用戶投訴，用戶一般會明顯感知到朋友圈內容變少了；
2）如果緩存timeline的時間過久，將緩存下發的過程就必須很慢，否則會引起下載流量的進一步暴漲。
春節人工執行柔性的步驟：
（原文鏈接：https://cloud.tencent.com/developer/article/1006591）
附錄1：有關IM架構設計的文章
《淺談IM系統的架構設計》
《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《一套原創分布式即時通訊(IM)系統理論架構方案》
《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》
《蘑菇街即時通訊/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產品的技術方法論》
《移動端IM中大規模群消息的推送如何保證效率、實時性？》
《現代IM系統中聊天消息的同步和存儲方案探討》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《微信朋友圈千億訪問量背后的技術挑戰和實踐總結》
>> 更多同類文章 ……
附錄2：QQ、微信團隊分享的文章匯總
[1] QQ、微信團隊原創技術文章：
《微信朋友圈千億訪問量背后的技術挑戰和實踐總結》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)》
《微信團隊分享：微信移動端的全文檢索多音字問題解決方案》
《騰訊技術分享：Android版手機QQ的緩存監控與優化實踐》
《微信團隊分享：iOS版微信的高性能通用key-value組件技術實踐》
《微信團隊分享：iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的？》
《騰訊技術分享：Android手Q的線程死鎖監控系統技術實踐》
《微信團隊原創分享：iOS版微信的內存監控系統技術實踐》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《iOS后臺喚醒實戰：微信收款到賬語音提醒技術總結》
《騰訊技術分享：社交網絡圖片的帶寬壓縮技術演進之路》
《微信團隊分享：視頻圖像的超分辨率技術原理和應用場景》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊團隊分享：手機QQ中的人臉識別酷炫動畫效果實現詳解》
《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《微信手機端的本地數據全文檢索優化之路》
《企業微信客戶端中組織架構數據的同步更新方案優化實戰》
《微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《QQ 18年：解密8億月活的QQ后臺服務接口隔離技術》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《以手機QQ為例探討移動端IM中的“輕應用”》
《一篇文章get微信開源移動端數據庫組件WCDB的一切！》
《微信客戶端團隊負責人技術訪談：如何著手客戶端性能監控和優化》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信后臺團隊：微信后臺異步消息隊列的優化升級實踐分享》
《微信團隊原創分享：微信客戶端SQLite數據庫損壞修復實踐》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信后臺?；顚崙鸱窒?進程?；钇?》
《微信團隊原創分享：Android版微信后臺?；顚崙鸱窒?網絡保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案》
《微信朋友圈海量技術之道PPT [附件下載]》
《微信對網絡影響的技術試驗及分析（論文全文）》
《一份微信后臺技術架構的總結性筆記》
《架構之道：3個程序員成就微信朋友圈日均10億發布量[有視頻]》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（二）》
《微信團隊原創分享：Android內存泄漏監控和優化技巧總結》
《全面總結iOS版微信升級iOS9遇到的各種“坑”》
《微信團隊原創資源混淆工具：讓你的APK立減1M》
《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》
《Android版微信安裝包“減肥”實戰記錄》
《iOS版微信安裝包“減肥”實戰記錄》
《移動端IM實踐：iOS版微信界面卡頓監測方案》
《微信“紅包照片”背后的技術難題》
《移動端IM實踐：iOS版微信小視頻功能技術方案實錄》
《移動端IM實踐：Android版微信如何大幅提升交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提升交互性能（二）》
《移動端IM實踐：實現Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《移動端IM實踐：iOS版微信的多設備字體適配方案探討》
《信鴿團隊原創：一起走過 iOS10 上消息推送(APNS)的坑》
《騰訊信鴿技術分享：百億級實時消息推送的實戰經驗》
>> 更多同類文章 ……
[2] 有關QQ、微信的技術故事：
《技術往事：微信估值已超5千億，雷軍曾有機會收編張小龍及其Foxmail》
《QQ和微信兇猛成長的背后：騰訊網絡基礎架構的這些年》
《閑話即時通訊：騰訊的成長史本質就是一部QQ成長史》
《2017微信數據報告：日活躍用戶達9億、日發消息380億條》
《騰訊開發微信花了多少錢？技術難度真這么大？難在哪？》
《技術往事：創業初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》
《技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》
《技術往事：“QQ群”和“微信紅包”是怎么來的？》
《開發往事：深度講述2010到2015，微信一路風雨的背后》
《開發往事：微信千年不變的那張閃屏圖片的由來》
《開發往事：記錄微信3.0版背后的故事（距微信1.0發布9個月時）》
《一個微信實習生自述：我眼中的微信開發團隊》
《首次揭秘：QQ實時視頻聊天背后的神秘組織》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-1569-1-1.html）