关注后回复 “进群” ，拉你进程序员交流群
大家好，今天是分享 Dubbo 知识点/面试题总结的 Guide！
这篇文章是我根据官方文档以及自己平时的使用情况，对 Dubbo 所做的一个总结。
文章内容有一点长，一次看不完的话，记得收藏起来，找时间再看！
服务消费端（client）以本地调用的方式调用远程服务；
客户端 Stub（client stub） 接收到调用后负责将方法、参数等组装成能够进行 络传输的消息体（序列化）：；
客户端 Stub（client stub） 找到远程服务的地址，并将消息发送到服务提供端；
服务端 Stub（桩）收到消息将消息反序列化为 Java 对象: ；
服务端 Stub（桩）根据中的类、方法、方法参数等信息调用本地的方法；
服务端 Stub（桩）得到方法执行结果并将组装成能够进行 络传输的消息体：（序列化）发送至消费方；
客户端 Stub（client stub）接收到消息并将消息反序列化为 Java 对象: ，这样也就得到了最终结果。over!
相信小伙伴们看完上面的讲解之后，已经了解了 RPC 的原理。
虽然篇幅不多，但是基本把 RPC 框架的核心原理讲清楚了！另外，对于上面的技术细节，我会在后面的章节介绍到。
最后，对于 RPC 的原理，希望小伙伴不单单要理解，还要能够自己画出来并且能够给别人讲出来。因为，在面试中这个问题在面试官问到 RPC 相关内容的时候基本都会碰到。
Dubbo 基础
简单来说就是：Dubbo 不光可以帮助我们调用远程服务，还提供了一些其他开箱即用的功能比如智能负载均衡。
Dubbo 目前已经有接近 34.4 k 的 Star 。
在 2020 年度 OSC 中国开源项目 评选活动中，Dubbo 位列开发框架和基础组件类项目的第 7 名。想比几年前来说，热度和排名有所下降。
另外，Dubbo 除了能够应用在分布式系统中，也可以应用在现在比较火的微服务系统中。不过，由于 Spring Cloud 在微服务中应用更加广泛，所以，我觉得一般我们提 Dubbo 的话，大部分是分布式系统的情况。
我们刚刚提到了分布式这个概念，下面再给大家介绍一下什么是分布式什么要分布式/strong>
分布式基础
什么是分布式/h3>
分布式或者说 SOA 分布式重要的就是面向服务，说简单的分布式就是我们把整个系统拆分成不同的服务然后将这些服务放在不同的服务器上减轻单体服务的压力提高并发量和性能。比如电商系统可以简单地拆分成订单系统、商品系统、登录系统等等，拆分之后的每个服务可以部署在不同的机器上，如果某一个服务的访问量比较大的话也可以将这个服务同时部署在多台机器上。
-
Container： 服务运行容器，负责加载、运行服务提供者。必须。
-
Provider： 暴露服务的服务提供方，会向注册中心注册自己提供的服务。必须。
-
Consumer： 调用远程服务的服务消费方，会向注册中心订阅自己所需的服务。必须。
-
Registry： 服务注册与发现的注册中心。注册中心会返回服务提供者地址列表给消费者。非必须。
-
Monitor： 统计服务的调用次数和调用时间的监控中心。服务消费者和提供者会定时发送统计数据到监控中心。非必须。
Dubbo 中的 Invoker 概念了解么/h3>
是 Dubbo 领域模型中非常重要的一个概念，你如果阅读过 Dubbo 源码的话，你会无数次看到这玩意。就比如下面我要说的负载均衡这块的源码中就有大量 的身影。
简单来说， 就是 Dubbo 对远程调用的抽象。
config 配置层：Dubbo 相关的配置。支持代码配置，同时也支持基于 Spring 来做配置，以 , 为中心
proxy 服务代理层：调用远程方法像调用本地的方法一样简单的一个关键，真实调用过程依赖代理类，以 为中心。
registry 注册中心层：封装服务地址的注册与发现。
cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 为中心。
monitor 监控层：RPC 调用次数和调用时间监控，以 为中心。
protocol 远程调用层：封装 RPC 调用，以 , 为中心。
exchange 信息交换层：封装请求响应模式，同步转异步，以 , 为中心。
transport 络传输层：抽象 mina 和 netty 为统一接口，以 为中心。
serialize 数据序列化层 ：对需要在 络传输的数据进行序列化。
Dubbo 的 SPI 机制了解么何扩展 Dubbo 中的默认实现/h3>
SPI（Service Provider Interface） 机制被大量用在开源项目中，它可以帮助我们动态寻找服务/功能（比如负载均衡策略）的实现。
SPI 的具体原理是这样的：我们将接口的实现类放在配置文件中，我们在程序运行过程中读取配置文件，通过反射加载实现类。这样，我们可以在运行的时候，动态替换接口的实现类。和 IoC 的解耦思想是类似的。
Java 本身就提供了 SPI 机制的实现。不过，Dubbo 没有直接用，而是对 Java 原生的 SPI 机制进行了增强，以便更好满足自己的需求。
那我们如何扩展 Dubbo 中的默认实现呢/strong>
比如说我们想要实现自己的负载均衡策略，我们创建对应的实现类 实现 接口或者 类。
我们将这个是实现类的路径写入到 目录下的 文件中即可。
其他还有很多可供扩展的选择，你可以在官方文档@SPI 扩展实现这里找到。
核心系统提供系统所需核心能力，插件模块可以扩展系统的功能。因此， 基于微内核架构的系统，非常易于扩展功能。
我们常见的一些 IDE，都可以看作是基于微内核架构设计的。绝大多数 IDE 比如 IDEA、VSCode 都提供了插件来丰富自己的功能。
正是因为 Dubbo 基于微内核架构，才使得我们可以随心所欲替换 Dubbo 的功能点。比如你觉得 Dubbo 的序列化模块实现的不满足自己要求，没关系啊！你自己实现一个序列化模块就好了啊！
通常情况下，微核心都会采用 Factory、IoC、OSGi 等方式管理插件生命周期。Dubbo 不想依赖 Spring 等 IoC 容器，也不想自已造一个小的 IoC 容器（过度设计），因此采用了一种最简单的 Factory 方式管理插件 ：JDK 标准的 SPI 扩展机制 （）。
关于 Dubbo 架构的一些自测小问题
注册中心的作用了解么/h4>
注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互。
服务提供者宕机后，注册中心会做什么/h4>
注册中心会立即推送事件通知消费者。
监控中心的作用呢/h4>
监控中心负责统计各服务调用次数，调用时间等。
注册中心和监控中心都宕机的话，服务都会挂掉吗/h4>
不会。两者都宕机也不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表。注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。
Dubbo 的负载均衡策略
什么是负载均衡/h3>
先来看一下稍微官方点的解释。下面这段话摘自维基百科对负载均衡的定义：
负载均衡改善了跨多个计算资源（例如计算机，计算机集群， 络链接，中央处理单元或磁盘驱动）的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用具有负载平衡而不是单个组件的多个组件可以通过冗余提高可靠性和可用性。负载平衡通常涉及专用软件或硬件。
上面讲的大家可能不太好理解，再用通俗的话给大家说一下。
我们的系统中的某个服务的访问量特别大，我们将这个服务部署在了多台服务器上，当客户端发起请求的时候，多台服务器都可以处理这个请求。那么，如何正确选择处理该请求的服务器就很关键。假如，你就要一台服务器来处理该服务的请求，那该服务部署在多台服务器的意义就不复存在了。负载均衡就是为了避免单个服务器响应同一请求，容易造成服务器宕机、崩溃等问题，我们从负载均衡的这四个字就能明显感受到它的意义。
Dubbo 提供的负载均衡策略有哪些/h3>
在集群负载均衡时，Dubbo 提供了多种均衡策略，默认为 随机调用。我们还可以自行扩展负载均衡策略（参考 Dubbo SPI 机制）。
在 Dubbo 中，所有负载均衡实现类均继承自 ，该类实现了 接口，并封装了一些公共的逻辑。
的实现类有下面这些：
以下源码来自 Dubbo master 分支上的最新的版本 2.7.9。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！