閱讀755 返回首頁    go 阿裏雲 go 技術社區[雲棲]


史上最複雜業務場景,逼出阿裏高可用三大法寶

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

image

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

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

image

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

  • 第一個階段為業務流量預估階段,通過曆史數據分析未來某一個時間點業務的訪問量會有多大;
  • 第二個階段為係統容量評估階段,初步計算每一個係統需要分配多少機器;
  • 第三個階段為容量的精調階段,通過全鏈路壓測來模擬大促時刻的用戶行為,在驗證站點能力的同時對整個站點的容量水位進行精細調整;
  • 第四個階段為流量控製階段,對係統配置限流閾值等係統保護措施,防止實際的業務流量超過預估業務流量的情況下,係統無法提供正常服務。


image


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

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

  • 1、模擬請求,通過對生產環境的一台機器發起模擬請求調用來達到壓力測試的目的;
  • 2、複製請求,通過將一台機器的請求複製多份發送到指定的壓測機器;
  • 3、請求轉發,將分布式環境中多台機器的請求轉發到一台機器上;
  • 4、調整負載均衡,修改負載均衡設備的權重,讓壓測的機器分配更多的請求。

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

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

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

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

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

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

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

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

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


image


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

我們對每一個係統都做好了粗略的容量計算,以為一切都會比較順利了,可是真實場景並非如此,當雙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的用戶請求。

image


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

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

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

image


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

前麵章節我們討論的都是”容量規劃”,我們知道容量規劃是基於一套精密的業務模型,而這個業務模型是根據曆年來的大促數據,以及複雜的預測模型推算出來的。然而,不論這個模型多麼強壯,它始終是一個預測。這就意味著我們存在著預測和現實流量有誤差。
這個並不僅僅是一個擔心,這個發生過非常多次。

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

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

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

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

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

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

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

image


下麵這個是我們流控的架構圖:

image


第一步,我們在程序入口給所有的方法都進行埋點;
第二步,我們把這些埋點方法的運行狀態,調用關係統計記錄下來;
第三步,我們通過從預設好的規則中心接收規則,來根據第二步中統計到的係統狀態進行控製。
然而,當係統發生流控的時候,係統雖然是安全的,但是它始在一個“受損”狀態下運行。所以我們也在問題排除之後,解除流量控製。用我們上麵的場景作為例子。一個鏈路上的一個下遊應用出現了問題,導致響應時間變長,從而導致上遊應用的係統負載過高。過了一會兒之後,這個下遊應用恢複了,響應時間大大縮短。然而這個時候,上遊應用的負載並不能馬上恢複,因為進來的請求已經堆積了一段時間了。

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

image


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

image


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

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

此外,基於阿裏在雙11大促上的多年的係統高可用保障經驗,全鏈路壓測服務6月份即將在阿裏雲上線(在原有雲產品PTS的基礎上進行全方位升級),通過模擬海量用戶的大流量場景,全方位驗證站點各個環節的可用性。壓測平台具備千萬/秒的用戶流量構造能力;從全國各地的CDN節點發起請求,最真實地模擬用戶行為;采用直接壓測生產環境的方式,精準探測站點的服務能力和性能瓶頸;壓測流量與正常流量隔離、不對線上正常的業務和數據造成汙染。歡迎大家關注和試用!
作者:遊驥&子矜
原文鏈接

最後更新:2017-06-06 07:38:21

  上一篇:go  《Vim實用技巧(第2版)》——第1章 Vim解決問題的方式 1.1認識 . 命令
  下一篇:go  《Git學習指南》——導讀