Java RPC框架如何實(shí)現(xiàn)客戶端限流配置
關(guān)鍵資源
關(guān)鍵資源總是有限的,也就意味著處理能力也有限,所以當(dāng)面對大量業(yè)務(wù)時,為了保障自己能夠有序的提供服務(wù)最經(jīng)濟(jì)的做法就是限制同一時間處理的事務(wù)數(shù)。比如銀行的工作人員,一個工作人員同時只能為一個客戶服務(wù),來多了根本處理不了,不光是一種浪費(fèi)而且有可以造成混亂的局面導(dǎo)致工作人員無法工作。
網(wǎng)絡(luò)請求漏斗
越上層的服務(wù)器處理的事務(wù)越輕,應(yīng)付請求的能力也越強(qiáng),也就意味著同一請求越上層處理時間越短。為了有效的保護(hù)下層服務(wù)器,就需要對發(fā)送給下層的請求量做限流,在下層服務(wù)器可接受的范圍內(nèi)。否則就可能會出現(xiàn)下層服務(wù)器資源耗盡而無法正常提供服務(wù)的情況。
限流場景服務(wù)端限流
如果在服務(wù)端做限流,無論有多少個客戶端,總的提供能力是固定的(感謝@ xuanbg提出的評論,指出服務(wù)端也可以對客戶端做精準(zhǔn)的判斷,后續(xù)我再想想實(shí)現(xiàn)方案),所以不會因?yàn)榭蛻舳藬?shù)量過多而導(dǎo)致資源不足,因?yàn)樘幚聿贿^來的請求會被阻塞等待獲取資源。
缺點(diǎn)
缺點(diǎn)也比較明顯,由于服務(wù)提供者整體設(shè)置了最大限流數(shù),此時所有的客戶端共享同一份限流數(shù)據(jù),那么有可能導(dǎo)致有的服務(wù)能分配到資源有些服務(wù)請求分配不到資源導(dǎo)致無法請求的情況。
客戶端限流
客戶端限流解決上服務(wù)端限流提到的問題,它能保證每個客戶端都能得到響應(yīng)。但是從其它方面考慮,必須針對不同的客戶端做不同的限流策略:
請求量大,但時效性不高,此時將限流數(shù)控制小一些會比較合適請求量大,但時效性高,此時將限流數(shù)適當(dāng)調(diào)高響應(yīng)時間長,即慢接口,適當(dāng)降低主流業(yè)務(wù),核心業(yè)務(wù),適當(dāng)調(diào)高非主流業(yè)務(wù),適當(dāng)降低......
缺點(diǎn)
如果客戶端的數(shù)量不固定,那么有可能導(dǎo)致客戶端數(shù)量過多造成大量請求打到服務(wù)端導(dǎo)致處理不了的結(jié)果,所以需要嚴(yán)格監(jiān)控客戶端的調(diào)用情況。
配置復(fù)雜,需要針對每個客戶端做相對精準(zhǔn)的判斷
RPC實(shí)現(xiàn)
限流
這里指的限流是指每秒從客戶端提交到服務(wù)端的請求數(shù)量。
服務(wù)引用注解上增加限流
public @interface RpcReference { boolean isSync() default true; /** * 客戶端最大并發(fā)數(shù) * @return */ int maxExecutesCount() default 10; }
創(chuàng)建動態(tài)代理時將限流參數(shù)傳遞到服務(wù)端
需要修改RpcProxy類,構(gòu)造函數(shù)中增加服務(wù)引用注解參數(shù),然后在invoke方法中從服務(wù)引用注解中獲取限流參數(shù)傳遞給request對象。
public RpcProxy(Class<T> clazz,ReferenceConfig referenceConfig,RpcReference reference) { this.clazz = clazz; this.referenceConfig=referenceConfig; this.reference=reference; this.isSync=reference.isSync(); } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { ... if (this.reference != null) { request.setMaxExecutesCount(this.reference.maxExecutesCount()); } ... }
AbstractInvoker修改buildRpcInvocation方法
從request對象中獲取限流參數(shù),傳遞給RpcInvocation對象。
public interface RpcInvocation { ... int getMaxExecutesCount(); }
AccessLimitFilter修改令牌管理器
按接口分配令牌管理器,令牌管理器存儲在map中共享。如果未初始化則進(jìn)行令牌管理器的初始化,如果已經(jīng)初始化則直接申請令牌。
public RpcInvocation buildRpcInvocation(RpcRequest request){ RpcInvocation rpcInvocation=new RpcInvocation() { ... @Override public int getMaxExecutesCount() { return request.getMaxExecutesCount(); } }; return rpcInvocation; }
修改invoke方法
將invocation參數(shù)傳遞給acquire方法。
public Object invoke(RpcInvoker invoker, RpcInvocation invocation) { logger.info("before acquire,"+new Date()); AccessLimitManager.acquire(invocation); Object rpcResponse=invoker.invoke(invocation); logger.info("after acquire,"+new Date()); return rpcResponse; }
客戶端服務(wù)引用配置限流
這里配置每秒一個請求
@RpcReference(maxExecutesCount = 1) private ProductService productService;
執(zhí)行結(jié)果
如下圖所示,每次請求相隔了一秒,達(dá)到了限流請求的目的。
支持方法級限流
以上只支持客戶端接口級別的限流配置,可以再單獨(dú)創(chuàng)建一個方法級的注解來配置相關(guān)參數(shù)。
支持服務(wù)端限流
服務(wù)端限流盡管有它的缺點(diǎn),但為了更好的保護(hù)服務(wù)提供者,需要結(jié)合多種業(yè)務(wù)場景來配合客戶端限流一起完善,取長補(bǔ)短共同發(fā)揮作用。
本文源碼
https://github.com/jiangmin168168/jim-framework
文中代碼是依賴上述項(xiàng)目的,如果有不明白的可下載源碼
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
SpringBoot2.7.14整合redis7的詳細(xì)過程
這篇文章主要介紹了SpringBoot2.7.14整合redis7的詳細(xì)過程,本文通過實(shí)例代碼給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友參考下吧2023-10-10spring cloud feign實(shí)現(xiàn)遠(yuǎn)程調(diào)用服務(wù)傳輸文件的方法
這篇文章主要介紹了spring cloud feign實(shí)現(xiàn)遠(yuǎn)程調(diào)用服務(wù)傳輸文件的方法,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2018-09-09string類和LocalDateTime的相互轉(zhuǎn)換方式
這篇文章主要介紹了string類和LocalDateTime的相互轉(zhuǎn)換方式,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-02-02實(shí)體類使用@Builder,導(dǎo)致@ConfigurationProperties注入屬性失敗問題
這篇文章主要介紹了實(shí)體類使用@Builder,導(dǎo)致@ConfigurationProperties注入屬性失敗問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-12-12