RPC框架学习笔记 | 青训营笔记

赚夯大户
85 阅读10分钟

这是我参与「第五届青训营」伴学笔记创作活动的第 14 天。

本节课简述了 RPC 的基本概念和模型。在分布式计算中，远程过程调用 （RPC） 是指计算机程序导致过程（子例程）在不同的地址空间（通常在共享网络上的另一台计算机上）中执行，其编码就像普通（本地）过程调用一样，程序员没有显式编码远程交互的详细信息。也就是说，程序员编写的代码基本相同，无论子例程是执行程序的本地还是远程的。这是客户端-服务器交互的一种形式（调用方是客户端，执行者是服务器），通常通过请求-响应消息传递系统实现。

基本概念

相比本地函数调用，RPC调用需要解决的问题

  • 函数映射：

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

  • 数据转换成字节流：

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

  • 网络传输

RPC模型

1984 年由 Nelson 发表的论文《Implementing remote procedure calls》提出 RPC 的过程由 5 个模型组成：User、User-stub、RPCRuntime、Server-stub、Server。

User 通过发起本地函数调用，由 User-stub 将函数参数包装并由 RPCRuntime 发送给被调用方，被调用方的 RPCRuntime 接受数据后，由 Server-stub 解包装参数到服务器，服务器处理后再以相同方式将数据数据返回给 User，完成一次 RPC 调用。

一次完整的RPC调用：

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

生成代码：通过编译器工具把 IDL 文件转换成语言对应的静态库 

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

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

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

RPC的优劣

好处：

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

问题：

  1. 目标服务宕机的处理问题
  2. 调用过程中网络异常导致的消息可达性
  3. 请求量突增导致服务无法及时处理

分层设计

编解码层

  • 数据格式

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

  • 选型考察点

    • 兼容性：支持自动增加新的字段，而不影响老的服务，这将提高系统的灵活度。

    • 通用型：支持跨平台、跨语言。

    • 性能：从空间和时间两个维度来考虑，也就是编码后数据大小和编码耗费时长。

  • 生成代码和编解码层相互依赖，框架的编解码应当具备扩展任意编解码协议的能力

协议层

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

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

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

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

  • 以 Thrift 的 THeader 协议为例

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

  • 协议解析

网络通信层

套接字编程中的客户端必须知道两个信息：服务器的 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 AP连接管理和事件分发 

  • 功能 

  • 协议支持: tcp、udp 和 uds 等

  • 优雅退出、异常处理等 

  • 性能 

  • 应用层 buffer 减少 copy 

  • 高性能定时器、对象池等

关键指标

稳定性

保障策略

熔断：

一个服务 A 调用服务 B 时，服务 B 的业务逻辑又调用了服务 C，而这时服务 C 响应超时了，由于服务 B 依赖服务 C，C 超时直接导致 B 的业务逻辑一直等待，而这个时候服务 A 继续频繁地调用服务 B，服务 B 就可能会因为堆积大量的请求而导致服务宕机，由此就导致了服务雪崩的问题。

限流：

当调用端发送请求过来时，服务端在执行业务逻辑之前先执行检查限流逻辑，如果发现访问量过大并且超出了限流条件，就让服务端直接降级处理或者返回给调用方一个限流异常。

超时：

当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，避免浪费资源。

请求成功率

  • 负载均衡
  • 重试

长尾请求

  • BackupRequest

易用性

  • 开箱即用

    • 合理的默认参数选项、丰富的文档

  • 周边工具

    • 生成代码工具、脚手架工具

扩展性

  • Middleware：middleware 会被构造成一个有序调用链逐个执行，比如服务发现、路由、负载均衡、超时控制等

  • Option：作为初始化参数

  • 核心层是支持扩展的：编解码、协议、网络传输层

  • 代码生成工具也支持插件扩展

观测性

  • 三件套：Log、Metric 和 Tracing

  • 内置观测性服务，用于观察框架内部状态

    • 当前环境变量
    • 配置参数
    • 缓存信息
    • 内置 pprof 服务用于排查问题

高性能

  • 连接池和多路复用：复用连接，减少频繁建联带来的开销

  • 高性能编解码协议：Thrift、Protobuf、Flatbuffer 和 Cap'n Proto 等

  • 高性能网络库：Netpoll 和 Netty 等

avatar
文章
阅读
粉丝