Dubbo基本原理及rpc过程

dubbo

1) 远程通讯协议基本原理

a) 网络通信:将二进制流从一台计算机传输到另外一台计算机,基于传输协议和网络IO来实现
b) 传输协议有 http 、 tcp 、 udp, 都是在基于 Socket 概念扩展而来
c) 网络IO,主要有 bio 、 nio 、 aio, 所有的分布式应用通讯都基于这个原理而实现

2) 狭义RPC过程

a) 假设两台服务器A,B,一个应用部署在A服务器上,想要调用B服务器上应用提供的函数/方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据
b) 首先A和B建立TCP链接,并且确定好RPC框架的网路端口,能够进行网络通信
c) 然后A服务器将需要调用B服务器的方法和参数进行序列化(Serialize)
d) 通过第一步建立的链接,将序列化后的二进制流发送给B
e) B服务器收到请求后,需要对参数进行反序列化,恢复为内存中的表达方式
f) 然后B服务器找到对应的方法(寻址的一部分)进行本地调用,然后得到返回值
g) B服务器对返回值再次进行序列化,并且通过相同的途径发送给A
h) A对B服务器返回的信息再进行反序列化,得到返回结果
i) 三个关键点
Call ID映射: 要调用的方法名, 必须是唯一的
序列化和反序列化: 二进制流
网络传输: 通过rpc协议

3) 分布式RPC过程

a) 传输协议: thrift,hession等
b) client代理,服务引用方调用方法通过代理发送远程调用
c) 协议编解码压缩,如序列化和反序列化 netty
d) 注册中心,服务注册和服务发现,存放服务信息 zookeeper
e) 负载均衡,服务容错策略其他:服务降级,服务隔离,服务治理

4) dubbo是一个分布式RPC框架

a) 包含四个角色服务提供者(provider),消费者(consumer),服务注册配置中心(registry),监控(monitor) 
b) 服务注册中心包含configServer+zookeeper,也支持redis
c) 服务提供者provider
启动时主动与ConfigServer建立Scoket长连接
同时将自己的IP,提供的服务名称,端口等信息直接发送给ConfigServer
configserver将provider提供的服务信息发送到zookeeper
zookeeper通过watcher机制推送提供者信息给消费者(此时可能没有服务消费者)
d) 服务消费者consumer
启动时主动与ConfigServer建立Socket长连接
同时将自己的IP等相应信息发送给ConfigServer
configserver将consumer提供的信息发送到zookeeper
zookeeper信息(Znode本身的增加,删除,修改,以及子Znode的变化)发生变更后通过watcher机制通知consumer, 也即推送服务提供者的信息 
拿到服务提供者信息后,与它们都建立连接,后面就可以直接调用服务
当有多个服务提供者的时候,Client根据一定的规则来进行负载均衡,如轮询,随机,按权重等
消费者自己宕机了, 没法自己通知configserver和zookeeper, 只能通过心跳机制
e) 服务注册配置中心: configServer+zookeeper
configserver跟所有服务提供者和消费者作心跳检测
当某个Server不可用,就触发修改zookeeper中服务提供者的请求
zookeeper信息发生变更后,通过watcher机制通知消费者,即推送最新的服务提供者信息
消费者重新连接服务提供者

5) 一次服务调用过程

a) 采用异步线程调用的方式执行rpc
b) consumer发起一个远程调用时,首先创建一个callback类型的线程对象
c) 生成一个唯一id(比如uuid)作为key
d) 方法调用信息(如调用的接口名称,参数)和处理返回结果的callback对象全部封装成一个object作为value
e) put到全局concurrenthashmap中
f) 服务端接收到请求并处理完成后,将结果发送给客户端,客户端专门监听消息的线程收到结果,取得唯一id,从全局concurrenthashmap中得到callback对象
g) 监听线程获取到callback对象的锁,然后notifyall()唤醒其它处于等待状态的线程,整个过程结束
h) dubbo默认使用mina+hession来进行rpc
mina处理网络传输:基于tcp的nio异步传输
序列化使用hession二进制序列化

猜你喜欢

转载自blog.csdn.net/zyf_balance/article/details/78729200