Apache Dubbo – Apache Dubbo 博客

Blog: Dubbo 在 Proxyless Mesh 模式下的探索与改进

Thu, 02 Feb 2023 00:00:00 +0000

一、背景

随着 Docker 和 Kubernetes 的出现，一个庞大的单体应用可以被拆分成多个独立部署的微服务，并被打包运行于对应的容器中。不同应用之间相互通信，以共同完成某一功能模块。微服务架构与容器化部署带来的好处是显而易见的，它降低了服务间的耦合性，利于开发和维护，能更有效地利用计算资源。当然，微服务架构也存在相应的缺点：

强依赖于 SDK，业务模块与治理模块耦合较为严重。除了相关依赖，往往还需要在业务代码中嵌入SDK代码或配置。
统一治理难。每次框架升级都需要修改 SDK 版本，并重新进行回归测试，确认功能正常后再对每一台机器重新部署上线。不同服务引用的 SDK 版本不统一、能力参差不齐，增大了统一治理的难度。
缺少一套统一解决方案。目前市场不存在一整套功能完善、无死角的微服务治理与解决方案。在实际生产环境往往还需要引入多个治理组件来完成像灰度发布、故障注入等功能。

为解决这些痛点，Service Mesh诞生了。以经典的 Sidecar 模式为例，它通过在业务 Pod 中注入 Sidecar 容器，对代理流量实施治理和管控，将框架的治理能力下层到 Sidecar 容器中，与业务系统解耦，从而轻松实现多语言、多协议的统一流量管控、监控等需求。通过剥离SDK能力并拆解为独立进程，从而解决了强依赖于SDK的问题，从而使开发人员可以更加专注于业务本身，实现了基础框架能力的下沉，如下图所示（源自dubbo官网）：

经典的 Sidecar Mesh 部署架构有很多优势，如减少SDK耦合、业务侵入小等，但增加了一层代理，也带来了一些额外的问题，比如:

Sidecar 代理会损耗一部分性能，当网络结构层级比较复杂时尤其明显，对性能要求很高的业务造成了一定的困扰。
架构更加复杂，对运维人员要求高。
对部署环境有一定的要求，需要其能支持 Sidecar 代理的运行。

为解决这些痛点，Proxyless Service Mesh 模式诞生了。传统服务网格通过代理的方式拦截所有的业务网络流量，代理需要感知到控制平面下发的配置资源，从而按照要求控制网络流量的走向。以istio为例，Proxyless 模式是指应用直接与负责控制平面的 istiod 进程通信，istiod 进程通过监听并获取 Kubernetes 的资源，例如 Service、Endpoint 等，并将这些资源统一通过 xDS 协议下发到不同的 RPC 框架，由 RPC 框架进行请求转发，从而实现服务发现和服务治理等能力。 Dubbo 社区是国内最早开始对 Proxyless Service Mesh 模式进行探索的社区，这是由于相比于 Service Mesh，Proxyless 模式落地成本较低，对于中小企业来说是一个较好的选择。Dubbo 在 3.1 版本中通过对 xDS 协议进行解析，新增了对 Proxyless 的支持。xDS 是一类发现服务的总称，应用通过 xDS API 可以动态获取 Listener(监听器)、Route(路由)、Cluster(集群)、Endpoint(集群成员) 以及 Secret(证书)配置。

通过 Proxyless 模式，Dubbo 与 Control Plane 直接建立通信，进而实现控制面对流量管控、服务治理、可观测性、安全等的统一管控，从而规避 Sidecar 模式带来的性能损耗与部署架构复杂性。

二、Dubbo xDS 推送机制详解

从整体上看，istio control plane 和 dubbo 的交互时序图如上。Dubbo 里 xDS 处理的主要逻辑在 PilotExchanger 和各个 DS (LDS、RDS、CDS、EDS) 的对应协议的具体实现里。PilotExchanger 统一负责串联逻辑，主要有三大逻辑：

获取授信证书。
调用不同 protocol 的 getResource 获取资源。
调用不同 protocol 得 observeResource 方法监听资源变更。

例如对于 lds 和 rds，PilotExchanger 会调用 lds 的 getResource 方法与 istio 建立通信连接，发送数据并解析来自 istio 的响应，解析完成后的 resource 资源会作为rds 调用 getResource 方法的入参，并由 rds 发送数据给 istio。当 lds 发生变更时，则由 lds 的 observeResource 方法去触发自身与 rds 的变更。上述关系对于 rds 和 eds 同样如此。现有交互如下，上述过程对应图里红线的流程：

在第一次成功获取资源之后，各个DS会通过定时任务去不断发送请求给 istio，并解析响应结果和保持与 istio 之间的交互，进而实现控制面对流量管控、服务治理、可观测性方面的管控，其流程对应上图蓝线部分。

三、当前Dubbo Proxyless实现存在的不足

Dubbo Proxyless 模式经过验证之后，已经证明了其可靠性。现有 Dubbo proxyless 的实现方案存在以下问题：

目前与 istio 交互的逻辑是推送模式。getResource 和 observeResource 是两条不同的 stream 流，每次发送新请求都需要重新建立连接。但我们建立的 stream 流是双向流动的，istio 在监听到资源变化后由主动推送即可，LDS、RDS、EDS 分别只需要维护一条 stream 流。
Stream 流模式改为建立持久化连接之后，需要设计一个本地的缓存池，去存储已经存在的资源。当 istio 主动推送更新后，需要去刷新缓存池的数据。
现有observeResource 逻辑是通过定时任务去轮询istio。现在 observeResource 不再需要定时去轮询，只需要将需要监听的资源加入到缓存池，等 istio 自动推送即可，且 istio 推送回来的数据需要按照 app 切分好，实现多点监听，后续 dubbo 支持其他 DS 模式，也可复用相应的逻辑。
目前由 istio 托管的 dubbo 应用在 istio 掉线后会抛出异常，断线后无法重新连接，只能重新部署应用，增加了运维和管理的复杂度。我们需增加断线重连的功能，等 istio 恢复正常后无需重新部署即可重连。

改造完成后的交互逻辑：

四、Xds 监听模式实现方案

4.1 资源缓存池

目前 Dubbo 的资源类型有LDS，RDS，EDS。对于同一个进程，三种资源监听的所有资源都与 istio 对该进程所缓存的资源监听列表一一对应。因此针对这三种资源，我们应该设计分别对应的本地的资源缓存池，dubbo 尝试资源的时候先去缓存池查询，若有结果则直接返回；否则将本地缓存池的资源列表与想要发送的资源聚合后，发送给 istio 让其更新自身的监听列表。缓存池如下，其中 key 代表单个资源，T 为不同 DS 的返回结果：

 protected Map<String, T> resourcesMap = new ConcurrentHashMap<>();

有了缓存池我们必须有一个监听缓存池的结构或者容器，在这里我们设计为 Map 的形式，如下：

protected Map<Set<String>, List<Consumer<Map<String, T>>>> consumerObserveMap = new ConcurrentHashMap<>();

其中key为想要监听的资源，value 为一个 List, 之所以设计为 List 是为了可以支持重复订阅。 List 存储的 item 为 jdk8 中的 Consumer 类型，它可以用于传递一个函数或者行为，其入参为 Map<String, T>，其 key 对应所要监听的单个资源，便于从缓存池中获取。如上文所述，PilotExchanger 负责串联整个流程，不同 DS 之间的更新关系可以用 Consumer 进行传递。以监听 LDS observeResource 为例, 大致代码如下：

// 监听
void observeResource(Set<String> resourceNames, Consumer<Map<String, T>> consumer, boolean isReConnect);

// Observe LDS updated
ldsProtocol.observeResource(ldsResourcesName, (newListener) -> {
 // LDS数据不一致
 if (!newListener.equals(listenerResult)) {
 //更新LDS数据
 this.listenerResult = newListener;
 // 触发RDS监听
 if (isRdsObserve.get()) {
 createRouteObserve();
 }
 }
}, false);

Stream流模式改为建立持久化连接之后，我们也需要把这个 Consumer 的行为存储在本地的缓存池中。Istio 收到来自 dubbo 的推送请求后，刷新自身缓存的资源列表并返回响应。此时 istio 返回的响应内容是聚合后的结果，Dubbo 收到响应后，将响应资源拆分为更小的资源粒度，再推送给对应的 Dubbo应用通知其进行变更。

踩坑点：

istio推送的数据可能为空字符串，此时缓存池子无需存储，直接跳过即可。否则dubbo会绕过缓冲池，不断向istio发送请求。
考虑以下场景，dubbo应用同时订阅了两个接口，分别由app1和app2提供。为避免监听之间的相互覆盖，因此向istio发送数据时，需要聚合所有监听的资源名一次性发起。

4.2 多点独立监听

在第一次向istio发送请求时会调用getResource方法先去cache查询，缺失了再聚合数据去istio请求数据，istio再返回相应的结果给dubbo。我们处理istio的响应有两种实现方案：

由用户在getResource方案中new 一个completeFuture，由cache分析是否是需要的数据，若确认是新数据则由该future回调传递结果。
getResource建立资源的监听器consumerObserveMap，定义一个consumer并把取到的数据同步到原来的线程，cache 收到来自istio的推送后会做两件事：将数据推送所有监听器和将数据发送给该资源的监听器。以上两种方案都能实现，但最大的区别就是用户调用onNext发送数据给istio的时候需不需要感知getResource 的存在。综上，最终选择方案2进行实现。具体实现逻辑是让dubbo与istio建立连接后，istio会推送自身监听到资源列表给dubbo，dubbo解析响应，并根据监听的不同app切分数据，并刷新本地缓存池的数据，并发送ACK响应给istio，大致流程如下：

public class ResponseObserver implements XXX {
 ...
 public void onNext(DiscoveryResponse value) {
 //接受来自istio的数据并切分
 Map<String, T> newResult = decodeDiscoveryResponse(value);
 //本地缓存池数据
 Map<String, T> oldResource = resourcesMap;
 //刷新缓存池数据
 discoveryResponseListener(oldResource, newResult);
 resourcesMap = newResult;
 // for ACK
 requestObserver.onNext(buildDiscoveryRequest(Collections.emptySet(), value));
 }
 ...
 public void discoveryResponseListener(Map<String, T> oldResult,
 Map<String, T> newResult) {
 ....
 }
}
//具体实现交由LDS、RDS、EDS自身
protected abstract Map<String, T> decodeDiscoveryResponse(DiscoveryResponse response){
 //比对新数据和缓存池的资源，并将不同时存在于两种池子的资源取出
 ...
 for (Map.Entry<Set<String>, List<Consumer<Map<String, T>>>> entry : consumerObserveMap.entrySet()) {
 // 本地缓存池不存在则跳过
 ...
 //聚合资源
 Map<String, T> dsResultMap = entry.getKey()
 .stream()
 .collect(Collectors.toMap(k -> k, v -> newResult.get(v)));
 //刷新缓存池数据
 entry.getValue().forEach(o -> o.accept(dsResultMap));
 }
}

踩坑点：

原本多个stream流的情况下，会用递增的requestId来复用stream流，改成持久化连接之后，一种resource会有多个requestid，可能会相互覆盖，因此必须去掉这个机制。
初始实现方案并没有对资源进行切分，而是一把梭，考虑到后续对其他DS的支持，对istio返回的数据进行切分，也导致consumerObserveMap有点奇形怪状。
三种DS在发送数据时可以共享同一channel，但监听所用到的必须是同一channel，否则数据变更时istio不会进行推送。
建立双向stream流之后，初始方案future为全局共享。但可能有这样的场景：相同的ds两次相邻时间的onNext事件，记为A事件和B事件，可能是A事件先发送，B随后；但可能是B事件的结果先返回，不确定istio推送的时间，因此future必须是局部变量而不是全局共享。

4.3 采用读写锁避免并发冲突

监听器consumerObserveMap和缓存池resourcesMap均可能产生并发冲突。对于resourcemap，由于put操作都集中在getResource方法，因此可以采用悲观锁就能锁住相应的资源，避免资源的并发监听。对于consumerObserveMap，同时存在put、remove和遍历操作，从时序上，采用读写锁可规避冲突，对于遍历操作加读锁，对于put和remove操作加写锁，即可避免并发冲突。综上，resourcesMap加悲观锁即可，consumerObserveMap涉及的操作场景如下：

远程请求istio时候会往consumerObserveMap 新增数据，加写锁。
CompleteFuture跨线程返回数据后，去掉监听future，加写锁。
监听缓存池时会往consumerObserveMap新增监听，加写锁。
断线重连时会往consumerObserveMap新增监听，加写锁。
解析istio返回的数据，遍历缓存池并刷新数据，加读锁。

踩坑点：

由于dubbo和istio建立的是是双向stream流，相同的ds两次相邻时间的onNext事件，记为A事件和B事件，可能是A事件先发送，B随后；但可能是B事件的结果先返回，不确定istio推送的时间。因此需要加锁。

4.4 断线重连

断线重连只需要用定时任务去定时与istio交互，尝试获取授信证书，证书获取成功即可视为istio成功重新上线，dubbo会聚合本地的资源去istio请求数据，并解析响应和刷新本地缓存池数据，最后再关闭定时任务。踩坑点：

采用全局共享的定时任务池，不能进行关闭，否则会影响其他业务。

五、感想与总结

在这次功能的改造中，笔者着实掉了一波头发，怎么找bug也找不到的情形不在少数。除了上述提到的坑点之外，其他的坑点包括但不局限于：

dubbo在某一次迭代里更改了获取k8s证书的方式，授权失败。
原本的功能没问题，merge了下master代码，grpc版本与envoy版本不兼容，各种报错，最后靠降低版本成功解决。
原本的功能没问题，merge了下master代码，最新分支代码里metadataservice发成了triple，然而在Proxyless模式下只支持dubbo协议，debug了三四天，最后发现需要增加配置。

…… 但不得不承认，Proxyless Service Mesh确实有它自身的优势和广阔的市场前景。自dubbo3.1.0 release版本之后，dubbo已经实现了Proxyless Service Mesh能力，未来dubbo社区将深度联动业务，解决更多实际生产环境中的痛点，更好地完善service mesh能力。

Blog: Dubbo 3.1.5、3.2.0-beta.4 正式发布

Mon, 30 Jan 2023 00:00:00 +0000

Dubbo 3.1.5 版本是目前 Dubbo 3 的最新稳定版本，我们建议所有的用户都升级到最新的稳定版本。Dubbo 3.2.0-beta.4 版本是目前 Dubbo 3 的最新特性版本，包括了如 Spring Boot 3、JDK 17、服务粒度的线程池隔离等新特性的支持，欢迎大家尝鲜使用。

Dubbo 3.1.5

新特性

Dubbo QoS 支持记录请求的记录，便于进行审计
支持在服务映射失败以后定时进行重试，降低由于元数据中心抖动带来的影响
支持在初始化 Nacos Client 的时候进行健康检查，如果失败则在一定次数限制下进行重试，降低由于 Nacos 性能问题带来的稳定性影响
支持序列化类检查机制，默认开启日志告警模式

Bugfix

修复资源加载器的日志级别
修复 Dubbo 配置类对 Scope Model 进行懒加载，避免触发非预期的默认模块初始化
修复 ReferenceConfig 中获取 ClassLoader 的逻辑
修复 Metadata Service 在获取订阅服务列表时出现 NPE 的问题
修复对接 Spring Cloud Rest 模式的时候 Metadata 配置覆盖的问题
修复 Spring 懒加载时可能出现死锁的问题
修复端口重复的无效日志
修复 Active Limit Filter 不生效的问题
修复服务映射时 Nacos CAS 检查写入无效的问题
修复 Zookeeper 注册中心对接的应用级服务发现在服务发布的时候出现单节点服务找不到的问题
修复服务映射在冲突以后未等待导致的冲突率高的问题
修复应用级服务发现下节点更新失败的问题
修复应用级配置覆盖不生效的问题
修复在应用级地址刷新之后原 Revision 的元数据无法获取的问题
修复 Zookeeper 注册中心在应用级服务发现下退订阅后无法重订阅的问题
兼容 Nacos 在频繁刷新时最终一致性错误的问题
关闭 Nacos 本地缓存获取的开关
修复 Triple 传递大写 Attachment 无效的问题
修复 Triple 处理特定类反序列化错误的问题
修复 Protobuf 依赖不存在时抛出非预期异常的问题
修复 CountDown 功能无效的问题
修复 Triple 在反序列化时类加载器未切换的问题

FAQ

本次发布中有 5 个提交涉及异常日志 FAQ 的完善。关于错误码机制请参考官网错误码机制介绍一文。（https://cn.dubbo.apache.org/zh/docs3-v2/java-sdk/faq/intro/）

代码优化

本次发布中有 4 个提交涉及代码质量的优化。

依赖升级

升级 protobuf-java: 3.16.3 -> 3.18.3
升级 fastjson2: 2.0.21 -> 2.0.23

贡献者

Dubbo 感谢以下贡献者对本次发布的贡献：@win120a, @wuwen5, @AlbumenJ, @CrazyHZM, @EarthChen, @xieshouyu, @wxbty

新贡献者

@xieshouyu 在 PR #11177 提交了第一个贡献

Dubbo 3.2.0-beta.4

注：Dubbo 3.2.0-beta.4 的代码基础和 Dubbo 3.1.5 完全一致，因此在 Dubbo 3.1.5 中包括的所有修改内容，在 Dubbo 3.2.0-beta.4 中也同样存在，后续说明中对于重复的内容讲不再赘述。

新特性

支持 bytebuddy 作为动态代理的生成平台
支持采集超时指标进行上报
完善 Metrics 上报应用名
完善 Metrics 上报指标的前缀
支持上报请求失败的指标
完善 xDS 的监听逻辑
完善 xDS 对接路由规则的能力

Bugfix

修复 Token 请求在 Rest 协议下不生效的问题
修复 GraalVM Native Image 的配置
修复配置类无法进行序列化的问题
修复 IPv6 地址段检查无效的问题
修复路由链切换时地址可能存在异常的情况
修复缓存文件锁被异常删除的问题
修复 Deployer Listener 并发修改的问题

性能优化

优化 ConcurrentHashMap 的使用方式，避免在 JDK 1.8 下出现性能衰减

代码优化

本次发布中有 8 个提交涉及代码质量的优化。

依赖升级

升级 protobuf-java: 3.18.3 -> 3.19.6
升级 cglib-nodep: 2.2 -> 2.2.2
升级 byte-buddy: 1.12.19 -> 1.12.22
升级 bouncycastle-bcprov_version: 1.69 -> 1.70
升级 javax.ws.rs-api: 2.0 -> 2.1.1
升级 curator_version: 4.2.0 -> 4.3.0
升级 maven-plugin-plugin: 3.6.0 -> 3.7.1
升级 javax.el: 3.0.1-b08 -> 3.0.1-b12
升级 slf4j-api: 1.7.25 -> 1.7.36
升级 spring-boot-dependencies: 2.3.1.RELEASE -> 2.7.7
升级 maven-enforcer-plugin: 3.0.0-M3 -> 3.1.0
升级 javassist: 3.28.0-GA -> 3.29.2-GA
升级 spring-boot-maven-plugin: 2.1.4.RELEASE -> 2.7.7
升级 javax.el-api: 2.2.4 -> 2.2.5
升级 eureka.version: 1.9.12 -> 1.10.18
升级 jetty-maven-plugin: 9.4.38.v20210224 -> 9.4.50.v20221201
升级 jetty_version: 9.4.43.v20210629 -> 9.4.50.v20221201
升级 resteasy_version: 3.0.20.Final -> 3.15.3.Final

贡献者

Dubbo 感谢以下贡献者对本次发布的贡献：@aamingaa, @AlbumenJ, @CrazyHZM, @fomeiherz, @HHoflittlefish777, @icodening, @jojocodeX, @LXPWing, @MentosL, @mxsm, @schneiderlin, @sconvent, @ShenFeng312, @songxiaosheng, @TigerTurbo, @yuluo-yx, @zeusbee

新贡献者

@LXPWing 在 PR #11258 提交了第一个贡献
@HHoflittlefish777 在 PR #11266 提交了第一个贡献
@sconvent 在 PR #11260 提交了第一个贡献
@yuluo-yx 在 PR #11291 提交了第一个贡献
@fomeiherz 在 PR #11295 提交了第一个贡献
@schneiderlin 在 PR #11324 提交了第一个贡献
@mxsm 在 PR #11326 提交了第一个贡献

未来版本规划

Dubbo 版本的发布规划以及在《聚焦稳定性，Dubbo 发版规划公布》一文中正式发布，欢迎查看。

Blog: Dubbo 3 之 Triple 流控反压原理解析

Wed, 28 Dec 2022 00:00:00 +0000

Triple 是 Dubbo 3 提出的基于 HTTP2 的开放协议，旨在解决 Dubbo 2 私有协议带来的互通性问题。 Triple 基于 HTTP/2 定制自己的流控，支持通过特定的异常通知客户端业务层服务端负载高情况，保护了服务端被大流量击垮，提高系统高可用能力。

一、流控反压现状

客户端和服务器端在接收数据的时候有一个缓冲区来临时存储数据，但是缓冲区的大小是有限制的，所以有可能会出现缓冲区溢出的情况， HTTP 通过流控保护数据溢出丢失风险。

1、HTTP/1 流控

在 HTTP/1.1 中，流量的控制依赖的是底层TCP协议，在客户端和服务器端建立连接的时候，会使用系统默认的设置来建立缓冲区。在数据进行通信的时候，会告诉对方它的接收窗口的大小，这个接收窗口就是缓冲区中剩余的可用空间。如果接收窗口大小为零，则说明接收方缓冲区已满，则发送方将不再发送数据，直到客户端清除其内部缓冲区，然后请求恢复数据传输。

2、HTTP/2 流控

HTTP/2 使用了多路复用机制，一个TCP连接可以有多个 HTTP/2 连接，故在 HTTP/2 中，有更加精细的流控制机制，允许服务端实现自己数据流和连接级的流控制。服务端与客户端第一次连接时，会通过发送 HTTP/2 SettingsFrame设置初始化的流控窗口大小，用于 Stream 级别流控，默认为 65,535 字节。定好流控窗口后，每次客户端发送数据就会减少流控窗口的大小，服务端收到数据后会发送窗口更新包（WINDOW_UPDATE frame）通知客户端更新窗口。客户端收到窗口更新包后就会增加对应值的流控窗口，从而达到动态控制的目的。

二、Triple流控反压

Netty 基于 HTTP/2 实现了基础的流控，当服务端负载过高，客户端发送窗口为 0 时，新增请求就无法被发送出去，会在缓存到客户端待发送请求队列中，缓存数据过大，就会造成客户端内存溢出，影响业务程序。

Triple 基于 Netty 实现了 HTTP/2 协议，通过 HTTP/2 FlowController接口统一封装，在实现分为进站（inbound）和出站（outbound）两个维度的实现。 Triple 在 inbound 流量上使用了 Netty 的默认流控实现，在 outbound 上实现了自己流控，基于服务端负载，将服务端流量压力透传到客户端业务层，实现客户端的业务反压，暂停业务继续发送请求，保护服务端不被大流量击垮。

1、连接初始化

Triple在初次建立连接时，通过 TripleHttpProtocol 初始化 HTTP/2 配置，默认流控窗口 DEFAULT_WINDOW_INIT_SIZE = MIB_8，并在服务端和客户端加入自己的 outbound 流控接口。

2、Inbound流控

Inbound 流量会通过 DefaultHttpLocalFlowController 的 consumeBytes 方法实现流控窗口更新与发送。

1) 入口传入HTTP 流与更新数据大小

2) 找到对应连接实现数据消费

3) 更新流控窗口

4) 发送流控更新数据包（window_update）

3、Outbound流控

Outbound 通过 Triple 自己的流控实现 TriHttpRemoteFlowController，将服务端压力反馈到业务层，保护服务端被大流量击垮。

1) 发送数据时判断是否还有窗口

2) 窗口为0时抛出特定异常

3) 反馈客户端流控异常

4、总结

Triple 通过将底层客户端发送窗口为 0 场景封装为特定流控异常，透传至客户端上层业务，阻止客户端业务继续数据发送，有效的保护了服务端被大流量击垮和客户端的内存溢出的问题。

三、未来展望

目前 Triple 已经基本实现了流控反压能力，未来我们将深度联动业务，基于业务负载自适应调整反压流控，一是在 inbound 上将流控窗口包发送时机调整到服务端业务处理完成后，二是在 outbound 流量上关联客户端业务层，动态调整客户端发送速率。从而实现基于服务端业务负载动态反压流控机制。

Blog: Dubbo 3.1.4、3.2.0-beta.3 正式发布

Thu, 22 Dec 2022 00:00:00 +0000

Dubbo 3.1.4 版本是目前 Dubbo 3 的最新稳定版本，我们建议所有的用户都升级到最新的稳定版本。Dubbo 3.2.0-beta.3 版本是目前 Dubbo 3 的最新特性版本，包括了如 Spring Boot 3、JDK 17、服务粒度的线程池隔离等新特性的支持，欢迎大家尝鲜使用。

Dubbo 3.1.4

新特性

Dubbo QoS 支持指定白名单 IP 列表访问所有命令

Bugfix

修复在泛化调用时 Dubbo Metrics 采集方法名错误
修复使用 Zookeeper 作为元数据中心时，上报接口映射可能存在相互覆盖的问题
修复 timeout countdown 在 Triple 协议的支持
修复 timeout countdown 存在透传的问题
修复多注册中心请求时，由于没有可用的地址导致的 NPE 问题
修复 Mesh 模式下 Triple 获取 remoteApplicationName 为空的问题
修复 GraalVM Native Image 的支持
修复端口复用时无 SSL 连接导致的 NPE 异常
完善 JDK 编译器报错日志的输出格式
修复 MetadataReportConfig 部分配置时应用无法启动的问题
修复 dubbo.reference 作为默认参数在 3.x 版本中不生效的问题
完善 Zookeeper 连接失败的日志
修复 ReferenceConfig 中配置的 ClassLoader 可能被覆盖的问题
修复部分属性在应用级服务发现时被缓存在实例级的地址中导致方法级配置失效的问题
修复 Triple 协议 onError 异常的问题

FAQ

本次发布中有 3 个提交涉及异常日志 FAQ 的完善。关于错误码机制请参考官网错误码机制介绍一文。（https://cn.dubbo.apache.org/zh/docs3-v2/java-sdk/faq/intro/）

代码优化

本次发布中有 11 个提交涉及代码质量的优化。

依赖升级

升级 fastjson2: 2.0.14 -> 2.0.21
升级 resteasy-jaxrs: 3.0.19.Final -> 3.0.20.Final

贡献者

Dubbo 感谢以下贡献者对本次发布的贡献：@cnjxzhao, @CrazyHZM, @EarthChen, @gold-fisher, @IncrementalRefinement, @Koooooo-7, @ShenFeng312, @tonycody, @twz007, @win120a, @wlazjr

新贡献者

@twz007 在 PR #11012 提交了第一个贡献
@IncrementalRefinement 在 PR #11046 提交了第一个贡献
@gold-fisher 在 PR #11058 提交了第一个贡献
@wlazjr 在 PR #11084 提交了第一个贡献
@ShenFeng312 在 PR #11102 提交了第一个贡献

Dubbo 3.2.0-beta.3

注：Dubbo 3.2.0-beta.3 的代码基础和 Dubbo 3.1.4 完全一致，因此在 Dubbo 3.1.4 中包括的所有修改内容，在 Dubbo 3.2.0-beta.3 中也同样存在，后续说明中对于重复的内容讲不再赘述。

新特性

支持使用 jackson 作为Dubbo 内部的 JSON 序列化方式
优化 Dubbo Logger 的选择逻辑，在存在多种日志框架的情况下会尝试读取其配置，选择一个有效的日志框架，解决在 SpringBoot 等场景下 Dubbo 日志不输出的问题。
Triple 协议支持客户端流控
支持发布 Dubbo Metrics 数据到 Spring Boot 的 Endpoints 上
支持可选关闭线程池满时的线程 Dump 以及支持配置 Dump 的结果输出路径
xDS 实现支持路由规则的解析
支持 Dubbo QoS 命令安全性分级，默认对外暴露存活检测的端口，支持 Kubernetes 的原生接入
支持基于 P2C 的自适应负载均衡

Bugfix

修复默认 Metadata 缓存未开启的问题
修复 Metrics 指标资源路径错误的问题
完善线程池隔离的配置，默认采用共享线程池，避免创建过多的线程
完善 prefer-serialization 的选择逻辑，提供向前兼容的能力
修复 Triple 协议传输时未携带版本号导致版本调用错误的问题
完善 GraalVM Native Image 的支持

性能优化

优化在连接数高时由于获取 channels 数量导致的资源占用问题

代码优化

本次发布中有 5 个提交涉及代码质量的优化。

贡献者

Dubbo 感谢以下贡献者对本次发布的贡献：@AlbumenJ, @asa3311, @conghuhu, @CrazyHZM, @gitchenjh, @haoyann, @JavaHello, @Koooooo-7, @nannanfighting, @ningboliu, @shanuo0312, @songxiaosheng, @tonycody, @XDanwar

新贡献者

@JavaHello 在 PR #10970 提交了第一个贡献
@songxiaosheng 在 PR #10997提交了第一个贡献
@Koooooo-7 在 PR #11051 提交了第一个贡献
@ningboliu 在 PR #10745 提交了第一个贡献
@XDanwar 在 PR #11063 提交了第一个贡献

未来版本规划

Dubbo 版本的发布规划以及在《聚焦稳定性，Dubbo 发版规划公布》一文中正式发布，欢迎查看。

Blog: Triple 协议支持 Java 异常回传的设计与实现

Mon, 19 Dec 2022 00:00:00 +0000

背景

在一些业务场景, 往往需要自定义异常来满足特定的业务, 主流用法是在catch里抛出异常, 例如：

public void deal() {
 try{
 //doSomething
 ...
 } catch(IGreeterException e) {
 ...
 throw e;
 }
}

或者通过ExceptionBuilder，把相关的异常对象返回给consumer：

provider.send(new ExceptionBuilders.IGreeterExceptionBuilder()
 .setDescription('异常描述信息');

在抛出异常后, 通过捕获和instanceof来判断特定的异常, 然后做相应的业务处理，例如：

try {
 greeterProxy.echo(REQUEST_MSG);
} catch (IGreeterException e) {
 //做相应的处理
 ...
}

在 Dubbo 2.x 版本，可以通过上述方法来捕获 Provider 端的异常。而随着云原生时代的到来， Dubbo 也开启了 3.0 的里程碑。

Dubbo 3.0 的一个很重要的目标就是全面拥抱云原生，在 3.0 的许多特性中，很重要的一个改动就是支持新的一代Rpc协议Triple。

Triple 协议基于 HTTP 2.0 进行构建，对网关的穿透性强，兼容 gRPC，提供 Request Response、Request Streaming、Response Streaming、 Bi-directional Streaming 等通信模型；从 Triple 协议开始，Dubbo 还支持基于 IDL 的服务定义。

采用 Triple 协议的用户可以在 provider 端生成用户定义的异常信息，记录异常产生的堆栈，triple 协议可保证将用户在客户端获取到异常的message。

Triple 的回传异常会在 AbstractInvoker 的 waitForResultIfSync 中把异常信息堆栈统一封装成 RpcException，所有来自 Provider 端的异常都会被封装成 RpcException 类型并抛出，这会导致用户无法根据特定的异常类型捕获来自 Provider 的异常，只能通过捕获 RpcException 异常来返回信息，且 Provider 携带的异常 message 也无法回传，只能获取打印的堆栈信息：

 try {
 greeterProxy.echo(REQUEST_MSG);
 } catch (RpcException e) {
 e.printStackTrace();
 }

自定义异常信息在社区中的呼声也比较高，因此本次改动将支持自定义异常的功能, 使得服务端能抛出自定义异常后被客户端捕获到。

Dubbo异常处理简介

我们从Consumer的角度看一下一次Triple协议 Unary请求的大致流程：

Dubbo Consumer 从 Spring 容器中获取 bean 时获取到的是一个代理接口，在调用接口的方法时会通过代理类远程调用接口并返回结果。

Dubbo提供的代理工厂类是 ProxyFactory，通过 SPI 机制默认实现的是 JavassistProxyFactory， JavassistProxyFactory 创建了一个继承自 AbstractProxyInvoker 类的匿名对象，并重写了抽象方法 doInvoke。重写后的 doInvoke 只是将调用请求转发给了 Wrapper 类的 invokeMethod 方法，并生成 invokeMethod 方法代码和其他一些方法代码。

代码生成完毕后，通过 Javassist 生成 Class 对象，最后再通过反射创建 Wrapper 实例，随后通过 InvokerInvocationHandler -> InvocationUtil -> AbstractInvoker -> 具体实现类发送请求到Provider端。

Provider 进行相应的业务处理后返回相应的结果给 Consumer 端，来自 Provider 端的结果会被封装成 AsyncResult ，在 AbstractInvoker 的具体实现类里，接受到来自 Provider 的响应之后会调用 appResponse 到 recreate 方法，若 appResponse 里包含异常，则会抛出给用户，大体流程如下：

上述的异常处理相关环节是在 Consumer 端，在 Provider 端则是由 org.apache.dubbo.rpc.filter.ExceptionFilter 进行处理，它是一系列责任链 Filter 中的一环，专门用来处理异常。

Dubbo 在 Provider 端的异常会在封装进 appResponse 中。下面的流程图揭示了 ExceptionFilter 源码的异常处理流程:

而当 appResponse 回到了 Consumer 端，会在 InvocationUtil 里调用 AppResponse 的 recreate 方法抛出异常，最终可以在 Consumer 端捕获：

public Object recreate() throws Throwable {
 if (exception != null) {
 try {
 Object stackTrace = exception.getStackTrace();
 if (stackTrace == null) {
 exception.setStackTrace(new StackTraceElement[0]);
 }
 } catch (Exception e) {
 // ignore
 }
 throw exception;
}
return result;
}

Triple 通信原理

在上一节中，我们已经介绍了 Dubbo 在 Consumer 端大致发送数据的流程，可以看到最终依靠的是 AbstractInvoker 的实现类来发送数据。在 Triple 协议中，AbstractInvoker 的具体实现类是 TripleInvoker ， TripleInvoker 在发送前会启动监听器，监听来自 Provider 端的响应结果，并调用 ClientCallToObserverAdapter 的 onNext 方法发送消息，最终会在底层封装成 Netty 请求发送数据。

在正式的请求发起前，TripleServer 会注册 TripleHttp2FrameServerHandler，它继承自 Netty 的 ChannelDuplexHandler，其作用是会在 channelRead 方法中不断读取 Header 和 Data 信息并解析，经过层层调用，会在 AbstractServerCall 的 onMessage 方法里把来自 consumer 的信息流进行反序列化，并最终由交由 ServerCallToObserverAdapter 的 invoke 方法进行处理。

在 invoke 方法中，根据 consumer 请求的数据调用服务端相应的方法，并异步等待结果；' 若服务端抛出异常，则调用 onError 方法进行处理，否则，调用 onReturn 方法返回正常的结果，大致代码逻辑如下：

public void invoke() {
 ...
 try {
 //调用invoke方法请求服务
 final Result response = invoker.invoke(invocation);
 //异步等待结果
 response.whenCompleteWithContext((r, t) -> {
 //若异常不为空
 if (t != null) {
 //调用方法过程出现异常，调用onError方法处理
 responseObserver.onError(t);
 return;
 }
 if (response.hasException()) {
 //调用onReturn方法处理业务异常
 onReturn(response.getException());
 return;
 }
 ...
 //正常返回结果
 onReturn(r.getValue());
 });
 }
 ...
}

大体流程如下：

实现版本

了解了上述原理，我们就可以进行相应的改造了，能让 consumer 端捕获异常的关键在于把异常对象以及异常信息序列化后再发送给consumer端。常见的序列化协议很多，例如 Dubbo/HSF 默认的 hessian2 序列化；还有使用广泛的 JSON 序列化；以及 gRPC 原生支持的 protobuf(PB) 序列化等等。 Triple协议因为兼容grpc的原因，默认采用 Protobuf 进行序列化。上述提到的这三种典型的序列化方案作用类似，但在实现和开发中略有不同。 PB 不可由序列化后的字节流直接生成内存对象，而 Hessian 和 JSON 都是可以的。后两者反序列化的过程不依赖“二方包”，其序列化和反序列化的代码由 proto 文件相同，只要客户端和服务端用相同的 proto 文件进行通信，就可以构造出通信双方可解析的结构。

单一的 protobuf 无法序列化异常信息，因此我们采用 Wrapper + PB 的形式进行序列化异常信息，抽象出一个 TripleExceptionWrapperUtils 用于序列化异常，并在 trailer 中采用 TripleExceptionWrapperUtils 序列化异常，大致代码流程如下：

上面的实现方案看似非常合理，已经能把 Provider 端的异常对象和信息回传，并在 Consumer 端进行捕获。但仔细想想还是有问题的：通常在 HTTP2 为基础的通信协议里会对 header 大小做一定的限制，太大的header size 会导致性能退化严重，为了保证性能，往往以 HTTP2 为基础的协议在建立连接的时候是要协商最大 header size 的，超过后会发送失败。对于 Triple 协议来说，在设计之初就是基于 HTTP 2.0，能无缝兼容 Grpc，而 Grpc header 头部只有 8KB 大小，异常对象大小可能超过限制，从而丢失异常信息；且多一个 header 携带序列化的异常信息意味着用户能加的 header 数量会减少，挤占了其他 header 所能占用的空间。

经过讨论，考虑将异常信息放置在 Body，将序列化后的异常从 trailer 挪至 body，采用 TripleWrapper + protobuf 进行序列化，把相关的异常信息序列化后回传。社区围绕这个问题进行了一系列的争论，读者也可尝试先思考一下：

1.在 body 中携带回传的异常信息，其对应HTTP header状态码该设置为多少？

2.基于 http2 构建的协议，按照主流的 grpc 实现方案，相关的错误信息放在 trailer，理论上不存在body，上层协议也需要保持语义一致性，若此时在payload回传异常对象，且grpc并没有支持在Body回传序列化对象的功能，会不会破坏Http和grpc协议的语义？从这个角度出发，异常信息更应该放在trailer里。

3.作为开源社区，不能一味满足用户的需求，非标准化的用法注定是会被淘汰的，应该尽量避免更改 Protobuf的语义，是否在Wrapper层去支持序列化异常就能满足需求？

首先回答第二、三个问题：HTTP 协议并没有约定在状态码非 2xx 的时候不能返回 body，返回之后是否读取取决于用户。grpc 采用protobuf进行序列化，所以无法返回 exception；且try catch机制为java独有，其他语言并没有对应的需求，但Grpc暂时不支持的功能并一定是unimplemented，Dubbo的设计目标之一是希望能和主流协议甚至架构进行对齐，但对于用户合理的需求也希望能进行一定程度的修改。且从throw本身的语义出发，throw 的数据不只是一个 error message，序列化的异常信息带有业务属性，根据这个角度，更不应该采用类似trailer的设计。至于单一的Wrapper层，也没办法和grpc进行互通。至于Http header状态码设置为200，因为其返回的异常信息已经带有一定的业务属性，不再是单纯的error，这个设计也与grpc保持一致，未来考虑网关采集可以增加新的triple-status。

更改后的版本只需在异常不为空时返回相关的异常信息，采用 TripleWrapper + Protobuf 进行序列化异常信息，并在consumer端进行解析和反序列化，大体流程如下：

总结

通过对 Dubbo 3.0 新增自定义异常的版本迭代中可以看出，尽管只能新增一个小小的特性，流程下并不复杂，但由于要考虑互通、兼容和协议的设计理念，因此思考和讨论的时间可能比写代码的时间更多。

Blog: 聚焦稳定性，Dubbo 发版规划公布

Mon, 05 Dec 2022 00:00:00 +0000

Dubbo 简介

Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java、Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力，利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑。

我应该如何选择版本？

对于这个问题，一直以来 Dubbo 都没有很好地去回答。究其原因保证所有版本的稳定性是一件非常有挑战的事情。比如在 Dubbo 2.7 的一些版本中，出现了一些前后不兼容的问题，给一些用户升级带来了困扰。为此，很多用户从保障稳定性的视角出发，选择了更保守的策略，即生产环境采用被采用最多的版本，此后就不再更新，避免升级过程中出现意外。

但是这种方式无疑是有问题的，一方面这将导致永远无法用上社区新的功能，得到技术演进的红利；另一方面，对于安全漏洞和带来不稳定因素的 bug 等已知问题如果不升级永远会存在，久而久之将给应用带来巨大的风险，很有可能导致严重的安全生产事故。

因此，为了更好地回答这个问题，Dubbo 制定了未来的版本迭代规划，明确版本的稳定性维护机制，提升开发者使用 Dubbo 的信心。

现状

在此前，Dubbo 总共维护了 2.6.x、2.7.x 以及 3.x 三个大版本，其中 2.7.x 为捐献进入 Apache 基金会之后的版本。

2.6.x 在去年已经宣布生命周期结束（EOL）了，而 2.7.x 累计维护了四年的时间了。这四年的时间里，2.7.x 版本经历了多次大的修改，如 2.7.3 版本中对 Nacos 的注册方式进行了修改、2.7.6 版本中添加了应用级服务发现、2.7.9 版本中对应用级服务发现进行大的重构等。

这些修改都对 2.7.x 版本的稳定性带来了巨大的风险隐患，导致 2.7.x 中很多版本或多或少存在不同的问题，用户无法选择一个最稳定的版本进行使用。

因此，我们希望在 3.x 版本中将这种不稳定的情况通过发版机制给收敛掉，提高 Dubbo 版本的稳定性。

未来总体规划

在接下来，Dubbo 将以每 6 个月为一个周期，对每个版本包括了新功能合入、稳定性维护以及安全漏洞修复三个大方向的内容。

新功能合入是指将 Dubbo 开发过程中所有新的特性、性能优化、破坏性修改都会被合入的行为。由于新功能是需要一段时间迭代稳定的，所以新功能的合入会给对应版本带来不稳定因素，因此只能在每个版本最开始的时候进行。

稳定性维护是指修复已有功能的非预期行为，进一步提升版本的稳定性。特别的，对于一些大的问题修复，如功能需要整体重构的，或者回带来破坏性影响的提交将被视为新功能提交，执行新功能合入的流程。避免因为修复一个问题而来带更多问题的严重后果。

安全维护是指修复使用中的安全风险问题，这一块主要是解决来自白帽子提交的漏洞问题。

新功能合入在每个版本中会持续 6 个月，稳定性维护在每个版本中会持续 12 个月，安全维护在每个版本中会持续 18 个月。

因此，从整体迭代规划来看，每 6 个月 Dubbo 会开始一个新的版本迭代，与之同时的，也会有一个版本宣布生命周期结束（EOL）。

逐版本维护规划

上图为具体到每个版本在每个时间点的维护状态图。

对于 Dubbo 2.7 以及 3.0 版本，目前已经进入了安全维护阶段，将在 2023 年 3 月宣布版本维护周期结束。

对于 Dubbo 3.1 版本，目前已经是稳定性维护阶段，如前一小节所述，目前只会继续合入和稳定性修改的修改。处于稳定性维护阶段的版本也是社区推荐生产使用的最新版本。稳定性维护工作将持续到 2023 年 3 月，在此之后会有持续 6 个月的安全维护阶段，最终在 2023 年 9 月结束其版本的生命周期。

对于 Dubbo 3.2 版本，目前仍处在新功能合入的阶段，发布的是 beta 版本。此阶段适合一些尝鲜使用，版本稳定性相较于已经进入仅稳定性维护阶段的版本稍欠。在 2023 年 3 月，Dubbo 3.2 将结束新功能合入周期，进行充分的稳定性验证，并正式发布生产可用的 GA 版本。此后在 2023 年 9 月之前会进行稳定性的维护，在 2024 年 3 月结束版本的生命周期。

对于 Dubbo 3.3 版本，将在 2023 年 3 月紧随着 3.2 版本结束新功能合入阶段后正式开始开发。因此，Dubbo 3.3 版本的第一个 beta release 也将会在 2023 年 3 月发布。同样的，经过 6 个月的新功能合入阶段之后，Dubbo 3.3 版本将会在 2023 年 9 月正式发布生产可用 GA 版本，同时进入稳定性维护阶段。之后在 2024 年 3 月进入安全维护阶段，在 2024 年 9 月结束版本的生命周期。

总结

对于绝大多数的生产用户，我们建议使用当前处于仅稳定性维护阶段的版本的最新小版本。如在 2022 年 9 月至 2023 年 3 月这段时间，Dubbo 3.1 是处于仅稳定性维护阶段的，因此首选 Dubbo 3.1 版本。而对于如 3.1.0、3.1.1、3.1.2 等的 Dubbo 3.1.x 的多个小版本，我们建议直接使用最新的小版本。由于各个小版本之间仅包含稳定性修复，所以越往后的版本是越稳定的。

对于愿意尝鲜、体验新功能的用户，可以直接基于最新的开发版本进行测试。即使是开发版本，Dubbo 也有一整套的质量保障机制，如果使用过程中遇到问题，欢迎向社区提交反馈。

目前，阿里巴巴集团已经基于 Dubbo 3.0 的稳定版本完美支撑了整个核心电商今年双十一的所有调用，现在也正在升级到 Dubbo 3.1 这个最新的稳定版本上来。我们欢迎更多的用户一起升级到 Dubbo 3.1 版本上，在升级过程中可以参考官网给出的升级指南，遇到任何问题也可以通过 issue、微信群、钉钉群及时反馈社区，我们将尽全力协助。

在版本规划的方向上，除了本次发布的迭代线路图，Dubbo 还将通过一系列的机制保障用户的使用体验是连续的、稳定的。在大版本升级方面，Dubbo 将建设完善的版本升级指南，如 Dubbo 3.1 版本升级到 Dubbo 3.2 版本中的重大修改点，让用户在升级的时候能够清晰的了解其中的风险点，更好的规划升级节奏。

此外，对于目前人在大范围使用的 Dubbo 2.7 版本，在近期 Dubbo 社区也将推出针对 Dubbo 2.7 版本的升级的指南与工具，通过工程化的方式让所有的 Dubbo 2.7 用户都可以提前查出所有的版本差异点，平滑升级到 Dubbo 3 上来。

Blog: Dubbo 3.1.3、3.2.0-beta.2 正式发布

Tue, 29 Nov 2022 00:00:00 +0000

Dubbo 3.1.3

修改内容

修复本地调用的过程中 Filter 顺序异常的问题
支持导入协议配置项到 MetadataService
支持在发布 MetadataService 时自动选择可用端口
完善错误码内容
泛化调用下支持一致性哈希负载均衡
修复泛化调用时反序列化异常的问题
修复由于 JVM Methods 顺序不一致导致的应用级元数据无法复用的问题
默认关闭端口复用能力，修复 remoting 组建找不到 SPI 的问题
修复由于引用计数异常导致的 safe gard 问题
删除 Nacos 注册中心组建中使用的 guava 依赖
修复接口级使用 Nacos 注册中心时由于地址聚合导致的无法下线的问题
多个代码质量优化提交

新贡献者

@zhangzq7 在 #10847 中提交了第一个贡献
@akaakking 在 #10799 中提交了第一个贡献
@wxbty 在 #10921 中提交了第一个贡献
@haoxz11 在 #10937 中提交了第一个贡献

Dubbo 3.2.0-beta.2

修改内容

切换到在用户线程序列化，提升协议性能
支持 Netty3 的端口复用
修复存在多个用户配置的 providedBy 时不生效的问题
支持 istio 的 first-party-jwt 能力
删除 fastjson 和 gson 的传递依赖
支持可选 appResponse 不透传的能力
切换到 Fastjson2 为默认序列化依赖
完善注册中心推送的日志
修复路由刷新时机早于服务目录刷新时机的问题
关闭地址推空保护
更新支持 GraalVM Native 的 SPI 生成代码
支持使用 plain text 模式传输 xds 通道
支持 Nacos 批量注册，修复多注册覆盖的问题
支持 Spring Framework 6 and Spring Boot 3
多个代码质量优化提交
前述 Dubbo 3.1.3 的所有修改内容

新贡献者

@weixsun 在 #10941 中提交了第一个贡献

未来的版本规划

3.0、3.1、3.2 有什么区别？未来会怎么发展？发版周期是怎么样的？更多的版本迭代规划也将在近期推出，欢迎关注 Apache Dubbo 官方公众号获取最新的信息。

Blog: Apache Dubbo 多语言体系再添新员：首个 Rust 语言版本正式发布

Sun, 23 Oct 2022 00:00:00 +0000

Dubbo Rust 定位为 Dubbo 多语言体系的重要实现，提供高性能、易用、可扩展的 RPC 框架，同时通过接入 Dubbo Mesh 体系提供丰富的服务治理能力。本文主要为大家介绍 Dubbo Rust 项目基本情况，通过一个示例快速体验 Rust 首个正式版本特性，并给出了 Dubbo Rust 社区的近期规划，适合于关注或正在采用 Rust 语言的开发者与企业用户阅读。

1 Dubbo Rust 简介

Dubbo 作为 Apache 基金会最活跃的明星项目之一，同时也是国内最受欢迎的开源微服务框架，在易用性、高性能通信、服务治理等方面有着非常大的优势，通过 Dubbo3、Dubbo Mesh 等提供了云原生友好的开发与部署模式。与此同时，Dubbo 的多语言体系也得到了快速发展，长期以来提供的有 Java、Golang 两种语言实现，Rust、Node、Python、C++ 等语言实现的支持也已在社区正式启动。

Dubbo 官网 https://dubbo.apache.org/
Dubbo Java https://github.com/apache/dubbo/
Dubbo Golang https://github.com/apache/dubbo-go/
Dubbo Rust https://github.com/apache/dubbo-rust/

Dubbo Rust 目标是对齐 Dubbo3 的所有核心功能设计，包括基于 HTTP/2 的高性能通信、用户友好的微服务开发编程模式、通过接入DubboMesh提供丰富的服务治理能力等，相比于其他语言实现，Dubbo Rust 将很好的利用 Rust 语言极致性能、安全和指令级掌控能力的特点。对于微服务框架，主流的编程语言都有对应的实现，而 Dubbo Rust 将很好的填补 Rust 领域的空白：

Golang：在微服务框架领域已经占据着很重要的地位；开源社区出现了dubbo-go、gRPC、go-micro、go-zero等多个微服务框架
Java：国内用户量最大的编程语言，Spring Cloud、Dubbo等优秀的微服务框架已经非常流行
C/C++：brpc、grpc 等微服务框架
Rust：目前没有很完善的微服务框架

依托 Dubbo 庞大的用户群，以及 Dubbo 体系下的 Mesh 服务治理整体方案规划。Dubbo Rust 可以轻松地融入到现有的云原生研发体系中，不会增加使用者的研发负担。下图是社区推出的 Dubbo Mesh 架构设计。

在上述架构下，整体分为控制面和数据面两个部分，其中，

控制面负责管理流量治理、地址发现、安全认证、可观测性等服务治理相关的配置信管控工作，包括与K8S等底层技术设施的对接；
Dubbo Rust 作为数据面组件，负责接收来自控制面的配置；将配置应用到服务中；同时为服务提供基础的RPC通信能力。

在架构设计方面，Dubbo Rust 将围绕 Dubbo 核心设计以及 Rust 语言的特性进行设计，并将 Dubbo 框架的核心设计输出为文档，从而提升Dubbo框架的易用性。因此，Dubbo Rust 具有如下特点：易用性、高性能以及可扩展，同时面向云原生提供丰富的服务治理能力。

2 快速体验 Dubbo Rust

2.1 首个版本核心能力

Dubbo Rust 首个正式版本为 v0.2.0，v0.2.0 提供的能力包括

基于 HTTP/2 的 Triple 协议的基础通信能力
基于 IDL 的 RPC 定义支持，Protobuf 来生成代码，同时支持 Serde 序列化
request-response、request/response streaming、bi-streaming 通信模型支持
设计了简洁的、可扩展的架构，支持对 Listener、Connector、Filter、Protocol以及Invoker组件进行扩展

Dubbo Rust v0.2.0 的核心组件及通信流程如下图所示

核心架构已经基本完成，接下来的版本将重点关注核心组件的扩展以及服务治理相关组件的设计实现。

2.2 Quick Start

完整示例可查看【Dubbo官网】 -> 【Rust SDK 文档】。 https://dubbo.apache.org/zh/docs3-v2/rust-sdk/quick-start/

使用 Dubbo Rust 服务开发的基本步骤为

使用 IDL 定义服务
添加 Dubbo Rust 依赖到项目
编译 IDL
基于 IDL 编译生成的 stub 编写 Server & Client 逻辑
运行项目
使用 IDL 定义 Dubb 服务

```protobuf
// ./proto/greeter.proto
syntax = "proto3";

option java_multiple_files = true;

package org.apache.dubbo.sample.tri;


// The request message containing the user's name.
message GreeterRequest {
string name = 1;
}

// The response message containing the greetings
message GreeterReply {
string message = 1;
}

service Greeter{
// unary
rpc greet(GreeterRequest) returns (GreeterReply);
}

�

2. 增加 Dubbo Rust 依赖
```toml
```toml
# ./Cargo.toml
[package]
name = "example-greeter"
version = "0.1.0"
edition = "2021"

[dependencies]
dubbo = "0.1.0"
dubbo-config = "0.1.0"

[build-dependencies]
dubbo-build = "0.1.0"

�3. 编译 IDL 并根据生成的 stub 编写逻辑
编写 Dubbo Server
```rust
#[tokio::main]
async fn main() {
 register_server(GreeterServerImpl {
 name: "greeter".to_string(),
 });

 // Dubbo::new().start().await;
 Dubbo::new()
 .with_config({
 let r = RootConfig::new();
 match r.load() {
 Ok(config) => config,
 Err(_err) => panic!("err: {:?}", _err), // response was droped
 }
 })
 .start()
 .await;
}

struct GreeterServerImpl {
 name: String,
}

impl Greeter for GreeterServerImpl {
 async fn greet(
 &self,
 request: Request<GreeterRequest>,
 ) -> Result<Response<GreeterReply>, dubbo::status::Status> {
 println!("GreeterServer::greet {:?}", request.metadata);

 Ok(Response::new(GreeterReply {
 message: "hello, dubbo-rust".to_string(),
 }))
 }
}

� 编写 Dubbo Client

#[tokio::main]
async fn main() {
 let mut cli = GreeterClient::new().with_uri("http://127.0.0.1:8888".to_string());

 println!("# unary call");
 let resp = cli
 .greet(Request::new(GreeterRequest {
 name: "message from client".to_string(),
 }))
 .await;
 let resp = match resp {
 Ok(resp) => resp,
 Err(err) => return println!("{:?}", err),
 };
 let (_parts, body) = resp.into_parts();
 println!("Response: {:?}", body);
}

这样，一个简单的 Dubbo Rust 示例就开发完成了，可以到 Dubbo 官网查看完整文档。

3 Roadmap 与未来规划

Dubbo Rust Roadmap 规划分为三个阶段：

首先，提供作为 RPC 框架的基础能力，此阶段重点完成的包括基于 HTTP/2 的 RPC 通信、基于 IDL 的 RPC 定义、其他必要的 RPC 内核组件等
其实，是完善 Dubbo Rust 作为微服务框架的高级功能，此阶段包括微服务定义、配置、功能设计等，如服务超时、异步调用、上下文传递等，具体可参见 Dubbo Java 的高级特性。
第三阶段重点是引入丰富的服务治理能力支持，如流量治理、限流降级、可观测性等，这一目标将主要通过融入 Dubbo Mesh 体系，即适配 Dubbo Mesh 控制面实现。

其中，第一阶段的工作已经基本完成，大家可通过上文的 Quick Start 进行深入体验，第二、第三阶段的工作已经在社区全面开展，欢迎感兴趣的社区开发者参与进来，具体联系方式参见下文。

下图是侧重从第一阶段（RPC框架）、第二阶段（微服务开发框架）的视角对当前 Dubbo Rust 功能完备性的评估和任务拆解。

上图中都是 Dubbo Rust 核心设计的重要组件，保证 Dubbo Rust 具备微服务框架中完整的 RPC 通信能力以及服务治理能力。

Protocol、Filter、Listener、Connector 等组件都是 RPC 通信核心能力
服务注册发现、负载均衡、Cluster、Metadata 为后续服务治理能力做铺垫

除了上图列出的模块以外，还有一些非功能需求也需要支持，例如：

Dubbo 多语言框架之间相互通信测试
性能验证与持续的 benchmark 机制
整体架构的持续优化，如核心配置简化以及相应的文档完善

4 参与 Dubbo Rust 社区

和 Rust 语言一样，Dubbo Rust 是一个非常有活力、非常前沿的社区，另一方面，依赖 Apache Dubbo 社区背后庞大的开发者群体和企业用户，Dubbo Rust 有着非常深厚的用户基础和发展潜力。Dubbo Rust 的快速发展期待社区贡献者的加入参与 Dubbo Rust 社区可以收获

见证 Dubbo Rust 开源项目的建设以及发展
在大型项目中通过实际使用学习 Rust 语言，加深对 Rust 语言的理解
获得提名为 Apache Dubbo CommitterPMC
借助 Dubbo 社区提高个人曝光度，提高个人技术影响力
与阿里巴巴等企业专家的面对面交流机会，快速提高技术视野

参与 Dubbo Rust 社区的方式有如下几种

搜索并加入钉钉群并参与社区双周会，钉钉群号 44694199
到 GitHub 提 Issue 或贡献代码 https://github.com/apache/dubbo-rust

Blog: Proxyless Mesh在Dubbo中的实践

Mon, 05 Sep 2022 00:00:00 +0000

背景

随着 Dubbo 3.1 的 release，Dubbo 在云原生的路上又迈出了重要的一步。在这个版本中添加了 Proxyless Mesh 的新特性，Dubbo Proxyless Mesh 直接实现 xDS 协议解析，实现 Dubbo 与 Control Plane 的直接通信，进而实现控制面对流量管控、服务治理、可观测性、安全等的统一管控，规避 Sidecar 模式带来的性能损耗与部署架构复杂性。

什么是Service Mesh

Service Mesh 又译作 “服务网格”，作为服务间通信的基础设施层。Buoyant 公司的 CEO Willian Morgan 在他的这篇文章 WHAT’S A Service Mesh? AND WHY DO I NEED ONE? 中解释了什么是 Service Mesh，为什么云原生应用需要 Service Mesh。

下面是 Willian Morgan 对 Service Mesh 的解释。

A Service Mesh is a dedicated infrastructure layer for handling service-to-service communication.
It’s responsible for the reliable delivery of requests through the complex topology of services
that comprise a modern, cloud native application. In practice, the Service Mesh is typically implemented
as an array of lightweight network proxies that are deployed alongside application code, without the
application needing to be aware.

翻译成中文

服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。
在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。

说到 Service Mesh 一定离不开 Sidecar 经典架构模式。它通过在业务 Pod 中注入 Sidecar 容器，接管业务容器的通信流量，同时 Sidecar 容器与网格平台的控制平面对接，基于控制平面下发的策略，对代理流量实施治理和管控，将原有服务框架的治理能力下层到 Sidecar 容器中，从而实现了基础框架能力的下沉，与业务系统解耦。

经典的 Sidecar Mesh 部署架构有很多优势，如平滑升级、多语言、业务侵入小等，但也带来了一些额外的问题，比如:

Proxy 带来的性能损耗，在复杂拓扑的网络调用中将变得尤其明显
流量拦截带来的架构复杂性
Sidecar 生命周期管理
部署环境受限，并不是所有环境都满足 Sidecar 流量拦截条件

针对 Sidecar Mesh 模型的问题，Dubbo 社区自很早之前就做了 Dubbo 直接对接到控制面的设想与思考，并在国内开源社区率先提出了 Proxyless Mesh 的概念，当然就 Proxyless 概念的说法而言，最开始是谷歌提出来的。

Dubbo Proxyless Mesh

Dubbo Proxyless 模式是指 Dubbo 直接与 Istiod通信，通过 xDS协议实现服务发现和服务治理等能力。

Proxyless 模式使得微服务又回到了 2.x 时代的部署架构，同 Dubbo 经典服务治理模式非常相似，所以说这个模式并不新鲜， Dubbo 从最开始就是这样的设计模式。这样做可以极大的提升应用性能，降低网络延迟。有人说这种做法又回到了原始的基于 SDK 的微服务模式，其实非也，它依然使用了 Envoy 的 xDS API，但是因为不再需要向应用程序中注入 Sidecar 代理，因此可以减少应用程序性能的损耗。

但相比于 Mesh 架构，Dubbo 经典服务治理模式并没有强调控制面的统一管控，而这点恰好是 Service Mesh 所强调的，强调对流量、可观测性、证书等的标准化管控与治理，也是 Mesh 理念先进的地方。

在 Dubbo Proxyless 架构模式下，Dubbo 进程将直接与控制面通信，Dubbo 进程之间也继续保持直连通信模式，我们可以看出 Proxyless 架构的优势：

没有额外的 Proxy 中转损耗，因此更适用于性能敏感应用
更有利于遗留系统的平滑迁移
架构简单，容易运维部署
适用于几乎所有的部署环境

服务发现

xDS 接入以注册中心的模式对接，节点发现同其他注册中心的服务自省模型一样，对于 xDS 的负载均衡和路由配置通过 ServiceInstance 的动态运行时配置传出，在构建 Invoker 的时候将配置参数传入配置地址。

证书管理

零信任架构下，需要严格区分工作负载的识别和信任，而签发 X.509 证书是推荐的一种认证方式。在 Kubernetes 集群中，服务间是通过 DNS 名称互相访问的，而网络流量可能被 DNS 欺骗、BGP/路由劫持、ARP 欺骗等手段劫持，为了将服务名称（DNS 名称）与服务身份强关联起来，Istio 使用置于 X.509 证书中的安全命名机制。SPIFFE是 Istio 所采用的安全命名的规范，它也是云原生定义的一种标准化的、可移植的工作负载身份规范。

Secure Production Identity Framework For Everyone (SPIFFE) 是一套服务之间相互进行身份识别的标准，主要包含以下内容：

SPIFFE ID 标准，SPIFFE ID 是服务的唯一标识，具体实现使用 URI 资源标识符
SPIFFE Verifiable Identity Document (SVID) 标准，将 SPIFFE ID 编码到一个加密的可验证的数据格式中
颁发与撤销 SVID 的 API 标准（SVID 是 SPIFFE ID 的识别凭证）

SPIFFE ID 规定了形如 spiffe://<trust domain>/<workload identifier> 的 URI 格式，作为工作负载（Workload）的唯一标识。而 Istio 在自身的生态中只使用到了 SPIFFE ID 作为安全命名，其数据格式由自己实现，通信格式采用 CNCF 支持的 xDS 协议规范（证书认证通信更具体来说是 xDS 的 SDS）。

Istio 使用形如 spiffe://<trust_domain>/ns/<namespace>/sa/<service_account> 格式的 SPIFFE ID 作为安全命名，注入到 X.509 证书的 subjectAltName 扩展中。其中"trust_domain"参数通过 Istiod 环境变量TRUST_DOMAIN 注入，用于在多集群环境中交互。

以下是 Dubbo Proxyless Mesh 证书颁发的过程

创建 RSA 私钥（Istio 还不支持 ECDSA 私钥）
构建 CSR（Certificate signing request）模板
自签名 CSR 生成证书
创建 Kubernetes Secret 资源储存 CA 证书和私钥（CA Service处理）

案例实践

接下来我将带领大家通过一个例子使已有的项目快速跑在 Proxyless Mesh 模式下。

环境准备

安装docker

https://www.docker.com/

安装minikube

安装istio

https://istio.io/latest/docs/setup/getting-started/

❗❗❗ 安装 Istio 的时候需要开启 first-party-jwt 支持（使用 istioctl 工具安装的时候加上 –set values.global.jwtPolicy=first-party-jwt 参数），否则将导致客户端认证失败的问题。参考命令如下：

curl -L https://istio.io/downloadIstio | sh -
cd istio-1.xx.x
export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo --set values.global.jwtPolicy=first-party-jwt -y

代码准备

xds-provider

定义一个接口

public interface GreetingService {

 String sayHello(String name);
}

实现对应的接口

@DubboService(version = "1.0.0")
public class AnnotatedGreetingService implements GreetingService {

 @Override
 public String sayHello(String name) {
 System.out.println("greeting service received: " + name);
 return "hello, " + name + "! from host: " + NetUtils.getLocalHost();
 }
}

编写启动类

public class ProviderBootstrap {

 public static void main(String[] args) throws Exception {
 AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ProviderConfiguration.class);
 context.start();
 System.out.println("dubbo service started");
 new CountDownLatch(1).await();
 }

 @Configuration
 @EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.impl")
 @PropertySource("classpath:/spring/dubbo-provider.properties")
 static class ProviderConfiguration {
 }
}

编写配置信息

dubbo.application.name=dubbo-samples-xds-provider
# 由于 Dubbo 3 应用级服务发现的元数据无法从 istio 中获取，需要走服务自省模式。
# 这要求了 Dubbo MetadataService 的端口在全集群的是统一的。
dubbo.application.metadataServicePort=20885
# 走xds协议
dubbo.registry.address=xds://istiod.istio-system.svc:15012
dubbo.protocol.name=tri
dubbo.protocol.port=50051
# 对齐k8s pod生命周期，由于 Kubernetes probe 探活机制的工作原理限制，
# 探活请求的发起方不是 localhost，所以需要配置 qosAcceptForeignIp 参数开启允许全局访问
dubbo.application.qosEnable=true
dubbo.application.qosAcceptForeignIp=true

编写Deployment.yml和Service.yml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: dubbo-samples-xds-provider
 namespace: dubbo-demo
spec:
 replicas: 3
 selector:
 matchLabels:
 app: dubbo-samples-xds-provider
 template:
 metadata:
 labels:
 app: dubbo-samples-xds-provider
 spec:
 containers:
 - name: server
 image: apache/dubbo-demo:dubbo-samples-xds-provider_0.0.1
 livenessProbe:
 httpGet:
 path: /live
 port: 22222
 initialDelaySeconds: 5
 periodSeconds: 5
 readinessProbe:
 httpGet:
 path: /ready
 port: 22222
 initialDelaySeconds: 5
 periodSeconds: 5
 startupProbe:
 httpGet:
 path: /startup
 port: 22222
 failureThreshold: 30
 periodSeconds: 10

apiVersion: v1
kind: Service
metadata:
 name: dubbo-samples-xds-provider
 namespace: dubbo-demo
spec:
 clusterIP: None
 selector:
 app: dubbo-samples-xds-provider
 ports:
 - name: grpc
 protocol: TCP
 port: 50051
 targetPort: 50051

编写Dockerfile

FROM openjdk:8-jdk
ADD ./target/dubbo-samples-xds-provider-1.0-SNAPSHOT.jar dubbo-samples-xds-provider-1.0-SNAPSHOT.jar
CMD java -jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=31000 /dubbo-samples-xds-provider-1.0-SNAPSHOT.jar

xds-consumer

定义一个接口

public interface GreetingService {

 String sayHello(String name);
}

实现对应的接口

@Component("annotatedConsumer")
public class GreetingServiceConsumer {
 // 这里特别注意的是、由于当前 Dubbo 版本受限于 istio 的通信模型无法获取接口所对应的应用名，
 // 因此需要配置 providedBy 参数来标记此服务来自哪个应用。
 @DubboReference(version = "1.0.0", providedBy = "dubbo-samples-xds-provider")
 private GreetingService greetingService;

 public String doSayHello(String name) {
 return greetingService.sayHello(name);
 }
}

编写启动类

public class ConsumerBootstrap {

 public static void main(String[] args) {
 AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ConsumerConfiguration.class);
 context.start();
 GreetingServiceConsumer greetingServiceConsumer = context.getBean(GreetingServiceConsumer.class);
 while (true) {
 try {
 String hello = greetingServiceConsumer.doSayHello("xDS Consumer");
 System.out.println("result: " + hello);
 Thread.sleep(100);
 } catch (Throwable t) {
 t.printStackTrace();
 }
 }
 }

 @Configuration
 @EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.action")
 @PropertySource("classpath:/spring/dubbo-consumer.properties")
 @ComponentScan(value = {"org.apache.dubbo.samples.action"})
 static class ConsumerConfiguration {

 }
}

编写配置信息

dubbo.application.name=dubbo-samples-xds-consumer
dubbo.application.metadataServicePort=20885
dubbo.registry.address=xds://istiod.istio-system.svc:15012
dubbo.consumer.timeout=3000
dubbo.consumer.check=false
dubbo.application.qosEnable=true
dubbo.application.qosAcceptForeignIp=true

编写Deployment.yml和Service.yml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: dubbo-samples-xds-consumer
 namespace: dubbo-demo
spec:
 replicas: 2
 selector:
 matchLabels:
 app: dubbo-samples-xds-consumer
 template:
 metadata:
 labels:
 app: dubbo-samples-xds-consumer
 spec:
 containers:
 - name: server
 image: apache/dubbo-demo:dubbo-samples-xds-consumer_0.0.1
 livenessProbe:
 httpGet:
 path: /live
 port: 22222
 initialDelaySeconds: 5
 periodSeconds: 5
 readinessProbe:
 httpGet:
 path: /ready
 port: 22222
 initialDelaySeconds: 5
 periodSeconds: 5
 startupProbe:
 httpGet:
 path: /startup
 port: 22222
 failureThreshold: 30
 periodSeconds: 10

apiVersion: v1
kind: Service
metadata:
 name: dubbo-samples-xds-consumer
 namespace: dubbo-demo
spec:
 clusterIP: None
 selector:
 app: dubbo-samples-xds-consumer
 ports:
 - name: grpc
 protocol: TCP
 port: 50051
 targetPort: 50051

编写Dockerfile

FROM openjdk:8-jdk
ADD ./target/dubbo-samples-xds-consumer-1.0-SNAPSHOT.jar dubbo-samples-xds-consumer-1.0-SNAPSHOT.jar
CMD java -jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=31000 /dubbo-samples-xds-consumer-1.0-SNAPSHOT.jar

✅ 到目前为止我们的环境和代码就全都准备完毕了！

构建镜像

1、启动docker

2、启动minikube

因为minikube是一个本地的k8s，他启动需要一个虚拟引擎，这里我们用docker来管理。我们通过如下命令启动

minikube start

我们可以在docker里看到minikube

3、检查istio的状态

4、构建镜像

在本地找到代码所在位置、依次执行以下命令

# 找到provider所在路径
cd ./dubbo-samples-xds-provider/
# 构建provider的镜像
docker build -t apache/dubbo-demo:dubbo-samples-xds-provider_0.0.1 .

# 找到consumer所在路径
cd ../dubbo-samples-xds-consumer/
# 构建consumer的镜像
docker build -t apache/dubbo-demo:dubbo-samples-xds-consumer_0.0.1 .

5、检查本地镜像

6、创建namespace

# 初始化命名空间
kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/dubbo-samples-xds/deploy/Namespace.yml

# 切换命名空间
kubens dubbo-demo

如果不创建namespace，那么会看到如下错误

部署容器

# 找到provider所在路径
cd ./dubbo-samples-xds-provider/src/main/resources/k8s
# dubbo-samples-xds/dubbo-samples-xds-provider/src/main/resources/k8s/Deployment.yml
# dubbo-samples-xds/dubbo-samples-xds-provider/src/main/resources/k8s/Service.yml

# 部署provider的Deployment和Service
kubectl apply -f Deployment.yml
kubectl apply -f Service.yml

# 找到consumer所在路径
cd ../../../../../dubbo-samples-xds-consumer/src/main/resources/k8s
# dubbo-samples-xds/dubbo-samples-xds-consumer/src/main/resources/k8s/Deployment.yml

# 部署consumer的Deployment
kubectl apply -f Deployment.yml

在minikube dashboard看到我们已经部署的pod

观察consumer效果

kubectl logs xxx

result: hello, xDS Consumer! from host: 172.17.0.5
result: hello, xDS Consumer! from host: 172.17.0.5
result: hello, xDS Consumer! from host: 172.17.0.6
result: hello, xDS Consumer! from host: 172.17.0.6

总结&展望

本文主要剖析了 Dubbo Proxyless Mesh 的架构、服务发现以及证书管理等核心流程，最后通过示例给大家演示了如何使用 Dubbo Proxyless。

随着 Dubbo 3.1 的 release，Dubbo 在云原生的路上又迈出了重要的一步。在今年年底，Dubbo Mesh 将发布具有服务发现能力的版本，届时将面向所有 Dubbo 用户提供从低版本平滑迁移到 Mesh 架构的能力；在明年年初春季的时候将发布带有治理能力的版本；在明年年底前发布带热插件更新能力的版本，希望有兴趣见证 Dubbo 云原生之路的同学可以积极参与社区贡献！

更多关于 Dubbo Mesh 的动态可以关注 Apache Dubbo 社区官方公众号（ApacheDubbo），及时获取最新消息。

Blog: 22-Dubbo3消费者自动感应决策应用级服务发现原理

Mon, 22 Aug 2022 00:00:00 +0000

22-Dubbo3消费者自动感应决策应用级服务发现原理

22.1 简介

这里要说的内容对Dubbo2迁移到Dubbo3的应用比较有帮助，消费者应用级服务发现做了一些自动决策的逻辑来决定当前消费者是应用级发现还是接口级服务发现，这里与前面说的提供者双注册的原理是对等的，提供者默认同时进行应用级注册和接口级注册，消费者对提供者注册的数据来决定使用应用级发现或者接口级发现。这些都是默认的行为，当然对于消费者来说还可以自定义其他的迁移规则，具体的需要我们详细来看逻辑。

如果说对于迁移过程比较感兴趣可以直接去官网看文档相对来说还是比较清晰:https://dubbo.apache.org/zh/docs/migration/migration-service-discovery/

这里再借官网的图来用用，迁移过程主要如下所示：第一个图是提供者双注册的图：

第二个图是消费者订阅决策的图：

第三个图就是精确到消费者订阅的代码层的逻辑了，消费者服务间调用通过一个Invoker类型对象来进行对象，如下图所示消费者代理对象通过创建一个迁移容错的调用器对象来对应用级或者接口级订阅进行适配如下所示

第二个图和第三个图是重点要关注的这一个文章的内容主要就是说这里的逻辑。

关于代码位置如果不知道是如何调用到这一块逻辑的可以查看博文《21-Dubbo3消费者引用服务入口》

这里直接将代码位置定位到：RegistryProtocol类型的interceptInvoker方法中：如下所示：

RegistryProtocol类型的interceptInvoker方法

protected <T> Invoker<T> interceptInvoker(ClusterInvoker<T> invoker, URL url, URL consumerUrl) {
 //目前存在的扩展类型为RegistryProtocolListener监听器的实现类型MigrationRuleListener
 List<RegistryProtocolListener> listeners = findRegistryProtocolListeners(url);
 if (CollectionUtils.isEmpty(listeners)) {
 return invoker;
 }

 for (RegistryProtocolListener listener : listeners) {
 listener.onRefer(this, invoker, consumerUrl, url);
 }
 return invoker;
 }

该方法尝试加载所有RegistryProtocolListener定义，这些定义通过与定义的交互来控制调用器的行为，然后使用这些侦听器更改MigrationInvoker的状态和行为。当前可用的监听器是MigrationRuleListener，用于通过动态变化的规则控制迁移行为。

22.2 MigrationRuleListener 类型的onRefer方法

直接来看代码：

@Override
 public void onRefer(RegistryProtocol registryProtocol, ClusterInvoker<?> invoker, URL consumerUrl, URL registryURL) {
 //创建一个对应invoker对象的MigrationRuleHandler类型对象 然后将其存放在缓存Map<MigrationInvoker, MigrationRuleHandler>类型对象handles中
 MigrationRuleHandler<?> migrationRuleHandler = handlers.computeIfAbsent((MigrationInvoker<?>) invoker, _key -> {
 ((MigrationInvoker<?>) invoker).setMigrationRuleListener(this);
 return new MigrationRuleHandler<>((MigrationInvoker<?>) invoker, consumerUrl);
 });

 //迁移规则执行 rule是封装了迁移的配置规则的信息对应类型MigrationRule类型，在初始化对象的时候进行了配置初始化
 migrationRuleHandler.doMigrate(rule);
 }

关于这个igrationRule的文可以直接看官方的文档比较详细：地址迁移规则说明

这个迁移规则是为了更细粒度的迁移决策：相关配置可以参考下面这个样例：

key: 消费者应用名（必填）
step: 状态名（必填）
threshold: 决策阈值（默认1.0）
proportion: 灰度比例（默认100）
delay: 延迟决策时间（默认0）
force: 强制切换（默认 false）
interfaces: 接口粒度配置（可选）
 - serviceKey: 接口名（接口 + : + 版本号）（必填）
 threshold: 决策阈值
 proportion: 灰度比例
 delay: 延迟决策时间
 force: 强制切换
 step: 状态名（必填）
 - serviceKey: 接口名（接口 + : + 版本号）
 step: 状态名
applications: 应用粒度配置（可选）
 - serviceKey: 应用名（消费的上游应用名）（必填）
 threshold: 决策阈值
 proportion: 灰度比例
 delay: 延迟决策时间
 force: 强制切换
 step: 状态名（必填）

不过为了简单起见暂时先不详细说这个配置细节，我们继续往下看

22.3 迁移规则处理器执行迁移规则MigrationRuleHandler类型的doMigrate方法

22.3.1 迁移规则的模版方法：

MigrationRuleHandler类型的doMigrate方法代码如下：

public synchronized void doMigrate(MigrationRule rule) {
 //默认情况下这个类型是MigrationInvoker
 if (migrationInvoker instanceof ServiceDiscoveryMigrationInvoker) {
 refreshInvoker(MigrationStep.FORCE_APPLICATION, 1.0f, rule);
 return;
 }

 //迁移步骤，MigrationStep 一共有3种枚举情况：FORCE_INTERFACE, APPLICATION_FIRST, FORCE_APPLICATION
 // initial step : APPLICATION_FIRST
 MigrationStep step = MigrationStep.APPLICATION_FIRST;
 float threshold = -1f;

 try {
 //获取配置的类型 默认走APPLICATION_FIRST
 step = rule.getStep(consumerURL);
 //threshold: 决策阈值（默认-1.0）计算与获取
 threshold = rule.getThreshold(consumerURL);
 } catch (Exception e) {
 logger.error("Failed to get step and threshold info from rule: " + rule, e);
 }
 //刷洗调用器对象 来进行决策服务发现模式
 if (refreshInvoker(step, threshold, rule)) {
 // refresh success, update rule
 setMigrationRule(rule);
 }
 }

22.3.2 服务发现调用器对象的选择（决策服务发现策略）

这里就是关键代码了：通过迁移配置和当前提供者注册信息来决定创建什么类型的调用器对象（Invoker)来为后续服务调用做准备

MigrationRuleHandler的refreshInvoker，注意默认情况下这个step参数为APPLICATION_FIRST

 private boolean refreshInvoker(MigrationStep step, Float threshold, MigrationRule newRule) {
 if (step == null || threshold == null) {
 throw new IllegalStateException("Step or threshold of migration rule cannot be null");
 }
 MigrationStep originStep = currentStep;

 if ((currentStep == null || currentStep != step) || !currentThreshold.equals(threshold)) {
 boolean success = true;
 switch (step) {
 case APPLICATION_FIRST:
 //默认和配置了应用级优先的服务发现则走这里
 migrationInvoker.migrateToApplicationFirstInvoker(newRule);
 break;
 case FORCE_APPLICATION:
 //配置了应用级服务发现则走这里
 success = migrationInvoker.migrateToForceApplicationInvoker(newRule);
 break;
 case FORCE_INTERFACE:
 //配置了接口级服务发现则走这里
 default:
 success = migrationInvoker.migrateToForceInterfaceInvoker(newRule);
 }

 if (success) {
 setCurrentStepAndThreshold(step, threshold);
 logger.info("Succeed Migrated to " + step + " mode. Service Name: " + consumerURL.getDisplayServiceKey());
 report(step, originStep, "true");
 } else {
 // migrate failed, do not save new step and rule
 logger.warn("Migrate to " + step + " mode failed. Probably not satisfy the threshold you set "
 + threshold + ". Please try re-publish configuration if you still after check.");
 report(step, originStep, "false");
 }

 return success;
 }
 // ignore if step is same with previous, will continue override rule for MigrationInvoker
 return true;
 }

可以看到这个代码做了判断的逻辑分别对应了Dubbo3消费者迁移的一个状态逻辑：三种状态分别如下枚举类型：当前共存在三种状态，

FORCE_INTERFACE（强制接口级）
APPLICATION_FIRST（应用级优先）
FORCE_APPLICATION（强制应用级）

通过代码我们可以看到默认情况下都会走APPLICATION_FIRST（应用级优先）的策略，这里我们也重点来说 APPLICATION_FIRST（应用级优先）来看下Dubbo3是如何决策使用接口级还是应用级发现模型来兼容迁移的服务的。

22.3.3 应用级优先的服务发现规则逻辑

这个规则就是智能选择应用级还是接口级的代码了，对应类型为MigrationInvoker的migrateToApplicationFirstInvoker方法，接下来我们详细看下：

MigrationInvoker类型的migrateToApplicationFirstInvoker方法：

@Override
 public void migrateToApplicationFirstInvoker(MigrationRule newRule) {
 CountDownLatch latch = new CountDownLatch(0);
 //刷新接口级服务发现Invoker
 refreshInterfaceInvoker(latch);
 //刷新应用级服务发现Invoker类型对象
 refreshServiceDiscoveryInvoker(latch);

 // directly calculate preferred invoker, will not wait until address notify
 // calculation will re-occurred when address notify later
 //计算当前使用应用级还是接口级服务发现的Invoker对象
 calcPreferredInvoker(newRule);
 }

22.3.4 刷新接口级服务发现Invoker

MigrationInvoker类型的refreshInterfaceInvoker方法

protected void refreshInterfaceInvoker(CountDownLatch latch) {
 clearListener(invoker);
 if (needRefresh(invoker)) {
 if (logger.isDebugEnabled()) {
 logger.debug("Re-subscribing interface addresses for interface " + type.getName());
 }

 if (invoker != null) {
 invoker.destroy();
 }
 invoker = registryProtocol.getInvoker(cluster, registry, type, url);
 }
 setListener(invoker, () -> {
 latch.countDown();
 if (reportService.hasReporter()) {
 reportService.reportConsumptionStatus(
 reportService.createConsumptionReport(consumerUrl.getServiceInterface(), consumerUrl.getVersion(), consumerUrl.getGroup(), "interface"));
 }
 if (step == APPLICATION_FIRST) {
 calcPreferredInvoker(rule);
 }
 });
 }

22.3.5 刷新应用级服务发现Invoker类型对象

MigrationInvoker类型的refreshServiceDiscoveryInvoker方法

protected void refreshServiceDiscoveryInvoker(CountDownLatch latch) {
 clearListener(serviceDiscoveryInvoker);
 if (needRefresh(serviceDiscoveryInvoker)) {
 if (logger.isDebugEnabled()) {
 logger.debug("Re-subscribing instance addresses, current interface " + type.getName());
 }

 if (serviceDiscoveryInvoker != null) {
 serviceDiscoveryInvoker.destroy();
 }
 serviceDiscoveryInvoker = registryProtocol.getServiceDiscoveryInvoker(cluster, registry, type, url);
 }
 setListener(serviceDiscoveryInvoker, () -> {
 latch.countDown();
 if (reportService.hasReporter()) {
 reportService.reportConsumptionStatus(
 reportService.createConsumptionReport(consumerUrl.getServiceInterface(), consumerUrl.getVersion(), consumerUrl.getGroup(), "app"));
 }
 if (step == APPLICATION_FIRST) {
 calcPreferredInvoker(rule);
 }
 });
 }

22.3.6 计算当前使用应用级还是接口级服务发现的Invoker对象

MigrationInvoker类型的的calcPreferredInvoker方法

private synchronized void calcPreferredInvoker(MigrationRule migrationRule) {
 if (serviceDiscoveryInvoker == null || invoker == null) {
 return;
 }
 Set<MigrationAddressComparator> detectors = ScopeModelUtil.getApplicationModel(consumerUrl == null ? null : consumerUrl.getScopeModel())
 .getExtensionLoader(MigrationAddressComparator.class).getSupportedExtensionInstances();
 if (CollectionUtils.isNotEmpty(detectors)) {
 // pick preferred invoker
 // the real invoker choice in invocation will be affected by promotion
 if (detectors.stream().allMatch(comparator -> comparator.shouldMigrate(serviceDiscoveryInvoker, invoker, migrationRule))) {
 this.currentAvailableInvoker = serviceDiscoveryInvoker;
 } else {
 this.currentAvailableInvoker = invoker;
 }
 }
 }

currentAvailableInvoker是后期服务调用使用的Invoker对象

原文地址：22-Dubbo3消费者自动感应决策应用级服务发现原理

Blog: 21-Dubbo3消费者引用服务入口

Sun, 21 Aug 2022 00:00:00 +0000

21-Dubbo3消费者引用服务入口

21.1 简介

前面我们通过Demo说了一个服务引用配置的创建。另外也在前面的文章说了服务提供者的启动完整过程，不过在说服务提供者启动的过程中并未提到服务消费者是如何发现服务，如果调用服务的，这里先就不再说关于服务消费者启动的一个细节了，直接来看前面未提到的服务消费者是如何引用到服务提供者提供的服务的。先来回顾下样例代码：

public class ConsumerApplication {
 public static void main(String[] args) {
 runWithBootstrap();
 }
 private static void runWithBootstrap() {
 ReferenceConfig<DemoService> reference = new ReferenceConfig<>();
 reference.setInterface(DemoService.class);
 reference.setGeneric("true");
 reference.setProtocol("");

 DubboBootstrap bootstrap = DubboBootstrap.getInstance();
 ApplicationConfig applicationConfig = new ApplicationConfig("dubbo-demo-api-consumer");
 applicationConfig.setQosEnable(false);
 applicationConfig.setQosPort(-1);
 bootstrap.application(applicationConfig)
 .registry(new RegistryConfig("zookeeper://8.131.79.126:2181"))
 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
 .reference(reference)
 .start();

 DemoService demoService = bootstrap.getCache().get(reference);
 String message = demoService.sayHello("dubbo");
 System.out.println(message);

 // generic invoke
 GenericService genericService = (GenericService) demoService;
 Object genericInvokeResult = genericService.$invoke("sayHello", new String[]{String.class.getName()},
 new Object[]{"dubbo generic invoke"});
 System.out.println(genericInvokeResult);
 }
}

这段代码我们前面详细说了服务引用的配置ReferenceConfig和Dubbo启动器启动应用的过程DubboBootstrap，后面我们直接定位到消费者引用服务的代码位置来看。

21.2 入口代码

21.2.1 DefaultModuleDeployer的start方法

第一个要关注的就是模块发布器DefaultModuleDeployer的start方法，这个start方法包含了Dubbo应用启动的过程

DefaultModuleDeployer的start方法

public synchronized Future start() throws IllegalStateException {
 ...省略掉若干代码

 onModuleStarting();

 // initialize
 applicationDeployer.initialize();
 initialize();

 // export services
 exportServices();

 // prepare application instance
 // exclude internal module to avoid wait itself
 if (moduleModel != moduleModel.getApplicationModel().getInternalModule()) {
 applicationDeployer.prepareInternalModule();
 }

 // refer services
 referServices();

 ...省略掉若干代码
 return startFuture;
 }

这个方法大部分代码已经省略，也不会详细去说了，感兴趣的可以看之前讲到的博客，这里主要来看引用服务方法referServices

21.2.2 DefaultModuleDeployer的referServices方法

下面就要来看消费者应用如何引用的服务的入口了，这个方法主要从大的方面做了一些服务引用生命周期的代码，看懂了这个方法我们就可以不依赖Dubbo负载的启动逻辑可以单独调用ReferenceConfigBase类型的对应方法来刷新，启动，销毁引用的服务了这里先来看下代码再详细介绍内容：

DefaultModuleDeployer的referServices方法

 private void referServices() {
 //这个是获取配置的所有的ReferenceConfigBase类型对象
 configManager.getReferences().forEach(rc -> {
 try {
 ReferenceConfig<?> referenceConfig = (ReferenceConfig<?>) rc;
 if (!referenceConfig.isRefreshed()) {
 //刷新引用配置
 referenceConfig.refresh();
 }

 if (rc.shouldInit()) {
 if (referAsync || rc.shouldReferAsync()) {
 ExecutorService executor = executorRepository.getServiceReferExecutor();
 CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
 try {
 //间接的通过缓存对象来引用服务配置
 referenceCache.get(rc);
 } catch (Throwable t) {
 logger.error(getIdentifier() + " refer async catch error : " + t.getMessage(), t);
 }
 }, executor);

 asyncReferringFutures.add(future);
 } else {
 //间接的通过缓存对象来引用服务配置
 referenceCache.get(rc);
 }
 }
 } catch (Throwable t) {
 logger.error(getIdentifier() + " refer catch error.");
 //出现异常销毁引用配置
 referenceCache.destroy(rc);
 throw t;
 }
 });
 }

在这个代码中我们核心需要关心的就是SimpleReferenceCache类型的get方法了，在获取服务对象之外包装了一层缓存。

如果出现了异常则执行referenceCache的destroy方法进行销毁引用配置。

21.3 开始引用服务

21.3.1 SimpleReferenceCache是什么？

一个用于缓存引用ReferenceConfigBase的util工具类。 ReferenceConfigBase是一个重对象，对于频繁创建ReferenceConfigBase的框架来说，有必要缓存这些对象。如果需要使用复杂的策略，可以实现并使用自己的ReferenceConfigBase缓存这个Cache是引用服务的开始如果我们想在代码中自定义一些服务引用的逻辑，可以直接创建SimpleReferenceCache类型对象然后调用其get方法进行引用服务。那这个缓存对象是和缓存与引用服务的可以继续往下看。

21.3.2 引用服务之前的缓存处理逻辑？

关于逻辑的处理，看代码有时候比文字更清晰明了，这里可以直接来看 SimpleReferenceCache类型的get方法

 @Override
 @SuppressWarnings("unchecked")
 public <T> T get(ReferenceConfigBase<T> rc) {
 //这个生成的key规则是这样的 服务分组/服务接口:版本号 详细的代码就不看了
 //例如： group/link.elastic.dubbo.entity.DemoService:1.0
 String key = generator.generateKey(rc);
 //服务类型 如果是泛化调用则这个类型为GenericService
 Class<?> type = rc.getInterfaceClass();

 //服务是否为单例的这里默认值都为空，为单例模式
 boolean singleton = rc.getSingleton() == null || rc.getSingleton();
 T proxy = null;
 // Check existing proxy of the same 'key' and 'type' first.
 if (singleton) {
 //一般为单例的 这个方法是从缓存中获取
 proxy = get(key, (Class<T>) type);
 } else {
 //非单例容易造成内存泄露，无法从缓存中获取
 logger.warn("Using non-singleton ReferenceConfig and ReferenceCache at the same time may cause memory leak. " +
 "Call ReferenceConfig#get() directly for non-singleton ReferenceConfig instead of using ReferenceCache#get(ReferenceConfig)");
 }
 //前面是从缓存中拿，如果缓存中获取不到则开始引用服务
 if (proxy == null) {
 //获取或者创建值，为引用类型referencesOfType对象（类型为Map<Class<?>, List<ReferenceConfigBase<?>>>）缓存对象生成值（值不存咋时候会生成一个）
 List<ReferenceConfigBase<?>> referencesOfType = referenceTypeMap.computeIfAbsent(type, _t -> Collections.synchronizedList(new ArrayList<>()));
 //每次走到这里都会添加一个ReferenceConfigBase 引用配置对象（单例的从缓存中拿到就可以直接返回了）
 referencesOfType.add(rc);

 //与前面一样 前面是类型映射，这里是key映射
 List<ReferenceConfigBase<?>> referenceConfigList = referenceKeyMap.computeIfAbsent(key, _k -> Collections.synchronizedList(new ArrayList<>()));
 referenceConfigList.add(rc);
 //开始引用服务
 proxy = rc.get();
 }

 return proxy;
 }

可以看到这个逻辑使用了享元模式（其实就是先查缓存，缓存不存在则创建对象存入缓存）来进行引用对象的管理这样一个过程，这里一共有两个缓存对象referencesOfType和referenceConfigList key分别为引用类型和引用的服务的key，值是引用服务的基础配置对象列表List<ReferenceConfigBase>

后面可以详细看下如果借助ReferenceConfigBase类型对象来进行具体类型的引用。

21.4 初始化引用服务的过程

21.4.1 初始化引用服务的调用入口

引用服务的逻辑其实是相对复杂一点的，包含了服务发现，引用对象的创建等等，接下来就让我们详细看下:

ReferenceConfig类型的get方法

@Override
 public T get() {
 if (destroyed) {
 throw new IllegalStateException("The invoker of ReferenceConfig(" + url + ") has already destroyed!");
 }

 //ref类型为 transient volatile T ref;
 if (ref == null) {
 // ensure start module, compatible with old api usage
 //这个前面已经调用了模块发布器启动过了，这里有这么一行代码是有一定作用的，如果使用方直接调用了ReferenceConfigBase的get方法或者缓存对象SimpleReferenceCache类型的对象的get方法来引用服务端的时候就会造成很多配置没有初始化下面执行逻辑的时候出现问题，这个代码其实就是启动模块进行一些基础配置的初始化操作 比如元数据中心默认配置选择，注册中心默认配置选择这些都是比较重要的
 getScopeModel().getDeployer().start();

 synchronized (this) {
 if (ref == null) {
 init();
 }
 }
 }

 return ref;
 }

这里有一段代码是：getScopeModel().getDeployer().start(); 这个前面已经调用了模块发布器启动过了，这里有这么一行代码是有一定作用的，如果使用方直接调用了ReferenceConfigBase的get方法或者缓存对象SimpleReferenceCache类型的对象的get方法来引用服务端的时候就会造成很多配置没有初始化下面执行逻辑的时候出现问题，这个代码其实就是启动模块进行一些基础配置的初始化操作比如元数据中心默认配置选择，注册中心默认配置选择这些都是比较重要的。

另外可以看到的是这里使用了双重校验锁来保证单例对象的创建，发现Dubbo种大量的使用了双重校验锁的逻辑。

21.4.2 初始化引用服务

这个就直接看代码了这，初始化过程相对复杂一点，我们一点点来看 ReferenceConfig类型init()方法

protected synchronized void init() {
 //初始化标记变量保证只初始化一次，这里又是加锁🔐又是加标记变量的
 if (initialized) {
 return;
 }
 initialized = true;
 //刷新配置
 if (!this.isRefreshed()) {
 this.refresh();
 }

 // init serviceMetadata
 //初始化ServiceMetadata类型对象serviceMetadata 为其设置服务基本属性比如版本号，分组，服务接口名
 initServiceMetadata(consumer);

 //继续初始化元数据信息 服务接口类型和key
 serviceMetadata.setServiceType(getServiceInterfaceClass());
 // TODO, uncomment this line once service key is unified
 serviceMetadata.setServiceKey(URL.buildKey(interfaceName, group, version));

 //配置转Map类型
 Map<String, String> referenceParameters = appendConfig();
 // init service-application mapping
 //来自本地存储和url参数的初始化映射。 参数转URL配置初始化 Dubbo中喜欢用url作为配置的一种处理方式
 initServiceAppsMapping(referenceParameters);
 //本地内存模块服务存储库
 ModuleServiceRepository repository = getScopeModel().getServiceRepository();
 //ServiceModel和ServiceMetadata在某种程度上是相互重复的。我们将来应该合并它们。
 ServiceDescriptor serviceDescriptor;
 if (CommonConstants.NATIVE_STUB.equals(getProxy())) {
 serviceDescriptor = StubSuppliers.getServiceDescriptor(interfaceName);
 repository.registerService(serviceDescriptor);
 } else {
 //本地存储库注册服务接口类型
 serviceDescriptor = repository.registerService(interfaceClass);
 }
 //消费者模型对象
 consumerModel = new ConsumerModel(serviceMetadata.getServiceKey(), proxy, serviceDescriptor, this,
 getScopeModel(), serviceMetadata, createAsyncMethodInfo());
 //本地存储库注册消费者模型对象
 repository.registerConsumer(consumerModel);

 //与前面代码一样基础初始化服务元数据对象为其设置附加参数
 serviceMetadata.getAttachments().putAll(referenceParameters);
 //创建服务的代理对象 ！！！核心代码在这里
 ref = createProxy(referenceParameters);

 //为服务元数据对象设置代理对象
 serviceMetadata.setTarget(ref);
 serviceMetadata.addAttribute(PROXY_CLASS_REF, ref);

 consumerModel.setProxyObject(ref);
 consumerModel.initMethodModels();

 //检查invoker对象初始结果
 checkInvokerAvailable();
 }

21.5 ReferenceConfig创建服务引用代理对象的原理

21.5.1 代理对象的创建过程

这里就要继续看 ReferenceConfig类型的创建代理方法createProxy了直接贴一下源码：

 private T createProxy(Map<String, String> referenceParameters) {
 //本地引用 这里为false
 if (shouldJvmRefer(referenceParameters)) {
 createInvokerForLocal(referenceParameters);
 } else {
 urls.clear();
 if (StringUtils.isNotEmpty(url)) {
 //url存在则为点对点引用
 // user specified URL, could be peer-to-peer address, or register center's address.
 parseUrl(referenceParameters);
 } else {
 // if protocols not in jvm checkRegistry
 //这里不是local协议默认这里为空
 if (!LOCAL_PROTOCOL.equalsIgnoreCase(getProtocol())) {
 //从注册表中获取URL并将其聚合。这个其实就是初始化一下注册中心的url配置
 aggregateUrlFromRegistry(referenceParameters);
 }
 }
 //这个代码非常重要 创建远程引用，创建远程引用调用器
 createInvokerForRemote();
 }

 if (logger.isInfoEnabled()) {
 logger.info("Referred dubbo service: [" + referenceParameters.get(INTERFACE_KEY) + "]." +
 (Boolean.parseBoolean(referenceParameters.get(GENERIC_KEY)) ?
 " it's GenericService reference" : " it's not GenericService reference"));
 }

 URL consumerUrl = new ServiceConfigURL(CONSUMER_PROTOCOL, referenceParameters.get(REGISTER_IP_KEY), 0,
 referenceParameters.get(INTERFACE_KEY), referenceParameters);
 consumerUrl = consumerUrl.setScopeModel(getScopeModel());
 consumerUrl = consumerUrl.setServiceModel(consumerModel);
 MetadataUtils.publishServiceDefinition(consumerUrl, consumerModel.getServiceModel(), getApplicationModel());

 // create service proxy
 return (T) proxyFactory.getProxy(invoker, ProtocolUtils.isGeneric(generic));
 }

21.5.2 创建远程引用，创建远程引用调用器

ReferenceConfig类型的createInvokerForRemote方法

private void createInvokerForRemote() {
 //这个url 为注册协议如registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-consumer&dubbo=2.0.2&pid=6204&qos.enable=false&qos.port=-1&registry=zookeeper&release=3.0.9&timestamp=1657439419495
 if (urls.size() == 1) {
 URL curUrl = urls.get(0);
 //这个SPI对象是由字节码动态生成的自适应对象Protocol$Adaptie直接看看不到源码，后续可以解析一个字节码生成的类型，这里后续来调用链路即可
 invoker = protocolSPI.refer(interfaceClass, curUrl);
 if (!UrlUtils.isRegistry(curUrl)) {
 List<Invoker<?>> invokers = new ArrayList<>();
 invokers.add(invoker);
 invoker = Cluster.getCluster(scopeModel, Cluster.DEFAULT).join(new StaticDirectory(curUrl, invokers), true);
 }
 } else {
 List<Invoker<?>> invokers = new ArrayList<>();
 URL registryUrl = null;
 for (URL url : urls) {
 // For multi-registry scenarios, it is not checked whether each referInvoker is available.
 // Because this invoker may become available later.
 invokers.add(protocolSPI.refer(interfaceClass, url));

 if (UrlUtils.isRegistry(url)) {
 // use last registry url
 registryUrl = url;
 }
 }

 if (registryUrl != null) {
 // registry url is available
 // for multi-subscription scenario, use 'zone-aware' policy by default
 String cluster = registryUrl.getParameter(CLUSTER_KEY, ZoneAwareCluster.NAME);
 // The invoker wrap sequence would be: ZoneAwareClusterInvoker(StaticDirectory) -> FailoverClusterInvoker
 // (RegistryDirectory, routing happens here) -> Invoker
 invoker = Cluster.getCluster(registryUrl.getScopeModel(), cluster, false).join(new StaticDirectory(registryUrl, invokers), false);
 } else {
 // not a registry url, must be direct invoke.
 if (CollectionUtils.isEmpty(invokers)) {
 throw new IllegalArgumentException("invokers == null");
 }
 URL curUrl = invokers.get(0).getUrl();
 String cluster = curUrl.getParameter(CLUSTER_KEY, Cluster.DEFAULT);
 invoker = Cluster.getCluster(scopeModel, cluster).join(new StaticDirectory(curUrl, invokers), true);
 }
 }
 }

21.5.3 Invoker对象创建的全过程

为了更好理解Protocol$Adaptie内部的引用执行过程这里我把Debug的链路截图了过来按照固定的顺序先执行AOP的逻辑再执行具体的逻辑:

Protocol$Adaptie的refer方法
ProtocolSerializationWrapper AOP类型的协议序列化器refer方法
ProtocolFilterWrapper AOP类型的协议过滤器的refer方法
QosProtocolWrapper AOP类型的QOS协议包装器的refer方法
ProtocolListenerWrapper APO类型监听器包装器的refer方法
RegistryProtocol 注册协议的refer方法（会添加容错逻辑）
RegistryProtocol 注册协议的doRefer方法（调用方法创建Invoker对象）

这里我们不再详细说这个引用链的具体过程直接定位到RegistryProtocol中创建Invoker类型的地方。先来看RegistryProtocol类型的refer方法，如下代码所示：

RegistryProtocol类型的refer方法

@Override
 @SuppressWarnings("unchecked")
 public <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException {
 //这个url已经被转换为具体的注册中心协议类型了
 //zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-consumer&dubbo=2.0.2&pid=7944&qos.enable=false&qos.port=-1&release=3.0.9&timestamp=1657440673100
 url = getRegistryUrl(url);
 //获取用于操作Zookeeper的Registry类型
 Registry registry = getRegistry(url);
 if (RegistryService.class.equals(type)) {
 return proxyFactory.getInvoker((T) registry, type, url);
 }

 // group="a,b" or group="*"
 Map<String, String> qs = (Map<String, String>) url.getAttribute(REFER_KEY);
 String group = qs.get(GROUP_KEY);
 if (StringUtils.isNotEmpty(group)) {
 if ((COMMA_SPLIT_PATTERN.split(group)).length > 1 || "*".equals(group)) {
 return doRefer(Cluster.getCluster(url.getScopeModel(), MergeableCluster.NAME), registry, type, url, qs);
 }
 }
 //降级容错的逻辑处理对象 类型为Cluster 实际类型为MockClusterWrapper 内部包装的是FailoverCluster
 //后续调用服务失败时候会先失效转移再降级
 Cluster cluster = Cluster.getCluster(url.getScopeModel(), qs.get(CLUSTER_KEY));
 //这里才是具体的Invoker对象的创建
 return doRefer(cluster, registry, type, url, qs);
 }

RegistryProtocol类型的doRefer方法创建Invoker对象直接来看代码了

 protected <T> Invoker<T> doRefer(Cluster cluster, Registry registry, Class<T> type, URL url, Map<String, String> parameters) {
 Map<String, Object> consumerAttribute = new HashMap<>(url.getAttributes());
 consumerAttribute.remove(REFER_KEY);
 String p = isEmpty(parameters.get(PROTOCOL_KEY)) ? CONSUMER : parameters.get(PROTOCOL_KEY);
 URL consumerUrl = new ServiceConfigURL (
 p,
 null,
 null,
 parameters.get(REGISTER_IP_KEY),
 0, getPath(parameters, type),
 parameters,
 consumerAttribute
 );
 url = url.putAttribute(CONSUMER_URL_KEY, consumerUrl);
 //重点看这一行 带迁移性质的Invoker对象
 ClusterInvoker<T> migrationInvoker = getMigrationInvoker(this, cluster, registry, type, url, consumerUrl);
 //这一行回来执行迁移规则创建应用级优先的服务发现Invoker对象
 return interceptInvoker(migrationInvoker, url, consumerUrl);
 }

这里代码比较重要的其实只有两行getMigrationInvoker和interceptInvoker方法比较核心也是Dubbo3比较重要的消费者启动逻辑基本都在这个方法里面interceptInvoker，这个方法执行了消费者应用级发现和接口级发现迁移的逻辑，会自动帮忙决策一个Invoker类型对象，不过这个逻辑这里先简单看下，后续单独整个文章来说。

这里我们先来看 ClusterInvoker对象的创建，下面先看代码：

RegistryProtocol类型的getMigrationInvoker方法

 protected <T> ClusterInvoker<T> getMigrationInvoker(RegistryProtocol registryProtocol, Cluster cluster, Registry registry, Class<T> type, URL url, URL consumerUrl) {
 return new ServiceDiscoveryMigrationInvoker<T>(registryProtocol, cluster, registry, type, url, consumerUrl);
 }

详细的逻辑这里就不再看了，我们继续看RegistryProtocol类型的interceptInvoker方法：

具体代码如下： RegistryProtocol类型的interceptInvoker方法

 protected <T> Invoker<T> interceptInvoker(ClusterInvoker<T> invoker, URL url, URL consumerUrl) {
 //获取激活的注册协议监听器扩展里面registry.protocol.listener，这里激活的类型为MigrationRuleListener
 List<RegistryProtocolListener> listeners = findRegistryProtocolListeners(url);
 if (CollectionUtils.isEmpty(listeners)) {
 return invoker;
 }

 for (RegistryProtocolListener listener : listeners) {
 //这里执行MigrationRuleListener类型的onRefer方法
 listener.onRefer(this, invoker, consumerUrl, url);
 }
 return invoker;
 }

可以看到核心的逻辑集中在了这个位置MigrationRuleListener类型的onRefer方法，这个这里就不深入往下说了，后续会有个文章专门来看Dubbo2迁移Dubbo3时候处理的逻辑。

Invoker对象的创建完成其实就代表了服务引用执行完成，不过这里核心的协议并没有来说

原文地址：21-Dubbo3消费者引用服务入口

Blog: 20-Dubbo3服务引用配置ReferenceConfig

Sat, 20 Aug 2022 00:00:00 +0000

20-Dubbo3服务引用配置ReferenceConfig

20.1 简介

前面简单介绍了一下消费者的例子，消费者创建的第一步就是先进行消费者信息的配置对应类型为ReferenceConfig，这里详细来看ReferenceConfig包含哪些信息？先简单了解下消费者配置的类型关系如下图所示：引用配置与服务配置类型都是通过继承接口配置来扩展的，在分析生产者的时候详细介绍过服务相关的配置，这里来详细看消费者引用者的相关配置信息.

前面例子说了消费者配置对象的创建主要是通过如下代码：

ReferenceConfig<DemoService> reference = new ReferenceConfig<>();

这个配置类型的对象创建过程并没有太多的逻辑这里主要来说下各种配置信息：服务消费者引用服务配置。对应的配置类： org.apache.dubbo.config.ReferenceConfig

属性	对应URL参数	类型	是否必填	缺省值	作用	描述	兼容性
id		string	必填		配置关联	服务引用BeanId	1.0.0以上版本
interface		class	必填		服务发现	服务接口名	1.0.0以上版本
version	version	string	可选		服务发现	服务版本，与服务提供者的版本一致	1.0.0以上版本
group	group	string	可选		服务发现	服务分组，当一个接口有多个实现，可以用分组区分，必需和服务提供方一致	1.0.7以上版本
timeout	timeout	long	可选	缺省使用dubbo:consumer的timeout	性能调优	服务方法调用超时时间(毫秒)	1.0.5以上版本
retries	retries	int	可选	缺省使用dubbo:consumer的retries	性能调优	远程服务调用重试次数，不包括第一次调用，不需要重试请设为0	2.0.0以上版本
connections	connections	int	可选	缺省使用dubbo:consumer的connections	性能调优	对每个提供者的最大连接数，rmi、http、hessian等短连接协议表示限制连接数，dubbo等长连接协表示建立的长连接个数	2.0.0以上版本
loadbalance	loadbalance	string	可选	缺省使用dubbo:consumer的loadbalance	性能调优	负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮询，最少活跃调用	2.0.0以上版本
async	async	boolean	可选	缺省使用dubbo:consumer的async	性能调优	是否异步执行，不可靠异步，只是忽略返回值，不阻塞执行线程	2.0.0以上版本
generic	generic	boolean	可选	缺省使用dubbo:consumer的generic	服务治理	是否缺省泛化接口，如果为泛化接口，将返回GenericService	2.0.0以上版本
check	check	boolean	可选	缺省使用dubbo:consumer的check	服务治理	启动时检查提供者是否存在，true报错，false忽略	2.0.0以上版本
url	url	string	可选		服务治理	点对点直连服务提供者地址，将绕过注册中心	1.0.6以上版本
stub	stub	class/boolean	可选		服务治理	服务接口客户端本地代理类名，用于在客户端执行本地逻辑，如本地缓存等，该本地代理类的构造函数必须允许传入远程代理对象，构造函数如：public XxxServiceLocal(XxxService xxxService)	2.0.0以上版本
mock	mock	class/boolean	可选		服务治理	服务接口调用失败Mock实现类名，该Mock类必须有一个无参构造函数，与Local的区别在于，Local总是被执行，而Mock只在出现非业务异常(比如超时，网络异常等)时执行，Local在远程调用之前执行，Mock在远程调用后执行。	Dubbo1.0.13及其以上版本支持
cache	cache	string/boolean	可选		服务治理	以调用参数为key，缓存返回结果，可选：lru, threadlocal, jcache等	Dubbo2.1.0及其以上版本支持
validation	validation	boolean	可选		服务治理	是否启用JSR303标准注解验证，如果启用，将对方法参数上的注解进行校验	Dubbo2.1.0及其以上版本支持
proxy	proxy	boolean	可选	javassist	性能调优	选择动态代理实现策略，可选：javassist, jdk	2.0.2以上版本
client	client	string	可选		性能调优	客户端传输类型设置，如Dubbo协议的netty或mina。	Dubbo2.0.0以上版本支持
registry		string	可选	缺省将从所有注册中心获服务列表后合并结果	配置关联	从指定注册中心注册获取服务列表，在多个注册中心时使用，值为dubbo:registry的id属性，多个注册中心ID用逗号分隔	2.0.0以上版本
owner	owner	string	可选		服务治理	调用服务负责人，用于服务治理，请填写负责人公司邮箱前缀	2.0.5以上版本
actives	actives	int	可选	0	性能调优	每服务消费者每服务每方法最大并发调用数	2.0.5以上版本
cluster	cluster	string	可选	failover	性能调优	集群方式，可选：failover/failfast/failsafe/failback/forking	2.0.5以上版本
filter	reference.filter	string	可选	default	性能调优	服务消费方远程调用过程拦截器名称，多个名称用逗号分隔	2.0.5以上版本
listener	invoker.listener	string	可选	default	性能调优	服务消费方引用服务监听器名称，多个名称用逗号分隔	2.0.5以上版本
layer	layer	string	可选		服务治理	服务调用者所在的分层。如：biz、dao、intl:web、china:acton。	2.0.7以上版本
init	init	boolean	可选	false	性能调优	是否在afterPropertiesSet()时饥饿初始化引用，否则等到有人注入或引用该实例时再初始化。	2.0.10以上版本
protocol	protocol	string	可选		服务治理	只调用指定协议的服务提供方，其它协议忽略。

原文地址：20-Dubbo3服务引用配置ReferenceConfig

Blog: 19 重新来过从一个服务消费者的Demo说起

Fri, 19 Aug 2022 00:00:00 +0000

19 重新来过从一个服务消费者的Demo说起

为了更方便了解原理,我们先来编写一个Demo,从例子中来看源码实现:，前面说了提供者现在已经有服务注册上去了，那接下来我们编写一个消费者的例子来进行服务发现与服务RPC调用。

19.1 启动Zookeeper

为了Demo可以正常启动,需要我们先在本地启动一个Zookeeper如下图所示:

19.2 服务消费者

接下来给大家贴一下示例源码,这个源码来源于Dubbo源码目录的 dubbo-demo/dubbo-demo-api 目录下面的dubbo-demo-api-consumer子项目,这里我做了删减,方便看核心代码: 首先我们定义一个服务接口如下所示:

import java.util.concurrent.CompletableFuture;
public interface DemoService {
 /**
 * 同步处理的服务方法
 * @param name
 * @return
 */
 String sayHello(String name);

 /**
 * 用于异步处理的服务方法
 * @param name
 * @return
 */
 default CompletableFuture<String> sayHelloAsync(String name) {
 return CompletableFuture.completedFuture(sayHello(name));
 }
}

服务实现类如下:

import org.apache.dubbo.rpc.RpcContext;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.util.concurrent.CompletableFuture;

public class DemoServiceImpl implements DemoService {
 private static final Logger logger = LoggerFactory.getLogger(DemoServiceImpl.class);

 @Override
 public String sayHello(String name) {
 logger.info("Hello " + name + ", request from consumer: " + RpcContext.getServiceContext().getRemoteAddress());
 return "Hello " + name + ", response from provider: " + RpcContext.getServiceContext().getLocalAddress();
 }

 @Override
 public CompletableFuture<String> sayHelloAsync(String name) {
 return null;
 }

}

19.3 启用服务消费者

有了服务接口之后我们来启用服务,启用服务的源码如下: 这里如果要启动消费者,主要要修改QOS端口这里我已经配置可以直接复用


package link.elastic.dubbo.consumer;

import link.elastic.dubbo.entity.DemoService;
import org.apache.dubbo.common.constants.CommonConstants;
import org.apache.dubbo.config.ApplicationConfig;
import org.apache.dubbo.config.MetadataReportConfig;
import org.apache.dubbo.config.ProtocolConfig;
import org.apache.dubbo.config.ReferenceConfig;
import org.apache.dubbo.config.RegistryConfig;
import org.apache.dubbo.config.bootstrap.DubboBootstrap;
import org.apache.dubbo.rpc.service.GenericService;

public class ConsumerApplication {
 public static void main(String[] args) {
 runWithBootstrap();
 }
 private static void runWithBootstrap() {
 ReferenceConfig<DemoService> reference = new ReferenceConfig<>();
 reference.setInterface(DemoService.class);
 reference.setGeneric("true");
 reference.setProtocol("");

 DubboBootstrap bootstrap = DubboBootstrap.getInstance();
 ApplicationConfig applicationConfig = new ApplicationConfig("dubbo-demo-api-consumer");
 applicationConfig.setQosEnable(false);
 applicationConfig.setQosPort(-1);
 bootstrap.application(applicationConfig)
 .registry(new RegistryConfig("zookeeper://8.131.79.126:2181"))
 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
 .reference(reference)
 .start();

 DemoService demoService = bootstrap.getCache().get(reference);
 String message = demoService.sayHello("dubbo");
 System.out.println(message);

 // generic invoke
 GenericService genericService = (GenericService) demoService;
 Object genericInvokeResult = genericService.$invoke("sayHello", new String[]{String.class.getName()},
 new Object[]{"dubbo generic invoke"});
 System.out.println(genericInvokeResult);
 }
}

1.4 启用服务后写入Zookeeper的节点数据

启动服务,这个时候我们打开Zookeeper图形化客户端来看看这个服务在Zookeeper上面写入来哪些数据,如下图: 在这里插入图片描述

写入Zookeper上的节点用于服务在分布式场景下的协调,这些节点是比较重要的。

如果了解过Dubbo的同学,应该会知道Dubbo在低版本的时候会向注册中心中写入服务接口,具体路径在上面的 dubbo目录下 ,然后在 /dubbo/服务接口/ 路径下写入如下信息:

服务提供者配置信息URL形式
服务消费者的配置信息URL形式
服务路由信息
配置信息

上面这个图就是Dubbo3的注册信息了,后面我们也会围绕细节来说明下,这里可以看下新增了:

/dubbo/metadata 元数据信息
/dubbo/mapping 服务和应用的映射信息
/dubbo/config 注册中心配置
/services目录应用信息

在这里可以大致了解下,在后面会有更详细的源码解析这个示例代码.通过透析代码来看透Dubbo3服务注册原理,服务提供原理。

原文地址：19-重新来过从一个服务消费者的Demo说起

Blog: 18-Dubbo3元数据服务MetadataService的导出

Thu, 18 Aug 2022 00:00:00 +0000

18-Dubbo3元数据服务MetadataService的导出

18.1 简介

MetadataService 此服务用于公开Dubbo进程内的元数据信息。典型用途包括：

使用者查询提供者的元数据信息，以列出接口和每个接口的配置
控制台（dubbo admin）查询特定进程的元数据，或聚合所有进程的数据。在Dubbo2.x的时候，所有的服务数据都是以接口的形式注册在注册中心.

Dubbo3将部分数据抽象为元数据的形式来将数据存放在元数据中心，然后元数据由服务提供者提供给消费者而不是再由注册中心进行推送，如下图所示：

引入 MetadataService 元数据服务服务的好处 • 由中心化推送转向点对点拉取（Consumer - Proroder） • 易于扩展更多的参数 • 更多的数据量 • 对外暴露更多的治理数据

18.2 MetadataService的导出过程

了解元数据的到处过程，这个就要继续前面博客往后的代码了前面博客说了一个服务发布之后的服务信息的双注册数据，这里继续看下导出服务之后的代码：先来简单回顾下模块发布的启动生命周期方法：

DefaultModuleDeployer类型的start方法：

 @Override
 public synchronized Future start() throws IllegalStateException {
 ...

 try {
 ...
 onModuleStarting();

 // initialize
 applicationDeployer.initialize();
 initialize();

 // export services
 exportServices();

 // prepare application instance
 // exclude internal module to avoid wait itself
 if (moduleModel != moduleModel.getApplicationModel().getInternalModule()) {
 applicationDeployer.prepareInternalModule();
 }

 // refer services
 referServices();

 // if no async export/refer services, just set started
 if (asyncExportingFutures.isEmpty() && asyncReferringFutures.isEmpty()) {
 onModuleStarted();
 } else {
 ....
 return startFuture;
 }

前面的博客我们已经说了服务提供者导出服务的方法如下：

 // export services
 exportServices();

在导出服务之后如果代码中配置了引用服务的代码将会执行引用服务的功能，调用代码如下：

referServices();

不过我们样例代码并没有介绍引用服务的功能，这里先不说，等服务提供者完全启动成功之后我们再来看消费者的逻辑。

接下来我们要看的是模块启动成功之后的方法 onModuleStarted();，在这个方法中会去发布服务元数据信息。

18.3 模块启动成功时候的逻辑 onModuleStarted();

这里我们直接先看代码再来分析下逻辑：

DefaultModuleDeployer类型的onModuleStarted方法如下所示：

 private void onModuleStarted() {
 try {
 //状态判断是否为启动中如果是则将状态设置为STARTED
 if (isStarting()) {
 //先修改状态
 setStarted();
 logger.info(getIdentifier() + " has started.");
 //状态修改成功之后开始通知应用程序发布器模块发布器启动成功了
 applicationDeployer.notifyModuleChanged(moduleModel, DeployState.STARTED);
 }
 } finally {
 // complete module start future after application state changed
 completeStartFuture(true);
 }
 }

应用程序发布器处理启动成功的逻辑： DefaultApplicationDeployer类型的notifyModuleChanged方法：

 @Override
 public void notifyModuleChanged(ModuleModel moduleModel, DeployState state) {
 //根据所有模块的状态来判断应用发布器的状态
 checkState(moduleModel, state);

 // notify module state changed or module changed
 //通知所有模块状态更新
 synchronized (stateLock) {
 stateLock.notifyAll();
 }
 }

应用发布器模型DefaultApplicationDeployer检查状态方法checkState代码如下：

 @Override
 public void checkState(ModuleModel moduleModel, DeployState moduleState) {
 //存在写操作 先加个锁
 synchronized (stateLock) {
 //非内部模块，并且模块的状态是发布成功了
 if (!moduleModel.isInternal() && moduleState == DeployState.STARTED) {

 prepareApplicationInstance();
 }
 //应用下所有模块状态进行汇总计算
 DeployState newState = calculateState();
 switch (newState) {
 case STARTED:
 onStarted();
 break;
 case STARTING:
 onStarting();
 break;
 case STOPPING:
 onStopping();
 break;
 case STOPPED:
 onStopped();
 break;
 case FAILED:
 Throwable error = null;
 ModuleModel errorModule = null;
 for (ModuleModel module : applicationModel.getModuleModels()) {
 ModuleDeployer deployer = module.getDeployer();
 if (deployer.isFailed() && deployer.getError() != null) {
 error = deployer.getError();
 errorModule = module;
 break;
 }
 }
 onFailed(getIdentifier() + " found failed module: " + errorModule.getDesc(), error);
 break;
 case PENDING:
 // cannot change to pending from other state
 // setPending();
 break;
 }
 }
 }

18.4 准备发布元数据信息和应用实例信息

前面有个代码调用比较重要：

prepareApplicationInstance()

DefaultApplicationDeployer类型的prepareApplicationInstance方法如下所示

 @Override
 public void prepareApplicationInstance() {
 //已经注册过应用实例数据了 直接返回 （下面CAS逻辑判断了）
 if (hasPreparedApplicationInstance.get()) {
 return;
 }
 //注册开关控制默认为true
 //通过将registerConsumer默认设置为“false”来关闭纯使用者进程实例的注册。
 if (isRegisterConsumerInstance()) {
 exportMetadataService();
 if (hasPreparedApplicationInstance.compareAndSet(false, true)) {
 // register the local ServiceInstance if required
 registerServiceInstance();
 }
 }
 }

18.4.1 导出元数据服务方法exportMetadataService

这里我们就先直接来贴一下代码：

DefaultApplicationDeployer类型的exportMetadataService方法如下所示：

 private void exportMetadataService() {
 if (!isStarting()) {
 return;
 }
 //这里监听器我们主要关注的类型是ExporterDeployListener类型
 for (DeployListener<ApplicationModel> listener : listeners) {
 try {
 if (listener instanceof ApplicationDeployListener) {
 // 回调监听器的模块启动成功方法
 ((ApplicationDeployListener) listener).onModuleStarted(applicationModel);
 }
 } catch (Throwable e) {
 logger.error(getIdentifier() + " an exception occurred when handle starting event", e);
 }
 }
 }

前面我们主要关注ExporterDeployListener类型的监听器的回调方法，这里我贴一下代码： ExporterDeployListener类型的onModuleStarted方法如下：

 @Override
 public synchronized void onModuleStarted(ApplicationModel applicationModel) {
 // start metadata service exporter
 //MetadataServiceDelegation类型为实现提供远程RPC服务以方便元数据信息的查询功能的类型。
 MetadataServiceDelegation metadataService = applicationModel.getBeanFactory().getOrRegisterBean(MetadataServiceDelegation.class);
 if (metadataServiceExporter == null) {
 metadataServiceExporter = new ConfigurableMetadataServiceExporter(applicationModel, metadataService);
 // fixme, let's disable local metadata service export at this moment
 //默认我们是没有配置这个元数据类型的这里元数据类型默认为local 条件是不是remote则开始导出，在前面的博客<<Dubbo启动器DubboBootstrap添加应用程序的配置信息ApplicationConfig>> 中有提到这个配置下面我再说下
 if (!REMOTE_METADATA_STORAGE_TYPE.equals(getMetadataType(applicationModel))) {
 metadataServiceExporter.export();
 }
 }
 }

在前面的博客«Dubbo启动器DubboBootstrap添加应用程序的配置信息ApplicationConfig» 中有提到这个配置下面我再说下

metadata-type

metadata 传递方式，是以 Provider 视角而言的，Consumer 侧配置无效，可选值有：

remote - Provider 把 metadata 放到远端注册中心，Consumer 从注册中心获取。
local - Provider 把 metadata 放在本地，Consumer 从 Provider 处直接获取 。

可以看到默认的local配置元数据信息的获取是由消费者从提供者拉的，那提供者怎么拉取对应服务的元数据信息那就要要用到这个博客说到的MetadataService服务，传递方式为remote的方式其实就要依赖注册中心了相对来说增加了注册中心的压力。

18.4.2 可配置元数据服务的导出ConfigurableMetadataServiceExporter的export

前面了解了导出服务的调用链路，这里详细看下ConfigurableMetadataServiceExporter的export过程源码如下所示：

public synchronized ConfigurableMetadataServiceExporter export() {
 //元数据服务配置已经存在或者已经导出或者不可导出情况下是无需导出的
 if (serviceConfig == null || !isExported()) {
 //创建服务配置
 this.serviceConfig = buildServiceConfig();
 // export
 //导出服务 ,导出服务的具体过程这里就不再说了可以看上一个博客，这个导出服务的过程会绑定端口
 serviceConfig.export();
 metadataService.setMetadataURL(serviceConfig.getExportedUrls().get(0));
 if (logger.isInfoEnabled()) {
 logger.info("The MetadataService exports urls : " + serviceConfig.getExportedUrls());
 }
 } else {
 if (logger.isWarnEnabled()) {
 logger.warn("The MetadataService has been exported : " + serviceConfig.getExportedUrls());
 }
 }

 return this;
 }

18.4.3 元数据服务配置对象的创建

前面我们看到了构建元数据服务对象的代码调用ServiceConfig，接下来我们详细看下构建源码如下所示： ConfigurableMetadataServiceExporter类型的buildServiceConfig构建元数据服务配置对象方法如下：

 private ServiceConfig<MetadataService> buildServiceConfig() {
 //1 获取当前的应用配置 然后初始化应用配置
 ApplicationConfig applicationConfig = getApplicationConfig();
 //创建服务配置对象
 ServiceConfig<MetadataService> serviceConfig = new ServiceConfig<>();
 //设置域模型
 serviceConfig.setScopeModel(applicationModel.getInternalModule());
 serviceConfig.setApplication(applicationConfig);

 //2 创建注册中心配置对象 然后并初始化
 RegistryConfig registryConfig = new RegistryConfig("N/A");
 registryConfig.setId("internal-metadata-registry");

 //3 创建服务配置对象，并初始化
 serviceConfig.setRegistry(registryConfig);
 serviceConfig.setRegister(false);
 //4 生成协议配置 ，这里会配置一下元数据使用的服务端口号默认使用其他服务的端口20880
 serviceConfig.setProtocol(generateMetadataProtocol());
 serviceConfig.setInterface(MetadataService.class);
 serviceConfig.setDelay(0);
 //这里也是需要注意的地方服务引用的类型为MetadataServiceDelegation
 serviceConfig.setRef(metadataService);
 serviceConfig.setGroup(applicationConfig.getName());
 serviceConfig.setVersion(MetadataService.VERSION);
 //5 生成方法配置 这里目前提供的服务方法为getAndListenInstanceMetadata方法 后续可以看下这个方法的视线
 serviceConfig.setMethods(generateMethodConfig());
 serviceConfig.setConnections(1); // separate connection
 serviceConfig.setExecutes(100); // max tasks running at the same time

 return serviceConfig;
 }

这个服务配置对象的创建非常像我们第一个博客提到的服务配置过程，不过这个元数据服务对象有几个比较特殊的配置

注册中心的配置register设置为了false 则为不向注册中心注册具体的服务配置信息
对每个提供者的最大连接数connections为1
服务提供者每服务每方法最大可并行执行请求数executes为100

在使用过程中可以知道上面这几个配置值

18.5 应用级数据注册 registerServiceInstance()

在前面导出元数据服务之后也会调用一行代码来注册应用级数据来保证应用上线

主要涉及到的代码为DefaultApplicationDeployer类型中的registerServiceInstance方法如下所示

 private void registerServiceInstance() {
 try {
 //标记变量设置为true
 registered = true;
 ServiceInstanceMetadataUtils.registerMetadataAndInstance(applicationModel);
 } catch (Exception e) {
 logger.error("Register instance error", e);
 }
 if (registered) {
 // scheduled task for updating Metadata and ServiceInstance
 asyncMetadataFuture = frameworkExecutorRepository.getSharedScheduledExecutor().scheduleWithFixedDelay(() -> {

 // ignore refresh metadata on stopping
 if (applicationModel.isDestroyed()) {
 return;
 }
 try {
 if (!applicationModel.isDestroyed() && registered) {
 ServiceInstanceMetadataUtils.refreshMetadataAndInstance(applicationModel);
 }
 } catch (Exception e) {
 if (!applicationModel.isDestroyed()) {
 logger.error("Refresh instance and metadata error", e);
 }
 }
 }, 0, ConfigurationUtils.get(applicationModel, METADATA_PUBLISH_DELAY_KEY, DEFAULT_METADATA_PUBLISH_DELAY), TimeUnit.MILLISECONDS);
 }
 }

这个方法先将应用元数据注册到注册中心，然后开始开启定时器每隔30秒同步一次元数据向注册中心。

18.5.1 服务实例元数据工具类注册服务发现的元数据信息

前面通过调用类型ServiceInstanceMetadataUtils工具类的registerMetadataAndInstance方法来进行服务实例数据和元数据的注册这里我们详细看下代码如下所示：

 public static void registerMetadataAndInstance(ApplicationModel applicationModel) {
 LOGGER.info("Start registering instance address to registry.");
 RegistryManager registryManager = applicationModel.getBeanFactory().getBean(RegistryManager.class);
 // register service instance
//注意这里服务发现的类型只有ServiceDiscoveryRegistry类型的注册协议才满足 registryManager.getServiceDiscoveries().forEach(ServiceDiscovery::register);
 }

18.5.2 AbstractServiceDiscovery中的服务发现数据注册的模版方法

AbstractServiceDiscovery类型的注册方法register()方法这个是一个模版方法，真正执行的注册逻辑封装在了doRegister方法中由扩展的服务发现子类来完成

 @Override
 public synchronized void register() throws RuntimeException {
 //第一步创建应用的实例信息等待下面注册到注册中心
 this.serviceInstance = createServiceInstance(this.metadataInfo);
 if (!isValidInstance(this.serviceInstance)) {
 logger.warn("No valid instance found, stop registering instance address to registry.");
 return;
 }

 //是否需要更新
 boolean revisionUpdated = calOrUpdateInstanceRevision(this.serviceInstance);
 if (revisionUpdated) {
 reportMetadata(this.metadataInfo);
 //应用的实例信息注册到注册中心之上 ，这个
 doRegister(this.serviceInstance);
 }
 }

18.5.3 应用级实例对象创建

可以看到在AbstractServiceDiscovery服务发现的第一步创建应用的实例信息等待下面注册到注册中心

this.serviceInstance = createServiceInstance(this.metadataInfo);

最终创建的serviceInstance类型为ServiceInstance 这个是Dubbo封装的一个接口，具体实现类型为DefaultServiceInstance，我们可以看下应用级的元数据有哪些

 protected ServiceInstance createServiceInstance(MetadataInfo metadataInfo) {
 //这里的服务名字为：dubbo-demo-api-provider
 DefaultServiceInstance instance = new DefaultServiceInstance(serviceName, applicationModel);
 //应用服务的元数据 ，可以看下面debug的数据信息
 instance.setServiceMetadata(metadataInfo);
 //metadataType的值为local 这个方法是将元数据类型存储到英勇的元数据对象中 对应内容为dubbo.metadata.storage-type:local
 setMetadataStorageType(instance, metadataType);
 // 这个是自定义元数据数据 我们也可以通过实现扩展ServiceInstanceCustomizer来自定义一些元数据
 ServiceInstanceMetadataUtils.customizeInstance(instance, applicationModel);
 return instance;
 }

这个方法的主要目的就是将应用的元数据信息都封装到ServiceInstance类型中，不过额外提供了一个扩展性比较好的方法可以自定义元数据信息

前面的metadataInfo对象的信息如下图所示：

自定义元数据类型Dubbo官方提供了一个默认的实现类型为：ServiceInstanceMetadataCustomizer

最终封装好的元数据信息如下所示：

DefaultServiceInstance{
serviceName='dubbo-demo-api-provider',
host='192.168.1.169',
port=20880,
enabled=true,
healthy=true,
 metadata={
 dubbo.metadata-service.url-params={"connections":"1",
 "version":"1.0.0",
 "dubbo":"2.0.2",
 "release":"3.0.9",
 "side":"provider",
 "port":"20880",
 "protocol":"dubbo"
 },
 dubbo.endpoints=[
 {"port":20880,"protocol":"dubbo"}],
 dubbo.metadata.storage-type=local,
 timestamp=1656227493387}}

18.5.4 应用级实例数据配置变更的的版本号获取

前面创建元应用的实例信息后开始创建版本号来判断是否需要更新，对应AbstractServiceDiscovery类型的calOrUpdateInstanceRevision

 protected boolean calOrUpdateInstanceRevision(ServiceInstance instance) {
 //获取元数据版本号对应字段dubbo.metadata.revision
 String existingInstanceRevision = getExportedServicesRevision(instance);
 //获取实例的服务元数据信息：metadata{app='dubbo-demo-api-provider',revision='null',size=1,services=[link.elastic.dubbo.entity.DemoService:dubbo]}
 MetadataInfo metadataInfo = instance.getServiceMetadata();
 //必须在不同线程之间同步计算此实例的状态，如同一实例的修订和修改。此方法的使用仅限于某些点，例如在注册期间。始终尝试使用此选项。改为getRevision（）。
 String newRevision = metadataInfo.calAndGetRevision();
 //版本号发生了变更（元数据发生了变更）版本号是md5元数据信息计算出来HASH验证
 if (!newRevision.equals(existingInstanceRevision)) {
 //版本号添加到dubbo.metadata.revision字段中
 instance.getMetadata().put(EXPORTED_SERVICES_REVISION_PROPERTY_NAME, metadataInfo.getRevision());
 return true;
 }
 return false;
 }

18.5.4.1 元数据版本号的计算与HASH校验 calAndGetRevision

这个方法其实比较重要，决定了什么时候会更新元数据，Dubbo使用了一种Hash验证的方式将元数据转MD5值与之前的存在的版本号（也是元数据转MD5得到的）如果数据发生了变更则MD5值会发生变化以此来更新元数据，不过发生了MD5冲突的话就会导致配置不更新这个冲突的概率非常小。好了直接来看代码吧： MetadataInfo类型的calAndGetRevision方法：

public synchronized String calAndGetRevision() {
 if (revision != null && !updated) {
 return revision;
 }

 updated = false;
 //应用下没有服务则使用一个空的版本号
 if (CollectionUtils.isEmptyMap(services)) {
 this.revision = EMPTY_REVISION;
 } else {
 StringBuilder sb = new StringBuilder();
 //app是应用名
 sb.append(app);
 for (Map.Entry<String, ServiceInfo> entry : new TreeMap<>(services).entrySet()) {
 sb.append(entry.getValue().toDescString());
 }
 String tempRevision = RevisionResolver.calRevision(sb.toString());
 if (!StringUtils.isEquals(this.revision, tempRevision)) {
 //元数据重新注册的话我们可以看看这个日志metadata revision change
 if (logger.isInfoEnabled()) {
 logger.info(String.format("metadata revision changed: %s -> %s, app: %s, services: %d", this.revision, tempRevision, this.app, this.services.size()));
 }
 this.revision = tempRevision;
 this.rawMetadataInfo = JsonUtils.getJson().toJson(this);
 }
 }
 return revision;
 }

RevisionResolver类型的Md5运算计算版本号

md5Utils.getMd5(metadata);

18.5.5 reportMetadata

回到18.5.2 AbstractServiceDiscovery中的模版方法register，这里我们来看下reportMetadata方法，不过这个方法目前并不会走到，因为我们默认的配置元数据是local不会直接把应用的元数据注册在元数据中心

 protected void reportMetadata(MetadataInfo metadataInfo) {
 if (metadataReport != null) {
 //订阅元数据的标识符
 SubscriberMetadataIdentifier identifier = new SubscriberMetadataIdentifier(serviceName, metadataInfo.getRevision());
 //是否远程发布元数据，这里我们是本地注册这个就不会在元数据中心发布这个元数据信息
 if ((DEFAULT_METADATA_STORAGE_TYPE.equals(metadataType) && metadataReport.shouldReportMetadata()) || REMOTE_METADATA_STORAGE_TYPE.equals(metadataType)) {
 metadataReport.publishAppMetadata(identifier, metadataInfo);
 }
 }
 }

18.5.6 扩展的注册中心来注册应用级服务发现数据doRegister方法

前面我们说了AbstractServiceDiscovery中的模版方法register，在register会调用一个doRegister方法来注册应用级数据，这个方法是需要扩展注册中心的服务发现来自行实现的，我们这里以官方实现的Zookeeper服务发现模型为例:

ZookeeperServiceDiscovery中的doRegister方法

 @Override
 public void doRegister(ServiceInstance serviceInstance) {
 try {
 //Dubbo实现的ServiceInstance类型对象转 Curator的ServiceInstance
 serviceDiscovery.registerService(build(serviceInstance));
 } catch (Exception e) {
 throw new RpcException(REGISTRY_EXCEPTION, "Failed register instance " + serviceInstance.toString(), e);
 }
 }

前面我们介绍了ZookeeperServiceDiscovery发现的构造器连接注册中心，这里来看下服务注册，应用级实例数据注册一共分为两步第一步是：Dubbo实现的ServiceInstance类型对象转 Curator的ServiceInstance 第二步是：执行registerService方法将数据注册到注册中心

先来看第一步：Dubbo实现的ServiceInstance类型对象转 Curator的ServiceInstance 关于Curator的服务发现原理可以参考官网的文章博客curator-x-discovery

什么是发现服务？ 在 SOA/分布式系统中，服务需要找到彼此。即，Web 服务可能需要找到缓存服务等。DNS 可以用于此，但对于不断变化的服务来说，它远不够灵活。服务发现系统提供了一种机制：

注册其可用性的服务
定位特定服务的单个实例
在服务实例更改时通知

服务实例由类表示：ServiceInstance。ServiceInstances 具有名称、id、地址、端口和/或 ssl 端口，以及可选的有效负载（用户定义）。ServiceInstances 通过以下方式序列化并存储在 ZooKeeper 中：

base path
 |_______ service A name
 |__________ instance 1 id --> (serialized ServiceInstance)
 |__________ instance 2 id --> (serialized ServiceInstance)
 |__________ ...
 |_______ service B name
 |__________ instance 1 id --> (serialized ServiceInstance)
 |__________ instance 2 id --> (serialized ServiceInstance)
 |__________ ...
 |_______ ...

这个应用最终注册应用级服务数据如下：这里需要注意的是这个应用的IP+端口的服务元数据信息是临时节点 build方法内容对应着上图的JSON数据可以看菜build方法封装的过程：

public static org.apache.curator.x.discovery.ServiceInstance<ZookeeperInstance> build(ServiceInstance serviceInstance) {
 ServiceInstanceBuilder builder;

 String serviceName = serviceInstance.getServiceName();
 String host = serviceInstance.getHost();
 int port = serviceInstance.getPort();
 Map<String, String> metadata = serviceInstance.getSortedMetadata();
 String id = generateId(host, port);
 //ZookeeperInstance是Dubbo封装的用于存放payload数据 包含服务id，服务名字和元数据
 ZookeeperInstance zookeeperInstance = new ZookeeperInstance(id, serviceName, metadata);
 try {
 builder = builder()
 .id(id)
 .name(serviceName)
 .address(host)
 .port(port)
 .payload(zookeeperInstance);
 } catch (Exception e) {
 throw new RuntimeException(e);
 }
 return builder.build();
 }

在《18.5 应用级数据注册 registerServiceInstance() 》小节中介绍了应用元数据信息的注册调用代码，其实后面还有个update的逻辑定期30秒同步元数据到元数据中心，这里就不详细介绍了。

原文地址：18-Dubbo3元数据服务MetadataService的导出

Blog: 17-Dubbo服务提供者的双注册原理

Wed, 17 Aug 2022 00:00:00 +0000

17-Dubbo服务提供者的双注册原理

17.1 简介

上个博客《15-Dubbo的三大中心之元数据中心源码解析》导出服务端的时候多次提到了元数据中心，注册信息的注册。 Dubbo3出来时间不太长，对于现在的用户来说大部分使用的仍旧是Dubbo2.x， Dubbo3 比较有特色也是会直接使用到的功能就是应用级服务发现：

应用级服务发现从服务/接口粒度到应用粒度的升级，使得 Dubbo 在集群可伸缩性、连接异构微服务体系上更具优势。应用粒度能以更低的资源消耗支持超百万实例规模集群程；实现与 Spring Cloud、Kubernetes Service 等异构微服务体系的互联互通。

对于直接使用Dubbo3的用户还好，可以仅仅开启应用级注册，但是对于Dubbo2.x的用户升级到Dubbo3的用户来说前期都是要开启双注册来慢慢迁移的，既注册传统的接口信息到注册中心，又注册应用信息到注册中心，同时注册应用与接口关系的元数据信息。关于双注册与服务迁移的过程的使用可以参考官网：应用级地址发现迁移指南

关于官网提供者双注册的图我这里贴一下，方便了解：

17.2 双注册配置的读取

17.2.1 注册中心地址作为元数据中心

这个配置的解析过程在前面的博客介绍元数据中心的时候很详细的说了相关链接：15-Dubbo的三大中心之元数据中心源码解析

对应代码位于：DefaultApplicationDeployer类型的startMetadataCenter()方法

private void startMetadataCenter() {
 //如果未配置元数据中心的地址等配置则使用注册中心的地址等配置做为元数据中心的配置
 useRegistryAsMetadataCenterIfNecessary();
 //...省略掉其他代码防止受到干扰
 }

具体逻辑是这个方法： useRegistryAsMetadataCenterIfNecessary

private void useRegistryAsMetadataCenterIfNecessary() {
 //配置缓存中查询元数据配置
 Collection<MetadataReportConfig> metadataConfigs = configManager.getMetadataConfigs();

 //...省略掉空判断
 //查询是否有注册中心设置了默认配置isDefault 设置为true的注册中心则为默认注册中心列表,如果没有注册中心设置为默认注册中心,则获取所有未设置默认配置的注册中心列表
 List<RegistryConfig> defaultRegistries = configManager.getDefaultRegistries();
 if (defaultRegistries.size() > 0) {
 //多注册中心遍历
 defaultRegistries
 .stream()
 //筛选符合条件的注册中心 (筛选逻辑就是查看是否有对应协议的扩展支持)
 .filter(this::isUsedRegistryAsMetadataCenter)
 //注册中心配置映射为元数据中心 映射就是获取需要的配置
 .map(this::registryAsMetadataCenter)
 //将元数据中心配置存储在配置缓存中方便后续使用
 .forEach(metadataReportConfig -> {
 //...省略掉具体的逻辑
 });
 }
 }

关于元数据中心地址的获取，主要经过如下逻辑：

查询： 所有可用的默认注册中心列表
遍历： 多注册中心遍历
筛选： 选符合条件的注册中心 (筛选逻辑就是查看是否有对应协议的扩展支持)
转化： 注册中心配置RegistryConfig映射转换为元数据中心配置类型MetadataReportConfig

MetadataReportConfig 映射就是获取需要的配置。

最后会把查询到的元数据中心配置存储在配置缓存中方便后续使用。

17.2.2 双注册模式配置

双注册配置类型是这个

dubbo.application.register-mode=all

默认值为all代表应用级注册和接口级注册，当前在完全迁移到应用级注册之后可以将服务直接迁移到应用级配置上去。配置值解释：

all 双注册
instance 应用级注册
interface 接口级注册

后面的代码如果想要看更详细的代码可以看博客《16-模块发布器发布服务全过程》关于这个配置的使用我们详细来看下，在Dubbo服务注册时候会先通过此配置查询需要注册服务地址，具体代码位于ServiceConfig的doExportUrls()方法中：

private void doExportUrls() {
 //省略掉前面的代码...
 List<URL> registryURLs = ConfigValidationUtils.loadRegistries(this, true);
 //省略掉后面的代码...
 }

然后就是具体注册中心地址的获取过程我们看下： ConfigValidationUtils的加载注册中心地址方法loadRegistries

 public static List<URL> loadRegistries(AbstractInterfaceConfig interfaceConfig, boolean provider) {
 // check && override if necessary
 //省略掉前面的代码...
 //这里会获取到一个接口配置注册地址例如：registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=9008&registry=zookeeper&release=3.0.8&timestamp=1653703292768
 List<RegistryConfig> registries = interfaceConfig.getRegistries();
 //省略掉中间的的代码...
 return genCompatibleRegistries(interfaceConfig.getScopeModel(), registryList, provider);
 }

ConfigValidationUtils的双注册地址的获取genCompatibleRegistries方法. 前面代码获取到了一个注册中心地址列表例如：

registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=9008&registry=zookeeper&release=3.0.8&timestamp=1653703292768

下面可以看下如果根据配置来转换为应用级注册地址+接口级注册地址

private static List<URL> genCompatibleRegistries(ScopeModel scopeModel, List<URL> registryList, boolean provider) {
 List<URL> result = new ArrayList<>(registryList.size());
 registryList.forEach(registryURL -> {
 if (provider) {
 // for registries enabled service discovery, automatically register interface compatible addresses.
 String registerMode;
 if (SERVICE_REGISTRY_PROTOCOL.equals(registryURL.getProtocol())) {
 //为了更好理解这里简化掉服务发现注册地址配置的逻辑判断过程仅仅看当前例子提供的值走的逻辑
 } else {
 //双注册模式配置查询 对应参数为dubbo.application.register-mode 默认值为all
 registerMode = registryURL.getParameter(REGISTER_MODE_KEY, ConfigurationUtils.getCachedDynamicProperty(scopeModel, DUBBO_REGISTER_MODE_DEFAULT_KEY, DEFAULT_REGISTER_MODE_ALL));
 //如果用户配置了一个错误的注册模式配置则只走接口级配置 这里默认值为interface
 if (!isValidRegisterMode(registerMode)) {
 registerMode = DEFAULT_REGISTER_MODE_INTERFACE;
 }
 //这个逻辑是满足应用级注册就添加一个应用级注册的地址
 if ((DEFAULT_REGISTER_MODE_INSTANCE.equalsIgnoreCase(registerMode) || DEFAULT_REGISTER_MODE_ALL.equalsIgnoreCase(registerMode))
 && registryNotExists(registryURL, registryList, SERVICE_REGISTRY_PROTOCOL)) {
 URL serviceDiscoveryRegistryURL = URLBuilder.from(registryURL)
 .setProtocol(SERVICE_REGISTRY_PROTOCOL)
 .removeParameter(REGISTRY_TYPE_KEY)
 .build();
 result.add(serviceDiscoveryRegistryURL);
 }
 //这个逻辑是满足接口级注册配置就添加一个接口级注册地址
 if (DEFAULT_REGISTER_MODE_INTERFACE.equalsIgnoreCase(registerMode) || DEFAULT_REGISTER_MODE_ALL.equalsIgnoreCase(registerMode)) {
 result.add(registryURL);
 }
 }
 //省略掉若干代码和括号

 return result;
 }

可以看到这里简化的配置比较容易理解了

双注册模式配置查询对应参数为dubbo.application.register-mode ，默认值为all
如果用户配置了一个错误的注册模式配置则只走接口级配置这里默认值为interface
满足应用级注册就添加一个应用级注册的地址
满足接口级注册配置就添加一个接口级注册地址

这个方法是根据服务注册模式来判断使用接口级注册地址还是应用级注册地址分别如下所示：配置信息： dubbo.application.register-mode 配置值：

interface
- 接口级注册
instance
- 应用级注册
all
- 接口级别和应用级都注册

最终的注册地址配置如下：接口级注册地址：

registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=9008&registry=zookeeper&release=3.0.8&timestamp=1653703292768

应用级注册地址：

service-discovery-registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=10275&registry=zookeeper&release=3.0.8&timestamp=1653704425920

17.3 双注册服务数据的注册

17.3.1 双注册代码逻辑调用简介

前面说了这个注册服务的配置地址会由Dubbo内部进行判断如果判断是all的话会自动将一个配置的注册地址转变为两个一个是传统的接口级注册，一个是应用级注册使用的配置地址

然后我们先看注册中心，注册服务数据的源码如果想要查看源码细节可以在RegistryProtocol类型的export(final Invoker originInvoker) 方法的如下代码位置打断点：

RegistryProtocol的export方法的注册中心注册数据代码如下：

 // url to registry 注册服务对外的接口
 //如果url为service-discovery-registry发现则这个实现类型为ServiceDiscoveryRegistry
 final Registry registry = getRegistry(registryUrl);
 //服务发现的提供者url: dubbo://192.168.1.9:20880/link.elastic.dubbo.entity.DemoService?anyhost=true&application=dubbo-demo-api-provider&background=false&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=link.elastic.dubbo.entity.DemoService&methods=sayHello,sayHelloAsync&pid=19559&release=3.0.8&service-name-mapping=true&side=provider&timestamp=1654938441023
 final URL registeredProviderUrl = getUrlToRegistry(providerUrl, registryUrl);

 // decide if we need to delay publish (provider itself and registry should both need to register)
 //register参数是否 注册数据到注册中心
 boolean register = providerUrl.getParameter(REGISTER_KEY, true) && registryUrl.getParameter(REGISTER_KEY, true);
 if (register) {
 //这里有两种情况 接口级注册会将接口级服务提供者数据直接注册到Zookeper上面，服务发现（应用级注册）这里仅仅会将注册数据转换为服务元数据等后面来发布元数据
 register(registry, registeredProviderUrl);
 }

 // register stated url on provider model
 //向提供者模型注册提供者配置ProviderModel
 registerStatedUrl(registryUrl, registeredProviderUrl, register);


 exporter.setRegisterUrl(registeredProviderUrl);
 exporter.setSubscribeUrl(overrideSubscribeUrl);

 if (!registry.isServiceDiscovery()) {
 // Deprecated! Subscribe to override rules in 2.6.x or before.
 registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);
 }

在上个博客中我们整体说了下服务注册时候的一个流程，关于数据向注册中心的注册细节这里可以详细看下

17.3.2 注册中心领域对象的初始化

前面的代码使用url来获取注册中心操作对象如下调用代码：

// url to registry 注册服务对外的接口
final Registry registry = getRegistry(registryUrl);

对应代码如下：

 protected Registry getRegistry(final URL registryUrl) {
 //这里分为两步先获取注册中心工厂对象
 RegistryFactory registryFactory = ScopeModelUtil.getExtensionLoader(RegistryFactory.class, registryUrl.getScopeModel()).getAdaptiveExtension();
 //使用注册中心工厂对象获取注册中心操作对象
 return registryFactory.getRegistry(registryUrl);
 }

关于参数URL有两个在前面已经说过，url信息如下：

接口级注册地址：

registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=9008&registry=zookeeper&release=3.0.8&timestamp=1653703292768

应用级注册地址：

service-discovery-registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=10275&registry=zookeeper&release=3.0.8&timestamp=1653704425920

注册中心工厂对象与注册中心操作对象的获取与执行我们通过Debug来看比较麻烦，这里涉及到很多扩展机制动态生成的代码我们无法看到，这里我直接来贴一下比较关键的一些类型，以Zookeeper注册中心来举例子：

先来看下注册工厂相关的类型：

RegistryFactory 注册中心对象获取
AbstractRegistryFactory 模板类型封装注册中心对象获取的基本逻辑，比如缓存和基本的逻辑判断
ServiceDiscoveryRegistryFactory 用于创建服务发现注册中心工厂对象用于创建ServiceDiscoveryRegistry对象
ZookeeperRegistryFactory 用于创建ZookeeperRegistry类型对象
NacosRegistryFactory Nacos注册中心工厂对象用于创建NacosRegistry

接下来看封装了注册中心操作逻辑的注册中心领域对象：

Node 节点信息开放接口比如节点 url的获取，销毁
RegistryService 注册服务接口，比如注册，订阅，查询等操作
Registry 注册中心接口，是否服务发现查询，注册，取消注册方法
AbstractRegistry 注册中心逻辑抽象模板类型，封装了注册，订阅，通知的基本逻辑，和本地缓存注册中心信息的基本逻辑
FailbackRegistry 封装了失败重试的逻辑
NacosRegistry 封装了以nacos作为注册中心的基本逻辑
ServiceDiscoveryRegistry 应用级服务发现注册中心逻辑，现在不需要这种网桥实现，协议可以直接与服务发现交互。ServiceDiscoveryRegistry是一种非常特殊的注册表实现，用于以兼容的方式将旧的接口级服务发现模型与3.0中引入的新服务发现模型连接起来。它完全符合注册表SPI的扩展规范，但与zookeeper和Nacos的具体实现不同，因为它不与任何真正的第三方注册表交互，而只与过程中ServiceDiscovery的相关组件交互。简而言之，它架起了旧接口模型和新服务发现模型之间的桥梁：register()方法主要通过与MetadataService交互，将接口级数据聚合到MetadataInfo中subscribe() 触发应用程序级服务发现模型的整个订阅过程。-根据ServiceNameMapping将接口映射到应用程序。-启动新的服务发现侦听器（InstanceListener），并使NotifierListener成为InstanceListener的一部分。
CacheableFailbackRegistry 提供了一些本地内存缓存的逻辑对注册中心有用，注册中心的sdk将原始字符串作为提供程序实例返回，例如zookeeper和etcd
ZookeeperRegistry Zookeeper作为注册中心的基本操作逻辑封装

了解了这几个领域对象这里我们回到代码逻辑，这里直接看将会执行的一些核心逻辑：

 protected Registry getRegistry(final URL registryUrl) {
 //这里分为两步先获取注册中心工厂对象
 RegistryFactory registryFactory = ScopeModelUtil.getExtensionLoader(RegistryFactory.class, registryUrl.getScopeModel()).getAdaptiveExtension();
 //使用注册中心工厂对象获取注册中心操作对象
 return registryFactory.getRegistry(registryUrl);
 }

前面注册中心工厂不论那种协议的地址信息获取到的都是一个RegistryFactory$Adaptive类型（由扩展机制的字节码工具自动生成的代码）

如果getRegistry参数为应用级注册地址。如下所示将获取到的类型为ServiceDiscoveryRegistryFactory逻辑来获取注册中心：（这个逻辑是@Adaptive注解产生的了逻辑具体原理可以看扩展机制中@Adaptive的实现）

service-discovery-registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=10275&registry=zookeeper&release=3.0.8&timestamp=1653704425920

getRegistry方法优先走的逻辑是这里：AbstractRegistryFactory模板类型中的getRegistry方法

@Override
 public Registry getRegistry(URL url) {
 if (registryManager == null) {
 throw new IllegalStateException("Unable to fetch RegistryManager from ApplicationModel BeanFactory. " +
 "Please check if `setApplicationModel` has been override.");
 }
 //销毁状态直接返回
 Registry defaultNopRegistry = registryManager.getDefaultNopRegistryIfDestroyed();
 if (null != defaultNopRegistry) {
 return defaultNopRegistry;
 }

 url = URLBuilder.from(url)
 .setPath(RegistryService.class.getName())
 .addParameter(INTERFACE_KEY, RegistryService.class.getName())
 .removeParameter(TIMESTAMP_KEY)
 .removeAttribute(EXPORT_KEY)
 .removeAttribute(REFER_KEY)
 .build();
 //这个key为 service-discovery-registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService
 String key = createRegistryCacheKey(url);
 Registry registry = null;
 //check配置 是否检查注册中心连通 默认为true
 boolean check = url.getParameter(CHECK_KEY, true) && url.getPort() != 0;
 // Lock the registry access process to ensure a single instance of the registry
 //给写操作加锁方式并发写问题
 registryManager.getRegistryLock().lock();
 try {
 //锁内检查是否销毁的逻辑
 // double check
 // fix https://github.com/apache/dubbo/issues/7265.
 defaultNopRegistry = registryManager.getDefaultNopRegistryIfDestroyed();
 if (null != defaultNopRegistry) {
 return defaultNopRegistry;
 }
 //锁内检查是否缓存中存在存在则直接返回
 registry = registryManager.getRegistry(key);
 if (registry != null) {
 return registry;
 }
 //create registry by spi/ioc
 //使用url创建注册中心操作的逻辑
 registry = createRegistry(url);
 } catch (Exception e) {
 //check配置检查
 if (check) {
 throw new RuntimeException("Can not create registry " + url, e);
 } else {
 LOGGER.warn("Failed to obtain or create registry ", e);
 }
 } finally {
 // Release the lock
 registryManager.getRegistryLock().unlock();
 }

 if (check && registry == null) {
 throw new IllegalStateException("Can not create registry " + url);
 }
 //缓存逻辑
 if (registry != null) {
 registryManager.putRegistry(key, registry);
 }
 return registry;
 }

逻辑其实吧比较简单，概括下上面的逻辑：

销毁逻辑判断
缓存获取，存在则直接返回
根据注册中心url配置，创建注册中心操作对象
注册中心连接失败的check配置逻辑处理
将注册中心操作对象存入缓存

上面比较重要的逻辑是createRegistry这个整个调用过程我给大家看下Debug的详情，这里很多逻辑由扩展机制产生的这里直接看下逻辑调用栈，有几个需要关注的地方我圈了起来：我们继续看服务发现的注册中心工厂对象的获取，代码如下： ServiceDiscoveryRegistryFactory类型的createRegistry方法

 @Override
 protected Registry createRegistry(URL url) {
 //判断url是否是这个前缀：service-discovery-registry
 if (UrlUtils.hasServiceDiscoveryRegistryProtocol(url)) {
 //切换下协议：将服务发现协议切换为配置的注册中心协议这里是Zookeeper如下：
 //zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&interface=org.apache.dubbo.registry.RegistryService&pid=39884&release=3.0.8
 String protocol = url.getParameter(REGISTRY_KEY, DEFAULT_REGISTRY);
 url = url.setProtocol(protocol).removeParameter(REGISTRY_KEY);
 }
 //创建服务发现注册中心对象对象
 return new ServiceDiscoveryRegistry(url, applicationModel);
 }

通过以上代码可以看到其实最终创建的是一个ServiceDiscoveryRegistry注册中心对象，这个url协议被转换为了对应注册中心的协议，也就是说双注册会有两个协议一个是原先的接口级注册注册中心对象（这个还未说到）和这里对应注册中心协议的服务发现注册中心对象ServiceDiscoveryRegistry

17.3.3 ServiceDiscoveryRegistry

ServiceDiscoveryRegistry服务发现注册中心对象的初始化过程：

17.3.3.1 ServiceDiscoveryRegistry的构造器：

 public ServiceDiscoveryRegistry(URL registryURL, ApplicationModel applicationModel) {
 super(registryURL);
 //根据url创建一个服务发现对象类型为ServiceDiscovery
 this.serviceDiscovery = createServiceDiscovery(registryURL);
 //这个类型为是serviceNameMapping类型是MetadataServiceNameMapping类型
 this.serviceNameMapping = (AbstractServiceNameMapping) ServiceNameMapping.getDefaultExtension(registryURL.getScopeModel());
 super.applicationModel = applicationModel;
 }

ServiceDiscoveryRegistry中创建服务发现对象createServiceDiscovery方法

protected ServiceDiscovery createServiceDiscovery(URL registryURL) {
 return getServiceDiscovery(registryURL.addParameter(INTERFACE_KEY, ServiceDiscovery.class.getName())
 .removeParameter(REGISTRY_TYPE_KEY));
 }

ServiceDiscoveryRegistry中创建服务发现对象getServiceDiscovery方法

private ServiceDiscovery getServiceDiscovery(URL registryURL) {
//服务发现工厂对象的获取这里是ServiceDiscoveryFactory类型，
 ServiceDiscoveryFactory factory = getExtension(registryURL);
 //服务发现工厂对象获取服务发现对象
 return factory.getServiceDiscovery(registryURL);
 }

ServiceDiscoveryFactory和ServiceDiscovery类型可以往后看

17.3.3.2 父类型FailbackRegistry的构造器

 public FailbackRegistry(URL url) {
 super(url);
 //重试间隔配置retry.period ，默认为5秒
 this.retryPeriod = url.getParameter(REGISTRY_RETRY_PERIOD_KEY, DEFAULT_REGISTRY_RETRY_PERIOD);

 // since the retry task will not be very much. 128 ticks is enough.
 //因为重试任务不会太多。128个刻度就足够了。Dubbo封装的时间轮用于高效率的重试，这个在Kafka也自定义实现了后续可以单独来看看
 retryTimer = new HashedWheelTimer(new NamedThreadFactory("DubboRegistryRetryTimer", true), retryPeriod, TimeUnit.MILLISECONDS, 128);
 }

17.3.3.3 AbstractRegistry的构造器

参数url如下所示：

zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&interface=org.apache.dubbo.registry.RegistryService&pid=39884&release=3.0.8


 public AbstractRegistry(URL url) {
 setUrl(url);
 registryManager = url.getOrDefaultApplicationModel().getBeanFactory().getBean(RegistryManager.class);
 //是否本地缓存默认为true
 localCacheEnabled = url.getParameter(REGISTRY_LOCAL_FILE_CACHE_ENABLED, true);
 registryCacheExecutor = url.getOrDefaultFrameworkModel().getBeanFactory()
 .getBean(FrameworkExecutorRepository.class).getSharedExecutor();
 if (localCacheEnabled) {
 // Start file save timer 是否同步缓存默认为false
 syncSaveFile = url.getParameter(REGISTRY_FILESAVE_SYNC_KEY, false);
 //默认缓存的文件路径与文件名字为：/Users/song/.dubbo/dubbo-registry-dubbo-demo-api-provider-127.0.0.1-2181.cache
 String defaultFilename = System.getProperty(USER_HOME) + DUBBO_REGISTRY +
 url.getApplication() + "-" + url.getAddress().replaceAll(":", "-") + CACHE;
 //未指定缓存的文件名字则用默认的文件名字
 String filename = url.getParameter(FILE_KEY, defaultFilename);
 File file = null;
 //父目录创建，保证目录存在
 if (ConfigUtils.isNotEmpty(filename)) {
 file = new File(filename);
 if (!file.exists() && file.getParentFile() != null && !file.getParentFile().exists()) {
 if (!file.getParentFile().mkdirs()) {
 throw new IllegalArgumentException("Invalid registry cache file " + file + ", cause: Failed to create directory " + file.getParentFile() + "!");
 }
 }
 }
 this.file = file;
 // When starting the subscription center,
 // we need to read the local cache file for future Registry fault tolerance processing.
 //加载本地磁盘文件
 loadProperties();
 //变更推送
 notify(url.getBackupUrls());
 }
 }

17.3.4 将服务提供者数据转换到本地内存的元数据信息中

在前面我们看到了RegistryProtocol中调用register来注册服务提供者的数据到注册的中心，接下来详细看下实现原理：下面参数为ServiceDiscoveryRegistry为情况下举例子：ServiceDiscoveryRegistry类型的register方法与ZookeeperRegister注册不一样传统的接口级注册在这个方法里面就将服务数据注册到注册中心了，服务发现的数据注册分为了两步，这里仅仅将数据封装到内存中如下： url例子为：

dubbo://192.168.1.9:20880/link.elastic.dubbo.entity.DemoService?anyhost=true&application=dubbo-demo-api-provider&background=false&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=link.elastic.dubbo.entity.DemoService&methods=sayHello,sayHelloAsync&pid=19559&release=3.0.8&service-name-mapping=true&side=provider&timestamp=1654938441023

RegistryProtocol中的register方法：

 private void register(Registry registry, URL registeredProviderUrl) {
 registry.register(registeredProviderUrl);
 }

上面这个代码会优先走ListenerRegistryWrapper的一些逻辑来执行register方法来触发一些监听器的逻辑，我们直接跳到ServiceDiscoveryRegistry中的register方法来看

ServiceDiscoveryRegistry的register方法

@Override
 public final void register(URL url) {
 //逻辑判断比如只有side为提供者时候才能注册
 if (!shouldRegister(url)) { // Should Not Register
 return;
 }
 doRegister(url);
 }

ServiceDiscoveryRegistry的doRegister方法：

 @Override
 public void doRegister(URL url) {
 // fixme, add registry-cluster is not necessary anymore
 url = addRegistryClusterKey(url);
 serviceDiscovery.register(url);
 }

AbstractServiceDiscovery的register方法：

@Override
 public void register(URL url) {
 //metadaInfo类型为MetadataInfo类型，用来操作元数据的
 metadataInfo.addService(url);
 }

MetadataInfo 类型的addService方法

public synchronized void addService(URL url) {
 // fixme, pass in application mode context during initialization of MetadataInfo.
 //元数据参数过滤器扩展获取:MetadataParamsFilter
 if (this.loader == null) {
 this.loader = url.getOrDefaultApplicationModel().getExtensionLoader(MetadataParamsFilter.class);
 }
 //元数据参数过滤器获取
 List<MetadataParamsFilter> filters = loader.getActivateExtension(url, "params-filter");
 // generate service level metadata
 //生成服务级别的元数据
 ServiceInfo serviceInfo = new ServiceInfo(url, filters);
 this.services.put(serviceInfo.getMatchKey(), serviceInfo);
 // extract common instance level params
 extractInstanceParams(url, filters);

 if (exportedServiceURLs == null) {
 exportedServiceURLs = new ConcurrentSkipListMap<>();
 }
 addURL(exportedServiceURLs, url);
 updated = true;
 }

17.3.5 接口级服务提供者配置的注册

前面我们通过服务发现的的url进行了举例子，其实在RegistryProtocol协议的export方法中还会注册接口级信息：例如如下关键代码：当registryUrl参数不是服务发现协议service-discovery-registry配置而是zookeeper如下时候获取到的扩展类型将是与Zookeeper相关的扩展对象

zookeeper://8.131.79.126:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=29386&release=3.0.8&timestamp=1655023329438

RegistryProtocol协议的export方法中接口级数据注册的核心代码如下：如下代码的操作类型可以看注释

// url to registry 这里registry对象的类型为ZookeeperRegistry
 final Registry registry = getRegistry(registryUrl);

 final URL registeredProviderUrl = getUrlToRegistry(providerUrl, registryUrl);
 // decide if we need to delay publish (provider itself and registry should both need to register)
 boolean register = providerUrl.getParameter(REGISTER_KEY, true) && registryUrl.getParameter(REGISTER_KEY, true);
 //这一个方法里面会将提供者的url配置写入Zookeeper的provider节点下面
 if (register) {
 register(registry, registeredProviderUrl);
 }

如上代码是获取Zookeeper操作对象和向Zookeeper中写入服务提供者信息的代码，关于与Zookeeper连接和注册数据本地缓存的代码可以看ZookeeperRegistry类型和它的几个父类型比如：CacheableFailbackRegistry类型，关于接口级数据的注册可以看register方法，这个就不详细说了，下面我贴一下接口级数据注册的Zookeeper信息可以了解下就行：接口信息如下，上面我们需要注意的是这个 url配置为临时节点，当与Zookeeper断开连接或者Session超时的时候这个信息会被移除：

/dubbo/link.elastic.dubbo.entity.DemoService/providers/dubbo%3A%2F%2F192.168.1.9%3A20880%2Flink.elastic.dubbo.entity.DemoService%3Fanyhost%3Dtrue%26application%3Ddubbo-demo-api-provider%26background%3Dfalse%26deprecated%3Dfalse%26dubbo%3D2.0.2%26dynamic%3Dtrue%26generic%3Dfalse%26interface%3Dlink.elastic.dubbo.entity.DemoService%26methods%3DsayHello%2CsayHelloAsync%26pid%3D29386%26release%3D3.0.8%26service-name-mapping%3Dtrue%26side%3Dprovider%26timestamp%3D1655023329514

17.4 应用级服务发现功能的实现ServiceDiscovery

在说这个实现之前我们先看看相关类型，这个服务发现相关的类型与注册中心相关的类型有点类似：

服务发现工厂类型：服务发现类型：

刚刚在 ServiceDiscoveryRegistry中创建服务发现对象getServiceDiscovery方法看到了两个类型一个是服务发现工厂类型ServiceDiscoveryFactory，一个是服务发现类型ServiceDiscovery

private ServiceDiscovery getServiceDiscovery(URL registryURL) {
//服务发现工厂对象的获取这里是ServiceDiscoveryFactory类型，这里对应ZookeeperServiceDiscoveryFactory
 ServiceDiscoveryFactory factory = getExtension(registryURL);
 //服务发现工厂对象获取服务发现对象
 return factory.getServiceDiscovery(registryURL);
 }

AbstractServiceDiscoveryFactory类型的getServiceDiscovery方法

 @Override
 public ServiceDiscovery getServiceDiscovery(URL registryURL) {
 //这个key是 zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.client.ServiceDiscovery
 //一个地址需要创建一个服务发现对象
 String key = registryURL.toServiceStringWithoutResolving();
 return discoveries.computeIfAbsent(key, k -> createDiscovery(registryURL));
 }

createDiscovery方法对应ZookeeperServiceDiscoveryFactory类型中的createDiscovery方法

如下代码所示：

@Override
 protected ServiceDiscovery createDiscovery(URL registryURL) {
 return new ZookeeperServiceDiscovery(applicationModel, registryURL);
 }

17.4.1 ZookeeperServiceDiscovery

ZookeeperServiceDiscovery的构造器

 public ZookeeperServiceDiscovery(ApplicationModel applicationModel, URL registryURL) {
 //先调用父类AbstractServiceDiscovery 模板类构造器
 super(applicationModel, registryURL);
 try {
 //创建 创建CuratorFramework 类型对象用于操作Zookeeper
 this.curatorFramework = buildCuratorFramework(registryURL);
 //获取应用级服务发现的根路径 值为/services 这个可以在Zookeeper上面看到
 this.rootPath = ROOT_PATH.getParameterValue(registryURL);
 //创建服务发现对象 实现类型为ServiceDiscoveryImpl 这个实现来源于Curator框架中的discovery模块
 this.serviceDiscovery = buildServiceDiscovery(curatorFramework, rootPath);
 //启动服务发现
 this.serviceDiscovery.start();
 } catch (Exception e) {
 throw new IllegalStateException("Create zookeeper service discovery failed.", e);
 }
 }

这个方法比较重要是应用级服务发现的实现，这里主要关注下serviceDiscovery类型的创建与启动，这个应用级服务发现的实现其实是Dubbo使用了Curator来做的，Dubbo只是在这里封装了一些方法来进行调用Curator的实现：关于Curator的官方文档可以看curator官网

关于Zookeeper上面注册服务应用级服务注册信息可以看如下图所示(后面会具体讲到数据注册时的调用）：我这个服务提供者注册的应用数据如下：

{
 "name" : "dubbo-demo-api-provider",
 "id" : "192.168.1.9:20880",
 "address" : "192.168.1.9",
 "port" : 20880,
 "sslPort" : null,
 "payload" : {
 "@class" : "org.apache.dubbo.registry.zookeeper.ZookeeperInstance",
 "id" : "192.168.1.9:20880",
 "name" : "dubbo-demo-api-provider",
 "metadata" : {
 "dubbo.endpoints" : "[{\"port\":20880,\"protocol\":\"dubbo\"}]",
 "dubbo.metadata-service.url-params" : "{\"connections\":\"1\",\"version\":\"1.0.0\",\"dubbo\":\"2.0.2\",\"release\":\"3.0.8\",\"side\":\"provider\",\"port\":\"20880\",\"protocol\":\"dubbo\"}",
 "dubbo.metadata.revision" : "a662fd2213a8a49dc6ff43a4c2ae7b9e",
 "dubbo.metadata.storage-type" : "local",
 "timestamp" : "1654916298616"
 }
 },
 "registrationTimeUTC" : 1654917265499,
 "serviceType" : "DYNAMIC",
 "uriSpec" : null
}

如果感兴趣的话可以看更详细的curator服务发现文档curator-x-discovery

17.4.2 AbstractServiceDiscovery的构造器

 public AbstractServiceDiscovery(ApplicationModel applicationModel, URL registryURL) {
 //调用重载的构造器
 this(applicationModel.getApplicationName(), registryURL);
 this.applicationModel = applicationModel;
 MetadataReportInstance metadataReportInstance = applicationModel.getBeanFactory().getBean(MetadataReportInstance.class);
 metadataType = metadataReportInstance.getMetadataType();
 this.metadataReport = metadataReportInstance.getMetadataReport(registryURL.getParameter(REGISTRY_CLUSTER_KEY));
// if (REMOTE_METADATA_STORAGE_TYPE.equals(metadataReportInstance.getMetadataType())) {
// this.metadataReport = metadataReportInstance.getMetadataReport(registryURL.getParameter(REGISTRY_CLUSTER_KEY));
// } else {
// this.metadataReport = metadataReportInstance.getNopMetadataReport();
// }
 }

重载的构造器

 public AbstractServiceDiscovery(String serviceName, URL registryURL) {
 this.applicationModel = ApplicationModel.defaultModel();
 //这个url参考：zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&interface=org.apache.dubbo.registry.client.ServiceDiscovery&pid=4570&release=3.0.8
 this.registryURL = registryURL;
 //这个serviceName参考dubbo-demo-api-provider
 this.serviceName = serviceName;
 //MetadataInfo 用来封装元数据信息
 this.metadataInfo = new MetadataInfo(serviceName);
 //这个是元数据缓存信息管理的类型 缓存文件使用LRU策略 感兴趣的可以详细看看
 //对应缓存路径为：/Users/song/.dubbo/.metadata.zookeeper127.0.0.1%003a2181.dubbo.cache
 this.metaCacheManager = new MetaCacheManager(getCacheNameSuffix(),
 applicationModel.getFrameworkModel().getBeanFactory()
 .getBean(FrameworkExecutorRepository.class).getCacheRefreshingScheduledExecutor());
 }

17.5 服务映射类型AbstractServiceNameMapping

服务映射主要是通过服务名字来反查应用信息的应用名字如下图所示这里我们来看下服务映射相关的类型主要通过如下代码来获取扩展对象：

this.serviceNameMapping = (AbstractServiceNameMapping) ServiceNameMapping.getDefaultExtension(registryURL.getScopeModel());

对应类型如下：

最终获取的扩展实现类型为：MetadataServiceNameMapping 构造器如下：

 public MetadataServiceNameMapping(ApplicationModel applicationModel) {
 super(applicationModel);
 metadataReportInstance = applicationModel.getBeanFactory().getBean(MetadataReportInstance.class);
 }

服务映射元数据父类型AbstractServiceNameMapping如下：

 public AbstractServiceNameMapping(ApplicationModel applicationModel) {
 this.applicationModel = applicationModel;
 //LRU缓存保存服务映射数据
 this.mappingCacheManager = new MappingCacheManager("",
 applicationModel.getFrameworkModel().getBeanFactory()
 .getBean(FrameworkExecutorRepository.class).getCacheRefreshingScheduledExecutor());
 }

17.4 双注册元数据信息发布到注册中心

17.4.1 回顾简介

前面注册数据的时候并没有把服务配置的元数据直接注册在注册中心而是需要在导出服务之后在ServiceConfig中来发布元数据，这个就需要我们回到ServiceConfig的exportUrl方法来看了如下所示：

private void exportUrl(URL url, List<URL> registryURLs) {
 String scope = url.getParameter(SCOPE_KEY);
 // don't export when none is configured
 ...省略到若干代码
 if (!SCOPE_LOCAL.equalsIgnoreCase(scope)) {
 url = exportRemote(url, registryURLs);
 if (!isGeneric(generic) && !getScopeModel().isInternal()) {
 MetadataUtils.publishServiceDefinition(url, providerModel.getServiceModel(), getApplicationModel());
 }
 }
 }
 this.urls.add(url);
 }

17.4.2 元数据服务定义数据的发布

在exportRemote之后单独调用发布元数据的方法来发布，通过调用元数据工具类来发布元数据信息接下来我们详细看下: MetadataUtils类型的publishServiceDefinition方法：

public static void publishServiceDefinition(URL url, ServiceDescriptor serviceDescriptor, ApplicationModel applicationModel) {
 //查询是否存在元数据存储对象 对应接口MetadataReport 这里对应实现类 ZookeeperMetadataReport
 if (getMetadataReports(applicationModel).size() == 0) {
 String msg = "Remote Metadata Report Server is not provided or unavailable, will stop registering service definition to remote center!";
 logger.warn(msg);
 }

 try {
 String side = url.getSide();
 //服务提供者走这个逻辑
 if (PROVIDER_SIDE.equalsIgnoreCase(side)) {
 String serviceKey = url.getServiceKey();
 //获取当前服务元数据信息
 FullServiceDefinition serviceDefinition = serviceDescriptor.getFullServiceDefinition(serviceKey);

 if (StringUtils.isNotEmpty(serviceKey) && serviceDefinition != null) {
 serviceDefinition.setParameters(url.getParameters());
 for (Map.Entry<String, MetadataReport> entry : getMetadataReports(applicationModel).entrySet()) {
 MetadataReport metadataReport = entry.getValue();
 if (!metadataReport.shouldReportDefinition()) {
 logger.info("Report of service definition is disabled for " + entry.getKey());
 continue;
 }
 //存储服务提供者的元数据 metadataReport类型为ZookeeperMetadataReport 方法来源于父类模板方法： AbstractMetadataReport类型的storeProviderMetadata模板方法
 metadataReport.storeProviderMetadata(
 new MetadataIdentifier(
 url.getServiceInterface(),
 url.getVersion() == null ? "" : url.getVersion(),
 url.getGroup() == null ? "" : url.getGroup(),
 PROVIDER_SIDE,
 applicationModel.getApplicationName())
 , serviceDefinition);
 }
 }
 } else {
 //服务消费者走这个逻辑
 for (Map.Entry<String, MetadataReport> entry : getMetadataReports(applicationModel).entrySet()) {
 MetadataReport metadataReport = entry.getValue();
 if (!metadataReport.shouldReportDefinition()) {
 logger.info("Report of service definition is disabled for " + entry.getKey());
 continue;
 }
 metadataReport.storeConsumerMetadata(
 new MetadataIdentifier(
 url.getServiceInterface(),
 url.getVersion() == null ? "" : url.getVersion(),
 url.getGroup() == null ? "" : url.getGroup(),
 CONSUMER_SIDE,
 applicationModel.getApplicationName()),
 url.getParameters());
 }
 }
 } catch (Exception e) {
 //ignore error
 logger.error("publish service definition metadata error.", e);
 }
 }

AbstractMetadataReport的storeProviderMetadata方法如下所示：

 @Override
 public void storeProviderMetadata(MetadataIdentifier providerMetadataIdentifier, ServiceDefinition serviceDefinition) {
 //是否同步配置对应sync-report 默认为异步
 if (syncReport) {
 storeProviderMetadataTask(providerMetadataIdentifier, serviceDefinition);
 } else {
 reportCacheExecutor.execute(() -> storeProviderMetadataTask(providerMetadataIdentifier, serviceDefinition));
 }
 }

AbstractMetadataReport的存储元数据方法storeProviderMetadataTask

private void storeProviderMetadataTask(MetadataIdentifier providerMetadataIdentifier, ServiceDefinition serviceDefinition) {
 try {
 if (logger.isInfoEnabled()) {
 logger.info("store provider metadata. Identifier : " + providerMetadataIdentifier + "; definition: " + serviceDefinition);
 }
 allMetadataReports.put(providerMetadataIdentifier, serviceDefinition);
 failedReports.remove(providerMetadataIdentifier);
 Gson gson = new Gson();
 String data = gson.toJson(serviceDefinition);
 doStoreProviderMetadata(providerMetadataIdentifier, data);
 saveProperties(providerMetadataIdentifier, data, true, !syncReport);
 } catch (Exception e) {
 // retry again. If failed again, throw exception.
 failedReports.put(providerMetadataIdentifier, serviceDefinition);
 metadataReportRetry.startRetryTask();
 logger.error("Failed to put provider metadata " + providerMetadataIdentifier + " in " + serviceDefinition + ", cause: " + e.getMessage(), e);
 }
 }

元数据信息如下：可以分为两类应用元数据，服务元数据

{
 "parameters": {
 "side": "provider",
 "interface": "link.elastic.dubbo.entity.DemoService",
 "pid": "22099",
 "application": "dubbo-demo-api-provider",
 "dubbo": "2.0.2",
 "release": "3.0.8",
 "anyhost": "true",
 "bind.ip": "192.168.1.9",
 "methods": "sayHello,sayHelloAsync",
 "background": "false",
 "deprecated": "false",
 "dynamic": "true",
 "service-name-mapping": "true",
 "generic": "false",
 "bind.port": "20880",
 "timestamp": "1654942353902"
 },
 "canonicalName": "link.elastic.dubbo.entity.DemoService",
 "codeSource": "file:/Users/song/Desktop/dubbo-test/target/classes/",
 "methods": [{
 "name": "sayHelloAsync",
 "parameterTypes": ["java.lang.String"],
 "returnType": "java.util.concurrent.CompletableFuture",
 "annotations": []
 }, {
 "name": "sayHello",
 "parameterTypes": ["java.lang.String"],
 "returnType": "java.lang.String",
 "annotations": []
 }],
 "types": [{
 "type": "java.util.concurrent.CompletableFuture",
 "properties": {
 "result": "java.lang.Object",
 "stack": "java.util.concurrent.CompletableFuture.Completion"
 }
 }, {
 "type": "java.lang.Object"
 }, {
 "type": "java.lang.String"
 }, {
 "type": "java.util.concurrent.CompletableFuture.Completion",
 "properties": {
 "next": "java.util.concurrent.CompletableFuture.Completion",
 "status": "int"
 }
 }, {
 "type": "int"
 }],
 "annotations": []
}

Zookeeper扩展类型ZookeeperMetadataReport实现的存储方法如下所示doStoreProviderMetadata：

如果我们自己实现一套元数据就可以重写这个方法来进行元数据的额存储

ZookeeperMetadataReport的doStoreProviderMetadata

 @Override
 protected void doStoreProviderMetadata(MetadataIdentifier providerMetadataIdentifier, String serviceDefinitions) {
 storeMetadata(providerMetadataIdentifier, serviceDefinitions);
 }

ZookeeperMetadataReport的storeMetadata

 private void storeMetadata(MetadataIdentifier metadataIdentifier, String v) {
 //参数false为非临时节点，这个元数据为持久节点，这个细节就暂时不看了就是将刚刚的json元数据存储到对应路径上面：路径为：/dubbo/metadata/link.elastic.dubbo.entity.DemoService/provider/dubbo-demo-api-provider
 zkClient.create(getNodePath(metadataIdentifier), v, false);
 }

原文地址：17-Dubbo服务提供者的双注册原理

Blog: 16-模块发布器发布服务全过程

Tue, 16 Aug 2022 00:00:00 +0000

16-模块发布器发布服务全过程

16.1 简介

Dubbo做为服务治理框架,比较核心的就是服务相关的概念,这里我先贴个找到的关于Dubbo工作原理的架构图: 如果按完整服务启动与订阅的顺序我们可以归结为以下6点:

导出服务(提供者)
- 服务提供方通过指定端口对外暴露服务
注册服务(提供者)
- 提供方向注册中心注册自己的信息
(服务发现)-订阅服务(消费者)
- 服务调用方通过注册中心订阅自己感兴趣的服务
(服务发现)-服务推送(消费者)
- 注册中心向调用方推送地址列表
调用服务(消费者调用提供者)
- 调用方选择一个地址发起RPC调用
监控服务
- 服务提供方和调用方的统计数据由监控模块收集展示

上面的完整的服务启动订阅与调用流程不仅仅适用于Dubbo 同样也适用于其他服务治理与发现的模型, 一般服务发现与服务调用的思路就是这样的,我们将以上内容扩展,暴漏服务可以使用http,tcp,udp等各种协议,注册服务可以注册到Redis,Dns,Etcd,Zookeeper等注册中心中,订阅服务可以主动去注册中心查询服务列表,服务发现可以让注册中心将服务数据动态推送给消费者.Dubbo其实就是基于这种简单的服务模型来扩展出各种功能的支持,来满足服务治理的各种场景,了解了这里可能各位同学就想着自行开发一个简单的微服务框架了。

回到主题,从以上的服务完整发布调用流程可以看到,所有的功能都是由导出服务(提供者)开始的,只有提供者先提供了服务才可以有真正的服务让消费者调用。

之前的博客内容链接:«12-全局视野来看Dubbo3.0.8的服务启动生命周期» 我们了解了 DefaultModuleDeployer模块器启动的流程,其中在start代码的模版方法中开始了导出服务的功能,这里我们来详细看下服务发布的全过程:

入口代码: DefaultModuleDeployer的发布服务方法

 private void exportServices() {
 //从配置管缓存中查询缓存的所有的服务配置然后逐个服务发布
 for (ServiceConfigBase sc : configManager.getServices()) {
 exportServiceInternal(sc);
 }
 }

16.2 导出服务的入口

入口代码: DefaultModuleDeployer的发布服务方法

 private void exportServices() {
 //从配置管缓存中查询缓存的所有的服务配置然后逐个服务发布
 for (ServiceConfigBase sc : configManager.getServices()) {
 exportServiceInternal(sc);
 }
 }

主要流程为遍历初始化的服务配置列表然后逐个服务开始到处内部导出服务代码: exportServiceInternal方法:

 private void exportServiceInternal(ServiceConfigBase sc) {

 ServiceConfig<?> serviceConfig = (ServiceConfig<?>) sc;
 //服务配置刷新 配置优先级覆盖
 if (!serviceConfig.isRefreshed()) {
 serviceConfig.refresh();
 }
 //服务已经导出过了就直接返回
 if (sc.isExported()) {
 return;
 }
 //是否异步方式导出 全局配置或者服务级其中一个配置了异步则异步处理
 if (exportAsync || sc.shouldExportAsync()) {
 //异步其实就是使用线程来导出服务serviceExportExecutor
 ExecutorService executor = executorRepository.getServiceExportExecutor();
 CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
 try {
 if (!sc.isExported()) {
 sc.export();
 exportedServices.add(sc);
 }
 } catch (Throwable t) {
 logger.error(getIdentifier() + " export async catch error : " + t.getMessage(), t);
 }
 }, executor);

 asyncExportingFutures.add(future);
 } else {
 //同步导出服务
 if (!sc.isExported()) {
 sc.export();
 exportedServices.add(sc);
 }
 }
 }

这个逻辑里面做了一些基本的操作,可以直接看注释然后调用ServiceConfig的export的来导出服务,继续往后看服务配置的导出服务方法。

16.3 服务配置导出服务模板方法

核心的服务导出代码是在服务配置中来做的ServiceConfig的 export() 方法 ServiceConfig的 export() 方法代码如下:


 @Override
 public void export() {
 //已经导出过服务直接放那会
 if (this.exported) {
 return;
 }

 // ensure start module, compatible with old api usage
 //确保模块启动了(基本的初始化操作执行了)
 getScopeModel().getDeployer().start();
 //悲观锁
 synchronized (this) {
 //双重校验
 if (this.exported) {
 return;
 }
 //配置是否刷新 前面初始化时候已经刷新过配置
 if (!this.isRefreshed()) {
 this.refresh();
 }
 //服务导出配置配置为false则不导出
 if (this.shouldExport()) {
 //服务发布前初始化一下元数据对象
 this.init();

 if (shouldDelay()) {
 //配置了服务的延迟发布配置则走延迟发布逻辑
 doDelayExport();
 } else {
 //导出服务
 doExport();
 }
 }
 }
 }

16.3.1 服务配置导出服务前的初始化方法

ServiceConfig 导出服务之前的初始化方法init

public void init() {
 if (this.initialized.compareAndSet(false, true)) {
 //加载服务监听器 这里暂时没有服务监听器扩展
 // load ServiceListeners from extension
 ExtensionLoader<ServiceListener> extensionLoader = this.getExtensionLoader(ServiceListener.class);
 this.serviceListeners.addAll(extensionLoader.getSupportedExtensionInstances());
 }
 //服务提供者配置传递给元数据配置对象 一个服务提供者配置会有一个元数据配置，服务配置
 initServiceMetadata(provider);
 //元数据
 serviceMetadata.setServiceType(getInterfaceClass());

 serviceMetadata.setTarget(getRef());
 //元数据的key格式为 group/服务接口:版本号
 serviceMetadata.generateServiceKey();
 }

16.4 服务配置导出服务模板方法2

ServiceConfig 导出服务核心逻辑

protected synchronized void doExport() {
 //取消发布
 if (unexported) {
 throw new IllegalStateException("The service " + interfaceClass.getName() + " has already unexported!");
 }
 //已经发布
 if (exported) {
 return;
 }
 //服务路径 为空则设置为接口名，本例子中为link.elastic.dubbo.entity.DemoService
 if (StringUtils.isEmpty(path)) {
 path = interfaceName;
 }
 //导出URL
 doExportUrls();
 //
 exported();
 }

16.4.1 导出服务的URL配置逻辑

ServiceConfig 导出URL核心逻辑

 private void doExportUrls() {
 //模块服务存储库
 ModuleServiceRepository repository = getScopeModel().getServiceRepository();
 ServiceDescriptor serviceDescriptor;
 //ref为服务实现类型 这里对应我们例子的DemoServiceImpl
 final boolean serverService = ref instanceof ServerService;
 if(serverService){
 serviceDescriptor=((ServerService) ref).getServiceDescriptor();
 repository.registerService(serviceDescriptor);
 }else{
 //我们代码走这个逻辑 注册服务 这个注册不是向注册中心注册 这个是解析服务接口将服务方法等描述信息存放在了服务存储ModuleServiceRepository类型对象的成员变量services中
 serviceDescriptor = repository.registerService(getInterfaceClass());
 }
 //提供者领域模型， 提供者领域模型 封装了一些提供者需要的就基本属性同时内部解析封装方法信息 ProviderMethodModel 列表 ， 服务标识符 格式group/服务接:版本号
 providerModel = new ProviderModel(getUniqueServiceName(),
 //服务实现类DemoServiceImpl
 ref,
 //服务描述符 描述符里面包含了服务接口的方法信息，不过服务接口通过反射也可以拿到方法信息
 serviceDescriptor,
 //服务配置
 this,
 //当前所处模型
 getScopeModel(),
 //当前服务接口的元数据对象
 serviceMetadata);

 //模块服务存储库存储提供者模型对象ModuleServiceRepository
 repository.registerProvider(providerModel);
 //获取配置的注册中心列表 ，同时将注册中心配置转URL （在Dubbo中URL就是配置信息的一种形式）
 //这里会获取到两个 由dubbo.application.register-mode 双注册配置决定
 //注册中心 registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=9008&registry=zookeeper&release=3.0.8&timestamp=1653703292768
 //service-discovery-registry://8.131.79.126:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=10275&registry=zookeeper&release=3.0.8&timestamp=1653704425920
 //参数dubbo是dubbo协议的版本不是Dubbo版本 Dubbo RPC protocol version, for compatibility, it must not be between 2.0.10 ~ 2.6.2
 //这里后面详细说下 服务双注册 dubbo.application.register-mode
 List<URL> registryURLs = ConfigValidationUtils.loadRegistries(this, true);

 for (ProtocolConfig protocolConfig : protocols) {
 String pathKey = URL.buildKey(getContextPath(protocolConfig)
 .map(p -> p + "/" + path)
 .orElse(path), group, version);
 // stub service will use generated service name
 if(!serverService) {
 // In case user specified path, register service one more time to map it to path.
 //模块服务存储库ModuleServiceRepository存储服务接口信息
 repository.registerService(pathKey, interfaceClass);
 }
 //导出根据协议导出配置到注册中心
 doExportUrlsFor1Protocol(protocolConfig, registryURLs);
 }
 }

16.4.2 应用级和接口级服务注册地址获取

这里主要看下注册中心的获取，这里涉及到服务的双注册配置

List<URL> registryURLs = ConfigValidationUtils.loadRegistries(this, true);

关于loadRegistries方法的详情我们就不看了主要看loadRegistries方法中调用的genCompatibleRegistries添加服务发现注册中心

 /**
 * @param scopeModel 域模型
 * @param registryList 配置的注册中心列表 例如：registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=9008&registry=zookeeper&release=3.0.8&timestamp=1653703292768
 *
 * @param provider 是否为服务提供者 这里Demo为true
 */
private static List<URL> genCompatibleRegistries(ScopeModel scopeModel, List<URL> registryList, boolean provider) {
 List<URL> result = new ArrayList<>(registryList.size());
 //遍历所有的注册中心 为每个注册中心增加兼容的服务发现注册中心地址配置
 registryList.forEach(registryURL -> {
 //是否为提供者
 if (provider) {
 // for registries enabled service discovery, automatically register interface compatible addresses.

 String registerMode;
 //注册协议配置了service-discovery-registry 走这个逻辑
 //前面这个逻辑是直接接给result结果中添加应用级注册，如果是all配置则增加接口级注册信息
 if (SERVICE_REGISTRY_PROTOCOL.equals(registryURL.getProtocol())) {
 registerMode = registryURL.getParameter(REGISTER_MODE_KEY, ConfigurationUtils.getCachedDynamicProperty(scopeModel, DUBBO_REGISTER_MODE_DEFAULT_KEY, DEFAULT_REGISTER_MODE_INSTANCE));
 if (!isValidRegisterMode(registerMode)) {
 registerMode = DEFAULT_REGISTER_MODE_INSTANCE;
 }
 //这里配置的就是应用级配置 则先添加应用级地址，再根据条件判断是否添加接口级注册中心地址
 result.add(registryURL);
 if (DEFAULT_REGISTER_MODE_ALL.equalsIgnoreCase(registerMode)
 && registryNotExists(registryURL, registryList, REGISTRY_PROTOCOL)) {
 URL interfaceCompatibleRegistryURL = URLBuilder.from(registryURL)
 .setProtocol(REGISTRY_PROTOCOL)
 .removeParameter(REGISTRY_TYPE_KEY)
 .build();
 result.add(interfaceCompatibleRegistryURL);
 }
 } else {
 //正常情况下我们的配置会走这个逻辑
 // 获取服务注册的注册模式 配置为dubbo.application.register-mode 默认值为all 既注册接口数据又注册应用级信息
 registerMode = registryURL.getParameter(REGISTER_MODE_KEY, ConfigurationUtils.getCachedDynamicProperty(scopeModel, DUBBO_REGISTER_MODE_DEFAULT_KEY, DEFAULT_REGISTER_MODE_ALL));

 if (!isValidRegisterMode(registerMode)) {
 registerMode = DEFAULT_REGISTER_MODE_INTERFACE;
 }
 //根据逻辑条件判断是否添加应用级注册中心地址
 if ((DEFAULT_REGISTER_MODE_INSTANCE.equalsIgnoreCase(registerMode) || DEFAULT_REGISTER_MODE_ALL.equalsIgnoreCase(registerMode))
 && registryNotExists(registryURL, registryList, SERVICE_REGISTRY_PROTOCOL)) {
 URL serviceDiscoveryRegistryURL = URLBuilder.from(registryURL)
 .setProtocol(SERVICE_REGISTRY_PROTOCOL)
 .removeParameter(REGISTRY_TYPE_KEY)
 .build();
 result.add(serviceDiscoveryRegistryURL);
 }
 //根据逻辑条件判断是否添加接口级注册中心地址
 if (DEFAULT_REGISTER_MODE_INTERFACE.equalsIgnoreCase(registerMode) || DEFAULT_REGISTER_MODE_ALL.equalsIgnoreCase(registerMode)) {
 result.add(registryURL);
 }
 }

 FrameworkStatusReportService reportService = ScopeModelUtil.getApplicationModel(scopeModel).getBeanFactory().getBean(FrameworkStatusReportService.class);
 reportService.reportRegistrationStatus(reportService.createRegistrationReport(registerMode));
 } else {
 result.add(registryURL);
 }
 });

 return result;
 }

这个方法是根据服务注册模式来判断使用接口级注册地址还是应用级注册地址分别如下所示：配置信息： dubbo.application.register-mode 配置值：

interface
- 接口级注册
instance
- 应用级注册
all
- 接口级别和应用级都注册

接口级注册地址：

registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=9008&registry=zookeeper&release=3.0.8&timestamp=1653703292768

应用级注册地址：

service-discovery-registry://8.131.79.126:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=10275&registry=zookeeper&release=3.0.8&timestamp=1653704425920

16.5 导出服务配置到本地和注册中心

 doExportUrlsFor1Protocol(protocolConfig, registryURLs);

protocolConfig为：dubbo协议的配置 <dubbo:protocol port="-1" name=“dubbo” />

registryURLs目前有两个应用级注册地址和接口级注册地址：

registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=9008&registry=zookeeper&release=3.0.8&timestamp=1653703292768

service-discovery-registry://8.131.79.126:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=10275&registry=zookeeper&release=3.0.8&timestamp=1653704425920

16.5.1 导出服务配置的doExportUrlsFor1Protocol方法

 private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) {
 //生成协议配置具体可见下图中的元数据配置中的attachments
 Map<String, String> map = buildAttributes(protocolConfig);

 // remove null key and null value
 //移除空值 简化配置
 map.keySet().removeIf(key -> key == null || map.get(key) == null);
 // init serviceMetadata attachments
 //协议配置放到元数据对象中
 serviceMetadata.getAttachments().putAll(map);

 //协议配置 + 默认协议配置转URL类型的配置存储
 URL url = buildUrl(protocolConfig, map);
 //导出url
 exportUrl(url, registryURLs);
 }

16.5.2 导出服务配置模板方法

继续看导出服务的模板方法，分为本地导出和注册中心导出 //参数url为协议配置url可以参考：

dubbo://192.168.1.9:20880/link.elastic.dubbo.entity.DemoService?anyhost=true&application=dubbo-demo-api-provider&background=false&bind.ip=192.168.1.9&bind.port=20880&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=link.elastic.dubbo.entity.DemoService&methods=sayHello,sayHelloAsync&pid=10953&release=3.0.8&side=provider&timestamp=1653705630518

private void exportUrl(URL url, List<URL> registryURLs) {
 String scope = url.getParameter(SCOPE_KEY);
 // don't export when none is configured
 if (!SCOPE_NONE.equalsIgnoreCase(scope)) {

 // export to local if the config is not remote (export to remote only when config is remote)
 //未明确指定远程导出 则开启本地导出
 if (!SCOPE_REMOTE.equalsIgnoreCase(scope)) {
 exportLocal(url);
 }
 //未明确指定本地导出 则开启远程导出
 // export to remote if the config is not local (export to local only when config is local)
 if (!SCOPE_LOCAL.equalsIgnoreCase(scope)) {
 url = exportRemote(url, registryURLs);
 if (!isGeneric(generic) && !getScopeModel().isInternal()) {
 MetadataUtils.publishServiceDefinition(url, providerModel.getServiceModel(), getApplicationModel());
 }
 }
 }
 this.urls.add(url);
 }

16.6 导出服务到本地

本地调用使用了 injvm 协议，是一个伪协议，它不开启端口，不发起远程调用，只在 JVM 内直接关联，但执行 Dubbo 的 Filter 链。

直接通过代码来看吧

 private void exportLocal(URL url) {
 //协议转为injvm 代表本地导出 host为127.0.0.1
 URL local = URLBuilder.from(url)
 .setProtocol(LOCAL_PROTOCOL)
 .setHost(LOCALHOST_VALUE)
 .setPort(0)
 .build();
 local = local.setScopeModel(getScopeModel())
 .setServiceModel(providerModel);
 doExportUrl(local, false);
 logger.info("Export dubbo service " + interfaceClass.getName() + " to local registry url : " + local);
 }

16.6.1 doExportUrl方法

private void doExportUrl(URL url, boolean withMetaData) {
 //这里是由adaptor扩展类型处理过的 我们直接看默认的类型javassist 对应JavassistProxyFactory代理工厂 获取调用对象 （
 Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url);
 if (withMetaData) {
 invoker = new DelegateProviderMetaDataInvoker(invoker, this);
 }
 Exporter<?> exporter = protocolSPI.export(invoker);
 exporters.add(exporter);
 }

16.6.2 JavassistProxyFactory类型的getInvoker方法

@Override
 public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) {
 try {
 // TODO Wrapper cannot handle this scenario correctly: the classname contains '$'
 // 创建实际服务提供者的代理类型，代理类型后缀为DubboWrap在这里类型为 link.elastic.dubbo.entity.DemoServiceImplDubboWrap0
 final Wrapper wrapper = Wrapper.getWrapper(proxy.getClass().getName().indexOf('$') < 0 ? proxy.getClass() : type);
 //创建一个匿名内部类对象 继承自AbstractProxyInvoker的Invoker对象
 return new AbstractProxyInvoker<T>(proxy, type, url) {
 @Override
 protected Object doInvoke(T proxy, String methodName,
 Class<?>[] parameterTypes,
 Object[] arguments) throws Throwable {
 return wrapper.invokeMethod(proxy, methodName, parameterTypes, arguments);
 }
 };
 } catch (Throwable fromJavassist) {
 // try fall back to JDK proxy factory
 ...
 }
 }
 }

16.6.3 使用协议导出调用对象 export

 Exporter<?> exporter = protocolSPI.export(invoker);

这个使用了Adaptor扩展和Wrapper机制Debug起来不太方便这里贴一下调用堆栈

16.6.3.1 协议序列化机制ProtocolSerializationWrapper

 @Override
 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
 //这里主要逻辑是将服务提供者url添加到服务存储仓库中
 getFrameworkModel(invoker.getUrl().getScopeModel()).getServiceRepository().registerProviderUrl(invoker.getUrl());
 return protocol.export(invoker);
 }

16.6.3.2 协议过滤器Wrapper ProtocolFilterWrapper

 @Override
 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
 //注册中心的协议导出直接执行
 if (UrlUtils.isRegistry(invoker.getUrl())) {
 return protocol.export(invoker);
 }
 //过滤器调用链FilterChainBuilder的扩展对象查询
 FilterChainBuilder builder = getFilterChainBuilder(invoker.getUrl());
 //这里分为2步 生成过滤器调用链 然后使用链表中的节点调用 这里值查询provider类型的过滤器
 return protocol.export(builder.buildInvokerChain(invoker, SERVICE_FILTER_KEY, CommonConstants.PROVIDER));
 }

过滤器调用链的生成对用DefaultFilterChainBuilder类型的buildInvokerChain方法

@Override
 public <T> Invoker<T> buildInvokerChain(final Invoker<T> originalInvoker, String key, String group) {
 //originalInvoker代表真正的服务调用器
 Invoker<T> last = originalInvoker;
 URL url = originalInvoker.getUrl();
 List<ModuleModel> moduleModels = getModuleModelsFromUrl(url);
 List<Filter> filters;
 if (moduleModels != null && moduleModels.size() == 1) {
 //类型Filter key为service.filter 分组为provider 所有提供者过滤器拉取
 filters = ScopeModelUtil.getExtensionLoader(Filter.class, moduleModels.get(0)).getActivateExtension(url, key, group);
 } else if (moduleModels != null && moduleModels.size() > 1) {
 filters = new ArrayList<>();
 List<ExtensionDirector> directors = new ArrayList<>();
 for (ModuleModel moduleModel : moduleModels) {
 List<Filter> tempFilters = ScopeModelUtil.getExtensionLoader(Filter.class, moduleModel).getActivateExtension(url, key, group);
 filters.addAll(tempFilters);
 directors.add(moduleModel.getExtensionDirector());
 }
 filters = sortingAndDeduplication(filters, directors);

 } else {
 filters = ScopeModelUtil.getExtensionLoader(Filter.class, null).getActivateExtension(url, key, group);
 }

 //倒序拼接，将过滤器的调用对象添加到链表中 最后倒序遍历之后 last节点指向了调用链路链表头节点的对象
 if (!CollectionUtils.isEmpty(filters)) {
 for (int i = filters.size() - 1; i >= 0; i--) {
 final Filter filter = filters.get(i);
 final Invoker<T> next = last;
 //每个invoker对象中都有originalInvoker对象
 last = new CopyOfFilterChainNode<>(originalInvoker, next, filter);
 }
 return new CallbackRegistrationInvoker<>(last, filters);
 }

 return last;
 }

16.6.3.3 协议监听器Wrapper ProtocolListenerWrapper

 @Override
 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
 //注册中心地址则直接导出
 if (UrlUtils.isRegistry(invoker.getUrl())) {
 return protocol.export(invoker);
 }
 // 先导出对象 再创建过滤器包装对象 执行监听器逻辑
 return new ListenerExporterWrapper<T>(protocol.export(invoker),
 Collections.unmodifiableList(ScopeModelUtil.getExtensionLoader(ExporterListener.class, invoker.getUrl().getScopeModel())
 .getActivateExtension(invoker.getUrl(), EXPORTER_LISTENER_KEY)));
 }

16.6.3.4 QOS的协议Wrapper QosProtocolWrapper

@Override
 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
 //注册中心导出的时候开启QOS 默认端口22222
 if (UrlUtils.isRegistry(invoker.getUrl())) {
 startQosServer(invoker.getUrl());
 return protocol.export(invoker);
 }
 return protocol.export(invoker);
 }

16.6.3.5 InjvmProtocol 的导出方法

 @Override
 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
 return new InjvmExporter<T>(invoker, invoker.getUrl().getServiceKey(), exporterMap);
 }

16.7 导出服务到注册中心

16.5.2 导出服务配置模板方法中我们看到了服务导出会导出到本地和远程，接下来就看下导出到远程的方法exportRemote 参数url:

dubbo://192.168.1.9:20880/link.elastic.dubbo.entity.DemoService?anyhost=true&application=dubbo-demo-api-provider&background=false&bind.ip=192.168.1.9&bind.port=20880&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=link.elastic.dubbo.entity.DemoService&methods=sayHello,sayHelloAsync&pid=12865&release=3.0.8&side=provider&timestamp=1653708351378

参数registryURLs目前有两个应用级注册地址和接口级注册地址：

registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=9008&registry=zookeeper&release=3.0.8&timestamp=1653703292768

service-discovery-registry://8.131.79.126:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=10275&registry=zookeeper&release=3.0.8&timestamp=1653704425920

private URL exportRemote(URL url, List<URL> registryURLs) {

 if (CollectionUtils.isNotEmpty(registryURLs)) {
 //遍历所有注册地址与注册模式 逐个注册
 for (URL registryURL : registryURLs) {
 //为协议URL 添加应用级注册service-discovery-registry参数service-name-mapping为true
 if (SERVICE_REGISTRY_PROTOCOL.equals(registryURL.getProtocol())) {
 url = url.addParameterIfAbsent(SERVICE_NAME_MAPPING_KEY, "true");
 }

 //if protocol is only injvm ,not register
 if (LOCAL_PROTOCOL.equalsIgnoreCase(url.getProtocol())) {
 continue;
 }
 //为协议url 添加动态配置dynamic
 url = url.addParameterIfAbsent(DYNAMIC_KEY, registryURL.getParameter(DYNAMIC_KEY));
 //监控配置暂时为null
 URL monitorUrl = ConfigValidationUtils.loadMonitor(this, registryURL);
 if (monitorUrl != null) {
 url = url.putAttribute(MONITOR_KEY, monitorUrl);
 }

 // For providers, this is used to enable custom proxy to generate invoker
 String proxy = url.getParameter(PROXY_KEY);
 if (StringUtils.isNotEmpty(proxy)) {
 registryURL = registryURL.addParameter(PROXY_KEY, proxy);
 }

 //开始注册服务了 打印个认知 提示下
 if (logger.isInfoEnabled()) {
 if (url.getParameter(REGISTER_KEY, true)) {
 logger.info("Register dubbo service " + interfaceClass.getName() + " url " + url + " to registry " + registryURL.getAddress());
 } else {
 logger.info("Export dubbo service " + interfaceClass.getName() + " to url " + url);
 }
 }

 doExportUrl(registryURL.putAttribute(EXPORT_KEY, url), true);
 }

 } else {

 if (logger.isInfoEnabled()) {
 logger.info("Export dubbo service " + interfaceClass.getName() + " to url " + url);
 }

 doExportUrl(url, true);
 }


 return url;
 }

16.7.1 doExportUrl方法

与 16.6.1 doExportUrl方法导出本地协议是一样的逻辑，我们来看看点不同地方

private void doExportUrl(URL url, boolean withMetaData) {
 Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url);
 if (withMetaData) {
 //远程服务导出逐个值为true 元数据invoker包装一下
 invoker = new DelegateProviderMetaDataInvoker(invoker, this);
 }
 Exporter<?> exporter = protocolSPI.export(invoker);
 exporters.add(exporter);
 }

与本地导出ProtocolFilterWrapper的不同之处服务发现service-discovery-registry的导出UrlUtils.isRegistry(invoker.getUrl() 判断结果为true会走这个逻辑

 @Override
 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
 //注册中心的协议导出直接执行
 // 服务发现service-discovery-registry的导出会走这个逻辑
 if (UrlUtils.isRegistry(invoker.getUrl())) {
 return protocol.export(invoker);
 }
 //过滤器调用链FilterChainBuilder的扩展对象查询
 FilterChainBuilder builder = getFilterChainBuilder(invoker.getUrl());
 //这里分为2步 生成过滤器调用链 然后使用链表中的节点调用 这里值查询provider类型的过滤器
 return protocol.export(builder.buildInvokerChain(invoker, SERVICE_FILTER_KEY, CommonConstants.PROVIDER));
 }

与协议监听器Wrapper ProtocolListenerWrapper 的不同之处

服务发现service-discovery-registry的导出UrlUtils.isRegistry(invoker.getUrl() 判断结果为true会走这个逻辑

 @Override
 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
 //注册中心地址则直接导出
 // 服务发现service-discovery-registry的导出会走这个逻辑
 if (UrlUtils.isRegistry(invoker.getUrl())) {
 return protocol.export(invoker);
 }
 // 先导出对象 再创建过滤器包装对象 执行监听器逻辑
 return new ListenerExporterWrapper<T>(protocol.export(invoker),
 Collections.unmodifiableList(ScopeModelUtil.getExtensionLoader(ExporterListener.class, invoker.getUrl().getScopeModel())
 .getActivateExtension(invoker.getUrl(), EXPORTER_LISTENER_KEY)));
 }

与 16.6.3.4 QOS的协议Wrapper QosProtocolWrapper 不同之处

服务发现service-discovery-registry的导出UrlUtils.isRegistry(invoker.getUrl() 判断结果为true会走这个逻辑

@Override
 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
 //注册中心导出的时候开启QOS 默认端口22222
 if (UrlUtils.isRegistry(invoker.getUrl())) {
 startQosServer(invoker.getUrl());
 return protocol.export(invoker);
 }
 return protocol.export(invoker);
 }

启动QOS服务startQosServer

private void startQosServer(URL url) {
 try {
 if (!hasStarted.compareAndSet(false, true)) {
 return;
 }

 boolean qosEnable = url.getParameter(QOS_ENABLE, true);
 if (!qosEnable) {
 logger.info("qos won't be started because it is disabled. " +
 "Please check dubbo.application.qos.enable is configured either in system property, " +
 "dubbo.properties or XML/spring-boot configuration.");
 return;
 }

 String host = url.getParameter(QOS_HOST);
 int port = url.getParameter(QOS_PORT, QosConstants.DEFAULT_PORT);
 boolean acceptForeignIp = Boolean.parseBoolean(url.getParameter(ACCEPT_FOREIGN_IP, "false"));
 Server server = frameworkModel.getBeanFactory().getBean(Server.class);
 server.setHost(host);
 server.setPort(port);
 server.setAcceptForeignIp(acceptForeignIp);
 server.start();

 } catch (Throwable throwable) {
 logger.warn("Fail to start qos server: ", throwable);
 }

QOS的Server的启动方法start

public void start() throws Throwable {
 if (!started.compareAndSet(false, true)) {
 return;
 }
 //1个主线程
 boss = new NioEventLoopGroup(1, new DefaultThreadFactory("qos-boss", true));
 //0个从线程
 worker = new NioEventLoopGroup(0, new DefaultThreadFactory("qos-worker", true));
 //服务端启动器，和参数设置
 ServerBootstrap serverBootstrap = new ServerBootstrap();
 serverBootstrap.group(boss, worker);
 serverBootstrap.channel(NioServerSocketChannel.class);
 serverBootstrap.option(ChannelOption.SO_REUSEADDR, true);
 serverBootstrap.childOption(ChannelOption.TCP_NODELAY, true);
 serverBootstrap.childHandler(new ChannelInitializer<Channel>() {

 @Override
 protected void initChannel(Channel ch) throws Exception {
 ch.pipeline().addLast(new QosProcessHandler(frameworkModel, welcome, acceptForeignIp));
 }
 });
 try {
 if (StringUtils.isBlank(host)) {
 serverBootstrap.bind(port).sync();
 } else {
 serverBootstrap.bind(host, port).sync();
 }

 logger.info("qos-server bind localhost:" + port);
 } catch (Throwable throwable) {
 logger.error("qos-server can not bind localhost:" + port, throwable);
 throw throwable;
 }
 }

QOS处理器为QosProcessHandler关于QosProcessHandler的细节这里先不说

最后一个不同的地方调用链路走的这个 RegistryProtocol

16.7.2 通过注册协议导出服务与注册服务的流程

RegistryProtocol的导出方法：这个方法非常重要也是服务注册的核心代码，先概括下包含了哪些步骤

覆盖配置
导出协议端口开启TCP服务
注册到注册中心
通知服务启动了

 @Override
 public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
 //service-discovery-registry://8.131.79.126:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=14256&registry=zookeeper&release=3.0.8&timestamp=1653710477057
 URL registryUrl = getRegistryUrl(originInvoker);
 // url to export locally
 //dubbo://192.168.1.9:20880/link.elastic.dubbo.entity.DemoService?anyhost=true&application=dubbo-demo-api-provider&background=false&bind.ip=192.168.1.9&bind.port=20880&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=link.elastic.dubbo.entity.DemoService&methods=sayHello,sayHelloAsync&pid=14256&release=3.0.8&service-name-mapping=true&side=provider&timestamp=1653710479073
 URL providerUrl = getProviderUrl(originInvoker);

 // Subscribe the override data
 // FIXME When the provider subscribes, it will affect the scene : a certain JVM exposes the service and call
 // the same service. Because the subscribed is cached key with the name of the service, it causes the
 // subscription information to cover.
 //provider://192.168.1.9:20880/link.elastic.dubbo.entity.DemoService?anyhost=true&application=dubbo-demo-api-provider&background=false&bind.ip=192.168.1.9&bind.port=20880&category=configurators&check=false&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=link.elastic.dubbo.entity.DemoService&methods=sayHello,sayHelloAsync&pid=14256&release=3.0.8&service-name-mapping=true&side=provider&timestamp=1653710479073

 final URL overrideSubscribeUrl = getSubscribedOverrideUrl(providerUrl);
 //override配置
 final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);
 Map<URL, NotifyListener> overrideListeners = getProviderConfigurationListener(providerUrl).getOverrideListeners();
 overrideListeners.put(registryUrl, overrideSubscribeListener);

 providerUrl = overrideUrlWithConfig(providerUrl, overrideSubscribeListener);

 //export invoker
 final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker, providerUrl);

 // url to registry
 //通过URL获取 注册中心Registry操作对象
 final Registry registry = getRegistry(registryUrl);
 //需要向注册中心注册地址转换
 //dubbo://192.168.1.9:20880/link.elastic.dubbo.entity.DemoService?anyhost=true&application=dubbo-demo-api-provider&background=false&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=link.elastic.dubbo.entity.DemoService&methods=sayHello,sayHelloAsync&pid=14656&release=3.0.8&service-name-mapping=true&side=provider&timestamp=1653711086189
 final URL registeredProviderUrl = getUrlToRegistry(providerUrl, registryUrl);

 // decide if we need to delay publish (provider itself and registry should both need to register)
 boolean register = providerUrl.getParameter(REGISTER_KEY, true) && registryUrl.getParameter(REGISTER_KEY, true);
 //是否向注册中心注册
 if (register) {
 register(registry, registeredProviderUrl);
 }

 // register stated url on provider model
 registerStatedUrl(registryUrl, registeredProviderUrl, register);


 exporter.setRegisterUrl(registeredProviderUrl);
 exporter.setSubscribeUrl(overrideSubscribeUrl);

 if (!registry.isServiceDiscovery()) {
 // Deprecated! Subscribe to override rules in 2.6.x or before.
 registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);
 }
 //内置监听器通知 这个不是通知消费者的
 notifyExport(exporter);
 //Ensure that a new exporter instance is returned every time export
 return new DestroyableExporter<>(exporter);
 }

16.8 doLocalExport本地导出协议开启端口

前面已经看过了本地协议JVM协议的服务导出和注册中心配置的导出，这里可以直接看一些关键代码：

 private <T> ExporterChangeableWrapper<T> doLocalExport(final Invoker<T> originInvoker, URL providerUrl) {
 String key = getCacheKey(originInvoker);

 return (ExporterChangeableWrapper<T>) bounds.computeIfAbsent(key, s -> {
 Invoker<?> invokerDelegate = new InvokerDelegate<>(originInvoker, providerUrl);
 //代码中用的这个protoco对象是dubbo自动生成的适配器对象protocol$Adaptive 适配器对象会根据当前协议的参数来查询具体的协议扩展对象
 return new ExporterChangeableWrapper<>((Exporter<T>) protocol.export(invokerDelegate), originInvoker);
 });
 }

上面这个protocol$Adaptive 协议的export导出方法与之前的一样也会经历下面几个过程，具体细节可以参考JVM协议的导出：

ProtocolSerializationWrapper
ProtocolFilterWrapper
ProtocolListenerWrapper
QosProtocolWrapper
唯一不同的是我们这里对应的协议扩展类型为DubboProtocol、接下来来看下DubboProtocol的导出服务export方法实现：

 @Override
 public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
 checkDestroyed();
 //服务提供者的url参考例子dubbo://192.168.1.9:20880/link.elastic.dubbo.entity.DemoService?anyhost=true&application=dubbo-demo-api-provider&background=false&bind.ip=192.168.1.9&bind.port=20880&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=link.elastic.dubbo.entity.DemoService&methods=sayHello,sayHelloAsync&pid=6043&release=3.0.8&service-name-mapping=true&side=provider&timestamp=1654224285437
 URL url = invoker.getUrl();

 // export service.
 //生成服务的key参考：link.elastic.dubbo.entity.DemoService:20880
 String key = serviceKey(url);
 //创建导出服务用的导出器DubboExporter
 DubboExporter<T> exporter = new DubboExporter<T>(invoker, key, exporterMap);

 //export a stub service for dispatching event
 //stub配置校验
 Boolean isStubSupportEvent = url.getParameter(STUB_EVENT_KEY, DEFAULT_STUB_EVENT);
 Boolean isCallbackservice = url.getParameter(IS_CALLBACK_SERVICE, false);
 if (isStubSupportEvent && !isCallbackservice) {
 String stubServiceMethods = url.getParameter(STUB_EVENT_METHODS_KEY);
 if (stubServiceMethods == null || stubServiceMethods.length() == 0) {
 if (logger.isWarnEnabled()) {
 logger.warn(new IllegalStateException("consumer [" + url.getParameter(INTERFACE_KEY) +
 "], has set stubproxy support event ,but no stub methods founded."));
 }

 }
 }
 //创建服务开启服务端口
 openServer(url);
 //
 optimizeSerialization(url);

 return exporter;
 }

开启服务端口

这里就到了RPC协议的TCP通信模块了，对应DubboProtocol 的 openServer(url);方法

 private void openServer(URL url) {
 checkDestroyed();
 // find server. 地址作为key这里是192.168.1.9:20880
 String key = url.getAddress();
 // client can export a service which only for server to invoke
 //默认提供者开启服务，消费者是不能开启服务的
 boolean isServer = url.getParameter(IS_SERVER_KEY, true);
 if (isServer) {
 //协议服务器 下面一个双重校验锁检查，如果为空则创建服务
 ProtocolServer server = serverMap.get(key);
 if (server == null) {
 synchronized (this) {
 server = serverMap.get(key);
 if (server == null) {
 serverMap.put(key, createServer(url));
 }else {
 server.reset(url);
 }
 }
 } else {
 // server supports reset, use together with override
 server.reset(url);
 }
 }
 }

为当前地址创建协议服务对应方法如下： DubboProtocol的createServer方法

private ProtocolServer createServer(URL url) {
 //下面将url增加了心跳参数最终如下dubbo://192.168.1.9:20880/link.elastic.dubbo.entity.DemoService?anyhost=true&application=dubbo-demo-api-provider&background=false&bind.ip=192.168.1.9&bind.port=20880&channel.readonly.sent=true&codec=dubbo&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&heartbeat=60000&interface=link.elastic.dubbo.entity.DemoService&methods=sayHello,sayHelloAsync&pid=6700&release=3.0.8&service-name-mapping=true&side=provider&timestamp=1654225251112
 url = URLBuilder.from(url)
 // send readonly event when server closes, it's enabled by default
 .addParameterIfAbsent(CHANNEL_READONLYEVENT_SENT_KEY, Boolean.TRUE.toString())
 // enable heartbeat by default
 .addParameterIfAbsent(HEARTBEAT_KEY, String.valueOf(DEFAULT_HEARTBEAT))
 .addParameter(CODEC_KEY, DubboCodec.NAME)
 .build();
 //这里服务端使用的网络库这里是默认值netty
 String str = url.getParameter(SERVER_KEY, DEFAULT_REMOTING_SERVER);

 if (StringUtils.isNotEmpty(str) && !url.getOrDefaultFrameworkModel().getExtensionLoader(Transporter.class).hasExtension(str)) {
 throw new RpcException("Unsupported server type: " + str + ", url: " + url);
 }
 //dubbo交换器层对象创建
 ExchangeServer server;
 try {
 //这个方法会绑定端口，关于交换器与传输网络层到后面统一说
 //这里通过绑定url和请求处理器来创建交换器对象
 server = Exchangers.bind(url, requestHandler);
 } catch (RemotingException e) {
 throw new RpcException("Fail to start server(url: " + url + ") " + e.getMessage(), e);
 }

 str = url.getParameter(CLIENT_KEY);
 if (StringUtils.isNotEmpty(str)) {
 Set<String> supportedTypes = url.getOrDefaultFrameworkModel().getExtensionLoader(Transporter.class).getSupportedExtensions();
 if (!supportedTypes.contains(str)) {
 throw new RpcException("Unsupported client type: " + str);
 }
 }

 DubboProtocolServer protocolServer = new DubboProtocolServer(server);
 //关闭等待时长默认为10秒
 loadServerProperties(protocolServer);
 return protocolServer;
 }

16.9 向注册中心注册服务register

这个细节在下个博客中说涉及到Dubbo3的双注册

原文地址：16-模块发布器发布服务全过程

Blog: 15-Dubbo的三大中心之元数据中心源码解析

Mon, 15 Aug 2022 00:00:00 +0000

15-Dubbo的三大中心之元数据中心源码解析

15.1 简介

关于元数据中心的概念对于大部分用户来说是比较陌生的,配置中心的话我们还好理解,对于元数据中心是什么,我们来看下我从官网拷贝过来的一段文字:

元数据中心在2.7.x版本开始支持，随着应用级别的服务注册和服务发现在Dubbo中落地，元数据中心也变的越来越重要。在以下几种情况下会需要部署元数据中心：

对于一个原先采用老版本Dubbo搭建的应用服务，在迁移到Dubbo 3时，Dubbo 3 会需要一个元数据中心来维护RPC服务与应用的映射关系（即接口与应用的映射关系），因为如果采用了应用级别的服务发现和服务注册，在注册中心中将采用“应用 —— 实例列表”结构的数据组织形式，不再是以往的“接口 —— 实例列表”结构的数据组织形式，而以往用接口级别的服务注册和服务发现的应用服务在迁移到应用级别时，得不到接口与应用之间的对应关系，从而无法从注册中心得到实例列表信息，所以Dubbo为了兼容这种场景，在Provider端启动时，会往元数据中心存储接口与应用的映射关系。
为了让注册中心更加聚焦与地址的发现和推送能力，减轻注册中心的负担，元数据中心承载了所有的服务元数据、大量接口/方法级别配置信息等，无论是接口粒度还是应用粒度的服务发现和注册，元数据中心都起到了重要的作用。

如果有以上两种需求，都可以选择部署元数据中心，并通过Dubbo的配置来集成该元数据中心。

元数据中心并不依赖于注册中心和配置中心，用户可以自由选择是否集成和部署元数据中心，如下图所示：

该图中不配备配置中心，意味着可以不需要全局管理配置的能力。该图中不配备注册中心，意味着可能采用了Dubbo mesh的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。官网参考文章地址:

综上所述可以用几句话概括下:

元数据中心来维护RPC服务与应用的映射关系（即接口与应用的映射关系）来兼容接口与应用之间的对应关系
让注册中心更加聚焦与地址的发现和推送能力

注册中心的启动是在DefaultApplicationDeployer中的初始化方法 initialize() 中:如下所示

这里只看下 startMetadataCenter();方法即可

 @Override
 public void initialize() {
 if (initialized) {
 return;
 }
 // Ensure that the initialization is completed when concurrent calls
 synchronized (startLock) {
 if (initialized) {
 return;
 }
 // register shutdown hook
 registerShutdownHook();

 startConfigCenter();

 loadApplicationConfigs();

 initModuleDeployers();

 // @since 2.7.8
 startMetadataCenter();

 initialized = true;

 if (logger.isInfoEnabled()) {
 logger.info(getIdentifier() + " has been initialized!");
 }
 }
 }

15.2 深入探究元数据中心的启动过程

15.2.1 启动元数据中心的代码全貌

关于元数据中心我们看下 startMetadataCenter()方法来大致了解下整个流程

private void startMetadataCenter() {
 //如果未配置元数据中心的地址等配置则使用注册中心的地址等配置做为元数据中心的配置
 useRegistryAsMetadataCenterIfNecessary();
 //获取应用的配置信息
 ApplicationConfig applicationConfig = getApplication();
 //元数据配置类型 元数据类型， local 或 remote,，如果选择远程，则需要进一步指定元数据中心
 String metadataType = applicationConfig.getMetadataType();
 // FIXME, multiple metadata config support.
 //查询元数据中心的地址等配置
 Collection<MetadataReportConfig> metadataReportConfigs = configManager.getMetadataConfigs();

 if (CollectionUtils.isEmpty(metadataReportConfigs)) {
 //这个就是判断 如果选择远程，则需要进一步指定元数据中心 否则就抛出来异常
 if (REMOTE_METADATA_STORAGE_TYPE.equals(metadataType)) {
 throw new IllegalStateException("No MetadataConfig found, Metadata Center address is required when 'metadata=remote' is enabled.");
 }
 return;
 }
 //MetadataReport实例的存储库对象获取
 MetadataReportInstance metadataReportInstance = applicationModel.getBeanFactory().getBean(MetadataReportInstance.class);
 List<MetadataReportConfig> validMetadataReportConfigs = new ArrayList<>(metadataReportConfigs.size());
 for (MetadataReportConfig metadataReportConfig : metadataReportConfigs) {
 ConfigValidationUtils.validateMetadataConfig(metadataReportConfig);
 validMetadataReportConfigs.add(metadataReportConfig);
 }
 //初始化元数据
 metadataReportInstance.init(validMetadataReportConfigs);
 //MetadataReport实例的存储库对象初始化失败则抛出异常
 if (!metadataReportInstance.inited()) {
 throw new IllegalStateException(String.format("%s MetadataConfigs found, but none of them is valid.", metadataReportConfigs.size()));
 }
 }

15.2.2 元数据中心未配置则使用注册中心配置

前面在说配置中心的时候有说过配置中心如果未配置会使用注册中心的地址等信息作为默认配置,这里元数据做了类似的操作:如代码: DefaultApplicationDeployer类型的 useRegistryAsMetadataCenterIfNecessary()方法

private void useRegistryAsMetadataCenterIfNecessary() {
 //配置缓存中查询元数据配置
 Collection<MetadataReportConfig> metadataConfigs = configManager.getMetadataConfigs();
 //配置存在则直接返回
 if (CollectionUtils.isNotEmpty(metadataConfigs)) {
 return;
 }
 ////查询是否有注册中心设置了默认配置isDefault 设置为true的注册中心则为默认注册中心列表,如果没有注册中心设置为默认注册中心,则获取所有未设置默认配置的注册中心列表
 List<RegistryConfig> defaultRegistries = configManager.getDefaultRegistries();
 if (defaultRegistries.size() > 0) {
 //多注册中心遍历
 defaultRegistries
 .stream()
 //筛选符合条件的注册中心 (筛选逻辑就是查看是否有对应协议的扩展支持)
 .filter(this::isUsedRegistryAsMetadataCenter)
 //注册中心配置映射为元数据中心 映射就是获取需要的配置
 .map(this::registryAsMetadataCenter)
 //将元数据中心配置存储在配置缓存中方便后续使用
 .forEach(metadataReportConfig -> {

 if (metadataReportConfig.getId() == null) {
 Collection<MetadataReportConfig> metadataReportConfigs = configManager.getMetadataConfigs();
 if (CollectionUtils.isNotEmpty(metadataReportConfigs)) {
 for (MetadataReportConfig existedConfig : metadataReportConfigs) {
 if (existedConfig.getId() == null && existedConfig.getAddress().equals(metadataReportConfig.getAddress())) {
 return;
 }
 }
 }
 configManager.addMetadataReport(metadataReportConfig);
 } else {
 Optional<MetadataReportConfig> configOptional = configManager.getConfig(MetadataReportConfig.class, metadataReportConfig.getId());
 if (configOptional.isPresent()) {
 return;
 }
 configManager.addMetadataReport(metadataReportConfig);
 }
 logger.info("use registry as metadata-center: " + metadataReportConfig);
 });
 }
 }

这个代码有些细节就不细说了我们概括下顺序梳理下思路:

配置缓存中查询元数据配置,配置存在则直接返回
查询所有可用的默认注册中心列表
- 多注册中心遍历
- 选符合条件的注册中心 (筛选逻辑就是查看是否有对应协议的扩展支持)
- 注册中心配置RegistryConfig映射转换为元数据中心配置类型MetadataReportConfig 映射就是获取需要的配置
- 将元数据中心配置存储在配置缓存中方便后续使用

元数据的配置可以参考官网:元数据参考手册

这里主要看下可配置项有哪些对应类型为MetadataReportConfig 在官网暂时未找到合适的文档,这里整理下属性列表方便后续配置说明查看:

配置变量	类型	说明
id	String	配置id
protocol	String	元数据协议
address	String	元数据中心地址
port	Integer	元数据中心端口
username	String	元数据中心认证用户名
password	String	元数据中心认证密码
timeout	Integer	元数据中心的请求超时（毫秒）
group	String	该组将元数据保存在中。它与注册表相同
parameters	Map<String, String>	自定义参数
retryTimes	Integer	重试次数
retryPeriod	Integer	重试间隔
cycleReport	Boolean	默认情况下，是否每天重复存储完整的元数据
syncReport	Boolean	Sync or Async report.
cluster	Boolean	需要群集支持，默认为false
registry	String	注册表配置id
file	String	元数据报告文件存储位置
check	Boolean	连接到元数据中心时要应用的失败策略

15.2.3 元数据中心的初始化逻辑

15.2.3.1 元数据中心的初始化调用逻辑

主要看这一行比较重要的逻辑:

 //初始化元数据
 metadataReportInstance.init(validMetadataReportConfigs);

在了解这一行逻辑之前我们先来看下元数据相关联的类型:

MetadataReportInstance中的初始化方法init

 public void init(List<MetadataReportConfig> metadataReportConfigs) {
 //CAS判断是否有初始化过
 if (!init.compareAndSet(false, true)) {
 return;
 }
 //元数据类型配置如果未配置则默认为local
 this.metadataType = applicationModel.getApplicationConfigManager().getApplicationOrElseThrow().getMetadataType();
 if (metadataType == null) {
 this.metadataType = DEFAULT_METADATA_STORAGE_TYPE;
 }
 //获取MetadataReportFactory 工厂类型
 MetadataReportFactory metadataReportFactory = applicationModel.getExtensionLoader(MetadataReportFactory.class).getAdaptiveExtension();
 //多元数据中心初始化
 for (MetadataReportConfig metadataReportConfig : metadataReportConfigs) {
 init(metadataReportConfig, metadataReportFactory);
 }
 }

 private void init(MetadataReportConfig config, MetadataReportFactory metadataReportFactory) {
 //配置转url
 URL url = config.toUrl();
 if (METADATA_REPORT_KEY.equals(url.getProtocol())) {
 String protocol = url.getParameter(METADATA_REPORT_KEY, DEFAULT_DIRECTORY);
 url = URLBuilder.from(url)
 .setProtocol(protocol)
 .setScopeModel(config.getScopeModel())
 .removeParameter(METADATA_REPORT_KEY)
 .build();
 }
 url = url.addParameterIfAbsent(APPLICATION_KEY, applicationModel.getCurrentConfig().getName());
 String relatedRegistryId = isEmpty(config.getRegistry()) ? (isEmpty(config.getId()) ? DEFAULT_KEY : config.getId()) : config.getRegistry();
 //从元数据工厂中获取元数据
 MetadataReport metadataReport = metadataReportFactory.getMetadataReport(url);
 //缓存元数据到内存
 if (metadataReport != null) {
 metadataReports.put(relatedRegistryId, metadataReport);
 }
 }

关于元数据的初始化我们主要看两个位置:

一个是元数据工厂对象的创建与初始化MetadataReportFactory
一个是元数据对象的创建与初始化MetadataReport

15.2.3.2 元数据工厂对象MetadataReportFactory

关于元数据工厂类型MetadataReportFactory,元数据工厂用于创建与管理元数据对象, 相关类型如下:

我们这里主要以为Zookeeper扩展的元数据工厂ZookeeperMetadataReportFactory类型为例子: 实现类型逻辑不复杂,这里就直接贴代码看看:

public class ZookeeperMetadataReportFactory extends AbstractMetadataReportFactory {
 //与Zookeeper交互的传输器
 private ZookeeperTransporter zookeeperTransporter;
 //应用程序模型
 private ApplicationModel applicationModel;

 public ZookeeperMetadataReportFactory(ApplicationModel applicationModel) {
 this.applicationModel = applicationModel;
 this.zookeeperTransporter = ZookeeperTransporter.getExtension(applicationModel);
 }

 @DisableInject
 public void setZookeeperTransporter(ZookeeperTransporter zookeeperTransporter) {
 this.zookeeperTransporter = zookeeperTransporter;
 }

 @Override
 public MetadataReport createMetadataReport(URL url) {
 return new ZookeeperMetadataReport(url, zookeeperTransporter);
 }

}

元数据工厂的实现比较简单

继承抽象的元数据工厂AbstractMetadataReportFactory
实现工厂方法createMetadataReport来创建一个元数据操作类型

如果我们想要实现一个元数据工厂扩展可以参考Zookeeper的这个方式

15.2.3.3 元数据操作对象MetadataReport的创建与初始化

前面的从元数据工厂中获取元数据操作对象的逻辑处理代码如下:

//从元数据工厂中获取元数据 ,url对象可以理解为配置
 MetadataReport metadataReport = metadataReportFactory.getMetadataReport(url);

关于元数据对象,用于元数据信息的增删改查等逻辑的操作与元数据信息的缓存

我们这里还是以Zookeeper的实现ZookeeperMetadataReportFactory类型做为参考:

我们先来看这个逻辑

//从元数据工厂中获取元数据 ,url对象可以理解为配置
 MetadataReport metadataReport = metadataReportFactory.getMetadataReport(url);

ZookeeperMetadataReportFactory的父类型AbstractMetadataReportFactory中的getMetadataReport方法如下:

 @Override
 public MetadataReport getMetadataReport(URL url) {
 //url值参考例子zookeeper://127.0.0.1:2181?application=dubbo-demo-api-provider&client=&port=2181&protocol=zookeeper
 //如果存在export则移除
 url = url.setPath(MetadataReport.class.getName())
 .removeParameters(EXPORT_KEY, REFER_KEY);
 //生成元数据缓存key 元数据维度 地址+名字
 //如: zookeeper://127.0.0.1:2181/org.apache.dubbo.metadata.report.MetadataReport
 String key = url.toServiceString();
 //缓存中查询 查到则直接返回
 MetadataReport metadataReport = serviceStoreMap.get(key);
 if (metadataReport != null) {
 return metadataReport;
 }

 // Lock the metadata access process to ensure a single instance of the metadata instance
 //存在写操作 加个锁
 lock.lock();
 try {
 //双重校验锁在查一下
 metadataReport = serviceStoreMap.get(key);
 if (metadataReport != null) {
 return metadataReport;
 }
 //check参数 查元数据报错是否抛出异常
 boolean check = url.getParameter(CHECK_KEY, true) && url.getPort() != 0;
 try {
 //关键模版方法 调用扩展实现的具体业务(创建元数据操作对象)
 metadataReport = createMetadataReport(url);
 } catch (Exception e) {
 if (!check) {
 logger.warn("The metadata reporter failed to initialize", e);
 } else {
 throw e;
 }
 }
 //check逻辑检查
 if (check && metadataReport == null) {
 throw new IllegalStateException("Can not create metadata Report " + url);
 }
 //缓存对象
 if (metadataReport != null) {
 serviceStoreMap.put(key, metadataReport);
 }
 //返回
 return metadataReport;
 } finally {
 // Release the lock
 lock.unlock();
 }
 }

上面这个抽象类AbstractMetadataReportFactory中的获取元数据操作对象的模版方法getMetadataReport(URL url), 用了双重校验锁的逻辑来创建对象缓存对象,又用了模版方法设计模式,来让抽象类做通用的逻辑,让实现类型去做扩展, 虽然代码写的太长了些整体还是用了不少的设计思想.

我们直接看这个代码:

metadataReport = createMetadataReport(url);

这个创建元数据操作对象的代码实际上走的是实现类型的逻辑:

来自工厂Bean ZookeeperMetadataReportFactory的工厂方法如下所示:

@Override
 public MetadataReport createMetadataReport(URL url) {
 return new ZookeeperMetadataReport(url, zookeeperTransporter);
 }

创建了元数据操作对象,这里我们继续看下元数据操作对象ZookeeperMetadataReport创建做了哪些逻辑: 来自ZookeeperMetadataReport的构造器:

public ZookeeperMetadataReport(URL url, ZookeeperTransporter zookeeperTransporter) {
 //url即配置 配置传递给抽象类 做一些公共的逻辑
 //url参考:zookeeper://127.0.0.1:2181/org.apache.dubbo.metadata.report.MetadataReport?application=dubbo-demo-api-provider&client=&port=2181&protocol=zookeeper
 super(url);
 if (url.isAnyHost()) {
 throw new IllegalStateException("registry address == null");
 }
 String group = url.getGroup(DEFAULT_ROOT);
 if (!group.startsWith(PATH_SEPARATOR)) {
 group = PATH_SEPARATOR + group;
 }
 this.root = group;
 //连接Zookeeper
 zkClient = zookeeperTransporter.connect(url);
 }

核心的公共的操作逻辑封装在父类AbstractMetadataReport里面我们来看前面super调用的构造器逻辑: 如下所示:

 public AbstractMetadataReport(URL reportServerURL) {
 //设置url 如:zookeeper://127.0.0.1:2181/org.apache.dubbo.metadata.report.MetadataReport?application=dubbo-demo-api-provider&client=&port=2181&protocol=zookeeper
 setUrl(reportServerURL);
 // Start file save timer
 //缓存的文件名字
 //格式为: 用户目录+/.dubbo/dubbo-metadata- + 应用程序名字application + url地址(IP+端口) + 后缀.cache 如下所示
 ///Users/song/.dubbo/dubbo-metadata-dubbo-demo-api-provider-127.0.0.1-2181.cache
 String defaultFilename = System.getProperty(USER_HOME) + DUBBO_METADATA +
 reportServerURL.getApplication() + "-" +
 replace(reportServerURL.getAddress(), ":", "-") + CACHE;
 //如果用户配置了缓存文件名字则以用户配置为准file
 String filename = reportServerURL.getParameter(FILE_KEY, defaultFilename);
 File file = null;
 //文件名字不为空
 if (ConfigUtils.isNotEmpty(filename)) {
 file = new File(filename);
 //文件和父目录不存在则创建文件目录
 if (!file.exists() && file.getParentFile() != null && !file.getParentFile().exists()) {
 if (!file.getParentFile().mkdirs()) {
 throw new IllegalArgumentException("Invalid service store file " + file + ", cause: Failed to create directory " + file.getParentFile() + "!");
 }
 }
 // if this file exists, firstly delete it.
 //还未初始化则已存在的历史文件删除掉
 if (!initialized.getAndSet(true) && file.exists()) {
 file.delete();
 }
 }
 //赋值给成员变量后续继续可以用
 this.file = file;
 //文件存在则直接加载文件中的内容
 loadProperties();
 //sync-report配置的值为同步配置还异步配置,true是同步配置,默认为false为异步配置
 syncReport = reportServerURL.getParameter(SYNC_REPORT_KEY, false);
 //重试属性与逻辑也封装了一个类型 创建对象
 //retry-times重试次数配置 默认为100次
 //retry-period 重试间隔配置 默认为3000
 metadataReportRetry = new MetadataReportRetry(reportServerURL.getParameter(RETRY_TIMES_KEY, DEFAULT_METADATA_REPORT_RETRY_TIMES),
 reportServerURL.getParameter(RETRY_PERIOD_KEY, DEFAULT_METADATA_REPORT_RETRY_PERIOD));

 // cycle report the data switch
 //是否定期从元数据中心同步配置
 //cycle-report配置默认为true
 if (reportServerURL.getParameter(CYCLE_REPORT_KEY, DEFAULT_METADATA_REPORT_CYCLE_REPORT)) {
 //开启重试定时器 24个小时间隔从元数据中心同步一次
 reportTimerScheduler = Executors.newSingleThreadScheduledExecutor(new NamedThreadFactory("DubboMetadataReportTimer", true));
 reportTimerScheduler.scheduleAtFixedRate(this::publishAll, calculateStartTime(), ONE_DAY_IN_MILLISECONDS, TimeUnit.MILLISECONDS);
 }

 this.reportMetadata = reportServerURL.getParameter(REPORT_METADATA_KEY, false);
 this.reportDefinition = reportServerURL.getParameter(REPORT_DEFINITION_KEY, true);
 }

15.2.3.4 内存中元数据自动同步到Zookeeper和本地文件

这里来总结下元数据操作的初始化逻辑:

首次初始化清理历史元数据文件如: Users/song/.dubbo/dubbo-metadata-dubbo-demo-api-provider-127.0.0.1-2181.cache
如果非首次进来则直接加载缓存在本地的缓存文件,赋值给properties成员变量
初始化同步配置是否异步(默认为false), sync-report配置的值为同步配置还异步配置,true是同步配置,默认为false为异步配置
初始化重试属性
是否定期从元数据中心同步配置初始化默认为true 24小时自动同步一次

关于元数据同步可以看AbstractMetadataReport类型的publishAll方法:

 reportTimerScheduler = Executors.newSingleThreadScheduledExecutor(new NamedThreadFactory("DubboMetadataReportTimer", true));
 reportTimerScheduler.scheduleAtFixedRate(this::publishAll, calculateStartTime(), ONE_DAY_IN_MILLISECONDS, TimeUnit.MILLISECONDS);

这里有个方法叫做calculateStartTime 这个代码是随机时间的between 2:00 am to 6:00 am, the time is random. 2点到6点之间启动, 低峰期启动自动同步返回值:

AbstractMetadataReport类型的

 void publishAll() {
 logger.info("start to publish all metadata.");
 this.doHandleMetadataCollection(allMetadataReports);
 }

AbstractMetadataReport类型的doHandleMetadataCollection

private boolean doHandleMetadataCollection(Map<MetadataIdentifier, Object> metadataMap) {
 if (metadataMap.isEmpty()) {
 return true;
 }
 Iterator<Map.Entry<MetadataIdentifier, Object>> iterable = metadataMap.entrySet().iterator();
 while (iterable.hasNext()) {
 Map.Entry<MetadataIdentifier, Object> item = iterable.next();
 if (PROVIDER_SIDE.equals(item.getKey().getSide())) {
 //提供端的元数据则存储提供端元数据
 this.storeProviderMetadata(item.getKey(), (FullServiceDefinition) item.getValue());
 } else if (CONSUMER_SIDE.equals(item.getKey().getSide())) {
 //消费端的元数据则存储提供端元数据
 this.storeConsumerMetadata(item.getKey(), (Map) item.getValue());
 }

 }
 return false;
 }

提供端元数据的存储: AbstractMetadataReport类型的storeProviderMetadata

 @Override
 public void storeProviderMetadata(MetadataIdentifier providerMetadataIdentifier, ServiceDefinition serviceDefinition) {
 if (syncReport) {
 storeProviderMetadataTask(providerMetadataIdentifier, serviceDefinition);
 } else {
 reportCacheExecutor.execute(() -> storeProviderMetadataTask(providerMetadataIdentifier, serviceDefinition));
 }
 }

AbstractMetadataReport类型的storeProviderMetadataTask 具体同步代码:storeProviderMetadataTask

private void storeProviderMetadataTask(MetadataIdentifier providerMetadataIdentifier, ServiceDefinition serviceDefinition) {
 try {
 if (logger.isInfoEnabled()) {
 logger.info("store provider metadata. Identifier : " + providerMetadataIdentifier + "; definition: " + serviceDefinition);
 }
 allMetadataReports.put(providerMetadataIdentifier, serviceDefinition);
 failedReports.remove(providerMetadataIdentifier);
 Gson gson = new Gson();
 String data = gson.toJson(serviceDefinition);
 //内存中的元数据同步到元数据中心
 doStoreProviderMetadata(providerMetadataIdentifier, data);
 //内存中的元数据同步到本地文件
 saveProperties(providerMetadataIdentifier, data, true, !syncReport);
 } catch (Exception e) {
 // retry again. If failed again, throw exception.
 failedReports.put(providerMetadataIdentifier, serviceDefinition);
 metadataReportRetry.startRetryTask();
 logger.error("Failed to put provider metadata " + providerMetadataIdentifier + " in " + serviceDefinition + ", cause: " + e.getMessage(), e);
 }
 }

上面代码我们主要看本地内存中的元数据同步到元数据中心和存本地的两个点:

//内存中的元数据同步到元数据中心
doStoreProviderMetadata(providerMetadataIdentifier, data);
//内存中的元数据同步到本地文件
saveProperties(providerMetadataIdentifier, data, true,

//内存中的元数据同步到元数据中心

这个方法会调用当前子类重写的具体存储逻辑:这里我们以 ZookeeperMetadataReport的doStoreProviderMetadata举例:

 private void storeMetadata(MetadataIdentifier metadataIdentifier, String v) {
 //使用zkClient创建一个节点数据为参数V v是前面说的服务定义数据
 zkClient.create(getNodePath(metadataIdentifier), v, false);
 }

这里参数我们举个例子: 提供者的元数据内容如下: 节点路径为:

/dubbo/metadata/link.elastic.dubbo.entity.DemoService/provider/dubbo-demo-api-provider

格式:

/dubbo/metadata前缀
服务提供者接口
提供者类型provider
应用名

具体的元数据内容如下: 比较详细的记录了应用信息,服务接口信息和服务接口对应的方法信息

{
 "parameters": {
 "side": "provider",
 "interface": "link.elastic.dubbo.entity.DemoService",
 "pid": "38680",
 "application": "dubbo-demo-api-provider",
 "dubbo": "2.0.2",
 "release": "3.0.8",
 "anyhost": "true",
 "bind.ip": "192.168.1.9",
 "methods": "sayHello,sayHelloAsync",
 "background": "false",
 "deprecated": "false",
 "dynamic": "true",
 "service-name-mapping": "true",
 "generic": "false",
 "bind.port": "20880",
 "timestamp": "1653097653865"
 },
 "canonicalName": "link.elastic.dubbo.entity.DemoService",
 "codeSource": "file:/Users/song/Desktop/Computer/A/code/gitee/weaving-a-net/weaving-test/dubbo-test/target/classes/",
 "methods": [
 {
 "name": "sayHello",
 "parameterTypes": [
 "java.lang.String"
 ],
 "returnType": "java.lang.String",
 "annotations": [

 ]
 },
 {
 "name": "sayHelloAsync",
 "parameterTypes": [
 "java.lang.String"
 ],
 "returnType": "java.util.concurrent.CompletableFuture",
 "annotations": [

 ]
 }
 ],
 "types": [
 {
 "type": "java.util.concurrent.CompletableFuture",
 "properties": {
 "result": "java.lang.Object",
 "stack": "java.util.concurrent.CompletableFuture.Completion"
 }
 },
 {
 "type": "java.lang.Object"
 },
 {
 "type": "java.lang.String"
 },
 {
 "type": "java.util.concurrent.CompletableFuture.Completion",
 "properties": {
 "next": "java.util.concurrent.CompletableFuture.Completion",
 "status": "int"
 }
 },
 {
 "type": "int"
 }
 ],
 "annotations": [

 ]
}

本地缓存文件的写入可以看下如下代码 AbstractMetadataReport类型的saveProperties方法

 private void saveProperties(MetadataIdentifier metadataIdentifier, String value, boolean add, boolean sync) {
 if (file == null) {
 return;
 }

 try {
 if (add) {
 properties.setProperty(metadataIdentifier.getUniqueKey(KeyTypeEnum.UNIQUE_KEY), value);
 } else {
 properties.remove(metadataIdentifier.getUniqueKey(KeyTypeEnum.UNIQUE_KEY));
 }
 long version = lastCacheChanged.incrementAndGet();
 if (sync) {
 //获取最新修改版本持久化到磁盘
 new SaveProperties(version).run();
 } else {
 reportCacheExecutor.execute(new SaveProperties(version));
 }

 } catch (Throwable t) {
 logger.warn(t.getMessage(), t);
 }
 }

主要看如下代码:

 new SaveProperties(version).run();

SaveProperties类型代码如下:

 private class SaveProperties implements Runnable {
 private long version;

 private SaveProperties(long version) {
 this.version = version;
 }

 @Override
 public void run() {
 doSaveProperties(version);
 }
 }

继续看doSaveProperties方法:

private void doSaveProperties(long version) {
 //不是最新的就不要持久化了
 if (version < lastCacheChanged.get()) {
 return;
 }
 if (file == null) {
 return;
 }
 // Save
 try {
 //创建本地文件锁:
 //路径为:
 ///Users/song/.dubbo/dubbo-metadata-dubbo-demo-api-provider-127.0.0.1-2181.cache.lock
 File lockfile = new File(file.getAbsolutePath() + ".lock");
 //锁文件不存在则创建锁文件
 if (!lockfile.exists()) {
 lockfile.createNewFile();
 }
 //随机访问文件工具类对象创建 读写权限
 try (RandomAccessFile raf = new RandomAccessFile(lockfile, "rw");
 //文件文件Channel
 //返回与此文件关联的唯一FileChannel对象。
 FileChannel channel = raf.getChannel()) {
 //FileChannel中的lock()与tryLock()方法都是尝试去获取在某一文件上的独有锁（以下简称独有锁），可以实现进程间操作的互斥。区别在于lock()会阻塞（blocking）方法的执行，tryLock()则不会。
 FileLock lock = channel.tryLock();
 //如果多个线程同时进来未获取锁的则抛出异常
 if (lock == null) {
 throw new IOException("Can not lock the metadataReport cache file " + file.getAbsolutePath() + ", ignore and retry later, maybe multi java process use the file, please config: dubbo.metadata.file=xxx.properties");
 }
 // Save
 try {
 //文件不存在则创建本地元数据缓存文件
 ///Users/song/.dubbo/dubbo-metadata-dubbo-demo-api-provider-127.0.0.1-2181.cache
 if (!file.exists()) {
 file.createNewFile();
 }

 Properties tmpProperties;
 if (!syncReport) {
 // When syncReport = false, properties.setProperty and properties.store are called from the same
 // thread(reportCacheExecutor), so deep copy is not required
 tmpProperties = properties;
 } else {
 // Using store method and setProperty method of the this.properties will cause lock contention
 // under multi-threading, so deep copy a new container
 //异步存储会导致锁争用 使用此的store方法和setProperty方法。属性将导致多线程下的锁争用，因此深度复制新容器
 tmpProperties = new Properties();
 Set<Map.Entry<Object, Object>> entries = properties.entrySet();
 for (Map.Entry<Object, Object> entry : entries) {
 tmpProperties.setProperty((String) entry.getKey(), (String) entry.getValue());
 }
 }

 try (FileOutputStream outputFile = new FileOutputStream(file)) {
 //Properties类型自带的方法:
 //将此属性表中的属性列表（键和元素对）以适合使用load（Reader）方法的格式写入输出字符流。
 tmpProperties.store(outputFile, "Dubbo metadataReport Cache");
 }
 } finally {
 lock.release();
 }
 }
 } catch (Throwable e) {
 if (version < lastCacheChanged.get()) {
 return;
 } else {
 reportCacheExecutor.execute(new SaveProperties(lastCacheChanged.incrementAndGet()));
 }
 //这个代码太诡异了如果是lock失败也会打印异常给人非常疑惑的感觉 后续会修复
 logger.warn("Failed to save service store file, cause: " + e.getMessage(), e);
 }
 }

写入文件的内容大致如下

link.elastic.dubbo.entity.DemoService:::provider:dubbo-demo-api-provider -> {
 "parameters": {
 "side": "provider",
 "interface": "link.elastic.dubbo.entity.DemoService",
 "pid": "41457",
 "application": "dubbo-demo-api-provider",
 "dubbo": "2.0.2",
 "release": "3.0.8",
 "anyhost": "true",
 "bind.ip": "192.168.1.9",
 "methods": "sayHello,sayHelloAsync",
 "background": "false",
 "deprecated": "false",
 "dynamic": "true",
 "service-name-mapping": "true",
 "generic": "false",
 "bind.port": "20880",
 "timestamp": "1653100253548"
 },
 "canonicalName": "link.elastic.dubbo.entity.DemoService",
 "codeSource": "file:/Users/song/Desktop/Computer/A/code/gitee/weaving-a-net/weaving-test/dubbo-test/target/classes/",
 "methods": [
 {
 "name": "sayHelloAsync",
 "parameterTypes": [
 "java.lang.String"
 ],
 "returnType": "java.util.concurrent.CompletableFuture",
 "annotations": [

 ]
 },
 {
 "name": "sayHello",
 "parameterTypes": [
 "java.lang.String"
 ],
 "returnType": "java.lang.String",
 "annotations": [

 ]
 }
 ],
 "types": [
 {
 "type": "java.util.concurrent.CompletableFuture",
 "properties": {
 "result": "java.lang.Object",
 "stack": "java.util.concurrent.CompletableFuture.Completion"
 }
 },
 {
 "type": "java.lang.Object"
 },
 {
 "type": "java.lang.String"
 },
 {
 "type": "java.util.concurrent.CompletableFuture.Completion",
 "properties": {
 "next": "java.util.concurrent.CompletableFuture.Completion",
 "status": "int"
 }
 },
 {
 "type": "int"
 }
 ],
 "annotations": [

 ]
}

原文地址：15-Dubbo的三大中心之元数据中心源码解析

Blog: 14-Dubbo配置加载全解析

Sun, 14 Aug 2022 00:00:00 +0000

14-Dubbo配置加载全解析

14.1 回到启动器的初始化过程

在应用程序启动的时候会调用发布器的启动方法 ,然后调用初始化方法,在发布器DefaultApplicationDeployer中的初始化方法initialize() 如下:

@Override
 public void initialize() {
 if (initialized) {
 return;
 }
 // Ensure that the initialization is completed when concurrent calls
 synchronized (startLock) {
 if (initialized) {
 return;
 }
 // register shutdown hook
 registerShutdownHook();

 startConfigCenter();

 loadApplicationConfigs();

 initModuleDeployers();

 // @since 2.7.8
 startMetadataCenter();

 initialized = true;

 if (logger.isInfoEnabled()) {
 logger.info(getIdentifier() + " has been initialized!");
 }
 }
 }

初始化过程中会先启动配置中心配置信息处理,然后调用加载初始化应用程序配置方法loadApplicationConfigs();进行配置加载关于配置的官方文档链接为配置概述

Dubbo框架的配置项比较繁多，为了更好地管理各种配置，将其按照用途划分为不同的组件，最终所有配置项都会汇聚到URL中，传递给后续处理模块。

常用配置组件如下：

application: Dubbo应用配置
registry: 注册中心
protocol: 服务提供者RPC协议
config-center: 配置中心
metadata-report: 元数据中心
service: 服务提供者配置
reference: 远程服务引用配置
provider: service的默认配置或分组配置
consumer: reference的默认配置或分组配置
module: 模块配置
monitor: 监控配置
metrics: 指标配置
ssl: SSL/TLS配置

配置还有几个比较重要的点:

配置来源 从Dubbo支持的配置来源说起，默认有6种配置来源：

JVM System Properties，JVM -D 参数
System environment，JVM进程的环境变量
Externalized Configuration，外部化配置，从配置中心读取
Application Configuration，应用的属性配置，从Spring应用的Environment中提取"dubbo"打头的属性集
API / XML /注解等编程接口采集的配置可以被理解成配置来源的一种，是直接面向用户编程的配置采集方式
从classpath读取配置文件 dubbo.properties

覆盖关系 下图展示了配置覆盖关系的优先级，从上到下优先级依次降低：

配置方式

Java API配置
XML配置
Annotation配置
属性配置

配置虽然非常多,但是我们掌握一下配置加载的原理,再了解下官网的文档说明路径应该基础的配置搞定是没问题的,更深入的配置很多参数还是需要了解下源码的.

14.2 配置信息的初始化回顾

前面我们在讲ModuleModel对象的创建的时候ModuleModel模型中包含了一个成员变量为ModuleEnvironment 代表当前的模块环境和ModuleConfigManager配置管理器而ModuleModel模型对象的父模型对象ApplicationModel中包含了一个成员变量Environment环境和ConfigManager配置管理器.

在回顾调用过程之前我们先看下模型,配置管理器和环境与配置之间的关系如下图:

在ModuleConfigManager对象初始化方法initialize()中创建了模块配置管理器:ModuleConfigManager 如下代码所示:

 @Override
 protected void initialize() {
 super.initialize();
 this.serviceRepository = new ModuleServiceRepository(this);
 this.moduleConfigManager = new ModuleConfigManager(this);
 this.moduleConfigManager.initialize();

ModuleEnvironment环境信息对象也会在配置管理器创建的时候被调用到: 如下代码所示:

 @Override
 public ModuleEnvironment getModelEnvironment() {
 if (moduleEnvironment == null) {
 moduleEnvironment = (ModuleEnvironment) this.getExtensionLoader(ModuleExt.class)
 .getExtension(ModuleEnvironment.NAME);
 }
 return moduleEnvironment;
 }

在扩展对象ExtensionLoader进行对象ModuleEnvironment创建之后会对对象进行初始化调用 initExtension(instance)方法初始化的时候调用如下代码: ExtensionLoader中的初始化方法如下:

 private void initExtension(T instance) {
 if (instance instanceof Lifecycle) {
 Lifecycle lifecycle = (Lifecycle) instance;
 lifecycle.initialize();
 }
 }

14.3 属性加载

14.3.1 Environment中属性的初始化方法

这个初始化方法对应ModuleEnvironment的父类型Environment中的初始化方法如下:initialize()

 @Override
 public void initialize() throws IllegalStateException {
 if (initialized.compareAndSet(false, true)) {
 //加载在JVM或者环境变量指定的dubbo.properties配置文件 配置的key为dubbo.properties.file ,如果未指定则查找类路径下的dubbo.properties
 this.propertiesConfiguration = new PropertiesConfiguration(scopeModel);
 //系统JVM参数的配置无需我们来加载到内存,系统已经加载好了放到了System中,我们只需System.getProperty(key)来调用
 this.systemConfiguration = new SystemConfiguration();
 //系统环境变量的配置,无需我们来加载到内存,系统已经加载好了放到了System中,我们只需System.getenv(key)来获取就可以
 this.environmentConfiguration = new EnvironmentConfiguration();
 //从远程配置中心的全局配置获取对应配置
 this.externalConfiguration = new InmemoryConfiguration("ExternalConfig");
 //从远程配置中心的应用配置获取对应配置
 this.appExternalConfiguration = new InmemoryConfiguration("AppExternalConfig");
 //应用内的配置比如: Spring Environment/PropertySources/application.properties
 this.appConfiguration = new InmemoryConfiguration("AppConfig");
 //加载迁移配置,用户在JVM参数或者环境变量中指定的dubbo.migration.file,如果用户未指定测尝试加载类路径下的dubbo-migration.yaml
 loadMigrationRule();
 }
 }

14.4.2 属性变量说明

前面我们已经基本上介绍了各个属性的含义下面用一个表格列举一下方便查看:

属性变量名	属性类型	说明
propertiesConfiguration	PropertiesConfiguration	dubbo.properties文件中的属性
systemConfiguration	SystemConfiguration	JVM参数启动进程时指定的 (-D)配置
environmentConfiguration	EnvironmentConfiguration	环境变量中的配置
externalConfiguration	InmemoryConfiguration	外部配置全局配置例如配置中心中 config-center global/default config
appExternalConfiguration	InmemoryConfiguration	外部的应用配置例如配置中心中执行的当前应用的配置 config-center app config
appConfiguration	InmemoryConfiguration	来自应用中的配置例如:Spring Environment/PropertySources/application.properties
globalConfiguration	CompositeConfiguration	前面6个配置属性放到一起就是这个
globalConfigurationMaps	List<Map<String, String»	最前面的6个属性转换为map放到一起就是这个可以理解为将全局配置globalConfiguration转换成了列表这个列表顺序在这里是:SystemConfiguration -> EnvironmentConfiguration -> AppExternalConfiguration -> ExternalConfiguration -> AppConfiguration -> AbstractConfig -> PropertiesConfiguration
defaultDynamicGlobalConfiguration	CompositeConfiguration	这个也是一个组合配置将defaultDynamicConfiguration动态配置(来自配置中心的配置)和全局配置添加到了自己的配置列表中列表顺序为defaultDynamicConfiguration -> globalConfiguration
localMigrationRule	String	,用户在JVM参数或者环境变量中指定的dubbo.migration.file,如果用户未指定测尝试加载类路径下的dubbo-migration.yaml

关于每个配置信息这里还是来了解下细节,方便大家了解原理.

14.3.3 dubbo.properties配置文件加载解析原理

如前面所示:

//加载在JVM或者环境变量指定的dubbo.properties配置文件 配置的key为dubbo.properties.file ,如果未指定则查找类路径下的dubbo.properties
 this.propertiesConfiguration = new PropertiesConfiguration(scopeModel);

下面就直接提构造器的PropertiesConfiguration代码了:

public PropertiesConfiguration(ScopeModel scopeModel) {
 this.scopeModel = scopeModel;
 refresh();
 }

 public void refresh() {
 //配置获取的过程是借助工具类ConfigUtils来获取的
 properties = ConfigUtils.getProperties(scopeModel.getClassLoaders());
 }

继续看ConfigUtils的getProperties方法:

public static Properties getProperties(Set<ClassLoader> classLoaders) {
 //这个配置的KEY是dubbo.properties.file System.getProperty是从JVM参数中获取配置的 一般情况下我们在启动Java进程的时候会指定Dubbo配置文件 如配置:
 //-Ddubbo.properties.file=/dubbo.properties
 String path = System.getProperty(CommonConstants.DUBBO_PROPERTIES_KEY);

 if (StringUtils.isEmpty(path)) {
 //优先级最高的JVM参数拿不到数据则从 环境变量中获取,这个配置key也是dubbo.properties.file System.getenv是从环境变量中获取数据
 //例如我们在环境变量中配置 dubbo.properties.file=/dubbo.properties
 path = System.getenv(CommonConstants.DUBBO_PROPERTIES_KEY);
 if (StringUtils.isEmpty(path)) {
 //如果在JVM参数和环境变量都拿不到这个配置文件的路径我们就用默认的吧
 //默认的路径是类路径下的资源文件 这个路径是: dubbo.properties
 path = CommonConstants.DEFAULT_DUBBO_PROPERTIES;
 }
 }
 return ConfigUtils.loadProperties(classLoaders, path, false, true);
 }

路径获取之后加载详细的配置内容:

ConfigUtils的loadProperties代码如下:

ConfigUtils.loadProperties(classLoaders, path, false, true);

代码如下:

public static Properties loadProperties(Set<ClassLoader> classLoaders, String fileName, boolean allowMultiFile, boolean optional) {
 Properties properties = new Properties();
 // add scene judgement in windows environment Fix 2557
 //检查文件是否存在 直接加载配置文件如果加载到了配置文件则直接返回
 if (checkFileNameExist(fileName)) {
 try {
 FileInputStream input = new FileInputStream(fileName);
 try {
 properties.load(input);
 } finally {
 input.close();
 }
 } catch (Throwable e) {
 logger.warn("Failed to load " + fileName + " file from " + fileName + "(ignore this file): " + e.getMessage(), e);
 }
 return properties;
 }

 //为什么会有下面的逻辑呢,如果仅仅使用上面的加载方式只能加载到本系统下的配置文件,无法加载封装在jar中的根路径的配置
 Set<java.net.URL> set = null;
 try {
 List<ClassLoader> classLoadersToLoad = new LinkedList<>();
 classLoadersToLoad.add(ClassUtils.getClassLoader());
 classLoadersToLoad.addAll(classLoaders);
 //这个方法loadResources在扩展加载的时候说过
 set = ClassLoaderResourceLoader.loadResources(fileName, classLoadersToLoad).values().stream().reduce(new LinkedHashSet<>(), (a, i) -> {
 a.addAll(i);
 return a;
 });
 } catch (Throwable t) {
 logger.warn("Fail to load " + fileName + " file: " + t.getMessage(), t);
 }

 if (CollectionUtils.isEmpty(set)) {
 if (!optional) {
 logger.warn("No " + fileName + " found on the class path.");
 }
 return properties;
 }

 if (!allowMultiFile) {
 if (set.size() > 1) {
 String errMsg = String.format("only 1 %s file is expected, but %d dubbo.properties files found on class path: %s",
 fileName, set.size(), set);
 logger.warn(errMsg);
 }

 // fall back to use method getResourceAsStream
 try {
 properties.load(ClassUtils.getClassLoader().getResourceAsStream(fileName));
 } catch (Throwable e) {
 logger.warn("Failed to load " + fileName + " file from " + fileName + "(ignore this file): " + e.getMessage(), e);
 }
 return properties;
 }

 logger.info("load " + fileName + " properties file from " + set);

 for (java.net.URL url : set) {
 try {
 Properties p = new Properties();
 InputStream input = url.openStream();
 if (input != null) {
 try {
 p.load(input);
 properties.putAll(p);
 } finally {
 try {
 input.close();
 } catch (Throwable t) {
 }
 }
 }
 } catch (Throwable e) {
 logger.warn("Fail to load " + fileName + " file from " + url + "(ignore this file): " + e.getMessage(), e);
 }
 }

 return properties;
 }

完整的配置加载流程这里用简单的话描述下:

项目内配置查询
- 路径查询
  - 从JVM参数中获取配置的 dubbo.properties.file配置文件路径
  - 如果前面未获取到路径则从环境变量参数中获取配置的dubbo.properties.file配置文件路径
  - 如果前面未获取到路径则使用默认路径dubbo.propertie
- 配置加载
  - 将路径转为FileInputStream 然后使用Properties加载
依赖中的配置扫描查询
- 使用类加载器扫描所有资源URL
- url转InputStream 如 url.openStream() 然后使用Properties加载

14.3.4 加载JVM参数的配置

这里我们继续看SystemConfiguration配置的加载这个直接看下代码就可以了:

这个类型仅仅是使用System.getProperty来获取JVM配置即可

 public class SystemConfiguration implements Configuration {

 @Override
 public Object getInternalProperty(String key) {
 return System.getProperty(key);
 }

 public Map<String, String> getProperties() {
 return (Map) System.getProperties();
 }
}

14.3.5 加载环境变量参数的配置

这里我们来看EnvironmentConfiguration,这里我们直接来看代码:

public class EnvironmentConfiguration implements Configuration {

 @Override
 public Object getInternalProperty(String key) {
 String value = System.getenv(key);
 if (StringUtils.isEmpty(value)) {
 value = System.getenv(StringUtils.toOSStyleKey(key));
 }
 return value;
 }

 public Map<String, String> getProperties() {
 return System.getenv();
 }
}

14.3.6 内存配置的封装:InmemoryConfiguration

这里我们看下InmemoryConfiguration的设计,这个直接看代码吧内部使用了一个LinkedHashMap来存储配置

public class InmemoryConfiguration implements Configuration {

 private String name;

 // stores the configuration key-value pairs
 private Map<String, String> store = new LinkedHashMap<>();

 public InmemoryConfiguration() {
 }

 public InmemoryConfiguration(String name) {
 this.name = name;
 }

 public InmemoryConfiguration(Map<String, String> properties) {
 this.setProperties(properties);
 }

 @Override
 public Object getInternalProperty(String key) {
 return store.get(key);
 }

 /**
 * Add one property into the store, the previous value will be replaced if the key exists
 */
 public void addProperty(String key, String value) {
 store.put(key, value);
 }

 /**
 * Add a set of properties into the store
 */
 public void addProperties(Map<String, String> properties) {
 if (properties != null) {
 this.store.putAll(properties);
 }
 }

 /**
 * set store
 */
 public void setProperties(Map<String, String> properties) {
 if (properties != null) {
 this.store = properties;
 }
 }

 public Map<String, String> getProperties() {
 return store;
 }

}

14.3.7 Dubbo迁移新版本的配置文件加载dubbo-migration.yaml

关于配置迁移文件的用法可以看下这个Dubbo官方的地址迁移规则说明

这个配置文件的文件名字为:dubbo-migration.yaml

这个和14.3.4加载JVM参数配置的过程是相似的细节可以看14.3.4节

 private void loadMigrationRule() {
 //JVM参数的dubbo.migration.file配置
 String path = System.getProperty(CommonConstants.DUBBO_MIGRATION_KEY);
 if (StringUtils.isEmpty(path)) {
 //环境变量的dubbo.migration.file配置
 path = System.getenv(CommonConstants.DUBBO_MIGRATION_KEY);
 if (StringUtils.isEmpty(path)) {
 //默认的迁移配置文件 dubbo-migration.yaml
 path = CommonConstants.DEFAULT_DUBBO_MIGRATION_FILE;
 }
 }
 this.localMigrationRule = ConfigUtils.loadMigrationRule(scopeModel.getClassLoaders(), path);
 }

14.4 初始化加载应用配置

加载配置涉及到了配置优先级的处理,

下面来看加载配置代码 loadApplicationConfigs()方法

private void loadApplicationConfigs() {
 //发布器还是不处理配置加载的逻辑还是交给配置管理器
 configManager.loadConfigs();
 }

配置管理器加载配置:

 @Override
 public void loadConfigs() {
 // application config has load before starting config center
 // load dubbo.applications.xxx
 //加载应用配置
 loadConfigsOfTypeFromProps(ApplicationConfig.class);

 // load dubbo.monitors.xxx
 //加载监控配置
 loadConfigsOfTypeFromProps(MonitorConfig.class);

 // load dubbo.metrics.xxx
 //加载指标监控配置
 loadConfigsOfTypeFromProps(MetricsConfig.class);

 // load multiple config types:
 // load dubbo.protocols.xxx
 //加载协议配置
 loadConfigsOfTypeFromProps(ProtocolConfig.class);

 // load dubbo.registries.xxx
 loadConfigsOfTypeFromProps(RegistryConfig.class);

 // load dubbo.metadata-report.xxx
 //加载元数据配置
 loadConfigsOfTypeFromProps(MetadataReportConfig.class);

 // config centers has bean loaded before starting config center
 //loadConfigsOfTypeFromProps(ConfigCenterConfig.class);

 //刷新配置
 refreshAll();

 //检查配置
 checkConfigs();

 // set model name
 if (StringUtils.isBlank(applicationModel.getModelName())) {
 applicationModel.setModelName(applicationModel.getApplicationName());
 }
 }

原文地址：Dubbo配置加载全解析

Blog: 13-Dubbo的三大中心之配置中心

Sat, 13 Aug 2022 00:00:00 +0000

13-Dubbo的三大中心之配置中心

13.1 配置中心简介

百度了一段不错的文字来介绍配置中心，我看了下肯定比我写的好多了，那我就直接拷贝过来一起看：

对于传统的单体应用而言，常使用配置文件来管理所有配置，比如SpringBoot的application.yml文件，但是在微服务架构中全部手动修改的话很麻烦而且不易维护。微服务的配置管理一般有以下需求：

集中配置管理，一个微服务架构中可能有成百上千个微服务，所以集中配置管理是很重要的。
不同环境不同配置，比如数据源配置在不同环境（开发，生产，测试）中是不同的。
运行期间可动态调整。例如，可根据各个微服务的负载情况，动态调整数据源连接池大小等。
配置修改后可自动更新。如配置内容发生变化，微服务可以自动更新配置。

综上所述对于微服务架构而言，一套统一的，通用的管理配置机制是不可缺少的主要组成部分。常见的做法就是通过配置服务器进行管理。

不过对于来看这个文章的小伙伴应该大部分对配置中心都会比较了解，分布式配置中心实现简单一点就是借助Zookeeper来协助存储，变更推送，不过为了实现各种不同的业务需求，市面上已经有很多很可靠的配置中心可用了，比如我从其他地方拷贝过来的图（虽然不是最新的但是可以供大家参考下）：

每个配置中心都有自己的实现，如果对配置中心感兴趣的小伙伴可以自行去对应开源项目官网查看，我们这里来看Dubbo对配置中心的支持

多配置中心： Dubbo支持多配置中心，来 保证其中一个配置中心集群出现不可用时能够切换到另一个配置中心集群 ，保证能够正常从配置中心获取全局的配置、路由规则等信息。这也能够满足配置中心在部署上适应各类高可用的部署架构模式。-来自官网

做中间件可能考虑更多的的不仅仅是性能，还要过多的考虑高可用，高可用怎么做呢，其实就是失效转移，主备切换，降级，降级再降级这些理论的运用，多多考虑某一个服务挂了怎么办，Dubbo的多配置中心支持增加了复杂性，不过降低了服务不可用的风险，有一定的人手的公司还是值得做的。

关于Dubbo的配置中心这里我来贴个官网的图: 关于官网的介绍可以自行去官网看详细内容: 部署架构(注册中心、配置中心、元数据中心

13.2 启动配置中心

在上一个博客中说到了《12-全局视野来看Dubbo3.0.8的服务启动生命周期》Dubbo应用的启动过程DefaultApplicationDeployer的initialize()方法的全生命周期，在初始化方法中通过调用startConfigCenter();方法来启动配置中心的加载。后面就来详细看下：

DefaultApplicationDeployer类型的startConfigCenter()代码如下：

private void startConfigCenter() {

 // load application config
 //加载应用程序配置 （配置可能有多个地方可以配置需要遵循Dubbo约定的优先级进行设置，也可能是多应用，多注册中心这样的配置）
 configManager.loadConfigsOfTypeFromProps(ApplicationConfig.class);

 // try set model name
 if (StringUtils.isBlank(applicationModel.getModelName())) {
 //设置一下模块名字和模块描述（我们再Debug里面经常会看到这个描述信息 toString直接返回了Dubbo为我们改造的对象信息）
 applicationModel.setModelName(applicationModel.tryGetApplicationName());
 }

 // load config centers
 //加载配置中心配置
 //配置可能有多个地方可以配置需要遵循Dubbo约定的优先级进行设置，也可能是多应用，多注册中心这样的配置）
 configManager.loadConfigsOfTypeFromProps(ConfigCenterConfig.class);
 //出于兼容性目的，如果没有明确指定配置中心，并且registryConfig的UseAConfigCenter为null或true，请使用registry作为默认配置中心
 useRegistryAsConfigCenterIfNecessary();

 // check Config Center
 //配置管理器中获取配置中心
 Collection<ConfigCenterConfig> configCenters = configManager.getConfigCenters();
 //配置中心配置不为空则刷新配置中心配置将其放入配置管理器中
 //下面开始刷新配置中心配置,如果配置中心配置为空则执行空刷新
 if (CollectionUtils.isEmpty(configCenters)) {
 //配置中心不存在的配置刷新
 ConfigCenterConfig configCenterConfig = new ConfigCenterConfig();
 configCenterConfig.setScopeModel(applicationModel);
 configCenterConfig.refresh();
 //验证配置
 ConfigValidationUtils.validateConfigCenterConfig(configCenterConfig);
 if (configCenterConfig.isValid()) {
 //配置合法则将配置放入配置管理器中
 configManager.addConfigCenter(configCenterConfig);
 configCenters = configManager.getConfigCenters();
 }
 } else {
 //一个或者多个配置中心配置存在的情况下的配置刷新
 for (ConfigCenterConfig configCenterConfig : configCenters) {
 configCenterConfig.refresh();
 //验证配置
 ConfigValidationUtils.validateConfigCenterConfig(configCenterConfig);
 }
 }

 //配置中心配置不为空则将配置中心配置添加到environment中
 if (CollectionUtils.isNotEmpty(configCenters)) {
 //多配置中心本地动态配置对象创建CompositeDynamicConfiguration
 CompositeDynamicConfiguration compositeDynamicConfiguration = new CompositeDynamicConfiguration();
 //获取配置中心的相关配置
 for (ConfigCenterConfig configCenter : configCenters) {
 // Pass config from ConfigCenterBean to environment
 //将配置中心的外部化配置,更新到环境里面
 environment.updateExternalConfigMap(configCenter.getExternalConfiguration());
 //将配置中心的应用配置,添加到环境里面
 environment.updateAppExternalConfigMap(configCenter.getAppExternalConfiguration());

 // Fetch config from remote config center
 //从配置中心拉取配置添加到组合配置中
 compositeDynamicConfiguration.addConfiguration(prepareEnvironment(configCenter));
 }
 //将配置中心中的动态配置信息 设置到environment的动态配置属性中
 environment.setDynamicConfiguration(compositeDynamicConfiguration);
 }
 }

13.2.1 配置管理器加载配置

前面我们看到了配置管理器会从系统属性中加载配置这里我们来详细看下，配置往往是我们使用者比较关注的内容，

configManager.loadConfigsOfTypeFromProps(ApplicationConfig.class);

配置管理器加载配置代码: 来自ConfigManager的父类型AbstractConfigManager中

public <T extends AbstractConfig> List<T> loadConfigsOfTypeFromProps(Class<T> cls) {
 List<T> tmpConfigs = new ArrayList<>();
 //获取属性配置 dubbo properties in classpath
 //这个配置信息回头说
 PropertiesConfiguration properties = environment.getPropertiesConfiguration();

 // load multiple configs with id
 //多注册中心配置id查询

 /*
 搜索属性并提取指定类型的配置ID。
 例如如下配置
 # 配置信息 properties
 dubbo.registries.registry1.address=xxx
 dubbo.registries.registry2.port=xxx

 # 提取配置的id extract
 Set configIds = getConfigIds(RegistryConfig.class)

 # 提取的配置id结果 result
 configIds: ["registry1", "registry2"]
 */
 Set<String> configIds = this.getConfigIdsFromProps(cls);
 configIds.forEach(id -> {
 //遍历这些配置id 判断配置缓存(configsCache成员变量)中是否已经存在当前配置
 if (!this.getConfig(cls, id).isPresent()) {
 T config;
 try {
 //创建配置对象 为配置对象初始化配置id
 config = createConfig(cls, scopeModel);
 config.setId(id);
 } catch (Exception e) {
 throw new IllegalStateException("create config instance failed, id: " + id + ", type:" + cls.getSimpleName());
 }

 String key = null;
 boolean addDefaultNameConfig = false;
 try {
 // add default name config (same as id), e.g. dubbo.protocols.rest.port=1234
 key = DUBBO + "." + AbstractConfig.getPluralTagName(cls) + "." + id + ".name";
 if (properties.getProperty(key) == null) {
 properties.setProperty(key, id);
 addDefaultNameConfig = true;
 }
 //刷新配置信息 好理解点就是Dubbo配置属性重写
 config.refresh();
 //将当前配置信息添加到配置缓存中configsCache成员变量
 this.addConfig(config);
 tmpConfigs.add(config);
 } catch (Exception e) {
 logger.error("load config failed, id: " + id + ", type:" + cls.getSimpleName(), e);
 throw new IllegalStateException("load config failed, id: " + id + ", type:" + cls.getSimpleName());
 } finally {
 if (addDefaultNameConfig && key != null) {
 properties.remove(key);
 }
 }
 }
 });

 // If none config of the type, try load single config
 //如果没有该类型的配置，请尝试加载单个配置
 if (this.getConfigs(cls).isEmpty()) {
 // load single config
 List<Map<String, String>> configurationMaps = environment.getConfigurationMaps();
 if (ConfigurationUtils.hasSubProperties(configurationMaps, AbstractConfig.getTypePrefix(cls))) {
 T config;
 try {
 config = createConfig(cls, scopeModel);
 config.refresh();
 } catch (Exception e) {
 throw new IllegalStateException("create default config instance failed, type:" + cls.getSimpleName());
 }

 this.addConfig(config);
 tmpConfigs.add(config);
 }
 }

 return tmpConfigs;
 }

13.2.2 默认使用注册中心地址为配置中心

出于兼容性目的，如果没有明确指定配置中心，并且registryConfig的UseAConfigCenter为null或true，请使用registry作为默认配置中心调用方法useRegistryAsConfigCenterIfNecessary()来处理逻辑我们来看下代码:

private void useRegistryAsConfigCenterIfNecessary() {
 // we use the loading status of DynamicConfiguration to decide whether ConfigCenter has been initiated.
 //我们使用DynamicConfiguration的加载状态来决定是否已启动ConfigCenter。配置中心配置加载完成之后会初始化动态配置defaultDynamicConfiguration
 if (environment.getDynamicConfiguration().isPresent()) {
 return;
 }
 //从配置缓存中查询是否存在config-center相关配置 ,如果已经存在配置了就无需使用注册中心的配置地址直接返回
 if (CollectionUtils.isNotEmpty(configManager.getConfigCenters())) {
 return;
 }

 // load registry
 //加载注册中心相关配置
 configManager.loadConfigsOfTypeFromProps(RegistryConfig.class);

 //查询是否有注册中心设置了默认配置isDefault 设置为true的注册中心则为默认注册中心列表,如果没有注册中心设置为默认注册中心,则获取所有未设置默认配置的注册中心列表
 List<RegistryConfig> defaultRegistries = configManager.getDefaultRegistries();
 //存在注册中心
 if (defaultRegistries.size() > 0) {
 defaultRegistries
 .stream()
 //判断当前注册中心是否可以作为配置中心
 .filter(this::isUsedRegistryAsConfigCenter)
 //将注册中心配置映射转换为配置中心
 .map(this::registryAsConfigCenter)
 //遍历配置中心流
 .forEach(configCenter -> {
 if (configManager.getConfigCenter(configCenter.getId()).isPresent()) {
 return;
 }
 //配置管理器中添加配置中心,方便后去读取配置中心的配置信息
 configManager.addConfigCenter(configCenter);
 logger.info("use registry as config-center: " + configCenter);

 });
 }
 }

13.2.2.1 如何判断当前注册中心是否可以为配置中心

isUsedRegistryAsConfigCenter

private boolean isUsedRegistryAsCenter(RegistryConfig registryConfig, Supplier<Boolean> usedRegistryAsCenter,
 String centerType,
 Class<?> extensionClass) {
 final boolean supported;
 //这个useAsConfigCenter参数是来自注册中心的配置 如果配置了这个值则以这个值为准,如果配置了false则这个注册中心不能做为配置中心
 Boolean configuredValue = usedRegistryAsCenter.get();
 if (configuredValue != null) { // If configured, take its value.
 supported = configuredValue.booleanValue();
 } else { // Or check the extension existence
 //这个逻辑的话是判断下注册中心的协议是否满足要求,我们例子代码中使用的是zookeeper
 String protocol = registryConfig.getProtocol();
 //这个扩展是否支持的逻辑判断是这样的扫描扩展类 看一下当前扩展类型是否有对应协议的扩展 比如在扩展文件里面这样配置过后是支持的 protocol=xxxImpl
 //动态配置的扩展类型为:interface org.apache.dubbo.common.config.configcenter.DynamicConfigurationFactory
 //zookeeper协议肯定是支持的因为zookeeper协议实现了这个动态配置工厂 ,这个扩展类型为ZookeeperDynamicConfigurationFactory
 //代码位置在dubbo-configcenter-zookeeper包中的org.apache.dubbo.common.config.configcenter.DynamicConfigurationFactory扩展配置中内容为zookeeper=org.apache.dubbo.configcenter.support.zookeeper.ZookeeperDynamicConfigurationFactory
 supported = supportsExtension(extensionClass, protocol);
 //配置中心走注册中心会打印一条日志
 if (logger.isInfoEnabled()) {
 logger.info(format("No value is configured in the registry, the %s extension[name : %s] %s as the %s center"
 , extensionClass.getSimpleName(), protocol, supported ? "supports" : "does not support", centerType));
 }
 }

 //配置中心走注册中心会打印一条日志
 if (logger.isInfoEnabled()) {
 logger.info(format("The registry[%s] will be %s as the %s center", registryConfig,
 supported ? "used" : "not used", centerType));
 }
 return supported;
 }

这个扩展是否支持的逻辑判断是这样的扫描扩展类看一下当前扩展类型是否有对应协议的扩展比如在扩展文件里面这样配置过后是支持的 protocol=xxxImpl 配置中心的动态配置的扩展类型为 org.apache.dubbo.common.config.configcenter.DynamicConfigurationFactory

zookeeper协议肯定是支持的因为zookeeper协议实现了这个动态配置工厂 ,这个扩展类型为ZookeeperDynamicConfigurationFactory代码位置在dubbo-configcenter-zookeeper包中的org.apache.dubbo.common.config.configcenter.DynamicConfigurationFactory扩展配置中内容为

zookeeper=org.apache.dubbo.configcenter.support.zookeeper.ZookeeperDynamicConfigurationFactory

13.2.2.2 注册中心配置转配置中心配置

这个逻辑是registryAsConfigCenter方法,我来贴一下代码:

private ConfigCenterConfig registryAsConfigCenter(RegistryConfig registryConfig) {
 //注册中心协议获取这里例子中的是zookeeper协议
 String protocol = registryConfig.getProtocol();
 //注册中心端口 2181
 Integer port = registryConfig.getPort();
 //在Dubbo中配置信息 很多情况下都以URL形式表示,这里转换后的地址为zookeeper://127.0.0.1:2181
 URL url = URL.valueOf(registryConfig.getAddress(), registryConfig.getScopeModel());
 //生成当前配置中心的id 封装之后的内容为:
 //config-center-zookeeper-127.0.0.1-2181
 String id = "config-center-" + protocol + "-" + url.getHost() + "-" + port;
 //配置中心配置对象创建
 ConfigCenterConfig cc = new ConfigCenterConfig();
 //config-center-zookeeper-127.0.0.1-2181
 cc.setId(id);
 cc.setScopeModel(applicationModel);
 if (cc.getParameters() == null) {
 cc.setParameters(new HashMap<>());
 }
 if (CollectionUtils.isNotEmptyMap(registryConfig.getParameters())) {
 cc.getParameters().putAll(registryConfig.getParameters()); // copy the parameters
 }
 cc.getParameters().put(CLIENT_KEY, registryConfig.getClient());
 //zookeeper
 cc.setProtocol(protocol);
 //2181
 cc.setPort(port);
 if (StringUtils.isNotEmpty(registryConfig.getGroup())) {
 cc.setGroup(registryConfig.getGroup());
 }
 //这个方法转换地址是修复bug用的可以看bug https://github.com/apache/dubbo/issues/6476
 cc.setAddress(getRegistryCompatibleAddress(registryConfig));
 //注册中心分组做为配置中心命名空间 这里为null
 cc.setNamespace(registryConfig.getGroup());
 //zk认证信息
 cc.setUsername(registryConfig.getUsername());
 //zk认证信息
 cc.setPassword(registryConfig.getPassword());
 if (registryConfig.getTimeout() != null) {
 cc.setTimeout(registryConfig.getTimeout().longValue());
 }
 //这个属性注释中已经建议了已经弃用了默认就是false了
 //如果配置中心被赋予最高优先级，它将覆盖所有其他配置，
 cc.setHighestPriority(false);
 return cc;
 }

13.3 配置刷新逻辑

来自AbstractConfig类型的refresh()方法

public void refresh() {
 refreshed.set(true);
 try {
 // check and init before do refresh
 //刷新之前执行的逻辑 这里并做什么逻辑
 preProcessRefresh();

 //获取当前域模型的环境信息对象
 Environment environment = getScopeModel().getModelEnvironment();
 List<Map<String, String>> configurationMaps = environment.getConfigurationMaps();

 // Search props starts with PREFIX in order
 String preferredPrefix = null;
 for (String prefix : getPrefixes()) {
 if (ConfigurationUtils.hasSubProperties(configurationMaps, prefix)) {
 preferredPrefix = prefix;
 break;
 }
 }
 if (preferredPrefix == null) {
 preferredPrefix = getPrefixes().get(0);
 }
 // Extract sub props (which key was starts with preferredPrefix)
 Collection<Map<String, String>> instanceConfigMaps = environment.getConfigurationMaps(this, preferredPrefix);
 Map<String, String> subProperties = ConfigurationUtils.getSubProperties(instanceConfigMaps, preferredPrefix);
 InmemoryConfiguration subPropsConfiguration = new InmemoryConfiguration(subProperties);

 if (logger.isDebugEnabled()) {
 String idOrName = "";
 if (StringUtils.hasText(this.getId())) {
 idOrName = "[id=" + this.getId() + "]";
 } else {
 String name = ReflectUtils.getProperty(this, "getName");
 if (StringUtils.hasText(name)) {
 idOrName = "[name=" + name + "]";
 }
 }
 logger.debug("Refreshing " + this.getClass().getSimpleName() + idOrName +
 " with prefix [" + preferredPrefix +
 "], extracted props: " + subProperties);
 }

 assignProperties(this, environment, subProperties, subPropsConfiguration);

 // process extra refresh of subclass, e.g. refresh method configs
 processExtraRefresh(preferredPrefix, subPropsConfiguration);

 } catch (Exception e) {
 logger.error("Failed to override field value of config bean: " + this, e);
 throw new IllegalStateException("Failed to override field value of config bean: " + this, e);
 }

 postProcessRefresh();
 }

13.4 配置中心配置大全

ConfigCenterConfig类型下面配置信息来自官网 dubbo:config-center 配置

配置中心。对应的配置类：org.apache.dubbo.config.ConfigCenterConfig

属性	对应URL参数	类型	是否必填	缺省值	描述	兼容性
protocol	config.protocol	string	可选	zookeeper	使用哪个配置中心：apollo、zookeeper、nacos等。以zookeeper为例 1. 指定protocol，则address可以简化为`127.0.0.1:2181`； 2. 不指定protocol，则address取值为`zookeeper://127.0.0.1:2181`	2.7.0+
address	config.address	string	必填		配置中心地址。取值参见protocol说明	2.7.0+
highest-priority	config.highestPriority	boolean	可选	true	来自配置中心的配置项具有最高优先级，即会覆盖本地配置项。	2.7.0+
namespace	config.namespace	string	可选	dubbo	通常用于多租户隔离，实际含义视具体配置中心而不同。如： zookeeper - 环境隔离，默认值`dubbo`； apollo - 区分不同领域的配置集合，默认使用`dubbo`和`application`	2.7.0+
cluster	config.cluster	string	可选		含义视所选定的配置中心而不同。如Apollo中用来区分不同的配置集群	2.7.0+
group	config.group	string	可选	dubbo	含义视所选定的配置中心而不同。 nacos - 隔离不同配置集 zookeeper - 隔离不同配置集	2.7.0+
check	config.check	boolean	可选	true	当配置中心连接失败时，是否终止应用启动。	2.7.0+
config-file	config.configFile	string	可选	dubbo.properties	全局级配置文件所映射到的key zookeeper - 默认路径/dubbo/config/dubbo/dubbo.properties apollo - dubbo namespace中的dubbo.properties键	2.7.0+
timeout	config.timeout	integer		3000ms	获取配置的超时时间	2.7.0+
username		string			如果配置中心需要做校验，用户名 Apollo暂未启用	2.7.0+
password		string			如果配置中心需要做校验，密码 Apollo暂未启用	2.7.0+
parameters		Map<string, string>			扩展参数，用来支持不同配置中心的定制化配置参数	2.7.0+
include-spring-env		boolean	可选	false	使用Spring框架时支持，为true时，会自动从Spring Environment中读取配置。默认依次读取 key为dubbo.properties的配置 key为dubbo.properties的PropertySource	2.7.0+

原文：Dubbo的三大中心之配置中心

Blog: 12 全局视野来看Dubbo3的服务启动生命周期

Fri, 12 Aug 2022 00:00:00 +0000

12 全局视野来看Dubbo3的服务启动生命周期

12.1 启动方法简介

在说启动方法之前先把视野拉回第一章《1-从一个服务提供者的Demo说起》我们的Demo代码,下面只贴一下核心代码:

public class Application {
 public static void main(String[] args) throws Exception {
 startWithBootstrap();
 }
 private static void startWithBootstrap() {
 //前面的文章都在说这个服务配置对象的创建,中间又说了分层域模型,扩展加载机制
 ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
 //为服务配置下服务接口和服务实现,下面两行用来初始化对象就不详细说了
 service.setInterface(DemoService.class);
 service.setRef(new DemoServiceImpl());
 //这一个篇章主要说这里:
 DubboBootstrap bootstrap = DubboBootstrap.getInstance();
 //初始化应用配置
 bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
 //初始化注册中心配置
 .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
 //初始化协议配置
 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
 //初始化服务配置
 .service(service)
 //启动
 .start()
 .await();
 }
}

前面我们介绍了Dubbo启动器DubboBootstrap类型对象的创建,又介绍了为DubboBootstrap启动器初始化各种配置信息,这一个博客就开始到了分析启动方法的位置了,Dubbo启动器借助Deployer发布器来启动和发布服务,发布器的启动过程包含了启动配置中心,加载配置,启动元数据中心,启动服务等操作都是比较重要又比较复杂的过程,这里我们先来看下启动过程的生命周期来为后面的内容做好铺垫。

12.2 启动器启动方法的调用逻辑start()

这里我们就直接来看DubboBootstrap的start()方法:

 public DubboBootstrap start() {
 //调用重载的方法进行启动参数代表是否等待启动结束
 this.start(true);
 return this;
 }

我们再来看重载的start方法:

public DubboBootstrap start(boolean wait) {
 //这个发布器是在ApplicationModel对象创建之后初始化的时候进行初始化的具体类型为DefaultApplicationDeployer
 Future future = applicationDeployer.start();

 if (wait) {
 try {
 //等待异步启动的结果
 future.get();
 } catch (Exception e) {
 //启动失败则抛出一个异常
 throw new IllegalStateException("await dubbo application start finish failure", e);
 }
 }
 return this;
 }

12.3 应用程序发布器DefaultApplicationDeployer的启动方法

发布器是帮助我们发布服务和引用服务的,在Dubbo3中不论是服务提供者还是服务消费者如果想要启动服务都需要走这个启动方法的逻辑,所以务必重视

我们直接来看DefaultApplicationDeployer的start()代码:

@Override
 public Future start() {
 //启动锁，防止重复启动
 synchronized (startLock) {
 //发布器,状态已经设置为停止或者失败了就直接抛出异常
 if (isStopping() || isStopped() || isFailed()) {
 throw new IllegalStateException(getIdentifier() + " is stopping or stopped, can not start again");
 }

 try {
 // maybe call start again after add new module, check if any new module
 //可能在添加新模块后再次调用start，检查是否有任何新模块
 //这里遍历当前应用程序下的所有模块如果某个模块是PENDING状态则这里hasPendingModule的值为true
 boolean hasPendingModule = hasPendingModule();
 //发布器状态正在启动中
 if (isStarting()) {
 // currently, is starting, maybe both start by module and application
 // if it has new modules, start them
 //存在挂器的模块
 if (hasPendingModule) {
 //启动模块
 startModules();
 }
 // if it is starting, reuse previous startFuture
 //模块异步启动中
 return startFuture;
 }

 // if is started and no new module, just return
 //如果已启动且没有新模块，直接返回
 if (isStarted() && !hasPendingModule) {
 return CompletableFuture.completedFuture(false);
 }

 // pending -> starting : first start app
 // started -> starting : re-start app
 //启动状态切换，将启动状态切换到STARTING（pending和started状态无需切换）
 onStarting();
 //核心初始化逻辑，这里主要做一些应用级别启动比如配置中心，元数据中心
 initialize();
 //启动模块（我们的服务提供和服务引用是在这个模块级别的）
 doStart();
 } catch (Throwable e) {
 onFailed(getIdentifier() + " start failure", e);
 throw e;
 }

 return startFuture;
 }
 }

这个启动方法逻辑不多主要三个方法我们重点来看：

onStarting() 这个是启动之前的状态切换
initialize() 应用的初始化逻辑比如配置中心，元数据中心的初始化
doStart() 启动模块比如启动我们的服务提供和服务引用的）

继续看后面的细节吧，代码胜千言。

12.4 应用程序发布器对应用级别的初始化逻辑

这个我们先来看DefaultApplicationDeployer的初始化方法initialize()：

@Override
 public void initialize() {
 //状态判断 如果已经初始化过了就直接返回
 if (initialized) {
 return;
 }
 // Ensure that the initialization is completed when concurrent calls
 //启动锁，确保在并发调用时完成初始化
 synchronized (startLock) {
 //双重校验锁 如果已经初始化过了就直接返回
 if (initialized) {
 return;
 }
 // register shutdown hook
 //注册关闭钩子，这个逻辑基本每个中间件应用都必须要要做的事情了，正常关闭应用回收资源，一般没这个逻辑情况下容易出现一些异常，让我们开发人员很疑惑，而这个逻辑往往并不好处理的干净。
 registerShutdownHook();

 //启动配置中心，感觉Dubbo3耦合了这个玩意
 startConfigCenter();

 //加载配置，一般配置信息当前机器的来源：环境变量，JVM启动参数，配置文字
 loadApplicationConfigs();

 //初始化模块发布器 （发布服务提供和服务引用使用）
 initModuleDeployers();

 // @since 2.7.8
 //启动元数据中心
 startMetadataCenter();

 //初始化完成
 initialized = true;

 if (logger.isInfoEnabled()) {
 logger.info(getIdentifier() + " has been initialized!");
 }
 }
 }

这个是个生命周期整体概览的方法，将具体逻辑拆分到各个子方法中，是代码重构的一种策略，上面注释也很清楚了就不细说了，上面每个方法在后面会有单独的博客来分析。

12.5 应用下模块的启动（服务的发布与引用）

我们回过头来详细看DefaultApplicationDeployer的doStart()代码:

private void doStart() {
 // 启动模块
 startModules();

DefaultApplicationDeployer的 startModules()方法

private void startModules() {
 // ensure init and start internal module first
 //确保初始化并首先启动内部模块,Dubbo3中将模块分为内部和外部，内部是核心代码已经提供的一些服务比如元数据服务，外部是我们自己写的服务
 prepareInternalModule();

 // filter and start pending modules, ignore new module during starting, throw exception of module start
 //启动所有的模块 （启动所有的服务）
 for (ModuleModel moduleModel : new ArrayList<>(applicationModel.getModuleModels())) {
 //这个状态默认就是PENDING的
 if (moduleModel.getDeployer().isPending()) {
 //模块启动器，发布服务
 moduleModel.getDeployer().start();
 }
 }
 }

这个模块的启动其实就是用来启动服务的先启动内部服务，再启动外部服务内部服务有个元数据服务Dubbo3中每个服务都可以对外提供服务的元数据信息，来简化服务配置，不论是内部服务还是外部服务调用的代码逻辑都是模块发布器ModuleDeployer的start()方法，接下来我们详细看下模块发布器的生命周期函数。

12.6 模块发布器发布服务的过程

前面我们说到了所有的服务都是经过模块发布器，ModuleDeployer的start()方法来启动的，那我们接下来就来看看这个模块发布器的启动方法。

ModuleDeployer的start()方法代码：

@Override
 public synchronized Future start() throws IllegalStateException {
 //模块发布器已经停止或者启动失败则直接抛出异常返回
 if (isStopping() || isStopped() || isFailed()) {
 throw new IllegalStateException(getIdentifier() + " is stopping or stopped, can not start again");
 }

 try {
 //启动中或者已经启动了则直接返回一个Future对象
 if (isStarting() || isStarted()) {
 return startFuture;
 }
 //切换模块启动状态为STARTING
 onModuleStarting();

 // initialize
 //如果应用未初始化则初始化（非正常逻辑）
 applicationDeployer.initialize();
 //模块发布器进行初始化
 initialize();

 // export services
 //暴露服务
 exportServices();

 // prepare application instance
 // exclude internal module to avoid wait itself
 if (moduleModel != moduleModel.getApplicationModel().getInternalModule()) {
 applicationDeployer.prepareInternalModule();
 }

 // refer services
 //引用服务
 referServices();

 // if no async export/refer services, just set started
 //非异步启动则直接切换状态为STARTED
 if (asyncExportingFutures.isEmpty() && asyncReferringFutures.isEmpty()) {
 onModuleStarted();
 } else {
 //如果是异步的则等待服务发布和服务引用异步回调
 frameworkExecutorRepository.getSharedExecutor().submit(() -> {
 try {
 // wait for export finish
 waitExportFinish();
 // wait for refer finish
 waitReferFinish();
 } catch (Throwable e) {
 logger.warn("wait for export/refer services occurred an exception", e);
 } finally {
 //异步回调完成 所有服务都启动了，再切换状态
 onModuleStarted();
 }
 });
 }
 } catch (Throwable e) {
 onModuleFailed(getIdentifier() + " start failed: " + e, e);
 throw e;
 }
 return startFuture;
 }

好了整体的服务启动生命周期就如上代码，后续我们再详细来看每个细节。

12.7 发布器简介

前面主要说了应用和模块的发布器的启动和初始化，下面简单了解下它们的关系，如下所示可以发布器主要包含

应用的发布器ApplicationDeployer用于初始化并启动应用程序实例
模块发布器ModuleDeployer 模块（服务）的导出/引用服务

两种发布器有各自的接口，他们都继承了抽象的发布器AbstractDeployer 封装了一些公共的操作比如状态切换，状态查询的逻辑。

另外我们再来看下发布过程的状态枚举DeployState如下：

public enum DeployState {
 /**
 * Unknown state
 */
 UNKNOWN,

 /**
 * Pending, wait for start
 */
 PENDING,

 /**
 * Starting
 */
 STARTING,

 /**
 * Started
 */
 STARTED,

 /**
 * Stopping
 */
 STOPPING,

 /**
 * Stopped
 */
 STOPPED,

 /**
 * Failed
 */
 FAILED
}

Dubbo这一块后续可以优化以下，这里的状态切换全部耦合在一起了，可以考虑使用状态机将状态与行为解耦。

原文：Dubbo启动器DubboBootstrap添加协议配置信息ProtocolConfig

Blog: 11-Dubbo启动器DubboBootstrap添加协议配置信息ProtocolConfig

Thu, 11 Aug 2022 00:00:00 +0000

11-Dubbo启动器DubboBootstrap添加协议配置信息ProtocolConfig

11.1 简介

先贴个代码用来参考:

 DubboBootstrap bootstrap = DubboBootstrap.getInstance();
 bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
 .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
 .service(service)
 .start()
 .await();

上个博客我们说了 RegistryConfig对象的创建,启动器对象在启动之前是要初始化一些配置信息的,这里我们来看这一行代码协议配置信息:

.protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))

11.2 协议的配置相关

下面的配置来源于官网

服务提供者协议配置。对应的配置类： org.apache.dubbo.config.ProtocolConfig。同时，如果需要支持多协议，可以声明多个 dubbo:protocol 标签，并在 dubbo:service 中通过 protocol 属性指定使用的协议。

属性	对应URL参数	类型	是否必填	缺省值	作用	描述	兼容性
id		string	可选	dubbo	配置关联	协议BeanId，可以在<dubbo:service protocol="">中引用此ID，如果ID不填，缺省和name属性值一样，重复则在name后加序号。	2.0.5以上版本
name		string	必填	dubbo	性能调优	协议名称	2.0.5以上版本
port		int	可选	dubbo协议缺省端口为20880，rmi协议缺省端口为1099，http和hessian协议缺省端口为80；如果没有配置port，则自动采用默认端口，如果配置为-1，则会分配一个没有被占用的端口。Dubbo 2.4.0+，分配的端口在协议缺省端口的基础上增长，确保端口段可控。	服务发现	服务端口	2.0.5以上版本
host		string	可选	自动查找本机IP	服务发现	-服务主机名，多网卡选择或指定VIP及域名时使用，为空则自动查找本机IP，-建议不要配置，让Dubbo自动获取本机IP	2.0.5以上版本
threadpool	threadpool	string	可选	fixed	性能调优	线程池类型，可选：fixed/cached	2.0.5以上版本
threads	threads	int	可选	200	性能调优	服务线程池大小(固定大小)	2.0.5以上版本
iothreads	threads	int	可选	cpu个数+1	性能调优	io线程池大小(固定大小)	2.0.5以上版本
accepts	accepts	int	可选	0	性能调优	服务提供方最大可接受连接数	2.0.5以上版本
payload	payload	int	可选	8388608(=8M)	性能调优	请求及响应数据包大小限制，单位：字节	2.0.5以上版本
codec	codec	string	可选	dubbo	性能调优	协议编码方式	2.0.5以上版本
serialization	serialization	string	可选	dubbo协议缺省为hessian2，rmi协议缺省为java，http协议缺省为json	性能调优	协议序列化方式，当协议支持多种序列化方式时使用，比如：dubbo协议的dubbo,hessian2,java,compactedjava，以及http协议的json等	2.0.5以上版本
accesslog	accesslog	string/boolean	可选		服务治理	设为true，将向logger中输出访问日志，也可填写访问日志文件路径，直接把访问日志输出到指定文件	2.0.5以上版本
path		string	可选		服务发现	提供者上下文路径，为服务path的前缀	2.0.5以上版本
transporter	transporter	string	可选	dubbo协议缺省为netty	性能调优	协议的服务端和客户端实现类型，比如：dubbo协议的mina,netty等，可以分拆为server和client配置	2.0.5以上版本
server	server	string	可选	dubbo协议缺省为netty，http协议缺省为servlet	性能调优	协议的服务器端实现类型，比如：dubbo协议的mina,netty等，http协议的jetty,servlet等	2.0.5以上版本
client	client	string	可选	dubbo协议缺省为netty	性能调优	协议的客户端实现类型，比如：dubbo协议的mina,netty等	2.0.5以上版本
dispatcher	dispatcher	string	可选	dubbo协议缺省为all	性能调优	协议的消息派发方式，用于指定线程模型，比如：dubbo协议的all, direct, message, execution, connection等	2.1.0以上版本
queues	queues	int	可选	0	性能调优	线程池队列大小，当线程池满时，排队等待执行的队列大小，建议不要设置，当线程池满时应立即失败，重试其它服务提供机器，而不是排队，除非有特殊需求。	2.0.5以上版本
charset	charset	string	可选	UTF-8	性能调优	序列化编码	2.0.5以上版本
buffer	buffer	int	可选	8192	性能调优	网络读写缓冲区大小	2.0.5以上版本
heartbeat	heartbeat	int	可选	0	性能调优	心跳间隔，对于长连接，当物理层断开时，比如拔网线，TCP的FIN消息来不及发送，对方收不到断开事件，此时需要心跳来帮助检查连接是否已断开	2.0.10以上版本
telnet	telnet	string	可选		服务治理	所支持的telnet命令，多个命令用逗号分隔	2.0.5以上版本
register	register	boolean	可选	true	服务治理	该协议的服务是否注册到注册中心	2.0.8以上版本
contextpath	contextpath	String	可选	缺省为空串	服务治理		2.0.6以上版本

同样官网提供的参数里面并未包含所有的属性下面我就将其余的属性列举一下方便学习参考:

变量	类型	说明
threadname	String	线程池名称
corethreads	Integer	线程池核心线程大小
alive	Integer	线程池keepAliveTime，默认单位时间单位。毫秒
exchanger	String	交换器配置信息如何交换
prompt	String	命令行提示符
status	String	状态检查
sslEnabled	Boolean	ssl是否启用

11.3 协议配置对象创建与添加

前面例子中调用的代码

 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))

这里我们配置了协议类型为dubbo 端口为-1则会分配一个没有被占用的端口

继续看下DubboBootstrap的protocol方法

public DubboBootstrap protocol(ProtocolConfig protocolConfig) {
 //配置信息转List
 return protocols(singletonList(protocolConfig));
 }

继续看protocols方法 ,这个代码与前面两个博客中看到的向配置管理器添加配置对象的逻辑是一样的这里就不说了可以看前面的博客《9-Dubbo启动器DubboBootstrap添加应用程序的配置信息ApplicationConfig》

 public DubboBootstrap protocols(List<ProtocolConfig> protocolConfigs) {
 if (CollectionUtils.isEmpty(protocolConfigs)) {
 return this;
 }
 for (ProtocolConfig protocolConfig : protocolConfigs) {
 protocolConfig.setScopeModel(applicationModel);
 configManager.addProtocol(protocolConfig);
 }
 return this;
 }

原文：Dubbo启动器DubboBootstrap添加协议配置信息ProtocolConfig

Blog: 10-Dubbo启动器DubboBootstrap添加注册中心配置信息RegistryConfig

Wed, 10 Aug 2022 00:00:00 +0000

10-Dubbo启动器DubboBootstrap添加注册中心配置信息RegistryConfig

10.1 简介

先贴个代码用来参考:

 DubboBootstrap bootstrap = DubboBootstrap.getInstance();
 bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
 .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
 .service(service)
 .start()
 .await();

上个博客我们说了启动器ApplicationConfig对象的创建,启动器对象在启动之前是要初始化一些配置信息的,这里我们来看这一行代码注册中心配置信息:

registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))

10.2 注册中心的配置相关

下面的配置来源于官网

属性	对应URL参数	类型	是否必填	缺省值	作用	描述	兼容性
id		string	可选		配置关联	注册中心引用BeanId，可以在<dubbo:service registry="">或<dubbo:reference registry="">中引用此ID	1.0.16以上版本
address	host:port	string	必填		服务发现	注册中心服务器地址，如果地址没有端口缺省为9090，同一集群内的多个地址用逗号分隔，如：ip:port,ip:port，不同集群的注册中心，请配置多个dubbo:registry标签	1.0.16以上版本
protocol		string	可选	dubbo	服务发现	注册中心地址协议，支持`dubbo`, `multicast`, `zookeeper`, `redis`, `consul(2.7.1)`, `sofa(2.7.2)`, `etcd(2.7.2)`, `nacos(2.7.2)`等协议	2.0.0以上版本
port		int	可选	9090	服务发现	注册中心缺省端口，当address没有带端口时使用此端口做为缺省值	2.0.0以上版本
username		string	可选		服务治理	登录注册中心用户名，如果注册中心不需要验证可不填	2.0.0以上版本
password		string	可选		服务治理	登录注册中心密码，如果注册中心不需要验证可不填	2.0.0以上版本
transport	registry.transporter	string	可选	netty	性能调优	网络传输方式，可选mina,netty	2.0.0以上版本
timeout	registry.timeout	int	可选	5000	性能调优	注册中心请求超时时间(毫秒)	2.0.0以上版本
session	registry.session	int	可选	60000	性能调优	注册中心会话超时时间(毫秒)，用于检测提供者非正常断线后的脏数据，比如用心跳检测的实现，此时间就是心跳间隔，不同注册中心实现不一样。	2.1.0以上版本
file	registry.file	string	可选		服务治理	使用文件缓存注册中心地址列表及服务提供者列表，应用重启时将基于此文件恢复，注意：两个注册中心不能使用同一文件存储	2.0.0以上版本
wait	registry.wait	int	可选	0	性能调优	停止时等待通知完成时间(毫秒)	2.0.0以上版本
check	check	boolean	可选	true	服务治理	注册中心不存在时，是否报错	2.0.0以上版本
register	register	boolean	可选	true	服务治理	是否向此注册中心注册服务，如果设为false，将只订阅，不注册	2.0.5以上版本
subscribe	subscribe	boolean	可选	true	服务治理	是否向此注册中心订阅服务，如果设为false，将只注册，不订阅	2.0.5以上版本
dynamic	dynamic	boolean	可选	true	服务治理	服务是否动态注册，如果设为false，注册后将显示为disable状态，需人工启用，并且服务提供者停止时，也不会自动取消注册，需人工禁用。	2.0.5以上版本
group	group	string	可选	dubbo	服务治理	服务注册分组，跨组的服务不会相互影响，也无法相互调用，适用于环境隔离。	2.0.5以上版本
simplified	simplified	boolean	可选	false	服务治理	注册到注册中心的URL是否采用精简模式的（与低版本兼容）	2.7.0以上版本
extra-keys	extraKeys	string	可选		服务治理	在simplified=true时，extraKeys允许你在默认参数外将额外的key放到URL中，格式：“interface,key1,key2”。	2.7.0以上版本

同样官网提供的参数里面并未包含所有的属性下面我就将其余的属性列举一下方便学习参考:

变量	类型	说明
server	String
client	String
cluster	String	影响流量在注册中心之间的分布，在订阅多个注册中心时很有用，可用选项：1。区域感知，特定类型的流量总是根据流量的来源进入一个注册表。
zone	String	注册表所属的区域，通常用于隔离流量
parameters	Map<String, String>	自定义参数
useAsConfigCenter	Boolean	该地址是否用作配置中心
useAsMetadataCenter	Boolean	该地址是否用作远程元数据中心
accepts	String	此注册表接受的rpc协议列表，例如“dubbo，rest”
preferred	Boolean	如果设置为true，则始终首先使用此注册表，这在订阅多个注册表时非常有用
weight	Integer	影响注册中心之间的流量分布，当订阅多个注册中心仅在未指定首选注册中心时才生效时，此功能非常有用。
registerMode	String	注册模式:实例级,接口级,所有
enableEmptyProtection	Boolean	收到的空url地址列表和空保护被禁用，将清除当前可用地址

10.3 注册中心配置对象创建与添加

前面例子中调用的代码

.registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))

首先我们要来看的是RegistryConfig类型的构造器

public RegistryConfig(String address) {
 setAddress(address);
 }

继续看setAddress方法

 public void setAddress(String address) {
 //保存地址
 this.address = address;
 //下面是支持将参数在url地址后面 比如用户名,密码,协议,端口,这几个参数提前做解析放入成员变量中
 if (address != null) {
 try {
 //地址转Dubbo的URL对象 这个URL是Dubbo自行实现的URL封装信息的类型
 URL url = URL.valueOf(address);

 // Refactor since 2.7.8
 //值不存在时候更新属性,非常巧妙的代码 重构了多个if判断
 //第一个参数值不存在则调用第二个方法,第二个方法的参数为第三方方法
 updatePropertyIfAbsent(this::getUsername, this::setUsername, url.getUsername());
 updatePropertyIfAbsent(this::getPassword, this::setPassword, url.getPassword());
 updatePropertyIfAbsent(this::getProtocol, this::setProtocol, url.getProtocol());
 updatePropertyIfAbsent(this::getPort, this::setPort, url.getPort());

 //移除掉url中的backup自定义参数 (备份的注册中心地址)
 Map<String, String> params = url.getParameters();
 if (CollectionUtils.isNotEmptyMap(params)) {
 params.remove(BACKUP_KEY);
 }
 //将自定义参数存储到成员变量中
 updateParameters(params);
 } catch (Exception ignored) {
 }
 }
 }

然后再回过头来看DubboBootstrap的registry方法:

 public DubboBootstrap registry(RegistryConfig registryConfig) {
 //将applicationModel对象设置给注册中心配置对象
 registryConfig.setScopeModel(applicationModel);
 //将注册中心配置对象添加到配置管理器中
 configManager.addRegistry(registryConfig);
 return this;
 }

直接来看配置管理器configManager的添加注册中心配置addRegistry方法:

public void addRegistry(RegistryConfig registryConfig) {
 addConfig(registryConfig);
}

configManager 的addConfig方法:

public final <T extends AbstractConfig> T addConfig(AbstractConfig config) {
 if (config == null) {
 return null;
 }
 // ignore MethodConfig
 //检查当前配置管理器支持管理的配置对象
 //目前支持的配置有ApplicationConfig,MonitorConfig,MetricsConfig,SslConfig,
 //ProtocolConfig,RegistryConfig,ConfigCenterConfig,MetadataReportConfig
 if (!isSupportConfigType(config.getClass())) {
 throw new IllegalArgumentException("Unsupported config type: " + config);
 }

 if (config.getScopeModel() != scopeModel) {
 config.setScopeModel(scopeModel);
 }
 //缓存中是否存在
 Map<String, AbstractConfig> configsMap = configsCache.computeIfAbsent(getTagName(config.getClass()), type -> new ConcurrentHashMap<>());
 //不是服务级接口配置则直接从缓存中读取到配置之后直接返回
 // fast check duplicated equivalent config before write lock
 if (!(config instanceof ReferenceConfigBase || config instanceof ServiceConfigBase)) {
 for (AbstractConfig value : configsMap.values()) {
 if (value.equals(config)) {
 return (T) value;
 }
 }
 }

 // lock by config type
 //添加配置
 synchronized (configsMap) {
 return (T) addIfAbsent(config, configsMap);
 }
 }

ConfigManager配置管理器的addIfAbsent方法:

private <C extends AbstractConfig> C addIfAbsent(C config, Map<String, C> configsMap)
 throws IllegalStateException {
 //配置信息为空直接返回
 if (config == null || configsMap == null) {
 return config;
 }

 // find by value
 //根据配置规则判断,配置存在则返回
 Optional<C> prevConfig = findDuplicatedConfig(configsMap, config);
 if (prevConfig.isPresent()) {
 return prevConfig.get();
 }

 //生成配置key
 String key = config.getId();
 if (key == null) {
 do {
 // generate key if id is not set
 key = generateConfigId(config);
 } while (configsMap.containsKey(key));
 }

 //不相同的配置key重复则抛出异常
 C existedConfig = configsMap.get(key);
 if (existedConfig != null && !isEquals(existedConfig, config)) {
 String type = config.getClass().getSimpleName();
 logger.warn(String.format("Duplicate %s found, there already has one default %s or more than two %ss have the same id, " +
 "you can try to give each %s a different id, override previous config with later config. id: %s, prev: %s, later: %s",
 type, type, type, type, key, existedConfig, config));
 }

 // override existed config if any
 //将配置对象存入configsMap对象中,configsMap来源于configsCache
 configsMap.put(key, config);
 return config;
 }

原文： «Dubbo启动器DubboBootstrap添加注册中心配置信息RegistryConfig»

Blog: 9-Dubbo启动器DubboBootstrap添加应用程序的配置信息ApplicationConfig

Tue, 09 Aug 2022 00:00:00 +0000

9-Dubbo启动器DubboBootstrap添加应用程序的配置信息ApplicationConfig

9.1 简介

先贴个代码用来参考:

 DubboBootstrap bootstrap = DubboBootstrap.getInstance();
 bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
 .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
 .service(service)
 .start()
 .await();

上个博客我们说了启动器对象的创建,启动器对象在启动之前是要初始化一些配置信息的,这里我们来看这一行代码:

bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))

9.2 应用程序ApplicationConfig的配置信息

ApplicationConfig的构造器比较简单就是为他的成员变量name赋值来标识这个应用程序的名字下面我们直接参考下官网的配置表格:

属性	对应URL参数	类型	是否必填	缺省值	作用	描述	兼容性
name	application	string	必填		服务治理	当前应用名称，用于注册中心计算应用间依赖关系，注意：消费者和提供者应用名不要一样，此参数不是匹配条件，你当前项目叫什么名字就填什么，和提供者消费者角色无关，比如：kylin应用调用了morgan应用的服务，则kylin项目配成kylin，morgan项目配成morgan，可能kylin也提供其它服务给别人使用，但kylin项目永远配成kylin，这样注册中心将显示kylin依赖于morgan	1.0.16以上版本
version	application.version	string	可选		服务治理	当前应用的版本	2.2.0以上版本
owner	owner	string	可选		服务治理	应用负责人，用于服务治理，请填写负责人公司邮箱前缀	2.0.5以上版本
organization	organization	string	可选		服务治理	组织名称(BU或部门)，用于注册中心区分服务来源，此配置项建议不要使用autoconfig，直接写死在配置中，比如china,intl,itu,crm,asc,dw,aliexpress等	2.0.0以上版本
architecture	architecture	string	可选		服务治理	用于服务分层对应的架构。如，intl、china。不同的架构使用不同的分层。	2.0.7以上版本
environment	environment	string	可选		服务治理	应用环境，如：develop/test/product，不同环境使用不同的缺省值，以及作为只用于开发测试功能的限制条件	2.0.0以上版本
compiler	compiler	string	可选	javassist	性能优化	Java字节码编译器，用于动态类的生成，可选：jdk或javassist	2.1.0以上版本
logger	logger	string	可选	slf4j	性能优化	日志输出方式，可选：slf4j,jcl,log4j,log4j2,jdk	2.2.0以上版本
metadata-type	metadata-type	String	可选	local	服务治理	metadata 传递方式，是以 Provider 视角而言的，Consumer 侧配置无效，可选值有： remote - Provider 把 metadata 放到远端注册中心，Consumer 从注册中心获取 local - Provider 把 metadata 放在本地，Consumer 从 Provider 处直接获取	2.7.6以上版本

官网的配置很详细了上面有一些属性是值得注意的比如这个name,compiler,logger,metadata-type 我们可能要多看下默认值是什么,方便我们在使用过程中遇到问题的排查

常用的属性参考官网的表格已经足够了,不过上面的属性不是列举了所有的属性,后续应该官方文档回更新: 我这里把缺失的一些属性列举出来:

变量	类型	说明
registries	List	应用级注册中心列表
registryIds	String	注册中心id列表
monitor	MonitorConfig	应用级监控配置
dumpDirectory	String	保存线程转储的目录
qosEnable	Boolean	是否启用qos
qosHost	String	要侦听的qos主机地址
qosPort	Integer	要侦听的qos端口
qosAcceptForeignIp	Boolean	qos是否接收外部IP
parameters	Map<String, String>	自定义参数
shutwait	String	应用程序关闭时间
hostname	String	主机名
registerConsumer	Boolean	用于控制是否将实例注册到注册表。仅当实例是纯消费者时才设置为“false”。
repository	String	没找到哪里用了
enableFileCache	Boolean	是否开启本地文件缓存
protocol	String	此应用程序的首选协议（名称）适用于难以确定哪个是首选协议的地方
metadataServiceProtocol	String	用于点对点的元数据传输的协议
metadataServicePort	Integer	元数据服务端口号，用于服务发现
livenessProbe	String	Liveness 存活探针用于设置qos中探测器的扩展
readinessProbe	String	Readiness 就绪探针
startupProbe	String	Startup 启动探针
registerMode	String	注册模式,实例级,接口集,所有
enableEmptyProtection	Boolean	接收到的空url地址列表和空保护被禁用，将清除当前可用地址

这里我们先来简单了解下这个实体类型的基本配置,直接看配置可能不太好理解,后面我们讲到每个配置的时候可以回来参考一下

应用程序配置对象添加到启动器中的配置管理器中

了解了配置信息再回过头来看下这个配置信息如何存放到启动器里面的:

我们的Demo调用代码如下:

 DubboBootstrap bootstrap = DubboBootstrap.getInstance();
 bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))

DubboBootstrap的application方法设置一个应用程序配置ApplicationConfig对象

 public DubboBootstrap application(ApplicationConfig applicationConfig) {
 //将启动器构造器中初始化的默认应用程序模型对象传递给配置对象
 applicationConfig.setScopeModel(applicationModel);
 //将配置信息添加到配置管理器中
 configManager.setApplication(applicationConfig);
 return this;
 }

ConfigManager配置管理器的setApplication方法

 @DisableInject
 public void setApplication(ApplicationConfig application) {
 addConfig(application);
 }

ConfigManager配置管理器的addConfig方法

public final <T extends AbstractConfig> T addConfig(AbstractConfig config) {

 if (config == null) {
 return null;
 }
 // ignore MethodConfig
 //检查当前配置管理器支持管理的配置对象
 //目前支持的配置有ApplicationConfig,MonitorConfig,MetricsConfig,SslConfig,
 //ProtocolConfig,RegistryConfig,ConfigCenterConfig,MetadataReportConfig
 if (!isSupportConfigType(config.getClass())) {
 throw new IllegalArgumentException("Unsupported config type: " + config);
 }

 if (config.getScopeModel() != scopeModel) {
 config.setScopeModel(scopeModel);
 }

 //缓存中是否存在
 Map<String, AbstractConfig> configsMap = configsCache.computeIfAbsent(getTagName(config.getClass()), type -> new ConcurrentHashMap<>());

 // fast check duplicated equivalent config before write lock
 //不是服务级配置则直接从缓存中读取到配置之后直接返回
 if (!(config instanceof ReferenceConfigBase || config instanceof ServiceConfigBase)) {
 for (AbstractConfig value : configsMap.values()) {
 if (value.equals(config)) {
 return (T) value;
 }
 }
 }

 // lock by config type
 //添加配置
 synchronized (configsMap) {
 return (T) addIfAbsent(config, configsMap);
 }
 }

ConfigManager配置管理器的addIfAbsent方法:

private <C extends AbstractConfig> C addIfAbsent(C config, Map<String, C> configsMap)
 throws IllegalStateException {
 //配置信息为空直接返回
 if (config == null || configsMap == null) {
 return config;
 }

 // find by value
 //根据配置规则判断,配置存在则返回
 Optional<C> prevConfig = findDuplicatedConfig(configsMap, config);
 if (prevConfig.isPresent()) {
 return prevConfig.get();
 }

 //生成配置key
 String key = config.getId();
 if (key == null) {
 do {
 // generate key if id is not set
 key = generateConfigId(config);
 } while (configsMap.containsKey(key));
 }

 //不相同的配置key重复则抛出异常
 C existedConfig = configsMap.get(key);
 if (existedConfig != null && !isEquals(existedConfig, config)) {
 String type = config.getClass().getSimpleName();
 logger.warn(String.format("Duplicate %s found, there already has one default %s or more than two %ss have the same id, " +
 "you can try to give each %s a different id, override previous config with later config. id: %s, prev: %s, later: %s",
 type, type, type, type, key, existedConfig, config));
 }

 // override existed config if any
 //将配置对象存入configsMap对象中,configsMap来源于configsCache
 configsMap.put(key, config);
 return config;
 }

原文： «Dubbo启动器DubboBootstrap添加应用程序的配置信息ApplicationConfig»

Blog: 8-Dubbo启动器DubboBootstrap借助双重校验锁的单例模式进行对象的初始化

Mon, 08 Aug 2022 00:00:00 +0000

8-Dubbo启动器DubboBootstrap借助双重校验锁的单例模式进行对象的初始化

8.1 启动器简介

在说启动器之前先把视野拉回第一章《1-从一个服务提供者的Demo说起》我们的Demo代码,下面只贴一下核心代码:

public class Application {
 public static void main(String[] args) throws Exception {
 startWithBootstrap();
 }
 private static void startWithBootstrap() {
 //前面的文章都在说这个服务配置对象的创建,中间又说了分层域模型,扩展加载机制
 ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
 //为服务配置下服务接口和服务实现,下面两行用来初始化对象就不详细说了
 service.setInterface(DemoService.class);
 service.setRef(new DemoServiceImpl());
 //这一个篇章主要说这里:
 DubboBootstrap bootstrap = DubboBootstrap.getInstance();
 bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
 .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
 .service(service)
 .start()
 .await();
 }
}

Dubbo3 往云原生的方向走自然要针对云原生应用的应用启动,应用运行,应用发布等信息做一些建模,这个DubboBootstrap就是用来启动Dubbo服务的.类似于Netty的Bootstrap类型和ServerBootstrap启动器

8.2 双重校验锁的单例模式创建启动器对象的

Dubbo的bootstrap类为啥要用单例模式:

通过调用静态方法getInstance()获取单例实例。之所以设计为单例，是因为Dubbo中的一些类（如ExtensionLoader）只为每个进程设计一个实例。

下面就来直接看代码吧,代码胜千言: 对象的调用代码如下:

DubboBootstrap bootstrap = DubboBootstrap.getInstance();

DubboBootstrap获取对象的getInstance()方法:

 public static DubboBootstrap getInstance() {
 //双重校验锁第一次判断空
 if (instance == null) {
 //为空都进行排队
 synchronized (DubboBootstrap.class) {
 //双重校验锁第二次判断空 上面为空的都排队了这里得判断下
 if (instance == null) {
 //调用重载方法获取对象
 instance = DubboBootstrap.getInstance(ApplicationModel.defaultModel());
 }
 }
 }
 return instance;
 }

DubboBootstrap获取对象重载的getInstance(ApplicationModel applicationModel)方法:

computeIfAbsent() 方法对 hashMap 中指定 key 的值进行重新计算，如果不存在这个 key，则添加到 hashMap 中。

instanceMap设计为Map<ApplicationModel, DubboBootstrap>类型 Key,意味着可以为多个应用程序模型创建不同的启动器,启动多个服务

 public static DubboBootstrap getInstance(ApplicationModel applicationModel) {
 return instanceMap.computeIfAbsent(applicationModel, _k -> new DubboBootstrap(applicationModel));
 }

8.3 DubboBootstrap的构造器代码

构造器代码是逻辑比较复杂的地方,我们先来看下代码

private DubboBootstrap(ApplicationModel applicationModel) {
 //存储应用程序启动模型
 this.applicationModel = applicationModel;
 //获取配置管理器ConfigManager: 配置管理器的扩展类型ApplicationExt ,扩展名字config
 configManager = applicationModel.getApplicationConfigManager();
 //获取环境信息Environment: 环境信息的扩展类型为ApplicationExt,扩展名字为environment
 environment = applicationModel.getModelEnvironment();
 //执行器存储仓库(线程池)ExecutorRepository: 扩展类型为ExecutorRepository,默认扩展扩展名字为default
 executorRepository = applicationModel.getExtensionLoader(ExecutorRepository.class).getDefaultExtension();
 //初始化并启动应用程序实例ApplicationDeployer,DefaultApplicationDeployer类型
 applicationDeployer = applicationModel.getDeployer();
 // listen deploy events
 //为发布器 设置生命周期回调
 applicationDeployer.addDeployListener(new DeployListenerAdapter<ApplicationModel>() {
 @Override
 public void onStarted(ApplicationModel scopeModel) {
 notifyStarted(applicationModel);
 }

 @Override
 public void onStopped(ApplicationModel scopeModel) {
 notifyStopped(applicationModel);
 }

 @Override
 public void onFailure(ApplicationModel scopeModel, Throwable cause) {
 notifyStopped(applicationModel);
 }
 });
 //将启动器对象注册到应用程序模型applicationModel的Bean工厂中
 // register DubboBootstrap bean
 applicationModel.getBeanFactory().registerBean(this);
 }

原文： «Dubbo启动器DubboBootstrap借助双重校验锁的单例模式进行对象的初始化»

Blog: 7-Dubbo的SPI扩展机制之自动激活扩展Activate源码解析

Sun, 07 Aug 2022 00:00:00 +0000

7-Dubbo的SPI扩展机制之自动激活扩展Activate源码解析

7.1 Activate扩展的说明

此注解对于使用给定条件自动激活某些扩展非常有用，例如：@Activate可用于在有多个实现时加载某些筛选器扩展。

group() 指定组条件。框架SPI定义了有效的组值。
value() 指定URL条件中的参数键。

SPI提供程序可以调用ExtensionLoader。getActivateExtension(URL、String、String)方法以查找具有给定条件的所有已激活扩展。

比如后面我们会说到的过滤器扩展对象的获取,如下通过调用getActivateExtension方法的代码:

 List<Filter> filters;
 filters = ScopeModelUtil.getExtensionLoader(Filter.class, moduleModels.get(0)).getActivateExtension(url, key, group);

7.2 获取自动激活扩展的源码

前面我们看了激活扩展是通过调用getActivateExtension方法来获取对象的,那接下来就来看下这个方法做了什么操作:

/**
* @param url 服务的url
* @param key 用于获取扩展点名称的url参数键 比如监听器:exporter.listener,过滤器:params-filter,telnet处理器:telnet
*/
 public List<T> getActivateExtension(URL url, String key) {
 return getActivateExtension(url, key, null);
 }

继续调用重载的方法

/**
 *
 *
 * @param url 服务的url
 * @param key 用于获取扩展点名称的url参数键 比如监听器:exporter.listener,过滤器:params-filter,telnet处理器:telnet
 * @param group group 用于筛选的分组,比如过滤器中使用此参数来区分消费者使用这个过滤器还是提供者使用这个过滤器他们的group参数分表为consumer,provider
 * @return 已激活的扩展列表。
 */
 public List<T> getActivateExtension(URL url, String key, String group) {
 //从参数中获取url指定的值
 String value = url.getParameter(key);
 //调用下个重载的方法
 return getActivateExtension(url, StringUtils.isEmpty(value) ? null : COMMA_SPLIT_PATTERN.split(value), group);
 }

上面的重载方法都是用来转换参数的,下面这个方法才是真正的逻辑

 /**
 * 获取激活扩展.
 *
 * @param url 服务的url
 * @param values 这个value是扩展点的名字 当指定了时候会使用指定的名字的扩展
 * @param group group 用于筛选的分组,比如过滤器中使用此参数来区分消费者使用这个过滤器还是提供者使用这个过滤器他们的group参数分表为consumer,provider
 * @return 获取激活扩展.
 */
 public List<T> getActivateExtension(URL url, String[] values, String group) {
 //检查扩展加载器是否被销毁了
 checkDestroyed();
 // solve the bug of using @SPI's wrapper method to report a null pointer exception.
 //创建个有序的Map集合,用来对扩展进行排序
 Map<Class<?>, T> activateExtensionsMap = new TreeMap<>(activateComparator);
 //初始化扩展名字,指定了扩展名字values不为空
 List<String> names = values == null ? new ArrayList<>(0) : asList(values);
 //扩展名字使用Set集合进行去重
 Set<String> namesSet = new HashSet<>(names);
 //参数常量是 -default 扩展名字是否不包含默认的
 if (!namesSet.contains(REMOVE_VALUE_PREFIX + DEFAULT_KEY)) {
 //第一次进来肯定是没有缓存对象双重校验锁检查下
 if (cachedActivateGroups.size() == 0) {
 synchronized (cachedActivateGroups) {
 // cache all extensions
 if (cachedActivateGroups.size() == 0) {
 //加载扩展类型对应的扩展类,这个具体细节参考源码或者《[Dubbo3.0.7源码解析系列]-5-Dubbo的SPI扩展机制与自适应扩展对象的创建与扩展文件的扫描源码解析》章节
 getExtensionClasses();
 for (Map.Entry<String, Object> entry : cachedActivates.entrySet()) {
 String name = entry.getKey();
 Object activate = entry.getValue();

 String[] activateGroup, activateValue;
 //遍历所有的activates列表获取group()和value()值
 if (activate instanceof Activate) {
 activateGroup = ((Activate) activate).group();
 activateValue = ((Activate) activate).value();
 } else if (activate instanceof com.alibaba.dubbo.common.extension.Activate) {
 activateGroup = ((com.alibaba.dubbo.common.extension.Activate) activate).group();
 activateValue = ((com.alibaba.dubbo.common.extension.Activate) activate).value();
 } else {
 continue;
 }
 //缓存分组值
 cachedActivateGroups.put(name, new HashSet<>(Arrays.asList(activateGroup)));
 String[][] keyPairs = new String[activateValue.length][];
 //遍历指定的激活扩展的扩展名字列表
 for (int i = 0; i < activateValue.length; i++) {
 if (activateValue[i].contains(":")) {
 keyPairs[i] = new String[2];
 String[] arr = activateValue[i].split(":");
 keyPairs[i][0] = arr[0];
 keyPairs[i][1] = arr[1];
 } else {
 keyPairs[i] = new String[1];
 keyPairs[i][0] = activateValue[i];
 }
 }
 //缓存指定扩展信息
 cachedActivateValues.put(name, keyPairs);
 }
 }
 }
 }

 // traverse all cached extensions
 //遍历所有激活的扩展名字和扩展分组集合
 cachedActivateGroups.forEach((name, activateGroup) -> {
 //筛选当前扩展的扩展分组与激活扩展的扩展分组是否可以匹配
 if (isMatchGroup(group, activateGroup)
 //不能是指定的扩展名字
 && !namesSet.contains(name)
 //也不能是带有 -指定扩展名字
 && !namesSet.contains(REMOVE_VALUE_PREFIX + name)
 //如果在Active注解中配置了value则当指定的键出现在URL的参数中时，激活当前扩展名。
 //如果未配置value属性则默认都是匹配的(cachedActivateValues中不存在对应扩展名字的缓存的时候默认为true)
 && isActive(cachedActivateValues.get(name), url)) {
 //缓存激活的扩展类型映射的扩展名字
 activateExtensionsMap.put(getExtensionClass(name), getExtension(name));
 }
 });
 }

 if (namesSet.contains(DEFAULT_KEY)) {
 // will affect order
 // `ext1,default,ext2` means ext1 will happens before all of the default extensions while ext2 will after them
 ArrayList<T> extensionsResult = new ArrayList<>(activateExtensionsMap.size() + names.size());
 for (int i = 0; i < names.size(); i++) {
 String name = names.get(i);
 if (!name.startsWith(REMOVE_VALUE_PREFIX)
 && !namesSet.contains(REMOVE_VALUE_PREFIX + name)) {
 if (!DEFAULT_KEY.equals(name)) {
 if (containsExtension(name)) {
 extensionsResult.add(getExtension(name));
 }
 } else {
 extensionsResult.addAll(activateExtensionsMap.values());
 }
 }
 }
 return extensionsResult;
 } else {
 // add extensions, will be sorted by its order
 for (int i = 0; i < names.size(); i++) {
 String name = names.get(i);
 if (!name.startsWith(REMOVE_VALUE_PREFIX)
 && !namesSet.contains(REMOVE_VALUE_PREFIX + name)) {
 if (!DEFAULT_KEY.equals(name)) {
 if (containsExtension(name)) {
 activateExtensionsMap.put(getExtensionClass(name), getExtension(name));
 }
 }
 }
 }
 return new ArrayList<>(activateExtensionsMap.values());
 }
 }

再来回顾下扫描扩展类型的时候,与激活扩展的相关扫描代码: 与激活注解关键的代码位置在这里ExtensionLoader的loadClass方法中我来贴下loadClass方法核心的代码:

if (clazz.isAnnotationPresent(Adaptive.class)) {
 cacheAdaptiveClass(clazz, overridden);
 } else if (isWrapperClass(clazz)) {
 cacheWrapperClass(clazz);
 } else {
 if (StringUtils.isEmpty(name)) {
 name = findAnnotationName(clazz);
 if (name.length() == 0) {
 throw new IllegalStateException("No such extension name for the class " + clazz.getName() + " in the config " + resourceURL);
 }
 }

 String[] names = NAME_SEPARATOR.split(name);
 if (ArrayUtils.isNotEmpty(names)) {
 //位置在这里其他地方就不标记注释了,前面判断了如果不是Adaptive也不是Wrapper类型则我们可以来判断是否为Activate 类型如果是的话调用cacheActivateClass方法将扩展缓存进cachedActivates缓存中
 cacheActivateClass(clazz, names[0]);
 for (String n : names) {
 cacheName(clazz, n);
 saveInExtensionClass(extensionClasses, clazz, n, overridden);
 }
 }
 }

private void cacheActivateClass(Class<?> clazz, String name) {
 Activate activate = clazz.getAnnotation(Activate.class);
 if (activate != null) {
 //注解存在则加入激活注解缓存
 cachedActivates.put(name, activate);
 } else {
 // support com.alibaba.dubbo.common.extension.Activate
 com.alibaba.dubbo.common.extension.Activate oldActivate = clazz.getAnnotation(com.alibaba.dubbo.common.extension.Activate.class);
 if (oldActivate != null) {
 cachedActivates.put(name, oldActivate);
 }
 }
 }

原文：《Dubbo的SPI扩展机制之自动激活扩展Activate源码解析》

Blog: 06-Dubbo的SPI扩展机制之普通扩展对象的创建与Wrapper机制的源码解析

Sat, 06 Aug 2022 00:00:00 +0000

6 Dubbo的SPI扩展机制之普通扩展对象的创建与Wrapper机制的源码解析

6.1 普通扩展对象的加载与创建

这里我们要分析的是ExtensionLoader类型的getExtension(String name)方法, 有了前面自适应扩展的铺垫,这里就更容易来看了getExtension是根据扩展名字获取具体扩展的通用方法,我们来根据某个类型来获取扩展的时候就是走的这里,比如在这个博客开头的介绍:

ApplicationModel中获取配置管理器对象

 configManager = (ConfigManager) this.getExtensionLoader(ApplicationExt.class)
 .getExtension(ConfigManager.NAME);

6.1.1 getExtension方法源码

先来看下getExtension方法的源码,根据扩展名字查询扩展对象


public T getExtension(String name) {
 //这里并不能看到什么,只多传了个参数wrap为true调用另外一个重载的方法
 T extension = getExtension(name, true);
 if (extension == null) {
 throw new IllegalArgumentException("Not find extension: " + name);
 }
 return extension;
 }

public T getExtension(String name, boolean wrap) {
 //检查扩展加载器是否已被销毁
 checkDestroyed();
 if (StringUtils.isEmpty(name)) {
 throw new IllegalArgumentException("Extension name == null");
 }
 //扩展名字为true则加载默认扩展
 if ("true".equals(name)) {
 return getDefaultExtension();
 }
 //非wrap类型则将缓存的扩展名字key加上_origin后缀
 //wrap是aop机制 俗称切面,这个origin在aop里面可以称为切点,下面的wrap扩展可以称为增强通知的类型,普通扩展和wrap扩展的扩展名字是一样的
 String cacheKey = name;
 if (!wrap) {
 cacheKey += "_origin";
 }
 //从cachedInstances缓存中查询
 final Holder<Object> holder = getOrCreateHolder(cacheKey);
 Object instance = holder.get();
 //缓存中不存在则创建扩展对象 双重校验锁
 if (instance == null) {
 synchronized (holder) {
 //双重校验锁的方式
 instance = holder.get();
 if (instance == null) {
 //创建扩展对象
 instance = createExtension(name, wrap);
 holder.set(instance);
 }
 }
 }
 return (T) instance;
 }

我们先来看一下默认扩展的加载代码:

public T getDefaultExtension() {
 //加载扩展类型对应的所有扩展SPI实现类型,在加载所有扩展实现类型的时候会缓存这个扩展的默认实现类型,将对象缓存在cachedDefaultName中
 getExtensionClasses();
 if (StringUtils.isBlank(cachedDefaultName) || "true".equals(cachedDefaultName)) {
 return null;
 }
 //再回到加载扩展的方法
 return getExtension(cachedDefaultName);
 }

创建扩展对象方法这个和自适应扩展的创建扩展类似 createExtension: 具体过程如下:

加载扩展类型:getExtensionClasses()
创建扩展对象:createExtensionInstance(clazz)
注入自适应扩展: injectExtension(instance);
wrap处理

private T createExtension(String name, boolean wrap) {
 //扩展的创建的第一步扫描所有jar中的扩展实现,这里扫描完之后获取对应扩展名字的扩展实现类型的Class对象
 Class<?> clazz = getExtensionClasses().get(name);
 //出现异常了 转换下异常信息 再抛出
 if (clazz == null || unacceptableExceptions.contains(name)) {
 throw findException(name);
 }
 try {
 //当前扩展对象是否已经创建过了则直接从缓存中获取
 T instance = (T) extensionInstances.get(clazz);
 if (instance == null) {
 //第一次获取缓存中肯定没有则创建扩展对象然后缓存起来
 //createExtensionInstance 这个是与自适应扩展对象创建对象的不同之处
 extensionInstances.putIfAbsent(clazz, createExtensionInstance(clazz));
 instance = (T) extensionInstances.get(clazz);
 instance = postProcessBeforeInitialization(instance, name);
 //注入扩展自适应方法,这个方法前面讲自适应扩展时候说了,注入自适应扩展方法的自适应扩展对象
 injectExtension(instance);
 instance = postProcessAfterInitialization(instance, name);
 }
 //是否开启了wrap
 //Dubbo通过Wrapper实现AOP的方法
 if (wrap) {
 //这个可以参考下Dubbo扩展的加载
 List<Class<?>> wrapperClassesList = new ArrayList<>();
 //wrap类型排序 这个wrap类型是如何来的呢,在前面扫描扩展类型的时候如果当前扩展类型不是Adaptive注解修饰的,并且当前类型type有个构造器参数是type自身的也是前面加载扩展类型时候说的装饰器模式 可以参考DubboProtocol的构造器
 if (cachedWrapperClasses != null) {
 wrapperClassesList.addAll(cachedWrapperClasses);
 //根据Wrapper注解的order值来进行排序值越小越在列表的前面
 wrapperClassesList.sort(WrapperComparator.COMPARATOR);
 //反转之后值越大就会在列表的前面
 Collections.reverse(wrapperClassesList);
 }
 //从缓存中查到了wrapper扩展则遍历这些wrapp扩展进行筛选
 if (CollectionUtils.isNotEmpty(wrapperClassesList)) {
 for (Class<?> wrapperClass : wrapperClassesList) {
 Wrapper wrapper = wrapperClass.getAnnotation(Wrapper.class);
 //需要包装的扩展名。当此数组为空时，默认值为匹配
 //看下当前扩展是否匹配这个wrap,如何判断呢?
 //wrapper注解不存在或者matches匹配,或者mismatches不包含当前扩展
 //如果匹配到了当前扩展对象是需要进行wrapp的就为当前扩展创建当前wrapper扩展对象进行包装
 boolean match = (wrapper == null) ||
 ((ArrayUtils.isEmpty(wrapper.matches()) || ArrayUtils.contains(wrapper.matches(), name)) &&
 !ArrayUtils.contains(wrapper.mismatches(), name));
 //这是扩展类型是匹配wrapp的则开始注入
 if (match) {
 //匹配到了就创建所有的wrapper类型的对象同时构造器参数设置为当前类型
 instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
 instance = postProcessAfterInitialization(instance, name);
 }
 }
 }
 }

 // Warning: After an instance of Lifecycle is wrapped by cachedWrapperClasses, it may not still be Lifecycle instance, this application may not invoke the lifecycle.initialize hook.
 //初始化扩展,如果当前扩展是Lifecycle类型则调用初始化方法
 initExtension(instance);
 return instance;
 } catch (Throwable t) {
 throw new IllegalStateException("Extension instance (name: " + name + ", class: " +
 type + ") couldn't be instantiated: " + t.getMessage(), t);
 }
 }

6.1.2 创建扩展对象

前面加载扩展类型在自适应扩展的时候已经说过了这里就不重复了,这里我们来看下扩展对象的创建过程:createExtensionInstance(clazz)

前面看自适应扩展对象创建的时候自适应扩展对象仅仅是使用反射newInstance了一个扩展对象,而普通的扩展类型创建对象的过程就相对复杂一点,接下来我们来看下:

ExtensionLoader的createExtensionInstance方法

private Object createExtensionInstance(Class<?> type) throws ReflectiveOperationException {
 //在ExtensionLoader构造器中,有个initInstantiationStrategy()方法中new了一个初始化策略InstantiationStrategy类型对象
 return instantiationStrategy.instantiate(type);
 }

InstantiationStrategy的实例化对象方法instantiate

public <T> T instantiate(Class<T> type) throws ReflectiveOperationException {

 // should not use default constructor directly, maybe also has another constructor matched scope model arguments
 // 1. try to get default constructor
 Constructor<T> defaultConstructor = null;
 try {
 //反射获取对应类型的无参构造器
 defaultConstructor = type.getConstructor();
 } catch (NoSuchMethodException e) {
 // ignore no default constructor
 }

 // 2. use matched constructor if found
 List<Constructor> matchedConstructors = new ArrayList<>();
 //获取所有构造器
 Constructor<?>[] declaredConstructors = type.getConstructors();
 //遍历构造器列表,
 for (Constructor<?> constructor : declaredConstructors) {
 //如果存在构造器则构造器参数类型是否为ScopeModel类型,如果为ScopeModel则为匹配的构造器 说明我们扩展类型在这个版本如果想要让这个构造器生效必须参数类型为ScopeModel
 if (isMatched(constructor)) {
 matchedConstructors.add(constructor);
 }
 }
 // remove default constructor from matchedConstructors
 if (defaultConstructor != null) {
 matchedConstructors.remove(defaultConstructor);
 }

 // match order:
 // 1. the only matched constructor with parameters
 // 2. default constructor if absent

 Constructor targetConstructor;
 //匹配的参数ScopeModel的构造器太多了就抛出异常
 if (matchedConstructors.size() > 1) {
 throw new IllegalArgumentException("Expect only one but found " +
 matchedConstructors.size() + " matched constructors for type: " + type.getName() +
 ", matched constructors: " + matchedConstructors);
 } else if (matchedConstructors.size() == 1) {
 //一个参数一般为一个参数类型ScopeModel的构造器
 targetConstructor = matchedConstructors.get(0);
 } else if (defaultConstructor != null) {
 //如果没有自定义构造器则使用空参数构造器
 targetConstructor = defaultConstructor;
 } else {
 //一个构造器也没匹配上也要报错
 throw new IllegalArgumentException("None matched constructor was found for type: " + type.getName());
 }

 // create instance with arguments
 //反射获取构造器参数的参数类型列表
 Class[] parameterTypes = targetConstructor.getParameterTypes();
 //如果存在参数则为参数设置值
 Object[] args = new Object[parameterTypes.length];
 for (int i = 0; i < parameterTypes.length; i++) {
 //借助scopeModelAccessor工具获取参数类型,这个参数类型为当前的域模型对象
 args[i] = getArgumentValueForType(parameterTypes[i]);
 }
 //创建扩展对象
 return (T) targetConstructor.newInstance(args);
 }

6.2 wrap机制

6.2.1 Wrapper机制说明

Dubbo通过Wrapper实现AOP的方法

Wrapper机制，即扩展点自动包装。Wrapper 类同样实现了扩展点接口，但是 Wrapper 不是扩展点的真正实现。它的用途主要是用于从 ExtensionLoader 返回扩展点时，包装在真正的扩展点实现外。即从 ExtensionLoader 中返回的实际上是 Wrapper 类的实例，Wrapper 持有了实际的扩展点实现类。扩展点的 Wrapper 类可以有多个，也可以根据需要新增。通过 Wrapper 类可以把所有扩展点公共逻辑移至 Wrapper 中。新加的 Wrapper 在所有的扩展点上添加了逻辑，有些类似 AOP，即 Wrapper 代理了扩展点。

Wrapper的规范 Wrapper 机制不是通过注解实现的，而是通过一套 Wrapper 规范实现的。 Wrapper 类在定义时需要遵循如下规范。

该类要实现 SPI 接口
该类中要有 SPI 接口的引用
该类中必须含有一个含参的构造方法且参数只能有一个类型为SPI接口
在接口实现方法中要调用 SPI 接口引用对象的相应方法
该类名称以 Wrapper 结尾

比如如下几个扩展类型

 class org.apache.dubbo.rpc.protocol.ProtocolListenerWrapper
 class org.apache.dubbo.qos.protocol.QosProtocolWrapper
 class org.apache.dubbo.rpc.protocol.ProtocolListenerWrapper
 class org.apache.dubbo.qos.protocol.QosProtocolWrapper

回顾下Wrapper扩展类型的扫描于对象的创建

6.2.2 Wrapper类型的扫描

Wrapper类型的扫描代码如下:

来自4.5.2.3小节ExtensionLoader类型中的loadClass方法

 //扩展子类型是否存在这个注解@Adaptive
 if (clazz.isAnnotationPresent(Adaptive.class)) {
 cacheAdaptiveClass(clazz, overridden);
 } else if (isWrapperClass(clazz)) {
 //扩展子类型构造器中是否有这个类型的接口 (这个可以想象下我们了解的Java IO流中的类型使用到的装饰器模式 构造器传个类型)
 cacheWrapperClass(clazz);
 } else {

isWrapperClass方法通过判断构造器类型是否为当前类型来判断是否为Wrapper类型

 private boolean isWrapperClass(Class<?> clazz) {
 try {
 clazz.getConstructor(type);
 return true;
 } catch (NoSuchMethodException e) {
 return false;
 }
 }

6.2.3 Wrapper类型的创建

这个可以看下4.6.1 getExtension方法源码的获取扩展对象时候查询扩展对象是否有对应的Wrapper类型的扩展为其创建Wrapper扩展对象,如下代码

//Dubbo通过Wrapper实现AOP的方法
 if (wrap) {
 //这个可以参考下Dubbo扩展的加载
 List<Class<?>> wrapperClassesList = new ArrayList<>();
 //wrap类型排序 这个wrap类型是如何来的呢,在前面扫描扩展类型的时候如果当前扩展类型不是Adaptive注解修饰的,并且当前类型type有个构造器参数是type自身的也是前面加载扩展类型时候说的装饰器模式 可以参考DubboProtocol的构造器
 if (cachedWrapperClasses != null) {
 wrapperClassesList.addAll(cachedWrapperClasses);
 //根据Wrapper注解的order值来进行排序值越小越在列表的前面
 wrapperClassesList.sort(WrapperComparator.COMPARATOR);
 //反转之后值越大就会在列表的前面
 Collections.reverse(wrapperClassesList);
 }
 //从缓存中查到了wrapper扩展则遍历这些wrapp扩展进行筛选
 if (CollectionUtils.isNotEmpty(wrapperClassesList)) {
 for (Class<?> wrapperClass : wrapperClassesList) {
 Wrapper wrapper = wrapperClass.getAnnotation(Wrapper.class);
 //需要包装的扩展名。当此数组为空时，默认值为匹配
 //看下当前扩展是否匹配这个wrap,如何判断呢?
 //wrapper注解不存在或者matches匹配,或者mismatches不包含当前扩展
 //如果匹配到了当前扩展对象是需要进行wrapp的就为当前扩展创建当前wrapper扩展对象进行包装
 boolean match = (wrapper == null) ||
 ((ArrayUtils.isEmpty(wrapper.matches()) || ArrayUtils.contains(wrapper.matches(), name)) &&
 !ArrayUtils.contains(wrapper.mismatches(), name));
 //这是扩展类型是匹配wrapp的则开始注入
 if (match) {
 //匹配到了就创建所有的wrapper类型的对象同时构造器参数设置为当前类型
 instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
 instance = postProcessAfterInitialization(instance, name);
 }
 }
 }
 }

主要来看下什么情况下才为当前扩展类型创建Wrapper包装类型:

wrapper注解不存在(前面判断过Wrapper类型是构造器满足条件的)
存在Wrapper注解:
- matches匹配,
- 或者mismatches不包含当前扩展

如果匹配到了当前扩展对象是需要进行wrapp的就为当前扩展创建当前wrapper扩展对象进行包装

原文：《Dubbo的SPI扩展机制之普通扩展对象的创建与Wrapper机制的源码解析》

Blog: 05-自适应扩展对象的创建getAdaptiveExtension方法

Fri, 05 Aug 2022 00:00:00 +0000

5 自适应扩展对象的创建getAdaptiveExtension方法

自适应扩展又称为动态扩展,可以在运行时生成扩展对象

ExtensionLoader中的getAdaptiveExtension()方法,这个方法也是我们看到的第一个获取扩展对象的方法. ,这个方法可以帮助我们通过SPI机制从扩展文件中找到需要的扩展类型并创建它的对象, 自适应扩展:如果对设计模式比较了解的可能会联想到适配器模式,自适应扩展其实就是适配器模式的思路,自适应扩展有两种策略:

一种是我们自己实现自适应扩展:然后使用@Adaptive修饰这个时候适配器的逻辑由我们自己实现,当扩展加载器去查找具体的扩展的时候可以通过找到我们这个对应的适配器扩展,然后适配器扩展帮忙去查询真正的扩展,这个比如我们下面要举的扩展注入器的例子,具体扩展通过扩展注入器适配器,注入器适配器来查询具体的注入器扩展实现来帮忙查找扩展。
还有一种方式是我们未实现这个自适应扩展,Dubbo在运行时通过字节码动态代理的方式在运行时生成一个适配器,使用这个适配器映射到具体的扩展. 第二种情况往往用在比如 Protocol、Cluster、LoadBalance 等。有时，有些拓展并不想在框架启动阶段被加载，而是希望在拓展方法被调用时，根据运行时参数进行加载。(如果还不了解可以考虑看下@Adaptive注解加载方法上面的时候扩展是如何加载的)

 public T getAdaptiveExtension() {
 //检查当前扩展加载器是否已经被销毁
 checkDestroyed();
 //从自适应扩展缓存中查询扩展对象如果存在就直接返回,这个自适应扩展类型只会有一个扩展实现类型如果是多个的话根据是否可以覆盖参数决定扩展实现类是否可以相互覆盖
 Object instance = cachedAdaptiveInstance.get();
 //这个if判断不太优雅 容易多层嵌套,上面instance不为空就可以直接返回了
 if (instance == null) {
 //创建异常则抛出异常直接返回(多线程场景下可能第一个线程异常了第二个线程进来之后走到这里)
 if (createAdaptiveInstanceError != null) {
 throw new IllegalStateException("Failed to create adaptive instance: " +
 createAdaptiveInstanceError.toString(),
 createAdaptiveInstanceError);
 }
 //加锁排队 (单例模式创建对象的思想 双重校验锁)
 synchronized (cachedAdaptiveInstance) {
 //加锁的时候对象都是空的,进来之后先判断下防止重复创建
 instance = cachedAdaptiveInstance.get();
 //只有第一个进来锁的对象为空开始创建扩展对象
 if (instance == null) {
 try {
 //根据SPI机制获取类型,创建对象
 instance = createAdaptiveExtension();
 //存入缓存
 cachedAdaptiveInstance.set(instance);
 } catch (Throwable t) {
 createAdaptiveInstanceError = t;
 throw new IllegalStateException("Failed to create adaptive instance: " + t.toString(), t);
 }
 }
 }
 }

 return (T) instance;
 }

前面使用单例思想来调用创建自适应扩展对象的方法,下面就让我们深入探究下创建自适应扩展对象的整个过程createAdaptiveExtension();方法:

5.1 创建扩展对象的生命周期方法-注意这个后续会详细解析这个声明周期方法的细节

createAdaptiveExtension() 我们先来看ExtensionLoader类型中的createAdaptiveExtension();方法,这个方法包含了扩展对象创建初始化的整个生命周期,如下代码所示:

private T createAdaptiveExtension() {
 try {
 //获取扩展类型实现类, 创建扩展对象
 T instance = (T) getAdaptiveExtensionClass().newInstance();
 //注入扩展对象之前的回调方法
 instance = postProcessBeforeInitialization(instance, null);
 //注入扩展对象
 instance = injectExtension(instance);
 //注入扩展对象之后的回调方法
 instance = postProcessAfterInitialization(instance, null);
 //初始化扩展对象的属性,如果当前扩展实例的类型实现了Lifecycle则调用当前扩展对象的生命周期回调方法initialize()(来自Lifecycle接口)
 //参考样例第一个instance为ExtensionInjector的自适应扩展对象类型为AdaptiveExtensionInjector,自适应扩展注入器(适配器)用来查询具体支持的扩展注入器比如scope,spi,spring注入器
 initExtension(instance);
 return instance;
 } catch (Exception e) {
 throw new IllegalStateException("Can't create adaptive extension " + type + ", cause: " + e.getMessage(), e);
 }
 }

5.2 SPI机制获取扩展对象实现类型getAdaptiveExtensionClass()

这个方法可以帮助我们了解具体的Dubbo SPI机制如果找到扩展类型的实现类,会寻找哪些文件,扩展文件的优先级又是什么,对我们自己写扩展方法很有帮助,接下来我们就来看下它的源码:

 private Class<?> getAdaptiveExtensionClass() {
 //获取扩展类型,将扩展类型存入成员变量cachedClasses中进行缓存
 getExtensionClasses();
 //在上个方法的详细解析中的最后一步loadClass方法中如果扩展类型存在Adaptive注解将会将扩展类型赋值给cachedAdaptiveClass,否则的话会把扩展类型都缓存起来存储在扩展集合extensionClasses中
 if (cachedAdaptiveClass != null) {
 return cachedAdaptiveClass;
 }
 //扩展实现类型没有一个这个自适应注解Adaptive时候会走到这里
 //刚刚我们扫描到了扩展类型然后将其存入cachedClasses集合中了 接下来我们看下如何创建扩展类型
 return cachedAdaptiveClass = createAdaptiveExtensionClass();
 }

继续看获取扩展类型的方法getExtensionClasses():

 private Map<String, Class<?>> getExtensionClasses() {
 //缓存中查询扩展类型是否存在
 Map<String, Class<?>> classes = cachedClasses.get();
 if (classes == null) {
 //单例模式双重校验锁判断
 synchronized (cachedClasses) {
 classes = cachedClasses.get();
 if (classes == null) {
 //加载扩展类型
 classes = loadExtensionClasses();
 //将我们扫描到的扩展类型存入成员变量cachedClasses中
 cachedClasses.set(classes);
 }
 }
 }
 return classes;
 }

5.2.1 使用不同的的策略加载加载不同目录下的扩展

加载扩展类型的方法loadExtensionClasses()

 private Map<String, Class<?>> loadExtensionClasses() {
 //检查扩展加载器是否被销毁
 checkDestroyed();
 //缓存默认的扩展名到成员变量cachedDefaultName中
 cacheDefaultExtensionName();
 //加载到的扩展集合
 Map<String, Class<?>> extensionClasses = new HashMap<>();
 //扩展策略,在4.3章节中我们介绍了这个类型的UML与说明
 //LoadingStrategy扩展加载策略,目前有3个扩展加载策略
 //DubboInternalLoadingStrategy:Dubbo内置的扩展加载策略,将加载文件目录为META-INF/dubbo/internal/的扩展
 //DubboLoadingStrategy:Dubbo普通的扩展加载策略,将加载目录为META-INF/dubbo/的扩展
 //ServicesLoadingStrategy:JAVA SPI加载策略 ,将加载目录为META-INF/services/的扩展
 //扩展策略集合对象在什么时候初始化的呢在成员变量初始化的时候就创建了集合对象,这个可以看方法loadLoadingStrategies() 通过Java的 SPI加载策略
 for (LoadingStrategy strategy : strategies) {
 //根据策略从指定文件目录中加载扩展类型
 loadDirectory(extensionClasses, strategy, type.getName());

 // compatible with old ExtensionFactory
 //如果当前要加载的扩展类型是扩展注入类型则扫描下ExtensionFactory类型的扩展
 if (this.type == ExtensionInjector.class) {
 //这个方法和上面那个方法是一样的就不详细说了 扫描文件 找到扩展类型
 loadDirectory(extensionClasses, strategy, ExtensionFactory.class.getName());
 }
 }
 //通过loadDirectory扫描 扫描到了ExtensionInjector类型的扩展实现类有3个 我们将会得到这样一个集合例子:
 //"spring" -> "class org.apache.dubbo.config.spring.extension.SpringExtensionInjector"
 //"scopeBean" -> "class org.apache.dubbo.common.beans.ScopeBeanExtensionInjector"
 //"spi" -> "class org.apache.dubbo.common.extension.inject.SpiExtensionInjector"
 return extensionClasses;
 }

从文件中加载扩展实现loadDirectory方法:

 private void loadDirectory(Map<String, Class<?>> extensionClasses, LoadingStrategy strategy, String type) {
 //加载并根据策略的参数来加载
 loadDirectory(extensionClasses, strategy.directory(), type, strategy.preferExtensionClassLoader(),
 strategy.overridden(), strategy.includedPackages(), strategy.excludedPackages(), strategy.onlyExtensionClassLoaderPackages());
 //下面两行就是要兼容alibaba的扩展包了
 String oldType = type.replace("org.apache", "com.alibaba");
 loadDirectory(extensionClasses, strategy.directory(), oldType, strategy.preferExtensionClassLoader(),
 strategy.overridden(), strategy.includedPackagesInCompatibleType(), strategy.excludedPackages(), strategy.onlyExtensionClassLoaderPackages());
 }

带扩展策略参数的loadDirectory方法

关于扩展策略的参数列表我这里列个表格方便大家来看

扩展类型	dir(目录)	extensionLoaderClassLoaderFirst(优先扩展类型的类加载器)	overridden(是否允许覆盖同名扩展)	includedPackages (明确包含的扩展包)	excludedPackages (明确排除的扩展包)	onlyExtensionClassLoaderPackages(限制应该从Dubbo的类加载器加载的类)
DubboInternalLoadingStrategy	META-INF/dubbo/internal/	false	false	null	null	[]
DubboLoadingStrategy	META-INF/dubbo/	false	true	null	null	[]
ServicesLoadingStrategy	META-INF/services/	false	true	null	null	[]

 /**
 * 不同的扩展策略传递了不同的参数,但是扩展的加载流程是相同的,这里我们可以参考上面表格
 * @param extensionClasses
 * @param dir
 * @param type 这里我们参考的示例这个值为org.apache.dubbo.common.extension.ExtensionInjector
 * @param extensionLoaderClassLoaderFirst
 * @param overridden false
 * @param includedPackages
 * @param excludedPackages
 * @param onlyExtensionClassLoaderPackages
 */
private void loadDirectory(Map<String, Class<?>> extensionClasses, String dir, String type,
 boolean extensionLoaderClassLoaderFirst, boolean overridden, String[] includedPackages,
 String[] excludedPackages, String[] onlyExtensionClassLoaderPackages) {
 //扩展目录 + 扩展类型全路径 比如: META-INF/dubbo/internal/org.apache.dubbo.common.extension.ExtensionInjector
 String fileName = dir + type;
 try {
 List<ClassLoader> classLoadersToLoad = new LinkedList<>();

 // try to load from ExtensionLoader's ClassLoader first
 //是否优先使用扩展加载器的 类加载器
 if (extensionLoaderClassLoaderFirst) {
 ClassLoader extensionLoaderClassLoader = ExtensionLoader.class.getClassLoader();
 if (ClassLoader.getSystemClassLoader() != extensionLoaderClassLoader) {
 classLoadersToLoad.add(extensionLoaderClassLoader);
 }
 }

 // load from scope model
 //获取域模型对象的类型加载器 ,这个域模型对象在初始化的时候会将自己的类加载器放入集合中可以参考《3.2.2 初始化ScopeModel》章节
 Set<ClassLoader> classLoaders = scopeModel.getClassLoaders();

 //没有可用的类加载器则从使用
 if (CollectionUtils.isEmpty(classLoaders)) {
 //从用于加载类的搜索路径中查找指定名称的所有资源。
 Enumeration<java.net.URL> resources = ClassLoader.getSystemResources(fileName);
 if (resources != null) {
 while (resources.hasMoreElements()) {
 loadResource(extensionClasses, null, resources.nextElement(), overridden, includedPackages, excludedPackages, onlyExtensionClassLoaderPackages);
 }
 }
 } else {
 classLoadersToLoad.addAll(classLoaders);
 }
 //使用类加载资源加载器(ClassLoaderResourceLoader)来加载具体的资源
 Map<ClassLoader, Set<java.net.URL>> resources = ClassLoaderResourceLoader.loadResources(fileName, classLoadersToLoad);
 //遍历从所有资源文件中读取到资源url地址,key为类加载器,值为扩展文件url如夏所示
 //jar:file:/Users/song/.m2/repository/org/apache/dubbo/dubbo/3.0.7/dubbo-3.0.7.jar!/META-INF/dubbo/internal/org.apache.dubbo.common.extension.ExtensionInjector
 resources.forEach(((classLoader, urls) -> {
 //从文件中加载完资源之后开始根据类加载器和url加载具体的扩展类型,最后将扩展存放进extensionClasses集合
 loadFromClass(extensionClasses, overridden, urls, classLoader, includedPackages, excludedPackages, onlyExtensionClassLoaderPackages);
 }));
 } catch (Throwable t) {
 logger.error("Exception occurred when loading extension class (interface: " +
 type + ", description file: " + fileName + ").", t);
 }
 }

5.2.2 借助类加载器的getResources方法遍历所有文件进行扩展文件的查询

查找扩展类型对应的扩展文件的url方法:ClassLoaderResourceLoader类型的loadResources源码:

public static Map<ClassLoader, Set<URL>> loadResources(String fileName, List<ClassLoader> classLoaders) {
 //
 Map<ClassLoader, Set<URL>> resources = new ConcurrentHashMap<>();
 //不同的类加载器之间使用不同的线程异步的方式进行扫描
 CountDownLatch countDownLatch = new CountDownLatch(classLoaders.size());
 for (ClassLoader classLoader : classLoaders) {
 //多线程扫描,这个是个newCachedThreadPool的类型的线程池
 GlobalResourcesRepository.getGlobalExecutorService().submit(() -> {
 //
 resources.put(classLoader, loadResources(fileName, classLoader));
 countDownLatch.countDown();
 });
 }
 try {
 countDownLatch.await();
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 return Collections.unmodifiableMap(new LinkedHashMap<>(resources));
 }

加载具体类加载器中的资源文件的loadResources方法

public static Set<URL> loadResources(String fileName, ClassLoader currentClassLoader) {
 Map<ClassLoader, Map<String, Set<URL>>> classLoaderCache;
 //第一次进来类加载器资源缓存是空的
 if (classLoaderResourcesCache == null || (classLoaderCache = classLoaderResourcesCache.get()) == null) {
 //类对象锁
 synchronized (ClassLoaderResourceLoader.class) {
 if (classLoaderResourcesCache == null || (classLoaderCache = classLoaderResourcesCache.get()) == null) {
 classLoaderCache = new ConcurrentHashMap<>();
 //创建一个类资源映射url的软引用缓存对象
 //软引用(soft references)，用于帮助垃圾收集器管理内存使用和消除潜在的内存泄漏。当内存快要不足的时候，GC会迅速的把所有的软引用清除掉，释放内存空间
 classLoaderResourcesCache = new SoftReference<>(classLoaderCache);
 }
 }
 }
 //第一次进来时候类加载器url映射缓存是空的,给类加载器缓存对象新增一个值,key是类加载器,值是map类型用来存储文件名对应的url集合
 if (!classLoaderCache.containsKey(currentClassLoader)) {
 classLoaderCache.putIfAbsent(currentClassLoader, new ConcurrentHashMap<>());
 }

 Map<String, Set<URL>> urlCache = classLoaderCache.get(currentClassLoader);
 //缓存中没有就从文件里面找
 if (!urlCache.containsKey(fileName)) {
 Set<URL> set = new LinkedHashSet<>();
 Enumeration<URL> urls;
 try {
 //getResources这个方法是这样的:加载当前类加载器以及父类加载器所在路径的资源文件,将遇到的所有资源文件全部返回！这个可以理解为使用双亲委派模型中的类加载器 加载各个位置的资源文件
 urls = currentClassLoader.getResources(fileName);
 //native配置 是否为本地镜像(k可以参考官方文档:https://dubbo.apache.org/zh/docs/references/graalvm/support-graalvm/
 boolean isNative = NativeUtils.isNative();
 if (urls != null) {
 //遍历找到的对应扩展的文件url将其加入集合
 while (urls.hasMoreElements()) {
 URL url = urls.nextElement();
 if (isNative) {
 //In native mode, the address of each URL is the same instead of different paths, so it is necessary to set the ref to make it different
 //动态修改jdk底层url对象的ref变量为可访问,让我们在用反射时访问私有变量
 setRef(url);
 }
 set.add(url);
 }
 }
 } catch (IOException e) {
 e.printStackTrace();
 }
 //存入缓存
 urlCache.put(fileName, set);
 }
 //返回结果
 return urlCache.get(fileName);
 }

5.2.3 使用找到的扩展资源url加载具体扩展类型到内存

ExtensionLoader类型中的loadFromClass方法遍历url 开始加载扩展类型

 private void loadFromClass(Map<String, Class<?>> extensionClasses, boolean overridden, Set<java.net.URL> urls, ClassLoader classLoader,
 String[] includedPackages, String[] excludedPackages, String[] onlyExtensionClassLoaderPackages) {
 if (CollectionUtils.isNotEmpty(urls)) {
 for (java.net.URL url : urls) {
 loadResource(extensionClasses, classLoader, url, overridden, includedPackages, excludedPackages, onlyExtensionClassLoaderPackages);
 }
 }
 }

ExtensionLoader类型中的loadResource方法使用IO流读取扩展文件的内容读取内容之前我这里先贴一下我们参考的扩展注入类型的文件中的内容如下所示:

adaptive=org.apache.dubbo.common.extension.inject.AdaptiveExtensionInjector
spi=org.apache.dubbo.common.extension.inject.SpiExtensionInjector
scopeBean=org.apache.dubbo.common.beans.ScopeBeanExtensionInjector

扩展中的文件都是一行一行的,并且扩展名字和扩展类型之间使用等号隔开= 了解了文件内容之后应该下面的代码大致思路就知道了,我们可以详细看下

private void loadResource(Map<String, Class<?>> extensionClasses, ClassLoader classLoader,
 java.net.URL resourceURL, boolean overridden, String[] includedPackages, String[] excludedPackages, String[] onlyExtensionClassLoaderPackages) {
 try {
 //这里固定了文件的格式为utf8
 try (BufferedReader reader = new BufferedReader(new InputStreamReader(resourceURL.openStream(), StandardCharsets.UTF_8))) {
 String line;
 String clazz;
 //按行读取 例如读取到的内容:spring=org.apache.dubbo.config.spring.extension.SpringExtensionInjector
 while ((line = reader.readLine()) != null) {
 //不知道为何会有这么一行代码删除#之后的字符串
 final int ci = line.indexOf('#');
 if (ci >= 0) {
 line = line.substring(0, ci);
 }
 line = line.trim();
 //
 if (line.length() > 0) {
 try {
 String name = null;
 //扩展文件可能如上面我贴的那样 名字和类型等号隔开,也可能是无类型的,例如扩展加载策略使用的是JDK自带的方式services内容中只包含具体的扩展类型
 int i = line.indexOf('=');
 if (i > 0) {
 name = line.substring(0, i).trim();
 clazz = line.substring(i + 1).trim();
 } else {
 clazz = line;
 }
 //isExcluded是否为加载策略要排除的配置,参数这里为空代表全部类型不排除
 //isIncluded是否为加载策略包含的类型,参数这里为空代表全部文件皆可包含
 //onlyExtensionClassLoaderPackages参数是否只有扩展类的类加载器可以加载扩展,其他扩展类型的类加载器不能加载扩展 这里结果为false 不排除任何类加载器
 if (StringUtils.isNotEmpty(clazz) && !isExcluded(clazz, excludedPackages) && isIncluded(clazz, includedPackages)
 && !isExcludedByClassLoader(clazz, classLoader, onlyExtensionClassLoaderPackages)) {
 //根据类全路径加载类到内存
 loadClass(extensionClasses, resourceURL, Class.forName(clazz, true, classLoader), name, overridden);
 }
 } catch (Throwable t) {
 IllegalStateException e = new IllegalStateException("Failed to load extension class (interface: " + type +
 ", class line: " + line + ") in " + resourceURL + ", cause: " + t.getMessage(), t);
 exceptions.put(line, e);
 }
 }
 }
 }
 } catch (Throwable t) {
 logger.error("Exception occurred when loading extension class (interface: " +
 type + ", class file: " + resourceURL + ") in " + resourceURL, t);
 }
 }

ExtensionLoader类型中的loadClass方法加载具体的类到内存

private void loadClass(Map<String, Class<?>> extensionClasses, java.net.URL resourceURL, Class<?> clazz, String name,
 boolean overridden) throws NoSuchMethodException {
 //当前clazz是否为type的子类型
 //这里第一次访问到的type是ExtensionInjector,clazz是SpringExtensionInjector 父子类型关系满足情况
 if (!type.isAssignableFrom(clazz)) {
 throw new IllegalStateException("Error occurred when loading extension class (interface: " +
 type + ", class line: " + clazz.getName() + "), class "
 + clazz.getName() + " is not subtype of interface.");
 }
 //扩展子类型是否存在这个注解@Adaptive
 if (clazz.isAnnotationPresent(Adaptive.class)) {
 cacheAdaptiveClass(clazz, overridden);
 } else if (isWrapperClass(clazz)) {
 //扩展子类型构造器中是否有这个类型的接口 (这个可以想象下我们了解的Java IO流中的类型使用到的装饰器模式 构造器传个类型)
 cacheWrapperClass(clazz);
 } else {
 //无自适应注解,也没有构造器是扩展类型参数 ,这个name我们在扩展文件中找到了就是等号前面那个
 if (StringUtils.isEmpty(name)) {
 //低版本中可以使用@Extension 扩展注解来标注扩展类型,这里获取注解有两个渠道:
 //先查询@Extension注解是否存在如果存在则取value值,如果不存在@Extension注解则获取当前类型的名字
 name = findAnnotationName(clazz);
 if (name.length() == 0) {
 throw new IllegalStateException("No such extension name for the class " + clazz.getName() + " in the config " + resourceURL);
 }
 }
 //获取扩展名字数组,扩展名字可能为逗号隔开的
 String[] names = NAME_SEPARATOR.split(name);
 if (ArrayUtils.isNotEmpty(names)) {
 //@Activate注解修饰的扩展
 cacheActivateClass(clazz, names[0]);
 for (String n : names) {
 //cachedNames缓存集合缓存当前扩展类型的扩展名字
 cacheName(clazz, n);
 //将扩展类型加入结果集合extensionClasses中,不允许覆盖的话出现同同名字扩展将抛出异常
 saveInExtensionClass(extensionClasses, clazz, n, overridden);
 }
 }
 }
 }

ExtensionLoader类型中cacheAdaptiveClass Adaptive 机制，即扩展类的自适应机制。即其可以指定想要加载的扩展名，也可以不指定。若不指定，则直接加载默认的扩展类。即其会自动匹配，做到自适应。其是通过@Adaptive注解实现的。自适应注解修饰的扩展同一个扩展名字只能有一个扩展实现类型, 扩展策略中提供的参数overridden是否允许覆盖扩展覆盖

private void cacheAdaptiveClass(Class<?> clazz, boolean overridden) {
 if (cachedAdaptiveClass == null || overridden) {
 //成员变量存储这个自适应扩展类型
 cachedAdaptiveClass = clazz;
 } else if (!cachedAdaptiveClass.equals(clazz)) {
 throw new IllegalStateException("More than 1 adaptive class found: "
 + cachedAdaptiveClass.getName()
 + ", " + clazz.getName());
 }
 }

ExtensionLoader类型中cacheWrapperClass Wrapper 机制，即扩展类的包装机制。就是对扩展类中的 SPI 接口方法进行增强，进行包装，是 AOP 思想的体现，是 Wrapper 设计模式的应用。一个 SPI 可以包含多个 Wrapper。这个也是可以同一个类型多个

private void cacheWrapperClass(Class<?> clazz) {
 if (cachedWrapperClasses == null) {
 cachedWrapperClasses = new ConcurrentHashSet<>();
 }
 //缓存这个Wrapper类型的扩展
 cachedWrapperClasses.add(clazz);
 }

ExtensionLoader类型中cacheActivateClass Activate用于激活扩展类的。这个扩展类型可以出现多个比如过滤器可以同一个扩展名字多个过滤器实现,所以不需要有override判断 Activate 机制，即扩展类的激活机制。通过指定的条件来激活当前的扩展类。其是通过@Activate 注解实现的。

private void cacheActivateClass(Class<?> clazz, String name) {
 Activate activate = clazz.getAnnotation(Activate.class);
 if (activate != null) {
 //缓存Activate类型的扩展
 cachedActivates.put(name, activate);
 } else {
 // support com.alibaba.dubbo.common.extension.Activate
 com.alibaba.dubbo.common.extension.Activate oldActivate = clazz.getAnnotation(com.alibaba.dubbo.common.extension.Activate.class);
 if (oldActivate != null) {
 cachedActivates.put(name, oldActivate);
 }
 }
 }

ExtensionLoader类型中的saveInExtensionClass方法

上面扩展对象加载了这么多最终的目的就是将这个扩展类型存放进结果集合extensionClasses中,扩展策略中提供的参数overridden是否允许覆盖扩展覆盖

private void saveInExtensionClass(Map<String, Class<?>> extensionClasses, Class<?> clazz, String name, boolean overridden) {
 Class<?> c = extensionClasses.get(name);
 if (c == null || overridden) {
 //上面扩展对象加载了这么多最终的目的就是将这个扩展类型存放进结果集合中
 extensionClasses.put(name, clazz);
 } else if (c != clazz) {
 // duplicate implementation is unacceptable
 unacceptableExceptions.add(name);
 String duplicateMsg = "Duplicate extension " + type.getName() + " name " + name + " on " + c.getName() + " and " + clazz.getName();
 logger.error(duplicateMsg);
 throw new IllegalStateException(duplicateMsg);
 }
 }

5.3 自适应扩展代理对象的代码生成与编译

5.3.1 自适应扩展对象的创建

Dubbo 的自适应扩展机制中如果 自己生成了自适应扩展的代理类

Dubbo 的自适应扩展为了做什么：在运行时动态调用扩展方法。以及怎么做的：生成扩展代理类。比如: 代理类中根据 URL 获取扩展名，使用 SPI 加载扩展类，并调用同名方法，返回执行结果。

看了上一个章节,我们了解到了Dubbo是如何通过扫描目录来查询扩展实现类的这一次我们看下扩展类我们找到了之后,如果这个扩展类型未加上这个@Adaptive注解那么是如何创建这个类型的,接下来看createAdaptiveExtensionClass方法,这个方法是借助字节码工具来动态生成所需要的扩展类型的包装类型的代码,这个代码在编译时我们可能看不到,但是在Debug的时候,我们还是可以看到这个对象名字的,但是往往Debug的时候又进不到具体的代码位置,这里可以注意下

当扩展点的方法被@Adaptive修饰时，在Dubbo初始化扩展点时会自动生成和编译一个动态的Adaptive类。

下面我们可以以interface org.apache.dubbo.rpc.Protocol 这个协议扩展类型来看协议扩展类型目前没有一个是带有自适应注解的

private Class<?> createAdaptiveExtensionClass() {
 // Adaptive Classes' ClassLoader should be the same with Real SPI interface classes' ClassLoader
 //获取加载器
 ClassLoader classLoader = type.getClassLoader();
 try {
 // //native配置 是否为本地镜像(可以参考官方文档:https://dubbo.apache.org/zh/docs/references/graalvm/support-graalv
 if (NativeUtils.isNative()) {
 return classLoader.loadClass(type.getName() + "$Adaptive");
 }
 } catch (Throwable ignore) {

 }
 //创建一个代码生成器,来生成代码 详细内容我们就下一章来看
 String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate();
 //获取编译器
 org.apache.dubbo.common.compiler.Compiler compiler = extensionDirector.getExtensionLoader(
 org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
 //生成的代码进行编译
 return compiler.compile(type, code, classLoader);
 }

5.4 为扩展对象的set方法注入自适应扩展对象

在4.4.5小节中我们已经讲解了获取扩展类型实现类, 创建扩展对象

 T instance = (T) getAdaptiveExtensionClass().newInstance();

接下来就让我们来看下为扩展对象的set方法注入自适应的扩展对象调用方法代码如下:

 //注入扩展对象之前的回调方法
injectExtension(instance);

ExtensionLoader类型的injectExtension方法具体代码如下:

private T injectExtension(T instance) {
 //如果注入器为空则直接返回当前对象
 if (injector == null) {
 return instance;
 }

 try {
 //获取当前对象的当前类的所有方法
 for (Method method : instance.getClass().getMethods()) {
 //是否为set方法 不是的话则跳过,在这里合法的set方法满足3个条件:
 //set开头,参数只有一个,public修饰
 if (!isSetter(method)) {
 continue;
 }
 /**
 * Check {@link DisableInject} to see if we need auto injection for this property
 */
 //方法上面是否有注解DisableInject修饰,这种情况也直接跳过
 if (method.isAnnotationPresent(DisableInject.class)) {
 continue;
 }
 //方法的参数如果是原生类型也跳过
 Class<?> pt = method.getParameterTypes()[0];
 if (ReflectUtils.isPrimitives(pt)) {
 continue;
 }
 try {
 //获取set方法对应的成员变量如setProtocol 属性为protocol
 String property = getSetterProperty(method);
 //根据参数类型如Protocol和属性名字如protocol获取应该注入的对象
 Object object = injector.getInstance(pt, property);
 if (object != null) {
 //执行对应对象和对应参数的这个方法
 method.invoke(instance, object);
 }
 } catch (Exception e) {
 logger.error("Failed to inject via method " + method.getName()
 + " of interface " + type.getName() + ": " + e.getMessage(), e);
 }

 }
 } catch (Exception e) {
 logger.error(e.getMessage(), e);
 }
 return instance;
 }

5.4.1 获取注入对象

这里我们主要来看下如何通过注入器找到需要注入的那个对象调用代码如下:

 Object object = injector.getInstance(pt, property);

在前面看注入器扩展对象的获取的时候是会获取到ExtensionInjector扩展的一个自适应扩展注入器实现类型 AdaptiveExtensionInjector,这个地方对应的getInstance也是这个扩展里面的,我们来看下它的方法:

 @Override
 public <T> T getInstance(Class<T> type, String name) {
 //遍历所有的扩展注入器
 for (ExtensionInjector injector : injectors) {
 //遍历所有的扩展注入器,如果可以获取到扩展对象则直接返回
 T extension = injector.getInstance(type, name);
 if (extension != null) {
 return extension;
 }
 }
 return null;
 }

可以看到上面代码按扩展注入器顺序来遍历的第一个找到的对象就直接返回了,

这个AdaptiveExtensionInjector在初始化的时候会获取所有的ExtensionInjector的扩展,非自适应的,它本身自适应的扩展,这里会获取非自适应的扩展列表一共有3个按顺序为:

ScopeBeanExtensionInjector
SpiExtensionInjector
SpringExtensionInjector

接下来我们详细看下每种扩展注入器加载扩展对象的策略:

5.4.2 域模型中的Bean扩展注入器ScopeBeanExtensionInjector

ScopeBeanExtensionInjector的getInstance方法: 每个域模型都会有个ScopeBeanFactory类型的对象用于存储共享对象,并且域模型之间按照层级子类型的Bean工厂可以从父域的Bean工厂中查询对象,

@Override
 public <T> T getInstance(Class<T> type, String name) {
 return beanFactory.getBean(name, type);
 }

ScopeBeanFactory的getBean方法先从当前域空间查询对象,如果找不到对应类型的扩展对象则从父域工厂查询扩展对象

public <T> T getBean(String name, Class<T> type) {
 //当前域下注册的扩展对象
 T bean = getBeanInternal(name, type);
 if (bean == null && parent != null) {
 //父域中查找扩展对象
 return parent.getBean(name, type);
 }
 return bean;
 }

ScopeBeanFactory的getBeanInternal方法从当前域下找注册的参数类型的对象

private <T> T getBeanInternal(String name, Class<T> type) {
 checkDestroyed();
 // All classes are derived from java.lang.Object, cannot filter bean by it
 if (type == Object.class) {
 return null;
 }
 List<BeanInfo> candidates = null;
 BeanInfo firstCandidate = null;
 //遍历列表查询
 for (BeanInfo beanInfo : registeredBeanInfos) {
 // if required bean type is same class/superclass/interface of the registered bean
 if (type.isAssignableFrom(beanInfo.instance.getClass())) {
 if (StringUtils.isEquals(beanInfo.name, name)) {
 return (T) beanInfo.instance;
 } else {
 // optimize for only one matched bean
 if (firstCandidate == null) {
 firstCandidate = beanInfo;
 } else {
 if (candidates == null) {
 candidates = new ArrayList<>();
 candidates.add(firstCandidate);
 }
 candidates.add(beanInfo);
 }
 }
 }
 }

 // if bean name not matched and only single candidate
 if (candidates != null) {
 if (candidates.size() == 1) {
 return (T) candidates.get(0).instance;
 } else if (candidates.size() > 1) {
 List<String> candidateBeanNames = candidates.stream().map(beanInfo -> beanInfo.name).collect(Collectors.toList());
 throw new ScopeBeanException("expected single matching bean but found " + candidates.size() + " candidates for type [" + type.getName() + "]: " + candidateBeanNames);
 }
 } else if (firstCandidate != null) {
 return (T) firstCandidate.instance;
 }
 return null;
 }

5.4.3 SPI扩展机制注入器SpiExtensionInjector

SPI是Dubbo自行实现的一套扩展机制,我们来看下它是如何查找扩展对象的

@Override
 public <T> T getInstance(Class<T> type, String name) {
 //如果是一个标准的被@SPI注解修饰的扩展接口则满足条件
 if (type.isInterface() && type.isAnnotationPresent(SPI.class)) {
 //使用扩展访问器来获取对应类型的扩展加载器
 ExtensionLoader<T> loader = extensionAccessor.getExtensionLoader(type);
 if (loader == null) {
 return null;
 }
 //使用对应类型的扩展加载器来加载自适应扩展 这个加载的扩展可以参考4.4.6小节
 if (!loader.getSupportedExtensions().isEmpty()) {
 return loader.getAdaptiveExtension();
 }
 }
 return null;
 }

5.4.4 Spring扩展注入器

SpringExtensionInjector

Spring扩展注入器主要是用来从Spring容器中查询当前类型的Bean是否存在的,如下代码直接看代码吧

@Override
 @SuppressWarnings("unchecked")
 public <T> T getInstance(Class<T> type, String name) {

 if (context == null) {
 // ignore if spring context is not bound
 return null;
 }

 //check @SPI annotation ,类型需要满足SPI机制 @SPI修饰的接口
 if (type.isInterface() && type.isAnnotationPresent(SPI.class)) {
 return null;
 }
 //从Spring容器中查询Bean
 T bean = getOptionalBean(context, name, type);
 if (bean != null) {
 return bean;
 }

 //logger.warn("No spring extension (bean) named:" + name + ", try to find an extension (bean) of type " + type.getName());
 return null;
 }

private <T> T getOptionalBean(ListableBeanFactory beanFactory, String name, Class<T> type) {
 //要搜索的扩展名字为空就根据类型搜索
 if (StringUtils.isEmpty(name)) {
 //返回与给定类型（包括子类）匹配的bean的名称，对于FactoryBeans
 String[] beanNamesForType = beanFactory.getBeanNamesForType(type, true, false);
 if (beanNamesForType != null) {
 if (beanNamesForType.length == 1) {
 //返回指定bean的实例，该实例可以是共享的，也可以是独立的。
 //根据Bean Name和类型 查询具体的扩展对象
 return beanFactory.getBean(beanNamesForType[0], type);
 } else if (beanNamesForType.length > 1) {
 throw new IllegalStateException("Expect single but found " + beanNamesForType.length + " beans in spring context: " +
 Arrays.toString(beanNamesForType));
 }
 }
 } else {
 //扩展名字不为空则直接通过名字搜索Bean
 if (beanFactory.containsBean(name)) {
 return beanFactory.getBean(name, type);
 }
 }
 return null;
 }

原文：《自适应扩展对象的创建getAdaptiveExtension方法》

Blog: 04-Dubbo的扩展机制

Thu, 04 Aug 2022 00:00:00 +0000

4-Dubbo的扩展机制

4.1 回顾我们前面使用到扩展场景

在上一章中我们初始化应用模型对象的时候,了解到有几个地方用到了扩展机制来创建对象,这一章我们会详细来讲一下这个扩展对象的加载过程,这里我们先来回顾下哪些地方用到了扩展机制:

// 使用扩展机制获取TypeBuilder
Set<TypeBuilder> tbs = model.getExtensionLoader(TypeBuilder.class).getSupportedExtensionInstances();

//获取域模型初始化器ScopeModelInitializer扩展对象,执行初始化方法
ExtensionLoader<ScopeModelInitializer> initializerExtensionLoader = this.getExtensionLoader(ScopeModelInitializer.class);
 Set<ScopeModelInitializer> initializers = initializerExtensionLoader.getSupportedExtensionInstances();

// OrderedPropertiesConfiguration 中获取有序配置提供器对象
ExtensionLoader<OrderedPropertiesProvider> propertiesProviderExtensionLoader = moduleModel.getExtensionLoader(OrderedPropertiesProvider.class);

// ApplicationModel中获取配置管理器对象
 configManager = (ConfigManager) this.getExtensionLoader(ApplicationExt.class)
 .getExtension(ConfigManager.NAME);

//ModuleModel中获取模块扩展对象
Set<ModuleExt> exts = this.getExtensionLoader(ModuleExt.class).getSupportedExtensionInstances();

// ApplicationModel中获Environment对象
environment = (Environment) this.getExtensionLoader(ApplicationExt.class)
 .getExtension(Environment.NAME);

// ApplicationModel中获取应用初始化监听器ApplicationInitListener扩展对象
ExtensionLoader<ApplicationInitListener> extensionLoader = this.getExtensionLoader(ApplicationInitListener.class);
Set<String> listenerNames = extensionLoader.getSupportedExtensions();

//ScopeModel中创建扩展访问器:
this.extensionDirector = new ExtensionDirector(parent != null ? parent.getExtensionDirector() : null, scope, this);

有了以上的应用场景我们可以来看下扩展机制了

4.2 为什么要用到扩展机制?

为什么要用到扩展这个想必每个编程人员都比较了解,一个好的程序是要遵循一定的设计规范比如设计模式中的开闭原则 英文全称是 Open Closed Principle，简写为 OCP,对扩展开放、对修改关闭:

对扩展开放： 指的是我们系统中的模块、类、方法对它们的提供者（开发者）应该是开放的，提供者可以对系统进行扩展（新增）新的功能。

对修改关闭： 指的是系统中的模块、类、方法对它们的使用者（调用者）应该是关闭的。使用者使用这些功能时，不会因为提供方新增了功能而导致使用者也进行相应修改。

我们再来了解下Dubbo的一些基本特性: 下面这句话是我摘自官网的: Apache Dubbo 是一款微服务开发框架，它提供了 RPC通信 与 微服务治理 两大关键能力。这意味着，使用 Dubbo 开发的微服务，将具备相互之间的远程发现与通信能力，同时利用 Dubbo 提供的丰富服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。 Dubbo3 基于 Dubbo2 演进而来，在保持原有核心功能特性的同时， Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配、安全设计等几大方向上进行了全面升级。以下文档都将基于 Dubbo3 展开。

对修改关闭的地方: 对于Apache Dubbo来说不变的是RPC调用流程,微服务治理这些抽象的概念,我们可以用摘自官网的下面几个图表示:

图4.1 Dubbo架构图

再来看一个调用链路的架构图

图4.2 Dubbo RPC调用链路
上面两个图整体来看都是Dubbo不变的地方涉及到服务的RPC调用和服务治理的一些概念与流程,但是对于每个环节又可以使用各种方式实现,比如序列化机制可以是Json,Java序列化,Hession2或者Protobuf等等,网络传输层可以是netty实现的tcp通信,也可以使用http协议,那Dubbo又是如何封装不变部分扩展这种可变部分呢?,那就是接下来要说的**微内核机制**,这个我们待会说

对扩展开放： : 对于Apache Dubbo来说变化的是RPC调用流程和微服务治理这些抽象的概念的具体实现,每个点应该用什么技术实现,又是用什么场景,这个可以用如下图来表示下:

图4.3 Dubbo的扩展生态

看到这里应该各位就明白了,我们写程序是为了业务,而针对不同的业务需求很多场景下我们是需要使用不同的实现来满足的,Dubbo使用微内核的架构,将具体的实现开放出来,让使用者可以根据自己的需求来选择,定制. Dubbo开放了很多的扩展点供大家扩展,可想而知使用Dubbo的灵活性是非常高的。

微内核架构: 微内核架构由两大架构模块组成：核心系统与插件模块,设计一个微内核体系关键工作全部集中于核心系统怎么构建。 核心系统 : 负责和具体业务功能无关的通用功能，例如模块加载、模块间通信等,这个其实对应着Dubbo的SPI机制。 插件模块 : 负责实现具体的业务逻辑，Dubbo,SPI接口与实现。

4.3 Dubbo的扩展机制包含了哪些重要的组成部分?

前面我们说了为什么要使用扩展机制,这里我们来看下具体实现

先将扩展包里面的代码截个图认识认识各类型的单词

顺便我们先简单看下类结构图,后续再详细看每个类型的解释:

为了后续看具体的扩展加载流程我们先看下以上类型的解释说明:

ExtensionAccessor
- 扩展的统一访问器
ExtensionDirector
- ExtensionDirector是一个作用域扩展加载程序管理器。
- ExtensionDirector支持多个级别，子级可以继承父级的扩展实例。查找和创建扩展实例的方法类似于Java classloader。
ExtensionScope
- 扩展SPI域,目前有FRAMEWORK,APPLICATION,MODULE,SELF
- FRAMEWORK : 扩展实例在框架内使用，与所有应用程序和模块共享。框架范围SPI扩展只能获取FrameworkModel，无法获取ApplicationModel和ModuleModel。考虑：一些SPI需要在框架内的应用程序之间共享数据无状态SPI在框架内是安全共享的
- APPLICATION 扩展实例在一个应用程序中使用，与应用程序的所有模块共享，不同的应用程序创建不同的扩展实例。应用范围SPI扩展可以获取FrameworkModel和ApplicationModel，无法获取ModuleModel。考虑：在框架内隔离不同应用程序中的扩展数据在应用程序内部的所有模块之间共享扩展数据
- MODULE 扩展实例在一个模块中使用，不同的模块创建不同的扩展实例。模块范围SPI扩展可以获得FrameworkModel、ApplicationModel和ModuleModel。考虑：隔离应用程序内部不同模块中的扩展数据
- SELF 自给自足，为每个作用域创建一个实例，用于特殊的SPI扩展，如ExtensionInjector
ExtensionLoader
- ApplicationModel、DubboBootstrap和这个类目前被设计为单例或静态（本身完全静态或使用一些静态字段）。因此，从它们返回的实例属于process或classloader范围。如果想在一个进程中支持多个dubbo服务器，可能需要重构这三个类。
- 加载dubbo扩展
- 自动注入依赖项扩展
- 包装器中的自动包装扩展
- 默认扩展是一个自适应实例
- JDK自带SPI参考地址点击查看
- @SPI 服务扩展接口详细内容看后面
- @Adaptive自适应扩展点注解详细内容看后面
- @Activate自动激活扩展点注解详细内容看后面
ExtensionPostProcessor
- 在扩展初始化之前或之后调用的后处理器。
LoadingStrategy
- 扩展加载策略,目前有3个扩展加载策略分别从不同文件目录加载扩展
DubboInternalLoadingStrategy
- Dubbo内置的扩展加载策略,将加载文件目录为META-INF/dubbo/internal/的扩展
DubboLoadingStrategy
- Dubbo普通的扩展加载策略,将加载目录为META-INF/dubbo/的扩展
ServicesLoadingStrategy
- JAVA SPI加载策略 ,将加载目录为META-INF/services/的扩展
Wrapper注解
SPI注解
ExtensionInjector接口
- 为SPI扩展提供资源的注入器。
ExtensionAccessorAware
- SPI扩展可以实现这个感知接口，以获得适当的xtensionAccessor实例。
DisableInject注解
AdaptiveClassCodeGenerator
- 自适应类的代码生成器
Adaptive注解
为ExtensionLoader注入依赖扩展实例提供有用信息。
Activate注解
- Activate。此注解对于使用给定条件自动激活某些扩展非常有用，例如：@Activate可用于在有多个实现时加载某些筛选器扩展。 **group()**指定组条件。框架SPI定义了有效的组值。 **value()**指定URL条件中的参数键。 SPI提供程序可以调用ExtensionLoader。getActivateExtension(URL、String、String)方法以查找具有给定条件的所有已激活扩展。
ActivateComparator
- Activate扩展的排序器
MultiInstanceActivateComparator
WrapperComparator
AdaptiveExtensionInjector
SpiExtensionInjector

4.4 扩展加载创建之前的调用过程

4.4.1 扩展的调用代码示例

了解了这么多与扩展相关的概念,接下来我们就来从前面的代码调用中找几个例子来看下扩展的调用过程:

代码来源于FrameworkModel对象的初始化initialize()中的如下代码调用:

 TypeDefinitionBuilder.initBuilders(this);

TypeDefinitionBuilder中初始化类型构建器代码如下:

 public static void initBuilders(FrameworkModel model) {
 Set<TypeBuilder> tbs = model.getExtensionLoader(TypeBuilder.class).getSupportedExtensionInstances();
 BUILDERS = new ArrayList<>(tbs);
 }

4.4.2 Dubbo的分层模型获取扩展加载器对象

以上扩展调用的时候对于扩展加载器对象的获取代码如下所示,我们来看下它的调用链路

model.getExtensionLoader(TypeBuilder.class)

getExtensionLoader方法来源于FrameworkModel类型的父类型ScopeModel的实现的接口ExtensionAccessor中的默认方法(JDK8 默认方法)

ExtensionAccessor接口中的getExtensionLoader方法如下代码:

default <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
 return this.getExtensionDirector().getExtensionLoader(type);
 }

获取扩展加载器之前需要先获取扩展访问器: 这里的链路先梳理下:

模型对象(FrameworkModel)-–> 扩展访问器(ExtensionAccessor) —> 作用域扩展加载程序管理器(ExtensionDirector) —>

这个getExtensionDirector()方法来源于FrameworkModel的抽象父类型ScopeModel中的getExtensionDirector()如下代码:

@Override
 public ExtensionDirector getExtensionDirector() {
 return extensionDirector;
 }

这里直接返回了extensionDirector,,不知道介绍到这里记得这个扩展加载程序管理器extensionDirector对象的由来不, 在上个章节《3-框架,应用程序,模块领域模型Model对象的初始化》中3.2.2 初始化ScopeModel的章节中的ScopeModel类型的初始化方法initialize()方法中我们提到过这个对象的创建,具体代码如下所示(这个代码比较简单):

this.extensionDirector = new ExtensionDirector(parent != null ? parent.getExtensionDirector() : null, scope, this);

我们继续前面getExtensionLoader(type)方法调用逻辑,前面我们知道了这个扩展访问器的对象是ExtensionDirector,接下来我们看下ExtensionDirector中获取扩展加载器的代码(如下所示): 在详细介绍扩展加载器对象获取之前我们先来看下当前我们要加载的扩展类型的源码,后续会用到: 我们要加载的扩展类型TypeBuilder接口

@SPI(scope = ExtensionScope.FRAMEWORK)
public interface TypeBuilder extends Prioritized {

 /**
 * Whether the build accept the class passed in.
 */
 boolean accept(Class<?> clazz);

 /**
 * Build type definition with the type or class.
 */
 TypeDefinition build(Type type, Class<?> clazz, Map<String, TypeDefinition> typeCache);

}

ExtensionDirector类型中获取扩展加载器的代码这个代码非常有意思 其实就是前面说到的域模型架构的数据访问架构类似于JVM类加载器访问加载类的情况,但是这个顺序可能有所不同,Dubbo的扩展加载器是如何访问的呢? 遵循以下顺序:

先从缓存中查询扩展加载器
如果前面没找到则查询扩展类型的scope所属域,如果是当前域扩展则从直接创建扩展加载器
如果前面没找到就从父扩展访问器中查询,查询这个扩展是否数据父扩展域
前面都没找到就尝试创建

@Override
 public <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
 //如果扩展加载器已经被销毁则抛出异常
 checkDestroyed();
 //这里参数类型传的是TypeBuilder.class不为空
 if (type == null) {
 throw new IllegalArgumentException("Extension type == null");
 }
 //扩展类型不为接口也要抛出异常,这个TypeBuilder.class具体类型代码往上看,这个类型是一个接口
 if (!type.isInterface()) {
 throw new IllegalArgumentException("Extension type (" + type + ") is not an interface!");
 }
 //这个判断逻辑是判断这个扩展接口是有有@SPI注解,TypeBuilder是有的
 if (!withExtensionAnnotation(type)) {
 throw new IllegalArgumentException("Extension type (" + type +
 ") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() + "!");
 }

 // 1. find in local cache
 //被加载的扩展类型对应的扩展加载器会放到extensionLoadersMap这个ConcurrentHashMap类型的集合中方便缓存
 ExtensionLoader<T> loader = (ExtensionLoader<T>) extensionLoadersMap.get(type);
 //查询扩展所属域,这个类型的扩展域是框架级别的ExtensionScope.FRAMEWORK
 //extensionScopeMap为ConcurrentHashMap类型的扩展域缓存集合
 ExtensionScope scope = extensionScopeMap.get(type);
 if (scope == null) {
 SPI annotation = type.getAnnotation(SPI.class);
 scope = annotation.scope();
 extensionScopeMap.put(type, scope);
 }
 //首次访问的时候当前类型的扩展加载器类型肯定是空的,会走如下两个逻辑中的其中一个进行创建扩展加载器
 //1)如果 扩展域为SELF 自给自足，为每个作用域创建一个实例，用于特殊的SPI扩展，如{@link ExtensionInjector}
 if (loader == null && scope == ExtensionScope.SELF) {
 // create an instance in self scope
 loader = createExtensionLoader0(type);
 }

 // 2. find in parent
 //3) 从父扩展加载器中查询当前扩展加载器是否存在,这里parent是空的先不考虑
 if (loader == null) {
 if (this.parent != null) {
 loader = this.parent.getExtensionLoader(type);
 }
 }

 // 3. create it
 //4) 这个是我们本次会走的逻辑,大部分是会走这个逻辑来创建扩展加载器对象的
 if (loader == null) {
 loader = createExtensionLoader(type);
 }

 return loader;
 }

前面提到的withExtensionAnnotation判断代码如下:

private static boolean withExtensionAnnotation(Class<?> type) {
 return type.isAnnotationPresent(SPI.class);
 }

ExtensionDirector类型的createExtensionLoader方法

private <T> ExtensionLoader<T> createExtensionLoader(Class<T> type) {
 ExtensionLoader<T> loader = null;
 //当前类型注解的scope与当前扩展访问器ExtensionDirector的scope是否一致,不一致则抛出异常
 //当前类型ExtensionDirector的scope是在构造器中传递的,在Model对象初始化的时候创建的本类型
 if (isScopeMatched(type)) {
 // if scope is matched, just create it
 loader = createExtensionLoader0(type);
 } else {
 // if scope is not matched, ignore it
 }
 return loader;
 }

ExtensionDirector类型的createExtensionLoader0方法

 private <T> ExtensionLoader<T> createExtensionLoader0(Class<T> type) {
 //检查当前扩展访问器是否被销毁掉了
 checkDestroyed();
 ExtensionLoader<T> loader;
 //为当前扩展类型创建一个扩展访问器并缓存到,当前成员变量extensionLoadersMap中
 extensionLoadersMap.putIfAbsent(type, new ExtensionLoader<T>(type, this, scopeModel));
 loader = (ExtensionLoader<T>) extensionLoadersMap.get(type);
 return loader;
 }

4.4.3 扩展加载器对象ExtensionLoader的构造器

扩展加载器相对来说是比较复杂的实现内容比较多,用到哪里我们说下哪里,这里先来看ExtensionLoader的构造器代码如下所示:

 ExtensionLoader(Class<?> type, ExtensionDirector extensionDirector, ScopeModel scopeModel) {
 //当前扩展加载器,需要加载的扩展的类型
 this.type = type;
 //创建扩展加载器的扩展访问器对象
 this.extensionDirector = extensionDirector;
 //从扩展访问器中获取扩展执行前后的回调器
 this.extensionPostProcessors = extensionDirector.getExtensionPostProcessors();
 //创建实例化对象的策略对象
 initInstantiationStrategy();
 //如果当前扩展类型为扩展注入器类型则设置当前注入器变量为空,否则的话获取一个扩展注入器扩展对象
 this.injector = (type == ExtensionInjector.class ? null : extensionDirector.getExtensionLoader(ExtensionInjector.class)
 .getAdaptiveExtension());
 //创建Activate注解的排序器
 this.activateComparator = new ActivateComparator(extensionDirector);
 //为扩展加载器下的域模型对象赋值
 this.scopeModel = scopeModel;
 }

先来看创建实例化对象的策略对象代码 initInstantiationStrategy();

private void initInstantiationStrategy() {
 for (ExtensionPostProcessor extensionPostProcessor : extensionPostProcessors) {
 //ScopeModelAwareExtensionProcessor在域模型对象时候为扩展访问器添加了这个域模型扩展处理器对象ScopeModelAwareExtensionProcessor,这个类型实现了ScopeModelAccessor域模型访问器可以用来获取域模型对象
 if (extensionPostProcessor instanceof ScopeModelAccessor) {

 instantiationStrategy = new InstantiationStrategy((ScopeModelAccessor) extensionPostProcessor);
 break;
 }
 }
 if (instantiationStrategy == null) {
 instantiationStrategy = new InstantiationStrategy();
 }
 }

再来看ExtensionInjector扩展对象的获取

//1)这里有个type为空的判断,普通的扩展类型肯定不是ExtensionInjector类型 这里必定会为每个非扩展注入ExtensionInjector类型创建一个ExtensionInjector类型的扩展对象,
//2) 这里代码会走extensionDirector.getExtensionLoader(ExtensionInjector.class)这一步进去之后的代码刚刚看过就不再看了,这个代码会创建一个为ExtensionInjector扩展对象的加载器对象ExtensionLoader
//3) getAdaptiveExtension() 这个方法就是通过扩展加载器获取具体的扩展对象的方法我们会详细说
 this.injector = (type == ExtensionInjector.class ? null : extensionDirector.getExtensionLoader(ExtensionInjector.class)
 .getAdaptiveExtension());

原文： «Dubbo的扩展机制»

Blog: 03-框架,应用程序,模块领域模型Model对象的初始化

Wed, 03 Aug 2022 00:00:00 +0000

3-框架,应用程序,模块领域模型Model对象的初始化

在上一章中我们详细看了服务配置ServiceConfig类型的初始化，不过我们跳过了AbstractMethodConfig的构造器中创建模块模型对象的过程，那这一章我们就来看下模块模型对象的初始化过程:

public AbstractMethodConfig() {
 super(ApplicationModel.defaultModel().getDefaultModule());
 }

那为什么会在Dubbo3的新版本中加入这个域模型呢，主要有如下原因之前dubbo都是只有一个作用域的，通过静态类属性共享增加域模型是为了:

让Dubbo支持多应用的部署，这块一些大企业有诉求
从架构设计上，解决静态属性资源共享、清理的问题
分层模型将应用的管理和服务的管理分开

可能比较抽象，可以具体点来看。Dubbo3中在启动时候需要启动配置中心、元数据中心，这个配置中心和元数据中心可以归应用模型来管理。Dubbo作为RPC框架又需要启动服务和引用服务，服务级别的管理就交给了这个模块模型来管理。分层次的管理方便我们理解和处理逻辑，父子级别的模型又方便了数据传递。

了解过JVM类加载机制的同学应该就比较清楚JVM类加载过程中的数据访问模型。子类加载器先交给父类加载器查找，找不到再从子类加载器中查找。Dubbo的分层模型类似这样一种机制，这一章先来简单了解下，后面用到时候具体细说。

3.1 模型对象的关系

为了不增加复杂性，我们这里仅仅列出模型对象类型类型之间的继承关系如下所示:

图3.1 模型对象的继承关系

模型对象一共有4个，公共的属性和操作放在了域模型类型中，下面我们来详细说下这几个模型类型:

ExtensionAccessor 扩展的统一访问器
- 用于获取扩展加载管理器ExtensionDirector对象
- 获取扩展对象ExtensionLoader
- 根据扩展名字获取具体扩展对象
- 获取自适应扩展对象
- 获取默认扩展对象
ScopeModel 模型对象的公共抽象父类型
- 内部id用于表示模型树的层次结构
- 公共模型名称，可以被用户设置
- 描述信息
- 类加载器管理
- 父模型管理parent
- 当前模型的所属域ExtensionScope有:FRAMEWORK(框架)，APPLICATION(应用)，MODULE(模块)，SELF(自给自足，为每个作用域创建一个实例，用于特殊的SPI扩展，如ExtensionInjector)
- 具体的扩展加载程序管理器对象的管理:ExtensionDirector
- 域Bean工厂管理，一个内部共享的Bean工厂ScopeBeanFactory
- 等等
FrameworkModel dubbo框架模型，可与多个应用程序共享
- FrameworkModel实例对象集合，allInstances
- 所有ApplicationModel实例对象集合，applicationModels
- 发布的ApplicationModel实例对象集合pubApplicationModels
- 框架的服务存储库FrameworkServiceRepository类型对象(数据存储在内存中)
- 内部的应用程序模型对象internalApplicationModel
ApplicationModel 表示正在使用Dubbo的应用程序，并存储基本元数据信息，以便在RPC调用过程中使用。 ApplicationModel包括许多关于发布服务的ProviderModel和许多关于订阅服务的Consumer Model。
- ExtensionLoader、DubboBootstrap和这个类目前被设计为单例或静态（本身完全静态或使用一些静态字段）。因此，从它们返回的实例属于流程范围。如果想在一个进程中支持多个dubbo服务器，可能需要重构这三个类。
- 所有ModuleModel实例对象集合moduleModels
- 发布的ModuleModel实例对象集合pubModuleModels
- 环境信息Environment实例对象environment
- 配置管理ConfigManager实例对象configManager
- 服务存储库ServiceRepository实例对象serviceRepository
- 应用程序部署器ApplicationDeployer实例对象deployer
- 所属框架FrameworkModel实例对象frameworkModel
- 内部的模块模型ModuleModel实例对象internalModule
- 默认的模块模型ModuleModel实例对象defaultModule
ModuleModel 服务模块的模型
- 所属应用程序模型ApplicationModel实例对象applicationModel
- 模块环境信息ModuleEnvironment实例对象moduleEnvironment
- 模块服务存储库ModuleServiceRepository实例对象serviceRepository
- 模块的服务配置管理ModuleConfigManager实例对象moduleConfigManager
- 模块部署器ModuleDeployer实例对象deployer用于导出和引用服务

了解了这几个模型对象的关系我们可以了解到这几个模型对象的管理层级从框架到应用程序，然后到模块的管理(FrameworkModel->ApplicationModel->ModuleModel)，他们主要用来针对框架，应用程序，模块的存储，发布管理，，配置管理

看来Dubbo3 针对应用服务治理与运维这一块也是在努力尝试.

3.1.1 AbstractMethodConfig 配置对象中获取模型对象的调用

模块模型(ModuleModel)参数对象的创建这个AbstractMethodConfig构造器在初始化的时候调调用了这么一行代码做为参数向父类型传递对象.

ApplicationModel.defaultModel().getDefaultModule()

默认情况下使用ApplicationModel的静态方法获取默认的模型对象和默认的模块对象

ApplicationModel(应用程序领域模型)类型中获取默认模型对象的方法:

 public static ApplicationModel defaultModel() {
 // should get from default FrameworkModel, avoid out of sync
 return FrameworkModel.defaultModel().defaultApplication();
 }

这里可以看到要想获取应用程序模型必须先通过框架领域模型来获取层级也是框架领域模型到应用程序领域模型

3.1.2 使用双重校验锁获取框架模型对象

FrameworkModel(框架模型)的默认模型获取工厂方法defaultModel()

 /**
 * 在源码的注释上有这么一句话:在销毁默认的 FrameworkModel 时， FrameworkModel.defaultModel()
 *或ApplicationModel.defaultModel() 将返回一个损坏的模型
 *可能会导致不可预知的问题。建议：尽量避免使用默认模型。
 */
 public static FrameworkModel defaultModel() {
 //双重校验锁的形式创建单例对象
 FrameworkModel instance = defaultInstance;
 if (instance == null) {
 synchronized (globalLock) {
 //重置默认框架模型
 resetDefaultFrameworkModel();
 if (defaultInstance == null) {
 defaultInstance = new FrameworkModel();
 }
 instance = defaultInstance;
 }
 }
 Assert.notNull(instance, "Default FrameworkModel is null");
 return instance;
 }

3.1.3 刷新重置默认框架模型对象

FrameworkModel中的重置默认框架模型resetDefaultFrameworkModel

 private static void resetDefaultFrameworkModel() {
 //全局悲观锁，同一个时刻只能有一个线程执行重置操作
 synchronized (globalLock) {
 //defaultInstance为当前成员变量FrameworkModel类型代表当前默认的FrameworkModel类型的实例对象
 if (defaultInstance != null && !defaultInstance.isDestroyed()) {
 return;
 }
 FrameworkModel oldDefaultFrameworkModel = defaultInstance;
 //存在实例模型列表则直接从内存缓存中查后续不需要创建了
 if (allInstances.size() > 0) {
 //当前存在的有FrameworkModel框架实例多个列表则取第一个为默认的
 defaultInstance = allInstances.get(0);
 } else {
 defaultInstance = null;
 }
 if (oldDefaultFrameworkModel != defaultInstance) {
 if (LOGGER.isInfoEnabled()) {
 LOGGER.info("Reset global default framework from " + safeGetModelDesc(oldDefaultFrameworkModel) + " to " + safeGetModelDesc(defaultInstance));
 }
 }
 }
 }

上面单例做了很多的初始化操作，这里开始调用构造器来创建框架模型对象，如下代码:

3.2 创建FrameworkModel对象

FrameworkModel()构造器

public FrameworkModel() {
 //调用父类型ScopeModel传递参数，这个构造器的第一个参数为空代表这是一个顶层的域模型，第二个代表了这个是框架FRAMEWORK域，第三个false不是内部域
 super(null, ExtensionScope.FRAMEWORK, false);
 //内部id用于表示模型树的层次结构，如层次结构:
 //FrameworkModel（索引=1）->ApplicationModel（索引=2）->ModuleModel（索引=1，第一个用户模块）
 //这个index变量是static类型的为静态全局变量默认值从1开始，如果有多个框架模型对象则internalId编号从1开始依次递增
 this.setInternalId(String.valueOf(index.getAndIncrement()));
 // register FrameworkModel instance early
 //将当前新创建的框架实例对象添加到容器中
 synchronized (globalLock) {
 //将当前框架模型实例添加到所有框架模型缓存对象中
 allInstances.add(this);
 //如上面代码所示重置默认的框架模型对象，这里将会是缓存实例列表的第一个，新增了一个刷新默认实例对象
 resetDefaultFrameworkModel();
 }
 if (LOGGER.isInfoEnabled()) {
 LOGGER.info(getDesc() + " is created");
 }
 //初始化框架模型领域对象
 initialize();
 }

ExtensionScope.FRAMEWORK

3.2.1 初始化FrameworkModel

FrameworkModel框架模型的初始化方法initialize()

@Override
 protected void initialize() {
 //这里初始化之前先调用下父类型ScopeModel的初始化方法我们在下面来看
 super.initialize();
 //使用TypeDefinitionBuilder的静态方法initBuilders来初始化类型构建器TypeBuilder类型集合
 TypeDefinitionBuilder.initBuilders(this);
 //框架服务存储仓库对象，可以用于快速查询服务提供者信息
 serviceRepository = new FrameworkServiceRepository(this);
 //获取ScopeModelInitializer类型(域模型初始化器)的扩展加载器ExtensionLoader，每个扩展类型都会创建一个扩展加载器缓存起来
 ExtensionLoader<ScopeModelInitializer> initializerExtensionLoader = this.getExtensionLoader(ScopeModelInitializer.class);
 //获取ScopeModelInitializer类型的支持的扩展集合，这里当前版本存在8个扩展类型实现
 Set<ScopeModelInitializer> initializers = initializerExtensionLoader.getSupportedExtensionInstances();
 //遍历这些扩展实现调用他们的initializeFrameworkModel方法来传递FrameworkModel类型对象，细节我们待会再详细说下
 for (ScopeModelInitializer initializer : initializers) {
 initializer.initializeFrameworkModel(this);
 }
 //创建一个内部的ApplicationModel类型，细节下面说
 internalApplicationModel = new ApplicationModel(this, true);
 //创建ApplicationConfig类型对象同时传递应用程序模型对象internalApplicationModel
 //获取ConfigManager类型对象，然后设置添加当前应用配置对象
 internalApplicationModel.getApplicationConfigManager().setApplication(
 new ApplicationConfig(internalApplicationModel, CommonConstants.DUBBO_INTERNAL_APPLICATION));
 //设置公开的模块名字为常量DUBBO_INTERNAL_APPLICATION
 internalApplicationModel.setModelName(CommonConstants.DUBBO_INTERNAL_APPLICATION);
 }

继续上面代码的调用链路，我们来看 FrameworkModel的super.initialize();方法调用父类型ScopeModel的initialize()方法

3.2.2 初始化ScopeModel

ScopeModel类型的初始化方法initialize():

protected void initialize() {
 //初始化ExtensionDirector是一个作用域扩展加载程序管理器。
 //ExtensionDirector支持多个级别，子级可以继承父级的扩展实例。
 //查找和创建扩展实例的方法类似于Java classloader。
 this.extensionDirector = new ExtensionDirector(parent != null ? parent.getExtensionDirector() : null, scope, this);
 //这个参考了Spring的生命周期回调思想，添加一个扩展初始化的前后调用的处理器，在扩展初始化之前或之后调用的后处理器，参数类型为ExtensionPostProcessor
 this.extensionDirector.addExtensionPostProcessor(new ScopeModelAwareExtensionProcessor(this));
 //创建一个内部共享的域工厂对象，用于注册Bean，创建Bean，获取Bean，初始化Bean等
 this.beanFactory = new ScopeBeanFactory(parent != null ? parent.getBeanFactory() : null, extensionDirector);
 //使用数据结构链表，创建销毁监听器容器，一般用于关闭进程，重置应用程序对象等操作时候调用
 this.destroyListeners = new LinkedList<>();
 //使用ConcurrentHashMap属性集合
 this.attributes = new ConcurrentHashMap<>();
 //使用ConcurrentHashSet存储当前域下的类加载器
 this.classLoaders = new ConcurrentHashSet<>();

 // Add Framework's ClassLoader by default
 //将当前类的加载器存入加载器集合classLoaders中
 ClassLoader dubboClassLoader = ScopeModel.class.getClassLoader();
 if (dubboClassLoader != null) {
 this.addClassLoader(dubboClassLoader);
 }
 }

3.2.3 初始类型定义构建器

TypeDefinitionBuilder的初始化类型构造器方法initBuilders

public static void initBuilders(FrameworkModel model) {
 Set<TypeBuilder> tbs = model.getExtensionLoader(TypeBuilder.class).getSupportedExtensionInstances();
 BUILDERS = new ArrayList<>(tbs);
 }

3.2.3.1 服务存储仓库对象的创建

FrameworkServiceRepository对象的初始化

public FrameworkServiceRepository(FrameworkModel frameworkModel) {
 this.frameworkModel = frameworkModel;
 }

3.2.4 域模型初始化器的获取与初始化回调

域模型初始化器的获取与初始化(ScopeModelInitializer类型和initializeFrameworkModel方法) 加载到的ScopeModelInitializer类型的SPI扩展实现

ExtensionLoader<ScopeModelInitializer> initializerExtensionLoader = this.getExtensionLoader(ScopeModelInitializer.class);
 //获取ScopeModelInitializer类型的支持的扩展集合，这里当前版本存在8个扩展类型实现
 Set<ScopeModelInitializer> initializers = initializerExtensionLoader.getSupportedExtensionInstances();
 //遍历这些扩展实现调用他们的initializeFrameworkModel方法来传递FrameworkModel类型对象，细节我们待会再详细说下
 for (ScopeModelInitializer initializer : initializers) {
 initializer.initializeFrameworkModel(this);
 }

通过Debug查到域模型初始化器的SPI扩展类型有如下8个:

这里我随机找两个说一下吧: 容错域模型初始化器:ClusterScopeModelInitializer的initializeFrameworkModel方法:

public class ClusterScopeModelInitializer implements ScopeModelInitializer {
 @Override
 public void initializeFrameworkModel(FrameworkModel frameworkModel) {
 ScopeBeanFactory beanFactory = frameworkModel.getBeanFactory();
 beanFactory.registerBean(RouterSnapshotSwitcher.class);
 }

public class CommonScopeModelInitializer implements ScopeModelInitializer {
 @Override
 public void initializeFrameworkModel(FrameworkModel frameworkModel) {
 ScopeBeanFactory beanFactory = frameworkModel.getBeanFactory();
 beanFactory.registerBean(FrameworkExecutorRepository.class);
 }

public class ConfigScopeModelInitializer implements ScopeModelInitializer {

 @Override
 public void initializeFrameworkModel(FrameworkModel frameworkModel) {
 frameworkModel.addDestroyListener(new FrameworkModelCleaner());
 }

3.2.5 将内部应用配置对象创建与添加至应用模型中

创建ApplicationConfig对象让后将其添加至应用模型中内部应用程序模型，这里为应用配置管理器设置一个应用配置对象，将这个应用配置的模块名字配置名字设置为DUBBO_INTERNAL_APPLICATION，应用配置记录着我们常见的应用配置信息，如下面表格所示:

 //获取ConfigManager类型对象，然后设置添加当前应用配置对象
 internalApplicationModel.getApplicationConfigManager().setApplication(
 new ApplicationConfig(internalApplicationModel, CommonConstants.DUBBO_INTERNAL_APPLICATION));
 //设置公开的模块名字为常量DUBBO_INTERNAL_APPLICATION
 internalApplicationModel.setModelName(CommonConstants.DUBBO_INTERNAL_APPLICATION);

来自官网目前版本的配置解释: 官网当前的配置描述知道到了元数据类型，后面我再补充几个

属性	对应URL参数	类型	是否必填	缺省值	作用	描述	兼容性
name	application	string	必填		服务治理	当前应用名称，用于注册中心计算应用间依赖关系，注意：消费者和提供者应用名不要一样，此参数不是匹配条件，你当前项目叫什么名字就填什么，和提供者消费者角色无关，比如：kylin应用调用了morgan应用的服务，则kylin项目配成kylin，morgan项目配成morgan，可能kylin也提供其它服务给别人使用，但kylin项目永远配成kylin，这样注册中心将显示kylin依赖于morgan	1.0.16以上版本
version	application.version	string	可选		服务治理	当前应用的版本	2.2.0以上版本
owner	owner	string	可选		服务治理	应用负责人，用于服务治理，请填写负责人公司邮箱前缀	2.0.5以上版本
organization	organization	string	可选		服务治理	组织名称(BU或部门)，用于注册中心区分服务来源，此配置项建议不要使用autoconfig，直接写死在配置中，比如china,intl,itu,crm,asc,dw,aliexpress等	2.0.0以上版本
architecture	architecture	string	可选		服务治理	用于服务分层对应的架构。如，intl、china。不同的架构使用不同的分层。	2.0.7以上版本
environment	environment	string	可选		服务治理	应用环境，如：develop/test/product，不同环境使用不同的缺省值，以及作为只用于开发测试功能的限制条件	2.0.0以上版本
compiler	compiler	string	可选	javassist	性能优化	Java字节码编译器，用于动态类的生成，可选：jdk或javassist	2.1.0以上版本
logger	logger	string	可选	slf4j	性能优化	日志输出方式，可选：slf4j,jcl,log4j,log4j2,jdk	2.2.0以上版本
metadata-type	metadata-type	String	可选	local	服务治理	metadata 传递方式，是以 Provider 视角而言的，Consumer 侧配置无效，可选值有：remote - Provider 把 metadata 放到远端注册中心，Consumer 从注册中心获取local - Provider 把 metadata 放在本地，Consumer 从 Provider 处直接获取	2.7.6以上版本

当前在Dubbo3.0.7中还有一些的配置我下面列举下:

属性	对应URL参数	类型	是否必填	缺省值	作用	描述
register-consumer	register-consumer	boolean	可选	false	服务治理	是否注册使用者实例，默认为false。
register-mode	register-mode	string	可选	all	服务治理	将interface/instance/all 地址注册到注册中心，默认为all。
enable-empty-protection	enable-empty-protection	boolean	可选	true	服务治理	在空地址通知上启用空保护，默认为true
protocol	protocol	string	可选	dubbo	服务治理	此应用程序的首选协议（名称）

3.3 创建ApplicationModel对象

ApplicationModel对象的初始化调用在前面 3.2.4 FrameworkModel框架模型的初始化方法initialize() 章节中，我们看到了代码ApplicationModel对象的初始化调用如下代码，这里我们来详细说一下:

 internalApplicationModel = new ApplicationModel(this, true);
 internalApplicationModel.getApplicationConfigManager().setApplication(
 new ApplicationConfig(internalApplicationModel, CommonConstants.DUBBO_INTERNAL_APPLICATION));
 internalApplicationModel.setModelName(CommonConstants.DUBBO_INTERNAL_APPLICATION);

3.3.1 ApplicationModel的构造器

ApplicationModel(FrameworkModel frameworkModel, boolean isInternal) 刚刚3.2.9那个地方我们看到了使用代码new ApplicationModel(this, true) 来创建对象这里我们详细看下代码细节:

public ApplicationModel(FrameworkModel frameworkModel, boolean isInternal) {
 //调用父类型ScopeModel传递参数，这个构造器的传递没与前面看到的FrameworkModel构造器的中的调用参数有些不同第一个参数我们为frameworkModel代表父域模型，第二个参数标记域为应用程序级别APPLICATION，第三个参数我们传递的为true代表为内部域
 super(frameworkModel, ExtensionScope.APPLICATION, isInternal);
 Assert.notNull(frameworkModel, "FrameworkModel can not be null");
 //应用程序域成员变量记录frameworkModel对象
 this.frameworkModel = frameworkModel;
 //frameworkModel对象添加当前应用程序域对象
 frameworkModel.addApplication(this);
 if (LOGGER.isInfoEnabled()) {
 LOGGER.info(getDesc() + " is created");
 }
 //初始化应用程序
 initialize();
 }

3.3.1.1 将ApplicationModel添加至FrameworkModel容器中

FrameworkModel的添加应用程序方法addApplication:

void addApplication(ApplicationModel applicationModel) {
 // can not add new application if it's destroying
 //检查FrameworkModel对象是否已经被标记为销毁状态，如果已经被销毁了则抛出异常无需执行逻辑
 checkDestroyed();
 synchronized (instLock) {
 //如果还未添加过当前参数传递应用模型
 if (!this.applicationModels.contains(applicationModel)) {
 //为当前应用模型生成内部id
 applicationModel.setInternalId(buildInternalId(getInternalId(), appIndex.getAndIncrement()));
 //添加到成员变量集合applicationModels中
 this.applicationModels.add(applicationModel);
 //如果非内部的则也向公开应用模型集合pubApplicationModels中添加一下
 if (!applicationModel.isInternal()) {
 this.pubApplicationModels.add(applicationModel);
 }
 resetDefaultAppModel();
 }
 }
 }

内部id生成算法buildInternalId方法代码如下: 看代码胜过，文字解释

 protected String buildInternalId(String parentInternalId, long childIndex) {
 // FrameworkModel 1
 // ApplicationModel 1.1
 // ModuleModel 1.1.1
 if (StringUtils.hasText(parentInternalId)) {
 return parentInternalId + "." + childIndex;
 } else {
 return "" + childIndex;
 }
 }

重置默认的应用模型对象 FrameworkModel 重置默认的应用模型对象 resetDefaultAppModel()方法与默认框架模型设置方式类似取集合的第一个，这里应用模型需要使用公开的应用模型的第一个做为默认应用模型，代码如下所示:

private void resetDefaultAppModel() {
 synchronized (instLock) {
 if (this.defaultAppModel != null && !this.defaultAppModel.isDestroyed()) {
 return;
 }
 //取第一个公开的应用模型做为默认应用模型
 ApplicationModel oldDefaultAppModel = this.defaultAppModel;
 if (pubApplicationModels.size() > 0) {
 this.defaultAppModel = pubApplicationModels.get(0);
 } else {
 this.defaultAppModel = null;
 }
 if (defaultInstance == this && oldDefaultAppModel != this.defaultAppModel) {
 if (LOGGER.isInfoEnabled()) {
 LOGGER.info("Reset global default application from " + safeGetModelDesc(oldDefaultAppModel) + " to " + safeGetModelDesc(this.defaultAppModel));
 }
 }
 }
 }

3.3.2 初始化ApplicationModel

ApplicationModel的初始化initialize()方法在前面3.2.10 ApplicationModel的构造器ApplicationModel(FrameworkModel frameworkModel, boolean isInternal) 中的最后一行开始初始化应用模型我们还未详细说明下面可以来看下

@Override
 protected void initialize() {
 //这个是调用域模型来初始化基础信息如扩展访问器等，可以参考 3.2.5 ScopeModel类型的初始化方法initialize()章节
 super.initialize();
 //创建一个内部的模块模型对象
 internalModule = new ModuleModel(this, true);
 //创建一个独立服务存储对象
 this.serviceRepository = new ServiceRepository(this);
 //获取应用程序初始化监听器ApplicationInitListener扩展
 ExtensionLoader<ApplicationInitListener> extensionLoader = this.getExtensionLoader(ApplicationInitListener.class);
 //如果存在应用程序初始化监听器扩展则执行这个初始化方法，在当前的版本还未看到有具体的扩展实现类型
 Set<String> listenerNames = extensionLoader.getSupportedExtensions();
 for (String listenerName : listenerNames) {
 extensionLoader.getExtension(listenerName).init();
 }
 //初始化扩展(这个是应用程序生命周期的方法调用，这里调用初始化方法
 initApplicationExts();

 //获取域模型初始化器扩展对象列表，然后执行初始化方法
 ExtensionLoader<ScopeModelInitializer> initializerExtensionLoader = this.getExtensionLoader(ScopeModelInitializer.class);
 Set<ScopeModelInitializer> initializers = initializerExtensionLoader.getSupportedExtensionInstances();
 for (ScopeModelInitializer initializer : initializers) {
 initializer.initializeApplicationModel(this);
 }
 }

3.3.4 initApplicationExts() 初始化应用程序扩展方法

 private void initApplicationExts() {
 //这个扩展实现一共有两个可以看下面那个图扩展类型为ConfigManager和Environment
 Set<ApplicationExt> exts = this.getExtensionLoader(ApplicationExt.class).getSupportedExtensionInstances();
 for (ApplicationExt ext : exts) {
 ext.initialize();
 }
 }

3.3.4.1 ConfigManager类型的initialize方法

先简单说下ConfigManager的作用，无锁配置管理器（通过ConcurrentHashMap），用于快速读取操作。写入操作锁带有配置类型的子配置映射，用于安全检查和添加新配置。其实ConfigManager实现类中并没有这个初始化方法initialize，不过ConfigManager的父类型AbstractConfigManager中是有initialize方法的，如下所示:

AbstractConfigManager的初始化方法initialize

@Override
 public void initialize() throws IllegalStateException {
 //乐观锁判断是否初始化过
 if (!initialized.compareAndSet(false, true)) {
 return;
 }
 //从模块环境中获取组合配置，目前Environment中有6种重要的配置，我们后面详细说
 CompositeConfiguration configuration = scopeModel.getModelEnvironment().getConfiguration();

 // dubbo.config.mode获取配置模式，配置模式对应枚举类型ConfigMode，目前有这么几个STRICT，OVERRIDE，OVERRIDE_ALL，OVERRIDE_IF_ABSENT，IGNORE，这个配置决定了属性覆盖的顺序，当有同一个配置key多次出现时候，以最新配置为准，还是以最老的那个配置为准，还是配置重复则抛出异常，默认值为严格模式STRICT重复则抛出异常
 String configModeStr = (String) configuration.getProperty(ConfigKeys.DUBBO_CONFIG_MODE);
 try {
 if (StringUtils.hasText(configModeStr)) {
 this.configMode = ConfigMode.valueOf(configModeStr.toUpperCase());
 }
 } catch (Exception e) {
 String msg = "Illegal '" + ConfigKeys.DUBBO_CONFIG_MODE + "' config value [" + configModeStr + "], available values " + Arrays.toString(ConfigMode.values());
 logger.error(msg, e);
 throw new IllegalArgumentException(msg, e);
 }

 // dubbo.config.ignore-duplicated-interface
 //忽略重复的接口（服务/引用）配置。默认值为false
 String ignoreDuplicatedInterfaceStr = (String) configuration
 .getProperty(ConfigKeys.DUBBO_CONFIG_IGNORE_DUPLICATED_INTERFACE);
 if (ignoreDuplicatedInterfaceStr != null) {
 this.ignoreDuplicatedInterface = Boolean.parseBoolean(ignoreDuplicatedInterfaceStr);
 }

 // print 打印配置信息
 Map<String, Object> map = new LinkedHashMap<>();
 map.put(ConfigKeys.DUBBO_CONFIG_MODE, configMode);
 map.put(ConfigKeys.DUBBO_CONFIG_IGNORE_DUPLICATED_INTERFACE, this.ignoreDuplicatedInterface);
 logger.info("Config settings: " + map);
 }

3.3.4.2 Environment类型的initialize方法

这是一个与环境配置有关系的类型，我们先来简单了解下它的初始化方法，后期再详细说明:

Environment类型的initialize方法

 @Override
 public void initialize() throws IllegalStateException {
 //乐观锁判断是否进行过初始化
 if (initialized.compareAndSet(false, true)) {
 //PropertiesConfiguration从系统属性和dubbo.properties中获取配置
 this.propertiesConfiguration = new PropertiesConfiguration(scopeModel);
 //SystemConfiguration获取的是JVM参数 启动命令中-D指定的
 this.systemConfiguration = new SystemConfiguration();
 //EnvironmentConfiguration是从环境变量中获取的配置
 this.environmentConfiguration = new EnvironmentConfiguration();
 //外部的Global配置config-center global/default config
 this.externalConfiguration = new InmemoryConfiguration("ExternalConfig");
 //外部的应用配置如:config-center中的应用配置
 this.appExternalConfiguration = new InmemoryConfiguration("AppExternalConfig");
 //本地应用配置 ， 如Spring Environment/PropertySources/application.properties
 this.appConfiguration = new InmemoryConfiguration("AppConfig");
 //服务迁移配置加载 dubbo2升级dubbo3的一些配置
 loadMigrationRule();
 }
 }
 //服务迁移配置加载 JVM > env > 代码路径dubbo-migration.yaml
 private void loadMigrationRule() {
 //文件路径配置的key dubbo.migration.file
 // JVM参数中获取
 String path = System.getProperty(CommonConstants.DUBBO_MIGRATION_KEY);
 if (StringUtils.isEmpty(path)) {
 //env环境变量中获取
 path = System.getenv(CommonConstants.DUBBO_MIGRATION_KEY);
 if (StringUtils.isEmpty(path)) {
 //类路径下获取文件dubbo-migration.yaml
 path = CommonConstants.DEFAULT_DUBBO_MIGRATION_FILE;
 }
 }
 this.localMigrationRule = ConfigUtils.loadMigrationRule(scopeModel.getClassLoaders(), path);
 }

ConfigUtils中读取迁移规则配置文件loadMigrationRule 这个我们不细说了，贴一下代码感兴趣可以了解下，这个代码主要是读取文件到内存字符串:

 public static String loadMigrationRule(Set<ClassLoader> classLoaders, String fileName) {
 String rawRule = "";
 if (checkFileNameExist(fileName)) {
 try {
 try (FileInputStream input = new FileInputStream(fileName)) {
 return readString(input);
 }
 } catch (Throwable e) {
 logger.warn("Failed to load " + fileName + " file from " + fileName + "(ignore this file): " + e.getMessage(), e);
 }
 }

 try {
 List<ClassLoader> classLoadersToLoad = new LinkedList<>();
 classLoadersToLoad.add(ClassUtils.getClassLoader());
 classLoadersToLoad.addAll(classLoaders);
 for (Set<URL> urls : ClassLoaderResourceLoader.loadResources(fileName, classLoadersToLoad).values()) {
 for (URL url : urls) {
 InputStream is = url.openStream();
 if (is != null) {
 return readString(is);
 }
 }
 }
 } catch (Throwable e) {
 logger.warn("Failed to load " + fileName + " file from " + fileName + "(ignore this file): " + e.getMessage(), e);
 }
 return rawRule;
 }

 private static String readString(InputStream is) {
 StringBuilder stringBuilder = new StringBuilder();
 char[] buffer = new char[10];
 try (BufferedReader reader = new BufferedReader(new InputStreamReader(is))) {
 int n;
 while ((n = reader.read(buffer)) != -1) {
 if (n < 10) {
 buffer = Arrays.copyOf(buffer, n);
 }
 stringBuilder.append(String.valueOf(buffer));
 buffer = new char[10];
 }
 } catch (IOException e) {
 logger.error("Read migration file error.", e);
 }

 return stringBuilder.toString();
 }

 /**
 * check if the fileName can be found in filesystem
 *
 * @param fileName
 * @return
 */
 private static boolean checkFileNameExist(String fileName) {
 File file = new File(fileName);
 return file.exists();
 }

3.4 创建ModuleModel对象

前面ApplicationModel对象初始化的时候创建了ModuleModel如下代码:

internalModule = new ModuleModel(this, true);

这里我们来看下这个它所对应的构造器

public ModuleModel(ApplicationModel applicationModel, boolean isInternal) {
 //调用ScopeModel传递3个参数父模型，模型域为模块域，是否为内部模型参数为true
 super(applicationModel, ExtensionScope.MODULE, isInternal);
 Assert.notNull(applicationModel, "ApplicationModel can not be null");
 //初始化成员变量applicationModel
 this.applicationModel = applicationModel;
 //将模块模型添加至应用模型中
 applicationModel.addModule(this, isInternal);
 if (LOGGER.isInfoEnabled()) {
 LOGGER.info(getDesc() + " is created");
 }
 //初始化模块模型
 initialize();
 Assert.notNull(serviceRepository, "ModuleServiceRepository can not be null");
 Assert.notNull(moduleConfigManager, "ModuleConfigManager can not be null");
 Assert.assertTrue(moduleConfigManager.isInitialized(), "ModuleConfigManager can not be initialized");

 // notify application check state
 //获取应用程序发布对象，通知检查状态
 ApplicationDeployer applicationDeployer = applicationModel.getDeployer();
 if (applicationDeployer != null) {
 applicationDeployer.notifyModuleChanged(this, DeployState.PENDING);
 }
 }

3.4.1 将模块模型添加至应用模型中

如上面代码所示调用如下代码将模块模型添加到应用模型中:

 applicationModel.addModule(this, isInternal);

这里我们来看下添加过程


void addModule(ModuleModel moduleModel, boolean isInternal) {
 //加锁
 synchronized (moduleLock) {
 //不存在则添加
 if (!this.moduleModels.contains(moduleModel)) {
 //检查应用模型是否已销毁
 checkDestroyed();
 //添加至模块模型成员变量中
 this.moduleModels.add(moduleModel);
 //设置模块模型内部id，这个内部id生成过程与上面将应用模型添加到框架模型中的方式是一致的
 //可以参考 3.3.2 将ApplicationModel添加至FrameworkModel容器中
 moduleModel.setInternalId(buildInternalId(getInternalId(), moduleIndex.getAndIncrement()));
 //如果不是内部模型则添加到公开模块模型中
 if (!isInternal) {
 pubModuleModels.add(moduleModel);
 }
 }
 }
 }

3.4.2 初始化模块模型

前面ModuleModel构造器中通过initialize()方法来进行初始化操作如下代码:

@Override
 protected void initialize() {
 //调用域模型ScopeModel的初始化，可以参考 3.2.5 ScopeModel类型的初始化方法initialize()章节
 super.initialize();
 //创建模块服务存储库对象
 this.serviceRepository = new ModuleServiceRepository(this);
 //创建模块配置管理对象
 this.moduleConfigManager = new ModuleConfigManager(this);
 //初始化模块配置管理对象
 this.moduleConfigManager.initialize();

 //初始化模块配置扩展
 initModuleExt();

 //初始化域模型扩展
 ExtensionLoader<ScopeModelInitializer> initializerExtensionLoader = this.getExtensionLoader(ScopeModelInitializer.class);
 Set<ScopeModelInitializer> initializers = initializerExtensionLoader.getSupportedExtensionInstances();
 for (ScopeModelInitializer initializer : initializers) {
 initializer.initializeModuleModel(this);
 }
 }

3.4.2.1 模块服务存储库的创建

ModuleServiceRepository是模块模型中用来存储服务的通过如下代码调用

//创建模块服务存储库对象
 this.serviceRepository = new ModuleServiceRepository(this);

这里我们来看下模块服务存储库的构造器代码:

 public ModuleServiceRepository(ModuleModel moduleModel) {
 //初始化模块模型
 this.moduleModel = moduleModel;
 //
 frameworkServiceRepository = ScopeModelUtil.getFrameworkModel(moduleModel).getServiceRepository();
 }

ModuleServiceRepository存储库中使用框架存储库frameworkServiceRepository来间接存储这里我们看下怎么通过模块模型获取框架服务存储库frameworkServiceRepository:通过代码

ScopeModelUtil.getFrameworkModel(moduleModel).getServiceRepository()

ScopeModelUtil工具类获取getFrameworkModel代码如下:

public static FrameworkModel getFrameworkModel(ScopeModel scopeModel) {
 if (scopeModel == null) {
 return FrameworkModel.defaultModel();
 }
 //通过成员变量获取(构造器初始化的时候将FrameworkModel赋值给了ApplicationModel的成员变量
 if (scopeModel instanceof ApplicationModel) {
 //直接获取
 return ((ApplicationModel) scopeModel).getFrameworkModel();
 } else if (scopeModel instanceof ModuleModel) {
 ModuleModel moduleModel = (ModuleModel) scopeModel;
 //间接通过ApplicationModel获取，不越级获取
 return moduleModel.getApplicationModel().getFrameworkModel();
 } else if (scopeModel instanceof FrameworkModel) {
 return (FrameworkModel) scopeModel;
 } else {
 throw new IllegalArgumentException("Unable to get FrameworkModel from " + scopeModel);
 }
 }

3.4.2.2 模块配置管理器对象的创建与初始化

 //创建模块配置管理对象
 this.moduleConfigManager = new ModuleConfigManager(this);
 //初始化模块配置管理对象
 this.moduleConfigManager.initialize();

ModuleConfigManager的构造器代码如下:

public ModuleConfigManager(ModuleModel moduleModel) {
 //向抽象的配置管理器AbstractConfigManager传递参数
 //模块模型参数，模块支持的配置类型集合
 super(moduleModel, Arrays.asList(ModuleConfig.class, ServiceConfigBase.class, ReferenceConfigBase.class, ProviderConfig.class, ConsumerConfig.class));
 //获取应用程序配置管理器
 applicationConfigManager = moduleModel.getApplicationModel().getApplicationConfigManager();
 }

ModuleConfigManager类型的初始化方法代码如下:

@Override
 public void initialize() throws IllegalStateException {
 if (!initialized.compareAndSet(false, true)) {
 return;
 }
 //获取组合配置对象
 CompositeConfiguration configuration = scopeModel.getModelEnvironment().getConfiguration();

 // dubbo.config.mode
 //3.3.4.1提到过这里再重复一次 dubbo.config.mode获取配置模式，配置模式对应枚举类型ConfigMode，目前有这么几个STRICT，OVERRIDE，OVERRIDE_ALL，OVERRIDE_IF_ABSENT，IGNORE，这个配置决定了属性覆盖的顺序，当有同一个配置key多次出现时候，以最新配置为准，还是以最老的那个配置为准，还是配置重复则抛出异常，默认值为严格模式STRICT重复则抛出异常
 String configModeStr = (String) configuration.getProperty(ConfigKeys.DUBBO_CONFIG_MODE);
 try {
 if (StringUtils.hasText(configModeStr)) {
 this.configMode = ConfigMode.valueOf(configModeStr.toUpperCase());
 }
 } catch (Exception e) {
 String msg = "Illegal '" + ConfigKeys.DUBBO_CONFIG_MODE + "' config value [" + configModeStr + "], available values " + Arrays.toString(ConfigMode.values());
 logger.error(msg, e);
 throw new IllegalArgumentException(msg, e);
 }

 // dubbo.config.ignore-duplicated-interface
 //忽略重复的接口（服务/引用）配置。默认值为false
 String ignoreDuplicatedInterfaceStr = (String) configuration
 .getProperty(ConfigKeys.DUBBO_CONFIG_IGNORE_DUPLICATED_INTERFACE);
 if (ignoreDuplicatedInterfaceStr != null) {
 this.ignoreDuplicatedInterface = Boolean.parseBoolean(ignoreDuplicatedInterfaceStr);
 }

 // print 打印配置信息到控制台
 Map<String, Object> map = new LinkedHashMap<>();
 map.put(ConfigKeys.DUBBO_CONFIG_MODE, configMode);
 map.put(ConfigKeys.DUBBO_CONFIG_IGNORE_DUPLICATED_INTERFACE, this.ignoreDuplicatedInterface);
 logger.info("Config settings: " + map);
 }

3.4.2.3 模块配置扩展的初始化

initModuleExt();

private void initModuleExt() {
//目前这里的扩展只支持有一个类型ModuleEnvironment
 Set<ModuleExt> exts = this.getExtensionLoader(ModuleExt.class).getSupportedExtensionInstances();
 for (ModuleExt ext : exts) {
 ext.initialize();
 }
 }

ModuleEnvironment的初始化

 @Override
 public void initialize() throws IllegalStateException {
 this.orderedPropertiesConfiguration = new OrderedPropertiesConfiguration(moduleModel);
 }

OrderedPropertiesConfiguration对象的创建

public OrderedPropertiesConfiguration(ModuleModel moduleModel) {
 this.moduleModel = moduleModel;
 refresh();
 }

 public void refresh() {
 properties = new Properties();
 //有序的配置提供器扩展获取
 ExtensionLoader<OrderedPropertiesProvider> propertiesProviderExtensionLoader = moduleModel.getExtensionLoader(OrderedPropertiesProvider.class);
 Set<String> propertiesProviderNames = propertiesProviderExtensionLoader.getSupportedExtensions();
 if (CollectionUtils.isEmpty(propertiesProviderNames)) {
 return;
 }
 List<OrderedPropertiesProvider> orderedPropertiesProviders = new ArrayList<>();
 for (String propertiesProviderName : propertiesProviderNames) {
 orderedPropertiesProviders.add(propertiesProviderExtensionLoader.getExtension(propertiesProviderName));
 }

 //order the propertiesProvider according the priority descending
 //根据优先级进行排序，值越小优先级越高
 orderedPropertiesProviders.sort((a, b) -> b.priority() - a.priority());


 //override the properties. 目前没看到有具体的扩展实现
 for (OrderedPropertiesProvider orderedPropertiesProvider : orderedPropertiesProviders) {
 properties.putAll(orderedPropertiesProvider.initProperties());
 }

 }

原文： «框架,应用程序,模块领域模型Model对象的初始化»

Blog: 02-启动服务前服务配置ServiceConfig类型是如何初始化的?

Tue, 02 Aug 2022 00:00:00 +0000

2-启动服务前服务配置ServiceConfig类型是如何初始化的?

2.1 示例源码回顾:

为了方便我们理解记忆,这里先来回顾下上一章我们说的示例代码,如下所示:

public class Application {
 public static void main(String[] args) throws Exception {
 startWithBootstrap();
 }
 private static void startWithBootstrap() {
 ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
 service.setInterface(DemoService.class);
 service.setRef(new DemoServiceImpl());
 DubboBootstrap bootstrap = DubboBootstrap.getInstance();
 bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
 .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
 .service(service)
 .start()
 .await();
 }
}

上面这几行代码虽然看似简单,仅仅几行的启动,但是完全掌握也得下一翻大功夫,接下来我们重点看启动代码中的第一行,创建一个服务配置对象:

ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();

2.2 了解一下服务配置的建模

下面是一个简单的UML继承关系图,当然这个图很是简单的,这里仅仅列出了当前服务提供者的相关服务配置继承关系, 服务提供者独有的配置标注颜色为蓝色,一些可能与服务引用配置所共有的父类型我们用红色背景,当然这里为了简便起见不会提起服务引用相关的配置类型,这里列举了如下服务提供者类型,他们各司其职:

图2.1 服务引用类继承关系UML

AbstractConfig
- 抽象的配置类型,也是最顶层的服务配置类型,封装着解析配置的实用方法和公共方法,比如服务id的设置,服务标签名字的处理,服务参数的添加,属性的提取等等
AbstractMethodConfig
- 抽象的方法配置,同样这个类型也是见名知意,服务方法的相关配置处理,这个类型主要用于对服务方法的一些配置信息建模比如服务方法的调用超时时间,重试次数,最大并发调用数,负载均衡策略,是否异步调用,是否确认异步发送等等配置信息.
AbstractInterfaceConfig
- 抽象的接口配置,与前面介绍的方法配置类似,这个类型是对服务接口的建模,主要的配置信息有暴漏服务的接口名字,服务接口的版本号,客户/提供方将引用的远程服务分组,服务元数据,服务接口的本地impl类名,服务监控配置,对于生成动态代理的策略，可以选择两种策略：jdk和javassist,容错类型等等配置
AbstractServiceConfig - 抽象的服务配置,这个就与我们的服务提供者有了具体的关系了,主要记录了一些服务提供者的公共配置,如服务版本,服务分组,服务延迟注册毫秒数,是否暴漏服务,服务权重,是否为动态服务,服务协议类型,是否注册等等.
ServiceConfigBase - 服务的基础配置类,这个类型仍旧是个抽象的类型提取了一些基础的配置:导出服务的接口类,服务名称,接口实现的引用类型,提供者配置,是否是通用服务GenericService
ServiceConfig - 服务配置实现类, 上面的类型都是抽象类型不能做为具体存在的事物,这个类型是我们出现的第一个服务配置实现类型,服务配置实现类已经从父类型中继承了这么多的属性,这里主要为实现服务提供了一些配置如服务的协议配置,服务的代理工厂JavassistProxyFactory是将生成导出服务代理的ProxyFactory实现，是其默认实现,服务提供者模型,是否导出服务,导出的服务列表,服务监听器等等.
ServiceBean - 服务工厂Bean ,这个主要是Spring模块来简化配置的一个服务工厂Bean这里就先不详细介绍Spring相关的配置. -

2.3 ServiceConfig构造器的初始化调用链

有了上面的类型继承关系我们就比较好分析了,接下来我们开始创建服务配置对象如下代码所示:

ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();

根据Java基础的构造器知识,在每个构造器的第一行都会有个super方法来调用父类的构造器,当前这个super方法我们可以不写但是Java编译器底层还是会为我们默认加上这么一行super()代码来调用父类构造器的.

对于上面我提到的这几个构造器根据代码被调用的先后顺序,这里重点说几个重要的,这里我仍旧按代码执行的先后顺序来说:

2.3.1 父类型AbstractMethodConfig构造器的初始化

根据super调用链这里先来看AbstractMethodConfig抽象方法配置

 public AbstractMethodConfig() {
 super(ApplicationModel.defaultModel().getDefaultModule());
 }

在这个构造器中只有个super方法用来调用父类型的构造器,但是在调用之前会先使用代码 ApplicationModel.defaultModel().getDefaultModule() 创建一个模块模型对象ModuleModel 关于模型对象的细节我们会在下个章节来说,这里我们继续来看调用链

2.3.2 最顶层类型AbstractConfig构造器的初始化

AbstractConfig的构造器初始化一共有两个,第一个步骤就是创建一个应用程序模型对象ApplicationModel,刚刚我们在AbstractMethodConfig的构造器中了解到使用这个代码ApplicationModel.defaultModel().getDefaultModule()创建了个模块模型对象ModuleModel,具体他们细节我们下一章细说,了解了子类型AbstractMethodConfig的构造器是带参数的那我们就直接看第二个构造器

public AbstractConfig() {
 this(ApplicationModel.defaultModel());
 }

将会调用第二个构造器初始化域模型

 public AbstractConfig(ScopeModel scopeModel) {
 this.setScopeModel(scopeModel);
 }

当前类型设置ScopeModel类型对象

 public final void setScopeModel(ScopeModel scopeModel) {
 //第一次初始化的当前成员变量是空的可以设置变量
 if (this.scopeModel != scopeModel) {
 //检查参数是否合法
 checkScopeModel(scopeModel);
 //初始化对象
 ScopeModel oldScopeModel = this.scopeModel;
 this.scopeModel = scopeModel;
 // reinitialize spi extension and change referenced config's scope model
 //被子类重写的方法,根据多态会调用具体子类型的这个方法我们下面来看
 //子类应该重写此方法以初始化其SPI扩展并更改引用的配置的范围模型。
 this.postProcessAfterScopeModelChanged(oldScopeModel, this.scopeModel);
 }
 }

检查ScopeModel参数是否合法,合法的参数是不能为空并且必须是ApplicationModel类型或者子类型

 protected void checkScopeModel(ScopeModel scopeModel) {
 if (scopeModel == null) {
 throw new IllegalArgumentException("scopeModel cannot be null");
 }
 if (!(scopeModel instanceof ApplicationModel)) {
 throw new IllegalArgumentException("Invalid scope model, expect to be a ApplicationModel but got: " + scopeModel);
 }
 }

2.3.2.1 重写的postProcessAfterScopeModelChanged调用逻辑

当ScopeModel模型对象发生了改变,上面调用了postProcessAfterScopeModelChanged方法来通知模型对象改变的时候要执行的操作,根据多态重写的逻辑我们从实现类的postProcessAfterScopeModelChanged来看,在下面的调用链路中部分父类型并未实现postProcessAfterScopeModelChanged方法我们就直接忽略了

第一个被调用到的是ServiceConfig类型的postProcessAfterScopeModelChanged方法

 @Override
 protected void postProcessAfterScopeModelChanged(ScopeModel oldScopeModel, ScopeModel newScopeModel) {
 super.postProcessAfterScopeModelChanged(oldScopeModel, newScopeModel);
 //初始化当前协议对象,通过扩展机制获取协议Protocol类型的对象
 protocolSPI = this.getExtensionLoader(Protocol.class).getAdaptiveExtension();
 //初始化当前代理工厂对象,通过扩展机制获取ProxyFactory类型的对象
 proxyFactory = this.getExtensionLoader(ProxyFactory.class).getAdaptiveExtension();
 }

第二个被调用到的方法为ServiceConfigBase的postProcessAfterScopeModelChanged方法

@Override
 protected void postProcessAfterScopeModelChanged(ScopeModel oldScopeModel, ScopeModel newScopeModel) {
 super.postProcessAfterScopeModelChanged(oldScopeModel, newScopeModel);
 //当服务提供者配置对象不为空时候为服务提供者对象设置域模型,这里服务提供者对象仍旧为空,这个一般用在兼容Dubbo低版本
 if (this.provider != null && this.provider.getScopeModel() != scopeModel) {
 this.provider.setScopeModel(scopeModel);
 }
 }

第三个被调用到的是AbstractInterfaceConfig类型的postProcessAfterScopeModelChanged方法

@Override
 protected void postProcessAfterScopeModelChanged(ScopeModel oldScopeModel, ScopeModel newScopeModel) {
 super.postProcessAfterScopeModelChanged(oldScopeModel, newScopeModel);
 // remove this config from old ConfigManager
// if (oldScopeModel != null && oldScopeModel instanceof ModuleModel) {
// ((ModuleModel)oldScopeModel).getConfigManager().removeConfig(this);
// }

 // change referenced config's scope model
 //获取应用程序模型对象
 ApplicationModel applicationModel = ScopeModelUtil.getApplicationModel(scopeModel);
 //为配置中心对象设置ApplicationModel类型对象(当前阶段配置中心配置对象为空)
 if (this.configCenter != null && this.configCenter.getScopeModel() != applicationModel) {
 this.configCenter.setScopeModel(applicationModel);
 }
 //为元数据配置对象设置ApplicationModel类型对象(当前阶段数据配置配置对象为空)
 if (this.metadataReportConfig != null && this.metadataReportConfig.getScopeModel() != applicationModel) {
 this.metadataReportConfig.setScopeModel(applicationModel);
 }
 //为MonitorConfig服务监控配置对象设置ApplicationModel类型对象(当前阶段数据配置配置对象为空)
 if (this.monitor != null && this.monitor.getScopeModel() != applicationModel) {
 this.monitor.setScopeModel(applicationModel);
 }
 //这个if判断和上面的上面是重复的估计是写代码人加班加的太久了,没注意看
 if (this.metadataReportConfig != null && this.metadataReportConfig.getScopeModel() != applicationModel) {
 this.metadataReportConfig.setScopeModel(applicationModel);
 }
 //如果注册中心配置列表不为空则为每个注册中心配置设置一个ApplicationModel类型对象(当前注册中心对象都为空)
 if (CollectionUtils.isNotEmpty(this.registries)) {
 this.registries.forEach(registryConfig -> {
 if (registryConfig.getScopeModel() != applicationModel) {
 registryConfig.setScopeModel(applicationModel);
 }
 });
 }
 }

最后被调用到的是最顶层父类型AbstractConfig的postProcessAfterScopeModelChanged方法这个方法什么也没干只是在父类型创建的模版方法让子类型来重写用的

protected void postProcessAfterScopeModelChanged(ScopeModel oldScopeModel, ScopeModel newScopeModel) {
 // remove this config from old ConfigManager
// if (oldScopeModel != null && oldScopeModel instanceof ApplicationModel) {
// ((ApplicationModel)oldScopeModel).getApplicationConfigManager().removeConfig(this);
// }
 }

2.3.3 ServiceConfigBase构造器的初始化

public ServiceConfigBase() {
 //服务元数据对象创建
 serviceMetadata = new ServiceMetadata();
 //为服务元数据对象
 serviceMetadata.addAttribute("ORIGIN_CONFIG", this);
 }

注意， ServiceMetadata这个类目前在Dubbo中没有用法。与服务级别相关的数据，例如名称、版本、业务服务的类加载器、安全信息等，还带有用于扩展的AttributeMap。

服务配置对象的创建过程就这样结束了,当然有一些细节会放到后面来写 上面主要顺序是按照代码执行的顺序来写的部分地方可能稍微做了调整,如果有条件的同学一定要自己进行DEBUG了解下细节.

关于服务配置官网提供了xml的配置信息这里我拷贝过来,可以做为参考: 当然这个配置不是最新的比如服务配置的标签配置tag, warmup 预热时间单位毫秒,暂时还没有说明

属性	对应URL参数	类型	是否必填	缺省值	作用	描述	兼容性
interface		class	必填		服务发现	服务接口名	1.0.0以上版本
ref		object	必填		服务发现	服务对象实现引用	1.0.0以上版本
version	version	string	可选	0.0.0	服务发现	服务版本，建议使用两位数字版本，如：1.0，通常在接口不兼容时版本号才需要升级	1.0.0以上版本
group	group	string	可选		服务发现	服务分组，当一个接口有多个实现，可以用分组区分	1.0.7以上版本
path	`<path>`	string	可选	缺省为接口名	服务发现	服务路径 (注意：1.0不支持自定义路径，总是使用接口名，如果有1.0调2.0，配置服务路径可能不兼容)	1.0.12以上版本
delay	delay	int	可选	0	性能调优	延迟注册服务时间(毫秒) ，设为-1时，表示延迟到Spring容器初始化完成时暴露服务	1.0.14以上版本
timeout	timeout	int	可选	1000	性能调优	远程服务调用超时时间(毫秒)	2.0.0以上版本
retries	retries	int	可选	2	性能调优	远程服务调用重试次数，不包括第一次调用，不需要重试请设为0	2.0.0以上版本
connections	connections	int	可选	100	性能调优	对每个提供者的最大连接数，rmi、http、hessian等短连接协议表示限制连接数，dubbo等长连接协表示建立的长连接个数	2.0.0以上版本
loadbalance	loadbalance	string	可选	random	性能调优	负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮询，最少活跃调用	2.0.0以上版本
async	async	boolean	可选	false	性能调优	是否缺省异步执行，不可靠异步，只是忽略返回值，不阻塞执行线程	2.0.0以上版本
local	local	class/boolean	可选	false	服务治理	设为true，表示使用缺省代理类名，即：接口名 + Local后缀，已废弃，请使用stub	2.0.0以上版本
stub	stub	class/boolean	可选	false	服务治理	设为true，表示使用缺省代理类名，即：接口名 + Stub后缀，服务接口客户端本地代理类名，用于在客户端执行本地逻辑，如本地缓存等，该本地代理类的构造函数必须允许传入远程代理对象，构造函数如：public XxxServiceStub(XxxService xxxService)	2.0.0以上版本
mock	mock	class/boolean	可选	false	服务治理	设为true，表示使用缺省Mock类名，即：接口名 + Mock后缀，服务接口调用失败Mock实现类，该Mock类必须有一个无参构造函数，与Local的区别在于，Local总是被执行，而Mock只在出现非业务异常(比如超时，网络异常等)时执行，Local在远程调用之前执行，Mock在远程调用后执行。	2.0.0以上版本
token	token	string/boolean	可选	false	服务治理	令牌验证，为空表示不开启，如果为true，表示随机生成动态令牌，否则使用静态令牌，令牌的作用是防止消费者绕过注册中心直接访问，保证注册中心的授权功能有效，如果使用点对点调用，需关闭令牌功能	2.0.0以上版本
registry		string	可选	缺省向所有registry注册	配置关联	向指定注册中心注册，在多个注册中心时使用，值为dubbo:registry的id属性，多个注册中心ID用逗号分隔，如果不想将该服务注册到任何registry，可将值设为N/A	2.0.0以上版本
provider		string	可选	缺省使用第一个provider配置	配置关联	指定provider，值为dubbo:provider的id属性	2.0.0以上版本
deprecated	deprecated	boolean	可选	false	服务治理	服务是否过时，如果设为true，消费方引用时将打印服务过时警告error日志	2.0.5以上版本
dynamic	dynamic	boolean	可选	true	服务治理	服务是否动态注册，如果设为false，注册后将显示后disable状态，需人工启用，并且服务提供者停止时，也不会自动取消册，需人工禁用。 2.0.5以上版本
accesslog	accesslog	string/boolean	可选	false	服务治理	设为true，将向logger中输出访问日志，也可填写访问日志文件路径，直接把访问日志输出到指定文件	2.0.5以上版本
owner	owner	string	可选		服务治理	服务负责人，用于服务治理，请填写负责人公司邮箱前缀	2.0.5以上版本
document	document	string	可选		服务治理	服务文档URL	2.0.5以上版本
weight	weight	int	可选		性能调优	服务权重	2.0.5以上版本
executes	executes	int	可选	0	性能调优	服务提供者每服务每方法最大可并行执行请求数	2.0.5以上版本
proxy	proxy	string	可选	javassist	性能调优	生成动态代理方式，可选：jdk/javassist	2.0.5以上版本
cluster	cluster	string	可选	failover	性能调优	集群方式，可选：failover/failfast/failsafe/failback/forking	2.0.5以上版本
filter	service.filter	string	可选	default	性能调优	服务提供方远程调用过程拦截器名称，多个名称用逗号分隔	2.0.5以上版本
listener	exporter.listener	string	可选	default	性能调优	服务提供方导出服务监听器名称，多个名称用逗号分隔
protocol		string	可选		配置关联	使用指定的协议暴露服务，在多协议时使用，值为dubbo:protocol的id属性，多个协议ID用逗号分隔	2.0.5以上版本
layer	layer	string	可选	服务治理	服务提供者所在的分层。如：biz、dao、intl:web、china:acton。	2.0.7以上版本
register	register	boolean	可选	true	服务治理	该协议的服务是否注册到注册中心	2.0.8以上版本

原文： «ServiceConfig对象的建模»

Blog: 01 从一个服务提供者的Demo说起

Mon, 01 Aug 2022 00:00:00 +0000

1 从一个服务提供者的Demo说起

为了更方便了解原理,我们先来编写一个Demo,从例子中来看源码实现:

1.1 启动Zookeeper

为了Demo可以正常启动,需要我们先在本地启动一个Zookeeper如下图所示:

1.2 服务提供者

接下来给大家贴一下示例源码,这个源码来源于Dubbo源码目录的 dubbo-demo/dubbo-demo-api 目录下面的dubbo-demo-api-provider子项目,这里我做了删减,方便看核心代码: 首先我们定义一个服务接口如下所示:

import java.util.concurrent.CompletableFuture;
public interface DemoService {
 /**
 * 同步处理的服务方法
 * @param name
 * @return
 */
 String sayHello(String name);

 /**
 * 用于异步处理的服务方法
 * @param name
 * @return
 */
 default CompletableFuture<String> sayHelloAsync(String name) {
 return CompletableFuture.completedFuture(sayHello(name));
 }
}

服务实现类如下:

import org.apache.dubbo.rpc.RpcContext;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.util.concurrent.CompletableFuture;

public class DemoServiceImpl implements DemoService {
 private static final Logger logger = LoggerFactory.getLogger(DemoServiceImpl.class);

 @Override
 public String sayHello(String name) {
 logger.info("Hello " + name + ", request from consumer: " + RpcContext.getServiceContext().getRemoteAddress());
 return "Hello " + name + ", response from provider: " + RpcContext.getServiceContext().getLocalAddress();
 }

 @Override
 public CompletableFuture<String> sayHelloAsync(String name) {
 return null;
 }

}

1.3 启用服务

有了服务接口之后我们来启用服务,启用服务的源码如下:

import org.apache.dubbo.common.constants.CommonConstants;
import org.apache.dubbo.config.ApplicationConfig;
import org.apache.dubbo.config.MetadataReportConfig;
import org.apache.dubbo.config.ProtocolConfig;
import org.apache.dubbo.config.RegistryConfig;
import org.apache.dubbo.config.ServiceConfig;
import org.apache.dubbo.config.bootstrap.DubboBootstrap;
import org.apache.dubbo.demo.DemoService;

public class Application {
 public static void main(String[] args) throws Exception {
 startWithBootstrap();
 }
 private static void startWithBootstrap() {
 ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
 service.setInterface(DemoService.class);
 service.setRef(new DemoServiceImpl());
 DubboBootstrap bootstrap = DubboBootstrap.getInstance();
 bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
 .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
 .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
 .service(service)
 .start()
 .await();
 }
}

1.4 启用服务后写入Zookeeper的节点数据

启动服务,这个时候我们打开Zookeeper图形化客户端来看看这个服务在Zookeeper上面写入来哪些数据,如下图: 写入Zookeper上的节点用于服务在分布式场景下的协调,这些节点是比较重要的。

服务提供者配置信息URL形式
服务消费者的配置信息URL形式
服务路由信息
配置信息

上面这个图就是Dubbo3的注册信息了,后面我们也会围绕细节来说明下,这里可以看下新增了:

/dubbo/metadata 元数据信息
/dubbo/mapping 服务和应用的映射信息
/dubbo/config 注册中心配置
/services目录应用信息

在这里可以大致了解下,在后面会有更详细的源码解析这个示例代码.通过透析代码来看透Dubbo3服务注册原理,服务提供原理。

原文： «从一个服务提供者的Demo说起»

Blog: 浅析 Dubbo 3.0 中接口级地址推送性能的优化

Thu, 23 Jun 2022 00:00:00 +0000

URL 简介

在阐述地址推送性能的具体优化之前，我们有必要先了解一下与之息息相关的内容 — URL。

定义

在不谈及 dubbo 时，我们大多数人对 URL 这个概念并不会感到陌生。统一资源定位器 (RFC1738――Uniform Resource Locators (URL))应该是最广为人知的一个 RFC 规范，它的定义也非常简单。

因特网上的可用资源可以用简单字符串来表示，该文档就是描述了这种字符串的语法和语义。而这些字符串则被称为：“统一资源定位器”（URL）

一个标准的 URL 格式至多可以包含如下的几个部分

protocol://username:password@host:port/path?key=value&key=value

一些典型 URL

http://www.facebook.com/friends?param1=value1&amp;param2=value2
https://username:password@10.20.130.230:8080/list?version=1.0.0
ftp://username:password@192.168.1.7:21/1/read.txt

当然，也有一些不太符合常规的 URL，也被归类到了 URL 之中

192.168.1.3:20880
url protocol = null, url host = 192.168.1.3, port = 20880, url path = null

file:///home/user1/router.js?type=script
url protocol = file, url host = null, url path = home/user1/router.js

file://home/user1/router.js?type=script<br>
url protocol = file, url host = home, url path = user1/router.js

file:///D:/1/router.js?type=script
url protocol = file, url host = null, url path = D:/1/router.js

file:/D:/1/router.js?type=script
同上 file:///D:/1/router.js?type=script

/home/user1/router.js?type=script
url protocol = null, url host = null, url path = home/user1/router.js

home/user1/router.js?type=script
url protocol = null, url host = home, url path = user1/router.js

Dubbo 中的 URL

在 dubbo 中，也使用了类似的 URL，主要用于在各个扩展点之间传递数据，组成此 URL 对象的具体参数如下:

protocol：一般是 dubbo 中的各种协议如：dubbo thrift http zk
username/password：用户名/密码
host/port：主机/端口
path：接口名称
parameters：参数键值对

一些典型的 Dubbo URL

dubbo://192.168.1.6:20880/moe.cnkirito.sample.HelloService?timeout=3000
描述一个 dubbo 协议的服务

zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=demo-consumer&dubbo=2.0.2&interface=org.apache.dubbo.registry.RegistryService&pid=1214&qos.port=33333&timestamp=1545721981946
描述一个 zookeeper 注册中心

consumer://30.5.120.217/org.apache.dubbo.demo.DemoService?application=demo-consumer&category=consumers&check=false&dubbo=2.0.2&interface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=1209&qos.port=33333&side=consumer&timestamp=1545721827784
描述一个消费者

可以说，任意的一个领域中的一个实现都可以认为是一类 URL，dubbo 使用 URL 来统一描述了元数据，配置信息，贯穿在整个框架之中。

Dubbo 2.7

URL 结构

在 Dubbo 2.7 中，URL 的结构非常简单，一个类就涵盖了所有内容，如下图所示。

地址推送模型

接下来我们再来看看 Dubbo 2.7 中的地址推送模型方案，主要性能问题由下列过程引起。

上图中主要的流程为 1、用户新增/删除DemoService的某个具体Provider实例（常见于扩容缩容、网络波动等原因） 2、ZooKeeper将DemoService下所有实例推送给Consumer端 3、Consumer端根据Zookeeper推送的数据重新全量生成URL 根据该方案可以看出在Provider实例数量较小时，Consumer端的影响比较小，但当某个接口有大量Provider实例时，便会有大量不必要的URL创建过程。而Dubbo 3.0中则主要针对上述推送流程进行了一系列的优化，接下来我们便对其进行具体的讲解。

Dubbo 3.0

URL 结构

当然，地址推送模型的优化依然离不开 URL 的优化，下图是Dubbo 3.0中优化地址推送模型的过程中使用的新的URL结构。

根据上图我们可以看出，在 Dubbo 2.7 的 URL 中的几个重要属性在 Dubbo 3.0 中已经不存在了，取而代之的是 URLAddress 和 URLParam 两个类。原来的 parameters 属性被移动到了 URLParam 中的 params，其他的属性则移动到了 URLAddress 及其子类中。再来介绍 URL 新增的 3 个子类，其中 InstanceAddressURL 属于应用级接口地址，本篇章中不做介绍。而 ServiceConfigURL 及 ServiceAddressURL 主要的差别就是，ServiceConfigURL 是程序读取配置文件时生成的 URL。而 ServiceAddressURL 则是注册中心推送一些信息（如 providers）过来时生成的 URL。在这里我们顺便提一下为什么会有 DubboServiceAddressURL 这个子类，按照目前的结构来看，ServiceAddressURL 只有这一个子类，所以完全可以将他们两个的属性全都放到 ServiceAddressURL 中，那么为什么还要有这个子类呢？其实是 Dubbo 3.0 为了兼容 HSF 框架所设计的，抽象出了一个 ServiceAddressURL，而 HSF 框架则可以继承这个类，使用 HSFServiceAddressURL，当然，这个类目前没有体现出来，所以此处我们简单一提，不过多讲解。那么，我们接下来就讨论一下 Dubbo 3.0 为什么要改为此种数据结构，并且该结构和地址推送模型的优化有何关联性吧！

地址推送模型的优化

URL 结构上的优化

我们在上小节中的类图里看到虽然原来的属性都被移到了 URLAddress 和 URLParam 里，但是 URL 的子类依然多了几个属性，这几个属性自然也是为了优化而新增的，那么这里就讲讲这几个属性的作用。 ServiceConfigURL：这个子类中新增了 attribute 这个属性，这个属性主要是针对 URLParam 的 params 做了冗余，仅仅只是将 value 的类型从 String 改为了 Object，减少了代码中每次获取 parameters 的格式转换消耗。 ServiceAddressURL：这个子类及其对应的其他子类中则新增了 overrideURL 和 consumerURL 属性。其中 consumerURL 是针对 consumer 端的配置信息，overrideURL 则是在 Dubbo Admin 上进行动态配置时写入的值，当我们调用 URL 的 getParameter() 方法时，优先级为 overrideURL > consumerURL > urlParam。在 Dubbo 2.7 时，动态配置属性会替换 URL 中的属性，及当你有大量 URL 时消耗也是不可忽视的，而此处的 overrideURL 则避免了这种消耗，因为所有 URL 都会共同使用同一个对象。

多级缓存

缓存是 Dubbo 3.0 在 URL 上做的优化的重点，同时这部分也是直接针对地址推送模型所做的优化，那么接下来我们就开始来介绍一下多级缓存的具体实现。首先，多级缓存主要体现在 CacheableFailbackRegistry 这个类之中，它直接继承于 FailbackRegistry，以 Zookeeper 为例，我们看看 Dubbo 2.7 和 Dubbo 3.0 继承结构的区别。

可以看到在 CacheableFailbackRegistry 缓存中，我们新增了 3 个缓存属性 stringAddress，stringParam 和 stringUrls。我们通过下图来描述这 3 个缓存的具体使用场景。

在该方案下，我们使用了 3 个纬度的缓存数据(URL 字符串缓存、URL 地址缓存、URL 参数缓存)，这样一来，在大部分情况下都能有效利用到缓存中的数据，减少了 Zookeeper 重复通知的消耗。

延迟通知

除了上面提到的优化之外，其实另外还有两个小小的优化。第一个是解析 URL 时可以直接使用编码后的 URL 字符串字节进行解析，而在 Dubbo 2.7 中，所有编码后的 URL 字符串都需要经过解码才可以正常解析为 URL 对象。该方式也直接减少了 URL 解码过程的开销。第二个则是 URL 变更后的通知机制增加了延迟，下图以Zookeeper为例讲解了实现细节。

在该方案中，当 Consumer 接收 Zookeeper 的变更通知后会主动休眠一段时间，而这段时间内的变更在休眠结束后只会保留最后一次变更，Consumer 便会使用最后一次变更来进行监听实例的更新，以此方法来减少大量 URL 的创建开销。

字符串重用

在旧版本实现中，不同的 URL 中属性相同的字符串会存储在堆内不同的地址中，如 protocol、path 等，当有大量 provider 的情况下，Consumer 端的堆内会存在大量的重复字符串，导致内存利用率低下，所以此处提供了另一个优化方式，即字符串重用。而它的实现方式也非常的简单，让我们来看看对应的代码片段。

public class URLItemCache {
 private static final Map<String, String> PATH_CACHE = new LRUCache<>(10000);
 private static final Map<String, String> PROTOCOL_CACHE = new ConcurrentHashMap<>();

 // 省略无关代码片段

 public static String checkProtocol(String _protocol) {
 if (_protocol == null) {
 return _protocol;
 }
 String cachedProtocol = PROTOCOL_CACHE.putIfAbsent(_protocol, _protocol);
 if (cachedProtocol != null) {
 return cachedProtocol;
 }
 return _protocol;
 }

 public static String checkPath(String _path) {
 if (_path == null) {
 return _path;
 }
 String cachedPath = PATH_CACHE.putIfAbsent(_path, _path);
 if (cachedPath != null) {
 return cachedPath;
 }
 return _path;
 }
}

由如上代码片段可以得知，字符串重用即为简单地使用了 Map 来存储对应的缓存值，当你使用了相同的字符串时，便会从 Map 中获取早已存在的对象返回给调用方，由此便可以减少堆内存中重复的字符串数以达到优化的效果。

优化结果

这里优化结果我引用了《Dubbo 3.0 前瞻：服务发现支持百万集群，带来可伸缩微服务架构》这篇文章中的两副图来说明，下图模拟了在220万个 Provider 接口的情况下，接口数据不断变更导致的 Consumer 端的消耗，我们看到整个 Consumer 端几乎被 Full GC 占满了，严重影响了性能。

那么我们再来看看 Dubbo 3.0 中对 URL 进行优化后同一个环境下的压测结果，如下图所示。

我们明显可以看到 Full GC 的频率减少到了只有 3 次，大大提升了性能。当然，该文章中还有其他方面的对比，此处便不一一引用了，感兴趣的读者可以自行去阅读该文章。

Blog: 如何通过 Apache ShenYu 网关代理 Dubbo 服务

Wed, 04 May 2022 00:00:00 +0000

1. 介绍

Apache ShenYu

Apache ShenYu(Incubating) 是一个异步的，高性能的，跨语言的，响应式的 API 网关。兼容各种主流框架体系，支持热插拔，用户可以定制化开发，满足用户各种场景的现状和未来需求，经历过大规模场景的锤炼。

2021年5月，ShenYu捐献给 Apache 软件基金会，Apache 基金会全票通过，顺利进入孵化器。

Apache Dubbo

Apache Dubbo 是一款微服务开发框架，它提供了 RPC 通信与微服务治理两大关键能力。这意味着，使用 Dubbo 开发的微服务，将具备相互之间的远程发现与通信能力，同时利用 Dubbo 提供的丰富服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。

2. Dubbo快速开始

本小节介绍如何将Dubbo服务接入到ShenYu网关，您可以直接在工程下找到本小节的示例代码。

2.1 启动shenyu-admin

shenyu-admin是Apache ShenYu后台管理系统，启动的方式有多种，本文通过 [本地部署](https://shenyu.apache.org/zh/docs/deployment/deployment-local) 的方式启动。启动成功后，需要在基础配置->插件管理中，把dubbo 插件设置为开启，并设置你的注册地址，请确保注册中心已经开启。

2.2 启动shenyu网关

在这里通过源码的方式启动，直接运行shenyu-bootstrap中的ShenyuBootstrapApplication。

在启动前，请确保网关已经引入相关依赖。如果客户端是apache dubbo，注册中心使用zookeeper，请参考如下配置：

 <!-- apache shenyu apache dubbo plugin start-->
 <dependency>
 <groupId>org.apache.shenyu</groupId>
 <artifactId>shenyu-spring-boot-starter-plugin-apache-dubbo</artifactId>
 <version>${project.version}</version>
 </dependency>
 <dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo</artifactId>
 <version>2.7.5</version>
 </dependency>
 <!-- Dubbo zookeeper registry dependency start -->
 <dependency>
 <groupId>org.apache.curator</groupId>
 <artifactId>curator-client</artifactId>
 <version>4.0.1</version>
 <exclusions>
 <exclusion>
 <artifactId>log4j</artifactId>
 <groupId>log4j</groupId>
 </exclusion>
 </exclusions>
 </dependency>
 <dependency>
 <groupId>org.apache.curator</groupId>
 <artifactId>curator-framework</artifactId>
 <version>4.0.1</version>
 </dependency>
 <dependency>
 <groupId>org.apache.curator</groupId>
 <artifactId>curator-recipes</artifactId>
 <version>4.0.1</version>
 </dependency>
 <!-- Dubbo zookeeper registry dependency end -->
 <!-- apache dubbo plugin end-->

2.3 启动shenyu-examples-dubbo

以官网提供的例子为例 shenyu-examples-dubbo 。假如dubbo服务定义如下：

<beans /* ...... * />

 <dubbo:application name="test-dubbo-service"/>
 <dubbo:registry address="${dubbo.registry.address}"/>
 <dubbo:protocol name="dubbo" port="20888"/>

 <dubbo:service timeout="10000" interface="org.apache.shenyu.examples.dubbo.api.service.DubboTestService" ref="dubboTestService"/>

</beans>

声明应用服务名称，注册中心地址，使用dubbo协议，声明服务接口，对应接口实现类：

/**
 * DubboTestServiceImpl.
 */
@Service("dubboTestService")
public class DubboTestServiceImpl implements DubboTestService {

 @Override
 @ShenyuDubboClient(path = "/findById", desc = "Query by Id")
 public DubboTest findById(final String id) {
 return new DubboTest(id, "hello world shenyu Apache, findById");
 }

 //......
}

在接口实现类中，使用注解@ShenyuDubboClient向shenyu-admin注册服务。

在配置文件application.yml中的配置信息：

server:
 port: 8011
 address: 0.0.0.0
 servlet:
 context-path: /
spring:
 main:
 allow-bean-definition-overriding: true
dubbo:
 registry:
 address: zookeeper://localhost:2181 # dubbo使用的注册中心

shenyu:
 register:
 registerType: http #注册方式
 serverLists: http://localhost:9095 #注册地址
 props:
 username: admin
 password: 123456
 client:
 dubbo:
 props:
 contextPath: /dubbo
 appName: dubbo

在配置文件中，声明dubbo使用的注册中心地址，dubbo服务向shenyu-admin注册，使用的方式是http，注册地址是http://localhost:9095。

关于注册方式的使用，请参考 [应用客户端接入](https://shenyu.apache.org/docs/design/register-center-design/) 。

2.4 调用dubbo服务

shenyu-examples-dubbo项目成功启动之后会自动把加 @ShenyuDubboClient 注解的接口方法注册到网关。

打开 插件列表 -> Proxy -> dubbo 可以看到插件规则配置列表：

注册成功的选择器信息：

注册成功的规则信息：

选择器和规则是 Apache ShenYu 网关中最灵魂的东西。掌握好它，你可以对任何流量进行管理。对应为选择器与规则里面的匹配条件(conditions)，根据不同的流量筛选规则，我们可以处理各种复杂的场景。流量筛选可以从Header, URI, Query, Cookie 等等Http请求获取数据。

然后可以采用 Match，=，Regex，Groovy，Exclude等匹配方式，匹配出你所预想的数据。多组匹配添加可以使用And/Or的匹配策略。

具体的介绍与使用请看: [选择器与规则管理](https://shenyu.apache.org/zh/docs/user-guide/admin-usage/selector-and-rule) 。

发起GET请求，通过ShenYu网关调用dubbo服务：

GET http://localhost:9195/dubbo/findById?id=100
Accept: application/json

成功响应之后，结果如下：

{
 "name": "hello world shenyu Apache, findById",
 "id": "100"
}

至此，就成功的通过http请求访问dubbo服务了，ShenYu网关通过shenyu-plugin-dubbo模块将http协议转成了dubbo协议。

3. 深入理解Dubbo插件

在运行上述demo的过程中，是否存在一些疑问：

dubbo服务是如何注册到shenyu-admin？
shenyu-admin是如何将数据同步到ShenYu网关？
DubboPlugin是如何将http协议转换到到dubbo协议？

带着这些疑问，来深入理解dubbo插件。

3.1 应用客户端接入

应用客户端接入是指将微服务接入到Apache ShenYu网关，当前支持Http、 Dubbo、 Spring Cloud、 gRPC、 Motan、 Sofa、 Tars等协议的接入。

将应用客户端接入到Apache ShenYu网关是通过注册中心来实现的，涉及到客户端注册和服务端同步数据。注册中心支持Http、Zookeeper、Etcd、Consul和Nacos。默认是通过Http方式注册。

客户端接入的相关配置请参考 [客户端接入配置](https://shenyu.apache.org/zh/docs/user-guide/register-center-access) 。

3.1.1 客户端注册

在你的微服务配置中声明注册中心客户端类型，如Http或Zookeeper。应用程序启动时使用SPI方式加载并初始化对应注册中心客户端，通过实现Spring Bean相关的后置处理器接口，在其中获取需要进行注册的服务接口信息，将获取的信息放入Disruptor中。

注册中心客户端从Disruptor中读取数据，并将接口信息注册到shenyu-admin，Disruptor在其中起数据与操作解耦的作用，利于扩展。

3.1.2 服务端注册

在shenyu-admin配置中声明注册中心服务端类型，如Http或Zookeeper。当shenyu-admin启动时，读取配置类型，加载并初始化对应的注册中心服务端，注册中心服务端收到shenyu-client注册的接口信息后，将其放入Disruptor中，然后会触发注册处理逻辑，将服务接口信息更新并发布同步事件。

Disruptor在其中起到数据与操作解耦，利于扩展。如果注册请求过多，导致注册异常，也有数据缓冲作用。

3.2 数据同步原理

数据同步是指在 shenyu-admin 后台操作数据以后，使用何种策略将数据同步到 Apache ShenYu 网关。Apache ShenYu 网关当前支持ZooKeeper、WebSocket、Http长轮询、Nacos 、Etcd 和 Consul 进行数据同步。默认是通过WebSocket进行数据同步。

数据同步的相关配置请参考 [数据同步配置](https://shenyu.apache.org/zh/docs/user-guide/use-data-sync) 。

3.2.1 数据同步的意义

网关是流量请求的入口，在微服务架构中承担了非常重要的角色，网关高可用的重要性不言而喻。在使用网关的过程中，为了满足业务诉求，经常需要变更配置，比如流控规则、路由规则等等。因此，网关动态配置是保障网关高可用的重要因素。

当前数据同步特性如下：

所有的配置都缓存在 Apache ShenYu 网关内存中，每次请求都使用本地缓存，速度非常快。
用户可以在 shenyu-admin 后台任意修改数据，并马上同步到网关内存。
支持 Apache ShenYu 的插件、选择器、规则数据、元数据、签名数据等数据同步。
所有插件的选择器，规则都是动态配置，立即生效，不需要重启服务。
数据同步方式支持 Zookeeper、Http 长轮询、Websocket、Nacos、Etcd 和 Consul。

3.2.2 数据同步原理分析

下图展示了 Apache ShenYu 数据同步的流程，Apache ShenYu 网关在启动时，会从配置服务同步配置数据，并且支持推拉模式获取配置变更信息，然后更新本地缓存。管理员可以在管理后台（shenyu-admin），变更用户权限、规则、插件、流量配置，通过推拉模式将变更信息同步给 Apache ShenYu 网关，具体是 push 模式，还是 pull 模式取决于使用哪种同步方式。

在最初的版本中，配置服务依赖 Zookeeper 实现，管理后台将变更信息 push 给网关。而现在可以支持 WebSocket、Http长轮询、Zookeeper、Nacos、Etcd 和 Consul，通过在配置文件中设置 shenyu.sync.${strategy} 指定对应的同步策略，默认使用 webosocket 同步策略，可以做到秒级数据同步。但是，有一点需要注意的是，Apache ShenYu网关和 shenyu-admin 必须使用相同的同步策略。

如下图所示，shenyu-admin 在用户发生配置变更之后，会通过 EventPublisher 发出配置变更通知，由 EventDispatcher 处理该变更通知，然后根据配置的同步策略(http、weboscket、zookeeper、naocs、etcd、consul)，将配置发送给对应的事件处理器。

如果是 websocket 同步策略，则将变更后的数据主动推送给 shenyu-web，并且在网关层，会有对应的 WebsocketDataHandler 处理器来处理 shenyu-admin 的数据推送。
如果是 zookeeper 同步策略，将变更数据更新到 zookeeper，而 ZookeeperSyncCache 会监听到 zookeeper 的数据变更，并予以处理。
如果是 http 同步策略，由网关主动发起长轮询请求，默认有 90s 超时时间，如果 shenyu-admin 没有数据变更，则会阻塞 http 请求，如果有数据发生变更则响应变更的数据信息，如果超过 60s 仍然没有数据变更则响应空数据，网关层接到响应后，继续发起 http 请求，反复同样的请求。

3.3 流程分析

流程分析是从源码的角度，展示服务注册流程，数据同步流程和服务调用流程。

3.3.1 服务注册流程

读取dubbo服务

使用注解@ShenyuDubboClient标记需要注册到网关的dubbo服务。

注解扫描通过ApacheDubboServiceBeanListener完成，它实现了ApplicationListener<ContextRefreshedEvent>接口，在Spring容器启动过程中，发生上下文刷新事件时，开始执行事件处理方法onApplicationEvent()。在重写的方法逻辑中，读取Dubbo服务ServiceBean，构建元数据对象和URI对象，并向shenyu-admin注册。

具体的注册逻辑由注册中心实现，请参考 [客户端接入原理](https://shenyu.apache.org/zh/docs/design/register-center-design/) 。

处理注册信息

客户端通过注册中心注册的元数据和URI数据，在shenyu-admin端进行处理，负责存储到数据库和同步给shenyu网关。Dubbo插件的客户端注册处理逻辑在ShenyuClientRegisterDubboServiceImpl中。继承关系如下：

ShenyuClientRegisterService：客户端注册服务，顶层接口；
FallbackShenyuClientRegisterService：注册失败，提供重试操作；
AbstractShenyuClientRegisterServiceImpl：抽象类，实现部分公共注册逻辑；
ShenyuClientRegisterDubboServiceImpl：实现Dubbo插件的注册；

注册信息包括选择器，规则和元数据。

整体的dubbo服务注册流程如下：

3.3.2 数据同步流程

admin更新数据

假设在在后台管理系统中，新增一条选择器数据，请求会进入SelectorController类中的createSelector()方法，它负责数据的校验，添加或更新数据，返回结果信息。

在SelectorServiceImpl类中通过createOrUpdate()方法完成数据的转换，保存到数据库，发布事件，更新upstream。

在Service类完成数据的持久化操作，即保存数据到数据库。发布变更数据通过eventPublisher.publishEvent()完成，这个eventPublisher对象是一个ApplicationEventPublisher类，这个类的全限定名是org.springframework.context.ApplicationEventPublisher，发布数据的功能正是是通过Spring相关的功能来完成的。

当事件发布完成后，会自动进入到DataChangedEventDispatcher类中的onApplicationEvent()方法，根据不同数据类型和数据同步方式进行事件处理。

网关数据同步

网关在启动时，根据指定的数据同步方式加载不同的配置类，初始化数据同步相关类。

在接收到数据后，进行反序列化操作，读取数据类型和操作类型。不同的数据类型，有不同的数据处理方式，所以有不同的实现类。但是它们之间也有相同的处理逻辑，所以可以通过模板方法设计模式来实现。相同的逻辑放在抽象类AbstractDataHandler中的handle()方法中，不同逻辑就交给各自的实现类。

新增一条选择器数据，是新增操作，会进入到SelectorDataHandler.doUpdate()具体的数据处理逻辑中。

在通用插件数据订阅者CommonPluginDataSubscriber，负责处理所有插件、选择器和规则信息

将数据保存到网关的内存中，BaseDataCache是最终缓存数据的类，通过单例模式实现。选择器数据就存到了SELECTOR_MAP这个Map中。在后续使用的时候，也是从这里拿数据。

上述逻辑用流程图表示如下：

3.3.3 服务调用流程

在Dubbo插件体系中，类继承关系如下：

ShenyuPlugin：顶层接口，定义接口方法；

AbstractShenyuPlugin：抽象类，实现插件共有逻辑；

AbstractDubboPlugin：dubbo插件抽象类，实现dubbo共有逻辑（ShenYu网关支持ApacheDubbo和AlibabaDubbo）；

ApacheDubboPlugin：ApacheDubbo插件。

org.apache.shenyu.web.handler.ShenyuWebHandler.DefaultShenyuPluginChain#execute()

通过ShenYu网关代理后，请求入口是ShenyuWebHandler，它实现了org.springframework.web.server.WebHandler接口，通过责任链设计模式将所有插件连接起来。

org.apache.shenyu.plugin.base.AbstractShenyuPlugin#execute()

当请求到网关时，判断某个插件是否执行，是通过指定的匹配逻辑来完成。在execute()方法中执行选择器和规则的匹配逻辑。

org.apache.shenyu.plugin.global.GlobalPlugin#execute()

最先被执行的是GlobalPlugin ，它是一个全局插件，在execute()方法中构建上下文信息。

org.apache.shenyu.plugin.base.RpcParamTransformPlugin#execute()

接着被执行的是RpcParamTransformPlugin ，它负责从http请求中读取参数，保存到exchange中，传递给rpc服务。在execute()方法中，执行该插件的核心逻辑：从exchange中获取请求信息，根据请求传入的内容形式处理参数。

org.apache.shenyu.plugin.dubbo.common.AbstractDubboPlugin

然后被执行的是DubboPlugin 。在doExecute()方法中，主要是检查元数据和参数。在doDubboInvoker()方法中设置特殊的上下文信息，然后开始dubbo的泛化调用。

在genericInvoker()方法中：

获取ReferenceConfig对象；
获取泛化服务GenericService对象；
构造请求参数pair对象；
发起异步的泛化调用。

通过泛化调用就可以实现在网关调用dubbo服务了。

ReferenceConfig对象是支持泛化调用的关键对象，它的初始化操作是在数据同步的时候完成的。

org.apache.shenyu.plugin.response.ResponsePlugin#execute()

最后被执行的是ResponsePlugin ，它统一处理网关的响应结果信息。处理类型由MessageWriter决定，类继承关系如下：

MessageWriter：接口，定义消息处理方法；

NettyClientMessageWriter：处理Netty调用结果；

RPCMessageWriter：处理RPC调用结果；

WebClientMessageWriter：处理WebClient调用结果；

Dubbo服务调用，处理结果是RPCMessageWriter。

org.apache.shenyu.plugin.response.strategy.RPCMessageWriter#writeWith()

在writeWith()方法中处理响应结果，获取结果或处理异常。

分析至此，关于Dubbo插件的源码分析就完成了，分析流程图如下：

4. 小结

本文从实际案例出发，由浅入深分析了ShenYu网关对Dubbo服务的代理过程。涉及到的主要知识点如下：

通过责任链设计模式执行插件；
使用模板方法设计模式实现AbstractShenyuPlugin，处理通用的操作类型；
使用单例设计模式实现缓存数据类BaseDataCache；
通过springboot starter即可引入不同的注册中心和数同步方式，扩展性很好；
通过admin支持规则热更新，方便流量管控；
Disruptor队列是为了数据与操作解耦，以及数据缓冲。

Blog: 谈谈Pixiu的Filter

Sat, 19 Feb 2022 00:00:00 +0000

Filter的生命周期

Pixiu作为一个面向云原生的gateway，通过简单的配置即可代理Http to Dubbo 2、Tripe甚至是Spring Cloud的请求。那Filter是怎样运行的呢？

首先Filter Plugin向Filter Manager注册自己**，然后Filter Manager根据配置创建好Filter Factory并持有它们，等待请求来临时，Manager创建一个一次性的用于此次请求的Filter Chain，然后利用Factory创建好Decode/Encode Filter并把它们加入链中，然后按照顺序去运行Decode Filter，然后去请求Upstream**，拿到Response再反向运行Encode Filter，让Filter可以访问到Response。

几个关键的概念：

Filter Manager

Filter的Manger。。。

// FilterManager manage filters
type FilterManager struct {
 filters map[string]HttpFilterFactory
 filtersArray []*HttpFilterFactory
}

Filter Plugin：定义了Filter的（唯一的）名字和描述如何去创建一个Filter Factory。

其实结合Filter Factory的定义，可以认为Plugin是Filter Factory的Factory

// HttpFilterPlugin describe plugin
HttpFilterPlugin interface {
 // Kind returns the unique kind name to represent itself.
 Kind() string

 // CreateFilterFactory return the filter factory
 CreateFilterFactory() (HttpFilterFactory, error)
}

Filter Factory：定义了Filter自身的配置，并且在请求来临时创建真实的Filter并把它添加到FilterChain中

Config() 的目的是能让Filter Manager能够有机会把配置交给Factory（此时golang泛型还没有落地）

Apply() 在配置被注入到Factory后，有机会对config做一些检查和提前做一些初始化的工作

PrepareFilterChain() 创建Filter并加入Filter Chain

// HttpFilterFactory describe http filter
HttpFilterFactory interface {
 // Config Expose the config so that Filter Manger can inject it, so it must be a pointer
 Config() interface{}

 // Apply After the config is injected, check it or make it to default
 Apply() error

 // PrepareFilterChain create filter and append it to FilterChain
 //
 // Be Careful !!! Do not pass the Factory's config pointer to the Filter instance,
 // Factory's config may be updated by FilterManager
 PrepareFilterChain(ctx *http.HttpContext, chain FilterChain) error
}

Decode/Encode Filter：Filter分为两个部分，Decode在实际请求Upstream之前，所以可以做一些鉴权、限流，把请求在gateway层拦截掉。Eecode则运行在获得Upstream的Response之后，所以可以对返回Log甚至修改Response。

一个Filter可以即是Decode Filter，又是Encode Filter，没有限制！

假设有A、B、C三个Filter，都是Decode/Encode Filter，如果配置的顺序是A、B、C，那么运行将会是下面这样

在Decode阶段 A->B->C，而在Encode阶段，顺序将会反过来！C->B->A

// decode filters will be invoked in the config order: A、B、C, and decode filters will be
// invoked in the reverse order: C、B、A
HttpDecodeFilter interface {
 Decode(ctx *http.HttpContext) FilterStatus
}

// HttpEncodeFilter after invoke upstream,
// decode filters will be invoked in the reverse order
HttpEncodeFilter interface {
 Encode(ctx *http.HttpContext) FilterStatus
}

更详细的，每个Decode/Encode Filter可以返回一个FilterStatus来决定继续还是就在这里停下！比如JWT鉴权，token无效时就要及时把401返回给Downstream。当然Decode Filter发出的停止命令只会终止Decode阶段，至于为什么？想想如何做一个Access Log Filter，能在请求失败时也把失败的结果记录下吧来！

怎样编写一个自定义Filter

我们来尝试写一个简单的Filter，这个Filter将会有简单的配置，在Decode阶段把请求的Body Log出来，并翻转后作为Mock的返回值。最后在Encode阶段根据配置把返回值Log出来。

1.首先创建一个Filter

type DemoFilter struct {
 logPrefix string
}

func (f *DemoFilter) Decode(ctx *contexthttp.HttpContext) filter.FilterStatus {
 body, _ := ioutil.ReadAll(ctx.Request.Body)
 logger.Infof("request body: %s", body)

 //reverse res str
 runes := []rune(string(body))
 for i := 0; i < len(runes)/2; i += 1 {
 runes[i], runes[len(runes)-1-i] = runes[len(runes)-1-i], runes[i]
 }
 reverse := string(runes)

 //mock response
 ctx.SendLocalReply(200, []byte(reverse))
 return filter.Stop
}

func (f *DemoFilter) Encode(ctx *contexthttp.HttpContext) filter.FilterStatus {
 res := ctx.SourceResp.(string)
 logger.Infof("%s: %s", f.logPrefix, res)
 return filter.Continue
}

2.创建Filter Factory

type (
 DemoFilterFactory struct {
 conf *Config
 }
 // Config describe the config of Filter
 Config struct {
 LogPrefix string `yaml:"logPrefix,omitempty"`
 }
)

func (f *DemoFilterFactory) PrepareFilterChain(ctx *contexthttp.HttpContext, chain filter.FilterChain) error {
 demo := &DemoFilter{logPrefix: f.conf.LogPrefix}

 chain.AppendDecodeFilters(demo)
 chain.AppendEncodeFilters(demo)
 return nil
}

func (f *DemoFilterFactory) Config() interface{} {
 return f.conf
}

func (f *DemoFilterFactory) Apply() error {
 return nil
}

3.创建Filter Plugin，并注册自己

//important
func init() {
 filter.RegisterHttpFilter(&Plugin{})
}

type Plugin struct {
}

func (p *Plugin) Kind() string {
 return "dgp.filters.demo"
}

func (p *Plugin) CreateFilterFactory() (filter.HttpFilterFactory, error) {
 return &DemoFilterFactory{conf: &Config{}}, nil
}

4.配置文件中配置此Filter，并启动Pixiu

static_resources:
 listeners:
 - name: "net/http"
 protocol_type: "HTTP"
 address:
 socket_address:
 address: "0.0.0.0"
 port: 8888
 filter_chains:
 filters:
 - name: dgp.filter.httpconnectionmanager
 config:
 route_config:
 routes:
 - match:
 prefix: "/"
 http_filters:
 - name: dgp.filters.demo
 config:

5.访问并查看日志与结果

curl localhost:8888/demo -d "eiv al tse’c"

c’est la vie%

日志

2022-02-19T20:20:11.900+0800 INFO demo/demo.go:62 request body: eiv al tse’c
2022-02-19T20:20:11.900+0800 INFO demo/demo.go:71 : eiv al tse’c

Blog: 从原理到操作，让你在 Apache APISIX 中代理 Dubbo 服务更便捷

Tue, 18 Jan 2022 00:00:00 +0000

背景

Apache Dubbo 是由阿里巴巴开源并捐赠给 Apache 的微服务开发框架，它提供了 RPC 通信与微服务治理两大关键能力。不仅经过了阿里电商场景中海量流量的验证，也在国内的技术公司中被广泛落地。

在实际应用场景中，Apache Dubbo 一般会作为后端系统间 RPC 调用的实现框架，当需要提供 HTTP 接口给到前端时，会通过一个「胶水层」将 Dubbo Service 包装成 HTTP 接口，再交付到前端系统。

Apache APISIX 是 Apache 软件基金会的顶级开源项目，也是当前最活跃的开源网关项目。作为一个动态、实时、高性能的开源 API 网关，Apache APISIX 提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。

得益于 Apache Dubbo 的应用场景优势，Apache APISIX 基于开源项目 tengine/mod_dubbo 模块为 Apache Dubbo 服务配备了HTTP 网关能力。通过 dubbo-proxy 插件，可以轻松地将 Dubbo Service 发布为 HTTP 服务。

如何使用

入门篇：安装使用

这里我们建议使用 Apache APISIX 2.11 版本镜像进行安装。该版本的 APISIX-Base 中已默认编译了 Dubbo 模块，可直接使用 dubbo-proxy 插件。

在接下来的操作中，我们将使用 dubbo-samples 项目进行部分展示。该项目是一些使用 Apache Dubbo 实现的 Demo 应用，本文中我们采用其中的一个子模块作为 Dubbo Provider。

在进入正式操作前，我们先简单看下 Dubbo 接口的定义、配置以及相关实现。

接口实现一览

public interface DemoService {

 /**
 * standard samples dubbo infterace demo
 * @param context pass http infos
 * @return Map<String, Object></> pass to response http
 **/
 Map<String, Object> apisixDubbo(Map<String, Object> httpRequestContext);
}

如上所示，Dubbo 接口的定义是固定的。即方法参数中 Map 表示 APISIX 传递给 Dubbo Provider 关于 HTTP request 的一些信息（如：header、body…)。而方法返回值的 Map 表示 Dubbo Provider 传递给 APISIX 要如何返回 HTTP response 的一些信息。

接口信息配置好之后可通过 XML 配置方式发布 DemoService。

<!-- service implementation, as same as regular local bean -->
<bean id="demoService" class="org.apache.dubbo.samples.provider.DemoServiceImpl"/>

<!-- declare the service interface to be exported -->
<dubbo:service interface="org.apache.dubbo.samples.apisix.DemoService" ref="demoService"/>

通过上述配置后，Consumer 可通过 org.apache.dubbo.samples.apisix.DemoService 访问其中的apisixDubbo 方法。具体接口实现如下：

public class DemoServiceImpl implements DemoService {
 @Override
 public Map<String, Object> apisixDubbo(Map<String, Object> httpRequestContext) {
 for (Map.Entry<String, Object> entry : httpRequestContext.entrySet()) {
 System.out.println("Key = " + entry.getKey() + ", Value = " + entry.getValue());
 }

 Map<String, Object> ret = new HashMap<String, Object>();
 ret.put("body", "dubbo success\n"); // http response body
 ret.put("status", "200"); // http response status
 ret.put("test", "123"); // http response header

 return ret;
 }
}

上述代码中，DemoServiceImpl 会打印接收到的 httpRequestContext，并通过返回包含有指定 Key 的 Map 对象去描述该 Dubbo 请求的 HTTP 响应。

操作步骤

启动 dubbo-samples。
在 config.yaml 文件中进行 dubbo-proxy 插件启用。

# Add this in config.yaml
plugins:
 - ... # plugin you need
 - dubbo-proxy

创建指向 Dubbo Provider 的 Upstream。

curl http://127.0.0.1:9180/apisix/admin/upstreams/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
 "nodes": {
 "127.0.0.1:20880": 1
 },
 "type": "roundrobin"
}'

为 DemoService 暴露一个 HTTP 路由。

curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
 "host": "example.org"
 "uris": [
 "/demo"
 ],
 "plugins": {
 "dubbo-proxy": {
 "service_name": "org.apache.dubbo.samples.apisix.DemoService",
 "service_version": "0.0.0",
 "method": "apisixDubbo"
 }
 },
 "upstream_id": 1
}'

使用 curl 命令请求 Apache APISIX，并查看返回结果。

curl http://127.0.0.1:9080/demo -H "Host: example.org" -X POST --data '{"name": "hello"}'

< HTTP/1.1 200 OK
< Date: Sun, 26 Dec 2021 11:33:27 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 14
< Connection: keep-alive
< test: 123
< Server: APISIX/2.11.0
<
dubbo success

:::note 说明上述代码返回中包含了 test: 123 Header，以及 dubbo success 字符串作为 Body 体。这与我们在 DemoServiceImpl 编码的预期效果一致。 :::

查看 Dubbo Provider 的日志。

Key = content-length, Value = 17
Key = host, Value = example.org
Key = content-type, Value = application/x-www-form-urlencoded
Key = body, Value = [B@70754265
Key = accept, Value = */*
Key = user-agent, Value = curl/7.80.0

:::note 说明通过 httpRequestContext 可以拿到 HTTP 请求的 Header 和 Body。其中 Header 会作为 Map 元素，而 Body 中 Key 值是固定的字符串"body"，Value 则代表 Byte 数组。 :::

进阶篇：复杂场景示例

在上述的简单用例中可以看出，我们确实通过 Apache APISIX 将 Dubbo Service 发布为一个 HTTP 服务，但是在使用过程中的限制也非常明显。比如：接口的参数和返回值都必须要是 Map<String, Object>。

那么，如果项目中出现已经定义好、但又不符合上述限制的接口，该如何通过 Apache APISIX 来暴露 HTTP 服务呢？

操作步骤

针对上述场景，我们可以通过 HTTP Request Body 描述要调用的 Service 和 Method 以及对应参数，再利用 Java 的反射机制实现目标方法的调用。最后将返回值序列化为 JSON，并写入到 HTTP Response Body 中。

这样就可以将 Apache APISIX 的「HTTP to Dubbo」能力进一步加强，并应用到所有已存在的 Dubbo Service 中。具体操作可参考下方：

为已有项目增加一个 Dubbo Service 用来统一处理 HTTP to Dubbo 的转化。

public class DubboInvocationParameter {
 private String type;
 private String value;
}

public class DubboInvocation {
 private String service;
 private String method;
 private DubboInvocationParameter[] parameters;
}

public interface HTTP2DubboService {
 Map<String, Object> invoke(Map<String, Object> context) throws Exception;
}


@Component
public class HTTP2DubboServiceImpl implements HTTP2DubboService {

 @Autowired
 private ApplicationContext appContext;

 @Override
 public Map<String, Object> invoke(Map<String, Object> context) throws Exception {
 DubboInvocation invocation = JSONObject.parseObject((byte[]) context.get("body"), DubboInvocation.class);
 Object[] args = new Object[invocation.getParameters().size()];
 for (int i = 0; i < args.length; i++) {
 DubboInvocationParameter parameter = invocation.getParameters().get(i);
 args[i] = JSONObject.parseObject(parameter.getValue(), Class.forName(parameter.getType()));
 }

 Object svc = appContext.getBean(Class.forName(invocation.getService()));
 Object result = svc.getClass().getMethod(invocation.getMethod()).invoke(args);
 Map<String, Object> httpResponse = new HashMap<>();
 httpResponse.put("status", 200);
 httpResponse.put("body", JSONObject.toJSONString(result));
 return httpResponse;
 }

}

通过如下命令请求来发起相关调用。

curl http://127.0.0.1:9080/demo -H "Host: example.org" -X POST --data '
{
 "service": "org.apache.dubbo.samples.apisix.DemoService",
 "method": "createUser",
 "parameters": [
 {
 "type": "org.apache.dubbo.samples.apisix.User",
 "value": "{'name': 'hello'}"
 }
 ]
}'

总结

本文为大家介绍了如何借助 Apache APISIX 实现 Dubbo Service 的代理，通过引入 dubbo-proxy 插件便可为 Dubbo 框架的后端系统构建更简单更高效的流量链路。

希望通过上述操作步骤和用例场景分享，能为大家在相关场景的使用提供借鉴思路。更多关于 dubbo-proxy 插件的介绍与使用可参考官方文档。

Blog: 2.7.14 发版公告

Mon, 20 Sep 2021 00:00:00 +0000

变动项

为 ServiceDiscovery 增加动态配置中心的覆盖规则。（#8389）
修复当 mock 参数中包含 ‘:’ 或者 ‘=’ 符号时无法正常使用的问题。（#8379）
修复 zone 参数对 ZoneAwareClusterInvoker 配置无法生效的问题。（#8521）
为序列化白名单检查增加开关，默认为 true。（#8537）
修复当请求超时时序列化检查的空指针异常。（#8587）
修复 NetUtils.ignoreNetworkInterface 无法处理网卡中包含 ‘(’ 符号的问题。（#8629）
统一获取本地地址的方式。（#8679）
修复当重试参数为0，依旧会重试1次的问题。（#8743）
当清除未使用的 invoker 时，立即关闭客户端。（#8756）
修复 destroy 方法以及 doOverrideIfNecessary 中的异常。（#8683）
DefaultFuture.closeChannel 根据日志级别选择是否打印请求的详细数据。（#8778）
使用 MapUtils 替换 AttachmentsAdapter（#8772）

Maven依赖变化

netty4: 4.1.51.Final -> 4.1.66.Final
netty4_ssl: 2.0.39.Final -> 2.0.40.Final
http_client: 4.5.3 -> 4.5.13
jetty: 9.4.11.v20180605 -> 9.4.43.v20210629
apollo_client: 1.1.1 -> 1.8.0
tomcat_embed: 8.5.31-> 9.0.48
commons_io: 2.6 -> 2.7
curator: 5.0.0 -> 5.1.0
hessian_lite: 3.2.8 -> 3.2.11

Blog: 3.0.2.1 发版公告

Mon, 23 Aug 2021 00:00:00 +0000

这是 3.0.2 的错误修正版本。除了以下更改外，与版本 3.0.2 完全相同。

Bug 修复

修复 nacos group 在消费者端不生效的问题 (#8533)
修复请求超时时序列化检查的 NPE (#8547)
兼容使用 dubbo-all 时未导入 farbic-io 包的问题 (#8546)

Blog: 3.0.2 发版公告

Wed, 18 Aug 2021 00:00:00 +0000

新特性

支持通过 @DubboService 注解暴露泛化服务
元数据中心xml格式的配置支持 protocol 和 port 属性
兼容 curator5 以上的版本
点对点调用支持*通配符进行匹配, 一个提供者地址可对应多个接口
为应用级别的服务发现增加动态配置去进行规则覆盖
对提供者测的动态配置覆盖规则提供开关，可以使提供者无视动态配置，不重新暴露
支持 native image
提供取消执行 shutdown hook 的开关
支持 Kubernetes Mesh 的服务治理规则
Netty 连接支持 SSL 配置

Bug 修复

DubboBootStrap start 重复调用后，动态配置被覆盖
动态配置规则被删除后，依然生效
triple 协议在暴露时会抛出空指针异常
ConfigCenterConfig.setAddress 方法会覆盖掉 username 属性
DefaultFuture.closeChannel 会销毁掉消费端测的线程池
TripleClientHandler.writeRequest 抛出空指针异常
解析3.0迁移规则异常时会抛出空指针异常
Activated Extensions 的顺序性问题
URLAddress.parse 方法在解析 ipv6 地址时存在问题
用户自定义的参数在 properties 配置中不生效
同时使用 API 模式和 Spring 模式配置时属性，Config Id 存在覆盖问题
应用级别服务发现在启动时不生效
Nacos 注册中心无法动态感知提供者的数量变化
${dubbo.application} 在 xml 文件中无法被 spring 的 placeholder 规则给解析替换
获取实例参数的顺序问题，先去获取了实例级别参数，再去获取接口级别参数
当 DubboConfigBeanInitializer 不存在时，注册应用启动监听器会抛出异常
Mock 时参数中包含 ‘:’ 或者 ‘=’ 字符时，不生效
删除 Mesh 规则时空指针异常

优化

抓住 RemovalTask 的异常，保证信号量能够释放
通过唯一 service name 检查 ReferenceConfig/ServiceConfig 是否重复
优化生成随机数的性能
如果用户使用接口级别去做服务发现，不发布应用与接口的映射数据到元数据中心
使用 StringBuilder#append(Char) 提升性能
保证 GRPC 编译的类文件中接口的顺序
优化 reference bean 的占位符解析
MergeableClusterInvoker 中使用 CompletableFuture#get(long, TimeUnit) 去提升性能
内置服务 MetadataService 不延迟暴露
优化 ConfigBean 和 Bootstrap 的启动逻辑
优化 Config 检查是否重复的逻辑
使用 Ring 数据结构去进行注册通知
优化动态配置的初始化逻辑
ConfigManager 使用 ConcurrentHashMap 去移除锁逻辑，提升 equals 和 toString 性能
优化 MetadataInfo equals 方法以及 Instance Listener
优化异步 export/refer 逻辑
使用 TreeSet 数据结构保证应用级别服务发现时应用名称的顺序一致
RegistryNotifier 的第一个十次通知不延迟
dubbo-compile 编译使用新的格式生成 stub
Mesh 服务治理规则在动态配置中心的分组和其他规则分组统一，由 DEFAULT_GROUP 改成 dubbo
使用 nacos 用作注册中心时，可以在注册中心地址中使用参数来改变在 nacos 中的分组
计算 ServiceInfo 的 reversion 时，移除运行时参数，避免生成多个 reversion
Nacos 注册中心抛出异常时，将异常封装称 RpcException 抛出
禁止动态配置中心对一些权限参数进行动态修改
优化 Config Bean 的初始化流程，并兼容 spring 3.x/4.1.x
Bootstrap.start 方法可重入，暴露或引用新的服务
将 org.apache.dubbo 包中的类默认添加到白名单中
保证生成的 Config 的 Id 唯一，并检查 Config 是否之前存在
Javaassist 兼容改变 override 声明字段
重构解码时的检查逻辑，当找不到 path, version 对应的提供者是，抛出异常
当 ApplicationModel 为 null 时，兼容 adaptive extensions

代码质量提升

感谢以下提高 Apache Dubbo 的稳定性的贡献。

#8111, #8147, #8164, #8177, #8180, #8161, #8183, #8205, #8215, #8173, #8219, #8228, #8232, #8230, #8236, #8260, #8262, #8252, #8246, #8208, #8278, #8267, #8277, #8291, #8296, #8302, #8175, #8319, #8309, #8336, #8332, #8328, #8355, #8396, #8401, #8395, #8415, #8406, #8411, #8418, #8439, #8404, #8443

Maven依赖变化

移除依赖: org.eclipse.collections:eclipse-collections
移除依赖: com.google.guava:guava
jetty: 9.4.11.v20180605 -> 9.4.43.v20210629
apollo client: 1.1.1 -> 1.8.0
snakeyaml: 1.20 -> 1.29
tomcat embed: 8.5.31 -> 8.5.69
nacos client: 2.0.0 -> 2.0.2
swagger: 1.5.19 -> 1.5.24
hessian_lite: 3.2.8 -> 3.2.11

Blog: 3.0.1 发版公告

Fri, 02 Jul 2021 00:00:00 +0000

优化

重构服务自省映射关系，支持地址迁移时直接配置上游应用名
为 Spring 扫描添加缓存
优化配置覆盖逻辑
支持 Servlet 环境下控制 Dubbo 生命周期
添加 ServiceListener 用于监听 ServiceConfig
优化方法回调参数设置

Bug 修复

启用强制校验
更正多注册中心情况下，一个注册中心启动时无地址就销毁的逻辑
移除冗余的日志输出
忽略无效的 MetadataReportConfig
修复消费端启动时 NPE 的情况
修复若干和低版本兼容问题
修复若干应用级服务发现逻辑存在的问题
优化地址迁移规则，支持应用级地址重订阅
修复 MetadataInfo 存在 NPE 的情况
修复应用级注册到注册中心的实例信息被错误覆盖的问题

代码质量提升

感谢以下提高 Apache Dubbo 的稳定性的贡献。

#8043, #8044, #8048, #8071, #8119, #8132

Blog: Dubbo3 应用级服务发现

Wed, 02 Jun 2021 00:00:00 +0000

1 服务发现（Service Discovery）概述

从 Internet 刚开始兴起，如何动态感知后端服务的地址变化就是一个必须要面对的问题，为此人们定义了 DNS 协议，基于此协议，调用方只需要记住由固定字符串组成的域名，就能轻松完成对后端服务的访问，而不用担心流量最终会访问到哪些机器 IP，因为有代理组件会基于 DNS 地址解析后的地址列表，将流量透明的、均匀的分发到不同的后端机器上。

在使用微服务构建复杂的分布式系统时，如何感知 backend 服务实例的动态上下线，也是微服务框架最需要关心并解决的问题之一。业界将这个问题称之为 - 微服务的地址发现（Service Discovery），业界比较有代表性的微服务框架如 SpringCloud、Dubbo 等都抽象了强大的动态地址发现能力，并且为了满足微服务业务场景的需求，绝大多数框架的地址发现都是基于自己设计的一套机制来实现，因此在能力、灵活性上都要比传统 DNS 丰富得多。如 SpringCloud 中常用的 Eureka， Dubbo 中常用的 Zookeeper、Nacos 等，这些注册中心实现不止能够传递地址（IP + Port），还包括一些微服务的 Metadata 信息，如实例序列化类型、实例方法列表、各个方法级的定制化配置等。

下图是微服务中 Service Discovery 的基本工作原理图，微服务体系中的实例大概可分为三种角色：服务提供者（Provider）、服务消费者（Consumer）和注册中心（Registry）。而不同框架实现间最主要的区别就体现在注册中心数据的组织：地址如何组织、以什么粒度组织、除地址外还同步哪些数据？

我们今天这篇文章就是围绕这三个角色展开，重点看下 Dubbo 中对于服务发现方案的设计，包括之前老的服务发现方案的优势和缺点，以及 Dubbo 3.0 中正在设计、开发中的全新的面向应用粒度的地址发现方案，我们期待这个新的方案能做到：

支持几十万/上百万级集群实例的地址发现
与不同的微服务体系（如 Spring Cloud）实现在地址发现层面的互通

2 Dubbo 地址发现机制解析

我们先以一个 DEMO 应用为例，来快速的看一下 Dubbo “接口粒度”服务发现与“应用粒度”服务发现体现出来的区别。这里我们重点关注 Provider 实例是如何向注册中心注册的，并且，为了体现注册中心数据量变化，我们观察的是两个 Provider 实例的场景。

应用 DEMO 提供的服务列表如下：

<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService" ref="demoService"/>
<dubbo:service interface="org.apache.dubbo.samples.basic.api.GreetingService" ref="greetingService"/>

我们示例注册中心实现采用的是 Zookeeper ，启动 192.168.0.103 和 192.168.0.104 两个实例后，以下是两种模式下注册中心的实际数据

1. “接口粒度” 服务发现

192.168.0.103 实例注册的数据

dubbo://192.168.0.103:20880/org.apache.dubbo.samples.basic.api.DemoService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.DemoService&methods=testVoid,sayHello&pid=995&release=2.7.7&side=provider&timestamp=1596988171266

dubbo://192.168.0.103:20880/org.apache.dubbo.samples.basic.api.GreetingService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.GreetingService&methods=greeting&pid=995&release=2.7.7&side=provider&timestamp=1596988170816

192.168.0.104 实例注册的数据

dubbo://192.168.0.104:20880/org.apache.dubbo.samples.basic.api.DemoService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.DemoService&methods=testVoid,sayHello&pid=995&release=2.7.7&side=provider&timestamp=1596988171266

dubbo://192.168.0.104:20880/org.apache.dubbo.samples.basic.api.GreetingService?anyhost=true&application=demo-provider&default=true&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.samples.basic.api.GreetingService&methods=greeting&pid=995&release=2.7.7&side=provider&timestamp=1596988170816

2. “应用粒度” 服务发现

192.168.0.103 与 192.168.0.104 两个实例共享一份注册中心数据，如下：

{
 "name": "demo-provider",
 "id": "192.168.0.103:20880",
 "address": "192.168.0.103",
 "port": 20880,
 "metadata": {
 "dubbo.endpoints": "[{\"port\":20880,\"protocol\":\"dubbo\"}]",
 "dubbo.metadata.storage-type": "local",
 "dubbo.revision": "6785535733750099598"
 },
 "time": 1583461240877
}

{
 "name": "demo-provider",
 "id": "192.168.0.104:20880",
 "address": "192.168.0.104",
 "port": 20880,
 "metadata": {
 "dubbo.endpoints": "[{\"port\":20880,\"protocol\":\"dubbo\"}]",
 "dubbo.metadata.storage-type": "local",
 "dubbo.revision": "7829635812370099387"
 },
 "time": 1583461240877
}

对比以上两种不同粒度的服务发现模式，从 “接口粒度” 升级到 “应用粒度” 后我们可以总结出最大的区别是：注册中心数据量不再与接口数成正比，不论应用提供有多少接口，注册中心只有一条实例数据。

那么接下来我们详细看下这个变化给 Dubbo 带来了哪些好处。

3 Dubbo 应用级服务发现的意义

我们先说结论，应用级服务发现给 Dubbo 带来以下优势：

与业界主流微服务模型对齐，比如 SpringCloud、Kubernetes Native Service等。
提升性能与可伸缩性。注册中心数据的重新组织（减少），能最大幅度的减轻注册中心的存储、推送压力，进而减少 Dubbo Consumer 侧的地址计算压力；集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。

3.1 对齐主流微服务模型

自动、透明的实例地址发现（负载均衡）是所有微服务框架需要解决的事情，这能让后端的部署结构对上游微服务透明，上游服务只需要从收到的地址列表中选取一个，发起调用就可以了。要实现以上目标，涉及两个关键点的自动同步：

实例地址，服务消费方需要知道地址以建立连接
RPC 方法定义，服务消费方需要知道 RPC 服务的具体定义，不论服务类型是 rest 或 rmi 等。

对于 RPC 实例间借助注册中心的数据同步，REST 定义了一套非常有意思的成熟度模型，感兴趣的朋友可以参考这里的链接 https://www.martinfowler.com/articles/richardsonMaturityModel.html，按照文章中的 4 级成熟度定义，Dubbo 当前基于接口粒度的模型可以对应到 L4 级别。

接下来，我们看看 Dubbo、SpringCloud 以及 Kubernetes 分别是怎么围绕自动化的实例地址发现这个目标设计的。

1. Spring Cloud

Spring Cloud 通过注册中心只同步了应用与实例地址，消费方可以基于实例地址与服务提供方建立连接，但是消费方对于如何发起 http 调用（SpringCloud 基于 rest 通信）一无所知，比如对方有哪些 http endpoint，需要传入哪些参数等。

RPC 服务这部分信息目前都是通过线下约定或离线的管理系统来协商的。这种架构的优缺点总结如下。优势：部署结构清晰、地址推送量小；缺点：地址订阅需要指定应用名， provider 应用变更（拆分）需消费端感知；RPC 调用无法全自动同步。

2. Dubbo

Dubbo 通过注册中心同时同步了实例地址和 RPC 方法，因此其能实现 RPC 过程的自动同步，面向 RPC 编程、面向 RPC 治理，对后端应用的拆分消费端无感知，其缺点则是地址推送数量变大，和 RPC 方法成正比。

3. Dubbo + Kubernetes

Dubbo 要支持 Kubernetes native service，相比之前自建注册中心的服务发现体系来说，在工作机制上主要有两点变化：

服务注册由平台接管，provider 不再需要关心服务注册
consumer 端服务发现将是 Dubbo 关注的重点，通过对接平台层的 API-Server、DNS 等，Dubbo client 可以通过一个 Service Name（通常对应到 Application Name）查询到一组 Endpoints（一组运行 provider 的 pod），通过将 Endpoints 映射到 Dubbo 内部地址列表，以驱动 Dubbo 内置的负载均衡机制工作。

Kubernetes Service 作为一个抽象概念，怎么映射到 Dubbo 是一个值得讨论的点

Service Name - > Application Name，Dubbo 应用和 Kubernetes 服务一一对应，对于微服务运维和建设环节透明，与开发阶段解耦。
apiVersion: v1
kind: Service
metadata:
 name: provider-app-name
spec:
 selector:
 app: provider-app-name
 ports:
 - protocol: TCP
 port:
 targetPort: 9376
Service Name - > Dubbo RPC Service，Kubernetes 要维护调度的服务与应用内建 RPC 服务绑定，维护的服务数量变多。
---
apiVersion: v1
kind: Service
metadata:
 name: rpc-service-1
spec:
 selector:
 app: provider-app-name
 ports: ##
...
---
apiVersion: v1
kind: Service
metadata:
 name: rpc-service-2
spec:
 selector:
 app: provider-app-name
 ports: ##
...
---
apiVersion: v1
kind: Service
metadata:
 name: rpc-service-N
spec:
 selector:
 app: provider-app-name
 ports: ##
...

结合以上几种不同微服务框架模型的分析，我们可以发现，Dubbo 与 SpringCloud、Kubernetes 等不同产品在微服务的抽象定义上还是存在很大不同的。SpringCloud 和 Kubernetes 在微服务的模型抽象上还是比较接近的，两者基本都只关心实例地址的同步，如果我们去关心其他的一些服务框架产品，会发现它们绝大多数也是这么设计的；

即 REST 成熟度模型中的 L3 级别。

对比起来 Dubbo 则相对是比较特殊的存在，更多的是从 RPC 服务的粒度去设计的。

对应 REST 成熟度模型中的 L4 级别。

如我们上面针对每种模型做了详细的分析，每种模型都有其优势和不足。而我们最初决定 Dubbo 要做出改变，往其他的微服务发现模型上的对齐，是我们最早在确定 Dubbo 的云原生方案时，我们发现要让 Dubbo 去支持 Kubernetes Native Service，模型对齐是一个基础条件；另一点是来自用户侧对 Dubbo 场景化的一些工程实践的需求，得益于 Dubbo 对多注册、多协议能力的支持，使得 Dubbo 联通不同的微服务体系成为可能，而服务发现模型的不一致成为其中的一个障碍，这部分的场景描述请参见以下文章：Dubbo 如何成为连接异构微服务体系的最佳服务开发框架

3.2 更大规模的微服务集群 - 解决性能瓶颈

这部分涉及到和注册中心、配置中心的交互，关于不同模型下注册中心数据的变化，之前原理部分我们简单分析过。为更直观的对比服务模型变更带来的推送效率提升，我们来通过一个示例看一下不同模型注册中心的对比：

图中左边是微服务框架的一个典型工作流程，Provider 和 Consumer 通过注册中心实现自动化的地址通知。其中，Provider 实例的信息如图中表格所示：应用 DEMO 包含三个接口 DemoService 1 2 3，当前实例的 ip 地址为 10.210.134.30。

对于 Spring Cloud 和 Kubernetes 模型，注册中心只会存储一条 DEMO - 10.210.134.30+metadata 的数据；
对于老的 Dubbo 模型，注册中心存储了三条接口粒度的数据，分别对应三个接口 DemoService 1 2 3，并且很多的址数据都是重复的；

可以总结出，基于应用粒度的模型所存储和推送的数据量是和应用、实例数成正比的，只有当我们的应用数增多或应用的实例数增长时，地址推送压力才会上涨。而对于基于接口粒度的模型，数据量是和接口数量正相关的，鉴于一个应用通常发布多个接口的现状，这个数量级本身比应用粒度是要乘以倍数的；另外一个关键点在于，接口粒度导致的集群规模评估的不透明，相对于实例、应用增长都通常是在运维侧的规划之中，接口的定义更多的是业务侧的内部行为，往往可以绕过评估给集群带来压力。

以 Consumer 端服务订阅举例，根据我对社区部分 Dubbo 中大规模头部用户的粗略统计，根据受统计公司的实际场景，一个 Consumer 应用要消费（订阅）的 Provier 应用数量往往要超过 10 个，而具体到其要消费（订阅）的的接口数量则通常要达到 30 个，平均情况下 Consumer 订阅的 3 个接口来自同一个 Provider 应用，如此计算下来，如果以应用粒度为地址通知和选址基本单位，则平均地址推送和计算量将下降 60% 还要多，而在极端情况下，也就是当 Consumer 端消费的接口更多的来自同一个应用时，这个地址推送与内存消耗的占用将会进一步得到降低，甚至可以超过 80% 以上。

一个典型的极端场景即是 Dubbo 体系中的网关型应用，有些网关应用消费（订阅）达 100+ 应用，而消费（订阅）的服务有 1000+ ，平均有 10 个接口来自同一个应用，如果我们把地址推送和计算的粒度改为应用，则地址推送量从原来的 n * 1000 变为 n * 100，地址数量降低可达近 90%。

4 应用级服务发现工作原理

4.1 设计原则

上面一节我们从服务模型及支撑大规模集群的角度分别给出了 Dubbo 往应用级服务发现靠拢的好处和原因，但这么做的同时接口粒度的服务治理能力还是要继续保留，这是 Dubbo 框架编程模型易用性、服务治理能力优势的基础。以下是我认为我们做服务模型迁移仍要坚持的设计原则

新的服务发现模型要实现对原有 Dubbo 消费端开发者的无感知迁移，即 Dubbo 继续面向 RPC 服务编程、面向 RPC 服务治理，做到对用户侧完全无感知。
建立 Consumer 与 Provider 间的自动化 RPC 服务元数据协调机制，解决传统微服务模型无法同步 RPC 级接口配置的缺点。

4.2 基本原理详解

应用级服务发现作为一种新的服务发现机制，和以前 Dubbo 基于 RPC 服务粒度的服务发现在核心流程上基本上是一致的：即服务提供者往注册中心注册地址信息，服务消费者从注册中心拉取&订阅地址信息。

这里主要的不同有以下两点：

4.2.1 注册中心数据以“应用 - 实例列表”格式组织，不再包含 RPC 服务信息

以下是每个 Instance metadata 的示例数据，总的原则是 metadata 只包含当前 instance 节点相关的信息，不涉及 RPC 服务粒度的信息。

总体信息概括如下：实例地址、实例各种环境标、metadata service 元数据、其他少量必要属性。

{
 "name": "provider-app-name",
 "id": "192.168.0.102:20880",
 "address": "192.168.0.102",
 "port": 20880,
 "sslPort": null,
 "payload": {
 "id": null,
 "name": "provider-app-name",
 "metadata": {
 "metadataService": "{\"dubbo\":{\"version\":\"1.0.0\",\"dubbo\":\"2.0.2\",\"release\":\"2.7.5\",\"port\":\"20881\"}}",
 "endpoints": "[{\"port\":20880,\"protocol\":\"dubbo\"}]",
 "storage-type": "local",
 "revision": "6785535733750099598",
 }
 },
 "registrationTimeUTC": 1583461240877,
 "serviceType": "DYNAMIC",
 "uriSpec": null
}

4.2.2 Client – Server 自行协商 RPC 方法信息

在注册中心不再同步 RPC 服务信息后，服务自省在服务消费端和提供端之间建立了一条内置的 RPC 服务信息协商机制，这也是“服务自省”这个名字的由来。服务端实例会暴露一个预定义的 MetadataService RPC 服务，消费端通过调用 MetadataService 获取每个实例 RPC 方法相关的配置信息。

当前 MetadataService 返回的数据格式如下，

[
 "dubbo://192.168.0.102:20880/org.apache.dubbo.demo.DemoService?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5&side=provider&timestamp=1583469714314",
 "dubbo://192.168.0.102:20880/org.apache.dubbo.demo.HelloService?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5&side=provider&timestamp=1583469714314",
 "dubbo://192.168.0.102:20880/org.apache.dubbo.demo.WorldService?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5&side=provider&timestamp=1583469714314"
]

熟悉 Dubbo 基于 RPC 服务粒度的服务发现模型的开发者应该能看出来，服务自省机制机制将以前注册中心传递的 URL 一拆为二：

一部分和实例相关的数据继续保留在注册中心，如 ip、port、机器标识等。

另一部分和 RPC 方法相关的数据从注册中心移除，转而通过 MetadataService 暴露给消费端。

理想情况下是能达到数据按照实例、RPC 服务严格区分开来，但明显可以看到以上实现版本还存在一些数据冗余，有些数据也还未合理划分。尤其是 MetadataService 部分，其返回的数据还只是简单的 URL 列表组装，这些 URL其实是包含了全量的数据。

以下是服务自省的一个完整工作流程图，详细描述了服务注册、服务发现、MetadataService、RPC 调用间的协作流程。

服务提供者启动，首先解析应用定义的“普通服务”并依次注册为 RPC 服务，紧接着注册内建的 MetadataService 服务，最后打开 TCP 监听端口。
启动完成后，将实例信息注册到注册中心（仅限 ip、port 等实例相关数据），提供者启动完成。
服务消费者启动，首先依据其要“消费的 provider 应用名”到注册中心查询地址列表，并完成订阅（以实现后续地址变更自动通知）。
消费端拿到地址列表后，紧接着对 MetadataService 发起调用，返回结果中包含了所有应用定义的“普通服务”及其相关配置信息。
至此，消费者可以接收外部流量，并对提供者发起 Dubbo RPC 调用

在以上流程中，我们只考虑了一切顺利的情况，但在更详细的设计或编码实现中，我们还需要严格约定一些异常场景下的框架行为。比如，如果消费者 MetadataService 调用失败，则在重试直到成功之前，消费者将不可以接收外部流量。

4.3 服务自省中的关键机制

4.3.1 元数据同步机制

Client 与 Server 间在收到地址推送后的配置同步是服务自省的关键环节，目前针对元数据同步有两种具体的可选方案，分别是：

内建 MetadataService。
独立的元数据中心，通过中心化的元数据集群协调数据。

1. 内建 MetadataService MetadataService 通过标准的 Dubbo 协议暴露，根据查询条件，会将内存中符合条件的“普通服务”配置返回给消费者。这一步发生在消费端选址和调用前。

2. 元数据中心 复用 2.7 版本中引入的元数据中心，provider 实例启动后，会尝试将内部的 RPC 服务组织成元数据的格式同步到元数据中心，而 consumer 则在每次收到注册中心推送更新后，主动查询元数据中心。

注意 consumer 端查询元数据中心的时机，是等到注册中心的地址更新通知之后。也就是通过注册中心下发的数据，我们能明确的知道何时某个实例的元数据被更新了，此时才需要去查元数据中心。

4.3.2 RPC 服务 < - > 应用映射关系

回顾上文讲到的注册中心关于“应用 - 实例列表”结构的数据组织形式，这个变动目前对开发者并不是完全透明的，业务开发侧会感知到查询/订阅地址列表的机制的变化。具体来说，相比以往我们基于 RPC 服务来检索地址，现在 consumer 需要通过指定 provider 应用名才能实现地址查询或订阅。

老的 Consumer 开发与配置示例：

<!-- 框架直接通过 RPC Service 1/2/N 去注册中心查询或订阅地址列表 -->
<dubbo:registry address="zookeeper://127.0.0.1:2181"/>
<dubbo:reference interface="RPC Service 1" />
<dubbo:reference interface="RPC Service 2" />
<dubbo:reference interface="RPC Service N" />

新的 Consumer 开发与配置示例：

<!-- 框架需要通过额外的 provided-by="provider-app-x" 才能在注册中心查询或订阅到地址列表 -->
<dubbo:registry address="zookeeper://127.0.0.1:2181?registry-type=service"/>
<dubbo:reference interface="RPC Service 1" provided-by="provider-app-x"/>
<dubbo:reference interface="RPC Service 2" provided-by="provider-app-x" />
<dubbo:reference interface="RPC Service N" provided-by="provider-app-y" />

以上指定 provider 应用名的方式是 Spring Cloud 当前的做法，需要 consumer 端的开发者显示指定其要消费的 provider 应用。

以上问题的根源在于注册中心不知道任何 RPC 服务相关的信息，因此只能通过应用名来查询。

为了使整个开发流程对老的 Dubbo 用户更透明，同时避免指定 provider 对可扩展性带来的影响（参见下方说明），我们设计了一套 RPC 服务到应用名的映射关系，以尝试在 consumer 端自动完成 RPC 服务到 provider 应用名的转换。

Dubbo 之所以选择建立一套“接口-应用”的映射关系，主要是考虑到 service - app 映射关系的不确定性。一个典型的场景即是应用/服务拆分，如上面提到的配置<dubbo:reference interface="RPC Service 2" provided-by="provider-app-x" />，PC Service 2 是定义于 provider-app-x 中的一个服务，未来它随时可能会被开发者分拆到另外一个新的应用如 provider-app-x-1 中，这个拆分要被所有的 PC Service 2 消费方感知到，并对应用进行修改升级，如改为<dubbo:reference interface="RPC Service 2" provided-by="provider-app-x-1" />，这样的升级成本不可否认还是挺高的。到底是 Dubbo 框架帮助开发者透明的解决这个问题，还是交由开发者自己去解决，当然这只是个策略选择问题，并且 Dubbo 2.7.5+ 版本目前是都提供了的。其实我个人更倾向于交由业务开发者通过组织上的约束来做，这样也可进一步降低 Dubbo 框架的复杂度，提升运行态的稳定性。

5 总结与展望

应用级服务发现机制是 Dubbo 面向云原生走出的重要一步，它帮 Dubbo 打通了与其他微服务体系之间在地址发现层面的鸿沟，也成为 Dubbo 适配 Kubernetes Native Service 等基础设施的基础。我们期望 Dubbo 在新模型基础上，能继续保留在编程易用性、服务治理能力等方面强大的优势。但是我们也应该看到应用粒度的模型一方面带来了新的复杂性，需要我们继续去优化与增强；另一方面，除了地址存储与推送之外，应用粒度在帮助 Dubbo 选址层面也有进一步挖掘的潜力。

Blog: dubbo-go 白话文

Sat, 20 Feb 2021 00:00:00 +0000

一、前言

本文基于 dubbogo 1.5.4 版本

最近开始参与 dubbogo 的一些开发测试，之前都是直接拿 samples 的例子验证功能，而这次为了复现一个功能问题，打算从零开始搭建一个 dubbo-go 和 dubbo 调用的工程，踩到了一些新人使用 dubbogo 的坑，把这个过程记录下供大家参考。

通过本文你可以了解到：

如何常规配置 dubbogo 消费方去调用 dubbo 和 dubbogo 服务提供方
通过一个实际的 BUG 介绍解决问题的思路

二、解决问题

2.1 准备 dubbo 服务提供者

2.1.1 基本定义

定义 DemoService 接口：

public interface DemoService {

 String sayHello(String name);

 String sayHello(User user);

 String sayHello(User user, String name);

}

定义 User 对象：

public class User implements Serializable {

 private String name;

 private int age;

 ......
}

2.1.2 启动 dubbo 服务提供者

用的 dubbo 官方示例代码:

public static void main(String[] args) throws IOException {
 // 服务实现
 DemoService demoService = new DemoServiceImpl();

 // 当前应用配置
 ApplicationConfig application = new ApplicationConfig();
 application.setName("demoProvider");

 // 连接注册中心配置
 RegistryConfig registry = new RegistryConfig();
 registry.setAddress("127.0.0.1:2181");
 registry.setProtocol("zookeeper");
 registry.setUsername("");
 registry.setPassword("");

 // 服务提供者协议配置
 ProtocolConfig protocol = new ProtocolConfig();
 protocol.setName("dubbo");
 protocol.setPort(12345);
 protocol.setThreads(200);

 // 注意：ServiceConfig为重对象，内部封装了与注册中心的连接，以及开启服务端口

 // 服务提供者暴露服务配置
 ServiceConfig<DemoService> service = new ServiceConfig<>(); // 此实例很重，封装了与注册中心的连接，请自行缓存，否则可能造成内存和连接泄漏
 service.setApplication(application);
 service.setRegistry(registry); // 多个注册中心可以用setRegistries()
 service.setProtocol(protocol); // 多个协议可以用setProtocols()
 service.setInterface(DemoService.class);
 service.setRef(demoService);
 service.setVersion("1.0.0");
 service.setGroup("tc");
 service.setTimeout(60 * 1000);

 // 暴露及注册服务
 service.export();

 System.in.read();
}

查看 zookeeper 看是否注册成功：

$ls /dubbo/com.funnycode.DemoService/providers
[dubbo%3A%2F%2F127.0.0.1%3A12345%2Fcom.funnycode.DemoService%3Fanyhost%3Dtrue%26application%3DdemoProvider%26deprecated%3Dfalse%26dubbo%3D2.0.2%26dynamic%3Dtrue%26generic%3Dfalse%26group%3Dtc%26interface%3Dcom.funnycode.DemoService%26methods%3DsayHello%26pid%3D18167%26release%3D2.7.7%26revision%3D1.0.0%26side%3Dprovider%26threads%3D200%26timestamp%3D1606896020691%26version%3D1.0.0]

如上的输出表示服务提供方已经启动。

2.2 准备 dubbogo 服务消费者

2.2.1 基本定义

定义 User 对象：

type User struct {
 Name string
 Age int
}

func (User) JavaClassName() string {
 return "com.funnycode.User"
}

定义 DemoProvider 接口：

type DemoProvider struct {
 SayHello func(ctx context.Context, name string) (string, error) `dubbo:"sayHello"`
 SayHello2 func(ctx context.Context, user User) (string, error) `dubbo:"sayHello"`
 SayHello3 func(ctx context.Context, user User, name string) (string, error) `dubbo:"sayHello"`
}

func (p *DemoProvider) Reference() string {
 return "DemoProvider"
}

2.2.2 启动 dubbogo 消费者

func main() {
 config.Load()
 gxlog.CInfo("\n\n\nstart to test dubbo")

 res, err := demoProvider.SayHello(context.TODO(), "tc")
 if err != nil {
 panic(err)
 }

 gxlog.CInfo("response result: %v\n", res)

 user := User{
 Name: "tc",
 Age: 18,
 }

 res, err = demoProvider.SayHello2(context.TODO(), user)
 if err != nil {
 panic(err)
 }

 gxlog.CInfo("response result: %v\n", res)

 res, err = demoProvider.SayHello3(context.TODO(), user, "tc")
 if err != nil {
 panic(err)
 }

 gxlog.CInfo("response result: %v\n", res)

 initSignal()
}

2.3 请求结果分析

2.3.1 直接调用

确认问题的存在

第一个接口的参数是字符串，可以正常返回 [2020-12-03/18:59:12 main.main: client.go: 29] response result: Hello tc 第二、三两个接口存在 User 对象，无法调用成功。错误信息如下：

2020-12-02T17:10:47.739+0800 INFO getty/listener.go:87 session{session session-closed, Read Bytes: 924, Write Bytes: 199, Read Pkgs: 0, Write Pkgs: 1} got error{java exception:Fail to decode request due to: java.lang.IllegalArgumentException: Service not found:com.funnycode.DemoService, sayHello
 at org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation.decode(DecodeableRpcInvocation.java:134)
 at org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation.decode(DecodeableRpcInvocation.java:80)
 at org.apache.dubbo.remoting.transport.DecodeHandler.decode(DecodeHandler.java:57)
 at org.apache.dubbo.remoting.transport.DecodeHandler.received(DecodeHandler.java:44)
 at org.apache.dubbo.remoting.transport.dispatcher.ChannelEventRunnable.run(ChannelEventRunnable.java:57)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run(Thread.java:748)
}, will be closed.

错误正如 issue 中描述的一模一样，因为错误信息返回到了消费端，可以看到 Java 那边的错误堆栈信息，所以直接去看 DecodeableRpcInvocation.decode#134。

2.3.2 断点查看

代码如下：

// 反序列化
public class DecodeableRpcInvocation extends RpcInvocation implements Codec, Decodeable {
 public Object decode(Channel channel, InputStream input) throws IOException {
 ......
 if (serviceDescriptor != null) {
 // 方法描述里面根据方法名查找
 MethodDescriptor methodDescriptor = serviceDescriptor.getMethod(getMethodName(), desc);
 if (methodDescriptor != null) {
 pts = methodDescriptor.getParameterClasses();
 this.setReturnTypes(methodDescriptor.getReturnTypes());
 }
 }
 // 表示没有找到方法
 if (pts == DubboCodec.EMPTY_CLASS_ARRAY) {
 if (!RpcUtils.isGenericCall(path, getMethodName()) && !RpcUtils.isEcho(path, getMethodName())) {
 throw new IllegalArgumentException("Service not found:" + path + ", " + getMethodName());
 }
 pts = ReflectUtils.desc2classArray(desc);
 }
 ......
 }
}

查看 MethodDescriptor，即找方法是否存在，存在的话就会设置好 ParameterClasses
如果上面没找到，pts == DubboCodec.EMPTY_CLASS_ARRAY 就会满足条件，进而判断是否是泛化调用或者是 echo 调用，如果都不是则报服务找不到方法错误
desc 是 Ljava/lang/Object ，很明显并没有参数是 Object 的方法，所以必然是会报错的

补充说明：

方法查询

代码如下：

public MethodDescriptor getMethod(String methodName, String params) {
 Map<String, MethodDescriptor> methods = descToMethods.get(methodName);
 if (CollectionUtils.isNotEmptyMap(methods)) {
 return methods.get(params);
 }
 return null;
}

优点：

比之前的版本加了方法的元信息缓存起来，不使用反射可以提高效率，可以理解用空间换时间。

2.4 解决问题

因为直接撸代码并 hold 不住，所以通过比较来查看问题所在。

2.4.1 启动 dubbo 服务消费者

通过 api 模式启动，参考官方例子。启动这个是为了查看 Java 版本的传输内容。

public static void main(String[] args) throws InterruptedException {
 // 当前应用配置
 ApplicationConfig application = new ApplicationConfig();
 application.setName("demoProvider2");

 // 连接注册中心配置
 RegistryConfig registry = new RegistryConfig();
 registry.setAddress("127.0.0.1:2181");
 registry.setProtocol("zookeeper");
 registry.setUsername("");
 registry.setPassword("");
 // 注意：ReferenceConfig为重对象，内部封装了与注册中心的连接，以及与服务提供方的连接

 // 引用远程服务
 ReferenceConfig<DemoService> reference
 = new ReferenceConfig<>(); // 此实例很重，封装了与注册中心的连接以及与提供者的连接，请自行缓存，否则可能造成内存和连接泄漏
 reference.setApplication(application);
 reference.setRegistry(registry); // 多个注册中心可以用setRegistries()
 reference.setInterface(DemoService.class);
 reference.setVersion("1.0.0");
 reference.setGroup("tc");
 reference.setCheck(true);
 reference.setTimeout(1000 * 60);

 // 和本地bean一样使用xxxService
 DemoService demoService = reference.get(); // 注意：此代理对象内部封装了所有通讯细节，对象较重，请缓存复用
 System.out.println(demoService.sayHello(new User("tc", 18)));

 TimeUnit.MINUTES.sleep(10);
}

desc 肉眼可见的是 Lcom/funnycode/User，这个就是正确的对象了。

2.4.2 查找 dubbogo 为什么不对

代码位置：

protocol/dubbo/impl/hessian.go:120#marshalRequest

代码实现：

func marshalRequest(encoder *hessian.Encoder, p DubboPackage) ([]byte, error) {
 service := p.Service
 request := EnsureRequestPayload(p.Body)
 encoder.Encode(DEFAULT_DUBBO_PROTOCOL_VERSION)
 encoder.Encode(service.Path)
 encoder.Encode(service.Version)
 encoder.Encode(service.Method)

 args, ok := request.Params.([]interface{})

 if !ok {
 logger.Infof("request args are: %+v", request.Params)
 return nil, perrors.Errorf("@params is not of type: []interface{}")
 }
 types, err := getArgsTypeList(args)
 if err != nil {
 return nil, perrors.Wrapf(err, " PackRequest(args:%+v)", args)
 }
 encoder.Encode(types)
 for _, v := range args {
 encoder.Encode(v)
 }

 ......
}

断点可以发现，types 返回的时候就已经是 Object 了，没有返回 User，那么继续跟进去查看代码。

protocol/dubbo/impl/hessian.go:394#getArgsTypeList
protocol/dubbo/impl/hessian.go:418#getArgType

func getArgType(v interface{}) string {
 // 常见的类型处理

 ......

 default:
 t := reflect.TypeOf(v)
 if reflect.Ptr == t.Kind() {
 t = reflect.TypeOf(reflect.ValueOf(v).Elem())
 }
 switch t.Kind() {
 case reflect.Struct:
 return "java.lang.Object"
 }
 ......
}

很明显当发现是 reflect.Struct 的时候就返回了 java.lang.Object，所以参数就变成了 Object，那么因为 Java 代码那边依赖这个类型所以就调用失败了。

2.4.3 其它版本验证

因为反馈是 2.7.7 出错，所以先考虑到在之前的版本是否功能正常，于是把服务提供者切换到 dubbo 2.7.3，发现调用仍然有错误，如下：

2020-12-02T21:52:25.945+0800 INFO getty/listener.go:85 session{session session-closed, Read Bytes: 4586, Write Bytes: 232, Read Pkgs: 0, Write Pkgs: 1} got error{java exception:org.apache.dubbo.rpc.RpcException: Failed to invoke remote proxy method sayHello to registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=demoProvider&dubbo=2.0.2&export=dubbo%3A%2F%2F192.168.0.113%3A12345%2Fcom.funnycode.DemoService%3Fanyhost%3Dtrue%26application%3DdemoProvider%26bind.ip%3D192.168.0.113%26bind.port%3D12345%26deprecated%3Dfalse%26dubbo%3D2.0.2%26dynamic%3Dtrue%26generic%3Dfalse%26group%3Dtc%26interface%3Dcom.funnycode.DemoService%26methods%3DsayHello%26pid%3D23889%26register%3Dtrue%26release%3D2.7.3%26revision%3D1.0.0%26side%3Dprovider%26threads%3D200%26timeout%3D60000%26timestamp%3D1606916702204%26version%3D1.0.0&pid=23889&registry=zookeeper&release=2.7.3&timestamp=1606916702193, cause: Not found method "sayHello" in class com.funnycode.DemoServiceImpl.
org.apache.dubbo.rpc.RpcException: Failed to invoke remote proxy method sayHello to registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=demoProvider&dubbo=2.0.2&export=dubbo%3A%2F%2F192.168.0.113%3A12345%2Fcom.funnycode.DemoService%3Fanyhost%3Dtrue%26application%3DdemoProvider%26bind.ip%3D192.168.0.113%26bind.port%3D12345%26deprecated%3Dfalse%26dubbo%3D2.0.2%26dynamic%3Dtrue%26generic%3Dfalse%26group%3Dtc%26interface%3Dcom.funnycode.DemoService%26methods%3DsayHello%26pid%3D23889%26register%3Dtrue%26release%3D2.7.3%26revision%3D1.0.0%26side%3Dprovider%26threads%3D200%26timeout%3D60000%26timestamp%3D1606916702204%26version%3D1.0.0&pid=23889&registry=zookeeper&release=2.7.3&timestamp=1606916702193, cause: Not found method "sayHello" in class com.funnycode.DemoServiceImpl.
 at org.apache.dubbo.rpc.proxy.AbstractProxyInvoker.invoke(AbstractProxyInvoker.java:107)
 at org.apache.dubbo.config.invoker.DelegateProviderMetaDataInvoker.invoke(DelegateProviderMetaDataInvoker.java:56)
 at org.apache.dubbo.rpc.protocol.InvokerWrapper.invoke(InvokerWrapper.java:56)
 at org.apache.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:55)
 at org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:82)
 at org.apache.dubbo.monitor.support.MonitorFilter.invoke(MonitorFilter.java:92)
 at org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:82)
 at org.apache.dubbo.rpc.filter.TimeoutFilter.invoke(TimeoutFilter.java:48)
 at org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:82)
 at org.apache.dubbo.rpc.protocol.dubbo.filter.TraceFilter.invoke(TraceFilter.java:81)
 at org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:82)
 at org.apache.dubbo.rpc.filter.ContextFilter.invoke(ContextFilter.java:96)
 at org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:82)
 at org.apache.dubbo.rpc.filter.GenericFilter.invoke(GenericFilter.java:148)
 at org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:82)
 at org.apache.dubbo.rpc.filter.ClassLoaderFilter.invoke(ClassLoaderFilter.java:38)
 at org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:82)
 at org.apache.dubbo.rpc.filter.EchoFilter.invoke(EchoFilter.java:41)
 at org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:82)
 at org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper$CallbackRegistrationInvoker.invoke(ProtocolFilterWrapper.java:157)
 at org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol$1.reply(DubboProtocol.java:152)
 at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.handleRequest(HeaderExchangeHandler.java:102)
 at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.received(HeaderExchangeHandler.java:193)
 at org.apache.dubbo.remoting.transport.DecodeHandler.received(DecodeHandler.java:51)
 at org.apache.dubbo.remoting.transport.dispatcher.ChannelEventRunnable.run(ChannelEventRunnable.java:57)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.dubbo.common.bytecode.NoSuchMethodException: Not found method "sayHello" in class com.funnycode.DemoServiceImpl.
 at org.apache.dubbo.common.bytecode.Wrapper1.invokeMethod(Wrapper1.java)
 at org.apache.dubbo.rpc.proxy.javassist.JavassistProxyFactory$1.doInvoke(JavassistProxyFactory.java:47)
 at org.apache.dubbo.rpc.proxy.AbstractProxyInvoker.invoke(AbstractProxyInvoker.java:84)
 ... 27 more
}, will be closed.

虽然和 2.7.7 的代码是不一样的，但是通过错误也能看出来是在代理增强类里面方法找不到，大概率是反射找不到方法，所以归根结底也是参数的问题。

2.4.4 修复问题

修复相对简单，就是拿到 struct 定义的 JavaClassName。

case reflect.Struct:
 v, ok := v.(hessian.POJO)
 if ok {
 return v.JavaClassName()
 }
 return "java.lang.Object"

2.4.3 验证结果

再次执行消费者，运行（提供方 2.7.7 和 2.7.3）正常，输出如下：

[2020-12-03/20:04:06 main.main: client.go: 29] response result: Hello tc
...
[2020-12-03/20:04:09 main.main: client.go: 41] response result: Hello tc You are 18
...
[2020-12-03/20:04:09 main.main: client.go: 48] response result: Hello tc You are 18

三、细节叨叨

3.1 如何配置 dubbgo 消费者

细心的你是否已经发现，在我 dubbogo 的消费端接口叫 DemoProvider，然后发现提供者叫 DemoService，这个又是如何正常运行的？

实际上和 client.yml 中配置项 references 有关，在配置文件详细说明了 interface，version，group 等，你还可以通过 methods 配置方法的超时时间等信息。

references:
 "DemoProvider":
 # 可以指定多个registry，使用逗号隔开;不指定默认向所有注册中心注册
 registry: "zk1"
 protocol: "dubbo"
 interface: "com.funnycode.DemoService"
 cluster: "failover"
 version: "1.0.0"
 group: "tc"
 methods:
 - name: "SayHello"
 retries: 3
 ......

3.2 全局的 group 和 version 怎么配置

配置文件如下：

# application config
application:
 organization: "dubbogoproxy.com"
 name: "Demo Micro Service"
 module: "dubbogoproxy tc client"
 version: "1.0.0"
 group: "tc"
 owner: "ZX"
 environment: "dev"

references:
 "DemoProvider":
 # 可以指定多个registry，使用逗号隔开;不指定默认向所有注册中心注册
 registry: "zk1"
 protocol: "dubbo"
 interface: "com.funnycode.DemoService"
 cluster: "failover"
# version: "1.0.0"
# group: "tc"
 methods:
 - name: "SayHello"
 retries: 3

从使用的习惯来讲，肯定是 application 表示了全局的配置，但是我发现启动的时候在 application 配置的 version 和 group 并不会赋值给接口，启动会报服务提供方找不到，如下：

2020-12-03T20:15:42.208+0800 DEBUG zookeeper/registry.go:237 Create a zookeeper node:/dubbo/com.funnycode.DemoService/consumers/consumer%3A%2F%2F30.11.176.107%2FDemoProvider%3Fapp.version%3D1.0.0%26application%3DDemo+Micro+Service%26async%3Dfalse%26bean.name%3DDemoProvider%26cluster%3Dfailover%26environment%3Ddev%26generic%3Dfalse%26group%3D%26interface%3Dcom.funnycode.DemoService%26ip%3D30.11.176.107%26loadbalance%3D%26methods.SayHello.loadbalance%3D%26methods.SayHello.retries%3D3%26methods.SayHello.sticky%3Dfalse%26module%3Ddubbogoproxy+tc+client%26name%3DDemo+Micro+Service%26organization%3Ddubbogoproxy.com%26owner%3DZX%26pid%3D38692%26protocol%3Ddubbo%26provided-by%3D%26reference.filter%3Dcshutdown%26registry.role%3D0%26release%3Ddubbo-golang-1.3.0%26retries%3D%26side%3Dconsumer%26sticky%3Dfalse%26timestamp%3D1606997742%26version%3D

version 和 group 都是空。必须把 DemoProvider 下的 version 和 group 注释打开。

3.3 怎么指定调用的方法名

3.3.1 go 调用 java

dubbogo 调用 dubbo，因为 go 是大写的方法名，java 里面是小写的方法名，所以会出现如下错误：

2020-12-02T17:10:47.739+0800 INFO getty/listener.go:87 session{session session-closed, Read Bytes: 924, Write Bytes: 199, Read Pkgs: 0, Write Pkgs: 1} got error{java exception:Fail to decode request due to: java.lang.IllegalArgumentException: Service not found:com.funnycode.DemoService, SayHello
java.lang.IllegalArgumentException: Service not found:com.funnycode.DemoService, SayHello
 at org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation.decode(DecodeableRpcInvocation.java:134)
 at org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation.decode(DecodeableRpcInvocation.java:80)
 at org.apache.dubbo.remoting.transport.DecodeHandler.decode(DecodeHandler.java:57)
 at org.apache.dubbo.remoting.transport.DecodeHandler.received(DecodeHandler.java:44)
 at org.apache.dubbo.remoting.transport.dispatcher.ChannelEventRunnable.run(ChannelEventRunnable.java:57)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run(Thread.java:748)
}, will be closed.

细心的读者可能已经注意到了，我在消费端的接口声明是有个 dubbo:"sayHello" 的，表示方法名是 sayHello，这样在服务提供方就可以得到 sayHello 这个方法名。

还有我声明的三个方法都指明它们的方法名叫 dubbo:"sayHello"，这是因为 Java 可以方法名字一样进行重载，而 go 是不能方法名重复的。

3.3.2 go 调用 go

直接贴能跑通的代码

我的提供者接口：

type DemoProvider struct{}

func (p *DemoProvider) SayHello(ctx context.Context, name string) (string, error) {
 return "Hello " + name, nil
}

func (p *DemoProvider) SayHello4(ctx context.Context, user *User) (string, error) {
 return "Hello " + user.Name + " You are " + strconv.Itoa(user.Age), nil
}

func (p *DemoProvider) SayHello5(ctx context.Context, user *User, name string) (string, error) {
 return "Hello " + name + " You are " + strconv.Itoa(user.Age), nil
}

func (p *DemoProvider) Reference() string {
 return "DemoProvider"
}

func (p *DemoProvider) MethodMapper() map[string]string {
 return map[string]string{
 "SayHello": "sayHello",
 }
}

我的消费者接口：

type DemoProvider struct {
 // 调用 java 和 go
 SayHello func(ctx context.Context, name string) (string, error) `dubbo:"sayHello"`
 // 只调用 java
 SayHello2 func(ctx context.Context, user *User) (string, error) `dubbo:"sayHello"`
 SayHello3 func(ctx context.Context, user *User, name string) (string, error) `dubbo:"sayHello"`
 // 只调用 go
 SayHello4 func(ctx context.Context, user *User) (string, error)
 SayHello5 func(ctx context.Context, user *User, name string) (string, error)
}

启动服务消费者：

func main() {
 config.Load()
 gxlog.CInfo("\n\n\nstart to test dubbo")

 res, err := demoProvider.SayHello(context.TODO(), "tc")
 if err != nil {
 panic(err)
 }

 gxlog.CInfo("response result: %v\n", res)

 user := &User{
 Name: "tc",
 Age: 18,
 }

 res, err = demoProvider.SayHello4(context.TODO(), user)
 if err != nil {
 panic(err)
 }

 gxlog.CInfo("response result: %v\n", res)

 res, err = demoProvider.SayHello5(context.TODO(), user, "tc")
 if err != nil {
 panic(err)
 }

 gxlog.CInfo("response result: %v\n", res)

 initSignal()
}

这里需要注意 MethodMapper 方法，有时候需要在这个方法中配置方法名的映射关系，否则还是会出现找不到方法的错误。

比如因为配置 dubbo:"sayHello" ，所以在 go 里面请求 SayHello 变成了 sayHello，那么服务提供方通过 MethodMapper 方法配置后使得提供方也是 sayHello，这样 go 和 java 下暴露的都是小写的 sayHello。

3.4 为什么会用 hessian2

老司机都懂，在 dubbo 中 SPI 机制的默认值就是 hessian2

@SPI("hessian2")
public interface Serialization {
}

而在 dubbo-go 中：

func NewDubboCodec(reader *bufio.Reader) *ProtocolCodec {
 s, _ := GetSerializerById(constant.S_Hessian2)
 return &ProtocolCodec{
 reader: reader,
 pkgType: 0,
 bodyLen: 0,
 headerRead: false,
 serializer: s.(Serializer),
 }
}

3.5 hessian序列化源码

可以自行断点查看，两边基本上一样，我也是通过两边比出来的，RpcInvocation.getParameterTypesDesc() 就是方法的参数

go 代码 protocol/dubbo/impl/hessian.go:120#marshalRequest
java 代码 org.apache.dubbo.rpc.protocol.dubbo.DubboCodec#encodeRequestData(org.apache.dubbo.remoting.Channel, org.apache.dubbo.common.serialize.ObjectOutput, java.lang.Object, java.lang.String)

3.6 dubbogo 服务提供者的方法对象需要是指针对象

之前的例子都是 copy 的，这次是纯手打的，才发现了这个问题。

如果你的提供类似：func (p *DemoProvider) SayHello4(ctx context.Context, user User) (string, error)，那么会出现如下错误：

2020-12-03T12:42:32.834+0800 ERROR getty/listener.go:280 OnMessage panic: reflect: Call using *main.User as type main.User
github.com/apache/dubbo-go/remoting/getty.(*RpcServerHandler).OnMessage.func1

参数里面的 User 需要改成 *User。

3.7 dubbogo 服务消费者的方法对象可以是非指针对象

SayHello4 func(ctx context.Context, user *User) (string, error)
// or
SayHello4 func(ctx context.Context, user User) (string, error)

因为在参数序列化的时候会对指针做操作：

t := reflect.TypeOf(v)
if reflect.Ptr == t.Kind() {
 t = reflect.TypeOf(reflect.ValueOf(v).Elem())
}

完整代码

3.8 配置文件说明

dubbogo 主要有三个配置文件：

server.yaml 服务提供方的配置文件
client.yaml 服务消费方的配置文件
log.yaml 日志文件

如果你什么都不配置，会出现：

2021/01/11 15:31:41 [InitLog] warn: log configure file name is nil
2021/01/11 15:31:41 [consumerInit] application configure(consumer) file name is nil
2021/01/11 15:31:41 [providerInit] application configure(provider) file name is nil

这样是没法正常使用的。如果你是服务提供方，必须要配置 server.yaml 文件，如果你是服务消费方，必须要配置 client.yaml，实际我们的应用应该既是消费者又是提供者，所以往往两个文件都是需要配置的。

服务提供方正常启动是会有如下输出的：

2021-01-11T15:36:55.003+0800 INFO protocol/protocol.go:205 The cached exporter keys is dubbo://:20000/DemoProvider?accesslog=&app.version=1.0.0&application=Demo+Micro+Service&auth=&bean.name=DemoProvider&cluster=failover&environment=dev&execute.limit=&execute.limit.rejected.handler=&group=tc&interface=com.funnycode.DemoService&loadbalance=random&methods.SayHello.loadbalance=random&methods.SayHello.retries=3&methods.SayHello.tps.limit.interval=&methods.SayHello.tps.limit.rate=&methods.SayHello.tps.limit.strategy=&methods.SayHello.weight=0&methods.SayHello4.loadbalance=random&methods.SayHello4.retries=3&methods.SayHello4.tps.limit.interval=&methods.SayHello4.tps.limit.rate=&methods.SayHello4.tps.limit.strategy=&methods.SayHello4.weight=0&methods.SayHello5.loadbalance=random&methods.SayHello5.retries=3&methods.SayHello5.tps.limit.interval=&methods.SayHello5.tps.limit.rate=&methods.SayHello5.tps.limit.strategy=&methods.SayHello5.weight=0&module=dubbogoproxy+tc+client&name=Demo+Micro+Service&organization=dubbogoproxy.com&owner=ZX&param.sign=&registry.role=3&release=dubbo-golang-1.3.0&retries=&serialization=&service.filter=echo%2Ctoken%2Caccesslog%2Ctps%2Cgeneric_service%2Cexecute%2Cpshutdown&side=provider&ssl-enabled=false&timestamp=1610350614&tps.limit.interval=&tps.limit.rate=&tps.limit.rejected.handler=&tps.limit.strategy=&tps.limiter=&version=1.0.0&warmup=100!
2021-01-11T15:36:55.003+0800 INFO dubbo/dubbo_protocol.go:86 Export service: dubbo://:20000/DemoProvider?accesslog=&app.version=1.0.0&application=Demo+Micro+Service&auth=&bean.name=DemoProvider&cluster=failover&environment=dev&execute.limit=&execute.limit.rejected.handler=&group=tc&interface=com.funnycode.DemoService&loadbalance=random&methods.SayHello.loadbalance=random&methods.SayHello.retries=3&methods.SayHello.tps.limit.interval=&methods.SayHello.tps.limit.rate=&methods.SayHello.tps.limit.strategy=&methods.SayHello.weight=0&methods.SayHello4.loadbalance=random&methods.SayHello4.retries=3&methods.SayHello4.tps.limit.interval=&methods.SayHello4.tps.limit.rate=&methods.SayHello4.tps.limit.strategy=&methods.SayHello4.weight=0&methods.SayHello5.loadbalance=random&methods.SayHello5.retries=3&methods.SayHello5.tps.limit.interval=&methods.SayHello5.tps.limit.rate=&methods.SayHello5.tps.limit.strategy=&methods.SayHello5.weight=0&module=dubbogoproxy+tc+client&name=Demo+Micro+Service&organization=dubbogoproxy.com&owner=ZX&param.sign=&registry.role=3&release=dubbo-golang-1.3.0&retries=&serialization=&service.filter=echo%2Ctoken%2Caccesslog%2Ctps%2Cgeneric_service%2Cexecute%2Cpshutdown&side=provider&ssl-enabled=false&timestamp=1610350614&tps.limit.interval=&tps.limit.rate=&tps.limit.rejected.handler=&tps.limit.strategy=&tps.limiter=&version=1.0.0&warmup=100

3.9 复现代码

四、参考

篇幅有限，就介绍到这里。欢迎有兴趣的同学来参与 dubbogo3.0 的建设，感谢阅读。

Blog: dubbo-go源码笔记（二）客户端调用过程

Fri, 15 Jan 2021 00:00:00 +0000

前言

有了上一篇文章《dubbo-go 源码笔记（一）Server服务暴露过程详解》的铺垫，可以大致上类比客户端服务类似于服务端启动过程。其中最大的区别是服务端通过zk注册服务，发布自己的ivkURL并订阅事件开启监听；而服务端应该是通过zk注册组件，拿到需要调用的serviceURL，更新invoker并重写用户的RPCService，从而实现对远程过程调用细节的封装。

1. 配置文件和客户端源码

1.1 client配置文件

helloworld提供的demo：profiles/client.yaml

registries :
 "demoZk":
 protocol: "zookeeper"
 timeout : "3s"
 address: "127.0.0.1:2181"
 username: ""
 password: ""
references:
 "UserProvider":
 # 可以指定多个registry，使用逗号隔开;不指定默认向所有注册中心注册
 registry: "demoZk"
 protocol : "dubbo"
 interface : "com.ikurento.user.UserProvider"
 cluster: "failover"
 methods :
 - name: "GetUser"
 retries: 3

可看到配置文件与之前讨论过的server端非常类似，其refrences部分字段就是对当前服务要主调的服务的配置，其中详细说明了调用协议、注册协议、接口id、调用方法、集群策略等，这些配置都会在之后与注册组件交互，重写ivk、调用的过程中使用到。

1.2 客户端使用框架源码

user.go

func init() {
 config.SetConsumerService(userProvider)
 hessian.RegisterPOJO(&User{})
}

main.go

func main() {
 hessian.RegisterPOJO(&User{})
 config.Load()
 time.Sleep(3e9)
 println("\n\n\nstart to test dubbo")
 user := &User{}
 err := userProvider.GetUser(context.TODO(), []interface{}{"A001"}, user)
 if err != nil {
 panic(err)
 }
 println("response result: %v\n", user)
 initSignal()
}

官网提供的helloworld demo的源码。可看到与服务端类似，在user.go内注册了rpc-service，以及需要rpc传输的结构体user。

在main函数中，同样调用了config.Load()函数，之后就可以直接通过实现好的rpc-service：userProvider 直接调用对应的功能函数，即可实现rpc调用。

可以猜到，从hessian注册结构、SetConsumerService，到调用函数.GetUser()期间，用户定义的rpc-service也就是userProvider对应的函数被重写，重写后的GetUser函数已经包含了实现了远程调用逻辑的invoker。

接下来，就要通过阅读源码，看看dubbo-go是如何做到的。

2. 实现远程过程调用

2.1 加载配置文件

config/config_loader.go :Load()

// Load Dubbo Init
func Load() {
 // init router
 initRouter()
 // init the global event dispatcher
 extension.SetAndInitGlobalDispatcher(GetBaseConfig().EventDispatcherType)
 // start the metadata report if config set
 if err := startMetadataReport(GetApplicationConfig().MetadataType, GetBaseConfig().MetadataReportConfig); err != nil {
 logger.Errorf("Provider starts metadata report error, and the error is {%#v}", err)
 return
 }
 // reference config
 loadConsumerConfig()

在main函数中调用的config.Load()函数，进而调用了loadConsumerConfig，类似于之前讲到的server端配置读入函数。

在loadConsumerConfig函数中，进行了三步操作：

检查配置文件并将配置写入内存
在for循环内部，依次引用（refer）并且实例化（implement）每个被调reference。
等待三秒钟所有invoker就绪

其中重要的就是for循环里面的引用和实例化，两步操作，会在接下来展开讨论。

至此，配置已经被写入了框架。

2.2 获取远程Service URL，实现可供调用的invoker

上述的ref.Refer完成的就是这部分的操作。

图（一）

2.2.1 构造注册url

和server端类似，存在注册url和服务url，dubbo习惯将服务url作为注册url的sub。

config/reference_config.go: Refer()

/ Refer ...
func (c *ReferenceConfig) Refer(_ interface{}) {
 //（一）配置url参数(serviceUrl)，将会作为sub
 cfgURL := common.NewURLWithOptions(
 common.WithPath(c.id),
 common.WithProtocol(c.Protocol),
 common.WithParams(c.getUrlMap()),
 common.WithParamsValue(constant.BEAN_NAME_KEY, c.id),
 )
 ...
 // （二）注册地址可以通过url格式给定，也可以通过配置格式给定
 // 这一步的意义就是配置->提取信息生成URL
 if c.Url != "" {// 用户给定url信息，可以是点对点的地址，也可以是注册中心的地址
 // 1. user specified URL, could be peer-to-peer address, or register center's address.
 urlStrings := gxstrings.RegSplit(c.Url, "\\s*[;]+\\s*")
 for _, urlStr := range urlStrings {
 serviceUrl, err := common.NewURL(urlStr)
 ...
 }
 } else {// 配置读入注册中心的信息
 // assemble SubURL from register center's configuration mode
 // 这是注册url，protocol = registry,包含了zk的用户名、密码、ip等等
 c.urls = loadRegistries(c.Registry, consumerConfig.Registries, common.CONSUMER)
 ...
 // set url to regUrls
 for _, regUrl := range c.urls {
 regUrl.SubURL = cfgURL// regUrl的subURl存当前配置url
 }
 }
 //至此，无论通过什么形式，已经拿到了全部的regURL
 // （三）获取registryProtocol实例，调用其Refer方法，传入新构建好的regURL
 if len(c.urls) == 1 {
 // 这一步访问到registry/protocol/protocol.go registryProtocol.Refer
 // 这里是registry
 c.invoker = extension.GetProtocol(c.urls[0].Protocol).Refer(*c.urls[0])
 } else {
 // 如果有多个注册中心，即有多个invoker,则采取集群策略
 invokers := make([]protocol.Invoker, 0, len(c.urls))
 ...
 }

这个函数中，已经处理完从Register配置到RegisterURL的转换,即图（一）中部分：

接下来，已经拿到的url将被传递给RegistryProtocol，进一步refer。

2.2.2 registryProtocol获取到zkRegistry实例，进一步Refer

registry/protocol/protocol.go: Refer

// Refer provider service from registry center
// 拿到的是配置文件registries的url，他能够生成一个invoker = 指向目的addr，以供客户端直接调用。
func (proto *registryProtocol) Refer(url common.URL) protocol.Invoker {
 var registryUrl = url
 // 这里拿到的是referenceConfig，serviceUrl里面包含了Reference的所有信息，包含interfaceName、method等等
 var serviceUrl = registryUrl.SubURL
 if registryUrl.Protocol == constant.REGISTRY_PROTOCOL {// registryUrl.Proto = "registry"
 protocol := registryUrl.GetParam(constant.REGISTRY_KEY, "")
 registryUrl.Protocol = protocol//替换成了具体的值，比如"zookeeper"
 }
 // 接口对象
 var reg registry.Registry
 // （一）实例化接口对象，缓存策略
 if regI, loaded := proto.registries.Load(registryUrl.Key()); !loaded {
 // 缓存中不存在当前registry，新建一个reg
 reg = getRegistry(&registryUrl)
 // 缓存起来
 proto.registries.Store(registryUrl.Key(), reg)
 } else {
 reg = regI.(registry.Registry)
 }
 // 到这里，获取到了reg实例 zookeeper的registry
 //（二）根据Register的实例zkRegistry和传入的regURL新建一个directory
 // 这一步存在复杂的异步逻辑，从注册中心拿到了目的service的真实addr，获取了invoker并放入directory，
 // 这一步将在下面详细给出步骤
 // new registry directory for store service url from registry
 directory, err := extension.GetDefaultRegistryDirectory(&registryUrl, reg)
 if err != nil {
 logger.Errorf("consumer service %v create registry directory error, error message is %s, and will return nil invoker!",
 serviceUrl.String(), err.Error())
 return nil
 }
 // （三）DoRegister 在zk上注册当前client service
 err = reg.Register(*serviceUrl)
 if err != nil {
 logger.Errorf("consumer service %v register registry %v error, error message is %s",
 serviceUrl.String(), registryUrl.String(), err.Error())
 }
 // （四）new cluster invoker，将directory写入集群，获得具有集群策略的invoker
 cluster := extension.GetCluster(serviceUrl.GetParam(constant.CLUSTER_KEY, constant.DEFAULT_CLUSTER))
 invoker := cluster.Join(directory)
 // invoker保存
 proto.invokers = append(proto.invokers, invoker)
 return invoker
}

可详细阅读上述注释，这个函数完成了从url到invoker的全部过程

（一）首先获得Registry对象，默认是之前实例化的zkRegistry，和之前server获取Registry的处理很类似。（二）通过构造一个新的directory，异步拿到之前在zk上注册的server端信息，生成invoker （三）在zk上注册当前service （四）集群策略，获得最终invoker

这一步完成了图（一）中所有余下的绝大多数操作，接下来就需要详细的查看directory的构造过程：

2.2.3 构造directory（包含较复杂的异步操作）

图（二）

上述的 extension.GetDefaultRegistryDirectory(&registryUrl, reg)函数，本质上调用了已经注册好的NewRegistryDirectory函数:

registry/directory/directory.go: NewRegistryDirectory()

// NewRegistryDirectory will create a new RegistryDirectory
// 这个函数作为default注册在extension上面
// url为注册url，reg为zookeeper registry
func NewRegistryDirectory(url *common.URL, registry registry.Registry) (cluster.Directory, error) {
 if url.SubURL == nil {
 return nil, perrors.Errorf("url is invalid, suburl can not be nil")
 }
 dir := &RegistryDirectory{
 BaseDirectory: directory.NewBaseDirectory(url),
 cacheInvokers: []protocol.Invoker{},
 cacheInvokersMap: &sync.Map{},
 serviceType: url.SubURL.Service(),
 registry: registry,
 }
 dir.consumerConfigurationListener = newConsumerConfigurationListener(dir)
 go dir.subscribe(url.SubURL)
 return dir, nil
}

首先构造了一个注册directory，开启携程调用其subscribe函数，传入serviceURL。

这个directory目前包含了对应的zkRegistry，以及传入的URL，他cacheInvokers的部分是空的。

进入dir.subscribe(url.SubURL)这个异步函数：

registry/directory/directory.go: subscribe()

// subscribe from registry
func (dir *RegistryDirectory) subscribe(url *common.URL) {
 // 增加两个监听，
 dir.consumerConfigurationListener.addNotifyListener(dir)
 dir.referenceConfigurationListener = newReferenceConfigurationListener(dir, url)
 // subscribe调用
 dir.registry.Subscribe(url, dir)
}

重点来了，他调用了zkRegistry的Subscribe方法,与此同时将自己作为ConfigListener传入

我认为这种传入listener的设计模式非常值得学习，而且很有java的味道。

针对等待zk返回订阅信息这样的异步操作，需要传入一个Listener，这个Listener需要实现Notify方法，进而在作为参数传入内部之后，可以被异步地调用Notify，将内部触发的异步事件“传递出来”，再进一步处理加工。

层层的Listener事件链，能将传入的原始serviceURL通过zkConn发送给zk服务，获取到服务端注册好的url对应的二进制信息。

而Notify回调链，则将这串byte[]一步一步解析、加工；以事件的形式向外传递，最终落到directory上的时候，已经是成型的newInvokers了。

具体细节不再以源码形式展示，可参照上图查阅源码。

至此已经拿到了server端注册好的真实invoker。

完成了图（一）中的部分：

2.2.4 构造带有集群策略的clusterinvoker

经过上述操作，已经拿到了server端Invokers，放入了directory的cacheinvokers数组里面缓存。

后续的操作对应本文2.2.2的第四步，由directory生成带有特性集群策略的invoker

// （四）new cluster invoker，将directory写入集群，获得具有集群策略的invoker
 cluster := extension.GetCluster(serviceUrl.GetParam(constant.CLUSTER_KEY, constant.DEFAULT_CLUSTER))
 invoker := cluster.Join(directory)
123

Join函数的实现就是如下函数：

cluster/cluster_impl/failover_cluster_invokers.go: newFailoverClusterInvoker()

func newFailoverClusterInvoker(directory cluster.Directory) protocol.Invoker {
 return &failoverClusterInvoker{
 baseClusterInvoker: newBaseClusterInvoker(directory),
 }
}
12345

dubbo-go框架默认选择failover策略，既然返回了一个invoker，我们查看一下failoverClusterInvoker的Invoker方法，看他是如何将集群策略封装到Invoker函数内部的：

cluster/cluster_impl/failover_cluster_invokers.go: Invoker()

// Invoker 函数
func (invoker *failoverClusterInvoker) Invoke(ctx context.Context, invocation protocol.Invocation) protocol.Result {
 ...
 //调用List方法拿到directory缓存的所有invokers
 invokers := invoker.directory.List(invocation)
 if err := invoker.checkInvokers(invokers, invocation); err != nil {// 检查是否可以实现调用
 return &protocol.RPCResult{Err: err}
 }
 // 获取来自用户方向传入的
 methodName := invocation.MethodName()
 retries := getRetries(invokers, methodName)
 loadBalance := getLoadBalance(invokers[0], invocation)
 for i := 0; i <= retries; i++ {
 // 重要！这里是集群策略的体现，失败后重试！
 //Reselect before retry to avoid a change of candidate `invokers`.
 //NOTE: if `invokers` changed, then `invoked` also lose accuracy.
 if i > 0 {
 if err := invoker.checkWhetherDestroyed(); err != nil {
 return &protocol.RPCResult{Err: err}
 }
 invokers = invoker.directory.List(invocation)
 if err := invoker.checkInvokers(invokers, invocation); err != nil {
 return &protocol.RPCResult{Err: err}
 }
 }
 // 这里是负载均衡策略的体现！选择特定ivk进行调用。
 ivk := invoker.doSelect(loadBalance, invocation, invokers, invoked)
 if ivk == nil {
 continue
 }
 invoked = append(invoked, ivk)
 //DO INVOKE
 result = ivk.Invoke(ctx, invocation)
 if result.Error() != nil {
 providers = append(providers, ivk.GetUrl().Key())
 continue
 }
 return result
 }
 ...
}

看了很多Invoke函数的实现，所有类似的Invoker函数都包含两个方向，一个是用户方向的invcation，一个是函数方向的底层invokers。

而集群策略的invoke函数本身作为接线员，把invocation一步步解析，根据调用需求和集群策略，选择特定的invoker来执行

proxy函数也是这样，一个是用户方向的ins[] reflect.Type, 一个是函数方向的invoker。

proxy函数负责将ins转换为invocation，调用对应invoker的invoker函数，实现连通。

而出于这样的设计，可以在一步步Invoker封装的过程中，每个Invoker只关心自己负责操作的部分，从而使整个调用栈解耦。

妙啊！！！

至此，我们理解了failoverClusterInvoker 的Invoke函数实现，也正是和这个集群策略Invoker被返回，接受来自上方的调用。

已完成图（一）中的：

2.2.5 在zookeeper上注册当前client

拿到invokers后，可以回到：

config/refrence_config.go: Refer()函数了。

 if len(c.urls) == 1 {
 // 这一步访问到registry/protocol/protocol.go registryProtocol.Refer
 c.invoker = extension.GetProtocol(c.urls[0].Protocol).Refer(*c.urls[0])
 // （一）拿到了真实的invokers
 } else {
 // 如果有多个注册中心，即有多个invoker,则采取集群策略
 invokers := make([]protocol.Invoker, 0, len(c.urls))
 ...
 cluster := extension.GetCluster(hitClu)
 // If 'zone-aware' policy select, the invoker wrap sequence would be:
 // ZoneAwareClusterInvoker(StaticDirectory) ->
 // FailoverClusterInvoker(RegistryDirectory, routing happens here) -> Invoker
 c.invoker = cluster.Join(directory.NewStaticDirectory(invokers))
 }
 // （二）create proxy，为函数配置代理
 if c.Async {
 callback := GetCallback(c.id)
 c.pxy = extension.GetProxyFactory(consumerConfig.ProxyFactory).GetAsyncProxy(c.invoker, callback, cfgURL)
 } else {
 // 这里c.invoker已经是目的addr了
 c.pxy = extension.GetProxyFactory(consumerConfig.ProxyFactory).GetProxy(c.invoker, cfgURL)
 }

我们有了可以打通的invokers，但还不能直接调用，因为invoker的入参是invocation，而调用函数使用的是具体的参数列表。需要通过一层proxy来规范入参和出参。

接下来新建一个默认proxy，放置在c.proxy内，以供后续使用

至此，完成了图（一）中最后的操作

2.3 将调用逻辑以代理函数的形式写入rpc-service

上面完成了config.Refer操作

回到config/config_loader.go: loadConsumerConfig()

下一个重要的函数是Implement，他完的操作较为简单：旨在使用上面生成的c.proxy代理，链接用户自己定义的rpcService到clusterInvoker的信息传输。

函数较长，只选取了重要的部分:

common/proxy/proxy.go: Implement()

// Implement
// proxy implement
// In consumer, RPCService like:
// type XxxProvider struct {
// Yyy func(ctx context.Context, args []interface{}, rsp *Zzz) error
// }
// Implement 实现的过程，就是proxy根据函数名和返回值，通过调用invoker 构造出拥有远程调用逻辑的代理函数
// 将当前rpc所有可供调用的函数注册到proxy.rpc内
func (p *Proxy) Implement(v common.RPCService) {
 // makeDubboCallProxy 这是一个构造代理函数，这个函数的返回值是func(in []reflect.Value) []reflect.Value 这样一个函数
 // 这个被返回的函数是请求实现的载体，由他来发起调用获取结果
 makeDubboCallProxy := func(methodName string, outs []reflect.Type) func(in []reflect.Value) []reflect.Value {
 return func(in []reflect.Value) []reflect.Value {
 // 根据methodName和outs的类型，构造这样一个函数，这个函数能将in 输入的value转换为输出的value
 // 这个函数具体的实现如下：
 ...
 // 目前拿到了 methodName、所有入参的interface和value，出参数reply
 // （一）根据这些生成一个 rpcinvocation
 inv = invocation_impl.NewRPCInvocationWithOptions(
 invocation_impl.WithMethodName(methodName),
 invocation_impl.WithArguments(inIArr),
 invocation_impl.WithReply(reply.Interface()),
 invocation_impl.WithCallBack(p.callBack),
 invocation_impl.WithParameterValues(inVArr))
 for k, value := range p.attachments {
 inv.SetAttachments(k, value)
 }
 // add user setAttachment
 atm := invCtx.Value(constant.AttachmentKey) // 如果传入的ctx里面有attachment，也要写入inv
 if m, ok := atm.(map[string]string); ok {
 for k, value := range m {
 inv.SetAttachments(k, value)
 }
 }
 // 至此构造inv完毕
 // (二）触发Invoker 之前已经将cluster_invoker放入proxy，使用Invoke方法，通过getty远程过程调用
 result := p.invoke.Invoke(invCtx, inv)
 // 如果有attachment，则加入
 if len(result.Attachments()) > 0 {
 invCtx = context.WithValue(invCtx, constant.AttachmentKey, result.Attachments())
 }
 ...
 }
 }
 numField := valueOfElem.NumField()
 for i := 0; i < numField; i++ {
 t := typeOf.Field(i)
 methodName := t.Tag.Get("dubbo")
 if methodName == "" {
 methodName = t.Name
 }
 f := valueOfElem.Field(i)
 if f.Kind() == reflect.Func && f.IsValid() && f.CanSet() { // 针对于每个函数
 outNum := t.Type.NumOut()
 // 规定函数输出只能有1/2个
 if outNum != 1 && outNum != 2 {
 logger.Warnf("method %s of mtype %v has wrong number of in out parameters %d; needs exactly 1/2",
 t.Name, t.Type.String(), outNum)
 continue
 }
 // The latest return type of the method must be error.
 // 规定最后一个返回值一定是error
 if returnType := t.Type.Out(outNum - 1); returnType != typError {
 logger.Warnf("the latest return type %s of method %q is not error", returnType, t.Name)
 continue
 }
 // 获取到所有的出参类型，放到数组里
 var funcOuts = make([]reflect.Type, outNum)
 for i := 0; i < outNum; i++ {
 funcOuts[i] = t.Type.Out(i)
 }
 // do method proxy here:
 // （三）调用make函数，传入函数名和返回值，获得能调用远程的proxy，将这个proxy替换掉原来的函数位置
 f.Set(reflect.MakeFunc(f.Type(), makeDubboCallProxy(methodName, funcOuts)))
 logger.Debugf("set method [%s]", methodName)
 }
 }
 ...
}

正如之前所说，proxy的作用是将用户定义的函数参数列表，转化为抽象的invocation传入Invoker，进行调用。

其中已标明有三处较为重要的地方：

在代理函数中实现由参数列表生成Invocation的逻辑
在代理函数实现调用Invoker的逻辑
将代理函数替换为原始rpc-service对应函数至此，也就解决了一开始的问题： client.go: main()

 config.Load()
 user := &User{}
 err := userProvider.GetUser(context.TODO(), []interface{}{"A001"}, user)

这里直接调用用户定义的rpcService的函数GetUser，这里实际调用的是经过重写入的函数代理，所以就能实现远程调用了。

3. 从client到server的invoker嵌套链- 小结

在阅读dubbo-go源码的过程中，我能发现一条清晰的invoker-proxy嵌套链，我希望通过图的形式来展现：

作者简介李志信 (GitHubID LaurenceLiZhixin)，中山大学软件工程专业在校学生，擅长使用 Java/Go 语言，专注于云原生和微服务等技术方向。

Blog: dubbogo 3.0：牵手 gRPC 走向云原生时代

Fri, 15 Jan 2021 00:00:00 +0000

自从 2011 年 Dubbo 开源之后，被大量中小公司采用，一直是国内最受欢迎的 RPC 框架。2014 年，由于阿里内部组织架构调整，Dubbo 暂停维护了一段时间，之后随着 Spring Cloud 的面世，两个体系在融合中一起助推了微服务的火热。

不过这世界变化快，自从以 docker 为代表的的容器技术和以 K8s 为代表的容器编排技术登上舞台之后，云原生时代到来了。在云原生时代，不可变的基础设施给原有的中间件带来了不可变的中间件基础设施：gRPC 统一了底层通信层；protobuf 统一了序列化协议；以 envoy + istio 为代表的 service mesh 逐渐统一了服务的控制面与数据面。

dubbogo 的天然使命是：Bridging the gap between Java and Go。保持 Go 应用与 Java 应用互联互通的同时，借助 Go 语言（事实上的第一云原生语言）的优势拥抱云原生时代。dubbogo 社区 2020 年勠力打造三支箭：

已经发布的对齐 dubbo 2.7 的 dubbogo v1.5 版本；
近期将要发布的 sidecar 形态的 dubbo-go-proxy 项目；
以及处于进行时的 dubbogo 3.0。

用一句话概括 dubbogo 3.0 即是：新通信协议、新序列化协议、新应用注册模型以及新的服务治理能力！本文主要着重讨论 dubbogo 3.0 的新通信协议和应用级服务注册发现模型。

dubbogo 3.0 vs gRPC

知己知彼，方能进步。dubbogo 3.0 的通信层改进主要借鉴了 gRPC。

gRPC 协议，简单来说就是 http2 协议的基础之上，增加了特定的协议 header：“grpc-” 开头的 header 字段，采用特定的打解包工具（protobuf）对数据进行序列化，从而实现 RPC 调用。

众所周知，gRPC 几乎没有服务治理能力，而阿里云现有 dubbo 框架兼具 RPC 和服务治理能力，整体实力不逊于 gRPC。但在“大家都用 gRPC” 这样的背景之下，dubbogo 3.0 的新通信协议就必须完美兼容 gRPC，对开发者已部署的服务完全兼容，并在此基础之上延续已有 dubbo 协议和服务治理能力，进而推出一系列新策略：比如 mesh 支持、应用级服务注册等。

dubbogo 3.0 vs dubbogo 1.5

目前已有的 dubbo 2.7 协议已经尽可能实现了 gRPC 的支持。开发者可以通过 protoc-gen-dubbo 工具将 pb IDL 协议转换为框架支持的 stub，再借助底层 gRPC conn 的 RPC 过程，将已有的服务治理能力自上而下传递给 gRPC，因此实现了 gRPC 服务的支持。

dubbo-go v1.5.x 也支持 gRPC 的 Stream 调用。和 unary RPC 类似，通过产生框架支持的 stub，在底层 gRPC stream 调用的基础之上，将流式 RPC 的能力和并入框架。但由于 dubbo v2.7.x / dubbo-go v1.5.x 本身并不支持流式调用，所以没有对 gRPC stream 调用的进行上层服务治理支持。

开发者所面临的问题就是：我们在使用 dubbo-go2.7 进行 grpc 协议传输的时候，或多或少不是那么放心。

而即将推出的 dubbo-go 3.0 协议将从根源解决这个问题。

协议兼容的三种层次

笔者认为，一款服务框架对于第三方协议的支持可分为三个程度：应用层次、协议层次、传输层次。

一款框架如果在一个协议的 sdk 之上封装接口，可以认为它处于应用层次支持，这样的框架需要遵循下层 sdk 的接口，可扩展性较差。

处于协议层次的框架，从配置层到服务治理层均由本框架提供，而在此之下的协议层到网络传输层均使用某个固定的通信协议，这样的框架可以解决服务治理的问题，但框架本身无法与第三方协议完全适配，如果不适配就会出现对第三方协议支持的削弱，比如上面说到的 dubbo-go 1.5 对 stream rpc 支持的缺陷。

如果想进一步支持更多的第三方协议，需要从传输层下手，真正了解第三方协议的具体字段、所依赖的底层协议（比如 HTTP2）的帧模型和数据流，再开发出与第三方协议完全一致的数据交互模块，作为本框架的底层。这样做的好处是最大程度赋予了协议的可扩展性，可以在兼容已有协议的基础之上，可选地增加开发者需要的字段，从而实现已有协议无法实现的功能，就比如 dubbogo 3.0 将支持的反压策略。

基于 HTTP2 的通信流程

gRPC 一次基于 HTTP2 的 unary rpc 调用传输主要流程如下：

client 发送 Magic 信息： PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n；
server 收到并检查是否正确；
client 和 server 互相发送 setting 帧，收到后发送 ACK 确认；
client 发送 Header 帧，包含 gRPC 协议字段，以 End Headers 作为 Header 结束标志；
client 紧接着发送 Data 帧，包含 RPC 调用的 request 信息，以 End Stream 作为 Data 结束标志；
server 调用函数获得结果；
server 发送 Header 帧，包含 gRPC 协议字段，以 End Headers 作为 Header 结束标志；
server 紧接着发送 Data 帧，包含 RPC 调用回传的 response 信息；
server 紧接着再次发送 Header 帧，包含 RPC 状态和 message 信息，以 End Stream 作为本次 RPC 调用结束标志。

其中包含 gRPC 调用信息的 HTTP2 Header 帧如下图：

另外，在 gRPC 的 stream 调用中，可在 server 端回传的过程中发送多次 Data，调用结束后再发送 Header 终止 RPC 过程，并汇报状态信息。

dubbogo 3.0 的通信层将在 HTTP2 通信协议之上采用同样的通信流程，以保证与 gRPC 的底层通信沟通能力。

dubbogo 3.0 预期通信架构

除了通信协议采用 HTTP2 外，dubbogo 3.0 将采用基于 google protobuf 的 triple 协议【下面称为 dubbo3 协议】作为 dubbogo 3.0 的序列化协议，为 dubbo 将来支持更多的编程语言打下通信协议层面的基础。

目前设计的 dubbogo 3.0 传输模型如下：

为保证同时支持 unary RPC 和 stream RPC，在 server 端和 client 端增加数据流结构，以异步调用的形式完成数据传递；
继续支持原有的 TCP 通信能力；
在 HTTP2 的通信协议之上支持 dubbo3 协议，decode 过程兼容 gRPC 使用的 protobuf，保证与 gRPC 服务打通。

应用级服务注册发现

1. 应用级服务注册发现介绍

dubbogo 3.0 使用的新一代服务注册发现体系，将摒弃旧版的“接口级注册发现”，使用“应用级别注册发现”。

简单地说，接口级别注册发现，在注册中心中以 RPC 服务为 key，以实例列表作为 value 来组织数据的，而我们新引入的“应用粒度的服务发现”，它以应用名（Application）作为 key，以这个应用部署的一组实例（Instance）列表作为 value。这带来两点不同：

数据映射关系变了，从 RPC Service -> Instance 变为 Application -> Instance；
数据变少了，注册中心没有了 RPC Service 及其相关配置信息。

可以认为，基于应用粒度的模型所存储和推送的数据量是和应用、实例数成正比的，只有当我们的应用数增多或应用的实例数增长时，地址推送压力才会上涨。

而对于基于接口粒度的模型，数据量是和接口数量正相关的，鉴于一个应用通常发布多个接口的现状，其数量级一般是比应用粒度的数十倍。另外一个关键点在于，接口的定义更多的是业务侧的内部行为，接口粒度导致的集群规模评估的不透明，而实例、应用增长都通常是在运维侧的规划之中，可控性较好。

工商银行曾经对这两个模型进行生产测算：应用级服务注册模型可以让注册中心上的数据量变成原来的 1.68%，新模型可以让 zookeeper 轻松支撑 10 万级别的服务量和 10 万级别的节点量。

2. 元数据中心同步机制的引入

数据中心的数据量变少所造成的结果，是 RPC 服务相关的数据在注册中心消失了，只有 application - instance 这两个层级的数据。为了保证这部分缺少的 RPC 服务数据仍然能被 Consumer 端正确的感知，我们在 Consumer 和 Provider 间建立了一条单独的通信通道，目前针对元数据同步有两种具体的可选方案，分别是：

内建 MetadataService；
独立的元数据中心，通过中细化的元数据集群协调数据。

3. 兼容旧版本 dubbo-go

为了使整个开发流程对老的 dubbo-go 用户更透明，同时避免指定 provider 对可扩展性带来的影响），我们设计了一套 RPC服务到应用名的映射关系，以尝试在 consumer 自动完成 RPC 服务到 provider 应用名的转换。

这套设计可以让 dubbogo 3.0 中同时保持对 dubbo v2.6.x、dubbo v2.7.x 和 dubbo v3.0.x 三个大版的互联互通。

统一路由的支持

路由在概念上可以理解为从已有的所有 IP 地址列表中，根据特定的路由规则，挑选出需要的 ip 地址子集。路由的过程需要根据配置好的路由规则进行筛选，最终取所有路由规则的交集获得结果。多个路由如同流水线一样，形成一条路由链，从所有的地址表中筛选出最终目的地址集合，再通过负载均衡策略选择访问的地址。

1. 路由链

可以把路由链的逻辑简单理解为 target = rn(…r3(r2(r1(src))))。对于每一个 router 内部的逻辑，可以抽象为输入地址 addrs-in 与 router 中按全量地址 addrs-all 实现切分好的 n 个互不相交的地址池 addrs-pool-1 … addrs-pool-n 按实现定义好的规则取交集作为输出地址。以此类推，完成整个路由链的计算。

2. failover

在路由规则配置文件中可以配置 failover 字段。在寻找地址失败时可以 failover，选择其他 subset，并且顺序执行下来，直到找到地址，否则最后报地址找不到异常。

3. 兜底路由

在的路由规则配置中，可以配置一个没有任何条件的 match, 最终的结果是至少会有一个 subset 被选到，以达到地址空保护的作用。

作为 2020 年 dubbogo 社区打造并将在 2021 年初亮出的的三支箭之一，dubbogo 3.0 将带来不同平常且焕然一新的开发体验，敬请广大开发者期待！

如果你有任何疑问，欢迎钉钉扫码加入交流群【钉钉群号 31363295】：

dubbogo 3.0 目前是社区和 dubbo 官方团队– 阿里中间件团队共同合作开发。

阿里云-中间件团队招募对 dubbo3 (java & go)、dapr、arthas 有兴趣的开发者。可以钉钉联系 northlatitude，或者发送邮件至 beiwei.ly@alibaba-inc.com。

作者简介

李志信 (GitHubID LaurenceLiZhixin)，阿里云云原生中间件团队开发工程师，dubbogo 社区开发者，中山大学软件工程专业在校学生，擅长使用 Go 语言，专注于云原生和微服务等技术方向。

于雨(github @AlexStocks)，dubbo-go 项目和社区负责人，一个有十多年服务端做着基础架构研发一线工作经验的程序员，陆续参与改进过 Muduo/Pika/Dubbo/Sentinel-go 等知名项目，目前在蚂蚁金服可信原生部从事容器编排和 service mesh 工作。

Blog: 分布式事务框架 seata-golang 通信模型详解

Fri, 15 Jan 2021 00:00:00 +0000

简介

Java 的世界里，大家广泛使用一个高性能网络通信框架 —— netty，很多 RPC 框架都是基于 netty 来实现的。在 golang 的世界里，getty 也是一个类似 netty 的高性能网络通信库。getty 最初由 dubbo-go 项目负责人于雨开发，作为底层通信库在 dubbo-go 中使用。随着 dubbo-go 捐献给 apache 基金会，在社区小伙伴的共同努力下，getty 也最终进入到 apache 这个大家庭，并改名 dubbo-getty。

18 年的时候，我在公司里实践微服务，当时遇到最大的问题就是分布式事务问题。同年，阿里在社区开源他们的分布式事务解决方案，我也很快关注到这个项目，起初还叫 fescar，后来更名 seata。由于我对开源技术很感兴趣，加了很多社区群，当时也很关注 dubbo-go 这个项目，在里面默默潜水。随着对 seata 的了解，逐渐萌生了做一个 go 版本的分布式事务框架的想法。

要做一个 golang 版的分布式事务框架，首先需要解决的一个问题就是如何实现 RPC 通信。dubbo-go 就是摆在眼前很好的一个例子，遂开始研究 dubbo-go 的底层 getty。

如何基于 getty 实现 RPC 通信

getty 框架的整体模型图如下：

下面结合相关代码，详述 seata-golang 的 RPC 通信过程。

1. 建立连接

实现 RPC 通信，首先要建立网络连接，这里先从 client.go 开始看起。

func (c *client) connect() {
 var (
 err error
 ss Session
 )

 for {
 // 建立一个 session 连接
 ss = c.dial()
 if ss == nil {
 // client has been closed
 break
 }
 err = c.newSession(ss)
 if err == nil {
 // 收发报文
 ss.(*session).run()
 // 此处省略部分代码

 break
 }
 // don't distinguish between tcp connection and websocket connection. Because
 // gorilla/websocket/conn.go:(Conn)Close also invoke net.Conn.Close()
 ss.Conn().Close()
 }
}

connect() 方法通过 dial() 方法得到了一个 session 连接，进入 dial() 方法：

func (c *client) dial() Session {
 switch c.endPointType {
 case TCP_CLIENT:
 return c.dialTCP()
 case UDP_CLIENT:
 return c.dialUDP()
 case WS_CLIENT:
 return c.dialWS()
 case WSS_CLIENT:
 return c.dialWSS()
 }

 return nil
}

我们关注的是 TCP 连接，所以继续进入 c.dialTCP() 方法：

func (c *client) dialTCP() Session {
 var (
 err error
 conn net.Conn
 )

 for {
 if c.IsClosed() {
 return nil
 }
 if c.sslEnabled {
 if sslConfig, err := c.tlsConfigBuilder.BuildTlsConfig(); err == nil && sslConfig != nil {
 d := &net.Dialer{Timeout: connectTimeout}
 // 建立加密连接
 conn, err = tls.DialWithDialer(d, "tcp", c.addr, sslConfig)
 }
 } else {
 // 建立 tcp 连接
 conn, err = net.DialTimeout("tcp", c.addr, connectTimeout)
 }
 if err == nil && gxnet.IsSameAddr(conn.RemoteAddr(), conn.LocalAddr()) {
 conn.Close()
 err = errSelfConnect
 }
 if err == nil {
 // 返回一个 TCPSession
 return newTCPSession(conn, c)
 }

 log.Infof("net.DialTimeout(addr:%s, timeout:%v) = error:%+v", c.addr, connectTimeout, perrors.WithStack(err))
 <-wheel.After(connectInterval)
 }
}

至此，我们知道了 getty 如何建立 TCP 连接，并返回 TCPSession。

2. 收发报文

那它是怎么收发报文的呢，我们回到 connection 方法接着往下看，有这样一行 ss.(*session).run()，在这行代码之后，代码都是很简单的操作，我们猜测这行代码运行的逻辑里面一定包含收发报文的逻辑，接着进入 run() 方法：

func (s *session) run() {
 // 省略部分代码

 go s.handleLoop()
 go s.handlePackage()
}

这里起了两个 goroutine：handleLoop 和 handlePackage，看字面意思符合我们的猜想，进入 handleLoop() 方法：

func (s *session) handleLoop() {
 // 省略部分代码

 for {
 // A select blocks until one of its cases is ready to run.
 // It choose one at random if multiple are ready. Otherwise it choose default branch if none is ready.
 select {
 // 省略部分代码

 case outPkg, ok = <-s.wQ:
 // 省略部分代码

 iovec = iovec[:0]
 for idx := 0; idx < maxIovecNum; idx++ {
 // 通过 s.writer 将 interface{} 类型的 outPkg 编码成二进制的比特
 pkgBytes, err = s.writer.Write(s, outPkg)
 // 省略部分代码

 iovec = append(iovec, pkgBytes)

 //省略部分代码
 }
 // 将这些二进制比特发送出去
 err = s.WriteBytesArray(iovec[:]...)
 if err != nil {
 log.Errorf("%s, [session.handleLoop]s.WriteBytesArray(iovec len:%d) = error:%+v",
 s.sessionToken(), len(iovec), perrors.WithStack(err))
 s.stop()
 // break LOOP
 flag = false
 }

 case <-wheel.After(s.period):
 if flag {
 if wsFlag {
 err := wsConn.writePing()
 if err != nil {
 log.Warnf("wsConn.writePing() = error:%+v", perrors.WithStack(err))
 }
 }
 // 定时执行的逻辑，心跳等
 s.listener.OnCron(s)
 }
 }
 }
}

通过上面的代码，我们不难发现，handleLoop() 方法处理的是发送报文的逻辑，RPC 需要发送的消息首先由 s.writer 编码成二进制比特，然后通过建立的 TCP 连接发送出去。这个 s.writer 对应的 Writer 接口是 RPC 框架必须要实现的一个接口。

继续看 handlePackage() 方法：

func (s *session) handlePackage() {
 // 省略部分代码

 if _, ok := s.Connection.(*gettyTCPConn); ok {
 if s.reader == nil {
 errStr := fmt.Sprintf("session{name:%s, conn:%#v, reader:%#v}", s.name, s.Connection, s.reader)
 log.Error(errStr)
 panic(errStr)
 }

 err = s.handleTCPPackage()
 } else if _, ok := s.Connection.(*gettyWSConn); ok {
 err = s.handleWSPackage()
 } else if _, ok := s.Connection.(*gettyUDPConn); ok {
 err = s.handleUDPPackage()
 } else {
 panic(fmt.Sprintf("unknown type session{%#v}", s))
 }
}

进入 handleTCPPackage() 方法：

func (s *session) handleTCPPackage() error {
 // 省略部分代码

 conn = s.Connection.(*gettyTCPConn)
 for {
 // 省略部分代码

 bufLen = 0
 for {
 // for clause for the network timeout condition check
 // s.conn.SetReadTimeout(time.Now().Add(s.rTimeout))
 // 从 TCP 连接中收到报文
 bufLen, err = conn.recv(buf)
 // 省略部分代码

 break
 }
 // 省略部分代码

 // 将收到的报文二进制比特写入 pkgBuf
 pktBuf.Write(buf[:bufLen])
 for {
 if pktBuf.Len() <= 0 {
 break
 }
 // 通过 s.reader 将收到的报文解码成 RPC 消息
 pkg, pkgLen, err = s.reader.Read(s, pktBuf.Bytes())
 // 省略部分代码

 s.UpdateActive()
 // 将收到的消息放入 TaskQueue 供 RPC 消费端消费
 s.addTask(pkg)
 pktBuf.Next(pkgLen)
 // continue to handle case 5
 }
 if exit {
 break
 }
 }

 return perrors.WithStack(err)
}

从上面的代码逻辑我们分析出，RPC 消费端需要将从 TCP 连接收到的二进制比特报文解码成 RPC 能消费的消息，这个工作由 s.reader 实现，所以，我们要构建 RPC 通信层也需要实现 s.reader 对应的 Reader 接口。

3. 底层处理网络报文的逻辑如何与业务逻辑解耦

我们都知道，netty 通过 boss 线程和 worker 线程实现了底层网络逻辑和业务逻辑的解耦。那么，getty 是如何实现的呢？

在 handlePackage() 方法最后，我们看到，收到的消息被放入了 s.addTask(pkg) 这个方法，接着往下分析：

func (s *session) addTask(pkg interface{}) {
 f := func() {
 s.listener.OnMessage(s, pkg)
 s.incReadPkgNum()
 }
 if taskPool := s.EndPoint().GetTaskPool(); taskPool != nil {
 taskPool.AddTaskAlways(f)
 return
 }
 f()
}

pkg 参数传递到了一个匿名方法，这个方法最终放入了 taskPool。这个方法很关键，在我后来写 seata-golang 代码的时候，就遇到了一个坑，这个坑后面分析。

接着我们看一下 taskPool 的定义：

// NewTaskPoolSimple build a simple task pool
func NewTaskPoolSimple(size int) GenericTaskPool {
 if size < 1 {
 size = runtime.NumCPU() * 100
 }
 return &taskPoolSimple{
 work: make(chan task),
 sem: make(chan struct{}, size),
 done: make(chan struct{}),
 }
}

构建了一个缓冲大小为 size （默认为 runtime.NumCPU() * 100）的 channel sem。再看方法 AddTaskAlways(t task)：

func (p *taskPoolSimple) AddTaskAlways(t task) {
 select {
 case <-p.done:
 return
 default:
 }

 select {
 case p.work <- t:
 return
 default:
 }
 select {
 case p.work <- t:
 case p.sem <- struct{}{}:
 p.wg.Add(1)
 go p.worker(t)
 default:
 goSafely(t)
 }
}

加入的任务，会先由 len(p.sem) 个 goroutine 去消费，如果没有 goroutine 空闲，则会启动一个临时的 goroutine 去运行 t()。相当于有 len(p.sem) 个 goroutine 组成了 goroutine pool，pool 中的 goroutine 去处理业务逻辑，而不是由处理网络报文的 goroutine 去运行业务逻辑，从而实现了解耦。写 seata-golang 时遇到的一个坑，就是忘记设置 taskPool 造成了处理业务逻辑和处理底层网络报文逻辑的 goroutine 是同一个，我在业务逻辑中阻塞等待一个任务完成时，阻塞了整个 goroutine，使得阻塞期间收不到任何报文。

4. 具体实现

下面的代码见getty.go ：

// Reader is used to unmarshal a complete pkg from buffer
type Reader interface {
 Read(Session, []byte) (interface{}, int, error)
}

// Writer is used to marshal pkg and write to session
type Writer interface {
 // if @Session is udpGettySession, the second parameter is UDPContext.
 Write(Session, interface{}) ([]byte, error)
}

// ReadWriter interface use for handle application packages
type ReadWriter interface {
 Reader
 Writer
}

// EventListener is used to process pkg that received from remote session
type EventListener interface {
 // invoked when session opened
 // If the return error is not nil, @Session will be closed.
 OnOpen(Session) error

 // invoked when session closed.
 OnClose(Session)

 // invoked when got error.
 OnError(Session, error)

 // invoked periodically, its period can be set by (Session)SetCronPeriod
 OnCron(Session)

 // invoked when getty received a package. Pls attention that do not handle long time
 // logic processing in this func. You'd better set the package's maximum length.
 // If the message's length is greater than it, u should should return err in
 // Reader{Read} and getty will close this connection soon.
 //
 // If ur logic processing in this func will take a long time, u should start a goroutine
 // pool(like working thread pool in cpp) to handle the processing asynchronously. Or u
 // can do the logic processing in other asynchronous way.
 // !!!In short, ur OnMessage callback func should return asap.
 //
 // If this is a udp event listener, the second parameter type is UDPContext.
 OnMessage(Session, interface{})
}

通过对整个 getty 代码的分析，我们只要实现 ReadWriter 来对 RPC 消息编解码，再实现 EventListener 来处理 RPC 消息的对应的具体逻辑，将 ReadWriter 实现和 EventLister 实现注入到 RPC 的 Client 和 Server 端，则可实现 RPC 通信。

1）编解码协议实现

下面是 seata 协议的定义：

在 ReadWriter 接口的实现 RpcPackageHandler 中，调用 Codec 方法对消息体按照上面的格式编解码：

// 消息编码为二进制比特
func MessageEncoder(codecType byte, in interface{}) []byte {
 switch codecType {
 case SEATA:
 return SeataEncoder(in)
 default:
 log.Errorf("not support codecType, %s", codecType)
 return nil
 }
}

// 二进制比特解码为消息体
func MessageDecoder(codecType byte, in []byte) (interface{}, int) {
 switch codecType {
 case SEATA:
 return SeataDecoder(in)
 default:
 log.Errorf("not support codecType, %s", codecType)
 return nil, 0
 }
}

2）Client 端实现

再来看 client 端 EventListener 的实现 RpcRemotingClient：

func (client *RpcRemoteClient) OnOpen(session getty.Session) error {
 go func()
 request := protocal.RegisterTMRequest{AbstractIdentifyRequest: protocal.AbstractIdentifyRequest{
 ApplicationId: client.conf.ApplicationId,
 TransactionServiceGroup: client.conf.TransactionServiceGroup,
 }}
 // 建立连接后向 Transaction Coordinator 发起注册 TransactionManager 的请求
 _, err := client.sendAsyncRequestWithResponse(session, request, RPC_REQUEST_TIMEOUT)
 if err == nil {
 // 将与 Transaction Coordinator 建立的连接保存在连接池供后续使用
 clientSessionManager.RegisterGettySession(session)
 client.GettySessionOnOpenChannel <- session.RemoteAddr()
 }
 }()

 return nil
}

// OnError ...
func (client *RpcRemoteClient) OnError(session getty.Session, err error) {
 clientSessionManager.ReleaseGettySession(session)
}

// OnClose ...
func (client *RpcRemoteClient) OnClose(session getty.Session) {
 clientSessionManager.ReleaseGettySession(session)
}

// OnMessage ...
func (client *RpcRemoteClient) OnMessage(session getty.Session, pkg interface{}) {
 log.Info("received message:{%v}", pkg)
 rpcMessage, ok := pkg.(protocal.RpcMessage)
 if ok {
 heartBeat, isHeartBeat := rpcMessage.Body.(protocal.HeartBeatMessage)
 if isHeartBeat && heartBeat == protocal.HeartBeatMessagePong {
 log.Debugf("received PONG from %s", session.RemoteAddr())
 }
 }

 if rpcMessage.MessageType == protocal.MSGTYPE_RESQUEST ||
 rpcMessage.MessageType == protocal.MSGTYPE_RESQUEST_ONEWAY {
 log.Debugf("msgId:%s, body:%v", rpcMessage.Id, rpcMessage.Body)

 // 处理事务消息，提交 or 回滚
 client.onMessage(rpcMessage, session.RemoteAddr())
 } else {
 resp, loaded := client.futures.Load(rpcMessage.Id)
 if loaded {
 response := resp.(*getty2.MessageFuture)
 response.Response = rpcMessage.Body
 response.Done <- true
 client.futures.Delete(rpcMessage.Id)
 }
 }
}

// OnCron ...
func (client *RpcRemoteClient) OnCron(session getty.Session) {
 // 发送心跳
 client.defaultSendRequest(session, protocal.HeartBeatMessagePing)
}

clientSessionManager.RegisterGettySession(session) 的逻辑将在下文中分析。

3）Server 端 Transaction Coordinator 实现

代码见 DefaultCoordinator：

func (coordinator *DefaultCoordinator) OnOpen(session getty.Session) error {
 log.Infof("got getty_session:%s", session.Stat())
 return nil
}

func (coordinator *DefaultCoordinator) OnError(session getty.Session, err error) {
 // 释放 TCP 连接
 SessionManager.ReleaseGettySession(session)
 session.Close()
 log.Errorf("getty_session{%s} got error{%v}, will be closed.", session.Stat(), err)
}

func (coordinator *DefaultCoordinator) OnClose(session getty.Session) {
 log.Info("getty_session{%s} is closing......", session.Stat())
}

func (coordinator *DefaultCoordinator) OnMessage(session getty.Session, pkg interface{}) {
 log.Debugf("received message:{%v}", pkg)
 rpcMessage, ok := pkg.(protocal.RpcMessage)
 if ok {
 _, isRegTM := rpcMessage.Body.(protocal.RegisterTMRequest)
 if isRegTM {
 // 将 TransactionManager 信息和 TCP 连接建立映射关系
 coordinator.OnRegTmMessage(rpcMessage, session)
 return
 }

 heartBeat, isHeartBeat := rpcMessage.Body.(protocal.HeartBeatMessage)
 if isHeartBeat && heartBeat == protocal.HeartBeatMessagePing {
 coordinator.OnCheckMessage(rpcMessage, session)
 return
 }

 if rpcMessage.MessageType == protocal.MSGTYPE_RESQUEST ||
 rpcMessage.MessageType == protocal.MSGTYPE_RESQUEST_ONEWAY {
 log.Debugf("msgId:%s, body:%v", rpcMessage.Id, rpcMessage.Body)
 _, isRegRM := rpcMessage.Body.(protocal.RegisterRMRequest)
 if isRegRM {
 // 将 ResourceManager 信息和 TCP 连接建立映射关系
 coordinator.OnRegRmMessage(rpcMessage, session)
 } else {
 if SessionManager.IsRegistered(session) {
 defer func() {
 if err := recover(); err != nil {
 log.Errorf("Catch Exception while do RPC, request: %v,err: %w", rpcMessage, err)
 }
 }()
 // 处理事务消息，全局事务注册、分支事务注册、分支事务提交、全局事务回滚等
 coordinator.OnTrxMessage(rpcMessage, session)
 } else {
 session.Close()
 log.Infof("close a unhandled connection! [%v]", session)
 }
 }
 } else {
 resp, loaded := coordinator.futures.Load(rpcMessage.Id)
 if loaded {
 response := resp.(*getty2.MessageFuture)
 response.Response = rpcMessage.Body
 response.Done <- true
 coordinator.futures.Delete(rpcMessage.Id)
 }
 }
 }
}

func (coordinator *DefaultCoordinator) OnCron(session getty.Session) {

}

coordinator.OnRegTmMessage(rpcMessage, session) 注册 Transaction Manager，coordinator.OnRegRmMessage(rpcMessage, session) 注册 Resource Manager。具体逻辑分析见下文。

消息进入 coordinator.OnTrxMessage(rpcMessage, session) 方法，将按照消息的类型码路由到具体的逻辑当中：

switch msg.GetTypeCode() {
 case protocal.TypeGlobalBegin:
 req := msg.(protocal.GlobalBeginRequest)
 resp := coordinator.doGlobalBegin(req, ctx)
 return resp
 case protocal.TypeGlobalStatus:
 req := msg.(protocal.GlobalStatusRequest)
 resp := coordinator.doGlobalStatus(req, ctx)
 return resp
 case protocal.TypeGlobalReport:
 req := msg.(protocal.GlobalReportRequest)
 resp := coordinator.doGlobalReport(req, ctx)
 return resp
 case protocal.TypeGlobalCommit:
 req := msg.(protocal.GlobalCommitRequest)
 resp := coordinator.doGlobalCommit(req, ctx)
 return resp
 case protocal.TypeGlobalRollback:
 req := msg.(protocal.GlobalRollbackRequest)
 resp := coordinator.doGlobalRollback(req, ctx)
 return resp
 case protocal.TypeBranchRegister:
 req := msg.(protocal.BranchRegisterRequest)
 resp := coordinator.doBranchRegister(req, ctx)
 return resp
 case protocal.TypeBranchStatusReport:
 req := msg.(protocal.BranchReportRequest)
 resp := coordinator.doBranchReport(req, ctx)
 return resp
 default:
 return nil
 }

4）session manager 分析

Client 端同 Transaction Coordinator 建立连接起连接后，通过 clientSessionManager.RegisterGettySession(session) 将连接保存在 serverSessions = sync.Map{} 这个 map 中。map 的 key 为从 session 中获取的 RemoteAddress 即 Transaction Coordinator 的地址，value 为 session。这样，Client 端就可以通过 map 中的一个 session 来向 Transaction Coordinator 注册 Transaction Manager 和 Resource Manager 了。具体代码见 getty_client_session_manager.go。

Transaction Manager 和 Resource Manager 注册到 Transaction Coordinator 后，一个连接既有可能用来发送 TM 消息也有可能用来发送 RM 消息。我们通过 RpcContext 来标识一个连接信息：

type RpcContext struct {
 Version string
 TransactionServiceGroup string
 ClientRole meta.TransactionRole
 ApplicationId string
 ClientId string
 ResourceSets *model.Set
 Session getty.Session
}

当收到事务消息时，我们需要构造这样一个 RpcContext 供后续事务处理逻辑使用。所以，我们会构造下列 map 来缓存映射关系：

var (
 // session -> transactionRole
 // TM will register before RM, if a session is not the TM registered,
 // it will be the RM registered
 session_transactionroles = sync.Map{}

 // session -> applicationId
 identified_sessions = sync.Map{}

 // applicationId -> ip -> port -> session
 client_sessions = sync.Map{}

 // applicationId -> resourceIds
 client_resources = sync.Map{}
)

这样，Transaction Manager 和 Resource Manager 分别通过 coordinator.OnRegTmMessage(rpcMessage, session) 和 coordinator.OnRegRmMessage(rpcMessage, session) 注册到 Transaction Coordinator 时，会在上述 client_sessions map 中缓存 applicationId、ip、port 与 session 的关系，在 client_resources map 中缓存 applicationId 与 resourceIds（一个应用可能存在多个 Resource Manager）的关系。

在需要时，我们就可以通过上述映射关系构造一个 RpcContext。这部分的实现和 java 版 seata 有很大的不同，感兴趣的可以深入了解一下。具体代码见 getty_session_manager.go。

至此，我们就分析完了 seata-golang 整个 RPC 通信模型的机制。

seata-golang 的未来

seata-golang 从今年 4 月份开始开发，到 8 月份基本实现和 java 版 seata 1.2 协议的互通，对 mysql 数据库实现了 AT 模式（自动协调分布式事务的提交回滚），实现了 TCC 模式，TC 端使用 mysql 存储数据，使 TC 变成一个无状态应用支持高可用部署。下图展示了 AT 模式的原理：

后续，还有许多工作可以做，比如：对注册中心的支持、对配置中心的支持、和 java 版 seata 1.4 的协议互通、其他数据库的支持、raft transaction coordinator 的实现等，希望对分布式事务问题感兴趣的开发者可以加入进来一起来打造一个完善的 golang 的分布式事务框架。如果你有任何疑问，欢迎钉钉扫码加入交流群【钉钉群号 33069364】：

另外，欢迎对 dubbogo 感兴趣的朋友到 dubbogo 社区钉钉群（钉钉群号 31363295）沟通 dubbogo 技术问题。

参考资料

seata 官方: https://seata.io
java 版 seata: https://github.com/seata/seata
seata-golang 项目地址: https://github.com/opentrx/seata-golang
seata-golang go 夜读 b 站分享: https://www.bilibili.com/video/BV1oz411e72T

作者简介

刘晓敏 (GitHubID dk-lockdown)，目前就职于 h3c 成都分公司，擅长使用 Java/Go 语言，在云原生和微服务相关技术方向均有涉猎，目前专攻分布式事务。于雨(（github @AlexStocks），dubbo-go 项目和社区负责人，一个有十多年服务端基础架构研发一线工作经验的程序员，陆续参与改进过 Muduo/Pika/Dubbo/Sentinel-go 等知名项目，目前在蚂蚁金服可信原生部从事容器编排和 service mesh 工作。

Blog: dubbo-go 1.5.0

Thu, 14 Jan 2021 00:00:00 +0000

引语

计算机技术浪潮每 10 年都有一次技术颠覆，相关知识体系最迟每 5 年都会革新一次，大概每两年贬值一半，在应用服务通信框架领域亦然。凡是有长期生命的通信框架，大概有 5 年的成长期和 5 年的稳定成熟期。每个时代都有其匹配的应用通信框架，在 20 年前的 2G 时代，强跨语言跨平台而弱性能的 gRPC 是不会被采用的。

每个通信框架，不同的人从不同角度看出不同的结论：初学者看重易用易学，性能测评者注重性能，应用架构师考虑其维护成本，老板则考虑则综合成本。一个应用通信框架的性能固然重要，其稳定性和进化能力更重要，得到有效维护的框架可在长时间单位内降低其综合成本：学习成本、维护成本、升级成本和更换成本。

什么是 Dubbo-go？第一，它是 Dubbo 的 Go 语言版本，全面兼容 Dubbo 是其第一要义。第二，它是一个 Go 语言应用通信框架，会充分利用作为云原生时代第一语言—Go 语言的优势，扩展 dubbo 的能力。

2008 年诞生的 Dubbo 已有十多年历史，依靠阿里和其社区，历久弥新。2016 年发布的 Dubbo-go 也已进入第五个年头，如今全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5 终于发布了。

回首过往，Dubbo-go 已经具备如下能力：

互联互通：打通了 gRPC 和 Spring Cloud 生态；
可观测性：基于 OpenTracing 和 Prometheus，使得其在 Logging、Tracing 和 Metrics 方面有了长足进步；
云原生：Dubbo-go 实现了基于 Kubernetes API Server 为注册中心的通信能力，做到了升级成本最低。

毋庸讳言，相较于现有成绩，发展阶段的 Dubbo-go 对未来有更多的期待之处：

易用性：Dubbo-go 的入门成本并不低，把很多感兴趣者挡在了门外。但好消息是，随着 Dubbo-go 在阿里内部的逐步推开，阿里中间件团队对其进行了进一步的封装，经生产环境检验后会开放给社区使用。
云原生：目前的 Dubbo-go 的基于 kubernetes 的方案，从技术分层角度来看， Kubernetes API Server 终究是系统的运维态组件，不应该暴露给应用层，否则会造成 APIServer 自身通信压力过大，且系统整体风险很高：应用层使用不当，或者框架自身的流量方面的 bug，可能会把 APIServer 打垮，后果就是造成整体后端服务能力的瘫痪！所以应用层需要感知的是 kubernetes 提供给应用层的 Operator，不断进化的 Dubbo-go 计划在 v1.6 版本中发布 Dubbo-go Operator。

雄关漫道真如铁，而今迈步从头越。Dubbo-go 社区【钉钉群 23331795】与 Dubbo-go 同在。

应用维度注册模型

经过一段时间的努力之后，我们终于完成了应用维度的服务注册与发现。和原本已有的接口维度的注册模型比起来，新的注册模型有两个突出特点：

和主流的注册模型保持一致。目前的主流做法都是按照应用为基本单位来进行注册的，如Spring Cloud。在支持应用维度注册之后，对于接下来的云原生支持，奠定了基础；
大幅度减轻对注册中心的压力。在该模型之下，从注册中心的视角看过去，集群规模只和实例数量成正比，而不是现有的和服务数量成正比；

当然，我们在设计的时候就考虑到了用户的迁移成本。要迁移到新的注册模型，只需要将现有使用的注册中心换成新的 ServiceDiscoveryRegistry 就可以。

ServiceDiscoveryRegistry 是支持多种实现的。目前来说，我们支持：

nacos;
etcd;
zookeeper;

我们提倡新上线的业务尽量使用 nacos 和 etcd 这种更可靠稳定的注册中心。

Metadata Report 元数据中心

v1.5 版本在支持应用维度注册模型时，有很重要的一个问题需要解决，即接口维度的元数据存储。服务维度的注册模型和应用维度的注册模型，本质的区别是往注册中心注册的数据维度的不一致。虽然我们在应用维度注册模型中，将接口维度的数据从注册中心中剔除了，但是在rpc的框架中，一个 consumer 要想真正找到想要调用的服务地址，就必须得到 provider 端开放的服务信息。这部分数据，在 v1.5 版本中，我们将它们存储到了元数据中心中。

元数据中心，是一个接口定义。泛指一块存储区域，可以对接口级别的元数据进行存储、读取，provider 端调用存储，consumer 端调用读取。元数据中心中的数据需要保持准确性、实时性。

目前元数据中心，有两个父类（Go 中没有继承，此处说的父子类，单纯指子类对父类的组合关系）实现，一个是 local 实现，一个是 remote 实现。local 实现是将 provider 的内存作为虚拟元数据中心，remote 实现是指依赖 ZooKeeper、etcd、nacos 等注册中心作为元数据中心。目前 remote 有 zookeeper、nacos、etcd 和 consul 的子类实现。即用户可以将元数据信息，通过以上的第三方注册中心进行数据存储和分发。

Invocation 接口支持 attribute 属性

invocation 结构中新增 attribute 属性支持，用于流程内部的属性存储。和 attachment 不同点在于，attachment会从 consumer 传递到 provider，但 attribute 属性不会。

k8s注册中心

在 v1.5 版本之前，k8s 注册中心的实现是通过直接使用 k8s client 中Pod对象的 List&&Watch 接口。在本次迭代中引入了 k8s informer。这样做的原因在于两点，首先一定的程度上来讲 dubbo-go 的 k8s 注册中心也是一个 k8s controller，使用 informer 的模式更加 k8s native。更重要的是社区计划后续向 CRD+Operator 的模式演进，informer 模式是对后续的演进的探索。除了这个铺垫之外，本次迭代还对跨 namespace 的服务发现做了支持。再有就是为了减少对 kube-apiserver List&&Watch 的压力，对 provider 和 consumer 的行为进行了区分，provider 不再进行 Watch 而仅对 kube-apiserver 进行写操作。

优化路由模型

在 1.5 版本之前，Router 模型中属性是包含：优先级与路由属性，Router Chain 只包含路由属性。从中能识别出其实 Router Chain 也是一种特殊 Router。1.5 版本之后，使 Router 更抽象，分离出其优先级属性，新增 Priority Router、Chain 继承 Router 使其变为特殊的 Router，使关系上看起来更加清晰。如下图：

回顾与展望

Dubbo-go 处于一个比较稳定成熟的状态。目前新版本正处于往云原生方向的尝试，应用服务维度注册是首先推出的功能，这是一个和之前模型完全不一样的新注册模型。该版本是我们朝云原生迈进新一步的关键版本。除此之外，包含在该版本也有一些之前提到的优化。

下一个版本 v1.5.1，虽然仍是以兼容 Dubbo 2.7.x 为主要任务，但在分布式能力的增强上，也是我们关注的重点。

在分布式事务方面，有一个重要的基于 Seata 扩展实现。通过增加过滤器，在服务端接收 xid 并结合 seata-golang¹ 达到支持分布式事务的目的。从而使 Dubbo-go 在分布式场景下，让用户有更多的选择，能适应更多的个性化场景。

与此同时，在传输链路安全性上，TLS 安全传输链路是该版本重要功能之一。通过提供统一入口，未来能引入更多的与传输链路安全性相关的功能，适应用户不一样的使用场景。

注册中心模型上，支持多注册中心集群负载均衡。业务部署假设是双注册中心（图 1 ），从原来双注册中心中所有 Provider 一起选址。优化成选址时的多了一层注册中心集群间的负载均衡（图 2 ）。

（图 1 ）

（图 2 ）

以前的 dubbo-go RPC 层直接复用了 getty 框架的 RPC[²(https://github.com/AlexStocks/getty/tree/feature/rpc)]，未能实现协议和应用通信地址的隔离。阿里中间件展图同学重构了 dubbo-go RPC 层，实现了连接复用：可以实现 consumer 与 provider 端的同一个 TCP 连接上进行多协议通信。相关 PR 业已合并，会在 dubbo-go v1.5.1 中发布。

目前下一个版本正在紧锣密鼓的开发中，具体规划及任务清单³ ，都已经在 Github 上体现。

Blog: dubbo-go 1.5.1

Thu, 14 Jan 2021 00:00:00 +0000

近期我们发布了 dubbo-go v1.5.1，虽然是 v1.5 的一个子版本，但相比于 v1.5.0，社区还是投入了很大人力添加了如下重大改进。

1 应用维度注册模型

在新模型 release 后，我们发现 Provider 每个 URL 发布元数据都会注册 ServiceInstance，影响性能需要优化。

我们的优化方案是：

去除 ServiceDiscoveryRegistry 中注册 ServiceInstance 的代码，在 config_loader 中的loadProviderConfig 方法的最后注册 ServiceInstance

具体步骤：

获取所有注册的 Registry，过滤出 ServiceDiscoveryRegistry，拿取所有 ServiceDiscovery。
创建 ServiceInstance。
每个 ServiceDiscovery 注册 ServiceInstance。

保证 Provider 在注册成功之后，才暴露元数据信息。

2 支持基于 Seata 的事务

基于 Seata 扩展实现。通过增加过滤器，在服务端接收 xid 并结合 seata-golang 达到支持分布式事务的目的。从而使 Dubbo-go 在分布式场景下，让用户有更多的选择，能适应更多的个性化场景。

我们在 dubbo-samples 中给出了事务测试用例。

3 多注册中心集群负载均衡

对于多注册中心订阅的场景，选址时的多了一层注册中心集群间的负载均衡：

在 Cluster Invoker 这一级，我们支持的选址策略有：

指定优先级
同 zone 优先
权重轮询

4 传输链路安全性

该版本在传输链路的安全性上做了尝试，对于内置的 Dubbo getty Server 提供了基于 TLS 的安全链路传输机制。

为尽可能保证应用启动的灵活性，TLS Cert 的指定通过配置文件方式，具体请参见 Dubbo-go 配置读取规则与 TLS 示例：

5 路由功能增强

本次路由功能重点支持了动态标签路由和应用/服务级条件路由。

5.1 动态标签路由

标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。

标签主要是指对 Provider 端应用实例的分组，目前有两种方式可以完成实例分组，分别是动态规则打标和静态规则打标，其中动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。

5.1.1 动态规则打标

可随时在服务治理控制台下发标签归组规则

# governance-tagrouter-provider应用增加了两个标签分组tag1和tag2
# tag1包含一个实例 127.0.0.1:20880
# tag2包含一个实例 127.0.0.1:20881
---
 force: false
 runtime: true
 enabled: true
 key: governance-tagrouter-provider
 tags:
 - name: tag1
 addresses: ["127.0.0.1:20880"]
 - name: tag2
 addresses: ["127.0.0.1:20881"]
 ...

5.1.2 静态规则打标

可以在 server 配置文件的 tag 字段里设置

services:
 "UserProvider":
 registry: "hangzhouzk"
 protocol : "dubbo"
 interface : "com.ikurento.user.UserProvider"
 loadbalance: "random"
 warmup: "100"
 tag: "beijing"
 cluster: "failover"
 methods:
 - name: "GetUser"
 retries: 1
 loadbalance: "random"

consumer 添加 tag 至 attachment 即可

ctx := context.Background()
attachment := make(map[string]string)
attachment["dubbo.tag"] = "beijing"
ctx = context.WithValue(ctx, constant.AttachmentKey, attachment)
err := userProvider.GetUser(ctx, []interface{}{"A001"}, user)

请求标签的作用域为每一次 invocation，使用 attachment 来传递请求标签，注意保存在 attachment 中的值将会在一次完整的远程调用中持续传递，得益于这样的特性，我们只需要在起始调用时，通过一行代码的设置，达到标签的持续传递。

5.1.3 规则详解

格式

Key明确规则体作用到哪个应用。必填。
enabled=true 当前路由规则是否生效，可不填，缺省生效。
force=false 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为 false。
runtime=false 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 true，需要注意设置会影响调用的性能，可不填，缺省为 false。
priority=1 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
tags 定义具体的标签分组内容，可定义任意n（n>=1）个标签并为每个标签指定实例列表。必填
- name，标签名称
addresses，当前标签包含的实例列表

降级约定

dubbo.tag=tag1 时优先选择标记了 tag=tag1 的 provider。若集群中不存在与请求标记对应的服务，默认将降级请求 tag 为空的 provider；如果要改变这种默认行为，即找不到匹配 tag1 的 provider 返回异常，需设置dubbo.force.tag=true。
dubbo.tag 未设置时，只会匹配 tag 为空的 provider。即使集群中存在可用的服务，若 tag 不匹配也就无法调用，这与约定 1 不同，携带标签的请求可以降级访问到无标签的服务，但不携带标签/携带其他种类标签的请求永远无法访问到其他标签的服务。

5.2 应用/服务级条件路由

您可以在路由规则配置中配置多个条件路由及其粒度

Sample:

# dubbo router yaml configure file
routerRules:
 - scope: application
 key: BDTService
 priority: 1
 enable: false
 force: true
 conditions : ["host = 192.168.199.208 => host = 192.168.199.208 "]
 - scope: service
 key: com.ikurento.user.UserProvider
 priority: 1
 force: true
 conditions : ["host = 192.168.199.208 => host = 192.168.199.208 "]

5.2.1 规则详解

各字段含义

scope表示路由规则的作用粒度，scope的取值会决定key的取值。必填。
- service 服务粒度
application 应用粒度
Key明确规则体作用在哪个服务或应用。必填。
- scope=service时，key取值为[{group}/]{service}[:{version}]的组合
scope=application时，key取值为application名称
enabled=true 当前路由规则是否生效，可不填，缺省生效。
force=false 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为 false。
runtime=false 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 true，需要注意设置会影响调用的性能，可不填，缺省为 false。
priority=1 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
conditions 定义具体的路由规则内容。必填。

6 回顾与展望

下一个版本 v1.5.2，本次的关注重点以通信模型改进为主，除此之外，与 2.7.x 的兼容性、易用性及质量保证也是本次关注的信息。

在服务发现，会支持更加多的方式，如：文件、Consul。从而使 Dubbo-go 在服务发现场景下，让用户有更多的选择，能适应更多的个性化场景。

另外 易用性及质量保证，主要关注的是 samples 与自动化构建部分。可降低用户上手 Dubbo-go 的难度，提高代码质量。

目前下一个版本正在紧锣密鼓的开发中，具体规划及任务清单¹ ，都已经在 Github 上体现。

https://github.com/apache/dubbo-go/projects/10 ↩︎

Blog: dubbo-go 可信调用实现

Thu, 14 Jan 2021 00:00:00 +0000

Apache Dubbo/Dubbo-Go 作为阿里巴巴开源的一款服务治理框架，因其适应 Java/Go 开发者面向接口的编程习惯、完全透明的调用方式、优越的性能以及强大的扩展性等优点，在国内使用非常广泛。除此之外，Dubbo 开源版本原生集成了很多开箱即用的服务治理功能，包括链路追踪，路由、负载均衡、服务注册发现、监控、认证等。

本文将讲解如何在 Dubbo/Dubbo-Go 中实现灵活，安全和高效的身份验证和授权方案。

可信的目的

为什么需要鉴权认证？实际生产中类似支付之类的安全性敏感的业务会有限制匿名系统调用的需求，其他业务在接入该类敏感业务之前，需要通过审批方可正常调用，这就需要对这类敏感服务进行权限管控。尽管 Dubbo 开源版本中支持 Token 方式的鉴权实现，但是该实现方式总体来说安全性并不高，并且无法满足我们需要动态下发以及变更的灵活性需求。

针对于此，我们内部着重从巩固安全性和拓展灵活性层面重新设计了一套 Dubbo/Dubbo-Go 的服务间调用的鉴权认证功能。本文我们将主要从实现层面讲解其大致实现思路。

可信方案

抽象来看鉴权认证主要围绕以下两个问题，

身份认证：指验证应用的身份，每个应用在其生命周期内只有唯一身份，无法变更和伪造。
权限鉴定：根据身份信息鉴定权限是否满足调用。权限粒度可以进行控制。

我们通过 Access Key ID/Secret Access Key (后文简称为 AK/SK) 信息标识应用和应用之间的身份关系。例如上游应用A 依赖下游服务B 和 C，则 A 对 B 和 C 分别有一套 AK/SK。其相互独立没有任何关系。就算 A服务的 AK/SK 信息泄漏，也无法通过该 AK/SK 信息调用其他的服务。

在权限鉴定方面也借鉴了公有云开放 API 常用的 AK/SK 签名机制。在请求过程中使用 SK 签名生成 SigningKey，并通过 Dubbo 的 attachment 机制将额外的元数据信息以及 SigningKey 传输到服务端，交由服务端计算和验签，验签通过方能正常处理和响应。

签名过程主要通过如下三个方式进行加强 SigningKey 的可靠性和安全性。

验证请求者的身份

签名会通过对应应用的SK作为加密密钥对请求元数据(以及参数)进行加密，保证签名的唯一性和不可伪造性。
支持对参数进行计算签名，防止非法篡改

若请求参数在传输过程中遭到非法篡改，则收到请求后服务端验签匹配将失败，身份校验无法通过，从而防止请求参数被篡改。考虑到签名以及验签过程中加入请求参数的计算可能会影响性能，所以这个过程是可选的。
防止重放攻击

每一次请求生成的SigningKey都具有指定的有效时间。如请求被截获，该请求无法在有效时间外进行调用。一定程度避免了重放攻击。

同时为了去掉明文配置，防止AK/SK信息泄漏，我们通过鉴权系统分发和管理所有AK/SK信息。并且通过对接内部审批流程，达到流程化和规范化。需要鉴权的应用会通过启动获取的方式拉当前应用分发出去或者是已被授权的AK/SK信息。这种方式也带来了另一种好处，新增、吊销以及更新权限信息也无需重启应用。

可信流程

结合上面的这些需求和方案，整个接入和鉴权流程图如下所示：

整体流程如下：

使用该功能的应用需要提前申请对应的证书，并向提供服务的应用提交申请访问工单，由双方负责人审批通过后，请求鉴权服务中心自动生成键值对。
除此之外，开启鉴权认证的服务在应用启动之后，会运行一个后台线程，长轮询远鉴权服务中心，查询是否有新增权限变动信息，如果有则进行全量/增量的拉取。
上游应用在请求需要鉴权的服务时，会通过SK作为签名算法的 key，对本次请求的元数据信息甚至是参数信息进行计算得到签名，通过 Dubbo协议 Attachment字段传送到对端，除此之外还有请求时间戳、AK信息等信息。
下游应用在处理鉴权服务时会对请求验签，验签通过则继续处理请求，否则直接返回异常。

其中需要说明的是第三步，使用鉴权服务的应用和鉴权服务中心的交互需通过 HTTPS 的双向认证，并在 TLS 信道上进行数据交互，保证 AK/SK 信息传输的安全性。

该方案目前已经有 Java/Go 实现，均已合并到 dubbo/dubbo-go。除了默认的 Hmac 签名算法实现之外，我们将签名和认证方法进行抽象，以Dubbo Go中的实现为例。

// Authenticator
type Authenticator interface {

 // Sign
 // give a sign to request
 Sign(protocol.Invocation, *common.URL) error

 // Authenticate
 // verify the signature of the request is valid or not
 Authenticate(protocol.Invocation, *common.URL) error
}

使用者可通过 SPI 机制定制签名和认证方式，以及适配公司内部基础设施的密钥服务下发 AK/SK。

示例

以 Helloworld 示例中的代码接入当前社区版本中的默认鉴权认证功能实现为例：

在无需改变代码的情况下，只需要在配置上增加额外的相关鉴权配置即可，dubbo-go 服务端配置示例如下：

services:
 "UserProvider":
 # 可以指定多个registry，使用逗号隔开;不指定默认向所有注册中心注册
 registry: "hangzhouzk"
 protocol : "dubbo"
 # 相当于dubbo.xml中的interface
 interface : "com.ikurento.user.UserProvider"
 loadbalance: "random"
 # 本服务开启auth
 auth: "true"
 # 启用auth filter，对请求进行验签
 filter: "auth"
 # 默认实现通过配置文件配置AK、SK
 params:
 .accessKeyId: "SYD8-23DF"
 .secretAccessKey: "BSDY-FDF1"
 warmup: "100"
 cluster: "failover"
 methods:
 - name: "GetUser"
 retries: 1
 loadbalance: "random"

dubbo-go 客户端配置示例如下：

references:
 "UserProvider":
 # 可以指定多个registry，使用逗号隔开;不指定默认向所有注册中心注册
 registry: "hangzhouzk"
 protocol: "dubbo"
 interface: "com.ikurento.user.UserProvider"
 cluster: "failover"
 # 本服务开启sign filter，需要签名
 filter: "sign"
 # 默认实现通过配置文件配置AK、SK
 params:
 .accessKeyId: "SYD8-23DF"
 .secretAccessKey: "BSDY-FDF1"
 methods:
 - name: "GetUser"
 retries: 3

可以看到，dubbo-go 接入鉴权认证的功能也十分简单。需要补充说明的是，配置文件文件中 ak/sk 都加了特殊前缀 “."，是为了说明该字段是敏感信息，不能在发起网络请求时传输出去，相关代码可参阅 dubbo-go-pr-509。

总结

Apache Dubbo 作为一款老而弥新的服务治理框架，无论是其自身还是其生态都还在飞速进化中。本文描述的最新实现的可信服务调用，是为了避免敏感接口被匿名用户调用而在 SDK 层面提供的额外保障，在 RPC 层面保障安全性。

Dubbo-Go 作为 Dubbo 生态中发展最快的成员，目前基本上保持与 Dubbo 齐头并进的态势。Dubbo-Go 社区钉钉群号为 23331795，欢迎你的加入。

作者信息：郑泽超，Apache Dubbo/Dubbo-Go committer，GithubID: CodingSinger，目前就职于上海爱奇艺科技有限公司，Java/Golang 开发工程师。