Dubbo扩展点应用之一filter及@Activate自激活使用

　　与很多框架一样，Dubbo也存在拦截（过滤）机制，可以通过该机制在执行目标程序前后执行我们指定的代码。Dubbo中Filter只是Dubbo提供的可自定义扩展的扩展点之一。通过该扩展点地理解，可以触类旁通地理解其他类似自激活的扩展点。

　　那么什么是自激活？如果一个扩展点有多个实现，那么最后究竟使用哪个实现呢？根据不同的条件参数来动态选择可以使用的扩展时（可能需要同时使用多个扩展），就会使用到自激活扩展了。这个就是自激活。

　　Dubbo的Filter机制是专门为服务提供方和服务消费方调用过程进行拦截设计的，每次远程方法执行该拦截都会被执行。这样就为开发者提供了非常方便的扩展性，比如为dubbo接口实现监控功能、日志功能等。

　　从Dubbo已实现的Filter中看具体如何实现：就用id为trace的filter

　　　　

　　该Filter的类图如下：

　　　　

　　对于@SPI之前注解前面已经阐述了，这里重点阐述@Activate和Filter接口中的invoke方法。

　　　　

　　首先看Filter接口：

　　　　

 　　　　通过接口注释可以看到整个Filter中invoke方法的执行顺序：invoker.invoke(invocation)必须执行一个filter的实现类才会有效工作。

　　再看@Activate注解：

　　　　这个注解中仍有效的group等如何赋值是一个需要关注的问题。根据该注解中的注释：

　　　　　　

　　　　可知SPI的框架定义了有效的group值，value值由URL判断是否有效。即group和value代表激活的条件，group代表URL中的分组，value代表URL中的key。如果匹配条件，则会激活扩展；order指定了扩展使用的顺序，值越小越早。

　　关于URL与注解中值的关系在SPI自适应中已经有体现(参考Dubbo SPI机制之三Adaptive自适应功能 - 池塘里洗澡的鸭子 - 博客园 (cnblogs.com))，那么group的值有哪些呢？在Dubbo的SPI框架中提供了哪些可选的group的值？

　　通过TraceFilter上的注解，可以明确group的访问在接口CommonConstants中，那哪些是group的可选值？参考dubbo官方文档，可知　　

　　　　

　　对于Filter与@Active具体使用范例，如下：

　　　　

　　下面自定义一个Filter，记录消费端每次调用耗时进行上述范例的具体实践。并利用该统计，计算调用方法的TP90和TP99。

　　1、自定义一个Filter，仅被消费端使用：

　　　　1）自定义一个TPMonitorFilter类implements Filter

　　　　　　

 　　　2）在 META-INF.dubbo 中新建 org.apache.dubbo.rpc.Filter 文件，并将当前类的全名写入timerFilter=包名.过滤器的名字

　　　　　　

 　　2、消费端引用上述Filter所属依赖，并调用。

　　　　1）引用该依赖

　　　　　　

　　　　2）调用

　　　　　　

 　　3、主程序中执行打印TP90及TP99：

　　　　

　　　　结果：

　　　　

 　　补充：之前阐述过自适应，那么自激活与自适应的区别在哪里,都是一个扩展点有多个实现?

　　　　区别在于自激活具体使用哪些实现类体现在配置或代码中的；而自适应是在运行时，通过URL参数来动态确定运行某一个实现。即自激活可以同时加载一个扩展点的一个或多个实现(个人理解为类似AOP，不知道实现是否使用AOP，待验证)，而自适应仅能加载一个实现。