【字节跳动】第十三讲 深入浅出RPC框架｜ 青训营笔记

讲师介绍：

江学武：目前就职于字节跳动基础架构服务框架团队，参与Kitex和ByteMesh的研发工作。

目录

1. 基本概念
2. 分层设计
3. 关键指标
4. 企业实践

1. 基本概念

1.1 本地函数调用

func main() {
   var a = 2
   var b = 3
   result := calculate(a, b)
   fmt.Println(result)
   return
}

func calculate(x, y int) 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

1.2 远程函数调用（RPC-Remote Procedure Calls）

RPC 需要解决的问题

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

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传输

1.5 RPC的好处

1. 单一职责，有利于分工协作和运维开发
   1. 可以采用不同的语言进行开发，部署运维上线都是独立的。可以不同的团队进行维护
2. 可扩展性强，资源使用率更优
   1. 压力大的时候可以独立扩充资源。例如，双十一的时候只需要对直播间购物的进行扩容就可以。整体来说就是资源利用率会更高
3. 故障隔离，服务的整体可靠性更高
   1. 某一个服务崩溃不会造成整体进行崩溃。

1.6 RPC带来的问题

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

1.7 总结

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

2. 分层设计

分为三层：编解码层、协议层、网络通信层

2.1 分层设计-以Apache Thrift为例

2.2 编解码层

2.3 编解码层-生成代码

2.4 编解码层-数据格式

• 语言特定的格式（优点：非常方便可以用额外很少的代码实现内存对象的保存和恢复。缺点：因为是和语言进行绑定的所以每个语言间的兼容性是一个问题。）
  • 许多编码语言都内建了将内存对象编码为字节序列的支持，例如 Java 有 java.io.Serializable
• 文本格式（例如json格式只有字符串和整型类型，不能处理浮点数的类型，对于处理大量数据问题就很严重，并且没有产品的模型约束，只有文档约束，调试起来不方便）
  • JSON、XML、CSV等文本格式，具有人类可读性
• 二进制编码（指将数据转换成二进制流，实现方式有tlv编码等）
  • 具备跨语言和高性能等优点，常见有Thrift的BinaryProtocol，Protobuf等

2.5 编解码层 - 二进制编码

TLV 编码

• Tag：标签，可以理解为类型
• Lenght：长度
• Value：值，Value也可以是个TLB结构

2.6 编解码层-选型

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

2.7 协议层

2.8 协议层-概念

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

14.png

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

15.png

2.9 协议层-协议构造

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

16.png

2.10 协议层-协议解析

17.png

一个简单的协议解析过程

2.11 网络通信层

18.png

2.12 网络通信层-Sockets API

19.png

20.png

2.13 网络通信层-网络库

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

2.14 小结

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

3. 关键指标

主要五个方面：稳定性、易用性、扩展性、观测性、高性能

3.1 稳定性-保障策略

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

21.png

3.2 稳定性-请求成功率

负载均衡（不至于其中一个服务压力过大而崩溃，从而提高成功率）

22.png

重试（增加成功率）

23.png

3.3 稳定性-长尾请求

Backup Request

24.png

t1+t2=总用时（增加了总时间）

25.png

只请求一次，过t3时后再一次请求返回代表上一次在等待并且上一次可以成功，所以总时间为t4，是一个针对长尾请求的处理。

pc99是什么？网上并没有查到有关信息

3.4 稳定性-注册中间件

26.png

3.5 易用性

27.png

• 开箱即用
  • 合理的默认参数选项、丰富的文档
• 周边工具
  • 生成代码工具、脚手架工具

28.png

3.6 扩展性

• Middleware
• Option
• 编解码层
• 协议层
• 网络传输层
• 代码生成工具插件扩展

29.png

3.7 观测性

• Log、Metric、Tracing
• 内置观测性服务

30.png

查看操作系统耗费资源工具（Linux top分析工具）

3.8 高性能

• 场景：单机多机、单连接多连接、单/多client 单/多 server、不同大小的请求包、不同请求类型：例如pingpong、streaming等
• 目标：高吞吐、低延迟
• 手段：连接池、多路复用、高性能编解码协议、高性能网络库

3.9 小结

1. 框架通过中间件来注入各种服务治理策略，保障服务的稳定性
2. 通过提供合理的默认配置和方便的命令行工具可以提升框架的易用性
3. 框架应当提供丰富的扩展点，例如核心的传输层和协议层
4. 观测性除了传统的Log、Metric和Tracing之外，内置状态暴露服务也很有必要
5. 性能可以从多个层面去优化，例如选择高性能的编解码协议和网络库

4. 企业实践

介绍：整体架构、自研网络库、扩展性设计、性能优化、合并部署

4.1 整体架构 - Kitex

• Kitex Core
  • 核心组件
• Kitex Byted
  • 与公司内部基础设施集成
• Kitex Tool
  • 代码生成工具

31.png

4.2 自研网络库 - 背景

• 原生库无法感知连接状态
  • 在使用连接池时，池中存在失效连接，影响连接池的复用。
• 原生库存在goroutine 暴涨的风险
  • 一个连接一个goroutine的模式，由于连接利用率低下，存在大量goroutine占用调度开销，影响性能。

4.3 自研网络库-Netpoll

<https://github.com/cloudwego/netpoll>

• 解决无法感知连接状态问题
  • 引入epoll主动监听机制，感知连接状态
• 解决goroutine暴涨的风险
  • 建立goroutine池，复用goroutine
• 提升性能
  • 引入Nocopy Buffer，向上层提供NoCopy的调用接口，编解码层面零拷贝

4.4 扩展性设计

支持多协议，也支持灵活的自定义协议扩展

32.png

33.png

4.5 性能优化-网络库优化

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

4.6 性能优化-编解码优化

<https://github.com/cloudwego/thriftgo>

<https://github.com/cloudvwego/frugal>

• Codegen
  • 预计算并预分配内存，减少内存操作次数，包括内存分配和拷贝
  • Inline减少函数调用次数和避免不必要的反射操作等
  • 自研了Go语言实现的Thrift IDL 解析和代码生成器，支持完善的Thrift IDL语法的语义检查，并支持了插件机制-Thriftgo
• JIT
  • 使用JIT编译技术改善用户体验的同时带来更强的编解码性能，减轻用户维护生成代码的负担
  • 基于JIT编译技术的高性能动态Thrift编解码器-Frugal

序列化和反序列的性能优化从大的方面来看可以从时间和空间两个维度进行优化。从兼容已有的Bimay 协议来看，空间上的优化似乎不太可行，只能从时间维度进行优化，包括下面的几点: ...

代码生成code-gen的优点是库开发者实现起来相对简单，缺点是增加业务代码的维护成本和局限性。

JIT编译(just-in-time compilation)狭义来说是当某段代码即将第一次被执行时进行编译，因而叫"即时编译"。

即时编译JIT则将编译过程移到了程序的加载（或首次解析）阶段，可以一次性编译生成对应的codec并高效执行，目前公司内部正在尝试。压测数据表明性能收益还是挺不错的，目的是不损失性能的前提下，减轻用户的维护负担生成代码的负担。

4.7 合并部署

34.png

• 微服务过微，传输和序列化开销越来越大
• 将亲和性强的服务实例尽可能调度到同一个物理机，远程RPC调用优化为本地IPC调用

35.png

• 中心化的部署调度和流量控制
• 基于共享内存的通信协议
• 定制化的服务发现和连接池实现
• 定制化的服务启动和监听逻辑

某抖音服务，30%合并流量，服务端CPU减少19%，延迟TCP99减少29%

36.png

4.8 小结

1. 介绍了Kitex的整体架构
2. 介绍了自研网络库Netpoll的背景和优势
3. 从扩展性和性能优化两个方面分享了相关实践
4. 介绍了内部正在尝试落地的新的微服务形式：合并部署

课程总结

1. 从本地函数调用引出RPC的基本概念
2. 重点讲解了RPC框架的核心的三层，编解码层、协议层的网络传输层
3. 围绕RPC框架的核心指标，例如稳定性、可扩展性和高性能等，展开讲解相关的知识
4. 分享了字节跳动高性能RPC框架Kitex的相关实践