第十三节：深入浅出RPC框架

Zora
160 阅读8分钟

1. 概述

本节课程主要分为四个方面：

  1. RPC 相关的基本概念
  1. RPC 框架的分层设计
  1. 衡量 RPC 框架的一些核心指标
  1. 字节内部 RPC 框架 Kitex 实践分享

课前部分主要罗列课程中涉及到的概念。对于不熟悉的概念，同学们可以提前查询预习；

课中部分主要罗列每一部分的关键思路，帮助同学们跟上课程的进度；

课后部分是一些问题，帮助同学们在课后梳理本课程的重点。

2. 课前

2.1 RPC 的基本概念

  • IDL(Interface Definition Language) 文件

    • Thrift
    • Protobuf
  • 生成代码
  • 编解码（序列化/反序列化）

  • 通信协议

    • 应用层协议

  • 网络通信

    • IO 网络模型

      • blocking IO
      • unblocking IO
      • IO multiplexing
      • signal driven IO
      • asynchronous IO

    • 传输层协议

      • TCP
      • UDP

2.2 RPC 框架分层设计

  • 编解码层

    • 数据格式：

      • 语言特定格式

      • 文本格式

      • 二进制编码

        • TLV 编码：Thrift 使用 TLV 编码
        • Varint 编码：Protobuf 使用 Varint 编码

    • 选项：

      • 兼容性
      • 通用型
      • 性能

  • 传输协议层

    • 消息切分

      • 特殊结束符
      • 变长协议：length+body

    • 协议构造

      • 以 Thrift 的 THeader 协议为例讲解

  • 网络通信层

    • 网络库

    • 核心指标

      • 吞吐高
      • 延迟低

2.3 RPC 框架的核心指标

  • 稳定性

    • 保障策略

      • 熔断
      • 限流
      • 超时

    • 请求成功率

      • 负载均衡
      • 重试

    • 长尾请求

      • BackupRequest

  • 易用性

    • 开箱即用
    • 周边工具
  • 扩展性

  • 观测性

    • Log
    • Metric
    • Tracing
    • 内置观测性服务
  • 高性能

2.4 字节内部 Kitex 实践分享

  • 合并部署

3. 课中

3.1 基本概念

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

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

  • PRC需要解决的问题

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

  • RPC概念模型

image.png

  • 一次 RPC 的完整过程
    • IDL（Interface description language）文件
      • IDL 通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信
    • 生成代码
      • 通过编译器工具把IDL文件转换成语言对应的静态库
    • 编解码
      • 从内存中的表示到字节序列的转换成为编码，反之为解码，也常叫做序列化和反序列化
    • 通信协议
      • 规范了数据在网络中的传输内容和格式。除必须的请求/相应数据外，通常还会包含额外的元数据。
    • 网络传输
      • 通常基于成熟的网络库走TCP/UDP传输

image.png

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

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

    • 服务宕机如何感知？
    • 遇到网络异常应该如何应对？
    • 请求量暴增怎么处理？

3.2 RPC 框架分层设计

编解码->协议层->网络通信层

3.2.1 编解码层

  • 数据格式

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

image.png

  • 选型考察点

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

    • 通用型（支持跨平台、跨语言）

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

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

3.2.2 协议层

  • 概念

    • 特殊结束符：一个特殊符号作为每个协议单元结束的标示
    • 变长协议：以定长加不定长的部分组成，其中定长的部分需要描述不定长的内容长度

  • 以 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 消息内容
  • 协议解析

3.2.3 网络通信层

image.png

  • 网络库
    • 提供易用API
      • 封装底层Socket API
      • 连接管理和事件分发
    • 功能
      • 协议支持：tcp、udp和uds
      • 优雅退出、异常处理
    • 性能
      • 应用层buffer减少copy
      • 高性能定时器、对象池等

  • 阻塞 IO 下，耗费一个线程去阻塞在 read(fd) 去等待用足够多的数据可读并返回。
  • 非阻塞 IO 下，不停对所有 fds 轮询 read(fd) ，如果读取到 n <= 0 则下一个循环继续轮询。

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

3.3 RPC 框架核心指标

3.3.1 稳定性

  • 保障策略

    • 熔断：保护调用方，防止被调用的服务出现问题而影响整个链路
    • 限流：保护被调用方，防止大流量把服务压垮
    • 超时控制：避免浪费资源在不可用的节点上

从某种程度上讲超时、限流和熔断也是一种服务降级的手段 。

image.png

  • 请求成功率

    • 负载均衡
    • 重试

  • 长尾请求

    • BackupRequest

  • 注册中间件

image.png

3.3.2 易用性

  • 开箱即用

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

  • 周边工具

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

3.3.3 扩展性

  • Middleware：middleware 会被构造成一个有序调用链逐个执行，比如服务发现、路由、负载均衡、超时控制等
  • Option：作为初始化参数
  • 核心层是支持扩展的：编解码、协议、网络传输层
  • 代码生成工具也支持插件扩展

3.3.4 观测性

  • 三件套：Log、Metric 和 Tracing

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

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

3.3.5 高性能

  • 连接池和多路复用：复用连接，减少频繁建联带来的开销
  • 高性能编解码协议：Thrift、Protobuf、Flatbuffer 和 Cap'n Proto 等
  • 高性能网络库：Netpoll 和 Netty 等

image.png

3.4 字节内部 Kitex 实践分享

  1. 框架文档 Kitex

image.png

  1. 自研网络库 Netpoll，背景：

    a. 原生库无法感知连接状态：在使用连接池时，池中存在失效连接，影响连接池的复用

    b. 原生库存在 goroutine 暴涨的风险：一个连接一个goroutine的模式，由于连接利用率的低下，存在goroutine占用调度开销，影响性能

  • Netpoll
    • 解决无法感知连接状态问题
      • 引入epoll主动监听机制，感知连接状态
    • 解决goroutine暴涨的风险
      • 建立gotoutine池，复用goroutine
    • 提升性能
      • 引入Nocopy Buffer，向上层提供NoCopy的调用接口，编码器层面零拷贝
  1. 扩展性：支持多协议，也支持灵活的自定义协议扩展

image.png

  1. 性能优化，参考 字节跳动 Go RPC 框架 KiteX 性能优化实践

    a. 网络优化

    i.  调度优化  
    - epoll_wait在调度上的控制
    - gopool重用goroutine降低同时运行协程数
ii.  LinkBuffer 减少内存拷贝，从而减少 GC  
    - 读写并行无锁，支持nocopy地流式读写
    - 高效扩缩容
    - Nocopy Buffer池化，减少GC
iii.  引入内存池和对象池，减少GC开销

    b. 编解码优化

  • i. Codegen：预计算提前分配内存，inline，SIMD等
  • ii. JIT：无生产代码，将编译过程移到了程序的加载（或首次解析）阶段，可以一次性编译生成对应的 codec 并高效执行

  1. 合并部署

    a. 微服务过微，引入的额外的传输和序列化开销越来越大
    b. 将强依赖的服务统计部署，有效减少资源消耗

4. 课后

  1. 行业内各个流行的 RPC 框架的优劣对比
  1. 从第三章节 RPC 的核心指标来看，Kitex 还有哪些功能是欠缺或者需要加强的？
  1. 了解微服务的新趋势 ServiceMesh，以及 RPC 框架和 ServiceMesh 的关系
  1. 关于 RPC 框架，业界有哪些新的趋势和概念？
  1. Netpoll 的优势在哪？相比其他高性能网络库例如 Netty 还有什么不足？
  1. Flatbuffer 和 Cap'n Proto 等编解码协议为什么高性能？

5. 参考文献

  1. 官方文档 Kitex Netpoll
  1. 字节跳动 Go RPC 框架 KiteX 性能优化实践_架构_字节跳动技术团队_InfoQ精选文章
  1. 字节跳动微服务架构体系演进_架构_字节跳动技术团队_InfoQ精选文章
avatar
文章
阅读
粉丝