微信紅包後臺系統可用性設計實踐

       微信紅包業務量級的高速發展，對後臺系統架構的可用性要求愈來愈高。在保障微信紅包業務體驗的前提下，紅包後臺系統進行了一系列高可用方面的優化設計。本次演講介紹了微信紅包後臺系統的高可用實踐經驗，主要包括後臺的 set 化設計、異步化設計、訂單異地存儲設計、存儲層容災設計與平行擴縮容等。聽衆能夠了解到微信紅包後臺架構的設計細節，共同探討高可用設計實踐上遇到的問題與解決方案。

     

微信紅包介紹

微信紅包從 2014 年開始發展到如今 2017 年，中間經歷了 3 年時間。在這三年的時間裏，整個系統可用性產生了較大的提高。2015 年年初的時候，天天晚上九點鐘是微信紅包的業務高峯期，系統常常性地出現性能問題。到了 2017 年的今天，即便在節假日高峯期，系統也不會出現問題。

如上圖所示，微信紅包的業務包含包、發、搶、拆、查詢發送紅包和收紅包數量，其中最關鍵的步驟是發紅包和搶紅包。

微信紅包是微信支付的商戶，微信紅包這個商戶出售的是錢。發紅包用戶在微信紅包平臺使用微信支付購買一份錢，微信紅包將錢發放到相對應的微信羣。羣裏的用戶搶紅包獲得微信零錢。這個過程當中，微信紅包和微信支付之間的關係是商家和第三方支付平臺的關係。

微信紅包和微信支付之間的交互，與普通商家與微信支付的交互同樣，須要通過六個步驟。用戶發紅包時，進入微信紅包下一筆訂單，系統記錄發紅包用戶、發紅包金額、紅包數量和要發送到的用微信羣。而後微信紅包系統請求微信支付服務器進行下單，用戶使用微信支付進行支付。

支付成功後，微信支付後臺系統通知微信紅包後臺系統支付成功結果，微信紅包後臺系統收到通知後推送微信紅包消息到微信羣。微信羣裏用戶即可搶紅包。這就是微信紅包和微信支付的關係以及交互過程。

微信紅包系統架構

微信紅包的系統流程

上圖是微信紅包系統角度上的流程，業務主流程是包、發、搶、拆四個操做，每一個操做包括幾個關鍵步驟。

包紅包，系統爲每一個紅包分配一個惟一 ID，即紅包發送訂單號，而後將發紅包用戶、紅包個數、紅包數額寫入存儲，最後去微信支付下單。

發紅包，用戶使用微信支付完成付款，微信紅包後臺系統收到微信支付系統的支付成功通知。紅包系統將紅包發送訂單狀態更新爲用戶已支付，並寫入用戶發紅包記錄（用戶發紅包記錄，就是微信錢包中，查看到的用戶每年總共發出及收到的紅包記錄）。最後微信紅包後臺系統發送微信紅包消息到微信羣。

搶紅包，指微信羣裏的用戶收到微信紅包消息後，點開紅包消息。這個過程，微信紅包後臺系統會檢查紅包是否已被搶完，是否已過時，是否已經搶過。

拆紅包是最複雜的業務是操做。包括查詢這個紅包發送訂單，判斷用戶是否可拆，而後計算本次可拆到的紅包金額。而後寫入一條搶紅包記錄。若是把拆紅包過程，類比爲一個秒殺活動的過程，至關於扣庫存與寫入秒殺記錄的過程。更新庫存對應於更新紅包發送訂單，寫入秒殺記錄對應於寫入這個紅包的領取紅包記錄。另外，還要寫入用戶總體的紅包領取記錄。最後請求微信支付系統給拆到紅包用戶轉入零錢，成功後更新搶紅包的訂單狀態爲已轉帳成功。

微信紅包的總體架構

　　

上圖所示，是微信紅包的系統架構。包括微信統一接入層，下面是微信紅包系統 API，包括髮、搶、拆、查紅包詳情、查紅包用戶列表。再下面是封裝微信紅包關鍵業務的邏輯服務；最下面一層是數據存儲層，微信紅包最主要的數據是訂單數據，包括髮紅包訂單和拆紅包訂單兩部分。業務邏輯和存儲服務器之間是數據接入層，它最重要的做用是封裝數據庫操做的領域邏輯，使得業務邏輯服務不須要感知對 MySQL 的鏈接管理、性能、容災等問題。

微信紅包數據的訪問熱度，隨着時間流逝會急劇下降，也就是數據的訪問時間段很是集中，通常紅包發出三天後，99% 的用戶不會再去點開這個紅包了。所以微信紅包系統採起按時間作冷熱數據分離，下降數據的存儲成本，同時提高了熱數據的訪問性能。

數據平臺用於對紅包數據的分析計算，好比朋友圈裏的文章，統計從 2016 年 1 月 1 日到 2017 年 1 月一個用戶總共搶紅包的金額，在全國的排名狀況，發紅包數最多的城市等。另一個做用就是對帳，紅包的訂單和微信支付的訂單須要對帳，以保證最終資金的一致性；訂單的數據和訂單的 cache 須要作對帳，以保證數據的完整性；訂單數據和用戶的收發記錄須要對帳，以保證用戶列表完整性。

微信紅包系統可用性實踐

系統可用性影響因素

系統的可用性影響因素可分紅兩類，一類計劃外，一類計劃內。計劃外包含不少因素，系統用到的全部東西均可能產生故障，均可能成功影響可用性的因素。從這個角度上來說，能夠說故障是沒法避免的，系統的運做必定會產生故障，尤爲是服務器有成千上萬個的時候。計劃內的影響因素，主要有與升級相關、運維相關的操做，以及平常的備份等。這一類影響因素，經過精細地設計方案，是能夠避免對可用性形成影響的。

微信紅包系統可用性設計方向

基於上面兩個分析結論，能夠總結出微信紅包後臺系統的可用性的設計方向。就是在不能避免意外故障的狀況下，儘量下降出現意外故障時對可用性的影響。另外一方面，絕大多數計劃內的平常維護能夠經過方案的設計避免影響可用性，其中平行擴容特指關於存儲層的平行擴容。

下面從下降故障影響和微信紅包系統的平行擴容兩方面進行分析。

首先是下降意外故障的影響，重點講解訂單存儲層在訂單 DB 故障的狀況下如何下降對紅包系統可用性的影響。

業務邏輯層 - 部署方案設計

首先是業務邏輯層的部署方案。業務邏輯層是無狀態的，微信紅包系統的業務邏輯層，部署在兩個城市，即兩地部署，每個城市部署至少三個園區，即三個 IDC。而且每一個服務須要保證三個 IDC 的部署均衡。另外，三個 IDC 總服務能力須要冗餘三分之一，當一個 IDC 出現故障時，服務能力仍然足夠。從而達到 IDC 故障不會對可用性產生影響。

業務邏輯層 - 異步化設計

第二是異步化設計。如上圖所示，微信紅包的某些步驟不實時完成也不會影響用戶對紅包業務可用性的體驗。好比拆紅包，正常的業務流程很長，但關鍵步驟只有訂單相關的幾步。至於轉零錢、寫紅包記錄等操做不須要實時。用戶搶到紅包時，通常不會實時去錢包查看微信零錢，而是在微信羣中點開消息查看本次搶到金額和他人搶紅包金額。因此拆紅包時只須要從 cache 查詢用戶是否拆過紅包，而後寫入拆紅包的訂單記錄，更新發紅包訂單，其餘的操做均可以異步化。固然，不是每一個業務均可以進行異步化設計，須要進行業務分析，判斷是否存在非關鍵步驟以外的事情能夠將其異步化，並經過異步對帳保證最終一致。

接下來是微信紅包訂單存儲設計。上圖是 2014 年微信紅包存儲層的模型。業務邏輯層請求數據層操做時，使用訂單號 hash 路由到訂單 SERVER。訂單 SERVER 與每一組 MYSQL 數據庫鏈接。

微信紅包的訂單號是在發紅包時系統生成惟一標識，使用序列號服務生成惟一 ID，後面拼接三位微信紅包的訂單分庫表的標識。因此，總共能夠分一百個邏輯庫，每一個邏輯庫含有十張表。一百個邏輯庫均勻地分佈到十組物理 DB，每組 DB 存十個邏輯庫。

這個架構的最大問題是，一組 DB 故障時，會影響其餘 DB。2014-2015 年期間，微信紅包量漲得特別快，擴容速度跟不上業務增加速度。一組 DB 的性能出現瓶頸時，數據操做變慢, 拆紅包的事務操做在 MYSQL 排隊等待。因爲全部十組 DB 機器與全部的訂單 SERVER 鏈接，致使全部的訂單 SERVER 都被拖住，從而影響紅包總體的可用性。這個架構的另外一個問題是擴容不方便，後面會介紹。

爲解決 DB 間的相互影響，須要將 DB 間相互隔離，訂單存儲層 SET 化。SET 化指訂單 DB 和訂單接入 SERVER 垂直 stick 一塊兒。業務邏輯層訪問訂單時，根據訂單倒數第2、三位數字找到所屬訂單 SET，一個 SET 的請求不能路由到其餘 SET。

找到對應的訂單接入服務器以後，在服務器內的多個進程中找到指定進程，讓同個紅包的全部拆請求串行化。當一組 DB 出現故障，只會影響該組 DB 對應的 SERVER。

這裏有一個問題，DB 故障拖住某些訂單 SERVER，會不會也拖住更上層業務邏輯服務？業務邏輯層爲何不一塊兒 SET 化？業務邏輯層承載了用戶維度相關的業務操做，不能夠按照訂單的維度分業務邏輯，例如務邏輯層會請求用戶的頭像、暱稱等，若是繼續按照訂單分業務邏輯，會致使跨地域調用。

微信紅包系統採起的方案是，在訂單 SERVER 服務端增長快速拒絕服務的能力。SERVER 主動監控 DB 的性能狀況，DB 性能降低、自身的 CPU 使用升高，或者發現其餘的監控維度超標時，訂單 SERVER 直接向上層報錯，再也不去訪問 DB，以此保證業務邏輯層的可用性。

一組 DB 故障不會影響整個系統的可用性。有影響的，只有十分之一，若擴成 100 組，影響便只有一百分之一。因此經過 SET 化獲得的好處是，控制 DB 鏈接數、隔離故障影響和分流併發。

完成 SET 化以後，DB 故障仍對業務有十分之一影響，那麼這十分之一該怎麼解決？經過對系統進行研究分析以後，發現 DB 能夠作到故障自愈。

如上圖所示，所設尾號 90-99 的 SET 故障時，若是業務邏輯服務後續再也不生成屬於這個 SET 的訂單，那後續的業務就能夠逐漸恢復。

也就是在發生故障時，業務邏輯層發佈一個版本，屏蔽故障號段的單號生成，就能夠恢復業務。進一步想，除了人爲發版本，有沒有方法可讓 DB 故障時自動恢復？在 DB 故障致使業務失敗時，業務邏輯層可獲取到故障 DB 的號段，在發紅包時，將這些故障的號段，換一個可用的號段就可恢復業務。訂單號除了最後三位，前面的部分已能保證該紅包惟一性，後面的數字只表明着分庫表信息，故障時只須要將最後三位換另一個 SET 即可自動恢復。

完成這個設計後，即便 DB 出現故障，業務的可用性也不會有影響。這裏還有一點，新的發紅包請求可避免 DB 故障的影響，但那些故障以前已發出未被領取的紅包，紅包消息已發送到微信羣，單號已肯定，拆紅包時仍是失敗。對這種狀況，因爲不會有增量，採用正常的主備切換解決便可。

平行擴縮容設計

上圖是微信紅包早期的擴縮容方式。這個擴容方式，對擴容的機器數有限制。前面講到，紅包系統按紅包單號後面兩個數字分多 SET，爲了使擴容後數據保持均衡，擴容只能由 10 組 DB 擴容到 20 組、50 組或者 100 組。另外，這個擴容方式，過程也比較複雜。首先，數據要先從舊數據庫同步複製到新擴容的 DB，而後部署 DB 的接入 SERVER，最後在凌晨業務低峯時停服擴容。

這個擴容方式的複雜性，根本緣由是數據須要從舊 SET 遷到新 SET。若是新產生數據與舊數據不要緊，那麼就能夠省掉這部分的遷移動做，不需停服輸。分析發現，須要把舊數據遷出來的緣由是訂單號段 00-99 已所有被用，每一個物理數據庫包含了 10 個邏輯庫。若是將訂單號從新設計，預留三位空間，三位數字每個表明獨立的物理 DB，原來 10 組 DB 分別爲 000-009 號段。

這種設計，縮容時，好比要縮掉 000 這組，只需在業務邏輯服務上不生成訂單號爲 000 的紅包訂單。擴容時，好比擴爲 11 組，只需多生成 010 的訂單號，這個數據便自動寫入新 DB。固然，縮容須要一個前提條件，也就是冷熱分離，縮容後數據變爲冷數據，可下線熱數據機器。以上就是紅包的平行擴縮容方案。

寫在最後

微信紅包系統的可用性實踐，主要包括了部署設計、SET 化設計、異步化設計、DB 故障自愈能力建設、平行擴容設計。在完成這些設計後，微信紅包系統的可用性獲得了很大提高，在 2017 年春節實現了 0 故障，在日常的運行中達到 99.99% 可用性。