Dubbo的Filter執行順序分析

最近用到了Dubbo的Filter來作一些監控的東西，順便整理了一下dubbo中的Filter調用順序及如何肯定的。

服務提供方的過濾器被調用順序：

EchoFilter->ClassLoaderFilter->GenericFilter->ContextFilter->(這4個是在代碼中指定的)

ExceptionFilter->  TimeoutFilter ->MonitorFilter-> TraceFilter

服務消費方的過濾器順序：

ConsumerContextFilter->FutureFilter->MonitorFilter

負責加載過濾器的類

ProtocolFilterWrapper

 

這個順序和SPI配置文件的順序並不一致。那麼是什麼決定了Filter的順序呢？

經過查看源代碼能夠看到，在初始化Filter時，有一個對全部的過濾器排序的過程，其使用的比較類是ActivateComparator。在這個類中，能夠看到，是使用Filter中的Activate類進行排序的。而Activate註解中，有一個order的屬性，這個屬性指定了Filter在chain中的順序。代碼以下：

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface Activate {
    String[] group() default {};

    String[] value() default {};

    String[] before() default {};

    String[] after() default {};

    int order() default 0;
}

經過查看EchoFilter的Activate屬性，能夠看到其order = -110000，而ClassLoaderFilter的order=-30000,所以能夠判定，order值越小，其越位於調用端的最頂層。

以下：

@Activate(
    group = {"provider"},
    order = -110000
)
public class EchoFilter implements Filter {
    public EchoFilter() {
    }

    public Result invoke(Invoker<?> invoker, Invocation inv) throws RpcException {
        return (Result)(inv.getMethodName().equals("$echo") && inv.getArguments() != null && inv.getArguments().length == 1 ? new RpcResult(inv.getArguments()[0]) : invoker.invoke(inv));
    }
}

@Activate(
    group = {"provider"},
    order = -30000
)
public class ClassLoaderFilter implements Filter {
    public ClassLoaderFilter() {
    }

    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        ClassLoader ocl = Thread.currentThread().getContextClassLoader();
        Thread.currentThread().setContextClassLoader(invoker.getInterface().getClassLoader());

        Result var4;
        try {
            var4 = invoker.invoke(invocation);
        } finally {
            Thread.currentThread().setContextClassLoader(ocl);
        }

        return var4;
    }
}

從上面能夠看出，若是須要規定自定義的Filter的執行順序，能夠經過設置自定義的Filter的@Active註解中order屬性值，越小越先執行。

 

那麼當order相同時（都沒有設置時），又是根據什麼排序的呢？

Collections.sort算法

從其說明文檔能夠看出，這個算法是一個穩定的排序算法，若是兩個值相同，不會改變其先後順序。而且從其文檔能夠看出，其所使用的是一個修改過的歸併排序算法。

可是Activate的compare方法故意將兩個相同的order類弄成了不一樣，致使排序有些變化。形成了最終上述順序。

因此致使原來配置文件中的位置爲：

一、monitor 

二、trace

三、exception

四、timeout

排序後變成了

一、exception

二、timeout

三、monitor

四、trace

參考文獻：http://blog.csdn.net/skiof007/article/details/51953497