贴一份网上对dubbo的总结，觉得不错，分享一下
DUBBO原理、应用与面经总结
1. 从HSF切到Dubbo
Dubbo比HSF的部署方式更轻量，Hsf需要定制化的容器，而Dubbo没有任何要求，可运行在任何Java环境中。
Dubbo比HSF的扩展性更好，很方便二次开发。
HSF依赖比较多内部系统，比如配置中心，通知中心，监控中心，单点登录等等，如果要开源还需要做很多剥离工作，而Dubbo为每个系统的集成都留出了扩展点，并已梳理干净所有依赖，同时为开源社区提供了替代方案，用户可以直接使用。
Dubbo比HSF的功能更多，除了ClassLoader隔离，Dubbo基本上是HSF的超集，Dubbo也支持更多协议，更多注册中心的集成，以适应更多的网站架构。
2.SPI机制
Java SPI思想梳理
1.看了一些spi机制相关的文章，尝试写出自己的理解，不正确的地方欢迎指出。
java的spi机制，相对于api机制；
api机制：模块之间依赖接口而不依赖具体的实现，具体的实现类的修改不影响接口的使用。而调用方不需要关心接口的具体实现是什么，只需要知道自己需要什么能力即可。
spi机制：提供方制定了接口，并事先准备好多套实现；使用方来决定使用哪种实现。
2 SPI具体约定
java spi的具体约定为:当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。 基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。jdk提供服务实现查找的一个工具类：java.util.ServiceLoader
java.util.ServiceLoader使用
Java.util.ServiceLoader这个类来从配置文件中加载子类或者接口的实现类。以前从来没有使用过这个类，进去大概看了一下具体的实现。主要是从META-INF/services这个目录下的配置文件加载给定接口或者基类的实现，ServiceLoader会根据给定的类的full name来在META-INF/services下面找对应的文件，在这个文件中定义了所有这个类的子类或者接口的实现类，返回一个实例。
首先定义接口
public interface Search {
public List
}
两个实现类
public class DocSearch implements Search {
@Override
public List
System.out.println("dearch in doc");
return null;
}
}
public class DbSearch implements Search {
@Override
public List
System.out.println("db search");
return null;
}
}
然后 在META-INF/services目录下新建文件：
spi.Search
文件内容为：实现类的全路径
#写上Search接口的实现类，这样就可以知道调用哪个实现类了
spi.DocSearch
spi.DbSearch
测试一下：
public class Test {
public static void main(String[] args) {
//加载到spi.Search文件下面配置的实现类
ServiceLoader
Iterator
while (iterator.hasNext()) {
System.out.println("#");
Search search = iterator.next();
search.search("hello world");
}
}
}
3. Dubbo的SPI和JDK的SPI有区别吗？有的话，究竟有什么区别？
Dubbo 的扩展点加载是基于JDK 标准的 SPI 扩展点发现机制增强而来的，Dubbo 改进了 JDK 标准的 SPI 的以下问题：
JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。
增加了对扩展点 IoC 和 AOP 的支持，一个扩展点可以直接 setter 注入其它扩展点。
上文已提供。另外在博客中也单独对此写了一篇《Dubbo内核之SPI机制》、《跟我学Dubbo系列之Java SPI机制简介》
4、Dubbo中SPI也增加了IoC，先讲讲Spring的IoC，然后再讲讲Dubbo里面又是怎么做的
5、Dubbo中SPI也增加了AOP，那你讲讲这用到了什么设计模式，Dubbo又是如何做的.
6.Dubbo原理 :Dubbo角色和设计是怎么样的，原理是怎么样的?请简单谈谈？
image.png
服务提供方发布服务到服务注册中心；
服务消费方从服务注册中心订阅服务；
服务消费方调用已经注册的可用服务
协议支持
Dubbo支持多种协议，如下所示：
Dubbo协议
Hessian协议
HTTP协议
RMI协议
WebService协议
Thrift协议
Memcached协议
Redis协议
在通信过程中，不同的服务等级一般对应着不同的服务质量，那么选择合适的协议便是一件非常重要的事情。你可以根据你应用的创建来选择。例如，使用RMI协议，一般会受到防火墙的限制，所以对于外部与内部进行通信的场景，就不要使用RMI协议，而是基于HTTP协议或者Hessian协议。
7.Dubbo以包结构来组织各个模块，各个模块及其关系：
可以通过Dubbo的代码（使用Maven管理）组织，与上面的模块进行比较。简单说明各个包的情况：
dubbo-common 公共逻辑模块，包括Util类和通用模型。
dubbo-remoting 远程通讯模块，相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。
dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡、容错、路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。
dubbo-config 配置模块，是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。
dubbo-container 容器模块，是一个Standalone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。
7. Dubbo中zookeeper做注册中心，如果注册中心集群都挂掉，发布者和订阅者之间还能通信么？
可以通信的，启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用；
注册中心对等集群，任意一台宕机后，将会切换到另一台；注册中心全部宕机后，服务的提供者和消费者仍能通过本地缓存通讯。服务提供者无状态，任一台 宕机后，不影响使用；服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复；
挂掉是不要紧的，但前提是你没有增加新的服务，如果你要调用新的服务，则是不能办到的。
8.dubbo服务负载均衡策略？
Random LoadBalance
随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。(权重可以在dubbo管控台配置)
RoundRobin LoadBalance
轮循，按公约后的权重设置轮循比率。存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance
一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。缺省只对第一个参数Hash，如果要修改，请配置
9 dubbo源码解析-从spi聊聊双亲委派机制
https://www.jianshu.com/p/99f568df0f05