Dubbo架构图和Dubbo执行流程

一：Dubbo架构图和Dubbo执行流程

Dubbo架构图

从架构图可以看出，Consumer服务消费者，Provider服务提供者。Container服务容器。消费当然是invoke提供者了，invoke这条实线按照图上的说明当然是同步的意思了。但是在实际调用过程中，Provider的位置对于Consumer来说是透明的，上一次调用服务的位置（IP地址）和下一次调用服务的位置，是不确定的。这个地方就需要使用注册中心来实现软负载。

Register
服务提供者先启动start，然后注册register服务。消费者订阅subscribe服务，如果没有订阅到自己想获得的服务，它会不断的尝试订阅。新的服务注册到注册中心以后，注册中心会将这些服务通过notify通知到消费者。
Monitor
这是一个监控，图中虚线表明Consumer 和Provider通过异步的方式发送消息至Monitor，Consumer和Provider会将信息存放在本地磁盘，平均1min会发送一次信息。Monitor在整个架构中是可选的（图中的虚线并不是可选的意思），Monitor功能需要单独配置，不配置或者配置以后，Monitor挂掉并不会影响服务的调用。

Dubbo的执行流程

• 第一步：provider 向注册中心去注册

• 第二步：consumer 从注册中心订阅服务，注册中心会通知 consumer 注册好的服务

• 第三步：consumer 调用 provider

• 第四步：consumer 和 provider 都异步通知监控中心

dubbo 工做原理

• 第一层：service 层，接口层，给服务提供者和消费者来实现的redis

• 第二层：config 层，配置层，主要是对 dubbo 进行各类配置的数据库

• 第三层：proxy 层，服务代理层，不管是 consumer 仍是 provider，dubbo 都会给你生成代理，代理之间进行网络通讯缓存

• 第四层：registry 层，服务注册层，负责服务的注册与发现微信

• 第五层：cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务网络

• 第六层：monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监控架构

• 第七层：protocol 层，远程调用层，封装 rpc 调用并发

• 第八层：exchange 层，信息交换层，封装请求响应模式，同步转异步负载均衡

• 第九层：transport 层，网络传输层，抽象 mina 和 netty 为统一接口异步

• 第十层：serialize 层，数据序列化层分布式

注册中心挂了能够继续通讯吗？

能够，由于刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，因此注册中心挂了能够继续通讯。