原文地址：http://chuansong.me/n/1608115051125

作者｜吳逸翔編輯｜唐聰

今年春節期間，QQ以AR技術為支撐、娛樂體驗為導向在春節期間推出系列紅包并成功刷屏，系列紅包包括三大玩法+年初一彩蛋，分別是“LBS+AR天降紅包”、刷一刷紅包和“面對面”紅包，加上“娛樂紅包”(明星刷臉紅包)，共計在春節期間派發了2.5億現金紅包和價值30億的卡券禮包。根據企鵝智酷提供的數據，手機QQ的用戶滲透率在全平臺排名第二，為52.9%（第一是微信）。本文將會詳細介紹手Q春節紅包項目的設計、容災、運維、架構以及總結。

先來介紹下整個過程中，手Q紅包的玩法，以方便不了解的同學理解。2017年的手Q春節游戲紅包共有刷一刷/AR地圖/掃福三種，如下圖所示：

雖然紅包分三種，但在游戲業務側這邊的體驗都是一樣：用戶得到一個紅包卡券，打開后展示一個（刷一刷紅包）或者多個（AR地圖紅包）游戲的禮包列表，用戶選擇一個禮包后彈出區服組件，用戶確認對應的區服角色信息后會禮包會在48個小時內發放到賬。體驗如下：

游戲紅包的設計容量為入口卡券頁流量80k/s，以上體驗流程一共涉及三個后臺接口：

• 禮包列表：用戶界面的禮包內容需要根據后臺接口返回禮包列表進行排序和過濾展示。

• 區服選擇：用戶界面彈出的區服組件需要后臺接口返回用戶區服角色信息。

• 領取禮包：用戶點擊“確認”按鈕領取禮包，后臺進行游戲道具發貨。

需求分析?禮包列表

這個功能使用現有能力比較容易解決。活動共有十種游戲，每個游戲有兩種禮包：拉新（面向非注冊用戶，價值80元）/拉活躍（面向注冊用戶，價值20元），一個用戶只能獲得這兩種禮包中的一種，產品策略允許拉新的用戶獲得價值較低的拉活躍禮包，反之則不允許。頁面展示按用戶偏好排序十個游戲，每個游戲展示一個拉新禮包或者一個拉活躍禮包。

出于降低除夕當前流量負載和柔性考慮，在紅包活動前，十種游戲的禮包內容作為前端靜態數據已經預先通過離線包/CDN下發；紅包活動時，后臺接口根據用戶偏好返回的游戲禮包列表，只是提供前端禮包內容進行過濾和排序，失敗了也有前端默認的游戲禮包列表，保障用戶體驗。

過濾：讀取存儲，用戶有注冊的游戲返回活躍禮包，用戶沒有注冊的游戲返回拉新禮包

排序：一個兩層排序，第一層排序讀取存儲（key為用戶，value為用戶所注冊的游戲列表），用戶注冊的游戲（拉活躍）排在用戶沒有注冊的游戲（拉新）前面；第二層排序，對于拉新游戲列表和拉活躍游戲列表內部，使用神盾算法對用戶這10款游戲的偏好再進行二次排序。對于外部接口的依賴只有CMEM存儲和神盾算法接口，這兩個接口以及合并這兩種數據給出最終的個性化推薦禮包列表接口都可以平行擴容以支持100k級別的QPS。

?區服信息

這個功能是現有能力。這個角色信息的來源是IDIP，但由于該接口較緩慢（2s左右）且容量較低（低于10k/s），故后臺做了一層緩存，將IDIP的區服信息永久性緩存到CMEM中，前臺也有本地緩存，在實踐中，前臺緩存命中率為60%，后臺為35%，多級緩存后走到IDIP的請求量只有5%，對IDIP影響不大，只需要擴容現有的區服server和CMEM即可。

?領取禮包

這個功能使用現有能力解決存在困難。游戲中心日常發貨的道具和平臺比較多，平臺分為IEG-AMS/MP兩種，MP發貨對于發游戲道具和發Q幣又是兩種接口，故我們在架構上使用Facade模式，使用AMS作為發貨proxy，屏蔽了底層發貨的復雜性，向游戲中心提供統一的發貨接口，但比較遺憾的是從AMS到游戲的發貨接口都是同步接口，發貨能力較低，發貨能力最高的王者榮耀也只承諾了3k/s的發貨速度，明顯不足以直接承受100k/s級別的紅包發貨，故這里的核心問題是需要有一個隊列來解決生產/消費速度不對等的問題。

去年的紅包是后臺收到發貨請求后落地到本地文件返回用戶成功，再由一個本機的daemon跑落地文件按游戲方所能提供的發貨速度進行實際發貨，相當于使用本地隊列緩沖。但這個方案存在某臺機器掛掉后如果不能恢復會丟失一部分本地的發貨數據造成漏發，以及每個高并發業務都要重新做這一套東西不方便通用的問題。

從架構上思考，其實最合理的方案是作為發貨proxy的AMS提供異步發貨的能力，將用來解決生成/消費速度不匹配的MQ做在AMS內部，為業務提供通用的異步發貨能力，業務側就不需要考慮發貨超過游戲方能力的問題，新業務有類似的場景也不需要重新開發。

游戲中心是業務側，AMS是平臺側的能力，屬于另一個中心的業務，于是一開始我們準備推動AMS做異步發貨的能力，這樣業務就只要調用發貨接口就可以了，很是方便。但事情并沒有想象中順利，與AMS的開發和PM開會溝通了幾次，異步發貨的能力他們也有做技術規劃，但年前他們有其它需求要做，沒有時間支持。和leader討論了一下這個能力最好還是放在AMS做成通用以便以后有同樣場景的業務使用，前臺也有同學開發過AMS功能，可以由游戲中心業務側的前后臺同學合作完成AMS異步發貨功能的開發，在春節紅包中應用，再將這個功能交接給平臺側的同學維護，達到雙贏的效果。

整體方案與項目分解

整體方案圖如上圖所示，由于整個項目涉及多方開發，而且模塊較多，整個模塊的開發周期較長，作為一期開發的話無法跟上基礎側卡券的驗收和安排的幾次演習/壓測，故按“大系統小做”的原則，根據模塊的重要和緊急程度分為幾期迭代完成，每一期有獨立的里程碑目標并達到對應的驗收/演習/壓測要求：

• 第一期（方案圖左側部分）為功能需求，在12月9號上線通過卡券方面功能驗收，先使用當前的同步發貨接口，對性能無特別要求。

• 第二期（方案圖右側偏左部分）為性能需求，在12月20號上線參加第一次演習，對發貨進行異步化改造，要求直接面向用戶的外網發貨接口能支持100k QPS的峰值流量。

• 第三期（方案圖右側偏右部分）為容錯需求，在12月27號上線參加第二次演習，對發貨進行對賬補送改造，保證發貨的可靠性。

• 第四期為監控需求，在1月6號上線參加第三次演習，確認各項關鍵數據的采集，并將采集到的數據展現到一個統一視圖上，以便除夕期間值班人員實時了解紅包系統的整體運行情況和出數據報表。

需求開發?功能需求開發

核心問題：不同場景的數據一致性

為用戶推薦禮包，用戶領取時需要經過{4.1AMS外網發貨新OP}校驗領取資格，后臺的推薦數據必須能和AMS的資格校驗數據能夠對上，否則會出現后臺推薦的禮包用戶領取時卻通不過AMS的資格校驗導致領取不了的問題。

接口處理的是單個游戲的領取禮包的請求，資格校驗操作判斷一個用戶是否注冊了某個游戲。這個是AMS現有的通用功能，數據存儲在AMS的CMEM中，簡化描述就是一個key-value模型，key為uin+appid，value如果有注冊則為1，沒有則為0（實際為了節省存儲空間，使用bitmap桶實現，具體參見號碼包系統使用文檔)，導入的數據源是產品在除夕前一周提供10款游戲的全量注冊號碼包，每個游戲一個文件，文件內容是注冊用戶的QQ號。

但{3.1后臺禮包推薦接口}接口返回的是多個游戲的禮包列表，需要獲取十個游戲的用戶注冊狀態。如果讀取AMS現有的接口/存儲，會有兩個問題：

• AMS號碼包服務也要承受等同于推薦列表接口48k/s的流量，需要進行擴容

• AMS號碼包服務調用CMEM雖然可以一次請求合并10個key進行批量讀取，但請求到了CMEM的Access機還是要讀取多個Cache塊，性能并不如單請求單key讀取。

解決方案：同質異構的數據冗余

后臺將號碼包數據進行重新組織存儲到后臺申請的另外一個CMEM中，key為uin，value為用戶已注冊的appid列表，已注冊的游戲推薦拉活躍禮包，沒注冊的游戲推薦拉新禮包，這樣只需要查詢一次CMEM就可以得到十個游戲每個游戲的禮包推薦類型是拉新還是拉活躍。

由于AMS和后臺使用的是同一份號碼包數據，只是應用場景不同，數據組織形式不同，兩份CMEM數據同質異構，故后臺推薦的禮包可以通過AMS的資格校驗。

?性能需求開發

核心問題：用戶領取禮包流量遠超游戲發貨能力

紅包活動具有時間短（單場5~30分鐘）、大用戶量參與（1.5億+）參與的特性，請求并發高，游戲紅包入口流量設計為80k/s，流經各個模塊有衰減也有增幅，最終用戶領取禮包請求預估為96k/s，而游戲方提供的十款游戲總發貨能力只有5k/s（單款游戲最大為王者榮耀3k/s），請求峰值接近處理能力的20倍，同步調用會導致游戲方發貨接口過載，造成大面積發貨失敗，這個問題如何處理？

解決方案：發貨異步化

使用一個緩沖隊列來解決生產消費能力不對等的問題。用戶領取請求到達AMS進行基礎的資格校驗后將請求放入MQ中，返回用戶成功并告知會在48小時內到賬。再由后臺發貨Daemon從MQ中讀取請求，通過限速組件控制保證以不超過游戲方發貨能力的速率進行發貨操作。使用的MQ是部門近來建設的RocketMQ，具體參見會員消息隊列（RocketMQ）接入指南。

?容錯需求開發

核心問題：安全發貨

三場活動發放的禮包總數預計將近4億，如何保障這些禮包對于合法用戶能都發貨到賬，不少發也不多發？如何防范高價值道具被惡意用戶刷走？有沒有可能內部開發人員自己調用接口給自己發禮包？

解決方案：對賬補送/訂單號/安全打擊/權限控制

1. 訂單號解決不多發的問題

用戶領取禮包的接口{4.1AMS外網發貨新OP}調用成功，會為這個請求附帶一個UUID生成的一個全局唯一的訂單號，再放進MQ中，{4.3AMS內網發貨OP}從MQ中取出消息，調用游戲方發貨接口前都會先校驗這個訂單號是否用過，沒用過則將訂單號以key的形式寫入CMEM，再進行發貨操作。如果出現對同一個發貨消息進行重復發貨，則會發現訂單號已經用過了不會進行實際的發貨操作，保證以訂單號為標識的同一個發貨請求只會進行一次發貨操作。

2. 對賬補送解決不少發的問題

發貨失敗是不可避免的，諸如網絡波動/游戲方發貨接口故障之類的問題都可能導致調用發貨接口失敗。在同步領取環境下，用戶可以通過重試在一定程度上解決這個問題。但是對于異步發貨，用戶點擊領取后發貨請求由{4.1AMS外網發貨新OP}放入MQ中就算成功了，即使后臺調用游戲的實際發貨接口失敗了沒有實際到賬，用戶對此也無感知不能進行重試但是會投訴，后臺發貨系統必須通過自身的容錯保證即使游戲方的發貨接口不穩定偶爾會失敗，用戶所領的禮包能最終到。這里我們使用了對賬補送方案。

對賬：用戶領取禮包調用的接口{4.1AMS外網發貨新OP}成功寫應發流水，{4.3AMS內網發貨OP}調用游戲方發貨接口的寫實發流水，由于部分消息會堆積在消息隊列中，這部分稱為隊列堆積流水。故實際要進行補發操作的流水由以下公式可得：

失敗補發流水= 應發流水 - 實發流水 - 隊列堆積流水。

由于訂單號的存在，可以保證同一個發貨請求重復發送也不會多發，對隊列中堆積的消息提前進行補發操作也不會導致多發。故當隊列中堆積的流水較少的時候，采用應發流水與實發流水的差集作為失敗補發流水是合理，只是每個對賬周期會對隊列中堆積的消息進行兩次發貨操作，對性能略有損耗。

后臺每個小時運行一次增量對賬功能，檢測MQ消息堆積量量低于某個閾值，則進行對賬操作，截取上次對賬到此時的應發流水/實發流水，兩者相減得到補發流水。

補送：對對賬操作得到的補發流水調用游戲方發貨接口進行發貨補送操作。

3. 安全打擊解決高價值道具防刷的問題

對于領獎的請求，都要求都要求帶上登錄態，對用戶進行身份驗證，同時對于高價值的道具開啟安全打擊，上報安全中心進行惡意用戶校驗，防止被惡意用戶刷走。

4. 權限控制解決內部人員監守自盜的問題

對于發貨的機器都要安裝鐵將軍，用戶需要使用RTX名和token才能登錄機器，審計用戶在機器上的操作行為；

發貨模塊對于調用方是需要嚴格授權，調用方需要申請key，包含程序路徑、程序MD5、部署模塊等信息，保證發貨功能不被隨意調用。

?監控需求開發

核心問題：紅包涉及多個系統的自有監控，數據收集困難

在監控方面有兩個主要訴求：

我們對外提供的服務是否正常？如果有問題，如何快速地發現問題、分析問題？

實時知道用戶在整個系統的行為漏斗模型，每一步的轉化率是多少？

游戲紅包涉及紅包基礎側/業務前臺/業務后臺/AMS/MQ平臺等多個合作方，各個系統有自己的監控系統，數據來源不一致，活動當天一個系統一個系統地收集的話效率太低。

解決方案：匯總各個系統的關鍵數據到一個視圖

紅包作為一個涉及多個子系統的聚合系統，我們需要一個匯總了各個子系統關鍵數據的整體視圖，才能夠較全面地監控業務核心指標，對系統和業務有較全面把控，避免在監控系統中跳轉檢索而耗費有限的時間，為迅速響應解決問題提供保證。

接口封裝：雖然紅包涉及的多個子系統，各自有各自的上報方式和監控系統，但是對于關鍵數據大都有提供HTTP形式的查詢接口，我們通過封裝，將接口的定義統一為key-value形式，以（監控項id，開始時間，結束時間）為key，value為（開始時間，結束時間）段內監控id的值之和。

配置化：一場紅包活動的監控，可以由一個時間段加若干個監控項定義。比如刷一刷紅包，時間段為除夕當天20:00~20:30，監控項為若干頁面的點擊量，若干禮包的發放量，若干后臺接口的請求量，若干MQ的堆積量等等。

通過對接口的封裝和配置化，新增一場紅包活動，只需要增加一個時間段和若干個監控項的配置文件，比如下圖的AR/刷一刷混場/刷一刷專場就是通過3個配置文件定義3場活動，新增一場活動也只需要增加一個配置文件，并可以在一個視圖上靈活切換，相當方便。

從上圖中我們就可以實時看到實發和應發是大致相等的，隊列沒有出現堆積，用戶在各級頁面的轉化率，可以很方便地判斷系統的健康狀態和分析定位問題。

系統保障

第四部分講述了業務需求的開發，但是否功能開發完成后我們就這樣就可放到線上安心睡大覺了呢？

• 如果出現一部分機器乃至整個機房掛了，服務是否可用？

• 外部的服務突然故障了，比如MQ突然掛了，不能寫入消息了，服務是否可用？

• 說是紅包入口流量8W/s，萬一來了20W/s呢？系統會不會掛掉？服務是否可用？

以下從系統容災/過載保護/柔性可用/立體監控來講我們這方面做的一些工作，我們對于除夕當天出現各種問題系統還能正常運行，用戶能正常體驗服務的信心從何而來？

系統容災

容災就是在整體服務一部分出現異常時，另一部分能頂上，不影響整體服務的使用，保障業務可用、數據安全。但容災設計會使得系統復雜度增加，成本和代價也增加，需要額外的開銷和資源，應該在合理的范圍內考慮容災。

容災級別一般劃分為多機容災、多機房容災，多地容災，紅包的后臺服務主要使用公用組件的均衡負載和系統容災能力，服務無單點問題，采用同地多機房部署，按多機房容災標準設計。

?接入層

典型的GSLB+TGW+QZHTTP接入，GSLB解析域名把請求帶到離用戶最近的IDC的TGW接入機，TGW再通過內網專線，把請求轉發到實際提供WEB服務的QZHTTP服務器上。

• GSLB：Global Server Load Balance的首字母縮寫，意為全局負載均衡，主要提供提供域名解析的就近接入和流量調度。實現在廣域網（包括互聯網）上不同地域的服務器間的流量調配，保證使用最佳的離自己最近的客戶服務器服務，從而確保訪問質量；它對服務器和鏈路進行綜合判斷來決定由哪個地點的服務器來提供服務，實現異地服務器群服務質量的保證。紅包使用獨立的sh.vip.hongbao.qq.com域名。

• TGW：Tencent Gateway，是一套實現多網統一接入，支持自動負載均衡的系統，TGW把外網不同運營商的請求，通過內網隧道轉發給server，server返回數據時，再把數據通過內網隧道返回給TGW，再由TGW發送給不同的運營商。紅包TGW外網部署了上海電信聯通雙VIP+香港CAP VIP。

• QZHTTP：Web服務器，負責將HTTP請求轉成邏輯層使用的WUP協議，采用同地多機房部署部署。QZHTTP作為TGW的RS，TGW會周期性的探測RS的狀態，在1分鐘內自動把故障RS從可服務列表中踢除，當TGW檢測到RS恢復正常后，自動把它加回可服務列表中。由TGW提供負載均衡和容災。

?邏輯層

邏輯層使用SPP容器開發，禮包列表/區服選擇/禮包發貨三個功能均是無狀態服務，多個服務器在服務容量足夠的情況下任意踢掉一部分都不會影響正常服務，使用L5進行負載均衡/容災/過載保護。

L5：機器級別容災，業務程序調用L5 API從L5 Agent獲取后臺服務器的(IP, Port)，使用該(IP, Port)對應的后臺服務器進行通信，訪問結束時調用L5 API上報訪問接口和處理時延，L5 Agent對L5 API 上報的訪問結果和處理時延進行統計和上報，當服務器出現故障，L5一般在1到2分鐘內就會自動剔除故障服務器。

?數據層

數據層主要使用了作為K-V存儲的CMEM和作為分布式消息隊列的RocketMQ，這兩種服務都采用接入層-存儲層劃分，邏輯層訪問數據層的接入層使用L5進行負載均衡/容災，數據層的存儲層都采用一主一備雙機熱備容災，并落地磁盤支持掉電重啟后重建內存數據，支持多機容災但是不支持多機房多地容災。

?過載保護

紅包入口流量說是8W/s，萬一基礎側有問題發到了20W/s怎么辦？

每個模塊的容量都是從入口流量按照用戶行為漏斗模型推算轉化率設計的，萬一評估有誤轉化率偏高超過了設計容量怎么辦？

對于可能出現的超過了設計容量的流量尖峰，就要應用過載保護方法，保障系統能拒絕超過容量的部分請求，保障設計容量內的請求還能正常響應，實施的時候有四個要注意的地方：

• 從源頭上減少無效請求；

• 從接入層開始拒絕；

• 各層互相不信任；

• 要照顧用戶的情緒。

?流量預加載

CDN做為頁面訪問的關鍵路徑，前端頁面制作離線包，預先下發到客戶端，減少除夕當天CDN的流量壓力。

?頻率限制

前臺對用戶發起請求的頻率進行限制，超出頻率的請求提示用戶失敗而不走到后臺（每5秒只允許請求一次到后臺），前臺保護后臺。

后臺接入層根據壓測數據配置CGI接口的每分鐘接受的請求數，超出接口處理能力的請求丟棄并進行告警。接入門神系統，配置IP/uin/refer等規則限制惡意用戶刷請求，保障服務的正常運行。

?降級開關

前臺調用后臺的接口，設置開關以一定概率丟棄請求，對于關鍵路徑返回錯誤提示用戶稍后重試，對于非關鍵路徑提供降級體驗，結合頻率限制功能，可以限制前臺的流量傳遞到后臺的比例，當比例設為0的時候則關閉該模塊，實現前臺保護后臺。

?隊列堆積丟棄

后臺邏輯層使用SPP框架，worker處理消息前先檢查消息在SPP消息隊列中等待時間是否超出了預設閾值（500ms），在隊列中堆積過久的消息前端已經超時，對于用戶已經無意義，服務丟棄請求并進行告警，預防隊列式過載雪崩。

?柔性可用

柔性可用，柔性是為了保護系統，保證系統整體的穩定性，可用性。可用是為了用戶，盡最大努力為用戶提供優質的體驗（可能是部分服務體驗）。一個是從系統本身角度出發，一個是從用戶角度看，在真正實施過程中只有將兩者分析清，并融合在一起才能真正做到系統的柔性可用。關鍵問題是找準用戶的核心訴求，找出符合求場景的核心訴求作為關鍵路徑，出現異常可以放棄的訴求作為非關鍵路徑。

?找準用戶的核心訴求

春節游戲紅包用戶的核心訴求有三個：

• 看到禮包列表

• 選擇區服角色

• 領取禮包到賬

其他的都可以作為非關鍵路徑，有可以提高用戶體驗，沒有也不影響用戶的核心訴求。

?保障關鍵路徑的可用

看到禮包列表：作為頁面關鍵模塊的禮包列表，在紅包活動前，十種游戲的禮包內容作為前端靜態數據已經預先通過離線包/CDN下發。紅包活動時，后臺接口根據用戶偏好返回的游戲禮包列表，只是提供前端禮包內容進行過濾和排序，失敗了也有前端默認的游戲禮包列表，用戶依舊能看到禮包列表，只是排序不夠智能化。

選擇區服角色：除夕前一周游戲中心的主站頁面和運營活動增加一個后臺接口請求，預先請求用戶的區服角色信息緩存到本地，既降低了除夕當天的區服接口請求量又保證了游戲中心核心用戶的區服信息是有效的。

領取禮包到賬：RocketMQ對于領取操作是關鍵路徑服務，用戶領取禮包后需要寫入RocketMQ才能算成功。故業務對消息隊列做了邏輯層面的容災，當RocketMQ出現故障時，可以打開容災開關，領取操作寫完應發流水后直接返回成功，不再往RocketMQ寫入消息，采用分時段對賬的方法替代實時發貨，達到消息隊列容災效果，參見容錯需求開發。

?放棄異常的非關鍵路徑

• 前端頁面展示模塊化，對于請求數據不成功的非關鍵模塊進行隱藏。

• 紅包頁面導流到游戲中心，游戲中心展示按紅點邏輯展示，只顯示第一屏的數據，默認不加載第二屏數據，用戶往下滾動時再加載，犧牲用戶往下滾動會短暫卡頓的體驗減少后臺的請求壓力。

• 后臺讀取算法接口返回的推薦排序失敗時使用默認的禮包排序。

• 后臺讀取CMEM接口返回的禮包是拉活躍還是拉新失敗的時每款游戲默認返回低價值的拉活躍禮包。

?立體監控

“我們對外提供的服務是否正常的么？怎么證明我們的服務是沒有問題的？”，是監控告警首先要回答的根本問題。有效的監控告警需要保證能完備地監測業務指標，當發現問題時能有效通知負責人并幫助分析問題，強調的是“完備性”和“有效通知”，兩者缺一不可。春節紅包的監控告警從用戶、業務和機器三個層面上描述。

?用戶層面

從用戶的角度監控系統是否有問題，模擬用戶行為從系統外部發起請求，判斷請求結果和時延是否符合預期，使用的是ATT的自動化用例。

ATT，autotest，是社交、開放平臺測試組使用的測試管理工具，它是功能用例、自動化用例管理的平臺。通過模擬真實的用戶訪問并校驗返回數據，確認訪問延時、功能正確性的用戶層的監控手段，從業務側進行實施監控功能的正常運行狀態的工具。

?業務層面

監控紅包系統內部的各個子業務模塊是否運行正常，分為兩種：

1. 模塊間的調用監控

監控系統內部各個模塊間的調用是否正常，使用的是模調系統。

2. 模塊內的狀態監控

監控某個業務模塊當前的狀態是否正常，使用的是各個子系統自建的監控告警系統，春節紅包這方面的監控主要有兩個：AMS禮包領取剩余數量和消息隊列消息堆積數量。春節紅包由于準備的禮包數量較為充足，故沒有引起告警；隊列由于生成速度遠超消費速度，設置的告警閾值是100W，但實際最終堆積超過了1200W，引發了告警。

?機器層面

監控機器的CPU/內存/磁盤/網絡是否正常，使用的是網管系統。

網管系統(TNM2)是一個功能非常強大的采集服務器CPU、內存、網絡、IO等指標的監控系統，同時還能對設備的進程和端口異常、磁盤使用率、硬件故障等進行告警，同時對外部系統提供功能豐富的調用接口，關于網管系統的監控能力，請參考其網站首頁的TMP監控能力白皮書 。

演習驗證

演習是一種將被動相應轉換為主動服務的手段，在演習前設定演習目標和演習方法，在演習過程中進行驗證并收集數據，在演習后進行總結并提出改進方案。通過演習，可以實際驗證用戶行為與評估預期是否一致（灰度演習），系統各個模塊的容量是否符合預期（壓測演習），各類容災和柔性的措施是否生效（異常演習），提前發現架構中存在的問題。

?壓測演習

核心問題：系統能否抗住壓力

細分又可以劃為兩個問題：

• 對于系統容量內的合理請求，系統能否正常處理

• 對于系統容量外的超額請求，系統能否成功丟棄

解決方案：全鏈路壓測和單模塊壓測

最理想的情況是先紅包各個模塊的進行壓測后評估沒有問題，再灰度用戶使用現網流量進入紅包系統進行全鏈路壓測，但由于使用現網流量進行演習需要實際地發送紅包，成本較高，灰度500萬用戶紅包入口峰值僅為5k/s，遠低于設計的80k/s。故對系統的壓力測試驗證主要以單模塊壓測結合灰度演習得到的用戶行為數據評估系統的整體能力。

對于未上線的接口的CGI Server和SPP Server，采用ApachBenchmark模擬請求壓測。

對于已經上線的接口，除了隔離現網機器用ApachBenchmark模擬請求壓測外，還使用了小組自研的壓測系統，通過調整L5權重把現網流量逐步導到一臺機器上來進行壓測。

經驗證，在V8的機器上，禮包列表/區服接口CGI/Server的QPS在5k/s~8k/s之間，禮包領取接口達到2k/s的QPS。在部署足夠的機器后，對于系統80k/s的請求量，是可以正常處理的。

在配置了接入層CGI的限速選項后，超出限速（8k/s）的超額請求會被CGI直接返回錯誤而不傳遞到后端處理；在配置了邏輯層SPP的超時丟棄后，在隊列中堆積超過超時時間（500ms）的堆積請求會被框架丟棄而不進行實際處理。對于超出系統容量的請求，系統是可以成功丟棄的。

?異常演習

核心問題：系統發生異常時各種柔性邏輯/容災措施能否生效

系統中的柔性/容災措施，往往只有系統異常時才會生效，導致在實際現網服務運行中，柔性邏輯經常無法測試到，容災措施一般也不會啟用。這樣，當運營環境真正異常時，柔性邏輯/容災措施是否有效還是個未知數。

解決方案：驗證柔性邏輯和容災措施

在紅包正式上線前，通過模擬故障發生的真實異常場景，列出重點可能發生的故障問題，驗證柔性邏輯和容災錯誤是否真實有效。

• 后臺SPP修改神盾的L5為錯誤的L5，SPP調用神盾出錯，預期后臺依舊能按默認排序返回禮包列表

• 后臺SPP修改CMEM的L5為錯誤的L5，SPP調用CMEM出錯，預期后臺依舊能按全部游戲推薦拉活躍禮包返回禮包列表

• 后臺隨機停掉一臺SPP，CGI調用SPP出錯，預期服務短時間內有部分失敗，L5能在1~2分鐘內踢掉該出錯機器，服務恢復正常

• 打開MQ容災開關，用戶領取成功消息不再放入MQ，而是直接走流水對賬，預期游戲能夠成功到賬

• 前臺用戶操作頻率超過了限制（5次/秒），預期前臺直接返回領取失敗，抓包看到請求不走到后臺

• 前臺調用后臺接口通過設置host指向錯誤IP，前臺調用后臺推薦接口出錯，預期前端頁面依然能正確顯示作為關鍵路徑的禮包列表

• 前臺調用后臺接口通過設置host指向錯誤IP，前臺調用后臺非關鍵信息接口出錯，預期前端頁面對非關鍵模塊進行隱藏

經測試同學驗證，checklist中的柔性邏輯和容災措施確切有效，符合預期。

轉載于:https://www.cnblogs.com/davidwang456/articles/6544418.html

總結

以上是生活随笔為你收集整理的从技术角度谈一谈，我参与设计开发的手Q春节红包项目--转的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。