很多朋友对于掌握Dubbo轻轻松松应对微服务面试和不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！

Dubbo起源于阿里巴巴。对于我们这些从事电子商务开发的人来说，基本上是首选技术。那么为什么单纯的SOA服务治理框架会受到这么多人的青睐呢？

今天，我们就跟随小宇来看看微服务框架之一的Dubbo的详细讲解。

前言

随着互联网的不断发展，网站应用规模不断扩大，传统的垂直应用架构已经无法应对。

随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖也越来越复杂。面向服务的架构（SOA）诞生了。

由此衍生出一系列相应的技术，例如封装服务提供、服务调用、连接处理、通信协议、序列化方法、服务发现、服务路由、日志输出等行为的服务框架。

这样，分布式系统的服务治理框架就出现了，Dubbo诞生了。

概念

Dubbo是一个高性能、轻量级的开源RPC框架，提供自动服务注册、自动发现等高效的治理解决方案，并且可以与Spring框架无缝集成。

简单来说，dubbo是一个分布式服务框架。当需要分发的时候可以使用dubbo的框架。使用dubbo的好处是：

1.透明的远程方法调用

2、软负载均衡和容错机制

3.自动服务注册和发现

4.提供完善的服务接口管理和监控功能

架构图

RPC

简介

RPC的全称是Remote procedure call，即远程过程调用。例如，有两台服务器A和B。服务器A上部署了一个应用程序，服务器B上部署了一个应用程序。服务器A上的应用程序想要调用服务器B上的应用程序提供的方法。由于这两个应用程序是不在同一内存空间，不能直接调用。所以表达调用的语义和传达调用的数据。RPC需要通过网络传递。它不是具体的技术，而是指整个网络远程调用过程。

RPC是一个通用的概念。严格来说，所有的远程过程调用方法都属于RPC的范畴。各种开发语言都有自己的RPC框架。 Java中有很多RPC框架，应用广泛的有RMI、Hessian、Dubbo等。

原理

服务消费者（客户端）以本地调用方式调用服务。收到调用后，客户端存根负责将方法、参数等编码成可以通过网络传输的消息体。然后，客户端存根找到服务地址后，将消息发送到服务器。

当服务提供者（服务器）收到序列化消息时，它会对该消息进行解码。然后根据解码结果调用本地服务。执行完成后，将结果打包发送给消费者。

服务消费者收到执行结果后，也进行解码，得到结果。

原则

使用场景

RPC 分布式服务，拆分应用进行服务，提高开发效率，优化性能，节省竞争资源

配置管理，解决服务地址信息激增、配置困难的问题

服务依赖，解决服务之间复杂依赖问题

服务扩容，解决随着访问量不断增加而动态扩展服务商机器的问题。

核心功能

Remoting：远程通信，提供各种NIO框架的抽象封装，包括“同步到异步”和“请求-响应”模式的信息交换方式。

Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡、容错、地址路由、动态配置等集群支持。

Registry：服务注册中心，自动服务发现： 基于注册中心目录服务，服务消费者可以动态搜索服务提供者，使地址透明化，让服务提供者可以平滑地增减机器。

核心组件

Provider：服务商

Consumer：调用远程服务的服务消费者

Registry：服务注册与发现的注册中心

Monitor：监控中心，统计服务呼叫次数和呼叫时间

Container：服务运行容器

成分

服务注册与发现

流程如下：

1.Provider绑定指定端口并启动服务

2、捐赠者连接注册中心，将本地IP、端口、应用信息和服务信息发送到注册中心保存。

3、消费者，连接注册中心，向注册中心发送申请信息和请求的服务信息

4、注册中心根据消费者请求的服务信息匹配对应的提供者列表，并发送给Consumer应用缓存。

5、Consumer发起远程调用时，选择缓存的消费者列表之一发起调用。

6、Provider状态变化会实时通知注册中心，并从注册中心实时推送到Consumer设计：

Consumer和Provider解耦，双方都可以水平增加或减少节点数量。注册中心本身可以是一个对等集群，并且可以动态添加或删除节点。如果任何一个失败，它会自动切换到另一个。

7. 权力下放。双方不直接依赖注册中心。即使注册中心短时间内完全宕机，也不会影响服务的调用。

8. 服务提供者是无国籍的。如果其中任何一个出现故障，都不影响使用。

过程

服务治理

治理原因

Dubbo 服务治理的主要原因：

1. 服务URL过多，配置困难。

2、当负载均衡分配节点压力过大时，也需要部署集群。

3、服务依赖关系混乱，启动顺序不清楚。

4. 服务太多，难以分析性能指标，需要监控。

主要特性

透明远程调用：像调用本地方法一样调用远程方法；只需简单配置，无API侵入

负载均衡机制：客户端LB，可以替代内网F5等硬件负载均衡器

容错重试机制：Service Mock数据、重试次数、超时机制等。

自动注册发现：注册中心根据接口名称查询服务商IP地址，可以平滑添加或删除服务商

性能日志监控：监控中心统计服务调用次数及调用时间

服务治理中心：路由规则、动态配置、服务降级、访问控制、权重调整、负载均衡等手动配置

自动治理中心：无，如：断路器限流机制、自动权重调整等（所以可以用Spring Cloud的断路器机制等进行开发）

服务治理

架构设计

整体架构

我们看一下Dubbo的整体架构图：

图例说明：

整体架构

图中，左侧浅蓝色背景为服务消费者使用的接口，右侧浅绿色背景为服务提供者使用的接口，中轴上的接口为双方使用的接口。

人物从下到上分为十层。每一层都具有单向依赖性。右边的黑色箭头代表层与层之间的依赖关系。每层都可以从上层剥离并重复使用。其中Service层和Config层都是API。所有其他层都是SPI。

图中绿色块是扩展接口，蓝色块是实现类。图中仅显示了用于关联各层的实现类。

图中蓝色虚线是初始化过程，即启动时的汇编链，红色实线是方法调用过程，即运行时时序链，紫色三角箭头是继承。子类可以看成是父类的同一个节点。上面的文字就是调用的方法。

各层说明

config 配置层：外部配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接初始化配置类，也可以通过spring解析配置生成配置类。

proxy 服务代理层：服务接口透明代理，生成服务的客户端Stub和服务端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory

registry 注册中心层：封装了服务地址的注册和发现，以服务URL为中心，扩展接口有RegistryFactory、Registry、RegistryService

cluster 路由层：封装多个Provider的路由和负载均衡，桥接注册中心，以Invoker为中心，扩展接口有Cluster、Directory、Router、LoadBalance

monitor 监控层：RPC调用次数和调用时间监控，以统计为中心，扩展接口有MonitorFactory、Monitor、MonitorService

protocol 远程调用层：封装RPC调用，以Invoking和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-公共公共逻辑模块，包括Util类和公共模型。

dubbo-remoting远程通信模块，相当于Dubbo协议的实现。如果RPC使用RMI协议，则不需要使用此包。

dubbo-rpc远程调用模块抽象了各种协议和动态代理。它只包含一对一的调用，不关心集群管理。

dubbo-cluster集群模块将多个服务提供者伪装成一个提供者，包括：负载均衡、容错、路由等。集群的地址列表可以静态配置，也可以由注册中心下发。

dubbo-registry 注册中心模块，基于注册中心发布的地址的聚类方法，对各个注册中心进行抽象。

dubbo-monitor监控模块，统计服务调用次数、调用时间、调用链跟踪服务。

dubbo-config配置模块是Dubbo的对外API。用户通过Config来使用Dubbo，隐藏Dubbo的所有细节。

dubbo-container 容器模块是一个独立容器，通过使用简单的Main 加载Spring 来启动。由于服务通常不需要Tomcat/JBoss等Web容器的功能，因此不需要使用Web容器来加载服务。

主要模块

调用方式

异步调用

基于NIO非阻塞实现并行调用，客户端不需要启动多个线程即可完成对多个远程服务的并行调用，多线程的开销也比较小。

异步调用

本地调用

使用Injvm协议，这是一个伪协议。它不开放端口，不发起远程调用，仅在JVM内部直接关联，但执行Dubbo的Filter链。

定义injvm协议：

dubbo:protocolname='injvm'/设置默认协议：

dubbo:providerprotocol='injvm'/设置服务协议：

dubbo:serviceprotocol='injvm'/

dubbo:consumerinjvm='true'./dubbo:providerinjvm='true'./或dubbo:referenceinjvm='true'./dubbo:serviceinjvm='true'./

容错机制

调用流程

1. Cluster将Directory中的多个Invoker伪装成一个Invoker，对上层透明。伪装过程包括容错逻辑。

2、Router负责根据路由规则从多个Invoker中选择子集，如读写分离、应用隔离等。

3. LoadBalance 负责从多个Invoker 中选择一个特定的Invoker 进行本次调用。选择过程包括负载均衡算法。

调用流程

容错策略

Dubbo官网一共提出了六种容错策略

1.故障转移集群

故障自动切换。出现故障时，请在其他服务器上重试。 （默认）

2. 故障快速集群

快速失败，只调用一次，失败立即报错。通常用于非幂等写操作，例如添加新记录。

3. 故障安全集群

故障安全，如果发生异常，将被忽略。通常用于写入审计日志等操作。

4.故障恢复集群

自动从故障中恢复，在后台记录失败的请求，并定期重新发送。通常用于消息通知操作。

5. 分叉集群

并行调用多个服务器，一旦成功就返回。通常用于实时性要求较高的读操作，但需要消耗较多的服务资源。

最大并行数可以通过forks="2" 设置。

6. 广播集群

广播一一呼叫所有提供商。如果其中任何一个报错，就会报错。 （从2.1.0开始支持）通常用于通知所有提供者更新本地资源信息，例如缓存或日志。

总结：实际应用中，查询语句容错策略建议使用默认的Failover Cluster，增删改查建议使用Failfast Cluster或Failover Cluster（retries=0）策略，防止重复添加数据等问题！建议设计接口有时会将查询接口方法做成一个单独的接口来提供查询。

连接方式

Dubbo的客户端和服务端有三种连接方式，分别是：广播、直连和使用Zookeeper注册中心。

Dubbo 广播

该方法是dubbo官方入门程序使用的连接方法。然而，这种方法存在很多问题。企业开发中不使用广播。

服务器配置：

!--配置dubbo--!--提供应用信息，用于计算依赖关系--dubbo:applicationname='demo-service'/!--使用组播广播注册暴露服务地址--dubbo:registryaddress='multicast://192.168.9.4:88888' /!--使用dubbo协议暴露20880端口服务--dubbo:protocolname='dubbo'port='20880'/dubbo:serviceinterface='com.demo.manger.service.TestService'ref='testServiceImpl'/客户端配置：

!--与dubbo配合--!--提供应用信息，用于计算依赖关系--dubbo:applicationname='demo-web'/!--使用组播广播注册中心暴露服务地址--dubbo:registryaddress='multicast://19.188 。 8.9:8888'/dubbo:referenceinterface='com.demo.manager.service.TestService'id='testService'timeout='1000000'/

Dubbo 直连

这种方法一般用于企业的开发环境，很少用于生产环境。由于直接调用服务，没有使用注册中心，因此很难管理服务。对于Dubbo直连，必须先取消广播，然后客户端才能直接去指定服务的URL获取服务。

服务器配置：

!--配置dubbo--!--提供应用信息，用于计算依赖关系--dubbo:applicationname='demo-service'/!--使用组播广播注册暴露服务地址----dubbo:registryaddress='multicast://192.168 。 9.4:88888'/--dubbo:registryadress='N/A'!--使用dubbo协议暴露20880端口服务--dubbo:protocolname='dubbo'port='20880'/dubbo:serviceinterface='com.demo.manger.service.TestService' ref='testServiceImpl'/

客户端配置：

!--与dubbo配合--!--提供应用信息用于计算依赖关系--dubbo:applicationname='demo-web'/!--使用组播广播注册中心暴露服务地址----dubbo:registryaddress='multicast://19.188.8.9:8888'/--dubbo:referenceinterface='com.demo.manager.service.TestService'id='testService'timeout='1000000'url='dubbo://127.0.0.1:20880'/

zookeeper 注册中心

Dubbo注册中心与广播注册中心配置类似，但需要指定注册中心类型和注册中心地址。此时，服务信息并不广播，而是告知注册中心进行管理。这时候我们就需要有一个注册中心。官方推荐使用zookeeper作为注册中心。

动物园管理员注册中心

服务器配置：

!--配置dubbo--!--提供应用信息，用于计算依赖关系--dubbo:applicationname='demo-service'/!--使用组播广播注册暴露服务地址--!--dubbo:registryaddress='multicast://192.168 .9.4:88888'/--!--dubbo:registryadress='N/A'--dubbo:registryprotocol='zookeeper'address='192.168.37,136:2181'!--使用dubbo协议暴露20880端口服务--dubbo33 360protocol名称=' dubbo 'port='20880'/dubbo:serviceinterface='com.demo.manger.service.TestService'ref='testServiceImpl'/客户端配置：

!--与dubbo配合--!--提供应用信息用于计算依赖关系--dubbo:applicationname='demo-web'/!--使用组播广播注册中心暴露服务地址----dubbo:registryaddress='multicast://19.188.8.9:8888'/--dubbo:registryprotocol='zookeeper'address='192.168.37.1336:2181'/dubbo:referenceinterface='com.demo.manager.service.TestService'id='testService'timeout='1000000'/

策略

负载均衡策略

1.Random LoadBalance，随机（默认负载均衡策略）

RandomLoadBalance是加权随机算法的具体实现。可以完全随机，也可以根据权重设置随机概率。

。 2、RoundRobin LoadBalance，轮循 可以轮询和加权轮询。存在响应慢的提供者会累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。 3、LeastActive LoadBalance，最少活跃调用数 活跃调用数越小，表明该服务提供者效率越高，单位时间内可处理更多的请求。此时应优先将请求分配给该服务提供者。 4、ConsistentHash LoadBalance，一致性 Hash 一致性 Hash 算法，相同参数的请求一定分发到一个 provider 上去。provider 挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。

集群容错策略

1、failover cluster(默认) 失败自动切换，调用失败时，自动重试其他机器。通常用于读操作，但重试会带来更长延迟。 2、Failfast Cluster 快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。 3、Failsafe Cluster

失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。 4、Failback Cluster 失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。 5、Forking Cluster 并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。

动态代理策略

默认使用 javassist 动态字节码生成，创建代理类。也可以通过 spi 扩展机制配置自己的动态代理策略。

集群容错方案

配置说明，方案配置方式，优先使用消费端配置<!--服务端配置--> <dubbo:service cluster="failover"/> <!--消费端配置--> <dubbo:reference cluster="failover"/> 尽量在只在服务端进行配置cluster类型均为小写默认为FailoverCluster失败切换方案

集群容错方案support

FailoverCluster(默认)：失败切换 场景：调用失败后切换其他服务 配置： <!-- retries:重试次数，不包括第一次，默认2次 --> <dubbo:service cluster="failover" retries="3"/> 代码实现逻辑： 1. 根据负载均衡策略选出需要调用的服务实例，排除已调用的 2. 执行选出的实例，并将其保存到已调用列表中 3. 执行实例成功即返回 4. 执行实例不成功，为到最大重试次数则执行第一步，否则抛出RpcException异常

FailbackCluster：失败重试

场景：调用失败时记录失败请求，定时重发 配置： <!-- retries:重试次数，不包括第一次，默认3次 failbacktasks:定时器中最大挂起任务数，默认100 --> <dubbo:service cluster="failback" retries="5" failbacktasks="200"/> 代码实现逻辑 1. 根据负载均衡策略选出需要调用的服务实例 2. 执行选出的实例 3. 执行实例成功即返回 4. 执行异常则创建延时5秒的定时任务，并加入时间轮定时器，第一次需要进行定时器初始化，分为32个时间片，每1秒滚动一次，最大挂起任务默认100个，超出最大任务数时抛出RejectedExecutionException异常。 5. 重试执行定时任务，次数超出最大执行次数停止，并输出error日志，默认为3次。

FailfastCluster：快速失败

场景：调用失败立即报错 配置： <dubbo:service cluster="failfast"/> 代码实现逻辑 1. 根据负载均衡策略选出需要调用的服务实例 2. 执行选出的实例 3. 执行实例成功即返回，失败抛出RpcException异常

FailsafeCluster：安全失败

场景：调用失败后忽略 配置： <dubbo:service cluster="failsafe"/> 代码实现逻辑 1. 根据负载均衡策略选出需要调用的服务实例 2. 执行选出的实例 3. 执行实例成功即返回，失败输出error日志，并返RpcResult，视为忽略。

ForkingCluster：并发处理

场景：并发调用指定数量的服务，一个成功则返回，对实时性要求高的场景，要求快速返回，需要使用更多服务器资源。 配置： <!-- forks:最大并发数,默认2 timeout:并发返回超时时间，默认1000ms --> <dubbo:service cluster="forking" forks="3" timeout="500"/> 代码实现逻辑 1. 根据负载均衡策略选出几个不同的服务实例 2. 并发执行选出的几个实例，并将返回结果放入堵塞队列中 3. 返回堵塞队列中的第一个值，如规定时间内未获取到队列中的值或获取到异常值则返回RPC异常。

BroadcastCluster：广播

场景：广播方式逐个调用服务提供者，有一个报错则返回错误，多用于通知服务提供者更新本地资源信息，如缓存，日志等。 配置： <dubbo:service cluster="broadcast"/> 代码实现逻辑 1. 循环逐个执行所有服务实例信息 2. 保存一份返回结果和异常信息 3. 执行完全部实例后，如异常信息不为空，则抛出异常信息，否则返回最后一个实例的结果。

AvailableCluster：可用服务

场景：调用第一个可用服务 配置： <dubbo:service cluster="available"/> 代码实现逻辑 1. 循环所有服务实例信息 2. 执行第一个可用的实例，并返回结果 3. 如无可用实例则返回RpcException异常

MergeableCluster：合并处理

场景：返回合并或叠加处理结果 配置： <!-- merger:合并发放名 timeout:调用服务超时时间，默认1000ms --> <dubbo:service cluster="mergeable" merger="true" timeout="500"/> 代码实现逻辑 1. 判断merger，为空、null、0、false、N/A是执行第一个可用服务并返回结果，无可用则执行第一个实例，并返回结果。 2. 获取方法实例的返回类型 3. 异步调用所有实例，并将异步结果Result存储到结果集中，返回异常输出error日志 4. 结果集为空返回 RpcException，大小为 1时返回第一个Result 5. 当merger的第一个字符为“.”时，判断当 merger 实例返回类型不为void,且返回类型必须是结果集中第一个返回类型的父类型或相同类型时，循环执行merger实例，每一次都传入上一次的返回结果，最终返回获取最后一次结果，非上述情况时循环执行merger实例，返回结果集中的第一个结果。 6. 当merger为true或default时使用Dubbo默认合并器，否则使用自定义merger合并器，合并后返回

RegistryAwareCluster:默认标识、注册标识

场景：调用注册默认标识的服务 配置： <!-- default:默认标识 --> <dubbo:registry address="zookeeper://xxx..." default="true"/> <dubbo:service cluster="registryaware"/> 代码实现逻辑 1.8 循环所有服务实例信息 2. 执行第一个可用的实例且default为true的实例 3. 无默认实例则执行第一个可用的实例 4. 无可用的实例则抛出RpcException异常

主要配置

配置应用信息： <dubbo:application name=“appName-provider” /> 配置注册中心相关信息： <dubbo:registryid=“zk” protocol=“zookeeper” address=“127.0.0.1:2181” /> 配置服务协议： <dubbo:protocol name=“dubbo” port=“20880” threadpool=“cached” threads=“80” /> 配置所有暴露服务缺省值： <dubbo:provider registry=“zk” protocol=“dubbo” retries=“0” version=“1.0.0” timeout=“3000” threadpool=“cached” threads=“4”/> 配置暴露服务： <dubbo:service interface=“com.orgname.app.serviceX” ref=“serviceX” /> 配置所有引用服务缺省值： <dubbo:consumer check=“false” timeout=“1000” version=“1.0” retries=“0” async=“false” /> 注解配置： com.alibaba.dubbo.config.annotation.Service 配置暴露服务  com.alibaba.dubbo.config.annotation.Reference配置引用服务 

超时设置

Dubbo消费端

全局超时配置 <dubbo:consumer timeout="5000" /> 指定接口以及特定方法超时配置 <dubbo:reference interface="com.foo.BarService" timeout="2000">     <dubbo:method name="sayHello" timeout="3000" /> </dubbo:reference> 

Dubbo服务端

全局超时配置 <dubbo:provider timeout="5000" /> 指定接口以及特定方法超时配置 <dubbo:provider interface="com.foo.BarService" timeout="2000">     <dubbo:method name="sayHello" timeout="3000" /> </dubbo:provider> 

支持协议

1、Dubbo 协议(官方推荐协议) 优点：采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好(推荐使用) 缺点：大文件上传时,可能出现问题(不使用 Dubbo 文件上传) 2、RMI(Remote Method Invocation)协议 优点:JDK 自带的能力。可与原生 RMI 互操作，基于 TCP 协议 缺点:偶尔连接失败. 3、Hessian协议 优点:可与原生 Hessian 互操作，基于 HTTP 协议 缺点:需 hessian.jar 支持，http 短连接的*开销大8

常用设计模式

Dubbo 框架在初始化和通信过程中使用了多种设计模式，可灵活控制类加载、权限控制等功能。

工厂模式

Provider 在 export 服务时，会调用 ServiceConfig 的 export 方法。ServiceConfig 中有个字段： private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension(); Dubbo 里有很多这种代码。这也是一种工厂模式，只是实现类的获取采用了 JDK SPI 的机制。这么实现的优点是可扩展性强，想要扩展实现，只需要在 classpath下增加个文件就可以了，代码零侵入。另外，像上面的 Adaptive 实现，可以做到调用时动态决定调用哪个实现，但是由于这种实现采用了动态代理，会造成代码调试比较麻烦，需要分析出实际调用的实现类。

装饰器模式

Dubbo 在启动和调用阶段都大量使用了装饰器模式。以 Provider 提供的调用链为例，具体的调用链代码是在 ProtocolFilterWrapper 的buildInvokerChain 完成的，具体是将注解中含有 group=provider 的 Filter 实现，按照 order 排序，最后的调用顺序是： EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter -> ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter -> ExceptionFilter 更确切地说，这里是装饰器和责任链模式的混合使用。例如，EchoFilter 的作用是判断是否是回声测试请求，是的话直接返回内容，这是一种责任链的体现。而像ClassLoaderFilter 则只是在主功能上添加了功能，更改当前线程的 ClassLoader，这是典型的装饰器模式。

观察者模式

Dubbo 的 Provider 启动时，需要与注册中心交互，先注册自己的服务，再订阅自己的服务，订阅时，采用了观察者模式，开启一个 listener。注册中心会每 5 秒定时检查是否有服务更新，如果有更新，向该服务的提供者发送一个 notify 消息，provider 接受到 notify 消息后，即运行 NotifyListener 的 notify 方法，执行监听器方法。

动态代理模式

Dubbo 扩展 JDK SPI 的类 ExtensionLoader 的 Adaptive 实现是典型的动态代理实现。Dubbo 需要灵活地控制实现类，即在调用阶段动态地根据参数决定调用哪个实现类，所以采用先生成代理类的方法，能够做到灵活的调用。生成代理类的代码是 ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理类的主要逻辑是，获取 URL 参数中指定参数的值作为获取实现类的 key

工作流程

整体流程： 第一步：provider 向注册中心去注册 第二步：consumer 从注册中心订阅服务，注册中心会通知 consumer 注册好的服务 第三步：consumer 调用 provider 第四步：consumer 和 provider 都异步通知监控中心流程图

总结

最后用一张图来形象的模拟 Dubbo 的使用：使用 以上只是我总结的一些关于 dubbo 最基础的原理及使用介绍，至于代码编写过程的 bug 处理经验，环境搭建、项目布局等等问题，需要我们在平时开发中，将系统知识与实战经验相结合去总结，这样才能真正的去掌握这项技术点。 Dubbo 目前是我用到过的最多的分布式框架，写出来的内容也是最多的，不过由于Dubbo用的太多，而 SpringCloud 难度比 Dubbo 要小很多，现在大部分项目都即将开始转投到了 SpringCloud 上面，后面也会出更多的 SpringCloud 相关的文章。

用户评论

寒山远黛

感觉Dubbo真的很关键啊，想要参加微服务的岗位，肯定得把Dubbo弄清楚

    有17位网友表示赞同！

仅有的余温

我之前也准备面试的时候，一直觉得微服务有点绕，后来知道要搞懂Dubbo才行！

    有13位网友表示赞同！

坏小子不坏

这篇博客讲得很详细，正好可以来複习一下Dubbo的使用场景

    有17位网友表示赞同！

铁树不曾开花

想要在微服务这条路上走得更远，Dubbo确实是一个很好的入门点

    有5位网友表示赞同！

红尘滚滚

面试时遇到 Dubbo 的问题也不愁了，看看这篇文章总能找到答案

    有12位网友表示赞同！

歆久

最近准备学习Dubbo，这篇博客来得非常时候！

    有16位网友表示赞同！

墨城烟柳

我以前对微服务不太了解，看了这个标题感觉很有收获

    有14位网友表示赞同！

如梦初醒

Dubbo 用得越多越觉得简单，这次面试应该能考过啦!

    有13位网友表示赞同！

男神大妈

微服务领域真的很火，学习 Dubbo 是个好的选择

    有13位网友表示赞同！

＊巴黎铁塔

想搞清楚微服务的底层架构，那就必须把Dubbo搞懂！

    有11位网友表示赞同！

拉扯

原来Dubbo这么详细？这篇文章真是让我更加了解了它

    有20位网友表示赞同！

厌归人

看来Dubbo是微服务面试的必考项啊！真得好好学习一下

    有12位网友表示赞同！

走过海棠暮

想要找到一份好工作，掌握Dubbo确实很重要

    有10位网友表示赞同！

米兰

这个博客看起来很不错，可以用来总结Dubbo的基本知识点

    有19位网友表示赞同！

满心狼藉

Dubbo真的很实用啊，很多项目都用到它!

    有9位网友表示赞同！

孤廖

这篇文章应该能帮助我更好地理解Dubbo的工作原理

    有8位网友表示赞同！

念旧情i

在微服务领域竞争越来越激烈，掌握像Dubbo这样的核心技术才能脱颖而出

    有18位网友表示赞同！

微信名字

面试的时候遇到 Dubbo 的问题可要好好准备了！

    有19位网友表示赞同！