dubbo 的服务引入和服务目录（二）（总结）

图1

图1服务引用开始是从ReferenceBean 类的getObject() 方法开始的

图2

图 2 在init() 方法中赋值到ref， 

图3

图 3 init() 的核心是createPrxy（）方法，创建好的代理类对象赋值给ref.

图4

 

图4  366行核f心，一般就是一个注册中心不会有直连的情况。 url是registry开头的。例如registry://  那么refprotocol的实现类为RegistryProtocol的 refer方法。

图5

图5 的核心是调用doRefer（）创建invoke.

图6

图6 的核心是 385行 初始化路由规则，386行在 zookeeper的config目录下订阅；第一绑定监听事件 ；第二 目录的变化，提供者参数的变化，路由的变化（图8），把提供者的地址取下来，每一个地址转化成一个invoker ,然后把invoker放在一个map中（图9，图10）   389行 利用cluster.join() 创建Invoke返回。每一个invoker负责调用一个提供者。 一个提供者返回一个invoker；如果是多个提供者，多个invoker.  会把多个invoker放在服务目录里，然后通过cluster.join(服务目录) 返回一个invoker ，最终把invoker包装成InvokerDelegate对象的Invoker返回图12； 服务目录就是一个消费者本地的缓存，对注册中心的缓存。缓存一个服务里有那几个提供者。389行 cluster 执行join方法前也要执行包装类。图

图7

 

图7 为 invokes  所有提供者的 invoker集合。

图8

图9 

图10

图11

图11  给invokers 赋值。 

图12

图12  把invoker包装成InvokerDelegate对象的Invoker返回。 protocol 的refer（）方法，根据url调用默认的实现类。 调用实现类前默认执行包装类。如图13 的3个包装类 。这三个包装类执行时没有顺序的，是放在set中的。

图13

图14

图14的  67行到71行的作用是，引用执行完后，去执行监听的事件，也就是监听器事件的触发（如图15）

图15

图16   

图16 这个wapper没有什么用，只是在注册中心的时候有用。

图17

 

图17  这个116行 就是构建一个调用链。 116行 protocol  从url获取的实现类为HttpProtocol， HttpProtocol没有refer() 方法，然后他会调用父类的refer方法返回 AbstractInvoker 对象。把AbstractInvoker对象作为参数传给 buildInvokerChain方法图20； 

图18

图18 为调用链详细的执行过程， 最终返回的InvokerDelegate对象，  InvokerDelegate对象实现了InvokerWrapper类因此他也invoker方法 图22,图23 ， InvokerDelegate调用时 先经过三个Wrapper类 ，执行invoker方法后最终同AbstractInvoker对象调用服务提供者。

 

图19

图19  49行 ，消费方会加载三个filter； ConsumerContexFilter,FutureFilter,MonittorFiter .图19

图20

图21

 AbstractInvoker 

图22

tu

图23

图24

图25

图26

图26 Cluster的默认实现类是FailoverCluster类。 当执行cluster.join()方法时，默认 先执行包装类MockClusterWrapper类的join方法（图28）, 在执行MockClusterWrapper类的join()方法时，执行 实现类的FailoverCluster类的join方法（图29） 返回FailoverClusterInvoker类。最终包装成MockClusterInvoker返回。 图30的 invoker==MockClusterInvoker 。 图31把为invoker创建代理类返回。 那么也就是 从spring中拿出来的对象是  MockClusterInvoker对象的代理对象。图35.

图27

图27 的ClusterWrapper的包装类。详细图28

图28

图29

图30

图31

图32

图32代理类默认的实现类为javassist，图33位对应的包装类.

图33

图34

图35