與傳統意義上的紅包相比，近兩年火起來的“紅包”，似乎才是如今春節的一大重頭戲。歷經上千年時代傳承與變遷，春節發紅包早已成為歷史沉澱的文化習俗，融入了民族的血脈。按照各家公佈的資料，除夕全天微信使用者紅包總髮送量達到80.8億個，紅包峰值收發量為40.9萬個/秒。春晚直播期間討論春晚的微博達到5191萬條，網友互動量達到1.15億，網友搶微博紅包的總次數超過8億次。

為此，本文策劃了“春節紅包”系列文章，以期為讀者剖析各大平臺的紅包活動背後的技術細節。本文為支付寶篇。

螞蟻金服旗下的支付寶經過十幾年的發展，從簡單的支付工具逐步發展成網際網路金融平臺。2013年餘額寶的崛起就是網際網路金融平臺升級的標誌型事件，這一年支付寶順利進行了PC向無線的佈局，可以說架構成功升級到移動網際網路金融平臺。經過兩年的發展，2015年口碑和社交業務的崛起讓支付寶架構進一步在原有架構基礎上擴充出支援線下市場和社交的生活互動型架構。2015年錢包9.0的釋出，這個里程碑式的專案初步奠定了支付+移動網際網路金融+生活互動型混合架構。演進示意圖如圖1所示。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314141542704.png)
圖1 架構演進示意圖

## 專案保障體系

2015年12月份，我們在第一時間得知支付寶中標央視訊息後，既興奮又擔心！興奮的是，這是一次千載難逢的機會，我們終於可以一展身手。擔心的是，支付寶和央視聯合搞活動，是我們有史以來最大規模的活動，到底規模多大，我們沒有任何概念。唯一能得到的資訊是，歷年觀看春晚的人數大約在7億多，支付寶的年度活躍使用者4億多，至於使用者的行為習慣，沒有任何參考模型。

雖然心裡不是很有譜，但也沒那麼擔心，信心來自於兩方面。

1. 經歷過這麼多年的雙11和去年的除夕，多年經驗的沉澱，我們對超大規模的活動沉澱總結出一整套預測模型，而且這個預測模型經過了多次實戰檢驗，相對比較準確。
 2. 從錢包9.0開始，我們已經開始佈局生活服務平臺，這個版本搭建起社交和口碑兩個平臺的雛形，架構上從移動網際網路金融架構擴充套件出能支撐生活互動型的架構，形成了支付+網際網路金融+生活互動的混合架構，這種架構體系既能支援移動網際網路金融的高可用、資金安全、高彈性伸縮，又能支援生活互動型架構的輕巧、靈便、彈性十足的特點。架構示意圖如圖2所示。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314141601597.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)
圖2 總體架構示意圖

團隊在拿到中標資訊後，我們迅速決策，達成了以下指導原則：優先確保核心鏈路，保證核心鏈路上使用者體驗順暢。萬一出現系統容量不足，系統必須能扛住洪峰，不被壓垮，即使這種情況下也要給使用者儘量友好的提示文案。在確保主鏈路基礎上，還需要照顧到支付寶App內幾百個非關鍵鏈路，對於非關鍵鏈路按照業務重要程度分為4個等級，根據等級分配不同的資源配置。

經過2個月的精心準備，在激動人心的4小時結束後，整個春晚支付寶系統穩穩地扛住了4波洪峰，表現平穩，無論是核心鏈路還是非核心鏈路，沒有出現任何問題。4個小時內幾乎沒有使用者因為系統、功能上的問題而產生投訴，客服同學沒有任何諮詢壓力。

使用者“咻一咻”在第二場活動達到高潮，累計互動次數達到1808億次，是去年的16倍。20點38分，“咻一咻”峰值達到177億次/分鐘。可以想象一下，幾億使用者同時拿著手機，以想戳透手機螢幕的速度點選咻咻按鈕，幾億的請求瞬間從客戶端洪水般湧入服務端，對後臺將是多大的壓力！這麼高併發情況下，如果系統設計不合理或者預測模型不準確，將立即被沖垮，應用系統一旦被沖垮，高壓下根本沒有恢復的機會。

## 五項準備

為了保證整個春晚順利進行，我們在以下5個方面做足了功課：

1）相對合理的超大規模壓力預測模型。前提約束條件要說明下，伺服器資源是有限的。總共這麼多伺服器，要充分利用起來需要兩個條件。應用架構必須可以大規模擴容。如果架構不合理，即使有伺服器也沒法擴容，剛好在架構演進的過程中，支付寶App服務端進行了LDC單元化改造，擴容對我們來說so easy。模型要儘量準確。模型不準確的後果是使用者的行為習慣和預期不同，導致部分業務壓力特別大，無法正常提供服務，而另外部分伺服器十分空閒，佔著機器資源不幹活。

2）核心鏈路和非核心鏈路徹底梳理。核心鏈路梳理和非核心鏈路梳理相對比較容易，注意以下5點。接入層必須具備足夠富裕的容量支撐，即使因為評估不準浪費部分機器也是可以容忍的。接入層一旦出問題，所有業務將全軍覆沒。如果接入層足夠健壯，當某個業務抗不住時，完全可以透過限流來隔離這個業務，而其他業務不受任何影響。使用者必須能進得來。也就是要保證使用者能順利登陸進來，如果使用者連登陸都受限制，體驗肯定好不到哪兒去。使用者要能玩起來。這是核心業務邏輯，如果咻都沒法咻，或者咻了半天紅包或者福卡發不出去，那也是致命的。要能保證使用者能傳播和互動起來，包括分享、加好友、聊天。非核心業務需要進行合理分級。我們大致分了4檔。第一檔4個tab，非核心鏈路中的最高優先順序，必須力保。第二檔1級入口，容量必須是平時的幾十倍。第三檔2級入口，容量是平時的十幾倍。第四檔，一、二、三檔外的其他業務，要保證系統具備自我保護能力，底線是不能被壓跨。

3）大規模生產系統全鏈路壓測。核心鏈路和非核心鏈路梳理清楚了，進行了效能最佳化和系統擴容後，能否達到我們預測的目標值，要靠線上全鏈路壓測來驗證。全鏈路壓測相應的原則：核心鏈路必須全部覆蓋，包括單獨壓測和混合壓測，非核心鏈路要盡最大可能覆蓋。經過專案組的努力，全鏈路壓測基本覆蓋了所有的核心鏈路和非核心鏈路，覆蓋率接近100%。單系統或介面壓測問題不大，但混合壓測就比較頭痛，主要還是使用者行為預測的問題，為了確保萬無一失，在混合壓測時組合出多個模型進行壓測，盡最大可能暴露出系統的效能和容量問題。

4） 高頻次灰度內測和線上小規模活動預熱（2月1日和2月4日兩次小規模活動）。高頻次的內部灰度測試更主要是能暴露出一些比較隱蔽的功能問題，能進行充分的業務配置演練。而兩次小規模預熱則起到了更大的作用，雖然規模沒有春晚大，但使用者行為習慣具備一定的參考性，並能相對真實地模擬春晚活動。我們在這兩次預熱活動中確實也發現了一些問題，並且根據相對真實的使用者行為習慣對系統容量進行了調整和最佳化，有效地防止了春晚出現資源分配不均的問題。

5） 上千個業務、技術預案和完備的應急響應體系支援。業務上主要引數化、配置化，透過服務端來控制客戶端的行為，以滿足業務多樣性需求，降低客戶端版本升級困難帶來的衝擊。技術上預案分為提前預案和應急預案。提前預案主要作用是讓伺服器輕裝上陣，將計算能力節省下來供核心功能使用，比如降級日誌、關掉定時任務等。而應急預案更主要是用來保命的，萬一系統在某些點出現了意外狀況，會透過所謂的大招以犧牲部分非核心業務來保核心業務，也就是丟卒保車。當然春晚因為前期工作做得比較到位，這些大招都深藏閨閣，沒機會施展。

## 八大技術難點

這麼超大規模的活動，肯定存在很多技術難點，平時看不起眼的一個問題，在超大規模情況下，就可能被放大。接下來簡短總結這些技術難點。

1） 登陸：去年除夕，我們登陸上容量做的不足，導致使用者在登陸時就被擋在門外。本次春晚，我們做了硬性規定，必須能順利登陸進來，堅決不允許出現因為登陸系統處理能力不足而導致出現限流這種很不好的體驗。去年的登陸峰值大約在十幾萬每秒，今年我們提出實現百萬登陸能力，這個量是平時量的200倍左右，也是去年除夕峰值的6、7倍，而我們使用者數量也僅僅增長了2，3倍，百萬級別應該沒有問題，而實際上登陸量確實也在這個數量級。目標確定好了，接下來比較難的就是如何做到這個系統容量目標。效能最佳化和擴容兩手抓，而且更多的是要靠效能最佳化，作為有追求的工程師擴容不應該是首選。經過1個月左右極致的效能最佳化，最終機器僅僅擴容到原來的4倍，大約在幾千臺，其他的提升全部透過效能最佳化實現。

2） 如何應對洪峰（圖3是簡單的架構示意圖）：可以想象，幾億使用者同時線上，在幾乎同一時刻進行咻咻操作，瞬間洪水般流量直接衝進來，當時秒級峰值達到了2.95億次。對於這麼大的流量，我們使用了漏斗形的分流、導流方案。客戶端請求到我們的網路裝置後，從應用視角我們大體分為三層LVS、spanner、gateway。這兒你可以看作一個漏斗，越往裡層，可以處理的請求越小。之所以這麼設計，還是基於業務和使用者體驗，對於咻一咻，雖然有2.95億次請求，但我們的獎品個數是有限的，每場只有6000萬個現金紅包和上億張福卡。如果發獎能力達到了6000萬每秒，那6000萬個現金紅包瞬間被秒光，這也不是業務和使用者想看到的。我們平衡下來，將獎品（現金紅包+福卡）發放能力設定在100萬每秒，大約可以在幾分鐘內順利發完這6000萬個現金紅包。這裡有幾個關鍵點，gateway的處理能力是千萬級別，集中咻咻大約用掉了100萬，剩下900萬是給其他業務的。當大量咻咻請求沒到gateway時，lvs和spanner要能正確處理，給使用者比較好的體驗，不能出現任何限流問題，這也符合使用者沒有中獎預期。我們的處理方案是，如果咻咻請求沒到後端，給使用者隨機顯示彩蛋（包括文案、圖片、影片等）。對於spanner雖然處在網路更外層，但也需要理解部分業務邏輯。比如要能識別出不同的rpc請求，尤其是要能區分出咻咻介面。如果spanner不做任何識別，只管向閘道器轉發1000萬請求，那肯定將導致轉發的咻咻請求超過100萬，而擠佔了其他業務的配額，導致其他業務被spanner限流無法正常處理。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314141646453.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)
圖3 網路漏斗模型示意圖

3）活動獎品控制系統：春晚一共搞了4場活動，大約發了2.3億個現金紅包和十幾億張福卡。在這麼大規模的活動下，我們做到了0差錯0資損，沒有多發或者少發一個紅包，嚴格控制了福卡的發放比例，也合理控制了發獎速度。4場活動基本控制在3-5分鐘內完成，嚴格按照我們設定的預期模型執行。所有這些都得益於我們的獎品控制系統，對於這個系統設計上有3個基本原則：資金0資損、百萬級的獎品處理能力、靈活的獎品發放控制。

4）動態技術：客戶端的一個最大的問題就是版本釋出，有個成語叫做“覆水難收”，剛好比較形象地說明了這個問題。版本一旦釋出，如果有問題需要讓使用者再次升級，時間已經來不急了。為了更好地控制客戶端的行為，引數化、配置化就成了必不可少的利器。但引數化、配置化帶來了兩個問題：

1. 客戶端預埋了很多邏輯，極大的增加了程式碼複雜度，客戶端的程式碼測試難度加大，質量很難保證。
 2. 因為引數化、配置化，需要有機制能夠保證配置資料能儘可能實時下發給幾億客戶端，並且在最短的時間內生效。

對於客戶端複雜度增大的問題，主要透過多套機制保障。傳統的質量保障，加強測試力度。進行不同範圍內的人群進行灰度。安排多輪演練，模擬各種配置場景。為了保證春晚的萬無一失，年前增加了幾場小規模預熱，透過預熱發現儘可能多的問題，並進行規避。客戶端版本釋出後，產生的部分bug，必須修復，透過熱補丁的方式，在不釋出版本的情況下修復這些bug。對於配置的實時下發，我們單獨做了一套機制，使用推拉結合的方式，在最短的時間內下發配置資訊。以服務端推送為主，透過sync機制，只要使用者線上，盡最大可能將配置資料推送到客戶端，萬一有極少量配置推送失敗，還可以透過拉的方式進行補償，這樣確保了配置資料一定能下發到客戶端。

5） 資源管理：在這次春晚活動中，涉及到大量的資源，包括圖片、拜年影片等。圖片和影片都比較大，十幾b到幾百kb不等。當在高峰期時，如果瞬間有海量的請求到CDN上，這麼大的請求頻寬根本扛不住。我們當時預估了大約有幾T的頻寬需求。

為了能有效地扛住瞬間峰值對CDN的壓力，我們對資源進行了有效的管理和控制。首先在客戶端預埋了幾個預設資源，萬一真不行了，這幾個資源可以用。其次儘量提前開啟入口，當使用者瀏覽過後，就將資源下載到本地。再次瀏覽時不再需要遠端訪問CDN。最後，做了應急預案，高峰期一旦發現流量告警，緊急從影片切換到圖片，降低頻寬壓力，確保不出現頻寬不夠而發生限流導致的黑屏等體驗不好的問題。

最後的結果可以用完美來形容，由於預熱充分，頻寬雖然很高，但沒達到我們的告警值，應急預案也沒有使用。

6） 實時資料計算能力：紅包剩餘個數儘可能實時準確顯示。這裡有一個細節，當咻咻的時候，紅包剩餘個數隨著你咻咻在不停的遞減，而且遞減的個數比較平滑，不像某些App，出現長時間不動，動一次就是斷崖式變化。雖然這是一個不起眼的細節，但我們為了給使用者更好的體驗，讓沒搶到紅包的使用者能在最短的時間內知道盡量準確的紅包剩餘個數，我們解決了這個技術難題。

我們充分利用了兩個方面的能力。一是實時的流式計算處理能力，可以在秒級收集各個伺服器處理的紅包個數，並且進行彙總計算，並把這個計算結果寫在快取中。另一方面我們充分利用每個請求頭的控制資訊，在使用者每次請求的同時帶回剩餘個數。客戶端收到應答後，如果發現本次請求沒有中獎，從頭部控制資訊中解析出紅包剩餘個數並正確顯示。

7） 全鏈路壓測：支付寶有一套非常強大的線上環境壓測的利器，能夠模擬出你所想要的任何請求場景。對於參與使用者量非常大的活動，前期再完備的準備，也不能確保一定不出問題，需要對線上環境進行效能壓測。在全鏈路壓測機制下你不僅僅可以知道各個應用系統的容量水位和目標之間的差距，還能夠知道整個基礎設施層，比如資料庫、網路、儲存等的瓶頸，讓你能夠根據壓測資料進行快速決策。

8） 超大規模活動彈性計算能力：這麼大規模的活動，初步計算下來，大約需要幾萬臺機器，包括應用伺服器、儲存、網路裝置等。對於這麼大量的資源調配，如果沒有金融雲高彈效能力，短時間內部署完成，這是不可想象的。得益於金融雲的高彈效能力，我們基本做到在1周內完成了相關資源的調配部署。

## 小結

2016年春晚在轟轟烈烈中過去了，我們收穫了很多，其中最重要的一點是我們對春晚的使用者行為有個初步的瞭解，如果再搞這種超大規模的活動，預測模型將更加精確。如果2017年央視春晚我們繼續中標，我們將做得更加從容，更加順滑，真正做到喝著咖啡過春晚！

原文來自：InfoQ；原文連結：http://www.infoq.com/cn/articles/alipay-high-concurrency-challenge
點選[閱讀更多](https://tech.antfin.com/articles?chInfo=zh)，檢視更多詳情

1808億次，16倍的超越！談支付寶紅包的高併發挑戰

相關文章