深入浅出 RPC 框架

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

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
}

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

以上步骤只是为了说明原理。事实上编译器经常会做优化，对于参数和返回值少的情况会直接将其存放在寄存器，而不需要压栈弹栈的过程，甚至都不需要调用call，而直接做inline操作。

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

RPC 需要解决的问题

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

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

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.6 RPC 带来的问题

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

小结

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

2.分层设计（以 Apache Thrift 为例）

2.1 Apache Thrift

分为服务端 Server 和客户端 Client

Code：开发者自己编写的业务逻辑代码

2.2 编解码层

Service.Processor 和 read/write：通过代码生成工具把 IDL 文件转换成不同语言对应的 lib 代码，里面封装了编解码逻辑
TProtocal：框架的编码层

2.3 编解码层 — 生成代码

Client 和 Server 依赖同一份 IDL 文件，生成不同语言的 CodeGen。

2.4 编解码层 — 数据格式

语言特定的编码格式

许多编程语言都内建了将内存对象编码为字节序列的支持，例如 Java 有 java.io.Serializable。

这种编码形式好处是非常方便，可以用很少的额外代码实现内存对象的保存与恢复，这类编码通常与特定的编程语言深度绑定，其他语言很难读取这种数据。如果以这类编码存储或传输数据，那就和这门语言绑定在一起。安全和兼容性也是问题。
文本格式

JSON、XML、CSV 等文本格式，具有人类可读性。

数字的编码多有歧义之处，比如 XML 和 CSV 不能区分数字和字符串。

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

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

2.5 编解码层 — 二进制编码

TLV 编码

Tag：标签，可以理解为类型
Length：长度
Value：值，Value 也可以是个 TLV 嵌套结构

IDL 源代码

struct Person {
    1: required string		 userName,
    2: optional i64	         favoriteNumber,
    3: optional list<string> interests 
}

转换成编码，以 Thrift BinaryProtocol 为例，下面的二进制编码转换为十六进制表示，方便观察

第一个字段 userName 对应的编码

type 11(string)	field tag(1)	length(6)	value(Martin)
0b	00 01	00 00 00 06	4d 61 72 69 6e

第二个字段 favoriteNumber 对应的编码

type 10(i64)	field tag(2)	value(1337)
0a	00 02	00 00 00 00 00 00 05 39

第三个字段 interests 对应的编码

type 15(list)	field tag(3)	item type11(string)	list items(2)
0f	00 03	0b	00 00 00 02

假设其中有两个值 daydreaming 和 hacking，其对应的编码如下

length	value
00 00 00 0b	64 61 79 64 72 65 61 6d 69 6e 67
00 00 00 07	68 61 63 6b 69 6e 67

最后再用 00 编码作为结尾。这里打包后压缩共 59 个字节。

TLV 编码结构清晰简单，并且扩展性较好，但是由于增加了 Type 和 Length 两个冗余信息，有额外的内存开销，特别是在大部分字段都是基本类型的情况下有不小的空间浪费。

2.6 编解码层 — 选型

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

兼容性：

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

通用性有两个层面的意义：

第一、技术层面，序列化协议是否支持跨平台、跨语言。如果不支持，在技术层面上的通用性就大大降低了。

第二、流行程度，序列化和反序列化需要多方参与，很少人使用的协议往往意味着昂贵的学习成本；另一方面，流行度低的协议，往往缺乏稳定而成熟的跨语言、跨平台的公共包。
性能：从空间和时间两个维度来考虑，即编码后数据大小和编码耗费时长。

性能：

第一、空间开销（Verbosity），序列化需要在原有的数据上加上描述字段，以为反序列化解析之用。如果序列化过程引入的额外开销过高，可能会导致过大的网络，磁盘等各方面的压力。对于海量分布式存储系统，数据量往往以TB为单位，巨大的的额外空间开销意味着高昂的成本。

第二、时间开销（Complexity），复杂的序列化协议会导致较长的解析时间，这可能会使得序列化和反序列化阶段成为整个系统的瓶颈。

2.7 协议层

TTransport：框架的协议层

2.8 协议层 — 概念

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

特殊结束符：一个特殊字符作为每个协议单元结束的标识。

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

HTTP 协议头就是以回车(CR)加换行(LF)符号序列结尾
变长协议：以定长加不定长的部分组成，其中定长的部分需要描述不定长的内容长度。

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

2.9 协议层 — 协议构造

Length：32bits，包括数据包剩余部分的字节大小，不包含自身长度数据包的大小
Header Magic：16bits，值为 0x1000，用于标识版本信息，协议解析时快速校验
Flags：16bits，为预留字段，暂未使用，默认值为 0x0000
Sequence Number：32bits，表示数据包的 seqID，可用于多路复用，最好确保单个连接内递增
Header Size：16bits，等于头部长度字节数/4，头部长度计算从第14个字节开始计算，一直到 PAYLOAD 前（备注：header 的最大长度为 64K）
Protocol ID：uint8 编码，编解码方式有 Binary 和 Compact 两种。

uint8 编码，取值有：

Protocol ID Binary = 0

Protocol ID Compact = 2
Number Transforms：uint8 编码，表示 Transform 个数。
Transform ID：uint8 编码，表示压缩方式，如 zlib 和 snappy
Info ID：uint8 编码，用于传递一些定制的 meta 信息
Payload：消息体

2.10 协议层 — 协议解析

— Peek —> Magic Number — Peek —> Playload Codec — Decode —> Payload

2.11 网络通信层

Network IO：框架的网络通信层

2.12 网络通信层 — Sockets API

套接字（Socket）编程是一种编程模式。在这种模式中，使用和操作套接字来创建软件之间的连接。套接字用于连接不同计算机之间或同一台计算机内的软件，以便程序可以共享数据。套接字编程可用于即时消息、Internet浏览器，文件共享程序，以及强制计算机连接到系统的任何程序。
套接字编程中的客户端必须知道两个信息：服务器的 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 是否关闭。

2.13 网络通信层 — 网络库

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

小结

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

3.关键指标

3.1 稳定性 — 保障策略

熔断：保护调用方，防止被调用的服务出现问题而影响到整个链路

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

当调用端发送请求过来时，服务端在执行业务逻辑之前先执行检查限流逻辑，如果发现访问量过大并且超出了限流条件，就让服务端直接降级处理或者返回给调用方一个限流异常
超时控制：避免资源浪费在不可用节点上

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

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

3.2 稳定性 — 请求成功率

负载均衡
重试

注意，重试有放大故障的风险，重试会直接加大下游的负载。

假设 A 服务调用 B 服务，重试次数设置为 r（包括首次请求），当 B 高负载时很可能调用不成功，这时 A 调用失败重试 B ，B 服务的被调用量快速增大，最坏情况下可能放大到 r 倍，不仅不能请求成功，还可能导致 B 的负载继续升高，甚至直接打挂。

为了防止重试风暴，需要限制单点重试和限制链路重试

3.3 稳定性 — 长尾请求

长尾请求一般是指明显高于均值的那部分占比较小的请求。

业界关于延迟有一个常用的P99标准， P99 单个请求响应耗时从小到大排列，顺序处于99%位置的值即为P99 值，那后面这 1%就可以认为是长尾请求。

在较复杂的系统中，长尾延时总是会存在。造成这个的原因非常多，常见的有网络抖动，GC，系统调度。可以使用 Backup Request 的机制来减少延时。

我们预先设定一个阈值 t3（比超时时间小，通常建议是 RPC 请求延时的 pct99 ），当 Req1 发出去后超过 t3 时间都没有返回，那我们直接发起重试请求 Req2 ，这样相当于同时有两个请求运行。然后等待请求返回，只要 Resp1 或者 Resp2 任意一个返回成功的结果，就可以立即结束这次请求，这样整体的耗时就是 t4 ，它表示从第一个请求发出到第一个成功结果返回之间的时间，相比于等待超时后再发出请求，这种机制能大大减少整体延时。

3.4 稳定性 — 注册中间件

Kitex 框架中的 Client 和 Server 创建接口均采用 Option 模式，提供了极大的灵活性，很方便就能注入这些稳定性策略。

3.5 易用性

开箱即用：合理的默认参数选项、丰富的文档。
周边工具：生成代码工具、脚手架工具
简单易用的命令行工具
- 生成服务代码脚手架
- 支持 protobuf 和 thrift
- 内置功能丰富的选项
- 支持自定义的生成代码插件

Kitex 使用 Suite 来打包自定义的功能，提供 ”一键配置基础依赖“ 的优势。

3.6 扩展性

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

一次请求发起首先会经过治理层面，治理相关的逻辑被封装在 middleware 中，这些 middleware 会被构造成一个有序调用链，逐个执行，比如服务发现、路由、负载均衡、超时控制等，mw 执行后就会进入到 remote 模块，完成与远端的通信

3.7 观测性

Log 日志、Metrics 指标、Trace 链路
内置观测性服务

除了传统的 Log、Metric、Trace 三件套之外，对于框架来说可能还不够，还有些框架自身状态需要暴露出来，例如当前的环境变量、配置、Client/Server初始化参数、缓存信息等

3.8 高性能

场景

单机、集群
单连接、多连接
单/多 client、单/多 server
不同大小的请求包
不同请求类型，例如 pingpong、streaming 等，参考消息类型

目标

高吞吐
低延迟

这里分两个维度，高性能意味着高吞吐和低延迟，两者都很重要，甚至大部分场景下低延迟更重要。

手段

连接池
多路复用
高性能编解码协议
高性能网络库

多路复用可以大大减少了连接带来的资源消耗，并且提升了服务端性能。

连接多路复用和非连接多路复用

调用端向服务端的一个节点发送请求，并发场景下，如果是非连接多路复用，每个请求都会持有一个连接，直到请求结束连接才会被关闭或者放入连接池复用，并发量与连接数是对等的关系。而使用连接多路复用，所有请求都可以在一个连接上完成，可以明显看到连接资源利用上的差异

小结

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

以下是内部开发者的分享，也整理在了青训营活动学习笔记中，如有侵权请联系笔者删除

4.企业实践

4.1 整体架构 — Kitex

Kitex Core：核心组件

core 是 Kitex的的主干逻辑，定义了框架的层次结构、接口，还有接口的默认实现，client 和 server 是对用户暴露的，client/server option 的配置都是在这两个package中提供的。还有client/server 的初始化，在 kitex_gen 生成代码时，用到的 client.go 和 server.go，在初始化 client 时调用的是 kitex_gen 中的方法，其实观察 kitex_gen 下 service package 的代码就知道这是对 client/server 的封装。

client/server 下的是框架治理层面的功能模块和交互元信息，remote 是与对端交互的模块，包括编解码和网络通信。
Kitex Byted：与企业内部基础设施基础

byted 是对字节内部的扩展，集成了内部的二方库还有与字节相关的非通用的实现，byted 部分是在生成代码中初始化 client 和 server 时通过 suite 集成进来的，这样实现的好处是与字节的内部特性解耦，方便后续开源拆分。
Kitex Tool：代码生成工具

tool 则是与生成代码相关的实现，生成代码工具就是编译这个包得到的，里面包括 idl 解析、校验、代码生成、插件支持、自更新等，未来生成代码逻辑还会做一些拆分，便于给用户提供更友好的扩展
Kitex 官方仓库github.com/cloudwego/k…

4.2 自研网络库 — 背景

原生库无法感知连接状态

在使用连接池时，池中存在失效连接，影响连接池的复用。
原生库存在 goroutine 暴涨的风险

一个连接一个 goroutine 的模式，由于连接利用率低下，存在大量 goroutine 占用调度开销，影响性能。
1. Go Net 使用 Epoll ET ，Netpoll 使用 LT。
2. Netpoll 在大包场景下会占用更多的内存。
3. Go Net 只有一个 Epoll 事件循环（因为 ET 模式被唤醒的少，且事件循环内无需负责读写，所以干的活少），而 Netpoll 允许有多个事件循环（循环内需要负责读写，干的活多，读写越重，越需要开更多 Loops）。
4. Go Net 一个连接一个 Goroutine，Netpoll 连接数和 Goroutine 数量没有关系，和请求数有一定关系，但是有 Gopool 重用。
5. Go Net 不支持 Zero Copy，甚至于如果用户想要实现 BufferdConnection 这类缓存读取，还会产生二次拷贝。Netpoll 支持管理一个 Buffer 池直接交给用户，且上层用户可以不使用 Read(p []byte) 接口而使用特定零拷贝读取接口对 Buffer 进行管理，实现零拷贝能力的传递。

4.3 自研网络库 — Netpoll

go net 无法检测连接对端关闭（无法感知连接状态）
1. 在使用长连接池时，池中存在失效连接，严重影响了连接池的使用和效率。
2. 希望通过引入 epoll 主动监听机制，感知连接状态。
解决无法感知连接问题
go net 缺乏对协程数量的管理
1. Kitex 采取一个连接一个 goroutine 模式，由于连接利用率低，服务存在较多无用的 goroutine，占用调度开销，影响性能。
2. 希望建立协程池，提升性能。
  
  netpoll 基于 epoll，同时采用 Reactor 模型，对于服务端则是主从 Reactor 模型，服务端的主reactor 用于接受调用端的连接，然后将建立好的连接注册到某个从Reactor 上，从Reactor 负责监听连接上的读写事件，然后将读写事件分发到协程池里进行处理。
解决 goroutine 暴涨的风险
提升性能

为了提升性能，引入了 Nocopy Buffer，向上层提供 NoCopy 的调用接口，编解码层面零拷贝

4.4 扩展性设计

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

kitex 支持多协议的并且也是可扩展的，交互方式上前面已经说过支持ping-pong、streaming、oneway

编解码支持 thrift、Protobuf 应用层协议支持 TTHeader、Http2、也支持裸的 thrift 协议

传输层目前支持 TCP，未来考虑支持 UDP、kernel-bypass 的 RDMA

框架内部不强依赖任何协议和网络模块，可以基于接口扩展，在传输层上则可以集成其他库进行扩展。

目前集成的有自研的 Netpoll，基于 netpoll 实现的 http2 库，用于 mesh 场景通过共享内存高效通信的 shm-ipc，以后也可以增加对 RDMA 支持的扩展

4.5 性能优化 — 网络库优化

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

4.6 性能优化 — 编解码优化

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

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

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

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

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

4.7 合并部署

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

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

小结

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

总结

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

参考资料

Apache Thrift系列详解(一) - 概述与入门

详解varint编码原理

几款主流的压缩算法对比Zlib,snappy,lz4

可观测性的三大支柱：Metrics、Trace、Log

消息类型