SREcon 是由計算機(jī)科學(xué)領(lǐng)域知名機(jī)構(gòu)USENIX主辦，聚焦網(wǎng)站可靠性、系統(tǒng)工程、以及復(fù)雜分布式系統(tǒng)相關(guān)的運(yùn)維行業(yè)技術(shù)盛會，今年SREcon17大會 Asia/Australia站于當(dāng)?shù)貢r間5月22日-24日在新加坡舉行。阿里中間件（Aliware）團(tuán)隊高級技術(shù)專家張軍（花名游驥）和林佳梁（花名子矜），受邀在本次大會上給現(xiàn)場聽眾分享了阿里巴巴容量規(guī)劃和全鏈路壓測方面的技術(shù)進(jìn)展。

容量規(guī)劃的由來

阿里巴巴有著非常豐富的業(yè)務(wù)形態(tài)，每種業(yè)務(wù)都由一系列不同的業(yè)務(wù)系統(tǒng)來提供服務(wù)，每個業(yè)務(wù)系統(tǒng)都分布式地部署在不同的機(jī)器上。隨著業(yè)務(wù)的發(fā)展，特別是在大促營銷等活動場景下（比如雙11），需要為每個業(yè)務(wù)系統(tǒng)準(zhǔn)備多少機(jī)器對于阿里巴巴技術(shù)團(tuán)隊來說是一大難題。

“容量規(guī)劃”正是為解決這個難題而誕生，容量規(guī)劃的目的在于讓每一個業(yè)務(wù)系統(tǒng)能夠清晰地知道：什么時候應(yīng)該加機(jī)器、什么時候應(yīng)該減機(jī)器？雙11等大促場景需要準(zhǔn)備多少機(jī)器，既能保障系統(tǒng)穩(wěn)定性、又能節(jié)約成本？

容量規(guī)劃四步走

在雙11等大促場景的準(zhǔn)備過程當(dāng)中，容量規(guī)劃一般分為四個階段：

• 第一個階段為業(yè)務(wù)流量預(yù)估階段，通過歷史數(shù)據(jù)分析未來某一個時間點業(yè)務(wù)的訪問量會有多大；
• 第二個階段為系統(tǒng)容量評估階段，初步計算每一個系統(tǒng)需要分配多少機(jī)器；
• 第三個階段為容量的精調(diào)階段，通過全鏈路壓測來模擬大促時刻的用戶行為，在驗證站點能力的同時對整個站點的容量水位進(jìn)行精細(xì)調(diào)整；
• 第四個階段為流量控制階段，對系統(tǒng)配置限流閾值等系統(tǒng)保護(hù)措施，防止實際的業(yè)務(wù)流量超過預(yù)估業(yè)務(wù)流量的情況下，系統(tǒng)無法提供正常服務(wù)。

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

要計算一個系統(tǒng)需要多少臺機(jī)器，除了需要知道未來的業(yè)務(wù)調(diào)用量之外，還有一個更重要的變量，就是單臺機(jī)器的服務(wù)能力。獲取單臺機(jī)器的服務(wù)能力在阿里巴巴是通過單機(jī)壓測的方式來獲取。在阿里巴巴，為了精準(zhǔn)地獲取到單臺機(jī)器的服務(wù)能力，壓力測試都是直接在生產(chǎn)環(huán)境進(jìn)行，這有兩個非常重要的原因：單機(jī)壓測既需要保證環(huán)境的真實性，又要保證流量的真實性。否則獲取到的單臺機(jī)器服務(wù)能力值將會有比較大的誤差，影響到整個容量規(guī)劃的準(zhǔn)確性。
生產(chǎn)環(huán)境進(jìn)行單臺機(jī)器壓力測試的方式主要分為4種：

• 1、模擬請求，通過對生產(chǎn)環(huán)境的一臺機(jī)器發(fā)起模擬請求調(diào)用來達(dá)到壓力測試的目的；
• 2、復(fù)制請求，通過將一臺機(jī)器的請求復(fù)制多份發(fā)送到指定的壓測機(jī)器；
• 3、請求轉(zhuǎn)發(fā)，將分布式環(huán)境中多臺機(jī)器的請求轉(zhuǎn)發(fā)到一臺機(jī)器上；
• 4、調(diào)整負(fù)載均衡，修改負(fù)載均衡設(shè)備的權(quán)重，讓壓測的機(jī)器分配更多的請求。

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

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

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

對于系統(tǒng)調(diào)用量比較大的場景，我們有更好的處理辦法。其中的一種做法我們稱為請求的引流轉(zhuǎn)發(fā)，阿里巴巴的系統(tǒng)基本上都是分布式的，通過將多臺機(jī)器的請求轉(zhuǎn)發(fā)到一臺機(jī)器上，讓一臺機(jī)器承受更大的流量，從而達(dá)到壓力測試的目的。

請求的引流轉(zhuǎn)發(fā)方式不僅壓測結(jié)果非常精準(zhǔn)、不會產(chǎn)生臟數(shù)據(jù)、而且操作起來也非常方便快捷，在阿里巴巴也是用的非常廣泛的一種單機(jī)壓測方式。當(dāng)然，這種壓測方式也有一個前提條件就是系統(tǒng)的調(diào)用量需要足夠大，如果系統(tǒng)的調(diào)用量非常小，即使把所有的流量都引到一臺機(jī)器，還是無法壓測到瓶頸。

與請求引流轉(zhuǎn)發(fā)的方式類似，最后一種壓測方式同樣是讓分布式環(huán)境下的某一臺機(jī)器分配更多的請求。不同的地方在于采用的方式是通過去調(diào)整負(fù)載均衡設(shè)備的權(quán)重。調(diào)整負(fù)載均衡方式活的的壓測結(jié)果非常準(zhǔn)確、并且不會產(chǎn)生臟數(shù)據(jù)。前提條件也需要分布式系統(tǒng)的調(diào)用量足夠大。

在阿里巴巴，單機(jī)壓測有一個專門的壓測平臺。壓測平臺在前面介紹的4種壓測方式基礎(chǔ)上，構(gòu)件了一套自動化的壓測系統(tǒng)。在這個系統(tǒng)上，可以配置定時任務(wù)定期對系統(tǒng)進(jìn)行壓測，也可以在任意想壓測的時間點手動觸發(fā)一次壓測。

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

有了預(yù)估的業(yè)務(wù)訪問量，也知道了系統(tǒng)單臺機(jī)器的服務(wù)能力，粗略的要計算需要多少臺機(jī)器就非常簡單了。最小機(jī)器數(shù) ＝ 預(yù)估的業(yè)務(wù)訪問量 ／ 單機(jī)能力。通常情況下，我們會預(yù)留少量的buffer來防止評估的誤差和意外情況。

為什么需要全鏈路壓測？

進(jìn)行到這一步，我們已經(jīng)完成了系統(tǒng)容量的粗略評估，然而做到這一步是不是就夠了呢？過去的教訓(xùn)曾經(jīng)狠狠地給我們上了一課。

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

事實上我們也有過血的教訓(xùn)。在2012年的雙11 零點，我們一個系統(tǒng)的數(shù)據(jù)庫的網(wǎng)卡被打滿了，從而導(dǎo)致部分用戶無法正常購物，盡快當(dāng)時我們做了非常充分的準(zhǔn)備，但還有一些事情是我們沒考慮到的。

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

雙11對我們的系統(tǒng)來說就是一年一度的期末考試，所以我們冒出了這么一個想法：“如果能讓雙11提前發(fā)生，讓系統(tǒng)提前經(jīng)歷雙11的模擬考驗，這個問題就解決了”。通過對雙11 零點的用戶行為進(jìn)行一次高仿真的模擬，驗證整個站點的容量、性能和瓶頸點，同時驗證之前進(jìn)行的容量評估是否合理，不合理的地方再進(jìn)行適當(dāng)?shù)奈⒄{(diào)。

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

• 1、用于的請求量非常大，在雙11 零點，每秒的用戶請求數(shù)超過1000w；
• 2、模擬的場景要跟雙11 零點盡可能的貼近，如果模擬的場景跟雙11 零點差距太大，將不具備實際的參考價值，而雙11 零點的業(yè)務(wù)場景非常復(fù)雜；
• 3、我們需要在生產(chǎn)環(huán)節(jié)去模擬雙11，如何去做到模擬的用戶請求不對正常的業(yè)務(wù)和數(shù)據(jù)造成影響。

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

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

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

雙11的業(yè)務(wù)模型包含100多個業(yè)務(wù)因子，比如：買家數(shù)量、買家種類、賣家數(shù)量、賣家種類、商品數(shù)量、商品種類，pc和無線的占比，購物車?yán)锏纳唐窋?shù)量，每一種業(yè)務(wù)類型的訪問量級等等）。有了業(yè)務(wù)模型之后，再根據(jù)業(yè)務(wù)模型構(gòu)造相應(yīng)的壓測請求，最終將壓測請求上傳到壓測引擎。

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

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

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

前面章節(jié)我們討論的都是”容量規(guī)劃”，我們知道容量規(guī)劃是基于一套精密的業(yè)務(wù)模型，而這個業(yè)務(wù)模型是根據(jù)歷年來的大促數(shù)據(jù)，以及復(fù)雜的預(yù)測模型推算出來的。然而，不論這個模型多么強(qiáng)壯，它始終是一個預(yù)測。這就意味著我們存在著預(yù)測和現(xiàn)實流量有誤差。
這個并不僅僅是一個擔(dān)心，這個發(fā)生過非常多次。

最近的一個例子是在16年的雙11，我們?yōu)槟骋粋€重要的場景預(yù)備了足以應(yīng)付16.2萬每秒的峰值，然而那天的峰值實際上到達(dá)了20萬每秒，超過我們準(zhǔn)備能力將近13%，你可能覺得這只會對峰值產(chǎn)生影響，這些額外的2W請求馬上就會被消耗掉，但并不是你想的這樣。

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

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

就這樣，在很短的時間之內(nèi)，越來越多的機(jī)器會停止響應(yīng)，最終導(dǎo)致整個集群都無法響應(yīng)。這就使我們常常說的“雪崩效應(yīng)”。一旦“雪崩”發(fā)生，就很難停止。我們必須有一個有效的機(jī)制，來監(jiān)控和控制進(jìn)入的流量，來防止災(zāi)難的發(fā)生。

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

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

所以，我們最終的流控框架可以從三個緯度著手，運(yùn)行狀況，調(diào)用關(guān)系，流控方式。應(yīng)用可以靈活的根據(jù)自己的需求，任意組合。

下面這個是我們流控的架構(gòu)圖：

第一步，我們在程序入口給所有的方法都進(jìn)行埋點；
第二步，我們把這些埋點方法的運(yùn)行狀態(tài)，調(diào)用關(guān)系統(tǒng)計記錄下來；
第三步，我們通過從預(yù)設(shè)好的規(guī)則中心接收規(guī)則，來根據(jù)第二步中統(tǒng)計到的系統(tǒng)狀態(tài)進(jìn)行控制。
然而，當(dāng)系統(tǒng)發(fā)生流控的時候，系統(tǒng)雖然是安全的，但是它始在一個“受損”狀態(tài)下運(yùn)行。所以我們也在問題排除之后，解除流量控制。用我們上面的場景作為例子。一個鏈路上的一個下游應(yīng)用出現(xiàn)了問題，導(dǎo)致響應(yīng)時間變長，從而導(dǎo)致上游應(yīng)用的系統(tǒng)負(fù)載過高。過了一會兒之后，這個下游應(yīng)用恢復(fù)了，響應(yīng)時間大大縮短。然而這個時候，上游應(yīng)用的負(fù)載并不能馬上恢復(fù)，因為進(jìn)來的請求已經(jīng)堆積了一段時間了。

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

讓我們來看一下最后取得的效果。用了新的算法之后，我們可以看到系統(tǒng)穩(wěn)定在一定的范圍之內(nèi)，同時當(dāng)問題機(jī)器恢復(fù)之后，流量也能夠很快的恢復(fù)。

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

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

此外，基于阿里在雙11大促上的多年的系統(tǒng)高可用保障經(jīng)驗，全鏈路壓測服務(wù)6月份即將在阿里云上線（在原有云產(chǎn)品PTS的基礎(chǔ)上進(jìn)行全方位升級），通過模擬海量用戶的大流量場景，全方位驗證站點各個環(huán)節(jié)的可用性。壓測平臺具備千萬／秒的用戶流量構(gòu)造能力；從全國各地的CDN節(jié)點發(fā)起請求，最真實地模擬用戶行為；采用直接壓測生產(chǎn)環(huán)境的方式，精準(zhǔn)探測站點的服務(wù)能力和性能瓶頸；壓測流量與正常流量隔離、不對線上正常的業(yè)務(wù)和數(shù)據(jù)造成污染。歡迎大家關(guān)注和試用！
作者：游驥&子矜

總結(jié)

以上是生活随笔為你收集整理的史上最复杂业务场景，逼出阿里高可用三大法宝的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。