10年5次進化，雙11容量規劃如何實現成本與穩定的最佳平衡？
第十個雙11已圓滿結束，但是技術的探索永不止步。阿里技術推出《十年牧碼記》系列，邀請參與歷年雙11備戰的核心技術大牛，一起回顧阿里技術的變遷。
“穩定，壓倒一切”，如何實現雙11的平穩支撐是阿里技術人永恆的目標。今天，阿里資深技術專家遊驥，將圍繞“容量規劃的精準度與確定性”、“容量規劃相關環節的效率和成本”兩個因子，詳細解讀阿里容量規劃的五次歷史演進。
阿里資深技術專家遊驥
2018年是雙11的第十個年頭。每年雙11備戰環節，穩定性都是最受關注的頭等大事。
十年以來，穩定性相關的技術體系和雙11就像DNA的雙螺旋，彼此相生相長。在雙11場景的錘鍊之下，阿里的穩定性技術體系也成為了行業的標杆和效仿物件。
穿越10年，雙11給技術留下最深的認知應該算是突發大流量的衝擊。
從第一年開始，雙11的0點時刻就代表了我們的歷史最高業務訪問量，它通常是日常流量的幾十倍甚至上百倍。因此，如何讓一個技術和業務持續複雜的分散式站點去更平穩支撐好這突如其來的流量衝擊，是我們這10年來一直在解的題。
在雙11非常多的備戰環節中，容量規劃是最重要也最具挑戰的環節之一。在如此龐大的分散式系統架構下，該為每一個業務系統分配多少資源成為一大技術挑戰。
其實，容量規劃就好比是一個天平。天平的一端是成本，我們需要儘可能地用較少的資源來支撐好我們的業務；另一端是穩定性，在成本儘可能低的情況下，各個系統都能跑在一個合適的水位，既保障業務的正常運轉，又不出現區域性的資源浪費。
容量規劃演進路線
圍繞“容量規劃的精準度與確定性”、“容量規劃相關環節的效率和成本”這兩個最核心的驅動力因子，容量規劃主要經歷了五次大的演進：
一、人工估算容量階段
這個時期，雙11對於系統的資源需求尚處於人工估算階段。比如2009年的容量規劃就是主要通過人工估算的方式來完成的。各個系統的負責同學聚在一起開個會，將資訊彙總到excel表格上，花上半天或者一天的時間就把容量規劃的機器預算給定下來了。而且，各個系統通常都留了比較大的機器冗餘，業務的流量也不大，即使估算得不準也不會造成大的業務影響。
二、線下效能壓測評估容量階段
2009年的雙11，雖然業務量級還不夠近年雙11峰值的零頭，但是業務量的暴漲卻直接給我們的系統來了一輪非常大的衝擊。
因此，在2010年，我們開始著手開發一套系統化的容量規劃平臺，這個時候，容量計算的公式也被第一次提了出來。在這個公式裡有兩個至關重要的變數：預估業務量級與單機能力，預估業務量級代表對系統呼叫量的估算，而單機能力則代表單臺機器最大的服務能力。
容量規劃公式
其實，容量規劃公式理解起來並不複雜，預估業務量級除以單臺機器的服務能力得到業務系統所需要的最小機器數，最小機器數作為理論的機器數下限，加上一個buffer值確保萬無一失，得出最終需要準備的機器數。
預估業務量級為雙11等業務場景下的業務系統呼叫量的一個預計值，比如雙11 0點同時會有多少人訪問商品詳情、有多少人訪問我的購物車、有多少人下單、有多少人付款等等，預估業務量級我們通過ＢＩ（商業智慧）的分析，結合相應的預測演算法就能夠拿到比較準確的值。
單臺機器的服務能力相對就沒那麼好拿到，在2010年容量規劃平臺的1.0版本當中，單機能力的獲取主要通過線下的效能測試來獲取。我們當時已經擁有非常成熟的線下的效能測試環境，於是在效能測試環境對各個業務系統逐個進行效能測試，獲得了每個業務系統的單機能力值。
解決了兩個關鍵變數的之後，Csp容量規劃平臺正式登上阿里的技術舞臺，在2010年我們完成了從人工容量規劃到系統化容量規劃的過度。
三、線上壓測評估容量階段
Csp容量規劃平臺上線之後，在當年的雙11當中立刻起到立竿見影的效果，相對於之前純人肉的容量規劃模式，不但節省了人力成本，更重要的是通過資料計算的方式取代了傳統的經驗預估方式，大幅提升了我們在容量規劃的準確性。
為了獲取到更加精準的單臺機器服務能力值，在線上壓力測試的模式上，我們進行了非常多的探索，積累了不少經驗，這些經驗後續為業界的容量規劃之路樹立了典範：
a．線上模擬壓力測試獲取單機能力
線上模擬壓力測試對線上應用系統發起模擬呼叫。模擬請求保障了環境的真實性，能夠很大程度提升單機能力的準確性。線上模擬壓力測試操作起來比較便捷，能夠藉助的工具也非常多。
b. 線上流量複製壓力測試獲取單機能力
線上模擬壓力測試解決了壓測環境的真實性問題，卻沒有完全解決流量真實的問題，如果能做到流量和環境都是真實的，通過線上壓力測試拿到的單機能力才更具備說服力。線上流量複製通過將線上某一臺機器的流量擴大N倍複製到壓測的目標機器，當線上機器的流量非常低的時候，複製N倍流量還能夠有效地將流量進行放大。
c. 線上引流壓力測試獲取單機能力
針對流量複製帶來複雜性和成本問題，我們繼續去探索一種既精準又方便快捷的線上壓測模式。阿里的業務系統都是分散式架構，一個業務系統由若干機器同時提供服務，如果能夠把分散式環境的流量比較集中地呼叫到某一臺機器，就能起到壓測一臺機器的目的！於是線上引流壓力測試的模式被用到生產環境。
線上引流壓力測試使得阿里集團大部分業務系統能夠獲取到非常精準的線上單機能力，是目前使用的最廣泛的一種線上單機壓測模式。
四、全鏈路壓測階段
容量規劃平臺從單個點的維度解決了容量規劃的問題，然而在進行單點容量規劃的時候，有一個前提條件：下游依賴的服務狀態是非常好的，實際情況並非如此。
此外隨著分散式系統架構的技術組建越來越多，也很難將所有的技術環節從前到後都做好單點容量規劃。
雙11 當天0點到來的時候，從CDN到接入層、前端應用、後端服務、快取、儲存、中介軟體整個鏈路上都面臨著巨大流量，這個時候應用的服務狀態除了受自身影響，還會受到依賴環境影響，並且影響面會繼續傳遞到上游，哪怕一個環節出現一點誤差，誤差在上下游經過幾層累積後會造成什麼影響誰都無法確定。
所以除了進行事先的容量規劃，我們還需要建立起一套驗證機制，來驗證我們各個環節的準備都是符合預期的。驗證的最佳方法就是讓事件提前發生，如果我們的系統能夠提前經歷幾次“雙11”，容量的不確定性問題也就解決了。
2013年，對雙11穩定性來說是一個大的里程碑，我們在生產環境採取模式雙11的方式來全方位驗證容量的確定性。也就是說，全鏈路壓測的誕生解決了容量的確定性問題。2013年之後基於全鏈路壓測為核心，打造了一系列容量規劃相關的配套生態，提升能力的同時，降低整個環節的成本、提升效率。
事實上，提前對雙11進行模擬聽起來就不簡單，畢竟雙11的規模和複雜性都是空前的，要將雙11提前模擬出來，難度可想而知，全鏈路壓測的誕生主要攻克了下面4個大的挑戰：
跟雙11相關的業務系統上百個，並且牽涉到整條鏈路上所有的基礎設施和中介軟體，確保在整個流程中壓測流量能夠通暢無阻。
壓測的資料怎麼構造（億萬級的商品和使用者），資料模型與雙11儘可能貼近。
全鏈路壓測直接在線上的真實環境進行雙11模擬，保障對線上的資料和業務沒有影響。
雙11是一個上億使用者參與的盛大活動，製造每秒幾萬次使用者行為的超大規模流量平臺。
每年雙11前夕，全鏈路壓測都要組織好幾次，不斷地通過壓測發現問題進行迭代優化、全方位驗證業務的穩定性，我們的系統也只有在經過了全鏈路壓測的驗證之後才有信心迎接雙11 那天0點的到來。全鏈路壓測將是雙11、雙12等大促備戰最重要的核武器，並且隨著業務的發展不斷進化，持續發揮著不可替代的作用。
五、“全鏈路壓測+隔離環境+彈性伸縮”的技術生態體系
全鏈路壓測經過幾年的發展，從一開始的單一壓測平臺，逐步演變成一套技術生態體系。
隔離環境、邊壓邊彈、功能預演、商家端全鏈路壓測等技術產品都開始成為全鏈路壓測生態家族的重要成員，協力為保障好雙11的穩定性發揮重要作用。
全鏈路壓測體系演進
全鏈路壓測除了在能力上的不斷演進外，壓測效率也在不斷的提升，智慧化的技術能力逐步切入到壓測場景。
通過“root cause”自動定位壓測中出現的問題，在壓測過程中，進行變壓邊彈，把容量配比調節至最優，系統產出詳細的壓測報告，希望這一切都在沒有人的情況下自動完成。
“尖兵計劃“專案正在朝著這個目標不斷邁進，並且已經取得了階段性的進展，在2017年和2018年全鏈路的首次壓測成功率大幅提升。之前可能要壓很多次才能壓測成功，通過“尖兵計劃”進行無人的常態化隔離環境壓測，提前發現80%的表層問題，大型壓測的阻斷率大幅下降。
除了在智慧壓測上的突破，全鏈路壓測的身份也有了一個大的轉變。壓測平臺從一個阿里內部的大促備戰利器，通過產品化升級，輸出到了阿里雲PTS：https://www.aliyun.com/product/pts
成千上萬的外部網際網路企業可以站在阿里的肩膀上，通過PTS完成一次精準的容量壓測，輕鬆具備跟阿里一樣的容量規劃能力。在這背後全鏈路壓測也經歷了一次大的技術演進。
內外一套：用一套核心壓測技術底座同時支撐了內外部的兩套壓測體系，意味著大部分的工作都是可以複用的，極大降低了運維成本。
壓測能力升級：除了具備每秒億級別的請求流量輸出，同時具備秒級的大流量和大資料排程能力，展現出讓業界驚歎的壓測能力。
開放：具備了更加開放的擴充套件性，在支撐了更大規模的外部使用者群體的同時也更好支撐了阿里愈加豐富的經濟體業務形態；
開源相容：相容主流開源生態，讓已經配置的壓測需求可以不做任何變化直接跑在壓測平臺上；
解決方案化：在整個壓測的技術上下游，打造了錄製器、資料工廠、指令集、診斷專家等技術模組，從單一壓測平臺演變成為整個容量規劃的閉環解決方案。
未來，我們將全力為全球消費者、商家、合作伙伴帶來完美的體驗。十年牧碼，一騎絕塵！
你可能還喜歡
點選下方圖片即可閱讀
關注「阿里技術」
把握前沿技術脈搏