版權聲明：本文由吳逸翔 原創文章，轉載請注明出處:
文章原文連結：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。故對系統的壓力測試驗證主要以單子產品壓測結合灰階演習得到的使用者行為資料評估系統的整體能力。
- 對于未上線的接口的 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)的堆積請求會被架構丢棄而不進行實際處理。對于超出系統容量的請求，系統是可以成功丢棄的。
6.3.異常演習
核心問題：系統發生異常時各種柔性邏輯/容災措施能否生效
系統中的柔性/容災措施，往往隻有系統異常時才會生效，導緻在實際現網服務運作中，柔性邏輯經常無法測試到，容災措施一般也不會啟用。這樣，當營運環境真正異常時，柔性邏輯/容災措施是否有效還是個未知數。
解決方案：驗證柔性邏輯和容災措施
在紅包正式上線前，通過模拟故障發生的真實異常場景，列出重點可能發生的故障問題，驗證柔性邏輯和容災錯誤是否真實有效。
- 背景 SPP 修改神盾的 L5 為錯誤的 L5，SPP 調用神盾出錯，預期背景依舊能按預設排序傳回禮包清單
- 背景 SPP 修改 CMEM 的 L5 為錯誤的 L5，SPP 調用 CMEM 出錯，預期背景依舊能按全部遊戲推薦拉活躍禮包傳回禮包清單
- 背景随機停掉一台 SPP，CGI 調用 SPP出錯，預期服務短時間内有部分失敗，L5 能在 1~2 分鐘内踢掉該出錯機器，服務恢複正常
- 打開 MQ 容災開關，使用者領取成功消息不再放入 MQ，而是直接走流水對賬，預期遊戲能夠成功到賬
- 前台使用者操作頻率超過了限制（5 次/秒），預期前台直接傳回領取失敗，抓包看到請求不走到背景
- 前台調用背景接口通過設定 host 指向錯誤 IP，前台調用背景推薦接口出錯，預期前端頁面依然能正确顯示作為關鍵路徑的禮包清單
- 前台調用背景接口通過設定 host 指向錯誤 IP，前台調用背景非關鍵資訊接口出錯，預期前端頁面對非關鍵子產品進行隐藏
經測試同學驗證，checklist 中的柔性邏輯和容災措施确切有效，符合預期。
7.總結
三個系統功能：禮包清單/區服選擇/禮包發貨
四個開發階段：功能開發/性能開發/容錯開發/監控開發
四種業務保障：系統容災/過載保護/柔性可用/立體監控
三場演習驗證：灰階演習/壓測演習/異常演習