服务化有什么好处? 服务化的一个好处就是,不限定服务的提供方使用什么技术选型,能够实现大公司跨团队的技术解耦,如下图所示:

整个二进制字节流共12292724=92字节。 实际的序列化协议要考虑的细节远比这个多,例如:强类型的语言不仅要还原属性名,属性值,还要还原属性类型;复杂的对象不仅要考虑 普通类型,还要考虑对象嵌套类型等。无论如何,序列化的思路都是类似的。 序列化协议要考虑什么因素? 不管使用成熟协议xml/json,还是自定义二进制协议来序列化对象,序列化协议设计时都需要考虑以下这些因素。

这两类调用,在RPC-client里,实现方式完全不一样。 RPC-client同步调用架构如何?

规定好转换规则,发送方很容易把User类的一个对象序列化为xml,服务方收到xml二进制流之后,也很容易将其范序列化为User对象。 画外音:语言支持反射时,这个工作很容易。 第二个方法是自己实现二进制协议来进行序列化,还是以上面的User对象为例,可以设计一个这样的通用协议:

序号后面的4个字节表示key的长度m 接下来的m个字节表示key的值 接下来的4个字节表示value的长度n 接下来的n个字节表示value的值 像xml一样递归下去,直到描述完整个对象

服务调用方client感觉就像调用本地函数一样,来调用服务 服务提供方server感觉就像实现一个本地函数一样,来实现服务

所以整个RPC框架又分为client部分与server部分,实现上面的目标,把复杂性屏蔽,就是RPC框架的职责。 如上图所示,业务方的职责是:

数据库索引的磁盘存储:数据库的索引在内存里是b树,但这个格式是不能够直接存储到磁盘上的,所以需要把b树转化为连续空间的二进制字节流,才能存 储到磁盘上 缓存的KV存储:redis/memcache是KV类型的缓存,缓存存储的value必须是连续空间的二进制字节流,而不能够是User对象 数据的网络传输:socket发送的数据必须是连续空间的二进制字节流,也不能是对象

这一部分,又分为同步调用与异步调用两种方式,下面一一来进行介绍。 画外音:搞通透RPC-client确实不容易。 同步调用的代码片段为:

解析效率:这个应该是序列化协议应该首要考虑的因素,像xml/json解析起来比较耗时,需要解析doom树,二进制自定义协议解析起来效率就很高 压缩率,传输有效性:同样一个对象,xml/json传输起来有大量的xml标签,信息有效性低,二进制自定义协议占用的空间相对来说就小多了 扩展性与兼容性:是否能够方便的增加字段,增加字段后旧版客户端是否需要强制升级,都是需要考虑的问题,xml/json和上面的二进制协议都能够方便的扩展 可读性与可调试性:这个很好理解,xml/json的可读性就比二进制协议好很多 跨语言:上面的两个协议都是跨语言的,有些序列化协议是与开发语言紧密相关的,例如dubbo的序列化协议就只能支持Java的RPC调用 通用性:xml/json非常通用,都有很好的第三方解析库,各个语言解析起来都十分方便,上面自定义的二进制协议虽然能够跨语言,但每个语言都要写一个简易 的协议客户端

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结果,工作线程继续往下走; 画外音:请对照架构图中的1-10步骤阅读。 连接池组件有什么作用?

所谓序列化(Serialization),就是将“对象”形态的数据转化为“连续空间二进制字节流”形态数据的过程。这个过程的逆过程叫做反序 列化。 怎么进行序列化? 这是一个非常细节的问题,要是让你来把“对象”转化为字节流,你会怎么做?很容易想到的一个方法是xml(或者json)这类具有自描述 特性的标记性语言:

第一行:序号4个字节(设0表示类名),类名长度4个字节(长度为4),接下来4个字节是类名(”User”),共12字节 第二行:序号4个字节(1表示第一个属性),属性长度4个字节(长度为9),接下来9个字节是属性名(”user_name”),属性值长度4个字节(长度为8),属 性值8个字节(值为”shenjian”),共29字节 第三行:序号4个字节(2表示第二个属性),属性长度4个字节(长度为7),接下来7个字节是属性名(”user_id”),属性值长度4个字节(长度为8),属性 值8个字节(值为123),共27字节 第四行:序号4个字节(3表示第三个属性),属性长度4个字节(长度为8),接下来8个字节是属性名(”user_name”),属性值长度4个字节(长度为4),属 性值4个字节(值为35),共24字节

RPC框架锁支持的负载均衡、故障转移、发送超时等特性,都是通过连接池组件去实现的。 典型连接池组件对外提供的接口为:

但当需要对数据进行存储或者传输时,“对象”就不这么好用了,往往需要把数据转化成连续空间的“二进制字节流”,一些典型的场景 是:

这4个步骤是: (1)将传入参数变为字节流; (2)将字节流发给服务B; (3)从服务B接受返回字节流; (4)将返回字节流变为传出参数; 服务方的代码可能变为:

这三个动作,都发生在同一个进程空间里,这是本地函数调用。 那有没有办法,调用一个跨进程的函数呢? 典型的,这个进程部署在另一台服务器上。

这个5个步骤也很好理解: (1)服务端收到字节流; (2)将字节流转为函数名与参数; (3)本地调用函数得到结果; (4)将结果转变为字节流; (5)将字节流发送给调用方; 这个过程用一张图描述如下:

调用方与服务方的处理步骤都是非常清晰。 这个过程存在最大的问题是什么呢? 调用方太麻烦了,每次都要关注很多底层细节:

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

左边大框,代表了调用方的一个工作线程 左边粉色中框,代表了RPC-client组件 右边橙色框,代表了RPC-server 蓝色两个小框,代表了同步RPC-client两个核心组件,序列化组件与连接池组件 白色的流程小框,以及箭头序号1-10,代表整个工作线程的串行执行步骤:

调用方A,传入参数,执行调。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注