摘要：?在整個穩定性體系中，所包含的范圍非常廣泛，從機房的布線、網絡通信、硬件部署、應用架構、數據容災等方面都與之相關。從共享服務中臺的角度看，則更多的是從應用架構設計和中間件平臺的維度對平臺的穩定性實現更精確化的管理和保障。

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

第一期：限流和降級

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

一、限流和降級的產生背景

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

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

二、限流的作用和前期準備

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

平臺要具備限流能力，需要配備好壓測和監控能力。

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

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

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

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

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

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

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

在接入層實現了限流后，一定會有部分用戶的請求得不到系統正常的處理，所以平臺一般會給用戶返回限流頁面，在一定程度上減少用戶因為請求沒有成功處理的失落體驗，限流頁面的風格會與網站、app的設計風格統一，頁面也會包含跳轉引導界面，以形成用戶體驗和業務處理流程的閉環。

四、TMD平臺在服務層面臨的挑戰

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

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

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

@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);
????}
}

這套流控技術方案是可行的，實現起來也非常簡單，但在實際應用場景中還是會發現不少問題，比如：

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

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

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

• 沒有一個統一的監控平臺，無法監控當前的限流情況；

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

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

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。