本文探讨了Dubbo服务调用过程中为何会先经过MockClusterInvoker处理，再进行集群容错策略。通过分析源码，发现服务引用时生成的代理对象包含了MockClusterInvoker。在refer方法内部，通过cluster.join()进行处理，而join()方法会涉及包装类mockClusterWrapper，它在执行时创建MockClusterInvoker，从而确保在实际调用前执行mock逻辑。
原来在学习源码的时候，没有注意到这个点，也没觉得有什么问题，但是最近忽然想到，为什么会先经过mockClusterInvoker的处理，然后再经过集群容错相关cluster的处理？
我们自己先分析一波
1.既然在调用目标方法的时候，先调用了mockClusterInvoker，那我们要看下注入的是个什么东西
2.执行链是先调用mockClusterInvoker，那我们可以认为一定是在通过@Reference注入bean的时候，这个bean类似于套娃形式，包了一层又一层，最外层是mockClusterInvoker(这里说最外面一层其实不太合适，因为debug的时候，会发现，最外面一层是InvokerInvocationHandler)
那我们有了这个推测，那就实际看下，通过@Reference注入的对象
可以发现，在通过@Reference注解或者dubbo:reference标签来引入一个bean的时候，引入的是一个代理对象，
这个代理对象是包装了N层，然后可以发现层次关系
那我们接下来要说的，就是在服务导出的时候，在什么时候，将mockClusterInvoker对象设置到了代理对象中
MockClusterInvoker
我之前的博客中有说过，在服务引入的时候，是会通过集群容错策略的处理，也就是failoverCluster、failbackCl
最低0.47元/天 解锁文章
扫一扫
3416
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
