day08深入浅出RPC框架 ｜ 青训营

timo队长
58 阅读9分钟

01.基本概念

1.1 本地函数调用

func main( ){
 var a = 2
 var b = 3
 result := calculate(a, b)
 fmt.Println(result)
 return
}
func calculate(x, y int) {
 z := x*y
 return z
}

复制

  1. 将a和b的值压栈
  2. 通过函数指针找到calculate函数，进入函数取出栈中的值2和3，将其赋予x和y
  3. 计算x*y，并将结果存在z
  4. 将Z的值压栈，然后从calculate返回
  5. 从栈中取出z返回值，并赋值给result

以上步骤只是为了说明原理。事实上编译器经常会做优化，对于参数和返回值少的情况会直接将其存放在寄存器，而不需要压栈弹栈的过程，甚至都不需要调用call，而直接做inline操作。

1.2远程函数调用(RPC - Remote Procedure Calls)

函数映射

我们怎么告诉支付服务我们要调用付款这个函数，而不是退款或者充值呢？

  • 在本地调用中，函数体是直接通过函数指针来指定的，我们调用哪个方法，编译器就自动帮我们调用它相应的函数指针。
  • 但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以函数都有自己的一个ID，在做 RPC的时候要附上这个 ID，还得有个 ID 和函数的对照关系表，通过 ID找到对应的函数并执行。

客户端怎么把参数值传给远程的函数呢？

  • 在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。
  • 但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。

远程调用往往用在网络上，如何保证在网络上高效稳定地传输数据？

1.3 RPC概念模型

理解RPC调用的完整过程

1.4 一次RPC的完整过程

IDL (Interface description language)文件

  • IDL通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信

生成代码

  • 通过编译器具把IDL文件转换成语言对应的静态库

编解码

  • 从内存中表示到字节序列的转换称为编码，反之为解码，也常叫做序列化和反序列化

通信协议

  • 规范了数据在网络中的传输内容和格式。除必须的请求/响应数据外，通常还会包含额外的元数据

网络传输

  • 通常基于成熟的网络库走TCP/UDP传输

相比本地函数调用，远程调用的话我们不知道对方有哪些方法，以及参数长什么样，所以需要有一种方式来描述或者说声明我有哪些方法，方法的参数都是什么样子的，这样的话大家就能按照这个来调用，这个描述文件就是 IDL 文件。

服务双方是通过约定的规范进行远程调用，双方都依赖同一份IDL文件，需要通过工具来生成对应的生成文件，具体调用的时候用户代码需要依赖生成代码，所以可以把用户代码和生成代码看做一个整体。

编码只是解决了跨语言的数据交换格式，但是如何通讯呢？需要制定通讯协议，以及数据如何传输？我的网络模型如何呢？那就是这里的 transfer 要做的事情。

1.5 RPC的好处

  1. 单一职责，有利于分工协作和运维开发
  2. 可扩展性强，资源使用率更优
  3. 故障隔离，服务的整体可靠性更高

单一职责，开发（采用不同的语言）、部署以及运维（上线独立）都是独立的。

可扩展性强，例如压力过大的时候可以独立扩充资源，底层基础服务可以复用，节省资源某个模块发生故障，不会影响整体的可靠性。

1.6 RPC带来的问题

  1. 服务宕机，对方应该如何处理?
  2. 在调用过程中发生网络异常，如何保证消息的可达性?
  3. 请求量突增导致服务无法及时处理，有哪些应对措施?

02 分层设计

编解码层 | 协议层 | 网络通信层

2.1分层设计-以Apache Thrift为例

2.2 编解码层-生成代码

2.3 编解码层-数据格式

语言特定的格式

  • 许多编程语言都内建了将内存对象编码为字节序列的支持，例如Java有java.io.Serializable

文本格式

  • JSON、XML、 CSV 等文本格式，具有人类可读性

二进制编码

  • 具备跨语言和高性能等优点，常见有Thrift 的BinaryProtocol, Protobuf 等

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

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

二进制编码：实现可以有很多种，TLV 编码 和 Varint 编码

2.5 编解码层-二进制编码

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

2.6 编解码层-选型

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

  • 第一、技术层面，序列化协议是否支持跨平台、跨语言。如果不支持，在技术层面上的通用性就大大降低了。
  • 第二、流行程度，序列化和反序列化需要多方参与，很少人使用的协议往往意味着昂贵的学习成本；另一方面，流行度低的协议，往往缺乏稳定而成熟的跨语言、跨平台的公共包。

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

性能：

  • 第一、空间开销（Verbosity）， 序列化需要在原有的数据上加上描述字段，以为反序列化解析之用。如果序列化过程引入的额外开销过高，可能会导致过大的网络，磁盘等各方面的压力。对于海量分布式存储系统，数据量往往以TB为单位，巨大的的额外空间开销意味着高昂的成本。
  • 第二、时间开销（Complexity），复杂的序列化协议会导致较长的解析时间，这可能会使得序列化和反序列化阶段成为整个系统的瓶颈。

2.8 协议层-概念

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

特殊结束符：过于简单，对于一个协议单元必须要全部读入才能够进行处理，除此之外必须要防止用户传输的数据不能同结束符相同，否则就会出现紊乱 HTTP 协议头就是以回车(CR)加换行(LF)符号序列结尾。

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

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 消息内容

2.10 协议层-协议解析

avatar
文章
阅读
粉丝