[引用]Dubbo之旅--内部逻辑

在没有开始用代码来解释之前,用图最能够表达一些关系,关于Dubbo的内部逻辑调用关系,借用官方的图示来说明一下,如下图

 

        通过上图中的一个个方框我们称之为节点,总共有5个节点,这五个节点可以看成五个角色,每个角色都有一定的功能.每个角色的意思如下:

1. Provider: 暴露服务的服务提供方。

在实际项目中一般称这个角色为提供者.它主要是向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

 

2. Consumer: 调用远程服务的服务消费方。

既然有提供者,对应的这就是消费者。服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

 

3. Registry: 服务注册与发现的注册中心。

注册中心这个概念将会在接下来多次提到, 它是一个比较关键的角色.它的角色是主要负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小

 

4. Monitor: 统计服务的调用次调和调用时间的监控中心。

用来监控各个服务提供者和消费者的相关情况.例如负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。

 

5. Container: 服务运行容器。

容器就很好理解了,Dubbo可以基于Spring容器来提供和消费.

 

        额外说明:注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外，注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者。

 

        到现在已经知道五个角色都是干什么的了,现在再回到上面的图,我们从0到5将这个五个角色串起来.

 

0.服务容器负责启动，加载，运行服务提供者。

 

1.服务提供者在启动时，向注册中心注册自己提供的服务。

 

2.服务消费者在启动时，向注册中心订阅自己所需的服务。

 

3.注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

 

4.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

 

5.服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

 

      以上的流程便是Dubbo的内部逻辑流程,这是从比较宏观的角度去它的内部逻辑.这里提到的注册中心,在项目中用到比较多的是Zookeeper.在下篇文章会对Zookeeper进行初步的介绍,原因是在随后对Dubbo的相关代码示例中用到了它.