共计 2699 个字符，预计需要花费 7 分钟才能阅读完成。
作者：黄金
一、架构演变
单利用架构 —-> 垂直架构 —-> 分布式架构 —-> 微服务架构 —-> 云原生架构
二、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 架构设计与源码解析”系列的文章。
