乐趣区

关于dubbo:Dubbo架构设计与源码解析一-架构设计

作者:黄金

一、架构演变

单利用架构 —-> 垂直架构 —-> 分布式架构 —-> 微服务架构 —-> 云原生架构





二、Dubbo 总体架构





1、角色职能

• Container:服务容器(tomcat、jetty、weblogic)

• Provider:服务提供者

•Consumer:服务消费者

•Registry:注册核心(zookeeper、Nacos、Apollo)

•Minitor:监控核心

2、调用流程

(1)服务容器负责启动,加载,运行服务提供者。

(2)服务提供者在启动时,向注册核心注册本人提供的服务。

(3)服务消费者在启动时,向注册核心订阅本人所需的服务。

(4)注册核心返回服务提供者地址列表给消费者,如果有变更,注册核心将基于长连贯推送变更数据给消费者。

(5)服务消费者,从提供者地址列表中,基于软负载平衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。

(6)服务消费者和提供者,在内存中累计调用次数和调用工夫,定时每分钟发送一次统计数据到监控核心。

三、Dubbo 分层架构





Config 配置层 :对外配置接口,以 ServiceConfig, ReferenceConfig 为核心,能够间接初始化配置类,也能够通过 spring 解析配置生成配置类

Proxy 服务代理层 :服务接口通明代理,生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为核心,扩大接口为 ProxyFactory

Registry 注册核心层 :封装服务地址的注册与发现,以服务 URL 为核心,扩大接口为 RegistryFactory, Registry, RegistryService

Cluster 路由层 :封装多个提供者的路由及负载平衡,并桥接注册核心,以 Invoker 为核心,扩大接口为 Cluster, Directory, Router, LoadBalance

Monitor 监控层 :RPC 调用次数和调用工夫监控,以 Statistics 为核心,扩大接口为 MonitorFactory, Monitor, MonitorService

Protocol 近程调用层 :封装 RPC 调用,以 Invocation, Result 为核心,扩大接口为 Protocol, Invoker, Exporter

Exchange 信息替换层 :封装申请响应模式,同步转异步,以 Request, Response 为核心,扩大接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer

Transport 网络传输层 :形象 mina 和 netty 为对立接口,以 Message 为核心,扩大接口为 Channel, Transporter, Client, Server, Codec

Serialize 数据序列化层 :可复用的一些工具,扩大接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

四、Dubbo 六大外围能力

1、面向接口代理的高性能 RPC 调用

提供高性能的基于代理的近程调用能力,服务以接口为粒度,为开发者屏蔽近程调用底层细节。

2、服务主动注册和发现

反对多种注册核心服务,服务实例高低线实时感知。

3、负载平衡和智能容错

内置多种负载平衡策略,智能感知上游节点健康状况,显著缩小调用提早,进步零碎吞吐量。

4、高度可扩大能力

遵循微内核 + 插件的设计准则,所有外围能力如 Protocol、Transport、Serialization 被设计为扩大点,平等看待内置实现和第三方实现

5、运行期流量调度

内置条件、脚本等路由策略,通过配置不同的路由规定,轻松实现灰度公布,同机房优先等性能。

6、可视化的服务治理与运维

提供丰盛服务治理、运维工具:随时查问服务元数据、服务衰弱状态及调用统计,实时下发路由策略、调整配置参数。

五、RPC 通信协议

分布式框架的外围是 RPC 框架,RPC 框架的外围是 RPC 协定。RPC 是指服务之间近程调用协定,也就是指明了服务之间接口调用,进行序列化和网络传输的约定。







Dubbo 提供了 Triple(Dubbo3)、Dubbo2 协定,第三方协定进行了集成,包含 gRPC、Thrift、JsonRPC、Hessian2、REST 等。其中 RPC 协定蕴含:服务提供者的 IP 地址、协定指定凋谢端口、运行服务、协定报文编码、序列化形式

六、负载平衡和集群容错

1、负载平衡

Dubbo 提供的是客户端负载平衡,即由 Consumer 通过负载平衡算法得出须要将申请提交到哪个 Provider 实例。在集群负载平衡时,Dubbo 提供了多种平衡策略,缺省为 random 随机调用。

算法 个性 备注
RandomLoadBalance 加权随机 默认算法,默认权重雷同
RoundRobinLoadBalance 加权轮询 借鉴于 Nginx 的平滑加权轮询算法,默认权重雷同
LeastActiveLoadBalance 起码沉闷优先 + 加权随机 背地是能者多劳的思维
ShortestResponseLoadBalance 最短响应优先 + 加权随机 更加关注响应速度
ConsistentHashLoadBalance 一致性 Hash 确定的入参,确定的提供者,实用于有状态申请

2、集群容错

在集群调用失败时,Dubbo 提供了多种容错计划,缺省为 failover 重试





容错机制 个性
Failover 失败主动切换
Failfast 疾速失败
Failsafe 失败平安
Failback 失败主动复原
Forking 并行调用多个服务器
Broadcast 播送调用所有提供者

七、设计思维

1、畛域模型

Protocol 服务域 :Invoker 裸露和援用的主性能入口,它负责 Invoker 的生命周期治理

Invoker 实体域 :Dubbo 的外围模型,其它模型都向它聚拢,或转换成它,它代表一个可执行体,可向它发动 invoke 调用,它有可能是一个本地的实现,也可能是一个近程的实现,也可能一个集群实现

Invocation 会话域 :持有调用过程中的变量,比方办法名,参数等

2、根本设计准则

Microkernel + Plugin 模式 :Microkernel 只负责组装 Plugin,Dubbo 本身的性能也是通过扩大点实现的,也就是 Dubbo 的所有性能点都可被用户自定义扩大所替换

URL:采纳 URL 作为配置信息的对立格局,所有扩大点都通过传递 URL 携带配置信息

八、总结

至此,Dubbo 总体架构与外围模块介绍实现,文中如有不当或者错误观点,欢送大家评论区指出。感兴趣的同学,能够关注后续“Dubbo 架构设计与源码解析”系列的文章。

退出移动版