dubbo请求调用过程分析

简介:

服务消费方发起请求

 

当服务的消费方引用了某远程服务,服务的应用方在spring的配置实例如下:

 

<dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" />

 

demoService实例其实是代理工厂生产的代理对象(大家可以参考代理那部分生成的伪代码),在代码中调用demoService.sayHello(“world!”)时,

 

1.      将方法名方法参数传入InvokerInvocationHandler的invoke方

 

对于Object中的方法toString, hashCode, equals直接调用invoker的对应方法,

 

这里对于Object的方法需要被远程调用吗?调用了是不是报错比默认处理更好呢??

 

远程调用层是以Invocation, Result为中心, 这里根据要调用的方法以及传入的参数构建RpcInvocation对象,作为Invoker的入参

 

2.      MockClusterInvoker根据参数提供了三种调用策略

 

不需要mock, 直接调用FailoverClusterInvoker

 

强制mock,调用mock

 

先调FailoverClusterInvoker,调用失败在mock、

 

3.      FailoverClusterInvoker默认调用策略

 

通过目录服务查找到所有订阅的服务提供者的Invoker对象

 

路由服务根据策略来过滤选择调用的Invokers

 

通过负载均衡策略LoadBalance来选择一个Invoker

 

4.      执行选择的Invoker.inoker(invocation)

 

经过监听器链,默认没有

 

经过过滤器链,内置实现了很多

 

执行到远程调用的DubboInvoker

 

5.      DubboInvoker

 

根据url 也就是根据服务提供者的长连接,这里封装成交互层对象ExchangeClient供这里调用

 

判断远程调用类型同步,异步还是oneway模式

 

ExchangeClient发起远程调用,底层remoting不在这里描述了

 

获取调用结果:

 

        Oneway返回空RpcResult

 

        异步,直接返回空RpcResult, ResponseFuture回调

 

        同步, ResponseFuture模式同步转异步,等待响应返回

 

 

 

 

 

服务提供方接收调用请求

 

同样我们也是rpc调用层DubboProtocol层开始分析,对于通信层remoting的数据接收反序列等等过程不做分析。

 

DubboProtocol的requestHandler是ExchangeHandler的实现,是remoting层接收数据后的回调。

 

requestHandler.replay方法接收请求消息,这里只处理远程调用消息Invocation。

 

1.      通过Invocation获取服务名和端口组成serviceKey=com.alibaba.dubbo.demo.DemoService:20880, 从DubboProtocol的exproterMap中获取暴露服务的DubboExporter, 在从dubboExporter 获取invoker返回

 

2.      经过过滤器链

 

3.      经过监听器链

 

4.      到达执行真正调用的invoker, 这个invoker由代理工厂ProxyFactory.getInvoker(demoService, DemoService.class, registryUrl)创建,具体请看代理那部分介绍。

 

调用demoService实例方法,将结果封装成RpcResult返回

 

5.      交换层构建Response,通过Remoting层编码传输将结果响应给调用方

 

 

 

 

 

服务消费方发起远程调用的底层通信

 

 

服务提供方接收请求并响应的底层通信

 

一:provider提供方

 



 

ClassPathXmlApplicationContext <init>(构造方法)

 

-> ClassPathXmlApplicationContext refresh()

 

-> ClassPathXmlApplicationContext finishRefresh()

 

-> AbstractApplicationContext publishEvent()

 

-> ServiceBean onApplicationEvent()

 

-> ServiceConfig doExport()

 

#构造dubbo对象 application provider module protocol registry service reference consume等

 

 

 

-> ServiceConfig doExportUrls #导出URL,获取注册中心RegistryConfig

 

#注册中心:registry://10.199.101.228:2181/com.alibaba.dubbo.registry.RegistryService?application=demo&backup=10.199.101.227:2181,10.199.101.229:2181&dubbo=2.4.9&pid=8045&registry=zookeeper&timestamp=1491546077803

 

 

 

-> ServiceConfig doExportUrlsFor1Protocol()

 

#需要暴露 dubbo://10.199.66.242:20880/com.unj.dubbotest.provider.DemoService?anyhost=true&application=dubbo_demo_provider&dubbo=2.4.9&interface=com.unj.dubbotest.provider.DemoService&methods=sayHello,getUsers&pid=8045&revision=0.0.1&side=provider&timestamp=1491546674441&version=0.0.1

 

 

 

-> ServiceConfig exportLocal()

 

-> Exporter<?> exporter = protocol.export(proxyFactory.getInvoker(ref, (Class) interfaceClass, local));

 

#暴露Invoker<XxxService>调用服务代理类

 

 

 

-> proxyFactory.getInvoker(ref, (Class) interfaceClass, local)

 

#返回 AbstractProxyInvoker代理ProxyInvoker<XxxService>

 

public abstract class AbstractProxyInvoker<T> implements Invoker<T> {

 

private final T proxy; //代理目标实例 XxxServiceImpl

 

private final Class<T> type;

 

private final URL url;

 

}

 

-> InvokerInvocationHandler.invoke()

 

#invoker.invoke(new RpcInvocation(method, args)).recreate();

 

 

 

-> DubboProtocol export(Invoker<T> invoker)

 

# 返回暴露Exporter<T>

 

public class DubboExporter<T> extends AbstractExporter<T> {

 

private final String key; //com.unj.dubbotest.provider.DemoService:0.0.1:20880

 

private final Map<String, Exporter<?>> exporterMap;

 

public DubboExporter(Invoker<T> invoker, String key, Map<String, Exporter<?>> exporterMap){

 

super(invoker);

 

this.key = key;

 

this.exporterMap = exporterMap;

 

}

 

 

 

-> DubboProtocol openServer(url)

 

#url dubbo://10.199.66.242:20880/com.unj.dubbotest.provider.DemoService?anyhost=true&application=dubbo_demo&dubbo=2.4.9&interface=com.unj.dubbotest.provider.DemoService&methods=sayHello,getUsers&pid=8045&revision=0.0.1&side=provider&timestamp=1491546674441&version=0.0.

 

#serverMap.put(key, createServer(url)); key:10.199.66.242:20880 value:ExchangeServer

 

 

 

-> DubboProtocol createServer(URL url)

 

#返回HeaderExchangeServer,添加参数列表 如心跳,心跳时间

 

-> Exchangers.bind(url, requestHandler);

 

#返回HeaderExchangeServer,getTransporter()获取的实例来源于配置,默认返回一个NettyTransporter

 

-> HeaderExchangeServer.bind(URL url, ExchangeHandler handler);

 

 

 

-> HeaderExchangeServer(Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler))));

 

#HeaderExchangeServer包装实例NettyServer

 

 

 

-> NettyTransporter.bind(URL url, ChannelHandler listener)

 

#return new NettyServer(url, listener)

 

 

 

-> NettyServer.doOpen();

 

#打开socket监听端口准备接收消息

 

#ServerBootstrap bind(getBindAddress())绑定地址端口

 

#RpcInvocation 具体类名、方法名、调用参数

 

#DubboInvoker – 执行具体的远程调用,包含初始化信息如client

 

#Protocol – 服务地址的发布和订阅

 

#Exporter – 暴露服务的引用,或取消暴露

 

 

 

二:consume(消费方):

 

->ReferenceConfig.init

 

#consume端启动初始化

 

->DubboProtocol.refer

 

#根据参数url,接口等构建Invoker

 

->JavassistProxyFactory.getProxy(Invoker<T> invoker, Class<?>[] interfaces)

 

#构建代理对象Proxy.getProxy(interfaces).newInstance(new InvokerInvocationHandler(invoker));

 

 

 

->DemoService.say(String hello);#真正调用时候

 

->InvokerInvocationHandler.invoke(Object proxy, Method method, Object[] args)

 

#invoker.invoke(new RpcInvocation(method, args)).recreate();RpcInvocation包装参数方法名

 

->DubboInvoker.doInovke(final Invocation invocation)

 

#统一代理调用

 

->ExchangeClient.send(invocation, isSent);

 

->HeaderExchangeChannel.request(Object request, int timeout)

 

->NettyChannel.send(Object message, boolean sent)

 

 

 

三:dubbo 底层通讯:NettyClient <-- 异步NIO传输 socket监听-> NettyServer

 

 

 

四:consume --> provider 调用过程:

 

-> NettyServer->NettyHandler.messageReceived #接收消息处理器

 

-> MultiMessageHandler->HeartbeatHandler->AllChannelHandler->DecodeHandler->HeaderExchangeHandler->DubboProtocol$requestHandler

 

#NettyServer启动时候绑定MultiMessageHandler

 

#DubboProtocol.getServers() 检索serverMap获取Exporter<?>

 

#DubboProtocol.getServers() 检索serverMap获取ExchangeServer

 

-> ExchangeHandlerAdapter.reply

 

#真正获取Invoker,将传入message 转换 invocation

 

-> invoker.invoke(invocation)

 

-> JavassistProxyFactory$AbstractProxyInvoker.doInvoke

 

#服务端Invoker代理 AbstractProxyInvoker调用目标引用service

原文链接:[http://wely.iteye.com/blog/2378164 ]
相关文章
|
2月前
|
Dubbo Cloud Native 网络协议
【Dubbo3技术专题】「服务架构体系」第一章之Dubbo3新特性要点之RPC协议分析介绍
【Dubbo3技术专题】「服务架构体系」第一章之Dubbo3新特性要点之RPC协议分析介绍
40 1
|
6月前
|
负载均衡 Dubbo 应用服务中间件
微服务技术系列教程(31) - Dubbo-原理及负载均衡分析
微服务技术系列教程(31) - Dubbo-原理及负载均衡分析
56 0
|
4月前
|
负载均衡 Dubbo 算法
深入理解Dubbo-2.Dubbo功能之高级特性分析
深入理解Dubbo-2.Dubbo功能之高级特性分析
58 0
|
2月前
|
Java fastjson 数据安全/隐私保护
【Dubbo3技术专题】「云原生微服务开发实战」 一同探索和分析研究RPC服务的底层原理和实现
【Dubbo3技术专题】「云原生微服务开发实战」 一同探索和分析研究RPC服务的底层原理和实现
45 0
|
5月前
|
Dubbo Java 应用服务中间件
Dubbo的原理分析
Dubbo的原理分析
42 0
|
6月前
|
缓存 Dubbo Java
Dubbo的优雅下线原理分析
在线上环境,用到更多的,是kill pid指令,这个指令,等同于kill -15 pid指令,因此,当你在网上看到一些介绍kill -15 pid指令时,不用纠结好像没用到过,其实,就是你用到最多的kill pid指令。使用这个指令时,系统会对pid进程发送一个SIGTERM信号,就像给pid打了一个电话,告诉他,你的房子就要到期了,麻烦快点清理好东西搬走。这时,你仍有充裕的时间,把自己的东西打包好,好好清理下房间,没问题了,再搬出去。
32 0
|
8月前
|
存储 Dubbo Java
dubbo 源码 v2.7 分析:通信过程及序列化协议
前面我们介绍了dubbo的核心机制,今天将开始分析远程调用流程。毕竟,作为一个rpc框架,远程调用是理论的核心内容。通过对dubbo相关实现的探究,深入了解rpc原理及可能的问题。
132 0
|
8月前
|
负载均衡 Dubbo Java
dubbo源码v2.7分析:结构、container入口及线程模型
Apache Dubbo 是一款高性能、轻量级的开源 Java 服务框架,提供了六大核心能力:面向接口代理的高性能RPC调用,智能容错和负载均衡,服务自动注册和发现,高度可扩展能力,运行期流量调度,可视化的服务治理与运维。
66 0
|
9月前
|
负载均衡 监控 Dubbo
Dubbo底层原理分析和分布式实际应用
Dubbo底层原理分析和分布式实际应用
|
12月前
|
安全 Dubbo 应用服务中间件
Dubbo反序列化漏洞复现分析(二)
Dubbo反序列化漏洞复现分析(二)