文章目录
一 基础介绍
1 互联网系统架构的演变
单一应用架构
当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是关键。
垂直应用架构
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的Web框架(MVC)是关键。
分布式服务架构
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式服务框架(RPC)是关键。
流动计算架构
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键。
2 rpc介绍
什么是rpc
远程过程调用协议RPC(Remote Procedure Call Protocol)
RPC可以指远程过程调用,
也就是说两台服务器A,B,一个应用部署在A服务器上,想要调用B服务器上应用提供的函数/方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据。
为什么要用RPC呢?
就是无法在一个进程内,甚至一个计算机内通过本地调用的方式完成的需求,比如不同的系统间的通讯,甚至不同的组织间的通讯,由于计算能力需要横向扩展,需要在多台机器组成的集群上部署应用。
RPC就是要像调用本地的函数一样去调远程函数
3 dubbo介绍
dubbo是什么
Dubbo是一个分布式服务框架,提供高性能和透明(调用远程方法犹如调用本地方法一样)的远程RPC调用方案,以及SOA服务治理方案。
(告别Web Service模式中的WSdl,以服务者与消费者的方式在dubbo上注册)
其核心部分包含:
- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式。
- 集群容错: 提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。
- 自动发现: 基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。
4 dubbo设计原理
1 dubbo的框架
0、服务容器在启动时启动、加载服务提供者;
1、启动时,服务提供者向注册中心注册服务;
2、启动时,服务消费者向注册中心订阅服务;
3、注册中心给消费者返回服务提供者的地址列表,的提供者服务有什么变动,将用长连接推送变动数据给订阅者;
4、服务消费者发起对提供者服务的调用,提供者返回调用结果给消费者;
5、服务消费者和提供者在内存中累计调用次数和调用时间,每分钟发送一次统计数据给监控中心Monitor,供监控中心统计查询。
二 dubbo简单入门
1 搭建zookeeper
使用docker搭建
docker run -d \
-p 2181:2181 \
-v /home/qw/docker/zookeeper/data/:/data/ \
--name=zookeeper \
--privileged zookeeper
作用:
zookeeper用来注册服务和进行负载均衡,哪一个服务由哪一个机器来提供必需让调用者知道,简单来说就是ip地址和服务名称的对应关系
Dubbo的将注册中心进行抽象,是得它可以外接不同的存储媒介给注册中心提供服务,有ZooKeeper,Memcached,Redis等。
引入了ZooKeeper作为存储媒介,也就把ZooKeeper的特性引进来。首先是负载均衡,单注册中心的承载能力是有限的,在流量达到一定程度的时候就需要分流,负载均衡就是为了分流而存在的,一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡;资源同步,单单有负载均衡还不够,节点之间的数据和资源需要同步,ZooKeeper集群就天然具备有这样的功能;命名服务,将树状结构用于维护全局的服务地址列表,服务提供者在启动的时候,向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址,这个操作就完成了服务的发布。其他特性还有Mast选举,分布式锁等。
2 搭建dubbo-admin
使用docker搭建
docker run -d \
--name dubbo-admin \
-p 8888:8080 \
-e DUBBO_REGISTRY="zookeeper:\/\/ip:port" \
-e DUBBO_ROOT_PASSWORD=root \
-e DUBBO_GUEST_PASSWORD=root \
--restart=always \
riveryang/dubbo-admin
http://localhost:8888
3 演示案例
4 监控中心
作用
-
Dubbo-Monitor主要用来统计服务的调用次数和调用时间,服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心,监控中心则使用数据绘制图表来显示。
-
Dubbo-Monitor挂掉不会影响到Consumer和Provider之间的调用,所以用于生产环境不会有风险。
-
配置好了之后可以结合admin管理后台使用,可以清晰的看到服务的访问记录、成功次数、失败次数等……
docker
docker run -d \
--name dubbo-monitor \
-e ZOOKEEPER_ADDRESS="172.30.83.141:2181" \
-p 7070:7070 \
-p 18081:18081 \
--restart=always \
jeromefromcn/dubbo-monitor \
bash -c "/dubbo-monitor-simple/bin/start.sh && tail -f /dev/null"
http://localhost:18081
统计
点击Statistics,成功的次数,失败的次数,平均花费的时间,最大花费的时间,并发的次数。
图表
三 综合实例讲解
1 新版维系外呼模块关系图
四 深入讲解dubbo服务的注册与发现
1 zookeeper 注册中心
流程说明:
- 服务提供者启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址
- 服务消费者启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向/dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址
- 监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。
支持以下功能:
- 当提供者出现断电等异常停机时,注册中心能自动删除提供者信息
- 当注册中心重启时,能自动恢复注册数据,以及订阅请求
- 当会话过期时,能自动恢复注册数据,以及订阅请求
- 当设置 <dubbo:registry check=“false” /> 时,记录失败注册和订阅请求,后台定时重试
- 可通过 <dubbo:registry username=“admin” password=“1234” /> 设置 zookeeper登录信息
- 可通过 <dubbo:registry group=“dubbo” /> 设置 zookeeper 的根节点,不设置将使用无根树
- 支持 * 号通配符 <dubbo:reference group="" version=""/>,可订阅服务的所有分组和所有版本的提供者
2 服务暴露的过程
dubbo采用的nio异步的通信,通信协议默认为 netty,当然也可以选择 mina,grizzy。在服务端(provider)在启动时主要是开启netty监听,在zookeeper上注册服务节点,处理消费者请求,返回处理后的消息给消费者,消费者使用服务时主要是订阅服务的节点,监听zookeeper节点目录,服务端的变化时zookeeper会推送给消费者,消费者重新缓存服务地址等。服务者、消费者、zookeeper三者之间都是长连接。
下面看dubbo源码来看服务暴露的过程,服务暴露的入口为:com.alibaba.dubbo.config.ServiceConfig#export 方法,代码如下:
//是否延时暴露
if (delay != null && delay > 0) {
Thread thread = new Thread(new Runnable() {
public void run() {
try {
Thread.sleep(delay);
} catch (Throwable e) {
}
doExport();
}
});
thread.setDaemon(true);
thread.setName("DelayExportServiceThread");
thread.start();
} else {
//不延时暴露,则直接暴露
doExport();
}
上面代码无论是延时暴露或直接暴露调用的方法是:doExport(),doExport会对解析完的配置再做一次检查,核心代码大家可以查看dubbo的源码,下面列出一小部分
/*
检查默认设置,如果xml中没有配置<dubbo:provider
主要是从系统环境变量中寻找是否有相应的provider的配置
*/
checkDefault();
//下面设置的内容如果没有配置<dubbo:provider时基本上都是Null
if (provider != null) {
if (application == null) {
application = provider.getApplication();
}
if (module == null) {
module = provider.getModule();
}
if (registries == null) {
registries = provider.getRegistries();
}
if (monitor == null) {
monitor = provider.getMonitor();
}
if (protocols == null) {
protocols = provider.getProtocols();
}
}
if (module != null) {
//registries一般都会配置
if (registries == null) {
registries = module.getRegistries();
}
if (monitor == null) {
monitor = module.getMonitor();
}
}
if (application != null) {
//application一般也会配置
if (registries == null) {
registries = application.getRegistries();
}
if (monitor == null) {
monitor = application.getMonitor();
}
}
//是否泛化调用
if (ref instanceof GenericService) {
interfaceClass = GenericService.class;
if (StringUtils.isEmpty(generic)) {
generic = Boolean.TRUE.toString();
}
} else {
try {
interfaceClass = Class.forName(interfaceName, true, Thread.currentThread()
.getContextClassLoader());
} catch (ClassNotFoundException e) {
throw new IllegalStateException(e.getMessage(), e);
}
/*
检查即将暴露的接口的方法配置,检查方法是否在接口中存在
一般不会配置所以一般情况下methods为null
<dubbo:service > <dubbo:method /> </dubbo:serivce>
*/
checkInterfaceAndMethods(interfaceClass, methods);
/*
检查接口的引用不为空,并且必须实现的是要暴露的接口
*/
checkRef();
generic = Boolean.FALSE.toString();
}
所有的检查通过之后,会调用 :com.alibaba.dubbo.config.ServiceConfig#doExportUrls 方法,因为dubbo支持多通信协议时,都进行暴露,所以在代码中可以看到
/*
将注册协议转化成url
registry://45.119.68.23:2181/com.alibaba.dubbo.registry.RegistryService?
application=test-dubbo&dubbo=2.5.3&pid=7648®istry=zookeeper×tamp=1462349748801
*/
List<URL> registryURLs = loadRegistries(true);
//配置多通信协议时,都进行暴露
for (ProtocolConfig protocolConfig : protocols) {
doExportUrlsFor1Protocol(protocolConfig, registryURLs);
}
doExportUrlsFor1Protocol中主要将所有的配置转化成map,然后将map转化成dubbo的统一URL,最终暴露的dubbo服务也就是这个统一的url,这个url也会注册到zookeeper的节点上,部分代码如下:
/*
将不为null的配置对象中的属性设置到 map 中
即将 xml 配置文件中的配置设置的值全转化成为map
{side=provider, application=alijk-dubbo, accepts=1000,
dubbo=2.5.3, threads=100, pid=7236, interface=cn.eoncloud.account.sdk.export.AccountService,
threadpool=fixed, version=1.0.0, timeout=500, anyhost=true, timestamp=1462347843960}
*/
appendParameters(map, application);
appendParameters(map, module);
appendParameters(map, provider, Constants.DEFAULT_KEY);
appendParameters(map, protocolConfig);
appendParameters(map, this);
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
/*
将配置信息转化成 url ,主要根据之前map里的数据组装成url
调用 URL#buildString方法
dubbo://10.6.13.137:9998/cn.eoncloud.account.sdk.export.AccountService
?accepts=1000&anyhost=true&application=test-dubbo&dubbo=2.5.3
&interface=cn.eoncloud.account.sdk.export.AccountService
&methods=getAccountName,getAllTest&pid=7236&revision=1.0.0&side=provider
&threadpool=fixed&threads=100&timeout=500×tamp=1462347843960&version=1.0.0
*/
URL url = new URL(name, host, port, (contextPath == null || contextPath.length() == 0 ? "" : contextPath + "/") + path, map);
if (ExtensionLoader.getExtensionLoader(ConfiguratorFactory.class)
.hasExtension(url.getProtocol())) {
url = ExtensionLoader.getExtensionLoader(ConfiguratorFactory.class)
.getExtension(url.getProtocol()).getConfigurator(url).configure(url);
}
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString()));
//com.alibaba.dubbo.registry.integration.RegistryProtocol#export 即将进行暴露
Exporter<?> exporter = protocol.export(invoker);
上面的代码核心暴露的一行代码为:protocol.export(invoker); 这个protocol的值为:RegistryProtocol,也就是暴露会跳到:RegistryProtocol.exprot中去处理,RegistryProtocol.exprot主要做两件事情:1、开启netty服务端 。2、创建zookeeper服务节点。下面来看RegistryProtocol.export 方法,代码如下:
public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
//export invoker doLocalExport调用dubboProtocol.export开启netty服务监听
final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker);
//registry provider
final Registry registry = getRegistry(originInvoker);
final URL registedProviderUrl = getRegistedProviderUrl(originInvoker);
//调用zodoRegister的doRegister 创建zookeeper的服务节点
registry.register(registedProviderUrl);
// 订阅override数据
// FIXME 提供者订阅时,会影响同一JVM即暴露服务,又引用同一服务的的场景,因为subscribed以服务名为缓存的key,导致订阅信息覆盖。
final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registedProviderUrl);
final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl);
overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);
//订阅
registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);
//保证每次export都返回一个新的exporter实例
return new Exporter<T>() {
public Invoker<T> getInvoker() {
return exporter.getInvoker();
}
public void unexport() {
try {
exporter.unexport();
} catch (Throwable t) {
logger.warn(t.getMessage(), t);
}
try {
registry.unregister(registedProviderUrl);
} catch (Throwable t) {
logger.warn(t.getMessage(), t);
}
try {
overrideListeners.remove(overrideSubscribeUrl);
registry.unsubscribe(overrideSubscribeUrl, overrideSubscribeListener);
} catch (Throwable t) {
logger.warn(t.getMessage(), t);
}
}
};
}
上面的代码里有一段特别重要,关键性的代码在doLocalExport中:
final Invoker<?> invokerDelegete = new InvokerDelegete<T>(originInvoker, getProviderUrl(originInvoker));
//此处protol为dubboProtocol
exporter = new ExporterChangeableWrapper<T>((Exporter<T>)protocol.export(invokerDelegete), originInvoker);
从上面的代码中可以看到会调用dubboProtocol的export对服务进行暴露,这个export最终目的就是开启netty的监听,下面来看dubbo是如何一步一步开启netty的
private void openServer(URL url) {
// find server. ip:port
String key = url.getAddress();
//client 也可以暴露一个只有server可以调用的服务。
boolean isServer = url.getParameter(Constants.IS_SERVER_KEY,true);
if (isServer) {
ExchangeServer server = serverMap.get(key);
if (server == null) {
//创建 Server
serverMap.put(key, createServer(url));
} else {
//server支持reset,配合override功能使用
server.reset(url);
}
}
}
private ExchangeServer createServer(URL url) {
//默认开启server关闭时发送readonly事件
url = url.addParameterIfAbsent(Constants.CHANNEL_READONLYEVENT_SENT_KEY, Boolean.TRUE.toString());
//默认开启heartbeat
url = url.addParameterIfAbsent(Constants.HEARTBEAT_KEY, String.valueOf(Constants.DEFAULT_HEARTBEAT));
//默认使用netty
String str = url.getParameter(Constants.SERVER_KEY, Constants.DEFAULT_REMOTING_SERVER);
if (str != null && str.length() > 0 && ! ExtensionLoader.getExtensionLoader(Transporter.class).hasExtension(str))
throw new RpcException("Unsupported server type: " + str + ", url: " + url);
//默认使用dubbo协议编码
url = url.addParameter(Constants.CODEC_KEY, Version.isCompatibleVersion() ? COMPATIBLE_CODEC_NAME : DubboCodec.NAME);
ExchangeServer server;
try {
//HeaderExchangeServer 在此处已经开启了Netty Server 进行监听
server = Exchangers.bind(url, requestHandler);
} catch (RemotingException e) {
throw new RpcException("Fail to start server(url: " + url + ") " + e.getMessage(), e);
}
str = url.getParameter(Constants.CLIENT_KEY);
if (str != null && str.length() > 0) {
Set<String> supportedTypes = ExtensionLoader.getExtensionLoader(Transporter.class).getSupportedExtensions();
if (!supportedTypes.contains(str)) {
throw new RpcException("Unsupported client type: " + str);
}
}
return server;
}
在上面的代码中:Exchangers.bind(url, requestHandler) 默认为:HeaderExchanger.bind()
public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
//Transporters默认为NettyTransporter
return new HeaderExchangeServer(Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler))));
}
代码运行到这里可以看到传输方式了,dubbo默认采用的通信方式为 NettyTransporter ,再来看NettyTransporter.bind方法
public static final String NAME = "netty";
public Server bind(URL url, ChannelHandler listener) throws RemotingException {
return new NettyServer(url, listener);
}
已经能看到NettyServer了,dubbo在暴露服务最终开启的netty服务监听,监听消费者发送的请求,通过反射调用方法得到结果通过 tcp/ip 网络传输返回给消费者。再进入到NettyServer中我们就能看到非常传统的开启Netty服务的代码了
protected void doOpen() throws Throwable {
NettyHelper.setNettyLoggerFactory();
ExecutorService boss = Executors.newCachedThreadPool(new NamedThreadFactory("NettyServerBoss", true));
ExecutorService worker = Executors.newCachedThreadPool(new NamedThreadFactory("NettyServerWorker", true));
//最后一个参数为 NIO 最大工作线程数
ChannelFactory channelFactory = new NioServerSocketChannelFactory(boss, worker, getUrl().getPositiveParameter(Constants.IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS));
//netty server 启动器
bootstrap = new ServerBootstrap(channelFactory);
final NettyHandler nettyHandler = new NettyHandler(getUrl(), this);
channels = nettyHandler.getChannels();
// https://issues.jboss.org/browse/NETTY-365
// https://issues.jboss.org/browse/NETTY-379
// final Timer timer = new HashedWheelTimer(new NamedThreadFactory("NettyIdleTimer", true));
bootstrap.setPipelineFactory(new ChannelPipelineFactory() {
public ChannelPipeline getPipeline() {
NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec() ,getUrl(), NettyServer.this);
ChannelPipeline pipeline = Channels.pipeline();
/*int idleTimeout = getIdleTimeout();
if (idleTimeout > 10000) {
pipeline.addLast("timer", new IdleStateHandler(timer, idleTimeout / 1000, 0, 0));
}*/
pipeline.addLast("decoder", adapter.getDecoder());
pipeline.addLast("encoder", adapter.getEncoder());
pipeline.addLast("handler", nettyHandler);
return pipeline;
}
});
// 创建一个绑定到指定地址的新通道,也就是绑定IP、端口供客户端连接
channel = bootstrap.bind(getBindAddress());
}
上面的代码执行完成后,netty的服务端就已经开启了,可以接收客户端的连接了,但客户端连接上来要怎么处理呢?消息接收、发送怎么处理呢?所有的处理都在上面代码的 NettyHandler类中,Nettyhandler继承了Netty包中的的SimpleChannelHandler
NettyHandler extends SimpleChannelHandler
重写了 channelConnected、channelDisconnected、messageReceived等方法,而我们比较关注的可能是messagereceived方法,在收到消息时如何处理,但今天暂时先不看dubbo如果处理消息,只看暴露,消息处理如何实现异步通信以后再讲。
/**
* 收到消息时触发
* @param ctx
* @param e
* @throws Exception
*/
@Override
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception {
NettyChannel channel = NettyChannel.getOrAddChannel(ctx.getChannel(), url, handler);
try {
handler.received(channel, e.getMessage());
} finally {
NettyChannel.removeChannelIfDisconnected(ctx.getChannel());
}
}
从前面知道,开启netty服务是在RegistryProtocol.export 的 doLocalExport 中,在开启了netty服务后,就是在zookeeper上注册服务节点了,消费者在消费服务时会根据消费的接口名找到对应的zookeeper节点目录,对目录进行监听,接收推送
//registry provider
final Registry registry = getRegistry(originInvoker);
final URL registedProviderUrl = getRegistedProviderUrl(originInvoker);
//调用zodoRegister的doRegister 创建zookeeper的服务节点
registry.register(registedProviderUrl);
// 订阅override数据
// FIXME 提供者订阅时,会影响同一JVM即暴露服务,又引用同一服务的的场景,因为subscribed以服务名为缓存的key,导致订阅信息覆盖。
final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registedProviderUrl);
final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl);
overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);
//订阅
registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);
dubbo服务在zookeeper上的节点注册是:com.alibaba.dubbo.registry.support.FailbackRegistry#register
@Override
public void register(URL url) {
super.register(url);
failedRegistered.remove(url);
failedUnregistered.remove(url);
try {
// 向服务器端发送注册请求
doRegister(url);
因为doRegister是一个抽象的方法,查看他的实现可以看到如下图:
从上图可以看到doRegister实现有 dubbo、redis、zookeeper,这也是在我们配置时经常看到的 注册协议的配置 ,最为常用的就是 zookeeper了,所以再看ZookeeperRegistry的代码,看他的doRegistry干什么了如下
protected void doRegister(URL url) {
try {
zkClient.create(toUrlPath(url), url.getParameter(Constants.DYNAMIC_KEY, true));
} catch (Throwable e) {
throw new RpcException("Failed to register " + url + " to zookeeper " + getUrl() + ", cause: " + e.getMessage(), e);
}
}
其实从上面已经可以看到 在zookeeper上面创建 节点了,默认不分组的情况下,服务结构如下:/dubbo/XXXXservice/consumers、providers
至此,dubbo的暴露基本上已经完成,开启了netty服务,注册了zookeeper的节点,就等着消费者连接上来使用了
2 消息发送和接收过程
3 dubbo总体架构
dubbo 总体设计
Dubbo框架一共分为10个层,图中左边淡蓝色为服务消费者使用的接口,右边淡绿色为服务提供者使用的接口,位于中轴线上的是双方都可使用的接口。下面看一下10各层每层的作用。
- 1.服务接口层(Service):主要是跟实际业务相关,是专门提供给想接入Dubbo的分布式服务项目实现业务逻辑的接口层,服务的提供方和消费方根据业务来设计接口和实现接口。
- 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 实际上不算一层,而是一个独立的节点,只是为了全局概览,用层的方式画在一起。
模块分包
-
dubbo-common公共逻辑模块,提供了各种Util类,通用模块。
-
dubbo-remoting远程通讯模块,主要实现DubboProtocol底层通讯细节(用RMI协议,此包没用),包含的接口有:Transaction(传输层),Exchange数据交换层等;
-
dubbo-rpc远程调用模块,实现Protocol,Invoker, Exporter等上层协议接口定义,实现
DubboProtocol协议的上层实现,以及DubboCodec类(dubbo编码)实现;封装了Hession协议、RMI协议、Http协议、WebService协议、Rest协议、Thrift等协议的实现;抽象了动态代理,只包含一对一的调用,不关心集群的管理。 -
dubbo-cluster集群模块,将多个提供方伪装成一个服务方,定义了Cluster集群接口、容错接口、Loadbalance负载均衡接口、Route接口,Directry目录接口,并提供了以上接口的各种实现。集群的地址列表可以是静态配置的,也可以是由注册中心下发。
-
dubbo-register注册中心模块,基于注册中心下发地址的集群方式,以及对各种注册中心的抽象。
-
dubbo-config配置模块,实现服务提供者和消费者的配置定义加载。
-
dubbo-container容器模块,实现了启动时的服务提供者和消费者启动、加载、初始化。一个 Standlone 的容器,以简单的Main 加载 Spring 启动,因为服务通常不需要 Tomcat/JBoss 等 Web 容器的特性,没必要用 Web容器去加载服务。
-
dubbo-monitor 监控模块:统计服务调用次数,调用时间的,调用链跟踪的服务。整体上按照分层结构进行分包,与分层的不同点在于:
-
container 为服务容器,用于部署运行服务,没有在层中画出。
-
protocol 层和 proxy 层都放在 rpc 模块中,这两层是 rpc的核心,在不需要集群也就是只有一个提供者时,可以只使用这两层完成 rpc 调用。
-
transport 层和 exchange 层都放在 remoting 模块中,为 rpc 调用的通讯基础。
-
serialize 层放在 common 模块中,以便更大程度复用。
将上图调用链展开的话就是下面这张详细调用链图
展开总设计图左边服务提供方暴露服务的蓝色初始化链,时序图如下:
展开总设计图右边服务消费方引用服务的蓝色初始化链,时序图如下: