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 层,数据序列化层分布式
注册中心挂了能够继续通讯吗?
能够,由于刚开始初始化的时候,消费者会将提供者的地址等信息拉取到本地缓存,因此注册中心挂了能够继续通讯。
还没有评论,来说两句吧...