前置文档
一、dubbo各版本总结与升级建议
-
如果你是新项目建议直接从dubbo3开始构建项目。
-
如果是老项目 Dubbo2.7.x/2.6.x 各版本总结与升级建议
二、dubbo依赖的注册中心zookeeper
2.1 接口级节点结构
在前面的一节中，我们讲解了应用级服务发现与接口级服务发现的区别，在 Zookeeper 实现中，它们的存储结构也存在较大差异。总体来说，Zookeeper 注册中心实现支持以下高可用能力：
- 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
- 当注册中心重启时，能自动恢复注册数据，以及订阅请求
- 当会话过期时，能自动恢复注册数据，以及订阅请求
- 当设置
registry.check=false时，记录失败注册和订阅请求，后台定时重试
流程：
- 服务提供者启动时: 向
/dubbo/com.foo.BarService/providers目录下写入自己的 URL 地址。 - 服务消费者启动时: 订阅
/dubbo/com.foo.BarService/providers目录下的提供者 URL 地址。并向/dubbo/com.foo.BarService/consumers目录下写入自己的 URL 地址 - 监控中心启动时: 订阅
/dubbo/com.foo.BarService目录下的所有提供者和消费者 URL 地址。
可通过 registry.group 设置 zookeeper 的根节点，不配置将使用默认的 /dubbo 根节点。
2.2 应用级节点结构
2.2.1 地址列表
应用级服务发现的地址结构比接口级更精简，它以应用名为粒度分发地址列表。服务提供者启动时，向 /services/app 目录下写入自己的 URL 地址，相比于接口级别的 URL，应用级别的 URL 更简单，只包含一些实例级别的参数，如 tri://ip:port?region=hangzhou。
可通过 registry.group 设置 zookeeper 的根节点，如设置 registry.group=dubbo 后，地址根节点变为 /dubbo。不配置将使用默认的 /services 根节点。在与 Spring Cloud Gateway 共用情况下，使用 /services 根节点会导致 dubbo 地址被 gateway 消费，此时可考虑设置独立 group。
注意
在应用级服务发现模型中，接口级别的配置信息由消费者与提供者之间自行协商同步，不再由注册中心负责同步，从而大大减少了注册中心地址同步压力。
2.2.2 接口应用映射
在应用级服务发现中，zookeeper 注册中心还会存储一份额外的元数据，用于解决 接口名到应用名 之间的映射关系，其存储结构如下：
service1 节点的 value 值是应用列表，可通过 get /dubbo/mapping/service1 查看：app1,app2
2.2.3 元数据
如果您用的是应用级服务发现的集中式元数据模式（默认是点对点的元数据模式，可通过 dubbo.registry.metadata-type=remote 开启）。在开启集中式元数据模式后，zookeeper 中还会发现以下节点内容：
每个 revision 下是该应用的部署元数据信息，包含完整的接口服务列表及其配置信息。
三、dubbo2.7.x快速开始
3.1 xml配置的实现类
3.2 dubbo SPI文件位置
四、dubbo的重要构成部分
4.1 dubbo provider的线程模型
dubbo的线程模型在代码中叫dispatcher 也可以在SPI文件中看到当前dubbo版本支持的线程模型实现类。
4.1.1 dubbo 2.7.12 支持新线程模型
dispatcher=all2 这个线程模型有个NB的地方，就是加入consumer超时10s provider实际要花20s，consumer这边发现超时了，就异常出去了，其实provider可以不用执行了，这种时候设置成all2就可以超时中断线程。
支持的dubbo版本是2.7.12 dubbo2.7.1不支持
超时的时候会抛出InterruptedException的异常，一般来说我们的业务代码都是被trycatch包住的，所以这个异常还要继续抛出去才行。这个timeout是优先看provider的timeout
4.1.2 导出dubbo线程堆栈
4.1.3 线程池拒绝策略的源码
先搜索 ThreadPoolExecutor 在ctrl+F12 找到reject方法
