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

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

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類弄成了不同，導致排序有些變化。造成了最終上述順序。

所以導致原來配置文件中的位置為：

1、monitor

2、trace

3、exception

4、timeout

排序后變成了

1、exception

2、timeout

3、monitor

4、trace