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

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

第一期：限流和降級(jí)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

其中的 SuperServiceApiAdvice 類實(shí)現(xiàn)MethodBeforeAdvice接口，重寫before方法，那么在調(diào)用指定的接口或者方法前會(huì)計(jì)算當(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ù)方案是可行的，實(shí)現(xiàn)起來也非常簡(jiǎn)單，但在實(shí)際應(yīng)用場(chǎng)景中還是會(huì)發(fā)現(xiàn)不少問題，比如：

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

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

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

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

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

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

原文鏈接

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