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紅包和五福紅包涉及的金額巨大；另外由於今年的獎池分配策略採用隨機分配的方式，進一步增加了困難：

1. 計算困難，開獎只有18分鐘，如何在18分鐘內將2億隨機分配併發放出去？
2. 核對困難，資損風險高，並非簡單地將金額計算出即可，而是要保障每個人金額總和和總金額相同。
3. 獎池發完難度大，將2億現金全部發放乾淨，其中涉及預測、保底等問題。

針對計算困難，引入多檔位類隨機機制，設計多個開獎檔位，使得看起來像隨機的結果，而不是純隨機的方式；另外採用提前算獎的方式，在使用者五福合一時提前計算出部分使用者的獎金，實際開獎時只是檢視原來計算好的金額。基於這兩種策略，支付寶設計了今年資損防控的新模型，該模型包括算獎、抽獎、發獎三個環節，透過監控、預警、核對機制來保證這三個環節的正確性；其中算獎環節設計了可重複算獎，當發現異常時，可重新計算獎金，抽獎環節支援快速訂正，發獎環節支援快速調賬。

核對機制是資損防控中最為關鍵的環節，今年採用的是基於實時計算平臺的核對機制。該核對機制主要包括兩種核對策略：一是實時核對，對關鍵的資金流變動、資金鍊的切換採用實時核對；另一種是非同步核對，也就是所謂的15分鐘核對、小時核對和T+1核對，對於所有和資金相關的環節都採用非同步核對以保證最終的一致性。

實時核對採用了三種基本策略：第一種策略採用了乾坤鏡技術，對介面的入參出參實時地檢查；第二種策略採用定時排程任務，儘量保證準實時性，將資料庫中的相關資料撈出來進行核對；第三種策略是將核對的程式碼片段糅雜在業務程式碼中，透過這種方式保證實時核對的一致性。非同步核對，包括15分鐘核對、小時核對、T+1核對，採用的技術架構主要是DRC（異地多活資料同步）與TT結合的方式，將DB的資料和日誌的資料按15分鐘、小時、日彙總儲存到ODPS上，再透過相應的核對機制來保證整體的一致性。

在算獎—抽獎、抽獎—發獎的過程中，下一個環節開始前，必須透過核對的策略保證上一個環節的準確性，包括總金額和明細；這樣一來，可以平穩地過渡到下一個階段而不必擔心上一階段出現問題。

總結

支付寶新春紅包產品以運維部署和投產保障為基石，以穩定性保障和資損防控為核心，輔以監控管理和安全防護這兩個重要組成部分，完美地解決了五福紅包和AR紅包的高併發業務和龐大的人員參與兩大難題，實現了81w/s的活動主頁面峰值、22w/s的掃福的峰值、29w/s的除夕當天的登入峰值以及90w/s的除夕開獎峰值等一系列指標。

原文來自：雲棲社群；原文連結：
點選，檢視更多詳情