Apache Dubbo详解

---

前言

开始之前，你们知道dubbo的历程吗哈哈。不知道为啥，不管听歌，还是学一个知识点，我觉得这个是我最想知道的，像是在听一个简短的故事🤣

其实最早他叫阿里巴巴dubbo,是阿里的内部分布式框架，在2012年开源。之后各大公司对他进行了扩展，有当当的dubbox和网易的dubbok等。2014年由于策略上的改变，阿里停更了，他的版本停留在了2.4.11。但是在 2017 年，spring cloud 大红大紫，阿里看到分布式市场的前景，又重启了对 Dubbo 维护。在 2018 年和 Dubbox 进行了合并，并且进入 Apache 孵化器，这个时候他的版本是2.6。在 2019 年毕业正式成为 Apache 顶级项目。 /font>

---

一、dubbo简介

这部分内容我觉得官网(https://dubbo.apache.org/zh/ )最有发言权 ，请看6大功能：面向接口代理的高性能RPC调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。话不多说，直接上官网图。


看这张图好像很简单，不过这只是让你有一个整体的映象，知道dubbo中的几个重要组件而已。想要进一步的了解，还要具体来看下他的分层结构和调用链路。
大家站稳扶好，我要开始装逼了。。。🤣（答应我，耐心看下面这张图，虽然又大又乱，我会一步步的分析）
Dubbo从整体上是个🍔设计，可以分为三大层10小层：

• Service，业务层，就是咱们开发的业务逻辑层。
• Config，配置层，主要围绕 ServiceConfig 和 ReferenceConfig，初始化配置信息。
• Proxy，代理层，服务提供者还是消费者都会生成一个代理类，使得服务接口透明化，代理层做远程调用和返回结果。
• Register，注册层，封装了服务注册和发现。
• Cluster，路由和集群容错层，负责选取具体调用的节点，处理特殊的调用要求和负责远程调用失败的容错措施。
• Monitor，监控层，负责监控统计调用时间和次数。
• Portocol，远程调用层，主要是封装 RPC 调用，主要负责管理 - Invoker，Invoker代表一个抽象封装了的执行体，之后再做详解。
• Exchange，信息交换层，用来封装请求响应模型，同步转异步。
• Transport，网络传输层，抽象了网络传输的统一接口，这样用户想用 Netty 就用 Netty，想用 Mina 就用 Mina。
• Serialize，序列化层，将数据序列化成二进制流，当然也做反序列化

1. 消费者通过Interface进行方法调用 统一交由消费者端的 Proxy 通过ProxyFactory 来进行代理对象的创建 使用到了 jdk javassist技术
2. 交给Filter 这个模块 做一个统一的过滤请求 在SPI案例中涉及过
3. 接下来会进入最主要的Invoker调用逻辑
   通过Directory 去配置中新读取信息 最终通过list方法获取所有的Invoker
   通过Cluster模块 根据选择的具体路由规则 来选取Invoker列表
   通过LoadBalance模块 根据负载均衡策略 选择一个具体的Invoker 来处 理我们的请求
   如果执行中出现错误 并且Consumer阶段配置了重试机制 则会重新尝试执行
4. 继续经过Filter 进行执行功能的前后封装 Invoker 选择具体的执行协议
5. 客户端 进行编码和序列化 然后发送数据
6. 到达Consumer中的 Server 在这里进行 反编码 和 反序列化的接收数据
7. 使用Exporter选择执行器
8. 交给Filter 进行一个提供者端的过滤 到达 Invoker 执行器
9. 通过Invoker 调用接口的具体实现 然后返回

二、高级特性

1.SPI机制

我们知道，SPI是JDK内置的一种服务发现机制。使用它的优势是实现解耦，使得第三方服务模块的装配控制逻辑与调用者的代码分离。

首先明确，Dubbo的SPI是自己封装的，那为什么不用JDK的呢？

• JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加 载，会很浪费资源
• 如果有扩展点加载失败，则所有扩展点无法使用
• 提供了对扩展点包装的功能(Adaptive)，并且还支持通过set的方式对其他的扩展点进行注入

2.使用javaAssist减少反射调用开销

javaAssist在服务提供者的实现类外面包了一层warpper对象，减少反射调用开销。

3.Dubbo集群容错与负载均衡策略

容错模式：

• 失败重试（Failover Cluster）
  服务消费方获取 提供方失败后，会自动切换到其他服务提供者服务器进行重试，这通常用于读操作或者具有幂等的写操作。
• 快速失败 (FailFast Cluster)
  服务消费方获取 提供方失败后，立即报错，也就是只调用一次。通常这种方式用于非幂等性写操作
• 安全失败
  当服务消费者调用服务出现异常时，直接忽略异常。这种模式通常用于写入审计日志等操作。
• 失败自动恢复
  当服务消费者调用服务出现异常后，在后台记录失败的请求，并按照一定的策略后期再进行重试。这种模式通常用于消息通知操作。
• 并行调用
  当消费方调用一个接口方法后，Dubbo Client会并行调用多个服务提供者的服务，只要其中一个成功即返回。这种模式通常用于实时性要求较高的读操作，但需要浪费更多的服务资源。
• 广播调用
  当消费方调用一个接口方法后，Dubbo Client会逐个调用服务提供者的服务，任意一台服务器调用异常则这次调用就标志失败。这种模式通常用于通知所有提供者更新缓存或者日志等本地资源信息。

负载均衡策略

• 随机策略
• 轮询策略
• 最少活跃调用数
• 一致性hash策略

---

总结

不管之前对dubbo是否了解，相信看完都应该有一些些收获吧哈哈。如果有什么错误，请一定在评论区指出。。。
如果不想吃生活的苦，那就跟我一起吃学习的苦，下期见。