Filter Interceptor

Filter Interceptor

Filters dynamically intercept requests or responses to transform or utilize the information contained in the requests or responses. Filters do not typically create responses themselves but provide generic functions that can be “attached” to any RPC request. Dubbo Filters are pluggable, allowing us to insert any type and number of filters into a single RPC request.

The working principle of filters is illustrated in the diagram below:

Usage

1. Concept of Filter Interceptor

Filter is defined as follows:

// Filter interface defines the functions of a filter
// Extension - Filter
type Filter interface {
    // Invoke is the core function of a filter, it determines the process of the filter
    Invoke(context.Context, protocol.Invoker, protocol.Invocation) protocol.Result
    // OnResponse updates the results from Invoke and then returns the modified results.
    OnResponse(context.Context, protocol.Result, protocol.Invoker, protocol.Invocation) protocol.Result
}

Filters can be loaded on either the Consumer or Provider side. When loaded on the Consumer side, the downstream of its Invoke function call is the network layer, and OnResponse is called after getting the return result from the network layer when the request ends. When loaded on the Provider side, the downstream of its Invoke function call is user code, and OnResponse is called before passing down to the network layer after user code execution ends.

Filters adopt an aspect-oriented design approach, allowing for reasonable extensions to record logs, set data points, record service performance corresponding to the invoker, limit traffic, and more.

2. Predefined Filters by the Framework

A series of predefined filters are available in the framework for direct use in the configuration, with their code implementation located at filter.

accesslog
active
sign: AuthConsumerFilter
auth: AuthProviderFilter
echo
execute: ExecuteLimitFilter
generic: GenericFilter
generic_service: GenericServiceFilter
pshutdown: GracefulShutdownProviderFilter
cshutdown: GracefulShutdownConsumerFilter
hystrix_consumer: HystrixConsumerFilter
hystrix_provider: HystrixProviderFilter
metrics
seata
sentinel-provider
sentinel-consumer
token
tps
tracing

3. Default Loaded Filters

When users configure custom filter loading strategies in their configuration files, the framework will load both the user-configured filters and default filters together; otherwise, it will only load the default filters. The list of currently activated default filters is as follows:

Consumer: cshutdown
Provider: echo, metrics, token, accesslog, tps, generic_service, executivete, pshutdown

4. Custom Filters

Users can create custom filters in their code, register them with the framework, and select them for use in the configuration.

func init() {
    extension.SetFilter("myCustomFilter", NewMyClientFilter)
}
func NewMyClientFilter() filter.Filter {
    return &MyClientFilter{}
}
type MyClientFilter struct {
}
func (f *MyClientFilter) Invoke(ctx context.Context, invoker protocol.Invoker, invocation protocol.Invocation) protocol.Result {
    fmt.Println("MyClientFilter Invoke is called, method Name = ", invocation.MethodName())
    return invoker.Invoke(ctx, invocation)
}
func (f *MyClientFilter) OnResponse(ctx context.Context, result protocol.Result, invoker protocol.Invoker, protocol protocol.Invocation) protocol.Result {
    fmt.Println("MyClientFilter OnResponse is called")
    return result
}

Complete Example

You can learn how to use the API to configure and enable filters through the following link: Complete example source code address

Feedback

Was this page helpful?

Yes No

Last modified September 30, 2024: Update & Translate Overview Docs (#3040) (d37ebceaea7)