017年支付寶五福紅包紅包開獎人數是167966715人（約1.68億）；除夕當天的參與人數是2.2億；在業務峯值上，活頁主頁面峯值達到81W/s；掃福的峯值爲22W/s；除夕當天的登錄峯值爲29W/s；除夕開獎峯值是90W/s。在本文中，螞蟻金服技術專家天鏡飛深入技術背後，爲大家講解了整體活動的穩定性保障、資損防控、運維部署、投產保障、監控管理、安全防護等方面的實戰經驗。
業務模式
今年支付寶新春紅包主要採用了AR紅包和五福紅包兩種模式。AR紅包是創新業務的體現，主要分爲藏、找、開三個步驟。其中藏是在當前位置掃描指定的物體，輸入金額、人數，支付完成之後，該紅包就出現在地圖上；用戶可以在地圖上發現該紅包或者是通過掃描指定的物體找到該紅包，找到紅包之後用戶可以使用線索圖打開紅包。AR紅包另一個玩法是商戶紅包，主要用於商戶的推廣，商戶可以把自己的Logo藏在所有門店的地理位置上，通過引導用戶去指定的門店掃Logo、開紅包，進而起到商戶宣傳的作用。
五福紅包也就是所謂的敬業福，今年的玩法和去年的類似：蒐集福卡、交換福卡，集齊五福之後等待開獎；二者區別在於在收集福卡上，今年的形式更加多樣化：掃福字，螞蟻森林澆水以及鑽石會員可以得到萬能福；同時金額分配採用隨機的方式，做到人人有份。
業務核心指標
上圖顯示的是今年支付寶紅包業務核心指標：五福紅包開獎人數是1.68億；除夕當天的參與人數是2.2億；在業務峯值上，活動主頁面峯值達到81w/s；掃福的峯值爲22w/s；除夕當天的登錄峯值爲29w/s；除夕開獎峯值是90w/s。
那麼支付寶是如何支持如此高併發的業務和如此龐大的人羣呢？背後的支撐的技術體系是怎麼樣的呢？下面來一探究竟。
支付寶支撐技術體系
支撐支付寶紅包產品實現的技術架構可以總結爲六個要素：其中穩定性保障、資損防控是核心；運維部署、投產保障是基石；監控管理、安全防護是重要組成部分。這六大要素支撐產品實現技術架構整體的運行以及最後完美地結束。
支付寶紅包產品實現的技術架構如上圖所示。基於業務可變性和用戶體驗的要求，在終端上主要採用H5和Native的實現方式：其中H5主要用於螞蟻森林、福卡任務、福卡排行榜等易變的業務；福卡主頁、AR地圖、AR掃一掃、AR引擎、AR開紅包等業務是採用本地Native的方式，因爲其用戶體驗非常好。當然，整體客戶端架構都是基於支付寶客戶端&H5容器的通用能力，如框架、通訊、網絡、登錄、安全等。
在服務器端，福卡業務平臺和AR業務平臺都是基於支付寶現有的資金能力，其中福卡業務平臺是基於現有的營銷發獎資金處理能力，在處理過程中，使用了推薦、憑證中心、螞蟻森林中的產品能力，福卡業務中最爲關鍵的是配置後臺（這是因爲它是配置型的產品），所以我們搭建了新春配置後臺和營銷配置後臺；AR業務平臺是基於個人紅包和商戶紅包現有的資金能力，其中圖像識別服務和地理位置服務是該業務中最爲重要的兩點。總結來看，服務器端依賴於支付寶新金融引擎的共享能力，如監控、社交、會員、賬務、支付、安全、SYNC、中間件等。
在存儲方面，除了採用通用的MySQL存儲，還大量引入了關係型數據庫Geabase，對於分佈式緩存採用了tair，圖片存儲使用的是OSS。
下面來逐一講解支撐產品實現的六個要素。
運維部署
運維部署要解決的問題是資源缺口。正常情況下，華東1和華南機房的機器數量是無法滿足新春活動資源的需求，因此需要週轉騰挪。在解決資源缺口的過程中，利用了彈性資源來節省成本，將關鍵鏈路“彈”到雲上；活動結束之後再將這些流量從雲上遷回線下機房中。正常情況下，華東1機房和華南機房分別承擔40%和60%的流量，並且它們都是非雲的機器；在新春紅包業務上，支付寶將60%的流量切到華東2機房中，並且將其上雲，藉助了阿里雲強大的服務器能力，此外，在華南機房會部署15%的雲機器，也就是說，新春紅包業務中，75%的機器是在雲上運行的，在活動結束後，流量會切出，將機器空閒出來極大的節省了成本。
投產保障
投產保障是技術架構的另外一塊基石。今年業務上線過程中，代碼開發、產品上線只佔了全部精力的20%；其中75%的精力用於演練和壓測。針對演練和壓測，支付寶設計了三套環境，分別是壓測環境、演練環境和正式環境。終端、服務器端和存儲都支持這三套環境來回切換，三套環境是基於白名單的隔離控制機制，以防止三套環境相互串擾帶來線上穩定性的風險。
在演練中優化產品流程，在壓測中打磨代碼性能。今年產品上線時的業務流程和最終正式環境下的產品業務流程變化非常大，並且代碼的層次也發生了很大的變化，利用這三套環境，通過壓測來調優代碼，通過線上的演練，不斷地完善代碼、產品，最終達到基本穩定線上產品狀態。這裏值得一提的是灰度拉練，在開獎環節，今年設計了灰度開獎的功能，也就是提前一天，某些用戶可以提前開獎，在提前開獎過程中修復了一個嚴重的配置問題，避免了正式上線時產生故障，因此灰度拉練可以說是投產保障中最關鍵的一環。
監控管理
監控管理和安全防護是兩個重要的組成部分。
監控是產品的“眼睛”，它爲技術和產品人員提供了發現線上問題、做出業務決策的依據。今年，依照不同的監控場景和需求，支付寶共部署了四套監控模式：第一套監控模式是利用Xflush分析系統的穩定性日誌，最終產出系統監控、業務鏈路大盤、SLA限流大盤，這部分主要是爲各技術負責人提供線上運行狀態的監控；第二套監控模式是利用Kepler實時計算平臺，對業務日誌進行分析，產生一些業務指標，最後產出電視大屏、移動直播間、營銷大盤，對外輸出有絢麗效果的展示；第三套監控模式是利用海納實時計算平臺，對客戶端日誌進行分析，產生資源下載大盤、性能穩定性大盤、基礎網絡大盤，可以對客戶端的運行狀態進行有效的監控和預警；最後一套監控模式是針對客服的安保日誌分析，產生安保大屏，對用戶投訴情況進行監控。
安全防護
只有在產品設計之初就考慮安全防護，才能做到產品運營時的防患於未然。今年，支付寶在AR紅包和五福紅包上採用了三道安全防護策略。前兩道防護主要是針對AR紅包的線索圖和LBS，其中第一道防護是針對AR紅包的線索圖，通過線索圖遮擋算法，在線索可識別和線索不泄露之間尋求平衡；第二道安全防護是針對LBS篡改的監測，採用的策略是終端採集用戶LBS、位移等數據，然後報送給服務器端，服務器端在用戶領取AR紅包時分析LBS、位移等數據是否出現漂移等現象，對異常的情況進行領取攔截；第三道防護是基於大數據的安全策略防護，支付寶安全團隊對用戶的數據進行大數據分析，基於大數據分析會產生相應的安全策略，這些安全策略會在產品的關鍵流程上進行防護，主要是得福卡、交換福卡、福卡開獎、領AR紅包和發AR紅包，針對不同的環節，採用不同的安全防護手段，保障用戶操作的有效性。
穩定性保障
在穩定性保障中，第一個較爲突出的點是將圖片識別散於終端，這是由於圖片識別算法是非常耗性能的。圖片識別時面臨着兩個選擇：一是在各終端上完成圖片識別，直接和用戶交流，具有較好的體驗，此外還緩解了服務器端的壓力，並且由於圖片不用上傳到服務器端，可節省了流量的開銷，但是它面臨的最大問題是不安全，因爲在終端進行圖片識別，用戶可以篡改圖片識別結果，從而欺騙服務器端，具有較高的風險；另一個選擇是在服務器端進行圖片識別，也就是圖片上傳到服務器端，通過服務器端的算法進行識別，保證了識別結果的安全性，它的缺點是用戶體驗差、服務器資源損耗高、消耗用戶大量的流量。
因此，需要在這兩種方式中尋求平衡，支付寶採用的策略是針對不同的圖片識別場景採用不同的圖片識別方式，如地圖上領取紅包，採用的是客戶端嚴格匹配，服務端按策略再次校驗的方式，以安全爲上；掃一掃領取紅包場景，採用服務端Top n匹配，領取時服務端驗籤的方式，也是爲了安全考慮。這兩種場景的實際峯值並不高，將其放在服務器端是在可接受範圍內；另外三個場景，包括可口可樂紅包（出紅包\福卡）、口碑活動（出紅包）、任意福活動（出福卡）主要是識別福字和商戶Logo，其中不牽扯隱私問題，因此對於商戶Logo採用的是純客戶端匹配，服務器端不再識別，避免了服務器的資源損耗；對於任意福活動，是採用客戶端嚴格匹配福字，當客戶端識別不出福字時，再由服務器端進行識別，這種方式可以節省服務器端70%以上的資源損耗。
在穩定性保障中，針對掃一掃環節實現了關鍵鏈路多檔位切換。掃一掃環節的關鍵點主要包括終端福字識別、附近可領取紅包線索匹配、服務端福字識別和福卡領取。支付寶針對掃一掃環節設計了三個檔位：檔位一，完全模式，即識別福字又識別紅包，該模式可承受峯值爲12W/s，在該模式下可以通過調整附近匹配紅包個數調整系統性能；檔位二是將紅包Top n匹配環節去掉，服務器端只保留福字識別和福卡領取這兩項功能，該檔位可承受峯值爲50W/s，該模式下可以通過調整服務端福字識別算法複雜度對系統性能進行調整；檔位三是在服務器端僅保留福卡領取功能，該檔位預計可承受峯值爲60W/s，節省圖片下載等資源損耗。
在實際使用過程中，檔位二已滿足要求，但多檔的思想爲穩定性保障提供了很好的支撐。
穩定性保障方面細節特別多，每個細節又非常重要。除了上述兩點外，支付寶還在全局上考慮了一些風險點的梳理、規避以及制定了活動前、活動中、活動後的操作手冊，制定了相應的應急處理機制，並對關鍵業務流程進行多次模擬演練。
在終端上採用了限流無感知、資源預下載、用戶操作數據緩存、開獎時間離散、數據項與開關動態配置等穩定性操作；在服務端，進行了全鏈路梳理、全鏈路壓測、限流保護、應急熔斷機制等。
資損防控
資損防控是今年紅包活動中的另一個核心點，這是因爲AR紅包和五福紅包涉及的金額巨大；另外由於今年的獎池分配策略採用隨機分配的方式，進一步增加了困難：
- 計算困難，開獎只有18分鐘，如何在18分鐘內將2億隨機分配併發放出去？
- 覈對困難，資損風險高，並非簡單地將金額計算出即可，而是要保障每個人金額總和和總金額相同。
- 獎池發完難度大，將2億現金全部發放乾淨，其中涉及預測、保底等問題。
針對計算困難，引入多檔位類隨機機制，設計多個開獎檔位，使得看起來像隨機的結果，而不是純隨機的方式；另外採用提前算獎的方式，在用戶五福合一時提前計算出部分用戶的獎金，實際開獎時只是查看原來計算好的金額。基於這兩種策略，支付寶設計了今年資損防控的新模型，該模型包括算獎、抽獎、發獎三個環節，通過監控、預警、覈對機制來保證這三個環節的正確性；其中算獎環節設計了可重複算獎，當發現異常時，可重新計算獎金，抽獎環節支持快速訂正，發獎環節支持快速調賬。
覈對機制是資損防控中最爲關鍵的環節，今年採用的是基於實時計算平臺的核對機制。該覈對機制主要包括兩種覈對策略：一是實時覈對，對關鍵的資金流變動、資金鍊的切換採用實時覈對；另一種是異步覈對，也就是所謂的15分鐘覈對、小時覈對和T+1覈對，對於所有和資金相關的環節都採用異步覈對以保證最終的一致性。
實時覈對採用了三種基本策略：第一種策略採用了乾坤鏡技術，對接口的入參出參實時地檢查；第二種策略採用定時調度任務，儘量保證準實時性，將數據庫中的相關數據撈出來進行覈對；第三種策略是將覈對的代碼片段糅雜在業務代碼中，通過這種方式保證實時覈對的一致性。異步覈對，包括15分鐘覈對、小時覈對、T+1覈對，採用的技術架構主要是DRC（異地多活數據同步）與TT結合的方式，將DB的數據和日誌的數據按15分鐘、小時、日彙總存儲到ODPS上，再通過相應的核對機制來保證整體的一致性。
在算獎—抽獎、抽獎—發獎的過程中，下一個環節開始前，必須通過覈對的策略保證上一個環節的準確性，包括總金額和明細；這樣一來，可以平穩地過渡到下一個階段而不必擔心上一階段出現問題。
總結
支付寶新春紅包產品以運維部署和投產保障爲基石，以穩定性保障和資損防控爲核心，輔以監控管理和安全防護這兩個重要組成部分，完美地解決了五福紅包和AR紅包的高併發業務和龐大的人員參與兩大難題，實現了81w/s的活動主頁面峯值、22w/s的掃福的峯值、29w/s的除夕當天的登錄峯值以及90w/s的除夕開獎峯值等一系列指標。
原文來自：雲棲社區；原文鏈接：https://yq.aliyun.com/articles/71053
點擊閱讀更多，查看更多詳情