dubbo中的Filter链原理及应用

filter在dubbo中的应用非常广泛，它可以对服务端、消费端的调用过程进行拦截，从而对dubbo进行功能上的扩展，我们所熟知的RpcContext就用到了filter。本文主要尝试从以下3个方面来简单介绍一下dubbo中的filter：
1.filter链原理
2.自定义filter
3.使用filter透传traceId

1.filter链原理

dubbo中filter链的入口在ProtocolFilterWrapper中，这是Protocol的一个包装类，在其服务暴露和服务引用时都进行了构建filter链的工作。

// 构建filter链
private static  Invoker buildInvokerChain(final Invoker invoker, String key, String group) {
    Invoker last = invoker;

    // 获取可用的filter列表
    List filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group);
    if (!filters.isEmpty()) {
        for (int i = filters.size() - 1; i >= 0; i--) {
            final Filter filter = filters.get(i);
            final Invoker next = last;

            // 典型的装饰器模式，将invoker用filter逐层进行包装
            last = new Invoker() {

                public Class getInterface() {
                    return invoker.getInterface();
                }

                public URL getUrl() {
                    return invoker.getUrl();
                }

                public boolean isAvailable() {
                    return invoker.isAvailable();
                }

                // 重点，每个filter在执行invoke方法时，会触发其下级节点的invoke方法，最后一级节点即为最原始的服务
                public Result invoke(Invocation invocation) throws RpcException {
                    return filter.invoke(next, invocation);
                }

                public void destroy() {
                    invoker.destroy();
                }

                @Override
                public String toString() {
                    return invoker.toString();
                }
            };
        }
    }
    return last;
}

// 服务端暴露服务
public  Exporter export(Invoker invoker) throws RpcException {
    if (Constants.REGISTRY_PROTOCOL.equals(invoker.getUrl().getProtocol())) {
        return protocol.export(invoker);
    }
    return protocol.export(buildInvokerChain(invoker, Constants.SERVICE_FILTER_KEY, Constants.PROVIDER));
}

// 客户端引用服务
public  Invoker refer(Class type, URL url) throws RpcException {
    if (Constants.REGISTRY_PROTOCOL.equals(url.getProtocol())) {
        return protocol.refer(type, url);
    }
    return buildInvokerChain(protocol.refer(type, url), Constants.REFERENCE_FILTER_KEY, Constants.CONSUMER);
}

可以看到，每一个filter节点都为原始的invoker服务增加了功能，是典型的装饰器模式。构建filter链的核心在于filter列表的获取，也就是这一行代码：

List filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group);

通过Filter的ExtendLoader实例获取其激活的filter列表，getActivateExtension逻辑分为两部分：
1.加载标注了Activate注解的filter列表
2.加载用户在spring配置文件中手动注入的filter列表

public List getActivateExtension(URL url, String key, String group) {
    // 根据key来获取服务方/消费方自定义的filter列表
    String value = url.getParameter(key);
    return getActivateExtension(url, value == null || value.length() == 0 ? null : Constants.COMMA_SPLIT_PATTERN.split(value), group);
}

public List getActivateExtension(URL url, String[] values, String group) {
    List exts = new ArrayList();
    List names = values == null ? new ArrayList(0) : Arrays.asList(values);

    // 如果用户配置的filter列表名称中不包含-default，则加载标注了Activate注解的filter列表
    if (!names.contains(Constants.REMOVE_VALUE_PREFIX + Constants.DEFAULT_KEY)) {

        // 加载配置文件，获取所有标注有Activate注解的类，存入cachedActivates中
        getExtensionClasses();
        for (Map.Entry entry : cachedActivates.entrySet()) {
            String name = entry.getKey();
            Activate activate = entry.getValue();

            // Activate注解可以指定group，这里是看注解指定的group与我们要求的group是否匹配
            if (isMatchGroup(group, activate.group())) {
                T ext = getExtension(name);

                // 对于每一个dubbo中原生的filter，需要满足以下3个条件才会被加载：
                // 1.用户配置的filter列表中不包含该名称的filter
                // 2.用户配置的filter列表中不包含该名称前加了"-"的filter
                // 3.该Activate注解被激活，具体激活条件随后详解
                if (!names.contains(name)
                        && !names.contains(Constants.REMOVE_VALUE_PREFIX + name)
                        && isActive(activate, url)) {
                    exts.add(ext);
                }
            }
        }

        // 对加载的dubbo原生的filter列表进行排序，ActivateComparator排序器会根据Activate注解的before、after、order属性对filter列表排序
        Collections.sort(exts, ActivateComparator.COMPARATOR);
    }

    // 加载用户在spring配置文件中配置的filter列表
    List usrs = new ArrayList();
    for (int i = 0; i < names.size(); i++) {
        String name = names.get(i);

        // 针对用户配置的每一个filter，需要满足以下两个条件才会被加载：
        // 1.名称不是以"-"开头
        // 2.用户配置的所有filter列表中不包含-name的filter
        if (!name.startsWith(Constants.REMOVE_VALUE_PREFIX)
                && !names.contains(Constants.REMOVE_VALUE_PREFIX + name)) {

            // 用户自己配置filter列表时，可以使用default的key来代表dubbo原生的filter列表，这样一来就可以控制dubbo原生filter列表和用户自定义filter列表之间的相对顺序
            if (Constants.DEFAULT_KEY.equals(name)) {
                if (!usrs.isEmpty()) {
                    exts.addAll(0, usrs);
                    usrs.clear();
                }
            } else {
                T ext = getExtension(name);
                usrs.add(ext);
            }
        }
    }
    if (!usrs.isEmpty()) {
        exts.addAll(usrs);
    }
    return exts;
}

判断Activate注解是否被激活的逻辑是这样的：

private boolean isActive(Activate activate, URL url) {
    // 如果注解没有配置value属性，则一定是激活的
    String[] keys = activate.value();
    if (keys == null || keys.length == 0) {
        return true;
    }

    // 对配置了value属性的注解，如果服务的url属性中存在与value属性值相匹配的属性且改属性值不为空，则该注解也是激活的
    for (String key : keys) {
        for (Map.Entry entry : url.getParameters().entrySet()) {
            String k = entry.getKey();
            String v = entry.getValue();
            if ((k.equals(key) || k.endsWith("." + key))
                    && ConfigUtils.isNotEmpty(v)) {
                return true;
            }
        }
    }
    return false;
}

ActivateComparator比较器的规则如下，总结起来有这么几条规则：
1.before指定的过滤器，该过滤器将在这些指定的过滤器之前执行
2.after指定的过滤器，该过滤器将在这些指定的过滤器之后执行
3.order数值越小，越先执行
4.order数值相等的条件下，顺序将依赖于两个filter的加载顺序
5.before/after的优先级高于order

public class ActivateComparator implements Comparator