深入浅出RPC框架(上篇)| 青训营笔记

DoerChan
1,207 阅读10分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的的第五篇笔记.

  • 本篇笔记主要分成两个部分，分别是RPC框架的基本概念，以及它的分层设计。

  • 下篇笔记将会介绍RPC的关键指标和它的企业实践

话不多说，我们开启本篇笔记~

1.基本概念

本地函数调用

image.png

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

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

RPC需要解决的问题：

image.png 1. 函数映射

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

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

2. 数据转换成字节流

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

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

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

RPC概念模型

image.png

这是理论模型

一次RPC的完整过程

image.png

  • IDL (Interface description language)文件 IDL通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信。（约定调用规范）

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

  • 生成代码 通过编译器工具把IDL文件转换成语言对应的静态库。（具体调用的时候用户代码需要依赖生成代码，所以可以把用户代码和生成代码看做一个整体）

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

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

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

服务双方是通过约定的规范进行远程调用，双方都依赖同一份IDL文件，需要通过工具来生成对应的生成文件，具体调用的时候用户代码需要依赖生成代码，所以可以把用户代码和生成代码看做一个整体。
编码只是解决了跨语言的数据交换格式，但是如何通讯呢？需要制定通讯协议，以及数据如何传输？我的网络模型如何呢？那就是这里的 transfer 要做的事情。

RPC的好处

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

RPC带来的问题

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

小结

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

2.分层设计

编解码层-以Apache Thrift为例

image.png

  • 生成代码

依赖同一份IDL文件生成不同语言的代码。

  • 数据格式
  1. 语言特定的格式

许多编程语言都内建了将内存对象编码为字节序列的支持，例如Java有java.io.Serializable （这种编码形式好处是非常方便，可以用很少的额外代码实现内存对象的保存与恢复，这类编码通常与特定的编程语言深度绑定，其他语言很难读取这种数据。如果以这类编码存储或传输数据，那你就和这门语言绑死在一起了。安全和兼容性也是问题）

  1. 文本格式

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

  1. 二进制编码

具备跨语言和高性能等优点，常见有Thrift 的BinaryProtocol, Protobuf 等 (实现可以有很多种，TLV 编码 和 Varint 编码)

  • 二进制编码

**TLV编码 **

Tag：标签，可以理解为类型

Lenght：长度 Value：值，Value也可以是个TLV结构

  • 选型 兼容性

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

通用性

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

性能

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

协议层

image.png

  • 概念 特殊结束符

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

变长协议

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

  • 协议构造

image.png

  • LENGTH(32bits):数据包大小，不包含自身长度

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

  • 协议解析

image.png

网络通信层

image.png

  • Sockets API

image.png

image.png 套接字编程中的客户端必须知道两个信息：服务器的 IP 地址，以及端口号。

socket函数创建一个套接字，bind 将一个套接字绑定到一个地址上。listen 监听进来的连接，backlog的含义有点复杂，这里先简单的描述：指定挂起的连接队列的长度，当客户端连接的时候，服务器可能正在处理其他逻辑而未调用accept接受连接，此时会导致这个连接被挂起，内核维护挂起的连接队列，backlog则指定这个队列的长度，accept函数从队列中取出连接请求并接收它，然后这个连接就从挂起队列移除。如果队列未满，客户端调用connect马上成功，如果满了可能会阻塞等待队列未满（实际上在Linux中测试并不是这样的结果，这个后面再专门来研究）。Linux的backlog默认是128，通常情况下，我们也指定为128即可。

connect 客户端向服务器发起连接，accept 接收一个连接请求，如果没有连接则会一直阻塞直到有连接进来。得到客户端的fd之后，就可以调用read, write函数和客户端通讯，读写方式和其他I/O类似

read 从fd读数据，socket默认是阻塞模式的，如果对方没有写数据，read会一直阻塞着：

write 写fd写数据，socket默认是阻塞模式的，如果对方没有写数据，write会一直阻塞着：

socket 关闭套接字，当另一端socket关闭后，这一端读写的情况：

尝试去读会得到一个EOF，并返回0。

尝试去写会触发一个SIGPIPE信号，并返回-1和errno=EPIPE，SIGPIPE的默认行为是终止程序，所以通常我们应该忽略这个信号，避免程序终止。

如果这一端不去读写，我们可能没有办法知道对端的socket关闭了。

  • 网络库 提供易用API
    • 封装底层Socket API
    • 连接管理和事件分发

功能

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

性能

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

小结

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

未完待续(To Be Continue...)

avatar
文章
阅读
粉丝