過濾器

字面義上理解的過濾器類似下圖，從一堆物品中篩選出符合條件的留下，不符合的丟棄。

GOF 職責鏈

GOF中有一種設計模式叫職責鏈，或者叫責任鏈，常規(guī)的UML圖如下：

正統(tǒng)的職責鏈是將一個請求發(fā)給第一個接收者，接收者判斷是否屬于自己能處理的，如果能處理則執(zhí)行操作并中止請求下發(fā)，流程到此為止。如果不能處理則將請求下發(fā)給下一個接收者一直到最后一個接收者。

變體職責鏈

上面提到正統(tǒng)的職責鏈有一個特點：當找到符合條件的執(zhí)行者后流程中止并不會將請求繼續(xù)下發(fā)給后續(xù)的執(zhí)行者。這類場景比較適合比如審核操作，一個報銷單由主管，經(jīng)理，CTO一級一級的審批不能越權。

解耦合/細分

在實際項目中，往往會遇到非常復雜的業(yè)務場景，有可能是需要執(zhí)行的方法特別多，也有可能是因為需要執(zhí)行的方法有可能事先不知道，需要在運行時才能判斷。如果將這些邏輯全部寫在一個類或者一個方法中就會出現(xiàn)這樣的問題：

耦合度高，一個方法或者一個類需要關聯(lián)所有業(yè)務方法以及相關類不易擴展，需要執(zhí)行的業(yè)務經(jīng)常發(fā)生變化，如果每次變化都去修改統(tǒng)一的方法或者類，不符合開閉原則，維護成本非常高

所以就有了下圖，一堆需要執(zhí)行的方法發(fā)給第一個接收者，接收者判斷哪些方法是自己可以執(zhí)行的，有執(zhí)行的就執(zhí)行，然后無論是否有可執(zhí)行的方法在處理完成后都將請求繼續(xù)下發(fā)給后面的接收者。每個接收者完成自己負責的內(nèi)容，多個接收者完成了復雜任務的分解。

RPC 過濾器

RPC過濾器與Spring MVC中的Filter作用基本相同，其中很大一個作用就是動態(tài)的給客戶端或者是服務端增加切面功能，比如：

權限控制加密解密訪問日志限流控制并發(fā)控制......

下圖是我在RPC項目中實現(xiàn)過濾器機制的UML示意圖

RpcFilter

定義一個過濾器接口，只包含一個invoke方法。

public interface RpcFilter<T> { <T> T invoke(RpcInvoker invoker, RpcInvocation invocation);}

RpcInvoker

這是RPC客戶端以及服務端執(zhí)行服務端方法或者是將客戶端請求發(fā)送給服務端時需要調(diào)用的方法接口。

這個角色在Netty中也可以叫Handle，這個接口與上面的RpcFilter有點類似，只是在RPC框架中體現(xiàn)的角色不同而已，具體看UML圖可知道兩者關系。

public interface RpcInvoker { Object invoke(RpcInvocation invocation);}

RpcServerInvoker

服務端的一個執(zhí)行者實現(xiàn)，包含兩個核心功能：

構建職責鏈this.filterMap，是通過注解獲取到的一組過濾器，此處不詳細講因為與本文關系不大RpcInvoker的invoker方法實際調(diào)用的是RpcFilter的方法，并將自身實例傳遞給RpcFilter，目的是構建職責鏈的關聯(lián)關系

public RpcInvoker buildInvokerChain(final RpcInvoker invoker) { RpcInvoker last = invoker; List<RpcFilter> filters = Lists.newArrayList(this.filterMap.values()); if (filters.size() > 0) { for (int i = filters.size() - 1; i >= 0; i --) { final RpcFilter filter = filters.get(i); final RpcInvoker next = last; last = new RpcInvoker() {@Overridepublic Object invoke(RpcInvocation invocation) { return filter.invoke(next, invocation);} }; } } return last;}

此處并沒有考慮職責鏈的排序，可以通過過濾器的注解上增加排序數(shù)字來解決。目前我寫的過濾器注解中并沒有實現(xiàn)排序功能，可以增加一個order的屬性，然后在需要指定順序的過濾器上增加對應屬性值來支持。

@Target({ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Componentpublic @interface ActiveFilter { String[] group() default {}; String[] value() default {};}

發(fā)請求給職責鏈

服務端在讀取到客戶端的請求后，首先通過構建職責鏈得到RpcInvoker，然后調(diào)用RpcInvoker的invoke方法將請求下發(fā)。

@Override protected void channelRead0(ChannelHandlerContext channelHandlerContext, RpcMessage message) { this.executor.execute(new Runnable() { @Override public void run() {RpcInvoker rpcInvoker=....RpcResponse response=(RpcResponse) rpcInvoker.invoke...... }

過濾器案例

一般HTTP請求在不同網(wǎng)絡角色中處理請求的能力會呈現(xiàn)為一個漏斗型，越上層職責越輕，越往下層職責越重，所對應的就是越上層處理請求量越大，越下層處理請求量越小。比如負載均衡器只負責請求轉發(fā)而不負責具體的任務執(zhí)行，而后端的Service服務器會執(zhí)行大量的IO操作或者是消耗cpu的計算任務等，所以這兩者在處理請求的量上往往是數(shù)量級的。

當出現(xiàn)大量請求時，為了有效的保護后端服務的穩(wěn)定性（盡量不出現(xiàn)宕機），除了橫向擴展服務器外還可以通過一些軟件手段緩解后端服務的壓力，這就是通常說的限流，本文因為需要簡單實現(xiàn)一個限制的過濾器，所以直接引用現(xiàn)成的限流算法：令牌桶。

下面是客戶端請求限流的一個簡單實現(xiàn)，客戶端在給服務端發(fā)起請求之前需要獲取令牌，如果獲取到則發(fā)送請求，如果獲取不到一直等待。當然為了防止死鎖，可以調(diào)用帶超時時間的獲取令牌方法。

@ActiveFilter(group = {ConstantConfig.CONSUMER})public class AccessLimitFilter implements RpcFilter { private final static Logger logger = LoggerFactory.getLogger(AccessLimitFilter.class); @Override public Object invoke(RpcInvoker invoker, RpcInvocation invocation) { logger.info('before acquire'); AccessLimitManager.acquire(); Object rpcResponse=invoker.invoke(invocation); logger.info('after acquire'); return rpcResponse; } static class AccessLimitManager{ private final static RateLimiter rateLimiter=RateLimiter.create(2); public static void acquire(){ rateLimiter.acquire(); } }}

實現(xiàn)的比較粗糙，桶的大小是寫死的，應該實現(xiàn)為可配置型，后續(xù)抽空完善下。

本文源碼

https://github.com/jiangmin168168/jim-framework

文中代碼是依賴上述項目的，如果有不明白的可下載源碼

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持好吧啦網(wǎng)。