海量服務實踐──手 Q 遊戲春節紅包項目設計與總結（下篇）

時間 2019-11-13

標籤海量服務實踐遊戲春節紅包項目設計總結下篇欄目系統性能简体版

原文原文鏈接

版權聲明：本文由吳逸翔原創文章，轉載請註明出處:
文章原文連接：https://www.qcloud.com/community/article/275520001486640245前端

來源：騰雲閣 https://www.qcloud.com/community算法

1.需求背景後端
- 1.1.紅包類別
- 1.2.體驗流程
- 1.3.後臺需求
2.需求分析緩存
- 2.1.禮包列表
- 2.2.區服信息
- 2.3.領取禮包
3.總體方案與項目分解安全
4.需求開發服務器
- 4.1.功能需求開發
- 4.2.性能需求開發
- 4.3.容錯需求開發
- 4.4.監控需求開發
5.系統保障網絡
- 5.1.系統容災
- 5.2.過載保護
- 5.3.柔性可用
- 5.4.立體監控
6.演習驗證架構
- 6.1.灰度演習
- 6.2.壓測演習
- 6.3.異常演習
7.總結負載均衡

接海量服務實踐──手 Q 遊戲春節紅包項目設計與總結（上篇）框架

5.系統保障

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

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

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

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

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

5.1.系統容災

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

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

5.1.1.接入層

典型的 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 提供負載均衡和容災。

5.1.2.邏輯層

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

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

5.1.3.數據層

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

5.2.過載保護

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

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

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

從源頭上減小無效請求；
從接入層開始拒絕；
各層互相不信任；
要照顧用戶的情緒。

5.2.1.流量預加載

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

5.2.2.頻率限制

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

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

5.2.3.降級開關

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

5.2.4.隊列堆積丟棄

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

5.3.柔性可用

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

5.3.1.找準用戶的核心訴求

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

看到禮包列表
選擇區服角色
領取禮包到帳

其餘的均可以做爲非關鍵路徑，有能夠提升用戶體驗，沒有也不影響用戶的核心訴求。

5.3.2.保障關鍵路徑的可用

看到禮包列表：做爲頁面關鍵模塊的禮包列表，在紅包活動前，十種遊戲的禮包內容做爲前端靜態數據已經預先經過離線包/CDN下發。紅包活動時，後臺接口根據用戶偏好返回的遊戲禮包列表，只是提供前端禮包內容進行過濾和排序，失敗了也有前端默認的遊戲禮包列表，用戶依舊能看到禮包列表，只是排序不夠智能化。
選擇區服角色：除夕前一週遊戲中心的主站頁面和運營活動增長一個後臺接口請求，預先請求用戶的區服角色信息緩存到本地，既下降了除夕當天的區服接口請求量又保證了遊戲中心核心用戶的區服信息是有效的。
領取禮包到帳：RocketMQ對於領取操做是關鍵路徑服務，用戶領取禮包後須要寫入RocketMQ才能算成功。故業務對消息隊列作了邏輯層面的容災，當RocketMQ出現故障時，能夠打開容災開關，領取操做寫完應發流水後直接返回成功，再也不往RocketMQ寫入消息，採用分時段對帳的方法替代實時發貨，達到消息隊列容災效果，參見4.3.容錯需求開發。

5.3.3.放棄異常的非關鍵路徑

前端頁面展現模塊化，對於請求數據不成功的非關鍵模塊進行隱藏
紅包頁面導流到遊戲中心，遊戲中心展現按紅點邏輯展現，只顯示第一屏的數據，默認不加載第二屏數據，用戶往下滾動時再加載，犧牲用戶往下滾動會短暫卡頓的體驗減小後臺的請求壓力。
後臺讀取算法接口返回的推薦排序失敗時使用默認的禮包排序
後臺讀取CMEM接口返回的禮包是拉活躍仍是拉新失敗的時每款遊戲默認返回低價值的拉活躍禮包

5.4.立體監控

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

5.4.1 用戶層面

從用戶的角度監控系統是否有問題，模擬用戶行爲從系統外部發起請求，判斷請求結果和時延是否符合預期，使用的是ATT的自動化用例。
ATT，autotest，是社交、開放平臺測試組使用的測試管理工具，它是功能用例、自動化用例管理的平臺。經過模擬真實的用戶訪問並校驗返回數據，確認訪問延時、功能正確性的用戶層的監控手段，從業務側進行實施監控功能的正常運行狀態的工具。

5.4.2 業務層面

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

模塊間的調用監控

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

模塊內的狀態監控

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

5.4.3 機器層面

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

6.演習驗證

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

6.1.灰度演習

核心問題：實際的用戶行爲與評估預期是否一致

已知遊戲紅包的入口流量設定是最大80k/s，紅包系統內的各個模塊須要支持的流量是多少？每一個模塊要部署多少機器以支持多大的流量？這個就要涉及到對用戶行爲和各個模塊的轉化率的評估？

解決方案：現網灰度用戶收集數據進行驗證

在現網灰度一部分用戶對遊戲紅包進行驗證，收集數據修正評估模型。結果以下：

入口卡券也到遊戲禮包列表頁的轉化率評估爲60%，實際爲59%，評估與實際至關接近。
區服組件數據前端有緩存，評估請求緩存命中率爲60%，請求到後臺的比例爲40%，實際爲45%，評估與實際至關接近。
遊戲禮包列表頁有10款遊戲，評估每一個用戶平均會領取2個禮包，實際爲0.23個禮包，評估與實際有很大出入。

從以上三個接口的流量評估來看，咱們的開發和產品根據以往經驗評估的用戶行爲數據大部分仍是比較接近實際狀況，但也有不太好評估的接口的灰度數據跟評估預期相差很大。根據灰度數據咱們從新修正了評估模型和模塊容量設計，極大地節約了領取接口的機器。活動當天的數據與灰度獲得的數據相差無幾，也證實了灰度驗證手段是確切可靠的。

6.2.壓測演習

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

細分又能夠劃爲兩個問題：

對於系統容量內的合理請求，系統可否正常處理
對於系統容量外的超額請求，系統可否成功丟棄

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

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