Apache Dubbo – 源码分析

Blog: Dubbo 3.0.8 源码解析

Mon, 01 Jan 0001 00:00:00 +0000

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: 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 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: 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 中的 URL 统一模型

Thu, 17 Oct 2019 00:00:00 +0000

定义

在不谈及 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：参数键值对

public URL(String protocol, String username, String password, String host, int port, String path, Map<String, String> parameters) {
 if ((username == null || username.length() == 0)
 && password != null && password.length() > 0) {
 throw new IllegalArgumentException("Invalid url, password without username!");
 }
 this.protocol = protocol;
 this.username = username;
 this.password = password;
 this.host = host;
 this.port = (port < 0 ? 0 : port);
 this.path = path;
 // trim the beginning "/"
 while(path != null && path.startsWith("/")) {
 path = path.substring(1);
 }
 if (parameters == null) {
 parameters = new HashMap<String, String>();
 } else {
 parameters = new HashMap<String, String>(parameters);
 }
 this.parameters = Collections.unmodifiableMap(parameters);
}

可以看出，dubbo 认为 protocol，username，passwored，host，port，path 是主要的 URL 参数，其他键值对存放在 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 来统一描述了元数据，配置信息，贯穿在整个框架之中。

URL 相关的生命周期

RPC调用

从地址发现的视角，URL 代表了一条可用的 provider 实例地址，除了地址信息之外还有相关的配置信息，这些配置信息是层次化的，有 provider 侧指定的配置值、consumer 侧指定的配置值、接口级别的配置值、方法级别的配置值等。这些 URL 配置值将直接影响消费端的 RPC 调用行为。

以 timeout 为例，下图显示了配置的查找顺序，其它 retries, loadbalance, actives 等类似：

方法级优先，接口级次之，全局配置再次之。
如果级别一样，则消费方优先，提供方次之。

其中，服务提供方配置，通过 URL 经由注册中心传递给消费方。

（建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置）。

理论上 ReferenceConfig 中除了interface这一项，其他所有配置项都可以缺省不配置，框架会自动使用ConsumerConfig，ServiceConfig, ProviderConfig等提供的缺省配置。

解析服务

基于 dubbo.jar 内的 META-INF/spring.handlers 配置，Spring 在遇到 dubbo 名称空间时，会回调 DubboNamespaceHandler。

所有 dubbo 的标签，都统一用 DubboBeanDefinitionParser 进行解析，基于一对一属性映射，将 XML 标签解析为 Bean 对象。

在 ServiceConfig.export() 或 ReferenceConfig.get() 初始化时，将 Bean 对象转换 URL 格式，所有 Bean 属性转成 URL 的参数。

然后将 URL 传给协议扩展点，基于扩展点自适应机制，根据 URL 的协议头，进行不同协议的服务暴露或引用。

暴露服务

1. 只暴露服务端口：

在没有注册中心，直接暴露提供者的情况下，ServiceConfig 解析出的 URL 的格式为：dubbo://service-host/com.foo.FooService?version=1.0.0。

基于扩展点自适应机制，通过 URL 的 dubbo:// 协议头识别，直接调用 DubboProtocol的 export() 方法，打开服务端口。

2. 向注册中心暴露服务：

在有注册中心，需要注册提供者地址的情况下，ServiceConfig 解析出的 URL 的格式为: registry://registry-host/org.apache.dubbo.registry.RegistryService?export=URL.encode("dubbo://service-host/com.foo.FooService?version=1.0.0")，

基于扩展点自适应机制，通过 URL 的 registry:// 协议头识别，就会调用 RegistryProtocol 的 export() 方法，将 export 参数中的提供者 URL，先注册到注册中心。

再重新传给 Protocol 扩展点进行暴露： dubbo://service-host/com.foo.FooService?version=1.0.0，然后基于扩展点自适应机制，通过提供者 URL 的 dubbo:// 协议头识别，就会调用 DubboProtocol 的 export() 方法，打开服务端口。

引用服务

1. 直连引用服务：

在没有注册中心，直连提供者的情况下，ReferenceConfig 解析出的 URL 的格式为：dubbo://service-host/com.foo.FooService?version=1.0.0。

基于扩展点自适应机制，通过 URL 的 dubbo:// 协议头识别，直接调用 DubboProtocol 的 refer() 方法，返回提供者引用。

2. 从注册中心发现引用服务：

在有注册中心，通过注册中心发现提供者地址的情况下，ReferenceConfig 解析出的 URL 的格式为：registry://registry-host/org.apache.dubbo.registry.RegistryService?refer=URL.encode("consumer://consumer-host/com.foo.FooService?version=1.0.0")。

基于扩展点自适应机制，通过 URL 的 registry:// 协议头识别，就会调用 RegistryProtocol 的 refer() 方法，基于 refer 参数中的条件，查询提供者 URL，如： dubbo://service-host/com.foo.FooService?version=1.0.0。

基于扩展点自适应机制，通过提供者 URL 的 dubbo:// 协议头识别，就会调用 DubboProtocol 的 refer() 方法，得到提供者引用。

然后 RegistryProtocol 将多个提供者引用，通过 Cluster 扩展点，伪装成单个提供者引用返回。

URL 统一模型的意义

对于 dubbo 中的 URL，有人理解为配置总线，有人理解为统一配置模型，说法虽然不同，但都是在表达一个意思，这样的 URL 在 dubbo 中被当做是公共契约，所有扩展点参数都包含 URL 参数，URL 作为上下文信息贯穿整个扩展点设计体系。

在没有 URL 之前，只能以字符串传递参数，不停的解析和拼装，导致相同类型的接口，参数时而 Map, 时而 Parameters 类包装：

export(String url)
createExporter(String host, int port, Parameters params)

使用 URL 一致性模型：

export(URL url)
createExporter(URL url)

在最新的 dubbo 代码中，我们可以看到大量使用 URL 来进行上下文之间信息的传递，这样的好处是显而易见的：

使得代码编写者和阅读者能够将一系列的参数联系起来，进而形成规范，使得代码易写，易读。
可扩展性强，URL 相当于参数的集合(相当于一个 Map)，他所表达的含义比单个参数更丰富，当我们在扩展代码时，可以将新的参数追加到 URL 之中，而不需要改变入参，返参的结构。
统一模型，它位于 org.apache.dubbo.common 包中，各个扩展模块都可以使用它作为参数的表达形式，简化了概念，降低了代码的理解成本。

如果你能够理解 final 契约和 restful 契约，那我相信你会很好地理解 URL 契约。契约的好处我还是啰嗦一句：大家都这么做，就形成了默契，沟通是一件很麻烦的事，统一 URL 模型可以省去很多沟通成本，这边是 URL 统一模型存在的意义。

Apache Dubbo – 源码分析

Blog: Dubbo 3.0.8 源码解析

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

一、流控反压现状

1、HTTP/1 流控

2、HTTP/2 流控

二、Triple流控反压

1、连接初始化

2、Inbound流控

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

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

3) 更新流控窗口

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

3、Outbound流控

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

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

3) 反馈客户端流控异常

4、总结

三、未来展望

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

背景

Dubbo异常处理简介

Triple 通信原理

实现版本

总结

Blog: 浅析 Dubbo 3.0 中接口级地址推送性能的优化

URL 简介

定义

Dubbo 中的 URL

Dubbo 2.7

URL 结构

地址推送模型

Dubbo 3.0

URL 结构

地址推送模型的优化

URL 结构上的优化

多级缓存

延迟通知

字符串重用

优化结果

Blog: Dubbo3 应用级服务发现

1 服务发现（Service Discovery） 概述

2 Dubbo 地址发现机制解析

3 Dubbo 应用级服务发现的意义

3.1 对齐主流微服务模型

3.2 更大规模的微服务集群 - 解决性能瓶颈

4 应用级服务发现工作原理

4.1 设计原则

4.2 基本原理详解

4.2.1 注册中心数据以“应用 - 实例列表”格式组织，不再包含 RPC 服务信息

4.2.2 Client – Server 自行协商 RPC 方法信息

4.3 服务自省中的关键机制

4.3.1 元数据同步机制

4.3.2 RPC 服务 < - > 应用映射关系

5 总结与展望

Blog: Dubbo 中的 URL 统一模型

定义

Dubbo 中的 URL

URL 相关的生命周期

RPC调用

解析服务

暴露服务

引用服务

URL 统一模型的意义

1 服务发现（Service Discovery）概述