码迷,mamicode.com
首页 > 其他好文 > 详细

Dubbo系列(三)dubbo的核心技术--RPC调用

时间:2019-03-30 16:06:51      阅读:473      评论:0      收藏:0      [点我收藏+]

标签:发送请求   视频   大数据量   问题:   mina框架   hash   千兆   tom   总结   

dubbo的核心技术--RPC调用:分为俩部分RPC协议Protocol和方法调用Invoke;

一、RPC协议Protocol(Remote Procedure Call)远程过程调用协议

1、我们平时使用最多的http协议其实也属于RPC协议,下图分别是普通的传输层TCP和应用层http与dubbo优化后的TCP和dubbo协议进行对比。

技术图片

总结:

原生的传输层协议(TCP)需要网络三次握手和四次挥手,客户端与服务端的建立链接成本过高,dubbo对TCP进行优化,实现单一长连接,降低网络链接成本;

原生的应用层协议(http)通用性高、拓展性强,同时协议复杂解析成本高,dubbo消费者调用服务者时只需要传输很少字节,并且结构简单,便与解析;

 2、dubbo远程同步调用原理分析:

Dubbo默认协议采用单一长连接和NIO异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。Dubbo缺省协议不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。

dubbo缺省协议,使用基于mina1.1.7+hessian3.2.1的tbremoting交互。

  • 连接个数:单连接
  • 连接方式:长连接
  • 传输协议:TCP
  • 传输方式:NIO异步传输
  • 序列化:Hessian二进制序列化
  • 适用范围:传入传出参数数据包较小(建议小于100K),消费者比提供者个数多,单一消费者无法压满提供者,尽量不要用dubbo协议传输大文件或超大字符串
  • 适用场景:常规远程服务方法调用

为什么采用异步单一长连接:因为服务的现状大都是服务提供者少,而服务的消费者多,通过单一长连接,保证单一消费者不会压死提供者,长连接减少连接握手验证,并使用异步IO,复用线程池,降低网络链接成本。

为什么要消费者比提供者个数多:因为dubbo协议采用单一长连接,假设网络为千兆网卡(1024Mbit=128MByte),根据测试经验数据每条连接最多只能压满7MByte(不同的网络环境可能不一样,仅供参考),理论上1个服务提供者需要20个服务消费者才能压满网卡。

为什么不能传大包:如果每次请求的数据包大小为500KByte,则单个服务提供者的TPS(每秒处理事务数)最大为:128Mbyte/500KByte=262. 单个消费者调用单个服务提供者的TPS(每秒处理事务数)最大为: 7MByte/500KByte = 14。可看出网络将成为瓶颈。

通常,一个典型的同步远程调用应该是这样的:

技术图片

1、客户端线程调用远程接口,向服务端发送请求,同时当前线程应该处于“暂停“状态,即线程不能向后执行了,必需要拿到服务端给自己的结果后才能向后执行;
2、服务端接到客户端请求后,处理请求,将结果给客户端;
3、客户端收到结果,然后当前线程继续往后执行;

Dubbo底层使用Socket发送消息的形式进行数据传递,结合了mina框架,使用IoSession.write()方法,这个方法调用后对于整个远程调用(从发出请求到接收到结果)来说是一个异步的,即对于当前线程来说,将请求发送出来,线程就可以往后执行了,至于服务端的结果,是服务端处理完成后,再以消息的形式发送给客户端的。----红字部分我没有搞明白!!

于是这里出现了2个问题:
  • 当前线程怎么让它“暂停”,等结果回来后,再向后执行?
  • 正如前面所说,Socket通信是一个全双工的方式,如果有多个线程同时进行远程方法调用,这时建立在client server之间的socket连接上会有很多双方发送的消息传递,前后顺序也可能是乱七八糟的,server处理完结果后,将结果消息发送给client,client收到很多消息,怎么知道哪个消息结果是原先哪个线程调用的?
基本原理如下:
1.client一个线程调用远程接口,生成一个唯一的ID(比如一段随机字符串,UUID等),Dubbo是使用AtomicLong从0开始累计数字的。
2.将打包的方法调用信息(如调用的接口名称,方法名称,参数值列表等),和处理结果的回调对象callback,全部封装在一起,组成一个对象object。
3.向专门存放调用信息的全局ConcurrentHashMap中put(Id,Object)。
4.将ID和打包的方法调用信息封装成以对象connRequest,使用IoSession.write(connRequest)异步发送出去。
5.当前线程再使用callback的get()方法视图获取远程方法返回的结果,在get()内部,则使用synchronized获取回调对象callback的锁,再先检测是否已经获取到结果,如果没有,就调用callback的wait()方法,释放callback上的锁,让当前线程处于等待状态。
6.服务端接收到请求并处理后,将结果(此结果中包含了签名的ID,即回传)发送给客户端,客户端socket连接上专门监听消息的线程收到消息,分析结果,取到ID,再从前面的ConcurrentHashMap中get(Id),从而找到callback,将方法调用结果设置到callback对象里。
7.监听线程接着使用synchronized获取回调对象callback的锁(因为前面调用过wait(),那个线程已经释放callback的锁了),再notifyAll(),唤醒前面处于等待状态的线程继续执行(callback的get()方法继续执行就能拿到调用结果了),至此,整个过程结束。
需要注意的是,这里的callback对象是每次调用产生一个新的,不能共享,否则会有问题;另外ID必需至少保证在一个Socket连接里面是唯一的。
 
现在,前面两个问题已经有答案了:
  • 当前线程怎么让它“暂停”,等结果回来后,再向后执行?
     答:先生成一个对象obj,在一个全局map里put(ID,obj)存放起来,再用synchronized获取obj锁,再调用obj.wait()让当前线程处于等待状态,然后另一消息监听线程等到服务端结果来了后,再map.get(ID)找到obj,再用synchronized获取obj锁,再调用obj.notifyAll()唤醒前面处于等待状态的线程。
  • 正如前面所说,Socket通信是一个全双工的方式,如果有多个线程同时进行远程方法调用,这时建立在client server之间的socket连接上会有很多双方发送的消息传递,前后顺序也可能是乱七八糟的,server处理完结果后,将结果消息发送给client,client收到很多消息,怎么知道哪个消息结果是原先哪个线程调用的?
     答:使用一个ID,让其唯一,然后传递给服务端,再服务端又回传回来,这样就知道结果是原先哪个线程的了。

 

Dubbo系列(三)dubbo的核心技术--RPC调用

标签:发送请求   视频   大数据量   问题:   mina框架   hash   千兆   tom   总结   

原文地址:https://www.cnblogs.com/aoshicangqiong/p/8111833.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!