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中的順序。

經過查看EchoFilter的Activate屬性，能夠看到其order = -110000，而ClassLoaderFilter的order=-30000,所以能夠判定，order值越小，其越位於調用端的最頂層。那麼當order相同時（都沒有設置時），又是根據什麼排序的呢？

Collections.sort算法

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

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

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

一、monitor

二、trace

三、exception

四、timeout

排序後變成了

一、exception

二、timeout

三、monitor

四、trace