高并發(fā)低成本場景“喊紅包”系統(tǒng)的設(shè)計與實施

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

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

1 引 言

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

本文研究了如何利用公有云資源結(jié)合微信平臺，設(shè)計與構(gòu)建針對全國用戶的低投入、高并發(fā)、低延遲的“喊紅包”系統(tǒng)。

2 需求分析

2.1 企業(yè)需求分析

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

因此，委托第三方很多時候并不是最佳解決方案。利用互聯(lián)網(wǎng)架構(gòu)下的技術(shù)思路，使用成熟的互聯(lián)網(wǎng)產(chǎn)品去解決高并發(fā)、彈性擴展、安全防護等問題，再配合自主研發(fā)的業(yè)務(wù)系統(tǒng)去處理多變的定制化需求，才是既節(jié)約成本又滿足使用效果的可行方案。

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

2.2 業(yè)務(wù)需求分析

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

中獎流程如下圖1所示：

圖1 獲得紅包流程圖

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

②微信平臺將語音轉(zhuǎn)換成文字后發(fā)送到網(wǎng)關(guān)系統(tǒng)；

③網(wǎng)關(guān)系統(tǒng)判斷口令正確且業(yè)務(wù)系統(tǒng)運行正常，將信息發(fā)送給業(yè)務(wù)系統(tǒng)處理；

④業(yè)務(wù)系統(tǒng)判斷是否滿足中獎概率，判斷結(jié)果為成功獲得紅包獎勵；

⑤訂單系統(tǒng)發(fā)送紅包指令給微信紅包模塊；

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

⑦用戶點擊領(lǐng)取紅包；

⑧用戶收到現(xiàn)金紅包。

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

?紅包發(fā)放需求

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

②所有獎品需可配置優(yōu)先級；

③要求總時段紅包數(shù)量大于60萬個，紅包每人限制領(lǐng)50個；

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

?優(yōu)惠券及會員發(fā)放需求

①央廣商城優(yōu)惠券和中國廣播會員卡每個微信號限領(lǐng)一次；

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

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

2.3 非功能需求分析

2.3.1 性能需求

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

2.3.2 安全需求

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

2.3.3 可靠性需求

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

2.3.4 高可用需求

系統(tǒng)需部署在電力和網(wǎng)絡(luò)互相獨立的不同物理區(qū)域內(nèi)，將故障隔離在一個可用區(qū)中。系統(tǒng)需能夠根據(jù)應(yīng)用負載情況進行彈性擴容，做到任意一臺設(shè)備故障或流量波動都不中斷對外服務(wù)。

3 系統(tǒng)設(shè)計

3.1 系統(tǒng)設(shè)計原則

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

3.2 系統(tǒng)體系架構(gòu)設(shè)計

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

系統(tǒng)總體架構(gòu)設(shè)計如下圖2所示，主要分為：表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)層，這種架構(gòu)確保了責(zé)任的明確劃分，使系統(tǒng)更加易于維護和擴展。

圖2 系統(tǒng)體系架構(gòu)圖

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

業(yè)務(wù)邏輯層包括網(wǎng)關(guān)系統(tǒng)、業(yè)務(wù)系統(tǒng)和訂單系統(tǒng)，位于數(shù)據(jù)層和表現(xiàn)層之間，其可通過數(shù)據(jù)層提交的數(shù)據(jù)為表現(xiàn)層提供良好的數(shù)據(jù)支撐。

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

3.3 系統(tǒng)基礎(chǔ)架構(gòu)設(shè)計

整體系統(tǒng)基礎(chǔ)架構(gòu)分為五層：接入層、網(wǎng)關(guān)層、業(yè)務(wù)層、數(shù)據(jù)庫層和支付業(yè)務(wù)層，圖3為系統(tǒng)基礎(chǔ)架構(gòu)圖。

圖3 系統(tǒng)基礎(chǔ)架構(gòu)圖

3.3.1 接入層

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

3.3.2 網(wǎng)關(guān)層

網(wǎng)關(guān)層在整個系統(tǒng)基礎(chǔ)架構(gòu)中起到業(yè)務(wù)數(shù)據(jù)流量的接入及分發(fā)的功能。由標(biāo)準(zhǔn)的SLB負載均衡組件和Nginx服務(wù)器組成。其中，單臺SLB能承擔(dān)5萬/秒的QPS并發(fā)。在SLB后接入的Nginx能承擔(dān)2萬/秒的QPS并發(fā)。從整體上看，網(wǎng)關(guān)層的接入性能較高，可以滿足“喊紅包”業(yè)務(wù)的高并發(fā)接入需求。使用Lua語言對Nginx層進行擴展，流量抵達Nginx層后，會根據(jù)條件判斷返回用戶中獎結(jié)果或者選擇繼續(xù)抵達業(yè)務(wù)層。通過代碼對用戶流量進行限流，實現(xiàn)后端業(yè)務(wù)層的并發(fā)性能可控，確保業(yè)務(wù)系統(tǒng)的性能安全。

3.3.3 業(yè)務(wù)層

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

3.3.4 數(shù)據(jù)庫層

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

3.3.5 支付業(yè)務(wù)層

支付層需要針對業(yè)務(wù)層產(chǎn)生的紅包訂單，進行計算和處理。根據(jù)微信的需求，在發(fā)紅包速度上有一定限制，所以支付業(yè)務(wù)層定時成批處理數(shù)據(jù)庫中的訂單數(shù)據(jù)，調(diào)用微信接口對紅包進行發(fā)送。在滿足微信發(fā)紅包限制的基礎(chǔ)之上，需要將紅包快速、穩(wěn)定的發(fā)放到用戶手中。經(jīng)過三輪壓力測試，最終實現(xiàn)了紅包在10分鐘之內(nèi)發(fā)到用戶賬戶的目標(biāo)。

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

3.4 系統(tǒng)網(wǎng)絡(luò)拓撲設(shè)計

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

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

圖4 系統(tǒng)網(wǎng)絡(luò)拓撲結(jié)構(gòu)圖

3.5 系統(tǒng)接口設(shè)計

“喊紅包”系統(tǒng)通過與微信開發(fā)者平臺的API做集成，實現(xiàn)微信公眾號各項功能的對接。外部接口按數(shù)據(jù)流向可分為上行接口和下行接口。各類接口需滿足表1的規(guī)則。

3.5.1 上行接口

實現(xiàn)用戶身份確認(rèn)，對接微信語音輸入轉(zhuǎn)文字的結(jié)果數(shù)據(jù)，將微信公眾號中的語音喊紅包的結(jié)果輸入到網(wǎng)關(guān)系統(tǒng)的概率邏輯控制模塊，完成語音輸入的上行功能。

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

表1 微信接口規(guī)則表

表2 回復(fù)語音消息的XML數(shù)據(jù)包結(jié)構(gòu)表

3.5.2 下行接口

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

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

3.6 系統(tǒng)業(yè)務(wù)邏輯設(shè)計

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

表3 獎品發(fā)放邏輯表

4 系統(tǒng)壓力測試

4.1 測試工具及測試環(huán)境

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

測試環(huán)境：測試中使用的應(yīng)用服務(wù)器配置及說明信息見表4。

4.2 測試流程

具體測試內(nèi)容如表5所示。

4.3 典型功能測試用例

具體測試用例見表6。

表4 壓力測試環(huán)境設(shè)備配置列表

表5 系統(tǒng)壓力測試內(nèi)容列表

表6 系統(tǒng)管理子系統(tǒng)功能測試表

續(xù)表

測試結(jié)果顯示：與目標(biāo)結(jié)果一致，達到預(yù)定目標(biāo)。

4.4 壓力測試

測試功能項：業(yè)務(wù)系統(tǒng)壓力測試

測試步驟：

業(yè)務(wù)系統(tǒng)1臺php服務(wù)器，連接redis和mysql，服務(wù)器掛載到SLB下；

locust向業(yè)務(wù)系統(tǒng)SLB打壓，模擬微信端的喊紅包請求；

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

預(yù)期結(jié)果：1臺php服務(wù)器承受QPS達到1500次/秒，無5XX報錯

測試結(jié)果：和預(yù)期結(jié)果基本一致

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

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

圖5 業(yè)務(wù)系統(tǒng)SLB壓力測試QPS圖

圖6 業(yè)務(wù)系統(tǒng)SLB壓力測試response time圖

圖7 業(yè)務(wù)系統(tǒng)SLB壓力測試5XX狀態(tài)碼圖

圖8 業(yè)務(wù)系統(tǒng)PHP壓力測試的資源使用情況圖

圖9 業(yè)務(wù)系統(tǒng)PHP壓力測試的網(wǎng)絡(luò)數(shù)據(jù)圖

測試功能項：網(wǎng)關(guān)系統(tǒng)壓力測試。

測試步驟：

網(wǎng)關(guān)系統(tǒng)1臺nginx服務(wù)器，服務(wù)器掛載到SLB下；

locust向網(wǎng)關(guān)系統(tǒng)SLB打壓

預(yù)期結(jié)果：1臺nginx服務(wù)器承受QPS達到25000次/秒

測試結(jié)果：和預(yù)期結(jié)果基本一致

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

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

圖10 網(wǎng)關(guān)系統(tǒng)SLB壓力測試QPS圖

圖11 網(wǎng)關(guān)系統(tǒng)SLB最大并發(fā)圖

圖12 網(wǎng)關(guān)系統(tǒng)Nginx網(wǎng)絡(luò)流量圖

4.5 測試結(jié)果分析

符合新春“喊紅包”活動功能及性能的需求。同時，在模擬用戶并發(fā)使用和持續(xù)運行中，系統(tǒng)未出現(xiàn)不良反應(yīng)，響應(yīng)時間令人滿意，系統(tǒng)穩(wěn)定性比較可靠。

5 系統(tǒng)實施

5.1 實施環(huán)境

具體軟硬件環(huán)境配置如下表7所示。

5.2 系統(tǒng)上線

準(zhǔn)備工作完成后由資源部署組完成系統(tǒng)的實施工作，主要工作內(nèi)容如下：

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

網(wǎng)關(guān)層限流配置進行最后確認(rèn)，通過壓測進行限流配置的校驗；

網(wǎng)關(guān)系統(tǒng)、業(yè)務(wù)系統(tǒng)、訂單系統(tǒng)分別創(chuàng)建ECS鏡像，為活動當(dāng)天擴容做準(zhǔn)備；

網(wǎng)關(guān)系統(tǒng)準(zhǔn)備若干臺ECS和SLB，用于業(yè)務(wù)并發(fā)過高時的備用；

創(chuàng)建最小災(zāi)備環(huán)境，在極端情況下上線使用；

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

更新微信白名單IP，重新創(chuàng)建WAF規(guī)則；

發(fā)布最終版代碼，上線前三天封版；

上線前一天修改SLB網(wǎng)絡(luò)模式為按帶寬付費；

清空所有日志、數(shù)據(jù)庫的測試數(shù)據(jù)，數(shù)據(jù)庫導(dǎo)入生產(chǎn)數(shù)據(jù)；

活動當(dāng)天前一小時，通過壓測進行系統(tǒng)預(yù)熱。

5.3 實施效果

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

表7 系統(tǒng)實施軟硬件配置表

表8 獎品分配表

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

用戶喊紅包過程系統(tǒng)響應(yīng)積極，未出現(xiàn)卡頓情況，平均響應(yīng)RT時間未超過100毫秒，高峰時段不超過500毫秒。

圖13 數(shù)據(jù)統(tǒng)計頁面圖

6 結(jié)論

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