739
詳解雙11終極“核武器”：全鏈路壓測如何誕生？
本文內容來自阿裏巴巴集團雙11技術團隊撰寫的《盡在雙11：阿裏巴巴技術演進與超越》一書。該書被阿裏巴巴集團CTO行癲盛讚為“迄今為止對雙11技術演進最客觀、最詳實的還原”，目前正在全國火熱銷售中。
全鏈路壓測被譽為大促備戰的“核武器”。如果之前關注過阿裏雙11相關的技術總結，對全鏈路壓測一定不會陌生，這個詞的出場率幾乎是100%，從對雙11穩定性的價值來看，用“核武器”來形容全鏈路壓測毫不為過。
曆年的雙11備戰過程中，最大的困難在於評估從用戶登錄到完成購買的整個鏈條中，核心頁麵和交易支付的實際承載能力。自2009年第一次雙11以來，每年雙11的業務規模增長迅速，零點的峰值流量帶給我們的不確定性越來越大。
2010年，我們上線了容量規劃平台從單個點的維度解決了容量規劃的問題，然而在進行單點容量規劃的時候，有一個前提條件：下遊依賴的服務狀態是非常好的。
實際情況並非如此，雙11 零點到來時，從CDN到接入層、前端應用、後端服務、緩存、存儲、中間件整個鏈路都麵臨著巨大流量，這時應用的服務狀態除了受自身影響，還會受到環境影響，並且影響麵會繼續傳遞到上遊，哪怕一個環節出現一點誤差，誤差在上下遊經過幾層累積後會造成什麼影響誰都無法確定。
所以除了事先進行容量規劃，還需要建立起一套驗證機製，來驗證我們各個環節的準備都是符合預期的。驗證的最佳方法就是讓事件提前發生，如果我們的係統能夠提前經曆幾次雙11，容量的不確定性問題也就解決了。全鏈路壓測的誕生就解決了容量的確定性問題！
提前對雙11進行模擬聽起來就不簡單，畢竟雙11的規模和複雜性都是空前的，要將雙11提前模擬出來，難度可想而知：
• 跟雙11相關的業務係統有上百個，並且牽涉整條鏈路上所有的基礎設施和中間件，如何確保壓測流量能夠通暢無阻，沒有死角？
• 壓測的數據怎麼構造（億萬級的商品和用戶），數據模型如何與雙11貼近？
• 全鏈路壓測直接在線上的真實環境進行雙11模擬，怎樣來保證對線上無影響？
• 雙11是一個上億用戶參與的盛大活動，所帶來的巨大流量要怎樣製作出來？
2013年8月中旬，當時高可用架構團隊的負責人叔同（高可用架構&運維產品&基礎產品團隊負責人、資深技術專家）接下了這個巨大的挑戰：打造一套全鏈路壓測平台。
平台需要在2013年雙11之前上線，錯過了這個時間點，我們就必須再等一年。
從立項到雙11，留給我們的時間隻有短短兩個多月，時間非常緊，我們需要在這麼短的時間裏應對一係列曆史級的挑戰。2013年阿裏搬到西溪園區，其他同學都是搬到新工位，全鏈路壓測項目組直接搬到了項目室，進行閉關攻堅。
1. 業務改造升級
2013年核心交易鏈路就有幾十條，牽涉多個BU的幾百位研發人員，這些業務鏈路絕大部分是沒法直接壓測的，需要進行相應的業務改造和中間件的升級。
推動幾百號人在短時間之內完成業務的改造在很多公司幾乎是不可能完成的，何況還牽涉中間件的升級，中間件的升級一般會有一個相對比較長的周期，有不少業務係統的中間件版本都非常古老（5年前的版本），需要確保無風險直接升級到最新版本。
在業務端我們需要逐條鏈路進行一一梳理，從請求進來的係統到請求的最後一個環節（複雜的業務會經過幾十個係統），每一個有阻壓測流量往下走的地方都進行特殊的邏輯改造。改造的業務點牽涉100多個，包括登錄驗證碼、安全策略、業務流程校驗等。
在基礎設施和中間件上，我們需要讓業務係統的代碼盡可能不需要修改，通用的技術通過基礎設施和中間件來屏蔽掉，比如壓測流量的標識怎樣在整個請求的生命周期中一直流轉下去，怎樣來對非法的請求進行攔截處理。
參與全鏈路壓測改造的技術人員體現了良好的協作精神和執行力，為了同一個目標齊頭並進、相互補位，原本認為幾乎不可能的事情，最終在一個月內完成了相應的業務改造和中間件升級。
2. 數據構造
數據構造有兩個核心點：
• 雙11的買家、賣家、商品數量都非常龐大，需要構造同數量級的業務數據；
• 需要確保業務數據的模型盡可能貼近雙11零點的真實場景，否則全鏈路壓測結果的誤差會比較大，參考的價值將會大打折扣。
為此我們專門搭建了全鏈路壓測的數據構造平台，對業務模型進行係統化的管理，同時完成海量業務數據的自動化構造，如圖2-5所示。
數據構造平台以線上數據為基礎，借助數據dump（dump：在特定時刻，將儲存裝置或儲存裝置之某部分的內容記錄在另一儲存裝置中）工具進行數據的抽取，並對關鍵數據進行相應的處理（脫敏、訂正等）後進入基礎數據池備用。基礎數據池是壓測數據的超集，具體壓測數據的構造基於基礎數據集進行數據的再加工。
除了需要有足夠量級的數據，我們要解決的另一個問題是數據的模型應該是怎樣的。借助BI工具結合預測算法對數據進行篩選建模，並結合每一年雙11的業務玩法進行修訂，產出一份最終的業務模型。業務模型的因子牽涉幾百個業務指標，包含買家數、買家類型、賣家數、賣家類型、優惠種類、優惠比例、購物車商品數、BC比例、移動PC比例、業務的量級等。
3. 數據隔離
全鏈路壓測要不要做數據隔離、怎樣來做數據隔離，在項目立項階段經過了非常多的討論甚至爭吵。在最開始的時候，我們想做邏輯隔離，直接把測試數據和正常數據寫到一起，通過特殊的標識區分開，這個方案很快就被放棄了：線上數據的安全性和完整性不能被破壞。
接下來我們提出了另一個方案，在所有寫數據的地方做mock（mock：軟件開發概念，指模擬），並不真正寫進去，這個方案不會對線上產生汙染，但評估時還是被放棄了：mock對壓測結果的準確性會產生幹擾，而我們需要一個最貼近實際行為的壓測結果。
經過反複討論，最終我們找到了一個既不汙染線上，又能保障壓測結果準確性的方案：在所有寫數據的地方對壓測流量進行識別，判斷一旦是壓測流量的寫，就寫到隔離的位置，包括存儲、緩存、搜索引擎等。
4. 流量構造
雙11是一場“剁手黨”的狂歡，零點的峰值流量是平時高峰的幾百倍，每秒幾百萬次的請求如何構造同樣成為大難題。我們嚐試通過瀏覽器引擎或者一些開源壓測工具的方式來模擬用戶請求，經過實際測試，要製作出雙11規模的用戶流量，瀏覽器引擎和開源壓測工具需要準備幾十萬台服務器的規模，成本是無法接受的，並且在集群控製、請求定製上存在不少限製。
既然沒有現成的工具可以使用，我們隻好選擇自己研發一套全鏈路壓測流量平台，如圖2-6所示。
全鏈路壓測的流量平台是一個典型的Master＋Slave結構：Master作為壓測管控台管理著上千個Slave節點；Slave節點作為壓測引擎，負責具體的請求發送。Master作為整個壓測平台的大腦，負責整個平台的運轉控製、命令發送、數據收集、決策等。
Slave節點部署在全球各地的CDN節點上，從而模擬從全球各地過來的用戶請求。整套全鏈路壓測的流量平台在壓測過程中平穩輸出1000多萬/秒的用戶請求，同時保持過億的移動端用戶長連接。
5. 正式上線
在兩個多月的時間裏，項目組的成員披星戴月，有一半時間在通宵，另外一半時間是淩晨3點以後下班。2013年10月17日淩晨的1號樓，全鏈路第一次登台亮相（如圖2-7所示），這一天對整個全鏈路壓測項目組的人都意義非凡，辛苦了兩個多月的“大殺招”終於要派上用場了！
當壓測開始的按鈕被按下去，大家都全神貫注地盯著各種係統等著流量上來，1分鍾、2分鍾過去了，我們的業務係統卻絲毫沒有流量進來。忙活了一晚上，第一次亮相狼狽收場，當時全場有200多號人，每一次讓大家準備好卻沒有流量發出去的時候，麵對著全場200多雙眼睛，壓測項目組每一個成員的手都是抖的。
好在第一次的失敗讓我們吸取了充分的經驗，又經過好幾個晝夜的奮戰，第二次的壓測比第一次進步了很多，到了第三次就已經能完全達到我們的使用預期了。
全鏈路壓測誕生之後為係統穩定性帶來的改變立竿見影，2013年經過了幾次全鏈路壓測，雙11零點的表現比以往任何一年都平順。全鏈路壓測也在阿裏一炮而紅，越來越多的業務希望能接入進來。
1. 平台化
海量的業務接入給全鏈路壓測平台帶來全新的挑戰：當時的全鏈路壓測操作都需要壓測項目組的成員來進行操控。隨著越來越多的業務接入全鏈路壓測平台，壓測項目組很快就成了瓶頸，壓測平台的能力急需升級。
2015年，全鏈路壓測“平台化”項目啟動，我們著手將全鏈路壓測朝著平台化的目標推進和實施，做到壓測能力開放、業務方自主壓測，讓更多業務方能夠享受到全鏈路壓測的優勢和便利，如圖2-8所示。
全鏈路壓測平台化項目的上線大幅提升了全鏈路壓測平台的服務能力：2015年大促備戰的3個月內，壓測平台總共受理近600多個壓測需求（比2014年提升20倍），執行壓測任務3000多次（比2014年提升30倍）。
2. 日常化
全鏈路壓測的壓測流量和正式流量經過的路徑是一致的，如果鏈路中某一個節點被壓掛或者觸發限流，勢必會影響線上用戶的正常訪問。為了減少影響，全鏈路壓測一般都安排在淩晨，通宵達旦，非常辛苦！
為了減少熬夜，提升壓測幸福度，我們啟動了白天壓測的項目：將線上運行的機器動態隔離出一部分放到隔離環境中，這部分機器上隻有壓測流量可以訪問，白天在隔離環境的機器上進行壓測。隔離環境與線上環境幾乎一樣，從流量入口、中間件、應用後端實現完整隔離。
隔離環境完全打通了配置中心、服務注冊中心、消息中心、地址服務器等基礎設施，不需要業務係統做任何改造即可完成。並且是直接從線上機器按照特定規則選擇到隔離環境中，機型配置跟線上基本一致，使用完畢之後直接恢複到線上集群中，不會影響線上集群的容量。
大促備戰期間，我們可以白天在隔離環境中進行小目標、小範圍的全鏈路壓測，用極小的代價提前發現問題。由於隔離環境場景相對於其他線下環境更加真實、操作快捷、不占用額外機器資源，在預案演練、破壞性測試、線上問題排查、故障演練等其他場合也獲得了比較廣泛的應用。
2016年在三地五單元混合雲部署架構下，電商一半以上的資源部署在雲上。在龐大的電商係統背景下，如何能夠在最短的時間內完成一個單元的搭建和容量準備成為擺在我們麵前的一道難題，而全靠“經驗之談”和人工介入是不可能完成的任務。
2016年初，“大促容量彈性交付產品”立項，旨在減少甚至釋放活動場景的容量交付中的人工投入，並將大促容量交付的運維能力沉澱到係統中，使全鏈路容量具備“自動化”調整的能力。
我們提出了大促自動化備戰的想法，將大促容量準備的各個環節進行係統層麵的打通，從業務因子埋點、監控體係、模型預測、壓測數據構造、壓測流量發送、壓測結果分析、壓測報表進行自動化串聯，大幅縮減了在大促容量準備階段的人員投入和時間周期。圍繞全鏈路壓測的核心基礎設施，全鏈路壓測的周邊生態逐步建立起來，打通建站、容量、監控等配套技術體係，如圖2-9所示。
全鏈路壓測在保障係統穩定性的同時，也為業務穩定性的保障提供了強有力的支持，2016年我們落地了全鏈路功能測試、大促功能預演等一係列項目：創造性地在隔離環境提前將係統時間設置到雙11的零點。通過在這個提前的雙11環境購買一遍雙11的商品，進行充分的業務驗證，最大限度地降低雙11當天的業務問題。
每年雙11前夕，全鏈路壓測都要組織好幾次，不斷地通過壓測發現問題進行迭代優化，全方位驗證業務的穩定性，我們的業務係統也隻有在經過了全鏈路壓測的驗證之後才有信心迎接雙11零點的到來。全鏈路壓測將大促穩定性保障提升到新的高度，是雙11、雙12等大促備戰最重要的“核武器”，並且隨著業務的發展不斷進化，持續發揮著不可替代的作用。
最後更新：2017-06-20 15:01:45