SREcon 是由計算機科學領域知名機構USENIX主辦，聚焦網站可靠性、系統工程、以及復雜分布式系統相關的運維行業技術盛會，今年SREcon17大會 Asia/Australia站于當地時間5月22日-24日在新加坡舉行。阿里中間件(Aliware)團隊高級技術專家張軍(花名游驥)和林佳梁(花名子矜)，受邀在本次大會上給現場聽眾分享了阿里巴巴容量規劃和全鏈路壓測方面的技術進展。

容量規劃的由來

阿里巴巴有著非常豐富的業務形態，每種業務都由一系列不同的業務系統來提供服務，每個業務系統都分布式地部署在不同的機器上。隨著業務的發展，特別是在大促營銷等活動場景下(比如雙11)，需要為每個業務系統準備多少機器對于阿里巴巴技術團隊來說是一大難題。

“容量規劃”正是為解決這個難題而誕生，容量規劃的目的在于讓每一個業務系統能夠清晰地知道：什么時候應該加機器、什么時候應該減機器?雙11等大促場景需要準備多少機器，既能保障系統穩定性、又能節約成本?

容量規劃四步走

在雙11等大促場景的準備過程當中，容量規劃一般分為四個階段：

第一個階段為業務流量預估階段，通過歷史數據分析未來某一個時間點業務的訪問量會有多大;

第二個階段為系統容量評估階段，初步計算每一個系統需要分配多少機器;

第三個階段為容量的精調階段，通過全鏈路壓測來模擬大促時刻的用戶行為，在驗證站點能力的同時對整個站點的容量水位進行精細調整;

第四個階段為流量控制階段，對系統配置限流閾值等系統保護措施，防止實際的業務流量超過預估業務流量的情況下，系統無法提供正常服務。

在第一個階段當中，通過合適的預測算法和豐富的歷史數據，通常能夠比較準確的預估業務的訪問量。即使在第一階段預估的業務訪問量跟實際的存在誤差，通過第四階段的流量控制也能夠確保站點始終處于良好的服務狀態。做完業務訪問量的預估之后，容量規劃進入第二階段，為系統進行容量的初步評估。如何通過精準的容量評估，用最小的成本來支撐好預估的業務量是這個階段的核心問題。

要計算一個系統需要多少臺機器，除了需要知道未來的業務調用量之外，還有一個更重要的變量，就是單臺機器的服務能力。獲取單臺機器的服務能力在阿里巴巴是通過單機壓測的方式來獲取。在阿里巴巴，為了精準地獲取到單臺機器的服務能力，壓力測試都是直接在生產環境進行，這有兩個非常重要的原因：單機壓測既需要保證環境的真實性，又要保證流量的真實性。否則獲取到的單臺機器服務能力值將會有比較大的誤差，影響到整個容量規劃的準確性。

生產環境進行單臺機器壓力測試的方式主要分為4種：

1、模擬請求，通過對生產環境的一臺機器發起模擬請求調用來達到壓力測試的目的;

2、復制請求，通過將一臺機器的請求復制多份發送到指定的壓測機器;

3、請求轉發，將分布式環境中多臺機器的請求轉發到一臺機器上;

4、調整負載均衡，修改負載均衡設備的權重，讓壓測的機器分配更多的請求。

模擬請求的實現比較簡單，也有非常多的開源或者商業工具可以來做請求模擬，比如apache ab、webbench、httpload、jmeter、loadrunner。通場情況下，新系統上線或者訪問量不大的系統采用這種方式來進行單機壓測。模擬請求的缺點在于，模擬請求和真實業務請求之間存在的差異，會對壓力測試的結構造成影響。模擬請求的另一個缺點在于寫請求的處理比較麻煩，因為寫請求可能會對業務數據造成污染，這個污染要么接受、要么需要做特殊的處理(比如將壓測產生的數據進行隔離)。

為了使得壓測的請求跟真實的業務請求更加接近，在壓測請求的來源方式上，我們嘗試從真實的業務流量進行錄制和回放，采用請求復制的方式來進行壓力測試。請求復制的方式比請求模擬請求方式的準確性更高，因為業務的請求更加真實了。

從不足上來看，請求復制同樣也面臨著處理寫請求臟數據的問題，此外復制的請求必須要將響應攔截下來，所以被壓測的這臺機器需要單獨提供，且不能提供正常的服務。請求復制的壓力測試方式，主要用于系統調用量比較小的場景。

對于系統調用量比較大的場景，我們有更好的處理辦法。其中的一種做法我們稱為請求的引流轉發，阿里巴巴的系統基本上都是分布式的，通過將多臺機器的請求轉發到一臺機器上，讓一臺機器承受更大的流量，從而達到壓力測試的目的。

請求的引流轉發方式不僅壓測結果非常精準、不會產生臟數據、而且操作起來也非常方便快捷，在阿里巴巴也是用的非常廣泛的一種單機壓測方式。當然，這種壓測方式也有一個前提條件就是系統的調用量需要足夠大，如果系統的調用量非常小，即使把所有的流量都引到一臺機器，還是無法壓測到瓶頸。

與請求引流轉發的方式類似，最后一種壓測方式同樣是讓分布式環境下的某一臺機器分配更多的請求。不同的地方在于采用的方式是通過去調整負載均衡設備的權重。調整負載均衡方式活的的壓測結果非常準確、并且不會產生臟數據。前提條件也需要分布式系統的調用量足夠大。

在阿里巴巴，單機壓測有一個專門的壓測平臺。壓測平臺在前面介紹的4種壓測方式基礎上，構件了一套自動化的壓測系統。在這個系統上，可以配置定時任務定期對系統進行壓測，也可以在任意想壓測的時間點手動觸發一次壓測。

在進行壓測的同時，實時探測壓測機器的系統負載，一旦系統負載達到預設的閾值即立刻停止壓測，同時輸出一份壓測報告。因為是在生產環境進行壓測，我們必須非常小心，保障壓測過程不影響到正常的業務。在單機壓測平臺上，每個月將進行5000次以上的壓測，系統發布或者大的變更都將通過單機壓測來驗證性能是否有變化，通過單機壓測獲取的單機服務能力值也是容量規劃一個非常重要的參考依據。

有了預估的業務訪問量，也知道了系統單臺機器的服務能力，粗略的要計算需要多少臺機器就非常簡單了。最小機器數 = 預估的業務訪問量 / 單機能力。通常情況下，我們會預留少量的buffer來防止評估的誤差和意外情況。

為什么需要全鏈路壓測?

進行到這一步，我們已經完成了系統容量的粗略評估，然而做到這一步是不是就夠了呢?過去的教訓曾經狠狠地給我們上了一課。

我們對每一個系統都做好了粗略的容量計算，以為一切都會比較順利了，可是真實場景并非如此，當雙11的零點到來的時候，許多系統的運行情況比我們想象的要更壞。原因在于真實的業務場景下，每個系統的壓力都比較大，而系統之間是有相互依賴關系的，單機壓測沒有考慮到依賴環節壓力都比較大的情況，會引入一個不確定的誤差。這就好比，我們要生產一個儀表，每一個零件都經過了嚴密的測試，最終把零件組裝成一個儀表，儀表的工作狀態會是什么樣的并不清楚。

事實上我們也有過血的教訓。在2012年的雙11 零點，我們一個系統的數據庫的網卡被打滿了，從而導致部分用戶無法正常購物，盡快當時我們做了非常充分的準備，但還有一些事情是我們沒考慮到的。

需要怎么樣才能解決這個問題?在2013年的雙11備戰過程當中，在很長一段時間內這都是我們面臨的一個難題。在中國，學生通常都會有期末考試，為了在期末考試中取得比較好的成績，老師通常會讓學生們在考試前先做幾套模擬題。

雙11對我們的系統來說就是一年一度的期末考試，所以我們冒出了這么一個想法：“如果能讓雙11提前發生，讓系統提前經歷雙11的模擬考驗，這個問題就解決了”。通過對雙11 零點的用戶行為進行一次高仿真的模擬，驗證整個站點的容量、性能和瓶頸點，同時驗證之前進行的容量評估是否合理，不合理的地方再進行適當的微調。

我們為此研發了一套新的壓測平臺—“全鏈路壓測”。雙11的模擬可不是一件簡單的事情，上億的用戶在阿里巴巴平臺上挑選、購買好幾百萬種不同類型的商品，場景的復雜性非常高。有三個最主要的難點需要解決：

1、用于的請求量非常大，在雙11 零點，每秒的用戶請求數超過1000w;

2、模擬的場景要跟雙11 零點盡可能的貼近，如果模擬的場景跟雙11 零點差距太大，將不具備實際的參考價值，而雙11 零點的業務場景非常復雜;

3、我們需要在生產環節去模擬雙11，如何去做到模擬的用戶請求不對正常的業務和數據造成影響。

為了能夠發出每秒1000w以上的用戶請求，全鏈路壓測構件了一套能夠發出超大規模用戶請求的流量平臺。流量平臺由一個控制節點和上千個worker節點組成，每一個worker節點上都部署了我們自己研發的壓測引擎。

壓測引擎除了需要支持阿里巴巴業務的請求協議，還需要具備非常好的性能，要不然1000w的用戶請求，我們將無法提供足夠多的worker節點。上千個壓測引擎彼此配合、緊密合作，我們能像控制一臺機器一樣控制整個壓測集群，隨心所欲的發出100w/s或者1000w/s的用戶請求。

1000w+/s的用戶請求量不僅要能夠發送出來，而且還需要跟雙11的用戶行為盡可能的接近，而雙11是一個非常復雜的業務場景。為了使得模擬能夠更加真實，我們做了非常多的工作。首先，我們從生產環境提取一份跟雙11 同等數量級的基礎數據(包含：買家、賣家、店鋪、商品、優惠等等)，做好篩選和敏感字段的脫敏，作為全鏈路壓測的基礎數據。然后基于這些基礎數據，結合前幾年的歷史數據，通過相應的預測算法，得到今年雙11的業務模型。

雙11的業務模型包含100多個業務因子，比如：買家數量、買家種類、賣家數量、賣家種類、商品數量、商品種類，pc和無線的占比，購物車里的商品數量，每一種業務類型的訪問量級等等)。有了業務模型之后，再根據業務模型構造相應的壓測請求，最終將壓測請求上傳到壓測引擎。

全鏈路壓測直接在生產環境進行雙11的模擬，在前面的單機壓測方式中也有提到，對于模擬請求的方式，需要考慮臟數據的處理方式。全鏈路壓測的所有數據都在生產環境做了數據隔離，包含存儲、緩存、消息、日志等一系列的狀態數據。在壓測請求上會打上特殊的標記，這個標記會隨著請求的依賴調用一直傳遞下去，任何需要對外寫數據的地方都會根據這個標記的判斷寫到隔離的區域，我們把這個區域叫做影子區域。全鏈路壓測對粗略的容量評估起到了精調的作用，使雙11 零點的各種不確定性變的更加確定。

我們在2013年雙11前夕的全鏈路壓測過程當中共發現了700多個系統問題，2014、2015、2016同樣也發現了好幾百個問題。這些問題如果沒有在全鏈路壓測的過程當中被發現，很有可能會在雙11 零點的真實業務場景當中暴露出來，將造成嚴重的可用性影響。

意外的甜蜜，超限后的流量控制如何做?

前面章節我們討論的都是”容量規劃”，我們知道容量規劃是基于一套精密的業務模型，而這個業務模型是根據歷年來的大促數據，以及復雜的預測模型推算出來的。然而，不論這個模型多么強壯，它始終是一個預測。這就意味著我們存在著預測和現實流量有誤差。

這個并不僅僅是一個擔心，這個發生過非常多次。

最近的一個例子是在16年的雙11，我們為某一個重要的場景預備了足以應付16.2萬每秒的峰值，然而那天的峰值實際上到達了20萬每秒，超過我們準備能力將近13%，你可能覺得這只會對峰值產生影響，這些額外的2W請求馬上就會被消耗掉，但并不是你想的這樣。

當一臺機器超負荷運轉的時候，這臺處理請求的時間會變長。這會給用戶帶來不好的體驗，用戶會試圖重復提交請求，這無形中又給系統帶來了更多的請求壓力。隨著請求堆積的月來越多，系統性能會逐漸下降甚至無法響應新的請求。

當一臺機器掛掉以后,負載均衡會把請求重定向到另外的機器上去，這又無形中給別的機器帶來了更多的任務，而這些機器也處于一個飽和的狀態，很快也會像第一臺機器一樣，也無法響應新的請求。

就這樣，在很短的時間之內，越來越多的機器會停止響應，最終導致整個集群都無法響應。這就使我們常常說的“雪崩效應”。一旦“雪崩”發生，就很難停止。我們必須有一個有效的機制，來監控和控制進入的流量，來防止災難的發生。

然而，流控并不僅僅用于流量高峰，它在很多的場景都可能用的到。比如在一個業務的鏈路上，有一個下游系統出現了問題，響應時間變得很長。這個問題在鏈路上會被放大，甚至導致整個鏈路不可用。這意味著流控也需要可以根據響應時間來控制系統的健康，當一個應用響應的時間超過閾值，我們可以認為這個應用不可控，應該迅速將它降級。

除了流控的激發原因之外，流控也可以靈活的定義流控的方式。不同的業務場景，可以采取不同的流控方式。比如說，對于有的應用，我們可以簡單的丟棄這個請求，有的應用，則需要對下游應用進行降級，甚至直接加入黑名單。而有的應用，則需要把這些多余的請求排隊，等到高峰期過后，系統沒有那么忙碌之后，再逐步消耗這些流量。

所以，我們最終的流控框架可以從三個緯度著手，運行狀況，調用關系，流控方式。應用可以靈活的根據自己的需求，任意組合。

下面這個是我們流控的架構圖：

第一步，我們在程序入口給所有的方法都進行埋點;

第二步，我們把這些埋點方法的運行狀態，調用關系統計記錄下來;

第三步，我們通過從預設好的規則中心接收規則，來根據第二步中統計到的系統狀態進行控制。

然而，當系統發生流控的時候，系統雖然是安全的，但是它始在一個“受損”狀態下運行。所以我們也在問題排除之后，解除流量控制。用我們上面的場景作為例子。一個鏈路上的一個下游應用出現了問題，導致響應時間變長，從而導致上游應用的系統負載過高。過了一會兒之后，這個下游應用恢復了，響應時間大大縮短。然而這個時候，上游應用的負載并不能馬上恢復，因為進來的請求已經堆積了一段時間了。

這就意味著，如果我們采用傳統的方式，用系統負載來判斷是否應該恢復流控，那么即使問題已經修復，系統地負載仍然處于一個比較高的狀態。這樣就會導致系統恢復慢。既要迅速恢復，同時也要系統穩定。最后我們采取的方式是，讓rt,load,允許通過的qps達到動態平衡。

讓我們來看一下最后取得的效果。用了新的算法之后，我們可以看到系統穩定在一定的范圍之內，同時當問題機器恢復之后，流量也能夠很快的恢復。

從近幾年雙11 零點的業務穩定性上來看，全鏈路壓測是一個明顯的分水嶺，在全鏈路壓測之后整個站點的穩定性明顯好于全鏈路壓測之前。全鏈路壓測已經成為阿里巴巴大促備戰的必要環節，無論是雙11大促、雙12大促，還是平時一些比較小的促銷活動，每一次活動之前都會進行好幾輪的全鏈路壓測來對系統進行一次全方位的模擬驗證，提前暴露各個環節的問題。全鏈路壓測的誕生使得阿里大促備戰的系統穩定性有了質的提升，被譽為大促備戰的核武器。

除了全鏈路壓測來驗證我們的容量規劃的正確性以外，流量控制的策略在我們的大促技術規劃時也很重要，限流框架通過 自由組合運行狀態，調用鏈路，限流措施的靈活組合，覆蓋了多種業務場景。同時，通過動態平衡，可以做到快恢復，最低的減低對用戶使用體驗的沖擊。流量控制和流量壓測兩者結合，讓我們的系統穩定健康地渡過各種極限業務場景。

【本文為51CTO專欄作者“阿里巴巴官方技術”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文