高并發低成本場景“喊紅包”系統的設計與實施

朱建勇，王樂，傅雷，代文章

(中央廣播電視總臺，北京 100866)

1 引 言

微信紅包自從在2015年春晚上大放異彩之后，讓人們傳統思維中的“紅包”產生了一個巨大的轉型，同時也為傳統廣播電視與新媒體平臺進行融合發展提出了一個新思路。很多媒體節目也都在嘗試使用這種模式來增加節目效果及關注度，但想完成一次用戶參與度高、體驗效果好、投入成本低的中大型直播“喊紅包”活動卻并非那么容易。首先面臨的問題就是技術平臺如何才能處理瞬時爆發的巨大數據流量，往往抗住此類流量所要付出的代價是巨大的。2019年百度為央視春晚發紅包活動調動了全球的供應鏈體系、全國的網絡帶寬，使用了10萬臺服務器才完成這項任務。可想要達到預期的效果花費是十分高昂的，很少有企業能夠承擔得起這么高的開銷，因此，節目效果與投入成本成為了兩難問題。

本文研究了如何利用公有云資源結合微信平臺，設計與構建針對全國用戶的低投入、高并發、低延遲的“喊紅包”系統。

2 需求分析

2.1 企業需求分析

融媒體時代，傳統媒體與互聯網媒體融合，互相協作利用“紅包”元素創造出很多成功案例，但也暴露出了一些問題。通常此類項目都會委托第三方新媒體技術服務提供商去完成發放紅包的環節，但受限于預算以及合作方的規模、產品力等問題，發放紅包的實際效果往往不盡如人意。例如，合作方計算資源處理能力不足，當并發數增大時會導致紅包發送卡頓甚至是業務崩潰無法使用，而面對這種情況合作方通常束手無策，無法做出及時有效的應急響應，因為他們的資源和能力確實有限。再比如合作方產品較為固定，在短時間內很難滿足用戶的多變定制化需求。如果是跨地域、大用戶量并發的場景，為了滿足用戶體驗效果，就要選擇規模更大的合作商，但這樣又遠超活動預算。

因此，委托第三方很多時候并不是最佳解決方案。利用互聯網架構下的技術思路，使用成熟的互聯網產品去解決高并發、彈性擴展、安全防護等問題，再配合自主研發的業務系統去處理多變的定制化需求，才是既節約成本又滿足使用效果的可行方案。

下文將以2019年中央廣播電視總臺央廣《中國聲音中國年》直播節目為例，分析探討如何設計并實現這一技術思路。

2.2 業務需求分析

該直播節目分六個時段，每時段由主持人公布“喊紅包”口令，用戶則通過央廣新聞公眾號發送對應的語音口令參與活動。口令正確有機會獲得現金紅包、優惠券、會員卡等福利，口令不正確或未中獎則接收明星主持人新春祝福語或央廣商城推廣頁。

中獎流程如下圖1所示：

圖1 獲得紅包流程圖

①用戶通過手機微信發送正確紅包口令到央廣新聞公眾號；

②微信平臺將語音轉換成文字后發送到網關系統；

③網關系統判斷口令正確且業務系統運行正常，將信息發送給業務系統處理；

④業務系統判斷是否滿足中獎概率，判斷結果為成功獲得紅包獎勵；

⑤訂單系統發送紅包指令給微信紅包模塊；

⑥微信紅包模塊將中獎通知發送給用戶；

⑦用戶點擊領取紅包；

⑧用戶收到現金紅包。

活動前央廣新聞公眾號關注用戶數為67萬，要求用戶必須關注該公眾號才能參與本次活動，從而達到推廣、宣傳增加關注度的目的。各獎品發放需求如下：

?紅包發放需求

①現金紅包累計總金額100萬，最終剩余紅包現金額需低于2萬元；

②所有獎品需可配置優先級；

③要求總時段紅包數量大于60萬個，紅包每人限制領50個；

④每個時段可視發放情況及節目效果隨時調整紅包額度及中獎概率，發送紅包金額最大可調整為58元；

?優惠券及會員發放需求

①央廣商城優惠券和中國廣播會員卡每個微信號限領一次；

②央廣商城會員卡曝光率需高于50%。

整個活動的獎品發放邏輯既要滿足用戶體驗，同時要兼顧自有業務的推廣，根據需求合理設計紅包和各類獎品的發放順序。頁面總瀏覽量需高于1700萬次。

2.3 非功能需求分析

2.3.1 性能需求

響應時間：微信語音接口從發送請求數據到接收響應數據所需要的RT時間不得超過200毫秒。平均響應RT時間不超過100毫秒，高峰時段不超過500毫秒。系統容量：要求系統最大可承載每秒40W萬次QPS(Query Per Second，每秒查詢率)并發處理能力。資源使用率：活動中服務器CPU平均占用率≤80%，內存占用率≤80%。“喊紅包”整體響應時長不得超過3秒。

2.3.2 安全需求

防護多種DDoS類型攻擊，包括但不限于以下攻擊類型：ICMP Flood、UDP Flood、TCP Flood、SYN Flood、ACK Flood 攻擊。防御SQL注入、XSS跨站腳本、常見Web服務器插件漏洞、木馬上傳、非授權核心資源訪問等OWASP常見攻擊，并過濾海量惡意CC攻擊，避免“喊紅包”系統內部數據泄露，保障系統的安全與可用性。

2.3.3 可靠性需求

使用獨立的基礎設施，配置兩個及以上可用區，不同可用區之間基礎設施(網絡，電力和空調等)相互獨立，即一個可用區出現基礎設施故障不影響另外一個可用區。所有服務資源(包括但不限于負載均衡SLB、云服務器ECS)，需具備當主可用區的機房故障或不可用時，可切換到另外一個備可用區的機房并恢復服務的能力；當主可用區恢復時，資源同樣會自動切換到主可用區的機房提供服務。

2.3.4 高可用需求

系統需部署在電力和網絡互相獨立的不同物理區域內，將故障隔離在一個可用區中。系統需能夠根據應用負載情況進行彈性擴容，做到任意一臺設備故障或流量波動都不中斷對外服務。

3 系統設計

3.1 系統設計原則

“喊紅包”系統設計時，綜合考慮了《中國聲音中國年》直播節目的影響力及重要性，借鑒了先進的技術路線，采取全面的安全保護措施，保證系統體系的先進性、開放性和實用性。在滿足系統功能及性能要求的前提下，盡量降低系統建設成本，采用經濟實用的方式，利用互聯網資源，綜合考慮系統的整體費用。在符合標準化原則，遵循國家標準、行業和相關規范的同時，力爭打造出在高并發場景下保證系統穩定性及用戶體驗的通用型產品，為后期類似業務的開展起到示范作用。

3.2 系統體系架構設計

根據對央廣信息化系統的需求分析，提出符合“中國聲音中國年”活動要求的“新春喊紅包”系統的設計方案。利用微信開發者平臺實現用戶身份驗證及語音轉換功能，利用阿里云實現計算資源彈性擴展及安全防護功能。

系統總體架構設計如下圖2所示，主要分為：表示層、業務邏輯層和數據層，這種架構確保了責任的明確劃分，使系統更加易于維護和擴展。

圖2 系統體系架構圖

表現層位于最外層，是“喊紅包”系統的系統管理、數據統計、用戶參與界面，主要完成中獎參數變更、用戶交流、參與人數和獎品發放量統計等工作；其中，央廣新聞公眾號頁面由微信平臺提供。

業務邏輯層包括網關系統、業務系統和訂單系統，位于數據層和表現層之間，其可通過數據層提交的數據為表現層提供良好的數據支撐。

數據層是支撐整個系統的基礎，使用阿里云RDS Mysql和RDS Redis存儲中獎信息和配置信息，保證系統數據安全、數據流入流出高效。

3.3 系統基礎架構設計

整體系統基礎架構分為五層：接入層、網關層、業務層、數據庫層和支付業務層，圖3為系統基礎架構圖。

圖3 系統基礎架構圖

3.3.1 接入層

接入層主要處理數據流量的接入和安全，中間使用阿里云的高防IP(DDOS)和WAF組件以阻擋網絡三層、七層上的流量攻擊和業務漏洞攻擊。預計在喊紅包活動中，可能出現的攻擊手段是DDOS泛洪攻擊、SQL注入和XSS注入攻擊。通過使用阿里云高防產品，將正常的數據流量經過阿里高防集群，對流量進行清洗和梳理，卸載其中的異常流量，達到防治DDOS攻擊的目的。針對SQL注入和XSS注入攻擊，使用阿里云WAF等安全組件，梳理系統中所有的參數提交關鍵點，對異常代碼、代碼注入、惡意代碼提交、代碼語義篡改等行為進行審計和攔截，確保未經過安全審核的代碼無法提交到系統中，保證系統在應用層面是安全可靠的。

3.3.2 網關層

網關層在整個系統基礎架構中起到業務數據流量的接入及分發的功能。由標準的SLB負載均衡組件和Nginx服務器組成。其中，單臺SLB能承擔5萬/秒的QPS并發。在SLB后接入的Nginx能承擔2萬/秒的QPS并發。從整體上看，網關層的接入性能較高，可以滿足“喊紅包”業務的高并發接入需求。使用Lua語言對Nginx層進行擴展，流量抵達Nginx層后，會根據條件判斷返回用戶中獎結果或者選擇繼續抵達業務層。通過代碼對用戶流量進行限流，實現后端業務層的并發性能可控，確保業務系統的性能安全。

3.3.3 業務層

業務層通過概率計算中獎的結果，并且將中獎信息、相關業務信息，例如用戶身份數據等寫入后面的數據庫。為避免計算成本過高，在此層盡量不處理未中獎的情況。

3.3.4 數據庫層

綜合考慮數據庫系統容災，借助阿里云的一些邏輯復制工具，對數據庫層的數據進行邏輯復制，避免數據庫物理層面的故障，例如跨可用區實例，數據庫實例三副本，以及數據庫數據實時備份等等。其中，在高并發下的數據庫高可用、容災方案設計需要考慮的因素較多，因涉及到大量數據，實施起來難度較大。

3.3.5 支付業務層

支付層需要針對業務層產生的紅包訂單，進行計算和處理。根據微信的需求，在發紅包速度上有一定限制，所以支付業務層定時成批處理數據庫中的訂單數據，調用微信接口對紅包進行發送。在滿足微信發紅包限制的基礎之上，需要將紅包快速、穩定的發放到用戶手中。經過三輪壓力測試，最終實現了紅包在10分鐘之內發到用戶賬戶的目標。

系統基礎架構中的各個層次都綜合考慮高可用和高并發，所有邏輯層中的計算資源(包括數據庫)都實現跨區高可用，一旦發生系統宕機、整個可用區發生故障等災難，會在第一時間進行無縫切換，將高并發下的活動影響降到最低。另外，在計算資源中除數據庫外，均已實現系統資源的動態擴容。系統資源可在3-5分鐘擴容翻倍，以應對活動中突發資源需求的挑戰。

3.4 系統網絡拓撲設計

所有服務器均部署在阿里云中，云下數據中心作為管理區域，對系統進行監控、調整。云上數據中心與云下數據中心使用兩根不同運營商的專線連接在一起，并在鏈路中間部署物理防火墻，啟用過濾功能防止未知流量進入，保護業務安全。防火墻開啟冗余功能，當主用線路出現問題時，防火墻將自動感知并迅速切換到備鏈路，阿里云邊界路由器同時感知故障，進行聯動切換，切換過程會出現1至2個丟包，業務層不受任何影響。

如圖4所示，阿里云內部按照業務創建四臺虛擬交換機，分別為訂單、數據庫、業務、網關系統提供服務。每類業務對應的虛擬交換機分別部署于北京的兩個不同機房中。可用區之間通過邊界路由器VBR相連，為紅包業務提供負載冗余能力，當某一可用區出現問題時，另一可用區將直接接管，承擔所有業務功能。使用阿里云200M互聯網出口并針對支付區配置SNAT，使支付區可與互聯網通信，將NAT規則升配至超大型，最大支持200萬連接數，保障紅包業務平穩運行。

圖4 系統網絡拓撲結構圖

3.5 系統接口設計

“喊紅包”系統通過與微信開發者平臺的API做集成，實現微信公眾號各項功能的對接。外部接口按數據流向可分為上行接口和下行接口。各類接口需滿足表1的規則。

3.5.1 上行接口

實現用戶身份確認，對接微信語音輸入轉文字的結果數據，將微信公眾號中的語音喊紅包的結果輸入到網關系統的概率邏輯控制模塊，完成語音輸入的上行功能。

接收用戶語音消息：當用戶發送消息給公眾號時(或某些特定的用戶操作引發的事件推送時)，會產生一個POST請求，“喊紅包”系統在響應包(Get)中返回特定XML結構，來對該消息進行響應。嚴格來說，發送被動響應消息其實并不是一種接口，而是對微信服務器發過來消息的一次回復。接收微信的語音轉文字XML內容接口，微信返回語音格式如表2。

表1 微信接口規則表

表2 回復語音消息的XML數據包結構表

3.5.2 下行接口

接收其他各系統返回給微信公眾號的反饋信息，使用這些反饋信息調用微信接口，壓入下行的隊列中，反饋紅包中獎狀態。

發送用戶紅包：通過微信平臺向微信支付用戶發放現金紅包。用戶領取紅包后，資金到達用戶微信支付零錢賬戶，和零錢包的其他資金有一樣的使用出口。若用戶未領取，資金將會在24小時后退回商戶的微信支付賬戶中。

3.6 系統業務邏輯設計

喊紅包業務邏輯場景分為中獎和未中獎兩個結果。未中獎的原因不只是口令錯誤這一種可能，還有可能為網關系統容錯機制生效、用戶發送空語音、非語音、數據量過大致使網關系統消峰處理、未達到中獎概率等情況。雖然未獲得紅包獎勵，但用戶可接收到事先編輯好的明星祝福語或央廣商城宣傳頁頁，從而達到宣傳自身產品及營造節日氣氛的效果。當用戶中獎時，除得到紅包獎勵外還可能得到央廣商城購物券、央廣商場會員卡和中國廣播會員卡，具體獎品發放邏輯如下表3所示。

表3 獎品發放邏輯表

4 系統壓力測試

4.1 測試工具及測試環境

測試工具：Locust壓力測試工具，python腳本

測試環境：測試中使用的應用服務器配置及說明信息見表4。

4.2 測試流程

具體測試內容如表5所示。

4.3 典型功能測試用例

具體測試用例見表6。

表4 壓力測試環境設備配置列表

表5 系統壓力測試內容列表

表6 系統管理子系統功能測試表

續表

測試結果顯示：與目標結果一致，達到預定目標。

4.4 壓力測試

測試功能項：業務系統壓力測試

測試步驟：

業務系統1臺php服務器，連接redis和mysql，服務器掛載到SLB下；

locust向業務系統SLB打壓，模擬微信端的喊紅包請求；

獲得紅包的訂單寫入mysql，查詢從redis中讀取。

預期結果：1臺php服務器承受QPS達到1500次/秒，無5XX報錯

測試結果：和預期結果基本一致

在壓力測試過程中SLB的QPS保持在1400—1600之間，response time維持在20-40ms/個之間，未出現5XX狀態碼。相關測試指標如下圖5-圖7。

在壓力測試過程中PHP服務器的CPU使用率維持在60%左右，內存基本無消耗，系統平均負載低于CPU核數。在模擬實際微信“喊紅包”，微信端向系統POST XML格式數據包的場景下，網絡流入流出速率保持在28-38Mbps之間，TCP連接數總數保持在4.8k，無明顯波動。具體見圖8、圖9所示。

圖5 業務系統SLB壓力測試QPS圖

圖6 業務系統SLB壓力測試response time圖

圖7 業務系統SLB壓力測試5XX狀態碼圖

圖8 業務系統PHP壓力測試的資源使用情況圖

圖9 業務系統PHP壓力測試的網絡數據圖

測試功能項：網關系統壓力測試。

測試步驟：

網關系統1臺nginx服務器，服務器掛載到SLB下；

locust向網關系統SLB打壓

預期結果：1臺nginx服務器承受QPS達到25000次/秒

測試結果：和預期結果基本一致

在壓力測試過程中，SLB上的QPS在24783次/秒左右，最大并發連接數50351個，實際業務場景中共使用了10臺SLB，參照此測試結果完全可以滿足40W并發量的業務需求，相關壓力測試數據如下圖10、圖11所示。

Nginx服務器網絡流入流出速率在140-250Mbps之間，TCP連接數維持在5500個左右，無明顯波動，實際業務場景中共使用20臺Nginx服務器。單臺Nginx相關壓力測試數據如下圖12所示。

圖10 網關系統SLB壓力測試QPS圖

圖11 網關系統SLB最大并發圖

圖12 網關系統Nginx網絡流量圖

4.5 測試結果分析

符合新春“喊紅包”活動功能及性能的需求。同時，在模擬用戶并發使用和持續運行中，系統未出現不良反應，響應時間令人滿意，系統穩定性比較可靠。

5 系統實施

5.1 實施環境

具體軟硬件環境配置如下表7所示。

5.2 系統上線

準備工作完成后由資源部署組完成系統的實施工作，主要工作內容如下：

梳理出自動化擴容、代碼更新、健康檢查等應用場景以及操作流程，各場景相關的配置參數整理成配置文件；

網關層限流配置進行最后確認，通過壓測進行限流配置的校驗；

網關系統、業務系統、訂單系統分別創建ECS鏡像，為活動當天擴容做準備；

網關系統準備若干臺ECS和SLB，用于業務并發過高時的備用；

創建最小災備環境，在極端情況下上線使用；

使用自動化擴容腳本生成的ECS，在上線前，通過健康檢查腳本進行服務可用性檢查；

更新微信白名單IP，重新創建WAF規則；

發布最終版代碼，上線前三天封版；

上線前一天修改SLB網絡模式為按帶寬付費；

清空所有日志、數據庫的測試數據，數據庫導入生產數據；

活動當天前一小時，通過壓測進行系統預熱。

5.3 實施效果

2019年2月4日(除夕)12點至18點，喊紅包互動人次突破3500萬，央廣新聞公眾號粉絲增長15萬。當天所有發放紅包、優惠券、會員卡等任務均達到預定目標，獎品具體分配情況及實際發放數如下表8所示。

表7 系統實施軟硬件配置表

表8 獎品分配表

數據統計頁面實時顯示獎品發放情況，電臺主持人根據數據隨時與后臺工程師溝通，結合節目進程和節目效果更改紅包金額從而達到調動聽眾情緒的效果。數據統計頁面如下圖13所示。

用戶喊紅包過程系統響應積極，未出現卡頓情況，平均響應RT時間未超過100毫秒，高峰時段不超過500毫秒。

圖13 數據統計頁面圖

6 結論

本文針對高并發場景、低成本“喊紅包”系統的整體架構設計進行了深入的研究和應用。該系統在實際應用中取得了較好的效果和積極的反響，在2019年中央廣播電視總臺央廣春節特別節目《中國聲音中國年》中，使用80臺服務器抗住來自全國總計3500萬人次的流量海嘯，順利完成高并發場景下的紅包發放任務，聽眾普遍反映良好。同時，該系統設計方案具有比較重要的指導意義，可為傳統媒體結合新媒體技術搭建互動平臺提供一定參考。