深入浅出 RPC 02 | 青训营

84 阅读5分钟

02分层设计

2.1 分层设计— 以Apache Thrift为例

Code 是用户自己编写的逻辑代码 不在框架范畴;

2.2 编解码层

生成代码也是编解码层的一部分

2.3 编解码层—生成代码

2.4 编解码层—数据格式

语言特定编码格式:

这种编码形式 好处 是非常方便,可以用很少的额外代码实现内存对象的保存与恢复,这类编码通常与特定的编程语言深度绑定,其他语言很难读取这种数据。 ​ 如果以这类编码存储或传输数据,那你就和这门语言绑死在一起了。安全和兼容性也是问题

文本格式:

文本格式具有人类可读性,数字的编码多有歧义之处,比如XML和CSV不能区分数字和字符串,JSON虽然区分字符串和数字,但是不区分整数和浮点数,而且不能指定精度,处理大量数据时,这个问题更严重了; ​ 没有强制模型约束,实际操作中往往只能采用文档方式来进行约定,这可能会给调试带来一些不便。 由于JSON在一些语言中的序列化和反序列化需要采用反射机制,所以性能比较差;

二进制编码:

实现可以有很多种,TLV 编码 和 Varint 编码

image-20230606123720165

2.5 编解码层—二进制编码

这里我们可以看到他的第一个byte是类型,主要用来表示是string还是int还是list等等。

这里不写key的字符串了,比如上面的userName,favoriteNumber等等, 取而代之的是一个field tag的东西,这个会设置成1,2,3和上面的schema中key字符串前面的数字,也就是用这里来取代了具体的key值,从而减小的总体的大小, 这里打包后压缩到 59个字节 TLV编码结构简单清晰,并且扩展性较好,但是由于增加了Type和Length两个冗余信息,有额外的内存开销,特别是在大部分字段都是基本类型的情况下有不小的空间浪费。

image-20230606124331594

2.6 编解码层— 选型

兼容性:

移动互联时代,业务系统需求的更新周期变得更快,新的需求不断涌现,而老的系统还是需要继续维护。如果序列化协议具有良好的可扩展性,支持自动增加新的业务字段,而不影响老的服务,这将大大提供系统的灵活度。

通用性有两个层面的意义:

第一、技术层面,序列化协议是否支持跨平台、跨语言。 如果不支持,在技术层面上的通用性就大大降低了。

第二、流行程度,序列化和反序列化需要多方参与,很少人使用的协议往往意味着昂贵的学习成本;另一方面,流行度低的协议,往往缺乏稳定而成熟的跨语言、跨平台的公共包。

性能:

 第一、空间开销(Verbosity),
      序列化需要在原有的数据上加上描述字段,为反序列化解析之用。如果序列化过程引入的额外开销过高,可能会导致过大的网络,磁盘等各方面的压力。

对于海量分布式存储系统,数据量往往以TB为单位,巨大的的额外空间开销意味着高昂的成本。

 第二、时间开销(Complexity),复杂的序列化协议会导致较长的解析时间,这可能会使得序列化和反序列化阶段成为整个系统的瓶颈。

image-20230606125615560

2.7 协议层 TTransport

2.8 协议层— 概念

协议是双方确定的交流语义,比如:我们设计一个字符串传输的协议,它允许客户端发送一个字符串,服务端接收到对应的字符串。 ​ 这个协议很简单,首先发送一个4字节的消息总长度,然后再发送1字节的字符集charset长度,接下来就是消息的payload,字符集名称和字符串正文。

特殊结束符:过于简单,对于一个协议单元必须要全部读入才能够进行处理,除此之外必须要防止用户传输的数据不能同结束符相同,否则就会出现紊乱

HTTP 协议头就是以回车(CR)加换行(LF)符号序列结尾。

变长协议:一般都是自定义协议,有 header 和 payload 组成,会以定长加不定长的部分组成,其中定长的部分需要描述不定长的内容长度,使用比较广泛

image-20230606130157324

2.9 协议构造

LENGTH 字段 32bits,包括数据包剩余部分的字节大小,不包含 LENGTH 自身长度

HEADER MAGIC 字段16bits,值为:0x1000,用于标识 协议版本信息,协议解析的时候可以快速校验 FLAGS 字段 16bits,为预留字段,暂未使用,默认值为 0x0000

SEQUENCE NUMBER 字段 32bits,表示数据包的 seqId,可用于多路复用,最好确保单个连接内递增

HEADER SIZE 字段 16bits,等于头部长度 字节数/4,头部长度计算从第14个字节开始计算,一直到 PAYLOAD 前(备注:header 的最大长度为 64K)

PROTOCOL ID 字段 uint8 编解码方式, 取值有:~ ProtocolIDBinary = 0 ProtocolIDCompact = 2 这两种

NUM TRANSFORMS 字段 uint8 编码,表示 TRANSFORM 个数

TRANSFORM ID 字段 uint8 编码,具体取值参考下文,表示压缩方式 zlib or snappy

INFO ID 字段 uint8 编码,具体取值参考下文,用于传递一些定制的 meta 元数据 信息

PAYLOAD 消息内容

image-20230606130322337