時間：2016年10月29日凌晨
地點：阿里巴巴西溪園區“光明頂”
事件：200多人聚在一起，精神抖擻，摩拳擦掌。這陣勢，是要去約群架嗎？別緊張，他們只是在進行一次雙11的模擬演習—全鏈路壓測。

歷年的雙11備戰過程當中，最大的困難在于評估從用戶登錄到完成購買的整個鏈條中，核心頁面和交易支付的實際承載能力。自2009年第一次雙11以來，每年雙11的業務規模增長迅速，0點的峰值流量帶給我們的不確定性越來越大。

2010年，我們上線了容量規劃平臺從單個點的維度解決了容量規劃的問題，然而在進行單點容量規劃的時候，有一個前提條件：下游依賴的服務狀態是非常好的。實際情況并非如此，雙11 當天0點到來的時候，從CDN到接入層、前端應用、后端服務、緩存、存儲、中間件整個鏈路上都面臨著巨大流量，這個時候應用的服務狀態除了受自身影響，還會受到依賴環境影響，并且影響面會繼續傳遞到上游，哪怕一個環節出現一點誤差，誤差在上下游經過幾層累積后會造成什么影響誰都無法確定。

所以除了進行事先的容量規劃，我們還需要建立起一套驗證機制，來驗證我們各個環節的準備都是符合預期的。驗證的最佳方法就是讓事件提前發生，如果我們的系統能夠提前經歷幾次“雙11”，容量的不確定性問題也就解決了。全鏈路壓測的誕生解決了容量的確定性問題！

全鏈路壓測1.0從無到有

提前對雙11進行模擬聽起來就不簡單，畢竟雙11的規模和復雜性都是空前的，要將雙11提前模擬出來，難度可想而知：

1、跟雙11相關的業務系統上百個，并且牽涉到整條鏈路上所有的基礎設施和中間件，如何確保壓測流量能夠通暢無阻，沒有死角？

2、壓測的數據怎么構造（億萬級的商品和用戶），數據模型如何與雙11貼近？

3、全鏈路壓測直接在線上的真實環境進行雙11模擬，怎么樣來保障對線上無影響？

4、雙11是一個上億用戶參與的盛大活動，所帶來的巨大流量要怎么樣制作出來？

來看下我們需要面對的挑戰：

以2016年雙11前30分鐘為例，每秒交易峰值17.5W筆，每秒支付峰值12W筆，相關鏈路光核心系統上百個，還有龐大的底層基礎設施（網絡、IDC、硬件、虛擬化、調度、彈性能力等），以及所有的中間件服務、數據庫、存儲，我們保障雙11的需求分層依次是確保沒有瓶頸短板、合理規劃容量配比降低成本、根據壓測模型動態調配容量配比。

但是線下壓測（沒有參考價值）、單機類型壓測+估算模型（無法識別全局瓶頸）、單鏈路壓測（無法識別真實業務場景下多鏈路沖擊下的短板）都顯然遠遠無法滿足需求，為了讓最真實的情況能夠提前預演，我們最終采用了這套模擬全球幾億用戶一起購物狂歡的方案-全鏈路壓測平臺。而它從2013年到2016年的4個年頭里已經發展到3.0版本。

下圖是這幾年主要完成的工作。

下面就其中一些關鍵點做下說明：

關于業務改造

涉及業務點100多個，交易鏈路幾十條，相關研發同學幾百號人，只要是寫相關接口肯定需要改造，壓測設計的原則是業務系統的代碼盡可能的不做修改、通用的技術通過基礎設施和中間件來處理，比如壓測流量的標識怎么在整個請求生命周期中一直傳遞下去、怎么樣來對非法的請求做攔截處理。

關于數據構造

數據構造有兩個關鍵點：

1、由于參與雙11的買家、賣家、商品數量都非常龐大，需要構造同數量級的龐大業務數據；

2、同時業務數據的模型要盡可能貼近雙11當天0點的真實場景；

以上兩個關鍵點必須同時做到，否則全鏈路壓測結果的誤差會比較大，參考的價值將會大打折扣。我們為此專門搭建了全鏈路壓測的數據構造平臺，構建業務模型，同時完成海量業務數據的自動化準備。

其實關于數據的模型應該是怎么樣的問題。我們借助了BI工具結合預測算法對數據進行篩選建模，并結合每一年雙11的業務玩法進行修訂，產出一份最終的業務模型。業務模型的因子牽涉幾百個業務指標，包含買家數、買家類型、賣家數、賣家類型、優惠種類、優惠比例、購物車商品數、bc比例、無線pc比例，業務的量級等等。

關于數據隔離

比如直接把測試數據和正常數據寫到一起，通過特殊的標識能夠區分開，出于對線上的數據的安全性和完整性不能被破壞的考量，這個方案很快就被放棄了。然后有人提出了另一個方案，在所有寫數據的地方做mock，并不真的寫進去，這個方案不會對線上產生污染，但也還是放棄了：mock對壓測結果的準確性會產生干擾，而我們需要一個最貼近實際行為的壓測結果。

經過反復的討論，最終找到了一個既不污染線上、又能保障壓測結果準確性的方案：所有寫數據的地方對壓測流量進行識別，判斷一旦是壓測流量的寫，就寫到隔離的位置，包括存儲、緩存、搜索引擎等等。

關于流量構造

雙11當天0點的峰值流量是平時高峰的幾百倍，每秒鐘幾百萬次的請求如何構造同樣成了壓測的大難題。瀏覽器引擎或者一些開源壓測工具來模擬用戶請求的做法經過實際測試，要制作出雙11規模的用戶流量需要準備幾十萬臺服務器的規模，成本是無法接受的，并且在集群控制、請求定制上存在不少限制。既然沒有現成的工具可以使用，只好選擇自己研發一套全鏈路壓測的流量平臺。

而隨著集團業務需求越來越多，急需將全鏈路壓測朝著平臺化推進和實施，做到壓測能力開放、業務方自主壓測，讓更多業務方能夠享受到全鏈路壓測的優勢和便利。平臺化上線之后大幅提升了全鏈路壓測平臺的服務能力，比如2015年大促備戰的3個月內，壓測平臺總共受理近600多個壓測需求（比14年提升20倍），執行壓測任務3000多次（比14年提升30倍），最重要的，這也為阿里云即將推出的性能測試PTS鉑金版做了很好的基礎建設。

生態化

2016年在三地五單元混合云部署架構下，電商一半以上的資源都部署在云上。如何能夠在最短的時間內完成一個單元的搭建和容量準備成為擺在我們面前的一道難題。“大促容量彈性交付產品”在年初的時候立項，旨在減少甚至釋放活動場景的容量交付中人工投入，將大促容量交付的運維能力沉淀到系統中，使全鏈路容量具備“自動化”調整的能力。

我們又提出了大促自動化備戰的想法，將大促容量準備的各環節進行系統層面的打通，從業務因子埋點、監控體系、模型預測、壓測數據構造、壓測流量發送、壓測結果分析、壓測報表進行自動化的串聯，大幅縮減了我們在大促容量準備階段的人員投入和時間周期。圍繞全鏈路壓測的核心基礎設施，全鏈路壓測的周邊生態逐步建立起來，打通建站、容量、監控等配套技術體系。

阿里云發布T級數據壓測的終極秘笈

阿里云的壓測解決方案-性能測試服務 PTS 就脫胎于阿里巴巴的雙11保障的核武器。在經過超高峰值、超高復雜度的千錘百煉后，性能測試 PTS(鉑金版)正式對外輸出，讓廣大企業級用戶能用最低的投入，享受阿里雙11保障級的性能測試服務。

PTS鉑金版目前已經將異常強大的流量構造能力和簡易友好的數據輸入方式提供出來。阿里云希望幫助企業騰出更多時間和成本去關注業務，而不再需要投入大量資源去研究壓測的引擎、改造并讓它適應業務特性，也不需要搭建龐大的壓測集群以支持業務的高并發度，甚至不需要專門的性能測試人員或者具備相當的測試專業知識的人員，以上這些會讓企業投入大量的人力成本、機器成本，性價比較低。PTS鉑金版提供了簡潔、高效、優質和高性價比的方案，它的優勢和特點是：

1、無限接近真實的流量：覆蓋到三四線城市的節點能真正模擬高并發和發起點分散的用戶行為，端到端之間的網絡瓶頸也能暴露無遺；

2、超高并發能力：低成本構造千萬TPS級的壓測流量，多協議支持（HTTP、HTTPS、TCP、UDP 等）；

3、壓測能力多維度動態支持：同時支持并發和TPS兩個維度設置，免除設置和換算的煩惱，壓測目標設置一步到位。壓測過程中還可以根據各種情況任意調整并發/TPS，靈活應對壓測場景下的多變環境；

4、使用零門檻：完全面向開發的交互設計，開發自測試，貼心的提供快捷壓測功能，1分鐘即可設置一個簡單壓測場景，快速熟悉產品功能；

5、復雜場景輕松應對：即使是電商交易類復雜場景，依舊可以方便的通過腳本拼裝，完全模擬用戶真實行為；

6、豐富的展現形式：壓測過程中重要指標實時展現，配合阿里云互聯網中間件的業務實時監控ARMS、分布式應用服務EDAS，可提供更全面、細致的性能指標，快速識別性能瓶頸。

來源：阿里技術
原文鏈接

總結

以上是生活随笔為你收集整理的200多位阿里工程师齐聚“光明顶”，双11模拟演习怎么搞？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。