做為一個資料上報系統,隨著接入量越來越大,由於 API 介面無法控制呼叫方的行為,因此當遇到瞬時請求量激增時,會導致介面占用過多伺服器資源,使得其他請求響應速度降低或是超時,更有甚者可能導致伺服器當機。
一、概念
限流(Ratelimiting)指對應用服務的請求進行限制,例如某一介面的請求限制為 100 個每秒,對超過限制的請求則進行快速失敗或丟棄。
1.1 使用場景
限流可以應對:
- 熱點業務帶來的突發請求;
- 呼叫方 bug 導致的突發請求;
- 惡意攻擊請求。
1.2 維度
對於限流場景,一般需要考慮兩個維度的資訊:
時間
限流基於某段時間範圍或者某個時間點,也就是我們常說的“時間視窗”,比如對每分鐘、每秒鐘的時間視窗做限定
資源
基於可用資源的限制,比如設定最大訪問次數,或最高可用連線數。
限流就是在某個時間視窗對資源訪問做限制,比如設定每秒最多100個訪問請求。
1.3 分散式限流
分散式限流相比於單機限流,只是把限流頻次分配到各個節點中,比如限制某個服務訪問100qps,如果有10個節點,那麼每個節點理論上能夠平均被訪問10次,如果超過了則進行頻率限制。
二、分散式限流常用方案
基於Guava的客戶端限流
Guava是一個客戶端元件,在其多執行緒模組下提供了以RateLimiter為首的幾個限流支援類。它只能對“當前”服務進行限流,即它不屬於分散式限流的解決方案。
閘道器層限流
服務閘道器,作為整個分散式鏈路中的第一道關卡,承接了所有使用者來訪請求。我們在閘道器層進行限流,就可以達到了整體限流的目的了。目前,主流的閘道器層有以軟體為代表的Nginx,還有Spring Cloud中的Gateway和Zuul這類閘道器層元件,也有以硬體為代表的F5。
中介軟體限流
將限流資訊儲存在分散式環境中某個中介軟體裡(比如Redis快取),每個元件都可以從這裡獲取到當前時刻的流量統計,從而決定是拒絕服務還是放行流量。
限流元件
目前也有一些開源元件提供了限流的功能,比如Sentinel就是一個不錯的選擇。Sentinel是阿里出品的開源元件,並且包含在了Spring Cloud Alibaba元件庫中。Hystrix也具有限流的功能。
Guava的Ratelimiter設計實現相當不錯,可惜只能支援單機,閘道器層限流如果是單機則不太滿足高可用,並且分散式閘道器的話還是需要依賴中介軟體限流,而redis之類的網路通訊需要佔用一小部分的網路消耗。阿里的Sentinel也是同理,底層使用的是redis或者zookeeper,每次訪問都需要呼叫一次redis或者zk的介面。那麼在雲原生場景下,我們有沒有什麼更好的辦法呢?
對於極致追求高效能的服務不需要考慮熔斷、降級來說,是需要儘量減少網路之間的IO,那麼是否可以通過一個總限頻然後分配到具體的單機裡面去,在單機中實現平均的限流,比如限制某個ip的qps為100,服務總共有10個節點,那麼平均到每個服務裡就是10qps,此時就可以通過guava的ratelimiter來實現了,甚至說如果服務的節點動態調整,單個服務的qps也能動態調整。
三、基於kubernetes的分散式限流
在Spring Boot應用中,定義一個filter,獲取請求引數裡的key(ip、userId等),然後根據key來獲取rateLimiter,其中,rateLimiter的建立由資料庫定義的限頻數和副本數來判斷,最後,再通過rateLimiter.tryAcquire來判斷是否可以通過。
3.1 kubernetes中的副本數
在實際的服務中,資料上報服務一般無法確定客戶端的上報時間、上報量,特別是對於這種要求高效能,服務一般都會用到HPA來實現動態擴縮容,所以,需要去間隔一段時間去獲取服務的副本數。
func CountDeploymentSize(namespace string, deploymentName string) *int32 {
deployment, err := client.AppsV1().Deployments(namespace).Get(context.TODO(), deploymentName, metav1.GetOptions{})
if err != nil {
return nil
}
return deployment.Spec.Replicas
}
用法:GET host/namespaces/test/deployments/k8s-rest-api直接即可。
3.2 rateLimiter的建立
在RateLimiterService中定義一個LoadingCache<String, RateLimiter>,其中,key可以為ip、userId等,並且,在多執行緒的情況下,使用refreshAfterWrite只阻塞載入資料的執行緒,其他執行緒則返回舊資料,極致發揮快取的作用。
private final LoadingCache<String, RateLimiter> loadingCache = Caffeine.newBuilder()
.maximumSize(10_000)
.refreshAfterWrite(20, TimeUnit.MINUTES)
.build(this::createRateLimit);
//定義一個預設最小的QPS
private static final Integer minQpsLimit = 3000;
之後是建立rateLimiter,獲取總限頻數totalLimit和副本數replicas,之後是自己所需的邏輯判斷,可以根據totalLimit和replicas的情況來進行qps的限定。
public RateLimiter createRateLimit(String key) {
log.info("createRateLimit,key:{}", key);
int totalLimit = 獲取總限頻數,可以在資料庫中定義
Integer replicas = kubernetesService.getDeploymentReplicas();
RateLimiter rateLimiter;
if (totalLimit > 0 && replicas == null) {
rateLimiter = RateLimiter.create(totalLimit);
} else if (totalLimit > 0) {
int nodeQpsLimit = totalLimit / replicas;
rateLimiter = RateLimiter.create(nodeQpsLimit > minQpsLimit ? nodeQpsLimit : minQpsLimit);
} else {
rateLimiter = RateLimiter.create(minQpsLimit);
}
log.info("create rateLimiter success,key:{},rateLimiter:{}", key, rateLimiter);
return rateLimiter;
}
3.3 rateLimiter的獲取
根據key獲取RateLimiter,如果有特殊需求的話,需要判斷key不存在的嚐盡
public RateLimiter getRateLimiter(String key) {
return loadingCache.get(key);
}
3.4 filter裡的判斷
最後一步,就是使用rateLimiter來進行限流,如果rateLimiter.tryAcquire()為true,則進行filterChain.doFilter(request, response),如果為false,則返回HttpStatus.TOO_MANY_REQUESTS
public class RateLimiterFilter implements Filter {
@Resource
private RateLimiterService rateLimiterService;
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException {
HttpServletRequest httpServletRequest = (HttpServletRequest) request;
HttpServletResponse httpServletResponse = (HttpServletResponse) response;
String key = httpServletRequest.getHeader("key");
RateLimiter rateLimiter = rateLimiterService.getRateLimiter(key);
if (rateLimiter != null) {
if (rateLimiter.tryAcquire()) {
filterChain.doFilter(request, response);
} else {
httpServletResponse.setStatus(HttpStatus.TOO_MANY_REQUESTS.value());
}
} else {
filterChain.doFilter(request, response);
}
}
}
四、效能壓測
為了方便對比效能之間的差距,我們在本地單機做了下列測試,其中,總限頻都設定為3萬。
無限流
使用redis限流
其中,ping redis大概6-7ms左右,對應的,每次請求需要訪問redis,時延都有大概6-7ms,效能下降明顯
自研限流
效能幾乎追平無限流的場景,guava的rateLimiter確實表現卓越
五、其他問題
5.1 對於保證qps限頻準確的時候,應該怎麼解決呢?
在k8s中,服務是動態擴縮容的,相應的,每個節點應該都要有所變化,如果對外宣稱限頻100qps,而且後續業務方真的要求百分百準確,只能把LoadingCache<String, RateLimiter>的過期時間調小一點,讓它能夠近實時的更新單節點的qps。這裡還需要考慮一下k8s的壓力,因為每次都要獲取副本數,這裡也是需要做快取的
5.2 服務從1個節點動態擴為4個節點,這個時候新節點識別為4,但其實有些並沒有啟動完,會不會造成某個節點承受了太大的壓力
理論上是存在這個可能的,這個時候需要考慮一下初始的副本數的,擴縮容不能一蹴而就,一下子從1變為4變為幾十個這種。一般的話,生產環境肯定是不能只有一個節點,並且要考慮擴縮容的話,至於要有多個副本預備的
5.3 如果有多個副本,怎麼保證請求是均勻的
這個是依賴於k8s的service負載均衡策略的,這個我們之前做過實驗,流量確實是能夠均勻的落到節點上的。還有就是,我們整個限流都是基於k8s的,如果k8s出現問題,那就是整個叢集所有服務都有可能出現問題了。
參考
1.常見的分散式限流解決方案
2.分散式服務限流實戰
3.高效能