Go语言框架：深入浅出RPC框架（上）｜ 青训营

Vagabonder
71 阅读7分钟

一、基本概念

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)

RPC需要解决的问题

  • 1.函数映射
  • 2.数据转换成字节流
  • 3.网络传输

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

在本地调用中，函数体是直接通过函数指针来指定的，我们询用哪个方法，编译器就自动帮我们询用它相应的函数指针。但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以函数都有自己的一个ID，在做RPC的时候要附上这个ID，还得有个ID和函数的对照关系表，通过ID找到对应的函数并执行。 在本地调用中，我们只需要把参数压到找里，然后让函数自己去找里读就行。 但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来 传递参数。这时候就需要客户端把参数先转成一个字节流， 传给服务端后，再把字节流转成自已能读取的格式。 远程调用往往用在网络上，如何保证在网络上高效稳定地传输数据?

1.3 RPC概念模型

1984年Nelson发表了论文<Implementing Remote Procedure Calls》，其中提出了RPC的过程由5个模型 组成: User、User-Stub、 RPC-Runtime、 Server-Stub、 Server

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.请求量突增导致服务无法及时处理，有哪些应对措施?

1.7 小结

    1. 本地函数调用和RPC调用的区别:函数映射、数据转成字节流、网络传输
    1. RPC的概念模型: User、User- Stub、RPC- Runtime、Server- Stub、Server
    1. 一次PRC的完整过程，并讲解了RPC的基本概念定义
    1. RPC带来好处的同时也带来了不少新的问题，将由RPC框架来解决

二、分层设计

2.1 分层设计一以Apache Thrift为例

image.png

2.2 编解码层

image.png

2.3 编解码层一生成代码

image.png

2.4 编解码层-数据格式

  • 语言特定的格式

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

  • 文本格式

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

  • 二进制编码

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

  • 语言特定编码格式:这种编码形式好处是非常方便，可以用很少的额外代码实现内存对象的保存与恢复，这类编码通常与特定的编程语言深度绑定，其他语言很难读取这种数据。如果以这类编码存储或传输数据，那你就和这门语言绑死在一起了。安全和兼容性也是问题
  • 文本格式:文本格式具有人类可读性，数字的编码多有歧义之处， 比如XML和CSV不能区分数字和字符串，JSON虽然区分字符串和数字，但是不区分 整数和浮点数，而且不能指定精度，处理大量数据时，这个问题更严重了; 没有强制模型约束，实际操作中往往只能采用文档方式来进行约定，这可能会给调试带来一些不便。 由于ISON在一些语言中的序列化和反序列化需要采用反射机制，所以在性能比较差;
  • 二进制编码: 实现可以有很多种，TLV 编码和Varint编码

2.5 编解码层-二进制编码

TLV编码

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

2.6 编解码层-选型

  • 兼容性 支持自动增加新的字段，而不影响老的服务，这将提高系统的灵活度
  • 通用性 支持跨平台、跨语言
  • 性能 从空间和时间两个维度来考虑，也就是编码后数据大小和编码耗费时长
  • 通用性: 通用生有两个层面的意义:

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

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

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

第一、空间开销(Verbosity) 序列化需要在原有的数据上加上描述字段，以为反序列化解析之用。如果序列化过程引入的额外开销过高，可能会导致过大的网络，磁盘等各方面的压力:对于海量分布式存储系统，数据量往往以TB为单位，巨大的的额外空间开销意味着高昂的成本。

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

2.7 协议层

image.png

2.8 协议层

  • 特殊结束符 一个特殊字符作为每 个协议单元结束的标示

image.png

  • 变长协议 以定长加不定长的部分组成，其中定长的部分需要描述不定长的内容长度

image.png

  • 协议是双方确定的交流语义，比如:我们设计一个字符串传输的协议，它允许客户端发送一个字符串， 服务端接收到对应的字符串。这个协议很简单，首先发送一个4字节的消息总长度，然后再发送1字节的字符集charset长度，接下来就是消息的payload,字符集名称和字符串正文。
  • 特殊结束符:过于简单，对于一个协议 单元必须要全部读入才能够进行处理，除此之外必须要防止用户传输的数据不能同结束符相同，否则就会出现紊乱 HTTP协议头就是以回车(CR)加换行(LF)符号序列结尾。
  • 变长协议:一般都是自定义协议，有header 和payload组成，会以定长加不定长的部分组成，其中定长的部分需要描述不定长的内容长度，使用比较广泛

2.9 协议层-协议构造

image.png

  • LENGTH:数据包大小，不包含自身
  • HEADER MAGIC:标识版本信息，协议解析时候快速校验
  • SEQUENCE NUMBER:表示数据包的seqlD,可用于多路复用，单连接内递增
  • HEADER SIZE:头部长度，从第14个字节开始计算一直到PAYLOAD前
  • PROTOCOL ID:编解码方式，有Binary和Compact两种
  • TRANSFORM ID:压缩方式，如zlib 和snappy
  • INFOID:传递一些定制的meta信息
  • PAYLOAD:消息体

2.10 协议层-协议解析

image.png

2.11 网络通信层

image.png

2.12 网络通信层- Sockets API

  • 套接字编程中的客户端必须知道两个信息:服务器的IP地址，以及端口号。
  • socke:函数创建一个 套接字，bind将一个 套接字绑定到一个地址上。listen监听进来的连接，backlog的含 义有点复杂，这里先简单的描述:指定挂起的连接 队列的长度，当客户端连接的时候，服务器可能正在处理其他逻辑而未调用acceo接受连接，此时会导致这个连接被挂起，内核维护挂起的连接队列， backlog则指定这个队列的长度，accept丞数从队列中取出连接请求并接收它，然后这个连接就从挂起队列移除。如吴队列未满，客户端调用connect马 上成 功，如果满了可能会阻塞等待队列未满(实际上在Linux中测试并不是这样的结美，这个后面再专门来研究) : Linux的backlog默认是128， 通常情况下，我 们也指定为128即可。
  • connect客户端向服务器发起连接，acceo:接收一 一个连接请求，如果没有连接则会一直阻塞直到有连接进来。 得到客户端的fd之后，就可以调用read. write函数和客户端通讯，读写方式和其他I/O类似
  • read从fd读数据，socket默认 是阻塞模式的，如果对方没有写数据，read会一 直阻塞着: write写fd写数据，socket默认是阻塞模式的，如果对方没有写数据，write会一直阻塞着: socke:关闭套接字，当另一端socke:关闭后， 这一端读写的情况:
  • 尝试去读会得到一个EOF，并返回0。 尝讨去写会触发一个SIGPIPE信号，并返回-1和erno=EPIPE， SIGPIPE的默认行为是终止程序， 所以通常我们应该忽略这个信号，避免程序终止。 如果这一端不去读写，我们可能没有办法知道对端的socke:关闭了。

2.13 网络通信层-网络库

提供易用API

  • 封装底层Socket API
  • 连接管理和事件分发

功能

  • 协议支持: tcp. udp和uds等
  • 优雅退出、异常处理等

性能

  • 应用层buffer减少copy
  • 高性能定时器、对象池等

2.14 小结

    1. RPC框架主要核心有三层:编解码层、协议层和网络通信层
    1. 二进制编解码的实现原理和选型要点
    1. 协议的一般构造，以及框架协议解析的基本流程
    1. Socket API的调用流程，以及选型网络库时要考察的核心指标
avatar
文章
阅读
粉丝