與傳統意義上的紅包相比，近兩年火起來的“紅包”，似乎纔是如今春節的一大重頭戲。歷經上千年時代傳承與變遷，春節發紅包早已成爲歷史沉澱的文化習俗，融入了民族的血脈。按照各家公佈的數據，除夕全天微信用戶紅包總髮送量達到80.8億個，紅包峯值收發量爲40.9萬個/秒。春晚直播期間討論春晚的微博達到5191萬條，網友互動量達到1.15億，網友搶微博紅包的總次數超過8億次。
爲此，本文策劃了“春節紅包”系列文章，以期爲讀者剖析各大平臺的紅包活動背後的技術細節。本文爲支付寶篇。
螞蟻金服旗下的支付寶經過十幾年的發展，從簡單的支付工具逐步發展成互聯網金融平臺。2013年餘額寶的崛起就是互聯網金融平臺升級的標誌型事件，這一年支付寶順利進行了PC向無線的佈局，可以說架構成功升級到移動互聯網金融平臺。經過兩年的發展，2015年口碑和社交業務的崛起讓支付寶架構進一步在原有架構基礎上拓展出支持線下市場和社交的生活互動型架構。2015年錢包9.0的發佈，這個里程碑式的項目初步奠定了支付+移動互聯網金融+生活互動型混合架構。演進示意圖如圖1所示。
圖1 架構演進示意圖
項目保障體系
2015年12月份，我們在第一時間得知支付寶中標央視消息後，既興奮又擔心！興奮的是，這是一次千載難逢的機會，我們終於可以一展身手。擔心的是，支付寶和央視聯合搞活動，是我們有史以來最大規模的活動，到底規模多大，我們沒有任何概念。唯一能得到的信息是，歷年觀看春晚的人數大約在7億多，支付寶的年度活躍用戶4億多，至於用戶的行爲習慣，沒有任何參考模型。
雖然心裏不是很有譜，但也沒那麼擔心，信心來自於兩方面。
- 經歷過這麼多年的雙11和去年的除夕，多年經驗的沉澱，我們對超大規模的活動沉澱總結出一整套預測模型，而且這個預測模型經過了多次實戰檢驗，相對比較準確。
- 從錢包9.0開始，我們已經開始佈局生活服務平臺，這個版本搭建起社交和口碑兩個平臺的雛形，架構上從移動互聯網金融架構擴展出能支撐生活互動型的架構，形成了支付+互聯網金融+生活互動的混合架構，這種架構體系既能支持移動互聯網金融的高可用、資金安全、高彈性伸縮，又能支持生活互動型架構的輕巧、靈便、彈性十足的特點。架構示意圖如圖2所示。
圖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限流無法正常處理。
圖3 網絡漏斗模型示意圖
3）活動獎品控制系統：春晚一共搞了4場活動，大約發了2.3億個現金紅包和十幾億張福卡。在這麼大規模的活動下，我們做到了0差錯0資損，沒有多發或者少發一個紅包，嚴格控制了福卡的發放比例，也合理控制了發獎速度。4場活動基本控制在3-5分鐘內完成，嚴格按照我們設定的預期模型執行。所有這些都得益於我們的獎品控制系統，對於這個系統設計上有3個基本原則：資金0資損、百萬級的獎品處理能力、靈活的獎品發放控制。
4）動態技術：客戶端的一個最大的問題就是版本發佈，有個成語叫做“覆水難收”，剛好比較形象地說明了這個問題。版本一旦發佈，如果有問題需要讓用戶再次升級，時間已經來不急了。爲了更好地控制客戶端的行爲，參數化、配置化就成了必不可少的利器。但參數化、配置化帶來了兩個問題：
- 客戶端預埋了很多邏輯，極大的增加了代碼複雜度，客戶端的代碼測試難度加大，質量很難保證。
- 因爲參數化、配置化，需要有機制能夠保證配置數據能儘可能實時下發給幾億客戶端，並且在最短的時間內生效。
對於客戶端複雜度增大的問題，主要通過多套機制保障。傳統的質量保障，加強測試力度。進行不同範圍內的人羣進行灰度。安排多輪演練，模擬各種配置場景。爲了保證春晚的萬無一失，年前增加了幾場小規模預熱，通過預熱發現儘可能多的問題，並進行規避。客戶端版本發佈後，產生的部分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
點擊閱讀更多，查看更多詳情