共计 3030 个字符，预计需要花费 8 分钟才能阅读完成。
1. 架构
dubbo 架构波及的角色：
节点
角色阐明
Provider
裸露服务的服务提供方
Consumer
调用近程服务的服务生产方
Registry
服务注册与发现的注册核心
Monitor
统计服务的调用次数和调用工夫的监控核心
Container
服务运行容器
2. 配置加载流程
Dubbo 配置形式有 XML 配置、注解配置、API 配置。反对多层级配置，依照优先级配置笼罩。
3.dubbo 相干重要点
3.1 负载平衡
负载平衡策略有：
- 按权随机
- 按权轮询
- 起码沉闷调用数：沉闷数指调用前后技术差
- 始终性 hash：缺省，对第一个参数做 hash，缺省用 160 分虚构节点
3.2 线程模型
3.3 服务分组
一个接口有多种实现时，应用 group 辨别。
3.4 接口测试留神点
(1) 直连提供者
在开发测试环境下，可能存在绕过注册核心的状况下，测试某个服务提供者，这时须要点对点直连。能够有如下形式：
- xml 配置：<dubbo:reference id=”xxxService” interface=”com.alibaba.xxx.XxxService”
url=”dubbo://localhost:8080″ />
- 指定 - D 参数：java -Dcom.alibaba.xxx.XxxService=dubbo://localhost:8080
- 文件映射：用 -Ddubbo.resolve.file 指定映射文件门路
(2) 只订阅
不便开发测试，可能存在共用注册核心的状况，防止正开发的服务提供者影响服务消费者，能够让服务提供这只订阅服务 (开发的服务可能依赖其余的服务)，通过直连形式测试。
3.5 异步调用
v2.7.0 起，dubbo 的异步编程接口以 CompletableFuture 为根底，基于 NIO 的非阻塞实现，不须要启动多线程，绝对多线程开销小。
3.6 多协定
dubbo 反对在不同服务上反对多个协定或者同一个服务上同时反对多个协定。
反对的协定有 dubbo、rmi、hessian、http、webservice、thrift、memcached、redis、rest
3.7 本地存根
近程服务调用后，客户端个别是接口，实现在服务端，提供方想在客户端提供局部执行逻辑如 ThreadLocal 缓存，提前验证参数，嗲用失败后伪造容错数据，须要在 api 带上 stub。
3.8 并发管制
能够限度每个办法服务端并发执行的个数，设置 executes 属性
3.9 连贯管制
限度服务端的连贯个数，设置 accepts 属性值
3.10 提早连贯
提早连贯用户缩小长连接数。有调用的时候才创立，设置 lazy 属性。
3.11 粘滞连贯
个别用户有状态的服务，使客户端总是向调用同一个服务提供者，设置 sticky 属性。
3.12 令牌验证
令牌验证注册核心受权权限，可避免消费者绕过注册核心拜访提供者，设置 token 属性。
3.13 集群容错
在集群调用失败时，Dubbo 提供了多种容错机制，缺省为 failover 重试。容错机制有:
- failover: 失败主动切换，重试其余服务器，通过设置 retries 属性 (不蕴含第一次)
- failfast：疾速失败，只发动一次调用。
- failsafe：失败平安，出现异常间接疏忽。
- failback：失败主动复原，后盾记录失败申请，定时重发。
- forking：并行调用多服务器，一个胜利即返回，通过设置 forks 属性。
4.dubbo 我的项目搭建
4.1 应用 idea 创立一个 spring boot kotlin 我的项目
(1) 点击菜单 File->new Project->Spring Initializr->next
(2) 抉择 kotlin 依照提醒流程创立集体我的项目
(3) 依照下面流程创立一个父我的项目，保留 pom 文件、.idea 文件，删除无关文件，而后 new module 增加模块
以上步骤就创立一个基于 dubbo 的 spring boot kotlin 多模块我的项目。
4.4 代码实现
基于接口开发，基于注解模式，不实用 xml，spring boot 提倡约定大于配置
- 对于接口的提供方，应用注解 @Service
- 对于接口的调用发应用 @Reference
- 裸露的接口对立放在一个治理 api 的子模块
- 须要用到接口时，在 pom 文件引入模块
如上面例子所示：
<dependency>
<groupId>com.xhh</groupId>
<artifactId>xhh-practice-api</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
4.5 可能会遇到的问题
(1) @Reference 空援用问题
- 集体一开始未应用 zookeeper 注册核心，采纳接口直连形式，须要在注解中设置好 url 属性，留神应用 dubbo 协定结尾如：dubbo：//。没有启动时不报错，接口调用发现失败，最终发现时配置不全导致的空援用问题
- 应用 zookeeper 注册核心时，本地曾经搭建好 zookeeper，须要配置的子模块也配置了 zookeeper 地址，启动我的项目时，工夫距离打印连贯 zookeeper 信息，调用接口时，提醒接口未注入实例。起初认为 @Reference 和 @Service 的注解短少相干属性，例如版本，check、接口对象等，最初发现不是这个问题，发现子模块都还未胜利注册到 zookeeper，依赖配置还短少一个 zookeeper 包，所以无奈取得另外一个服务的接口代理对象，引入上面配置即可：
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
</dependency>以上这些依赖包次要是实现在 zookeeper 原生 API 的根底上进行封装、实现一些开发细节，包含接连重连、注册等。
5.dubbo 框架原理
5.1 SPI 机制
服务发现机制。SPI 的实质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，运行时加载实现类，动静为接口替换实现类。原生 JDK 规范 SPI 只能通过遍历查找拓展点和实例化，存在一次性加载所有拓展点的状况导致资源节约，dubbo SPI 机制解决了这个问题。
(1) 注解 @SPI
示意该接口为可拓展接口。以上面阐明为例子：
@SPI(“netty”)
public interface Transporter {
@Adaptive({“server”, “transporter”})
Server bind(URL var1, ChannelHandler var2) throws RemotingException;
@Adaptive({“client”, “transporter”})
Client connect(URL var1, ChannelHandler var2) throws RemotingException;
}
@SPI 中的属性值，示意获取配置中 key，会获取这个 key 对应的值，对应的值就是对应的实现类。
