与很多框架一样，Dubbo也存在拦截（过滤）机制，可以通过该机制在执行目标程序前后执行我们指定的代码。Dubbo中Filter只是Dubbo提供的可自定义扩展的扩展点之一。通过该扩展点地理解，可以触类旁通地理解其他类似自激活的扩展点。 那么什么是自激活？如果一个扩展点有多个实现，那么最后究竟使用哪个实现呢？根据不同的条件参数来动态选择可以使用的扩展时（可能需要同时使用多个扩展），就会使用到自激活
理解dubbofilter的执行顺序 对dubbo filter执行顺序可以看下这篇。背景在处理网关泛化调用的异常时，需要在provider端将可读异常的message返回给调用方，方便展示。 现有工程中有处理异常的filter:@Activate(group = Constants.PROVIDER, order=Integer.MIN_VALUE)
@Slf4j
public class E
ListenerExporterListener: dubbo在服务暴露(exporter)以及销毁暴露(unexporter)服务的过程中提供了回调窗口，供用户做业务处理。ProtocolListenerWrapper在暴露过程中构建了监听器链public class ProtocolListenerWrapper implements Protocol {
public <T&g
背景dubbo 项目需要配置日志信息，显示请求路径、入参、返回值。本来已经用spring的AoP实现了消费者端的日志，但是提供者处不知道如何弄。后来又查到dubbo有自己的方式，通过filter 的方式配置日志（有贴子说dubbo filter 的方式和spring aop 方式冲突，我没有试过）。原生的总是最适合的，所以采用了dubbo的filter 方式。dubbo配置filterconsum
文章目录一、前言二、Filter 分类三、代码解析1. CacheFilter2. ValidationFilter3. EchoFilter4. GenericFilter & GenericImplFilter5. TokenFilter6. AccessLogFilter7. ActiveLimitFilter & ExecuteLimitFilter7.1 ActiveL
写在前面dubbo给我们提供了很多的扩展点，异常过滤就是其中的一个，比如参数验证的ContraintViolationException异常需要我们在service方法上手动的throw，才能抛出去，不然会自动的封装为RuntimeException，我们来扩展异常过滤，抛出自定义的异常信息，从而以更加友好的方式来暴漏出现的问题。 扩展的原理是利用SPI，SPI符合开闭原则，即，对修改关闭，对扩展
今天在学习别人做的一份工程项目的时候发现了一块新大陆，虽然很小，但作为入侵者的我觉得还是有必要从应用层面对它进行记录，至于从源码原理层面，那也得等定居久了，有了深入了解才来写嘛！对了，忘了说了，这块新大陆就是dubbo filter。做过web开发的朋友都知道，在java EE中都有过滤器这种东西，作用就是用来对请求前做些权限校验，同时过滤器也是有链式调用的，你可以声明多个Filter,然后指定调
加载机制provider端//org.apache.dubbo.config.ServiceConfig#doExportUrlsFor1Protocol方法中
Exporter<?> exporter = PROTOCOL.export(wrapperInvoker);//org.apache.dubbo.qos.protocol.QosProtocolWrapper#export
概述哈喽，咱们如约而至，今天咱一起看下dubbo的SPI扩展部分，说起这个不禁感慨当初开发dubbo的人，脑子怎么长得做出来这么优秀的产品。我们可以基于SPI做过滤器、负载均衡器、日志打印、协议扩展等等操作，非常的方便，而且相对于jdk原生SPI做了不少优化。咱们先实战一波，看下具体是如何使用的，然后再分析下源码。应用实战dubbo支持的SPI扩展有:协议扩展、调用拦截扩展、引用监听扩展、暴露监听
自己搞明白了，开始没读懂代码。Dubbo的Filter是一个调用另一个的，最后再执行业务代码。在这一行调下一个Filter，那么写在这行代码前
原创
2023-06-06 16:52:09
185阅读
dubbo过滤器1.前言dubbo filter的作用和web filter的作用是一样的，在真正调用前做一些公共的处理。这也就是在重要的过程上设置拦截接口，提供扩展供业务实现。dubbo过滤器是整个dubbo框架中非常重要的组成部分，dubbo中许多重要功能都是基于过滤器扩展而来。过滤器提供了provider和consumer调用过程的拦截，即每次RPC调用的时候，对应的过滤器都会生效。虽然过滤
...
转载
2017-02-03 09:54:00
66阅读
2评论
Dubbo服务调用扩展点学习及实践Dubbo有哪些服务调用扩展点？ 在服务调用过程中，主要分为两部分，一部分是消费者端链路，另一部分是服务端链路。消费者端：首先由Stub将请求封装成Invocation对象，将Invocation对象传递给ClusterFilter。ClusterFilter是一个扩展点，主要做消费者端的请求拦截，实现请求预处理、参数转换、请求日志记录、限流等操作。随后进入Clu
从上文可知，在服务的调用或消费端发送请求命令中，Dubbo引入过滤器链机制来实现功能的包装（或扩展）。Dubbo很多功能，例如泛化调用、并发控制等都是基于Filter机制实现的，系统默认的Filter在/dubbo-rpc-api/src/main/resources/META-INF/dubbo/internal/com.alibaba.dubbo.rpc.Filter文件中定义，内容如下
1 先说解决方案（2.7.3 版本）全局指定直接使用 <dubbo:consumer filter="filter1,filter2"/>如果是service单独指定可如下配置，consumer端类似2 为什么？一起来看看，filter过滤链的构造过程（2.7.3 版本）执行流程是：org.apache.dubbo.config.ServiceConfig 类加载时jvm 实例化 fi
扩展点介绍 如上图所示，从服务调用的角度来看，Dubbo 在链路中提供了丰富的扩展点，覆盖了负载均衡方式、选址前后的拦截器、服务端处理拦截器等。 简单来说 Dubbo 发起远程调用的时候，主要工作流程可以分为消费端和服务端两个部分。消费端的工作流程如下：通过 Stub 接收来自用户的请求，并且封装在 Invocation 对象中将 Invocation 对象传递给 ClusterFilter（扩展
起因发现这个问题的起因是前端联调接口的时候发现统一的异常处理没有发挥作用,我们定义的处理的异常类型为AppException(国际惯例继承于RuntimeException),但是Dubbo服务端实际返回的异常变成了RuntimeException,我们自定义的异常处理没有发生作用.深入研究Dubbo的异常处理针对发现的问题,查阅了相关的代码和源码发现Dubbo有一个自带的过滤器接口声明了,并且实
熟悉Dubbo的同学或朋友，都会知道，一般dubbo的service层都是一些通用的，无状态的服务。但是在某些特殊的需求下，我们又需要传递一些上下文环境,打个不恰当的比方，例如需要在每次调用dubbo的服务的时候，记录一下用户名或者需要知道sessionid等。解决办法1如果是在项目设计的时候就意识到这一点的话，就好办，把所有的dubbo服务请求的参数都封装一个公共的父类，把一些上下文
原创
2022-04-22 17:54:45
750阅读
Dubbo 是阿里巴巴开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输入与输出功能。作为一个优秀的框架，至少应该包含以下几个特点：完善的文档活跃的社区良好的扩展性今天主要讨论的主题就是 dubbo 中良好的扩展性。 dubbo 的扩展点加载是从 JDK 标准的 SPI (Service Provider Interface) 扩展点发现加强而来。JDK 标准的 SPI
熟悉Dubbo的同学或朋友，都会知道，一般dubbo的service层都是一些通用的，无状态的服务。但是在某些特殊的需求下，我们又需要传递一些上下文环境,打个不恰当的比方，例如需要在每次调用dubbo的服务的时候，记录一下用户名或者需要知道sessionid等。解决办法1如果是在项目设计的时候就意识到这一点的话，就好办，把所有的dubbo服务请求的参数都封装一个公共的父类，把一些上下文
原创
2017-07-06 00:37:35
269阅读
