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