Dubbo框架

SpringCloud与Dubbo的区别

两者都是现在主流的微服务框架，但却存在不少差异：

• 初始定位不同：SpringCloud定位为微服务架构下的一站式解决方案；Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理
• 生态环境不同：SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。
• 调用方式：SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。
• 组件差异比较多：例如SpringCloud注册中心一般用Eureka，而Dubbo用的是Zookeeper

SpringCloud：Spring公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案。

Dubbo：阿里巴巴开源的RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。

 

Dubbo

Apache Dubbo是一款高性能Java RPC框架。

Dubbo 是阿里巴巴 2011年开源的一个基于 Java 的 RPC 框架，中间沉寂了一段时间，不过其他一些企业还在用 Dubbo 并自己做了扩展，比如当当网的 Dubbox，还有网易考拉的 Dubbok。

但是在 2017 年阿里巴巴又重启了对 Dubbo 维护，在 2017 年荣获了开源中国 2017 最受欢迎的中国开源软件 Top 3。

在 2018 年和 Dubbox 进行了合并，并且进入 Apache 孵化器，在 2019 年毕业正式成为 Apache 顶级项目。

目前 Dubbo 社区主力维护的是 2.6.x 和 2.7.x 两大版本，2.6.x 版本主要是 bug 修复和少量功能增强为准，是稳定版本。而 2.7.x 是主要开发版本，更新和新增新的 feature 和优化，并且 2.7.5 版本的发布被 Dubbo 认为是里程碑式的版本发布。

2.7.5:

• HTTP/2 (gRPC) 协议支持
• Protobuf 支持
• 性能优化，调用链路性能提高 30%
• 支持 TLS 安全传输链路
• 其它

自己实现一个RPC框架需要做什么

这些都是框架需要做的，让消费者像在调用本地方法一样，无感知。

• 1.首先得提供接口吧，以jar包方式
• 2.接口的实现呢？使用proxy代理
• 3.代理到哪里呢？所以得有个注册中心获取具体的服务地址
• 4.有多个服务地址用谁呢？所以得有负载均衡或者调用策略，按机房就近还是随机等等
• 5.发生错误/异常怎么办？所以得有容错机制、限流、降级、熔断等等
• 6.通信双方怎么交互？制定交互协议、数据/对象 编解码 序列化等
• 7.除此之外，过程中间可能还需要一些自定义处理：加入一些用户自定义filter、默认filter比如统计数量等
• 8.整体监控中心：调用次数、调用时间、失败次数等等
• 9.动态配置：错误多少次降级等等

Dubbo分层架构

 

逻辑三层：分别为 Business（业务层）、RPC 层、Remoting，分为大三层其实就是和我们知道的网络分层一样的意思，只有层次分明，职责边界清晰才能更好的扩展。

实现上分为 API 层和 SPI 层，分 API 层和 SPI 层这是 Dubbo 成功的一点，采用微内核设计+SPI扩展，使得有特殊需求的接入方可以自定义扩展，做定制的二次开发。

• Service，业务层，就是咱们开发的业务逻辑层。
• proxy 服务代理层：调用远程方法像调用本地的方法一样简单的一个关键，真实调用过程依赖代理类，以 ServiceProxy 为中心。
• registry 注册中心层：封装服务地址的注册与发现。
• cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心。
• monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心。
• protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心。
• exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心。
• transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心。
• serialize 数据序列化层 ：对需要在网络传输的数据进行序列化。

Invoker

Invoker 是 Dubbo 领域模型中非常重要的一个概念，你如果阅读过 Dubbo 源码的话，你会无数次看到这玩意。就比如下面我要说的负载均衡这块的源码中就有大量 Invoker 的身影。简单来说，Invoker 就是 Dubbo 对远程调用的抽象。按照 Dubbo 官方的话来说，Invoker 分为：服务提供 Invoker、服务消费 Invoker。

假如我们需要调用一个远程方法，我们需要动态代理来屏蔽远程调用的细节吧！我们屏蔽掉的这些细节就依赖对应的 Invoker 实现， Invoker 实现了真正的远程服务调用。

Dubbo SPI

 SPI（Service Provider Interface），是 JDK 内置的一个服务发现机制，它使得接口和具体实现完全解耦。我们只声明接口，具体的实现类在配置中选择。具体的就是你定义了一个接口，然后在META-INF/services目录下放置一个与接口同名的文本文件，文件的内容为接口的实现类，多个实现类用换行符分隔。这样就通过配置然后反射加载实现类来决定具体用哪个实现！

为什么 Dubbo 不用 JDK 的 SPI，而是要自己实现?

因为 Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化，假设一个实现类初始化过程比较消耗资源且耗时，但是你的代码里面又用不上它，这就产生了资源的浪费。

因此 Dubbo 就自己实现了一个 SPI，给每个实现类配了个名字，通过名字去文件里面找到对应的实现类全限定名然后加载实例化，按需加载。

微内核架构

微内核架构包含两类组件：核心系统（core system） 和 插件模块（plug-in modules）。核心系统提供系统所需核心能力，插件模块可以扩展系统的功能。因此， 基于微内核架构的系统，非常易于扩展功能。我们常见的一些 IDE，都可以看作是基于微内核架构设计的。绝大多数 IDE 比如 IDEA、VSCode 都提供了插件来丰富自己的功能。

通常情况下，微核心都会采用 Factory、IoC、OSGi 等方式管理插件生命周期。Dubbo 不想依赖 Spring 等 IoC 容器，也不想自已造一个小的 IoC 容器（过度设计），因此采用了一种最简单的 Factory 方式管理插件 ：JDK 标准的 SPI 扩展机制 （java.util.ServiceLoader）。

服务注册和调用

首先 Provider 启动，通过 Proxy 组件根据具体的协议 Protocol 将需要暴露出去的接口封装成 Invoker，Invoker 是 Dubbo 一个很核心的组件，代表一个可执行体。

然后再通过 Exporter 包装一下，这是为了在注册中心暴露自己套的一层，然后将 Exporter 通过 Registry 注册到注册中心。这就是整体服务暴露过程。

Dubbo 就是采用 URL 的方式来作为约定的参数类型，被称为公共契约，就是我们都通过 URL 来交互。

（protocol://username:password@host:port/path?key=value&key=value）

• 第一步是检测配置，如果有些配置空的话会默认创建，并且组装成 URL 。
• 第二步是暴露服务，包括暴露到本地的服务和远程的服务。
• 第三步是注册服务至注册中心。

首先消费者启动会向注册中心拉取服务提供者的元信息，然后调用流程也是从 Proxy 开始，毕竟都需要代理才能无感知。

Proxy 持有一个 Invoker 对象，调用 invoke 之后需要通过 Cluster 先从 Directory 获取所有可调用的远程服务的 Invoker 列表，如果配置了某些路由规则，比如某个接口只能调用某个节点的那就再过滤一遍 Invoker 列表。

剩下的 Invoker 再通过 LoadBalance 做负载均衡选取一个。然后再经过 Filter 做一些统计什么的，再通过 Client 做数据传输，比如用 Netty 来传输。

传输需要经过 Codec 接口做协议构造，再序列化。最终发往对应的服务提供者。

服务提供者接收到之后也会进行 Codec 协议处理，然后反序列化后将请求扔到线程池处理。某个线程会根据请求找到对应的 Exporter ，而找到 Exporter 其实就是找到了 Invoker，但是还会有一层层 Filter，经过一层层过滤链之后最终调用实现类然后原路返回结果。