摘要：?在整個穩(wěn)定性體系中，所包含的范圍非常廣泛，從機房的布線、網(wǎng)絡(luò)通信、硬件部署、應(yīng)用架構(gòu)、數(shù)據(jù)容災(zāi)等方面都與之相關(guān)。從共享服務(wù)中臺的角度看，則更多的是從應(yīng)用架構(gòu)設(shè)計和中間件平臺的維度對平臺的穩(wěn)定性實現(xiàn)更精確化的管理和保障。

在整個穩(wěn)定性體系中，所包含的范圍非常廣泛，從機房的布線、網(wǎng)絡(luò)通信、硬件部署、應(yīng)用架構(gòu)、數(shù)據(jù)容災(zāi)等方面都與之相關(guān)。從共享服務(wù)中臺的角度看，則更多的是從應(yīng)用架構(gòu)設(shè)計和中間件平臺的維度對平臺的穩(wěn)定性實現(xiàn)更精確化的管理和保障。本期開始，我們將從這個角度介紹阿里巴巴中間件團隊多年來為了提升平臺穩(wěn)定性所做出的一系列技術(shù)創(chuàng)新和成果，包括限流和降級、流量調(diào)度、業(yè)務(wù)開關(guān)、容量壓測和評估、全鏈路壓測平臺業(yè)務(wù)一直性平臺等。

第一期：限流和降級

由于第一期的內(nèi)容篇幅較多，我們將切分為上下兩個篇章。

一、限流和降級的產(chǎn)生背景

先設(shè)想一個場景，你開發(fā)了一個企業(yè)中非常核心的一個服務(wù)，日常情況下會有上百個應(yīng)用調(diào)用，如果對服務(wù)的調(diào)用不加限制的使用，可能會因為某個應(yīng)用開發(fā)的bug 或不合理的設(shè)計給服務(wù)造成非常大的壓力，直接導(dǎo)致所有服務(wù)節(jié)點全部被請求占滿，使得原本非常核心的應(yīng)用因為訪問服務(wù)超時而產(chǎn)生了很大的生成事故。從現(xiàn)象來說，所有服務(wù)節(jié)點看起來運行很繁忙，但從應(yīng)用方的角度來看，因為服務(wù)響應(yīng)時間過長，實際上該服務(wù)并沒有提供有效服務(wù)。從設(shè)置上來說，服務(wù)就是給其他應(yīng)用提供服務(wù)的，用戶怎么調(diào)用服務(wù)很難控制，所以必須從服務(wù)自身做好保護，否則可能因為一個小的問題造成平臺級的故障。

另一個是活動大促的場景，準(zhǔn)備好的50臺機器資源可以應(yīng)對預(yù)估的100萬參與人數(shù)，但實際情況是瞬間來了1000萬用戶，遠遠超過服務(wù)處理能力的訪問請求，會使后端的服務(wù)器直接滿負荷運算，并伴隨著大量的資源搶占和上下文切換，使平臺處理能力下降到一個極低的程度，影響業(yè)務(wù)請求的響應(yīng)時間。類似的還有因為一個社會熱點，應(yīng)用端出現(xiàn)用戶請求陡增的情況。

二、限流的作用和前期準(zhǔn)備

限流的作用相當(dāng)于電路上的保險絲，當(dāng)過載的時候掐掉一點流量，讓系統(tǒng)有能力集中資源以較快的深度處理 平臺處理能力范圍內(nèi) 的業(yè)務(wù)請求。也就是讓上面提到的大促場景中，僅讓1000萬用戶中的100萬用戶進入后端的處理流程中，將其余900萬用戶的請求通過隊列或直接阻擋在平臺處理單元之外的方式，保障平臺在處理能力范圍內(nèi)對100萬的用戶請求進行處理。

平臺要具備限流能力，需要配備好壓測和監(jiān)控能力。

通過壓測，我們可以知道服務(wù)實例的部署最大能滿足多少的業(yè)務(wù)請求。但傳統(tǒng)的壓力測試方法都是采用模擬的數(shù)據(jù)，從實踐的角度來看，這些壓測數(shù)據(jù)與在實際生產(chǎn)環(huán)境中所表現(xiàn)的指標(biāo)還是有比較大的偏差，也就是說，采用模擬數(shù)據(jù)進行壓力測試的方式并不能準(zhǔn)確測量出平臺的能力峰值。阿里巴巴中間件團隊經(jīng)過內(nèi)部5年+的全生態(tài)沉淀，開發(fā)出的針對分布式場景，可模擬海量用戶的真實業(yè)務(wù)場景的性能測試產(chǎn)品PTS，能更方便和準(zhǔn)確的對服務(wù)的容量進行評估，這在“如何打造系統(tǒng)穩(wěn)定平臺”之后的章節(jié)中會詳細介紹。

在掌握服務(wù)的容量后，接下來就是針對服務(wù)資源的使用情況進行監(jiān)控，通過資源監(jiān)控的指標(biāo)與之前所獲取的服務(wù)能力進行比較，如果超過服務(wù)處理上限則啟動限流。通過CPU、內(nèi)存和磁盤IO等資源的使用情況來判斷系統(tǒng)目前的負載往往是不準(zhǔn)確的。因為很多情況下系統(tǒng)本身的處理能力出于什么樣的水位跟這些操作系統(tǒng)資源的使用情況沒有一個清晰的對應(yīng)關(guān)系，所以在實際生產(chǎn)中，都會通過服務(wù)的QPS作為限流的關(guān)鍵判斷指標(biāo)。

三、阿里巴巴是如何做限流管控的

對于平臺限流的實現(xiàn)，先從一個典型服務(wù)化應(yīng)用架構(gòu)的角度來看。用戶的請求首先會通過前端接入層（一般采用Nginx），分發(fā)到后端的應(yīng)用集群上，應(yīng)用集群中主要負責(zé)用戶的前端交互以及業(yè)務(wù)需求對后端服務(wù)集群中的服務(wù)進行服務(wù)調(diào)用。為了避免出現(xiàn)遠超過系統(tǒng)處理負載上限的訪問請求，同時又能很好的兼顧安全問題，通過一些安全策略防止對平臺的惡意攻擊，所以最優(yōu)的限流攔截點在前端接入層面，因為一旦讓“洪流”進入到系統(tǒng)的下層，對于系統(tǒng)的沖擊以及限流的難度都會加大。

阿里巴巴是通過在 Nginx 上實現(xiàn)的擴展組件 TMD（taobao missile defense淘寶導(dǎo)彈防御系統(tǒng)）實現(xiàn)了接入層限流的主要工作，TMD系統(tǒng)可通過域名類限流、cookie限流、黑名單以及一些安全策略等很好的實現(xiàn)了在接入層的限流措施。

TMD系統(tǒng)包含了淘寶技術(shù)團隊開發(fā)的開源模塊 nginx-http-sysguard，主要用于當(dāng)訪問負載和內(nèi)存達到一定的閾值時，會執(zhí)行相應(yīng)的動作，比如直接返回503、504或者其他url請求返回代碼，一直等到內(nèi)存或者負載回到閾值的范圍內(nèi)，站點才恢復(fù)可用。

在模塊 nginx-http-sysguard基礎(chǔ)上，淘寶TMD系統(tǒng)給用戶提供了可視化的配置管理界面，方便用戶針對不同的業(yè)務(wù)場景實現(xiàn)不同的限流規(guī)則。如果來自單臺機器持續(xù)訪問淘寶平臺上的一個URL頁面，可在TMD中設(shè)置規(guī)則：訪問頻率大雨180次/秒，則進行IP訪問頻率限速或cookie訪問頻率限速。正是有了TMD 這樣配置靈活、操作方便的規(guī)則配置界面，運維人員可以針對所發(fā)現(xiàn)的異常請求以及實時的處理狀態(tài)，設(shè)置出各種保護措施，保障平臺在面對大流量時具備一定的自我保護能力，在平臺接入層外部驚濤駭浪的訪問洪流下，平臺接入蹭內(nèi)部保持穩(wěn)定、健康的運行狀態(tài)。

在接入層實現(xiàn)了限流后，一定會有部分用戶的請求得不到系統(tǒng)正常的處理，所以平臺一般會給用戶返回限流頁面，在一定程度上減少用戶因為請求沒有成功處理的失落體驗，限流頁面的風(fēng)格會與網(wǎng)站、app的設(shè)計風(fēng)格統(tǒng)一，頁面也會包含跳轉(zhuǎn)引導(dǎo)界面，以形成用戶體驗和業(yè)務(wù)處理流程的閉環(huán)。

四、TMD平臺在服務(wù)層面臨的挑戰(zhàn)

TMD平臺能很好的實現(xiàn)在平臺接入層的限流功能，但對于服務(wù)層就無能為力了。對于實現(xiàn)服務(wù)的限流控制，傳統(tǒng)的實現(xiàn)方式通常用spring的aop機制，對需要限流的接口定義一個advice攔截器，示例代碼如下：

????
????????com.taobao.item.service.SpuService.*
????
????
????
????????
????
????class="com.taobao.trade.buy.web.buy.util.monitor.advice.SpuServiceApiAdvice"?/>

其中的 SuperServiceApiAdvice 類實現(xiàn)MethodBeforeAdvice接口，重寫before方法，那么在調(diào)用指定的接口或者方法前會計算當(dāng)前thread count或qps，如果當(dāng)前的線程數(shù)大于所設(shè)置的最大線程數(shù)閾值，則返回訪問限流的異常信息。示例代碼如下：

@Overrideprotected?void?invokeBeforeMethodForFlowControl(MonitorStore?monitorStore)?throws?FlowControlException{long?newThreadCnt?=?monitorStore
.getStoreDataInfo(getMonitorNmae(),getKey()).getThreadCnt()
.get();if(newThreadCnt?>?MonitorParam.MAX_THREAD_COUT_FIVE){???throw?new?FlowControlException(???"SpuServiceApiAdvice?access?control,?threadcnt="
???????????+?newThreadCnt);
????}
}

這套流控技術(shù)方案是可行的，實現(xiàn)起來也非常簡單，但在實際應(yīng)用場景中還是會發(fā)現(xiàn)不少問題，比如：

• 如果一個應(yīng)用需要對100個接口進行限流，那么對應(yīng)地也就需要配置100個advice和編寫100個攔截器，如果是成百上千的應(yīng)用呢？

• 限流閥值是硬編碼形式，無法動態(tài)調(diào)整，當(dāng)然你也可以動態(tài)調(diào)整（比如定義成一個靜態(tài)變量，然后通過curl去調(diào)整），但當(dāng)限流開關(guān)達到一定量級后你會發(fā)現(xiàn)這是一件非常痛苦的事，很難維護管理；

• 限流手段太過單一，無法對特殊場景實現(xiàn)多樣化的限流；

• 沒有一個統(tǒng)一的監(jiān)控平臺，無法監(jiān)控當(dāng)前的限流情況；

• 限流算法簡單，當(dāng)在雙十一這種特殊場景，會看到毛刺現(xiàn)象，需要一種更平滑的限流算法；

那么我們是如何解決以上的問題？解決的過程中有哪些新的思考？阿里巴巴是否有將這類解決方案開源貢獻給社區(qū)？我們將在下一篇“如何打造平臺穩(wěn)定性能力”系列文章中為大家解讀。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。