Extension for intercepting the invocation for both service provider and consumer, furthermore, most of
functions in dubbo are implemented base on the same mechanism. Since every time when remote method is
invoked, the filter extensions will be executed too, the corresponding penalty should be considered before
more filters are added.
They way filter work from sequence point of view is
...code before filter ...
invoker.invoke(invocation) //filter work in a filter implementation class
...code after filter ...
Caching is implemented in dubbo using filter approach. If cache is configured for invocation then before
remote call configured caching type's (e.g. Thread Local, JCache etc) implementation invoke method gets called.
Start from 3.0, the semantics of the Filter component at the consumer side has changed.
Instead of intercepting a specific instance of invoker, Filter in 3.0 now intercepts ClusterInvoker. A new SPI named
InstanceFilter is introduced to work as the same semantic as Filter in 2.x.
The difference of Filter is as follows:
3.x Filter
-> InstanceFilter -> Invoker
Proxy -> Filter -> Filter -> ClusterInvoker -> InstanceFilter -> Invoker
-> InstanceFilter -> Invoker
2.x Filter
Filter -> Filter -> Invoker
Proxy -> ClusterInvoker -> Filter -> Filter -> Invoker
Filter -> Filter -> Invoker
If you want to a Filter
Filter. (SPI, Singleton, ThreadSafe)