RPC通信 | 青训营笔记

这是我参与「第五届青训营」伴学笔记创作活动的第 9 天，本文是课程「RPC 原理与实现」的学习笔记。

基本概念

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

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

• 一次 RPC 的完整过程

• RPC 带来的问题将由 RPC 框架来解决

  • 服务宕机如何感知？

  • 遇到网络异常应该如何应对？

  • 请求量暴增怎么处理？

RPC 框架分层设计

编解码层

• 数据格式

  • 语言特定格式：例如 java.io.Serializable
  • 文本格式：例如 JSON、XML、CSV 等
  • 二进制编码：常见有 Thrift 的 BinaryProtocol，Protobuf，实现可以有多种形式，例如 TLV 编码 和 Varint 编码

• 选型考察点

  • 兼容性

  • 通用型

  • 性能

    • 空间开销
    • 时间开销

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

协议层

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

网络通信层

• 阻塞 IO 下，耗费一个线程去阻塞在 read(fd) 去等待用足够多的数据可读并返回。

• 非阻塞 IO 下，不停对所有 fds 轮询 read(fd) ，如果读取到 n <= 0 则下一个循环继续轮询。

第一种方式浪费线程（会占用内存和上下文切换开销），第二种方式浪费 CPU 做大量无效工作。而基于 IO 多路复用系统调用实现的 Poll 的意义在于将可读/可写状态通知和实际文件操作分开，并支持多个文件描述符通过一个系统调用监听以提升性能。
网络库的核心功能就是去同时监听大量的文件描述符的状态变化(通过操作系统调用)，并对于不同状态变更，高效，安全地进行对应的文件操作。