源码架构 on Apache Dubbo

单端口多协议实现原理解析

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

通过对protocol进行配置，dubbo3可以支持端口的协议复用。比如使用Triple协议启动端口复用后，可以在相同的端口上为服务增加 Dubbo协议支持，以及Qos协议支持。这些协议的识别都是由一个统一的端口复用服务器进行处理的，可以用于服务的协议迁移，并且可以节约端口以及相关的资源，减少运维的复杂性。

在服务的创建阶段，通过从Config层获取到服务导出的协议配置从而创建不同的Protocol对象进行导出。在导出的过程中，如果不是第一次创建端口复用的Server，那么Exchanger会将Protcol层传递的数据保存到Server，用于后续处理该协议类型的消息。
当客户端的消息传递过来后，首先会通过Server传递给ProtocolDetector，如果完成了识别，那么就会标记该客户端为对应的协议。并通过WireProtocol配置对应的处理逻辑，最后交给ChannelOperator完成底层的IO框架和对应的Dubbo框架的处理逻辑的绑定。
以上的协议识别完成之后，Channel已经确定了如何处理远程的客户端消息，通过对应的ServerPipeline进行处理即可（在处理的过程中也会根据配置信息决定消息的处理线程）。

使用场景

最常用的是用于服务发现。这允许应用程序通过网络发现服务，然后使用同一端口与它们通信，有助于降低网络通信的复杂性，并使其更易于管理。
可以用于负载平衡。这允许应用程序在多个远程服务或服务集群之间平衡负载，有助于提高服务的可扩展性、可靠性和可用性。
可以用于服务监控。这允许应用程序监视远程服务的运行状况，并在服务出现故障或变得不可用时发出警报，有助于确保服务的可用性并减少停机时间。

参考用例 https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-port-unification

使用方式

在同一主机上部署多个服务或需要通过负载均衡器访问多个服务。

关于Dubbo支持的配置方式配置说明

服务多协议导出

ext-protocol参数支持配置多个不同的协议，协议之间通过",“进行分隔。

xml 配置

<dubbo:protocol name="dubbo" port="-1" ext-protocol="tri,"/>

<bean id="greetingService" class="org.apache.dubbo.demo.provider.GreetingServiceImpl"/>

<dubbo:service delay="5000" version="1.0.0" group="greeting" timeout="5000" interface="org.apache.dubbo.demo.GreetingService" ref="greetingService" protocol="dubbo"/>

API 配置

ProtocolConfig config = new ProtocolConfig(CommonConstants.TRIPLE, -1);

config.setExtProtocol(CommonConstants.DUBBO+",");

yaml 配置

dubbo:
 application:
 name: dubbo-springboot-demo-provider
 protocol:
 name: tri
 port: -1
 ext-protocol: dubbo,

properties 配置

dubbo.protocol.name=tri
dubbo.protocol.ext-protocol=dubbo,
dubbo.protocol.port=20880

Qos接入

Qos模块导入

<dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo-qos</artifactId>
</dependency>

完成Qos模块的导入之后，相关的配置项可参考Qos操作手册进行配置。

代码架构

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

整体设计

图例说明：

图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。
图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调用链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。

各层说明

Config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
Proxy 服务代理层：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory
Registry 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService
Cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance
Monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService
Protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter
Exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
Transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec
Serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

关系说明

在 RPC 中，Protocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点。
图中的 Consumer 和 Provider 是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不用 Client 和 Server 的原因是 Dubbo 在很多场景下都使用 Provider, Consumer, Registry, Monitor 划分逻辑拓扑节点，保持统一概念。
而 Cluster 是外围概念，所以 Cluster 的目的是将多个 Invoker 伪装成一个 Invoker，这样其它人只要关注 Protocol 层 Invoker 即可，加上 Cluster 或者去掉 Cluster 对其它层都不会造成影响，因为只有一个提供者时，是不需要 Cluster 的。
Proxy 层封装了所有接口的透明化代理，而在其它层都以 Invoker 为中心，只有到了暴露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker，也就是去掉 Proxy 层 RPC 是可以 Run 的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
而 Remoting 实现是 Dubbo 协议的实现，如果你选择 RMI 协议，整个 Remoting 都不会用上，Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层，Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，而 Exchange 层是在传输层之上封装了 Request-Response 语义。
Registry 和 Monitor 实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。

模块分包

服务调用扩展点

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

如上图所示，从服务调用的角度来看，Dubbo 在链路中提供了丰富的扩展点，覆盖了负载均衡方式、选址前后的拦截器、服务端处理拦截器等。简单来说 Dubbo 发起远程调用的时候，主要工作流程可以分为消费端和服务端两个部分。

消费端的工作流程如下：

通过 Stub 接收来自用户的请求，并且封装在 Invocation 对象中
将 Invocation 对象传递给 ClusterFilter（扩展点）做选址前的请求预处理，如请求参数的转换、请求日志记录、限流等操作都是在此阶段进行的
将 Invocation 对象传递给 Cluster（扩展点）进行集群调用逻辑的决策，如快速失败模式、安全失败模式等决策都是在此阶段进行的
- Cluster 调用 Directory 获取所有可用的服务端地址信息
- Directory 调用 StateRouter（扩展点，推荐使用）和 Router（扩展点）对服务端的地址信息进行路由筛选，此阶段主要是从全量的地址信息中筛选出本次调用允许调用到的目标，如基于打标的流量路由就是在此阶段进行的
- Cluster 获得从 Directory 提供的可用服务端信息后，会调用 LoadBalance （扩展点）从多个地址中选择出一个本次调用的目标，如随机调用、轮询调用、一致性哈希等策略都是在此阶段进行的
- Cluster 获得目标的 Invoker 以后将 Invocation 传递给对应的 Invoker，并等待返回结果，如果出现报错则执行对应的决策（如快速失败、安全失败等）
经过上面的处理，得到了带有目标地址信息的 Invoker，会再调用 Filter（扩展点）进行选址后的请求处理（由于在消费端侧创建的 Filter 数量级和服务端地址量级一致，如无特殊需要建议使用 ClusterFilter 进行扩展拦截，以提高性能）
最后 Invocation 会被通过网络发送给服务端

服务端的工作流程如下：

服务端通信层收到请求以后，会将请求传递给协议层构建出 Invocation
将 Invocation 对象传递给 Filter （扩展点）做服务端请求的预处理，如服务端鉴权、日志记录、限流等操作都是在此阶段进行的
将 Invocation 对象传递给动态代理做真实的服务端调用

Filter（拦截器）

拦截器可以实现服务提供方和服务消费方调用过程拦截，Dubbo 本身的大多功能均基于此扩展点实现，每次远程方法执行，该拦截都会被执行，请注意对性能的影响。其中在消费端侧，ClusterFilter 用于选址前的拦截和 Filter 用于选址后的拦截。如无特殊需要使用 ClusterFilter 进行扩展拦截，以提高性能。

扩展点开发指南

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

1. Dubbo SPI 扩展简介

Dubbo 中的扩展机制与 JDK 标准的 SPI 扩展点原理类似。Dubbo 对其做了一定的改造与加强：

JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。
如果扩展点加载失败，JDK SPI 没给出详细信息，不方便定位问题，Dubbo SPI 在失败时记录真正的失败原因，并打印出来
增加 IOC、AOP 能力
增加排序能力
增加条件激活能力
提供了一系列更灵活的 API，如获取所有 SPI 扩展实现、根据名称查询某个扩展实现、根据类型查询扩展实现、查询匹配条件的扩展实现等。

1.1 SPI定义

Dubbo 中的 SPI 插件是标准的 Java Interface 定义，并且必须包含 @org.apache.dubbo.common.extension.SPI 注解：

@SPI(value = "dubbo", scope = ExtensionScope.FRAMEWORK)
public interface Protocol {
	// ...
}

@SPI 注解的定义如下：

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE})
public @interface SPI {
 /**
 * default extension name
 */
 String value() default "";

 /**
 * scope of SPI, default value is application scope.
 */
 ExtensionScope scope() default ExtensionScope.APPLICATION;
}

1.2 SPI加载流程

Dubbo 加载扩展的整个流程如下：