敖丙思维导图系列目录
这些知识整理都是自己查阅帅丙资料(当然还有其他渠道)加以总结滴~ 每周都会更新知识进去。
如有不全或错误还请大家在评论中指出~
- 敖丙思维导图-集合
- 敖丙思维导图-多线程之synchronized\ThreadLocal\Lock\Volatitle\线程池
- 敖丙思维导图-JVM知识整理
- 敖丙思维导图-Spring
- 敖丙思维导图-Redis
- 敖丙思维导图-RocketMQ+Zookeeper
- 敖丙思维导图-Mysql数据库
- 敖丙思维导图-网络基础
- 敖丙思维导图-Dubbo
以下大部分来自傲丙的blog
Dubbo 总体架构
节点 | 角色说明 |
---|---|
Consumer | 需要调用远程服务的服务消费方 |
Registry | 注册中心 |
Provider | 服务提供方 |
Container | 服务运行的容器 |
Monitor | 监控中心 |
- 首先服务提供者 Provider 启动然后向注册中心注册自己所能提供的服务。
- 服务消费者 Consumer 启动向注册中心订阅自己所需的服务。
- 注册中心将提供者元信息通知给 Consumer, 之后 Consumer 因为已经从注册中心获取提供者的地址,因此可以通过负载均衡选择一个 Provider 直接调用 。
- 服务提供方元数据变更的话注册中心会把变更推送给服务消费者。
- 服务提供者和消费者都会在内存中记录着调用的次数和时间,然后定时的发送统计数据到监控中心。
注册中心和监控中心是可选的,你可以不要监控,也不要注册中心,直接在配置文件里面写然后提供方和消费方直连。
注册中心、提供方和消费方之间都是长连接,和监控方不是长连接,并且消费方是直接调用提供方,不经过注册中心。
就算注册中心和监控中心宕机了也不会影响到已经正常运行的提供者和消费者,因为消费者有本地缓存提供者的信息。
Dubbo 分层架构
大的三层分别为 Business(业务层)、RPC 层、Remoting,并且还分为 API 层和 SPI 层。
而分 API 层和 SPI 层这是 Dubbo 成功的一点,采用微内核设计+SPI扩展,使得有特殊需求的接入方可以自定义扩展,做定制的二次开发。
每层功能
-
Service,业务层,就是咱们开发的业务逻辑层。
-
Config,配置层,主要围绕 ServiceConfig 和 ReferenceConfig,初始化配置信息。
-
Proxy,代理层,服务提供者还是消费者都会生成一个代理类,使得服务接口透明化,代理层做远程调用和返回结果。
-
Register,注册层,封装了服务注册和发现。
-
Cluster,路由和集群容错层,负责选取具体调用的节点,处理特殊的调用要求和负责远程调用失败的容错措施。
-
Monitor,监控层,负责监控统计调用时间和次数。
-
Portocol,远程调用层,主要是封装 RPC 调用,主要负责管理 Invoker,Invoker代表一个抽象封装了的执行体,之后再做详解。
-
Exchange,信息交换层,用来封装请求响应模型,同步转异步。
-
Transport,网络传输层,抽象了网络传输的统一接口,这样用户想用 Netty 就用 Netty,想用 Mina 就用 Mina。
-
Serialize,序列化层,将数据序列化成二进制流,当然也做反序列化。
SPI (JDK 内置的一个服务发现机制)
它使得接口和具体实现完全解耦。我们只声明接口,具体的实现类在配置中选择。
定义了一个接口,然后在META-INF/services目录下放置一个与接口同名的文本文件,文件的内容为接口的实现类,多个实现类用换行符分隔。
Dubbo的服务暴露过程
URL
Dubbo 就是采用 URL 的方式来作为约定的参数类型,被称为公共契约,就是我们都通过 URL 来交互,来交流。
protocol://username:password