優才點評版：架構師們是靠什麼扛住了10億個紅包？

編者按：

微信這麼大的流量，尤爲是瞬間的峯值，對於任何團隊和架構師都是一個極大的挑戰，咱們也在想，微信團隊會用什麼樣的辦法扛住了搶紅包的流量，正巧今天騰訊大講堂的公共帳號就分發出了這篇文章，儘管沒有從具體的技術細節上介紹，但在宏觀策略上仍是至關地有學習的價值 ，優才學院做爲培養全棧工程師和將來架師的團隊，轉載並加以註釋，分享給你們。
進入搶紅包環節，後臺數據瞬間飆升400倍的挑戰
今年微信紅包方式與去年用戶與用戶之間互發紅包相比，搖紅包的方式對業務量來講是一個極大的爆發，光是除夕10：30送出的一波紅包就達到了1.2億個，已是2014年除夕夜峯值的400倍之巨（2014年峯值每分鐘被拆開紅包數量僅2.5W個）！

發10億紅包，難在哪裏？

微信團隊總結下來有三大難點：
快——如何保證用戶快速搖到紅包？
準——如何保證搖到的紅包能成功拆開？
穩——如何保證拆開的紅包能分享出去？

大量用戶在同一時間搖紅包，瞬間產生每秒千萬級的請求，這個量級的請求若是不加以疏導處理直接到達後臺，一定會致使後端服務過載甚至崩潰。上文中除夕當天後臺監控數據曲線便能說明一切——在前臺重重的分流減壓下，後臺服務器負載仍然瞬間飆升十倍以上。

**

三大應對策略齊上陣

**
對於以上三個難點，微信後臺開發團隊主要經過三大應對策略應對：有損服務，柔性可用，大系統小作有損服務-追求高可用和快速響應。

什麼是有損服務？有損服務是經過精心拆分產品流程，選擇性犧牲一部分數據一致性和完整性從而保證核心功能絕大多數運行。這是騰訊在PC時代積累下來的一種特點運營策略——在資源必定的前提下，互聯網條件變幻無窮的場景中，量力而爲，知足用戶的核心需求。

微信紅包的核心點是搖，拆，分享紅包，整個系統設計時必須盡最大可能保證這三個步驟一鼓作氣，任何關聯繫統出現異常的時候立刻進行系統降級，防止引發系統雪崩
。
系統降級能夠分爲兩個方面，一是把核心功能進行分拆和簡化，經過輔助輕量化的服務實現，確保最短關鍵路徑的可行，比方說在接入層置入搖紅包邏輯，將每秒千萬級請求轉化爲每秒萬級的紅包請求，再傳到紅包服務的後端邏輯，下降雪崩的可能性。

點評：有損服務就是讓重要的事情先作，重要的人物先行。這在現實中也很常見，軍人買票優先，領導視察封路，讓領導車先行，我等小民等待也是這個路子。

同時後端採用異步分拆，接收到用戶請求時僅進行合法性驗證，驗證完成後直接告知成功，後續業務邏輯進入異步隊列進行處理，減小了用戶的等待時間，也極大下降了峯值雪崩的機率。

耗時最長的入帳操做，直接跳過，異步處理

另一方面是採起過載保護措施：
微信紅包的過載保護在客戶端已提早預埋了策略，在鏈接失敗或超時狀況下會有相應提示，減小用戶重複請求次數。接入層面也會進行自我保護，針對頻繁發出請求的客戶端限制響應速度，並對系統負載劃分出若干等級，達到不一樣閾值時引導客戶端使用不一樣限速速率；在異常狀況出現時，採起減小紅包數，異步限流下降拆/分享紅包的速率等措施減輕服務器端壓力；與此同時，微信紅包還有全程壓測流程，對整個業務連接進行自動提早評估，防止過載。
點評：在前端擋住對後端流量的進入，好比出現通訊失敗時，當前這個用戶，對後臺已經不會有什麼壓力了。

這畫面你可能沒見過，它其實早已在手機待命

在有損服務思想的重重保護下，第一波的搖紅包體驗活動中，微信紅包幾乎滿分經過考驗，其中過載保護的做用至關明顯，在客戶端、接入層層減壓、過濾，最終僅把十萬級壓力傳遞到後臺。
柔性可用-細化場景把握核心需求。
柔性可用是在有損服務價值觀支持下的方法，重點在於實際上會結合用戶使用場景，根據資源消耗，調整產品策略，設計幾個級別不一樣的用戶體驗場景，保證儘量成功返回關鍵數據，並正常接受請求，毫不輕易倒下。
柔性服務更具備產品的思惟性質，意義在於深入理解產品每個場景的核心價值，把握用戶在每個場景中的核心需求，設計不一樣層次的知足核心訴求的辦法，對柔性服務在微信紅包中的實踐，紅包團隊也有相應的措施，主要能夠分爲幾大類。
一、系統容災：
面對大規模的請求量，系統容災必不可少，容災通常可分爲邏輯層容災和數據層容災，此次微信後臺開發團隊在容災佈置中採用30%切換的邏輯層方案，即核心服務都能作到最多1/3服務器出問題的狀況下自動容災切換以保證服務質量，提升預警級別換取系統的可用性。
二、資源隔離：
顧名思義就是把資源進行隔離減小服務支路間的影響，從邏輯入手，在資源邏輯中，當A服務同時分派任務給BC服務時，設定單個最大分配上限值，避免任意一個支路出問題影響整個服務鏈條，這樣即便部分服務出現問題也不會影響到整個服務的崩塌。
三、快速拒絕：
當服務過載時儘早拒絕請求，由服務調用方換機重試避免單一服務器重試過載，快速拒絕和有損服務中的及早拒絕是一個概念的方法，從過程的源頭將問題解決，成本越低，影響越小，前端保護後端的方式來解決問題。

點評：這裏面須要指出一點的是，客戶端跟Web 系統不一樣，作這種操做的前提，是提早預計到關鍵路徑，在客戶端的版本更新中，將相關的指令和策略埋入，當接受數據獲取異常時，在客戶端自動就下降請求頻率，好比一次請求失敗，用戶確定想二次再刷，可是可能實際上沒有向後端請求，而是直接返回，請客戶稍安勿躁，若是不提早埋入，到有問題時才處理是來不及的。
四、支付分組：
從支付環節入手，將全部紅包分爲50個組，放在50個單獨的set上互不影響，單組set出問題最多隻影響1/50用戶，保證多數人服務不受干擾。分組set化也是柔性可用的一個重要技術手段，這一思惟很是相似於現實生活中的集裝箱思惟——經過標準化，規模化的箱體設計，應對複雜多樣的貨物，使每一個流通環節既獨立又不失靈活。
五、流量預加載：
從客戶端入手，將語音圖片等極消耗流量的資源提早讓客戶端自動下載預置好，提早將流量洪峯疏導，並在活動當天CDN將準備數百G帶寬應對，這塊也與過載保護中的快慢分離是相通的，將耗流量的服務提早加載避免高峯期間的衝突。
點評：這是提早準備，從各個路徑上，把緩存用到完全。

**

大系統小作-保證進程的功能單一

**
大系統小作應該來講，是一種意識，他的核心思想是將功能複雜較大的系統，化大爲小，減小模塊耦合，下降關聯性，用多個獨立的模塊來實現總體系統的功能，大系統小作採用的是化繁爲簡，分而治之，便於開發和迅速實現。
微信紅包如此龐大的後臺系統，模塊也至關之多，而此次的模塊微信開發後臺團隊採用了系統高度模塊化的方式，分紅一個個高度自制的小系統，造成高內聚低耦合的格局，每一個模塊之間不會過度依賴對方，這樣的好處是不會由於任何一個模塊而影響所有服務，避免牽一髮動全身的風險，實現真正的灰度服務。
點評：下降耦合，增長問題處理時的難度和平時的可維護性。

**

海量服務能力決定成敗

**
從2014的滴滴打車，到2015的微信紅包，騰訊用一個個案例，去證實自身在海量服務方面的實力。事實上，真正支撐起微信紅包順暢運營的幕後英雄，正是騰訊內部一個叫作「海量之道2.0」的技術體系。有損服務，柔性服務，大系統小作三大手段也是脫胎於此體系中。移動互聯網大戰硝煙味愈濃，BAT都在爲爭奪支付入口使出渾身解數，在業務從起步到小跑再到騰飛的過程當中，巨頭背後的海量服務能力將對其最終成敗有着來愈加深遠的影響。

**

總結：

**優才學院一直堅持一個觀點，儘管是在移動互聯網時代，可是客戶端應用開發自己，並非體驗的決勝之處，真正對團隊挑戰的地方，還在於後端，不管是承壓能力，仍是安全性等方面，若是這些地方過不了關，整個應用的基礎是不紮實的，咱們也認爲，技術能力是應用的骨架，若是技術能力，或者說後端能力不強，應用在長到必定程度也會支撐不下去。固然可喜的是，如今有了不少雲服務，從Iaas 騰訊雲、阿里雲，到Paas SAE，另外還有專業的存儲雲服務，好比七牛，甚至對於代碼級服務質量監控 APM 廠商也出現了，國內作得最好的是 OneAPM， 這些服務必定程度上能下降團隊的技術要求，以及在平時，能發現本身服務中所存在的問題。進行及早準備。