默認
打賞 發表評論 0
社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等
閱讀(1113) | 評論(0 收藏1 淘帖2 1

本文來自騰訊云技術社區的分享,原作者:吳逸翔,原題《從技術角度談一談,我參與設計開發的手Q春節紅包項目》,收錄時有改動。


一、引言


春節期間,QQ以AR技術為支撐、娛樂體驗為導向在春節期間推出了系列紅包。

系列紅包包括三大玩法+年初一彩蛋,分別是“LBS+AR天降紅包”、刷一刷紅包和“面對面”紅包,加上“娛樂紅包”(明星刷臉紅包)。以2017年為例,共計在春節期間派發了2.5億現金紅包和價值30億的卡券禮包。根據企鵝智酷提供的數據,手機QQ的用戶滲透率在全平臺排名第二,為52.9%(第一是微信)。

本文將會詳細介紹手Q春節紅包項目的功能設計/邏輯、容災、運維、架構以及實踐總結。

補充說明:QQ團隊的另一篇分享《社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等》,講述了更多技術方面的細節,有興趣也可以一讀。

二、系列文章


❶ 系列文章目錄:


❷ 其它相關文章:

三、產品功能需求


3.1、紅包類別


以2017 年的手 Q 春節游戲紅包為例,共有刷一刷/ AR 地圖/掃福三種。

如下圖所示:
社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_1.jpg

3.2、體驗流程


雖然紅包分三種,但在游戲業務側這邊的體驗都是一樣:

  • 1)用戶得到一個紅包卡券,打開后展示一個(刷一刷紅包)或者多個( AR 地圖紅包)游戲的禮包列表;
  • 2)用戶選擇一個禮包后彈出區服組件;
  • 3)用戶確認對應的區服角色信息后會禮包會在 48 個小時內發放到賬。

體驗如下:
社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_2.png

3.3、后臺需求


游戲紅包的設計容量為入口卡券頁流量 80k/s,以上體驗流程一共涉及三個后臺接口:
社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_3.jpg

三個后臺接口分別是:

  • 1)禮包列表:用戶界面的禮包內容需要根據后臺接口返回禮包列表進行排序和過濾展示;
  • 2)區服選擇:用戶界面彈出的區服組件需要后臺接口返回用戶區服角色信息;
  • 3)領取禮包:用戶點擊“確認”按鈕領取禮包,后臺進行游戲道具發貨。

四、需求拆解和分析


4.1、禮包列表


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

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


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

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

4.2、區服信息


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

4.3、領取禮包


這個功能使用現有能力解決存在困難。游戲中心日常發貨的道具和平臺比較多,平臺分為 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 異步發貨功能的開發,在春節紅包中應用,再將這個功能交接給平臺側的同學維護,達到雙贏的效果。

五、整體方案與項目分解


社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_4.png
注意:因本圖較大,清晰大圖請從此附件下載 整體方案圖(清晰大圖).zip (769.6 KB , 下載次數: 1 )

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

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

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

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

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

六、實際需求開發


6.1、功能需求開發


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

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

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

但{3.1 后臺禮包推薦接口}接口返回的是多個游戲的禮包列表,需要獲取十個游戲的用戶注冊狀態。

如果讀取 AMS 現有的接口/存儲,會有兩個問題:

  • 1)AMS 號碼包服務也要承受等同于推薦列表接口 48k/s 的流量,需要進行擴容;
  • 2)AMS 號碼包服務調用 CMEM 雖然可以一次請求合并 10 個 key 進行批量讀取,但請求到了 CMEM 的 Access 機還是要讀取多個 Cache 塊,性能并不如單請求單 key 讀取。

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_5.jpg

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

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

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_6.jpg

6.2、性能需求開發


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

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_7.jpg

➋ 解決方案:發貨異步化

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_8.jpg

6.3、容錯需求開發


➊ 核心問題:安全發貨

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

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

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

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_9.jpg

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

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

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

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

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

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_10.jpg

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

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_11.jpg

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

  • 對于發貨的機器都要安裝鐵將軍,用戶需要使用 RTX 名和 token 才能登錄機器,審計用戶在機器上的操作行為;
  • 發貨模塊對于調用方是需要嚴格授權,調用方需要申請 key,包含程序路徑、程序 MD5、部署模塊等信息,保證發貨功能不被隨意調用。

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_12.jpg

6.4、監控需求開發


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

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

  • 1)我們對外提供的服務是否正常?如果有問題,如何快速地發現問題、分析問題?
  • 2)實時知道用戶在整個系統的行為漏斗模型,每一步的轉化率是多少?

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_13.jpg
注意:因本圖較大,清晰大圖請從此附件下載 13(清晰大圖).zip (855.33 KB , 下載次數: 1 )

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

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

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

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

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_14.jpg

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

七、系統保障


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

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

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

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

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

7.1、系統容災


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

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

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

7.1.2 邏輯層:

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

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

7.1.3 數據層:

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_1.jpg

7.2、過載保護


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

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

對于可能出現的超過了設計容量的流量尖峰,就要應用過載保護方法,保障系統能拒絕超過容量的部分請求,保障設計容量內的請求還能正常響應。

實施的時候有四個要注意的地方:

  • 1)從源頭上減少無效請求;
  • 2)從接入層開始拒絕;
  • 3)各層互相不信任;
  • 4)要照顧用戶的情緒。

7.2.1 流量預加載:

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

7.2.2 頻率限制:

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

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

7.2.3 降級開關:

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

7.2.4 隊列堆積丟棄:

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_2.jpg

7.3、柔性可用


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

7.3.1 找準用戶的核心訴求:

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

  • 1)看到禮包列表;
  • 2)選擇區服角色;
  • 3)領取禮包到賬。

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

7.3.2 保障關鍵路徑的可用:

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

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

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

7.3.3 放棄異常的非關鍵路徑:

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_3.jpg

7.4、立體監控


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

7.4.1 用戶層面:

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

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

7.4.2 業務層面:

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

  • a. 模塊間的調用監控:監控系統內部各個模塊間的調用是否正常,使用的是模調系統。
  • b. 模塊內的狀態監控:監控某個業務模塊當前的狀態是否正常,使用的是各個子系統自建的監控告警系統。

春節紅包這方面的監控主要有兩個: AMS禮包領取剩余數量和消息隊列消息堆積數量。春節紅包由于準備的禮包數量較為充足,故沒有引起告警;隊列由于生成速度遠超消費速度,設置的告警閾值是100W,但實際最終堆積超過了1200W,引發了告警。

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_44.jpg

7.4.3 機器層面:

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

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_4.jpg

八、演習驗證


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

8.1、灰度演習


➊ 核心問題:實際的用戶行為與評估預期是否一致

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

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

在現網灰度一部分用戶對游戲紅包進行驗證,收集數據修正評估模型。

結果如下:

  • a. 入口卡券也到游戲禮包列表頁的轉化率評估為60%,實際為59%,評估與實際相當接近;
  • b. 區服組件數據前端有緩存,評估請求緩存命中率為60%,請求到后臺的比例為40%,實際為45%,評估與實際相當接近;
  • c. 游戲禮包列表頁有10款游戲,評估每個用戶平均會領取2個禮包,實際為0.23個禮包,評估與實際有很大出入。

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_5.jpg

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

8.2、壓測演習


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

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

  • a. 對于系統容量內的合理請求,系統能否正常處理;
  • b. 對于系統容量外的超額請求,系統能否成功丟棄。

]➋ 解決方案:全鏈路壓測和單模塊壓測

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

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

社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等_6.jpg

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

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

8.3、異常演習


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

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

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

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

  • a. 后臺 SPP 修改神盾的 L5 為錯誤的 L5,SPP 調用神盾出錯,預期后臺依舊能按默認排序返回禮包列表。
  • b. 后臺 SPP 修改 CMEM 的 L5 為錯誤的 L5,SPP 調用 CMEM 出錯,預期后臺依舊能按全部游戲推薦拉活躍禮包返回禮包列表。
  • c. 后臺隨機停掉一臺 SPP,CGI 調用 SPP出錯,預期服務短時間內有部分失敗,L5 能在 1~2 分鐘內踢掉該出錯機器,服務恢復正常。
  • d. 打開 MQ 容災開關,用戶領取成功消息不再放入 MQ,而是直接走流水對賬,預期游戲能夠成功到賬。
  • e. 前臺用戶操作頻率超過了限制(5 次/秒),預期前臺直接返回領取失敗,抓包看到請求不走到后臺。
  • f. 前臺調用后臺接口通過設置 host 指向錯誤 IP,前臺調用后臺推薦接口出錯,預期前端頁面依然能正確顯示作為關鍵路徑的禮包列表。
  • g. 前臺調用后臺接口通過設置 host 指向錯誤 IP,前臺調用后臺非關鍵信息接口出錯,預期前端頁面對非關鍵模塊進行隱藏。

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

九、總結


針對本文內容,我們總結一下手Q的紅包系統:

  • 三個系統功能:禮包列表/區服選擇/禮包發貨;
  • 四個開發階段:功能開發/性能開發/容錯開發/監控開發;
  • 四種業務保障:系統容災/過載保護/柔性可用/立體監控;
  • 三場演習驗證:灰度演習/壓測演習/異常演習。

附錄1:有關微信、QQ的技術文章匯總


微信朋友圈千億訪問量背后的技術挑戰和實踐總結
騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)
騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)
微信團隊分享:微信移動端的全文檢索多音字問題解決方案
騰訊技術分享:Android版手機QQ的緩存監控與優化實踐
微信團隊分享:iOS版微信的高性能通用key-value組件技術實踐
微信團隊分享:iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的?
騰訊技術分享:Android手Q的線程死鎖監控系統技術實踐
微信團隊原創分享:iOS版微信的內存監控系統技術實踐
讓互聯網更快:新一代QUIC協議在騰訊的技術實踐分享
iOS后臺喚醒實戰:微信收款到賬語音提醒技術總結
騰訊技術分享:社交網絡圖片的帶寬壓縮技術演進之路
微信團隊分享:視頻圖像的超分辨率技術原理和應用場景
微信團隊分享:微信每日億次實時音視頻聊天背后的技術解密
QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)
QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)
騰訊團隊分享:手機QQ中的人臉識別酷炫動畫效果實現詳解
騰訊團隊分享 :一次手Q聊天界面中圖片顯示bug的追蹤過程分享
微信團隊分享:微信Android版小視頻編碼填過的那些坑
微信手機端的本地數據全文檢索優化之路
企業微信客戶端中組織架構數據的同步更新方案優化實戰
微信團隊披露:微信界面卡死超級bug“15。。。。”的來龍去脈
QQ 18年:解密8億月活的QQ后臺服務接口隔離技術
月活8.89億的超級IM微信是如何進行Android端兼容測試的
以手機QQ為例探討移動端IM中的“輕應用”
一篇文章get微信開源移動端數據庫組件WCDB的一切!
微信客戶端團隊負責人技術訪談:如何著手客戶端性能監控和優化
微信后臺基于時間序的海量數據冷熱分級架構設計實踐
微信團隊原創分享:Android版微信的臃腫之困與模塊化實踐之路
微信后臺團隊:微信后臺異步消息隊列的優化升級實踐分享
微信團隊原創分享:微信客戶端SQLite數據庫損壞修復實踐
騰訊原創分享(一):如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率
騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(下篇)
騰訊原創分享(三):如何大幅壓縮移動網絡下APP的流量消耗(上篇)
微信Mars:微信內部正在使用的網絡層封裝庫,即將開源
如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源
開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]
微信新一代通信安全解決方案:基于TLS1.3的MMTLS詳解
微信團隊原創分享:Android版微信后臺保活實戰分享(進程保活篇)
微信團隊原創分享:Android版微信后臺保活實戰分享(網絡保活篇)
Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]
微信團隊原創分享:Android版微信從300KB到30MB的技術演進
微信技術總監談架構:微信之道——大道至簡(演講全文)
微信技術總監談架構:微信之道——大道至簡(PPT講稿) [附件下載]
如何解讀《微信技術總監談架構:微信之道——大道至簡》
微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]
微信異步化改造實踐:8億月活、單機千萬連接背后的后臺解決方案
微信朋友圈海量技術之道PPT [附件下載]
微信對網絡影響的技術試驗及分析(論文全文)
一份微信后臺技術架構的總結性筆記
架構之道:3個程序員成就微信朋友圈日均10億發布量[有視頻]
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
快速裂變:見證微信強大后臺架構從0到1的演進歷程(二)
微信團隊原創分享:Android內存泄漏監控和優化技巧總結
全面總結iOS版微信升級iOS9遇到的各種“坑”
微信團隊原創資源混淆工具:讓你的APK立減1M
微信團隊原創Android資源混淆工具:AndResGuard [有源碼]
Android版微信安裝包“減肥”實戰記錄
iOS版微信安裝包“減肥”實戰記錄
移動端IM實踐:iOS版微信界面卡頓監測方案
微信“紅包照片”背后的技術難題
移動端IM實踐:iOS版微信小視頻功能技術方案實錄
移動端IM實踐:Android版微信如何大幅提升交互性能(一)
移動端IM實踐:Android版微信如何大幅提升交互性能(二)
移動端IM實踐:實現Android版微信的智能心跳機制
移動端IM實踐:WhatsApp、Line、微信的心跳策略分析
移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)
移動端IM實踐:iOS版微信的多設備字體適配方案探討
信鴿團隊原創:一起走過 iOS10 上消息推送(APNS)的坑
騰訊信鴿技術分享:百億級實時消息推送的實戰經驗
IPv6技術詳解:基本概念、應用現狀、技術實踐(上篇)
IPv6技術詳解:基本概念、應用現狀、技術實踐(下篇)
騰訊TEG團隊原創:基于MySQL的分布式數據庫TDSQL十年鍛造經驗分享
微信多媒體團隊訪談:音視頻開發的學習、微信的音視頻技術和挑戰等
了解iOS消息推送一文就夠:史上最全iOS Push技術詳解
騰訊技術分享:微信小程序音視頻技術背后的故事
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
微信多媒體團隊梁俊斌訪談:聊一聊我所了解的音視頻技術
騰訊音視頻實驗室:使用AI黑科技實現超低碼率的高清實時視頻聊天
騰訊技術分享:微信小程序音視頻與WebRTC互通的技術思路和實踐
手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術研究學習)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)
騰訊技術分享:GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐
微信團隊分享:Kotlin漸被認可,Android版微信的技術嘗鮮之旅
QQ設計團隊分享:新版 QQ 8.0 語音消息改版背后的功能設計思路
>> 更多同類文章 ……

附錄2:更多架構方面的文章匯總


[1] 有關IM架構設計的文章:
淺談IM系統的架構設計
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)
一套原創分布式即時通訊(IM)系統理論架構方案
從零到卓越:京東客服即時通訊系統的技術架構演進歷程
蘑菇街即時通訊/IM服務器開發之架構選擇
騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT
微信后臺基于時間序的海量數據冷熱分級架構設計實踐
微信技術總監談架構:微信之道——大道至簡(演講全文)
如何解讀《微信技術總監談架構:微信之道——大道至簡》
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
17年的實踐:騰訊海量產品的技術方法論
移動端IM中大規模群消息的推送如何保證效率、實時性?
現代IM系統中聊天消息的同步和存儲方案探討
IM開發基礎知識補課(二):如何設計大量圖片文件的服務端存儲架構?
IM開發基礎知識補課(三):快速理解服務端數據庫讀寫分離原理及實踐建議
IM開發基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token
WhatsApp技術實踐分享:32人工程團隊創造的技術神話
微信朋友圈千億訪問量背后的技術挑戰和實踐總結
王者榮耀2億用戶量的背后:產品定位、技術架構、網絡方案等
IM系統的MQ消息中間件選型:Kafka還是RabbitMQ?
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
以微博類應用場景為例,總結海量社交系統的架構設計步驟
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
IM開發基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列
微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
>> 更多同類文章 ……

[2] 更多其它架構設計相關文章:
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
達達O2O后臺架構演進實踐:從0到4000高并發請求背后的努力
優秀后端架構師必會知識:史上最全MySQL大表優化方案總結
小米技術分享:解密小米搶購系統千萬高并發架構的演進和實踐
一篇讀懂分布式架構下的負載均衡技術:分類、原理、算法、常見方案等
通俗易懂:如何設計能支撐百萬并發的數據庫架構?
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:社交軟件紅包技術解密(八):全面解密微博紅包技術方案下一篇:即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?

本帖已收錄至以下技術專輯

推薦方案
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特