原来在学习源码的时候,没有注意到这个点,也没觉得有什么问题,但是最近忽然想到,为什么会先经过mockClusterInvoker的处理,然后再经过集群容错相关cluster的处理?
我们自己先分析一波
1.既然在调用目标方法的时候,先调用了mockClusterInvoker,那我们要看下注入的是个什么东西
2.执行链是先调用mockClusterInvoker,那我们可以认为一定是在通过@Reference注入bean的时候,这个bean类似于套娃形式,包了一层又一层,最外层是mockClusterInvoker(这里说最外面一层其实不太合适,因为debug的时候,会发现,最外面一层是InvokerInvocationHandler)
那我们有了这个推测,那就实际看下,通过@Reference注入的对象

可以发现,在通过@Reference注解或者dubbo:reference标签来引入一个bean的时候,引入的是一个代理对象,
这个代理对象是包装了N层,然后可以发现层次关系
那我们接下来要说的,就是在服务导出的时候,在什么时候,将mockClusterInvoker对象设置到了代理对象中
MockClusterInvoker
我之前的博客中有说过,在服务引入的时候,是会通过集群容错策略的处理,也就是failoverCluster、failbackCluster的处理(具体看配置的容错策略是什么),但是在经过容错策略处理之前,是会先经过mockClusterWrapper的处理
mockClusterWrapper是cluster的包装类,在dubbo中,包装类类似于spring中的aop,我是这么来理解的,包装类的处理,是在spi机制中完成的
com.alibaba.dubbo.config.ReferenceConfig#createPr

本文探讨了Dubbo服务调用过程中为何会先经过MockClusterInvoker处理,再进行集群容错策略。通过分析源码,发现服务引用时生成的代理对象包含了MockClusterInvoker。在refer方法内部,通过cluster.join()进行处理,而join()方法会涉及包装类mockClusterWrapper,它在执行时创建MockClusterInvoker,从而确保在实际调用前执行mock逻辑。
最低0.47元/天 解锁文章
1878

被折叠的 条评论
为什么被折叠?



