【功能上新】UAVStack服務治理之流量控制

背景

應用微服務化場景下，隨着服務個數的增長，服務之間的相互調用變得更加複雜，服務治理需求越發突出，其中服務流量控制是服務治理中的重要一環。

當前經常使用的流量控制方案主要有基於Spring Cloud的Hystrix和阿里開源的Sentinel應用流量控制降級方案。客觀而言，兩個方案都是侵入式的，要求用戶在應用中引入相關包，編寫相關邏輯。

UAVStack做爲一套智能化服務技術棧，其服務治理（UAV.ServiceGovern）模塊提供了基於畫像的服務註冊與發現、服務訪問受權及服務流量控制能力。 本文主要介紹UAVStack的無侵入式服務流量限制及降級方案。安裝UAV後，經過頁面配置便可用實現經常使用的QPS限流等。

1、限流模型

圖1限流模型

UAV服務治理流量控制採用上圖所示的漏斗+能力池限流模型。將應用根據UAV畫像抽象出三層，分別是應用層（應用實例層）、服務組件層和URL層。每一層都可以添加多個限流策略，多個限流策略以「且」的關係存在。請求呈漏斗狀依次進入URL層限流、服務組件層限流、應用層限流，只有經過三層限流後才能進入應用。

• 應用層（應用實例層）：應用層表明當前應用實例總體，應用層限流即限制進入當前應用的總流量。應用層限流流量爲服務組件層和URL層流量上限；
• 服務組件層：服務組件層是應用下全部服務組件的集合，包含一個或多個服務組件。能夠針對每一個服務組件配置不一樣的限流和降級策略，每一個服務組件包含0個或多個URL；
• URL層：URL層包含全部服務URL。URL層限流即限制進入具體URL的流量。

流量控制的目標不是僅僅限制QPS，還要限制對系統資源的使用。服務能力池描述當前應用或組件對外提供的服務能力的上限，該上限爲池的最大容量；因爲不一樣的請求消耗的系統資源不同，所以每種類型的請求將會被賦予不一樣的權重值。重的請求消耗更多系統資源，將被賦予更大的權重值，而輕的請求賦予較小的權重值。每一個請求都會根據權重值消耗服務能力池中的能力，重的請求比輕的請求消耗得服務能力多。沒法從服務能力池中獲取足夠的服務能力時，便會觸發降級策略。

2、關鍵技術

• MOF中間件劫持

MOF(MonitorFramework)中間件劫持爲UAV服務治理中流量控制提供基礎支撐。主要提供如下幾方面的支撐：

• 請求捕獲：捕獲全部進入應用容器的請求，並將請求轉入限流模型處理流程，實現流量控制和請求降級；

• 流量控制策略配置：基於MOF提供的基礎能力實現流量控制策略配置、當前限流狀態查詢/開啓/關閉等熱控制。

• 限流器和降級策略

UAV服務治理默認支持兩種限流器：時間段計數限流器和基於令牌桶算法的服務能力限流器。

時間段計數限流器經過原子量累計時間段內請求個數。當請求個數超過限制總數時，執行降級策略。默認的降級策略是終止請求處理流程，返回TOO_MANY_REQUEST。UAV服務治理支持開發和配置自定義的降級策略。

基於令牌桶算法的服務能力限流器會隨着時間變化按恆定時間間隔(1/QPS，若是QPS=100,則間隔是10ms)向服務能力池中裏補充，直至將能力池填滿。出現新請求時，會根據當前請求權重值N拿走N個Token；若是沒有足夠的Token可取，則會阻塞或拒絕請求，從而執行拒絕策略。基於令牌桶算法的服務能力限流器也支持開發和配置自定義的降級策略。

UAV服務治理不只支持自定義降級策略，也支持自定義限流器，知足不一樣用戶的不一樣需求。

3、功能展現

• 限流策略配置樹

頁面根據應用畫像以配置樹形將應用展現爲三層：應用實例層、服務組件層、URL組件層。如圖2所示，應用實例層節點表明當前應用實例（僅有一個）；服務組件節點表明當前應用下的某一具體服務組件，如RS服務組件，每一個服務組件下可能包含0個或多個URL節點；一個URL節點表明應用對外提供的服務的具體URL。

流量控制策略能夠配置在三層中的任意節點上。配置在應用實例層節點能夠限制進入整個應用的流量；配置在服務組件節點上能夠控制當前服務組件下全部URL的流量；配置在URL節點上能夠限制訪問當前URL的流量。

圖2 應用配置樹

• 策略配置及策略下發

策略配置中主要配置限流器、限流器參數、降級策略及降級策略參數。默認限流器是基於令牌桶算法的服務能力限流器，URL節點須要配置限流閾值和當前節點的請求權重值。請求超過閾值時，默認降級策略會返回TOO_MANY_REQUEST。

圖3 策略配置

配置策略完成，經過策略下發按鈕將策略下發至目標應用，同時展現當前實時限流狀態。

圖4 策略下發結果狀態展現

• 限流效果及性能展現

圖5爲極簡應用（接收到請求後直接返回）場景下的測試結果，包括在壓力不斷加強的狀況下應用原生吞吐量（紅線）、安裝UAV不啓用限流的吞吐量（黑線）、安裝UAV限流900QPS時應用接收到的請求量（限流900總體，藍線）、限流900QPS時正常處理的請求量（橙線，限流900正常請求）及限流900QPS時拒絕的請求量（綠線，限流900限流請求）。

圖5 應用吞吐量測試

從圖5中能夠看出，對比原生和安裝UAV無限流狀況，UAV限流對應用的吞吐量影響比較小，基本能夠忽略不計。隨着請求量的增長，進入應用的正常請求量（橙線）穩定在900左右，被限流的請求量隨着總體請求量增長而增長，且與未被限流的請求量之和爲總體請求量，代表UAV限流有效。另外一方面，隨着請求量的增長，在原生和無限流的狀況下，應用吞吐量在1500左右達到上限；但在限流900QPS的狀況下，應用請求量一直在增長，由於超出的請求被直接拒絕，沒有進入應用中，從側面體現了UAV限流對應用的保護能力。

圖6爲極簡應用場景的測試結果，爲應用在壓力不斷加強的狀況下的平均響應時間。在原生和無限流狀況下（紅線和黑線），應用的平均響應時間隨着壓力增大而增長，最終在1300左右時大幅增長，說明應用的服務能力已經接近極限；在UAV限流900QPS的狀況，正常請求（橙線）的平均響應時間即便超過1300達到2100時也基本保持穩定，被拒絕的請求的平均響應時間未見大幅變更，應用服務器的平均響應時間也基本保持穩定。UAV限流對應用實現了有效保護。

圖6 應用平均響應時間測試

總結

服務治理是微服務化場景下的一個重要問題。本文僅簡單介紹UAV服務治理中服務端限流部分原理和功能展現。因爲篇幅有限，暫不詳細展開介紹。你們有興趣能夠繼續關注UAVStack公衆號或申請加入官方微信羣，相信您必定會有所收穫。

官方網站

開源地址

UAVStack已在Github上開放源碼，並提供了安裝部署、架構說明和用戶指南等雙語文檔，歡迎訪問-給星-拉取~~~

掃一掃下方二維碼，關注一個不會讓你失望的公衆號