【Dubbo】Dubbo 有什么用？Dubbo 架构？

1.Dubbo 有什么用

1.1 远程通信

架构已经从最初的单体到分布式，而实现分布式的关键因素就是远程服务的调用。

在远程通信领域已经出现过许多技术，如 Java 的 RMI、WebService、Hessian、Dubbo、Thrift 等 RPC框架；但现在我们使用较多的就是 Dubbo 以及 Http 协议。

为什么不直接使用socket或nio进行通信，而是要使用这些RPC框架？因为如下因素

• 需要考虑底层网络通信的处理
• 序列化和反序列化工作
• 功能模块的可复用性强

因此远程通信应该是一个中间件服务，有专门的开发人员去实现，使用者不用关心底层通信逻辑。

1.2 服务治理

虽然满足了通信的需求，但是当大规模服务化后，远程通信打来的弊端就愈发凸显

• 跟踪监控：服务链路变长了，如何实现对服务的跟踪和监控
• 发现感知：服务的大规模集群使得服务之间需要依赖注册中心来解决服务的发现和服务感知
• 容错机制：服务通信之间的异常，需要有一种保护机制防止一个节点故障引发大规模的系统故障，所以要有容错机制
• 负载均衡：服务大规模集群会是的客户端需要引入负载均衡机制实现请求分发

对于服务治理的需求，传统 rpc框架就显得有点力不从心，因此很多企业开发了自己的 rpc框架

• 阿里的 HSF、Dubbo
• 京东的 JSF框架
• 当当的 dubbox
• 新浪的 motan
• 蚂蚁金服的 sofa

然后对于没有从0到1开发能力的公司，就会优先采用比较成熟的开源框架，而 Dubbo 就是其中一个

Dubbo 主要是一个分布式服务治理解决方案，那么什么是服务治理？服务治理主要是针对大规模服务化以后，服务之间的路由、负载均衡、容错机制、 服务降级这些问题的解决方案，而 Dubbo 实现的不仅仅是远程服务通信， 并且还解决了服务路由、负载、降级、容错等功能。

2.Dubbo发展史

Dubbo 是阿里巴巴内部使用的一个分布式服务治理框架

1. 2012 年开源，因为 Dubbo 在公司内部经过了很多的验证相对来说比较成熟，所以在很短的 的还是件就被很多互联网公司使用，再加上阿里出来的很多技术大牛进入各 个创业公司担任技术架构以后，都以 Dubbo 作为主推的 RPC 框架使得 dubbo 很快成为了很多互联网公司的首要选择。并且很多公司在应用 dubbo时，会基于自身业务特性进行优化和改进，所以也衍生了很多版本， 比如京东的 JSF、比如新浪的 Motan、比如当当的 dubbox.
2. 在2014年10月份，Dubbo停 止了维护。
3. 后来在2017年的9月份，阿里宣布重启 Dubbo，并且对于 Dubbo 做好了长期投入的准备，并且在这段时间 Dubbo 进行了非常多的更新。
4. 2018年1月8日，Dubbo 创始人之一梁飞在 Dubbo 交流群里透露了 Dubbo 3.0 正在动工的消息。Dubbo 3.0 内核与Dubbo2.0 完全不同，但兼容 Dubbo 2.0。Dubbo 3.0 将支持可选Service Mesh
5. 2018年2月份， Dubbo 捐给了 Apache。另外，阿里巴巴对于 Spring Cloud Alibaba 生态的完善，以及 Spring Cloud 团队对于 alibaba 整个服务治理生态的支持，所以 Dubbo 未来依然是国内绝大部分公司的首要选择。

3.Dubbo 架构

流程说明：

1. Provider(提供者)绑定指定端口并启动服务
2. 指供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储
3. Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心
4. 注册中心根据 消费者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。
5. Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。
6. Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer

这么设计的意义：

1. Consumer 与Provider 解偶，双方都可以横向增减节点数。
2. 注册中心对本身可做对等集群，可动态增减节点，并且任意一台宕掉后，将自动切换到另一台
3. 去中心化，双方不直接依懒注册中心，即使注册中心全部宕机短时间内也不会影响服务的调用
4. 服务提供者无状态，任意一台宕掉后，不影响使用

4.Dubbo 整体设计

• config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
• proxy 服务代理层：服务接口透明代理，生成动态代理 扩展接口为 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

其协作流程如下：