阿里高可用的兩大法寶

      從 2009 年開始，阿里雙十一就成了流量最大、成交額最高、業務場景最複雜的電商大促活動。曾在 2011/12 年給淘寶技術團隊留下慘痛回憶的大促活動，也倒逼阿里技術人員加強對大促環節的加持。容量規劃、全鏈路壓測，這是阿里應對大促環境的兩大法寶，怎麼作的？

SREcon 是由計算機科學領域知名機構 USENIX 主辦，聚焦網站可靠性、系統工程、以及複雜分佈式系統相關的運維行業技術盛會，今年 SREcon17 大會 Asia/Australia 站於當地時間 5 月 22 日 -24 日在新加坡舉行。吸引了來自 Google、Facebook、微軟、阿里巴巴、百度和滴滴等全球著名互聯網科技公司的頂級技術專家，到會分享網站可靠性工程相關的議題，包含大規模網站可用性提高、資源規劃及性能優化等話題。

    

寫在前面

雙十一從 2009 誕生到如今，2013 年絕對是一個分水嶺。

爲何這麼說？由於 2013 有了全鏈路壓測。

每一年的 11 月 11 日 00：00：00，阿里巴巴集團最緊張激動的時刻到來了。多收檔的熱情這一刻開始爆發，反映到數字上是去年雙十一今人的記錄：24 小時交易額 1012 億，交易建立峯值 17.2w；而在二進制世界裏面，則是極短期內如海嘯般涌入的超大規模流量。

流量洪峯的殺傷力，曾在 2011 年和 2012 年給技術團隊留下了午夜驚魂的難忘回憶。然而隨着全鏈路壓測的登場，它改變了阿里巴巴對應流量洪峯的態度和方式，也一次次刷新中國互聯網世界的紀錄。

爲何須要容量規劃？

阿里巴巴有着很是豐富的業務形態，每種業務都由一系列不一樣的業務系統來提供服務，每一個業務系統都分佈式地部署在不一樣的機器上。隨着業務的發展，特別是在大促營銷等活動場景下（好比雙 11），須要爲每一個業務系統準備多少機器對於阿里巴巴技術團隊來講是一大難題。「容量規劃」正是爲解決這個難題而誕生，容量規劃的目的在於讓每個業務系統可以清晰地知道：何時應該加機器、何時應該減機器？雙 11 等大促場景須要準備多少機器，既能保障系統穩定性、又能節約成本？

容量規劃四步走

在雙 11 等大促場景的準備過程中，容量規劃通常分爲四個階段：

1. 業務流量預估階段：經過歷史數據分析將來某一個時間點業務的訪問量會有多大；

2. 系統容量評估階段：初步計算每個系統須要分配多少機器；

3. 容量的精調階段：經過全鏈路壓測來模擬大促時刻的用戶行爲，在驗證站點能力的同時對整個站點的容量水位進行精細調整；

4. 流量控制階段：對系統配置限流閾值等系統保護措施，防止實際的業務流量超過預估業務流量的狀況下，系統沒法提供正常服務。

在第一個階段當中，經過合適的預測算法和豐富的歷史數據，一般可以比較準確地預估業務的訪問量。即便在第一階段預估的業務訪問量跟實際的存在偏差，經過第四階段的流量控制也可以確保站點始終處於良好的服務狀態。作完業務訪問量的預估以後，容量規劃進入第二階段，爲系統進行容量的初步評估。如何經過精準的容量評估，用最小的成原本支撐好預估的業務量是這個階段的核心問題。

要計算一個系統須要多少臺機器，除了須要知道將來的業務調用量以外，還有一個更重要的變量，就是單臺機器的服務能力。獲取單臺機器的服務能力在阿里巴巴是經過單機壓測的方式來獲取。在阿里巴巴，爲了精準地獲取到單臺機器的服務能力，壓力測試都是直接在生產環境進行，這有兩個很是重要的緣由：單機壓測既須要保證環境的真實性，又要保證流量的真實性。不然獲取到的單臺機器服務能力值將會有比較大的偏差，影響到整個容量規劃的準確性。

生產環境進行單臺機器壓力測試的方式主要分爲 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 多個系統問題，201四、201五、2016 一樣也發現了好幾百個問題。這些問題若是沒有在全鏈路壓測的過程中被發現，頗有可能會在雙 11 零點的真實業務場景當中暴露出來，將形成嚴重的可用性影響。

超限後的流量控制如何作？

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

這個並不只僅是一個擔憂，這個發生過很是屢次。最近的一個例子是在 16 年的雙 11，咱們爲某一個重要的場景預備了足以應付 16.2 萬每秒的峯值，然而那天的峯值實際上到達了 20 萬每秒，超過咱們準備能力將近 13%，你可能以爲這隻會對峯值產生影響，這些額外的 2W 請求立刻就會被消耗掉，但並非你想的這樣。

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

當一臺機器掛掉之後, 負載均衡會把請求重定向到另外的機器上去，這又無形中給別的機器帶來了更多的任務，而這些機器也處於一個飽和的狀態，很快也會像第一臺機器同樣，也沒法響應新的請求。就這樣，在很短的時間以內，愈來愈多的機器會中止響應，最終致使整個集羣都沒法響應。這就使咱們經常說的「雪崩效應」。一旦「雪崩」發生，就很難中止。咱們必須有一個有效的機制，來監控和控制進入的流量，來防止災難的發生。

然而，流控並不只僅用於流量高峯，它在不少的場景均可能用的到。好比在一個業務的鏈路上，有一個下游系統出現了問題，響應時間變得很長。這個問題在鏈路上會被放大，甚至致使整個鏈路不可用。這意味着流控也須要能夠根據響應時間來控制系統的健康，當一個應用響應的時間超過閾值，咱們能夠認爲這個應用不可控，應該迅速將它降級。

除了流控的激發緣由以外，流控也能夠靈活的定義流控的方式。不一樣的業務場景，能夠採起不一樣的流控方式。好比說，對於有的應用，咱們能夠簡單的丟棄這個請求，有的應用，則須要對下游應用進行降級，甚至直接加入黑名單。而有的應用，則須要把這些多餘的請求排隊，等到高峯期事後，系統沒有那麼忙碌以後，再逐步消耗這些流量。

因此，咱們最終的流控框架能夠從三個緯度着手，運行情況，調用關係，流控方式。應用能夠靈活的根據本身的需求，任意組合。

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

• 第一步，咱們在程序入口給全部的方法都進行埋點；

• 第二步，咱們把這些埋點方法的運行狀態，調用關係統計記錄下來；

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

然而，當系統發生流控的時候，系統雖然是安全的，可是它始在一個「受損」狀態下運行。因此咱們也在問題排除以後，解除流量控制。用咱們上面的場景做爲例子。一個鏈路上的一個下游應用出現了問題，致使響應時間變長，從而致使上游應用的系統負載太高。過了一下子以後，這個下游應用恢復了，響應時間大大縮短。然而這個時候，上游應用的負載並不能立刻恢復，由於進來的請求已經堆積了一段時間了。

這就意味着，若是咱們採用傳統的方式，用系統負載來判斷是否應該恢復流控，那麼即便問題已經修復，系統地負載仍然處於一個比較高的狀態。這樣就會致使系統恢復慢。既要迅速恢復，同時也要系統穩定。最後咱們採起的方式是，讓 rt,load, 容許經過的 qps 達到動態平衡。

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

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

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