第一章聊了【“为什么要进行服务化,服务化究竟解决什么问题”

第二章聊了【“微服务的服务粒度选型”

第三章聊了【“为什么说要搞定微服务架构,先搞定RPC框架?”

上一章聊了【“微服务架构之RPC-client序列化细节”

通过上篇文章的介绍,知道了要实施微服务,首先要搞定RPC框架,RPC框架分为客户端部分与服务端部分。


RPC-client的部分又分为:

(1)序列化反序列化的部分(上图中的1、4)

(2)发送字节流与接收字节流的部分(上图中的2、3)

前一篇文章讨论了序列化与范序列化的细节,这一篇文章将讨论发送字节流与接收字节流的部分。

客户端调用又分为同步调用与异步调用

同步调用的代码片段为:

Result = Add(Obj1, Obj2);// 得到Result之前处于阻塞状态

异步调用的代码片段为:

Add(Obj1, Obj2, callback);// 调用后直接返回,不等结果

处理结果通过回调得到:

callback(Result){// 得到处理结果后会调用这个回调函数

}

这两个调用方式,RPC-client里,处理方式也不一样,下文逐一叙述。

RPC-client同步调用


所谓同步调用,在得到结果之前,一直处于阻塞状态,会一直占用一个工作线程,上图简单的说明了一下组件、交互、流程步骤。

上图中的左边大框,就代表了调用方的一个工作线程。

左边粉色中框,代表了RPC-client组件。

右边橙色框,代表了RPC-server。

蓝色两个小框,代表了同步RPC-client两个核心组件,序列化组件与连接池组件。

白色的流程小框,以及箭头序号1-10,代表整个工作线程的串行执行步骤:

1)业务代码发起RPC调用,Result=Add(Obj1,Obj2)

2)序列化组件,将对象调用序列化成二进制字节流,可理解为一个待发送的包packet1

3)通过连接池组件拿到一个可用的连接connection

4)通过连接connection将包packet1发送给RPC-server

5)发送包在网络传输,发给RPC-server

6)响应包在网络传输,发回给RPC-client

7)通过连接connection从RPC-server收取响应包packet2

8)通过连接池组件,将conneciont放回连接池

9)序列化组件,将packet2范序列化为Result对象返回给调用方

10)业务代码获取Result结果,工作线程继续往下走

RPC框架需要支持负载均衡、故障转移、发送超时,这些特性都是通过连接池组件去实现的。

连接池组件


典型连接池组件对外提供的接口为:

int ConnectionPool::init(…);

Connection ConnectionPool::getConnection();

intConnectionPool::putConnection(Connection t);

【INIT】

和下游RPC-server(一般是一个集群),建立N个tcp长连接,即所谓的连接“池”

【getConnection】

从连接“池”中拿一个连接,加锁(置一个标志位),返回给调用方

【putConnection】

将一个分配出去的连接放回连接“池”中,解锁(也是置一个标志位)

如何实现负载均衡?

回答:连接池中建立了与一个RPC-server集群的连接,连接池在返回连接的时候,需要具备随机性。

如何实现故障转移?

回答:连接池中建立了与一个RPC-server集群的连接,当连接池发现某一个机器的连接异常后,需要将这个机器的连接排除掉,返回正常的连接,在机器恢复后,再将连接加回来。

如何实现发送超时?

回答:因为是同步阻塞调用,拿到一个连接后,使用带超时的send/recv即可实现带超时的发送和接收。

总的来说,同步的RPC-client的实现是相对比较容易的,序列化组件、连接池组件配合多工作线程数,就能够实现。还有一个问题,就是【“工作线程数设置多少最为合适?”】,这个问题在之前的文章中讨论过,此处不再深究。

RPC-client异步回调


所谓异步回调,在得到结果之前,不会处于阻塞状态,理论上任何时间都没有任何线程处于阻塞状态,因此异步回调的模型,理论上只需要很少的工作线程与服务连接就能够达到很高的吞吐量。

上图中左边的框框,是少量工作线程(少数几个就行了)进行调用与回调。

中间粉色的框框,代表了RPC-client组件。

右边橙色框,代表了RPC-server。

蓝色六个小框,代表了异步RPC-client六个核心组件:上下文管理器,超时管理器,序列化组件,下游收发队列,下游收发线程,连接池组件。

白色的流程小框,以及箭头序号1-17,代表整个工作线程的串行执行步骤:

1)业务代码发起异步RPC调用,Add(Obj1,Obj2, callback)

2)上下文管理器,将请求,回调,上下文存储起来

3)序列化组件,将对象调用序列化成二进制字节流,可理解为一个待发送的包packet1

4)下游收发队列,将报文放入“待发送队列”,此时调用返回,不会阻塞工作线程

5)下游收发线程,将报文从“待发送队列”中取出,通过连接池组件拿到一个可用的连接connection

6)通过连接connection将包packet1发送给RPC-server

7)发送包在网络传输,发给RPC-server

8)响应包在网络传输,发回给RPC-client

9)通过连接connection从RPC-server收取响应包packet2

10)下游收发线程,将报文放入“已接受队列”,通过连接池组件,将conneciont放回连接池

11)下游收发队列里,报文被取出,此时回调将要开始,不会阻塞工作线程

12)序列化组件,将packet2范序列化为Result对象

13)上下文管理器,将结果,回调,上下文取出

14)通过callback回调业务代码,返回Result结果,工作线程继续往下走

如果请求长时间不返回,处理流程是:

15)上下文管理器,请求长时间没有返回

16)超时管理器拿到超时的上下文

17)通过timeout_cb回调业务代码,工作线程继续往下走

上下文管理器

为什么需要上下文管理器?

回答:由于请求包的发送,响应包的回调都是异步的,甚至不在同一个工作线程中完成,需要一个组件来记录一个请求的上下文,把请求-响应-回调等一些信息匹配起来。

如何将请求-响应-回调这些信息匹配起来?

这是一个很有意思的问题,通过一条连接往下游服务发送了a,b,c三个请求包,异步的收到了x,y,z三个响应包:


(1)怎么知道哪个请求包与哪个响应包对应?

(2)怎么知道哪个响应包与哪个回调函数对应?

回答:这是通过【请求id】来实现请求-响应-回调的串联的。


整个处理流程如上,通过请求id,上下文管理器来对应请求-响应-callback之间的映射关系:

1)生成请求id

2)生成请求上下文context,上下文中包含发送时间time,回调函数callback等信息

3)上下文管理器记录req-id与上下文context的映射关系,

4)将req-id打在请求包里发给RPC-server

5)RPC-server将req-id打在响应包里返回

6)由响应包中的req-id,通过上下文管理器找到原来的上下文context

7)从上下文context中拿到回调函数callback

8)callback将Result带回,推动业务的进一步执行

如何实现负载均衡,故障转移?

回答:与同步的连接池思路相同。不同在于,同步连接池使用阻塞方式收发,需要与一个服务的一个ip建立多条连接,异步收发,一个服务的一个ip只需要建立少量的连接(例如,一条tcp连接)。

如何实现超时发送与接收?

回答:同步阻塞发送,可以直接使用带超时的send/recv来实现,异步非阻塞的nio的网络报文收发,如何实现超时接收呢?(由于连接不会一直等待回包,那如何知晓超时呢?)这时,超时管理器就上场啦。

超时管理器


超时管理器,用于实现请求回包超时回调处理。

每一个请求发送给下游RPC-server,会在上下文管理器中保存req-id与上下文的信息,上下文中保存了请求很多相关信息,例如req-id,回包回调,超时回调,发送时间等。

超时管理器启动timer对上下文管理器中的context进行扫描,看上下文中请求发送时间是否过长,如果过长,就不再等待回包,直接超时回调,推动业务流程继续往下走,并将上下文删除掉。

如果超时回调执行后,正常的回包又到达,通过req-id在上下文管理器里找不到上下文,就直接将请求丢弃(因为已经超时处理过了)。

however,异步回调和同步回调相比,除了序列化组件和连接池组件,会多出上下文管理器,超时管理器,下游收发队列,下游收发线程等组件,并且对调用方的调用习惯有影响(同步->回调)。异步回调能提高系统整体的吞吐量,具体使用哪种方式实现RPC-client,可以结合业务场景来选取(对时延敏感的可以选用同步,对吞吐量敏感的可以选用异步)。

末了,通过最近几篇RPC框架细节的文章阅读量来看,貌似大伙对细节不是特别感兴趣,后续文章就不再延续这个系列啦。

==【完】==

【文章转载自微信公众号“架构师之路”】

【58沈剑架构系列】RPC-client异步收发核心细节?的更多相关文章

  1. 【58沈剑架构系列】为什么说要搞定微服务架构,先搞定RPC框架?

    第一章聊了[“为什么要进行服务化,服务化究竟解决什么问题”] 第二章聊了[“微服务的服务粒度选型”] 今天开始聊一些微服务的实践,第一块,RPC框架的原理及实践,为什么说要搞定微服务架构,先搞定RPC ...

  2. 【58沈剑架构系列】微服务架构之RPC-client序列化细节

    第一章聊了[“为什么要进行服务化,服务化究竟解决什么问题”] 第二章聊了[“微服务的服务粒度选型”] 上一篇聊了[“为什么说要搞定微服务架构,先搞定RPC框架?”] 通过上篇文章的介绍,知道了要实施微 ...

  3. 【58沈剑架构系列】互联网公司为啥不使用mysql分区表?

    缘起:有个朋友问我分区表在58的应用,我回答不出来,在我印象中,百度.58都没有听说有分区表相关的应用,业内进行一些技术交流的时候也更多的是自己分库分表,而不是使用分区表.于是去网上查了一下,并询问了 ...

  4. 【58沈剑架构系列】mysql并行复制优化思路

    一.缘起 mysql主从复制,读写分离是互联网用的非常多的mysql架构,主从复制最令人诟病的地方就是,在数据量较大并发量较大的场景下,主从延时会比较严重. 为什么mysql主从延时这么大? 回答:从 ...

  5. 【58沈剑架构系列】主从DB与cache一致性

    本文主要讨论这么几个问题: (1)数据库主从延时为何会导致缓存数据不一致 (2)优化思路与方案 一.需求缘起 上一篇<缓存架构设计细节二三事>中有一个小优化点,在只有主库时,通过“串行化” ...

  6. 【58沈剑架构系列】lvs为何不能完全替代DNS轮询

    上一篇文章“一分钟了解负载均衡的一切”引起了不少同学的关注,评论中大家争论的比较多的一个技术点是接入层负载均衡技术,部分同学持这样的观点: 1)nginx前端加入lvs和keepalived可以替代“ ...

  7. 【58沈剑架构系列】DB主从一致性架构优化4种方法

    需求缘起 大部分互联网的业务都是“读多写少”的场景,数据库层面,读性能往往成为瓶颈.如下图:业界通常采用“一主多从,读写分离,冗余多个读库”的数据库架构来提升数据库的读性能. 这种架构的一个潜在缺点是 ...

  8. 【58沈剑架构系列】细聊分布式ID生成方法

    一.需求缘起 几乎所有的业务系统,都有生成一个记录标识的需求,例如: (1)消息标识:message-id (2)订单标识:order-id (3)帖子标识:tiezi-id 这个记录标识往往就是数据 ...

  9. KA,连接池居然这么简单? 原创: 58沈剑 架构师之路 3月20日

    KA,连接池居然这么简单? 原创: 58沈剑 架构师之路 3月20日

随机推荐

  1. Docker生产实践(六)

    镜像构建思路 思路:分层设计 最底层:系统层,构建自己适用的不同操作系统镜像: 中间层:根据运行环境,如php.java.python等,构建业务基础运行环境层镜像: 最上层:根据具体的业务模块,构建 ...

  2. Vue组件穿透

    1. element ui怎么修改单独一个label的颜色 用 >>> 进行组件的穿透

  3. java内存溢出xms xmx

    java内存堆栈不够用时我们会寻求java参数-Xms和-Xmx的帮助,网上也有许多前辈给出了例子,但很多人喜欢把-Xms和-Xmx的值设置成一样的,甚至我还见过有吧-Xms设的比-Xmx还要大(-X ...

  4. Vue入坑教程(二)——项目结构详情介绍

    之前已经介绍了关于Vue的脚手架vue-cli的安装,以及一些文件目录介绍.具体可以查看<vue 入坑教程(一)--搭建vue-cli脚手架> 下面简单说一下具体的文件介绍 (一) pac ...

  5. python3使用stmplib发送邮件

    代码如下: import smtplib from email.mime.text import MIMEText from email.header import Header from email ...

  6. highCharts使用记录

    公司的架构师让我做一个mockup,要用到highCharts,,以前想接触的,没时间学习,也没有用过,正好工作可以用上了,可以边学边做了. 环境 <script src="./js/ ...

  7. Intellij IDEA 2017 控制台打印换行

    Intellij IDEA 2017 控制台打印的内容超过屏幕宽度了,请问怎么自动换行? 记得重启idea

  8. Flash数据的采集方法-搜房房价走势采集

    一般来说flash中的数据是不能被现有技术很容易采集到的,但是也不能谈flash色变,要具体问题具体分析,有些flash是可以通过一些分析发现背后的数据.然后采集就变得很容易了. 具体案例:搜房房价走 ...

  9. 微服务深入浅出(6)-- 熔断器Hystrix

    概念 在分布式系统中,一种不可避免的情况就是某些服务会出现故障,导致依赖他们的其他服务出现远程调度的线程问题(雪崩效应).而Hystrix提供的熔断器,通过隔离服务的访问点,能阻止这种分布式系统中出现 ...

  10. tmux终端工具

    本文原始地址:http://www.cnblogs.com/chinas/p/7094172.html,转载请注明出处,谢谢!!! 1.介绍 tmux(终端复用工具):一个很有趣的工具,类似GNU S ...