深入浅出RPC框架｜ 青训营笔记

xYx
124 阅读6分钟

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

1.主要内容

  • RPC基本概念
  • RPC框架的分层设计和关键指标
  • 字节实践

2.本节详细内容

RPC基本概念

RPC就是远程函数调用（Remote Procedure Calls）
RPC调用需要解决的问题：

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

RPC带来的问题由框架解决

一次RPC的完整过程

  • IDL文件：IDL通过中立方式描述接口，不同平台运行的对象和不同语言编写的程序可以互相通信
  • 生成代码：通过编译工具把IDL文件转为语言对应静态库
  • 编解码：也叫序列化和反序列化
  • 通信协议：规范数据在网络中传输内容和格式，通常包括额外的元数据
  • 网络传输：走TCP/UDP传输

RPC分层设计

分层设计

Apache Thrift为例

image.png

编解码层

数据格式

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

选型

  • 兼容性：需要有良好的可扩展性，支持自动增加新的字段，而不影响老的服务，提高系统的灵活度
  • 通用性：技术层面：序列化协议是否支持跨平台、跨语言； 流行程度：序列化和反序列化需要多方参与，流行性度低的协议，跨语言跨平台的包很少也不稳定不成熟
  • 性能：空间开销和时间开销来考虑，编码后数据的大小和编码所需要的时长

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

image.png

协议层

是双方确定的交流语义

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

协议构造

以Thrift的THeader协议为例

image.png

协议解析

image.png

网络通信层

Sockets API

套接字编程中客户端必须知道两个信息：服务器的IP地址以及端口号

  • Socket函数创建一个套接字，bind将一个套接字绑定到一个地址上。Listen监听进来的连接。Backlog通常情况指定为128即可
  • connect客户端向服务器发起连接，accept接受一个连接请求，如果没有连接则会一直阻塞到有连接进来。得到客户端fd后，就可以调用read，write函数和客户端进行通讯，读写方式和其他I/O类似
  • read从fd读数据，socket默认是阻塞模式的，如果对方没有写数据，read会一直阻塞
  • write从fd写数据，socket默认是阻塞模式的，如果对方没有写数据，write会一直阻塞
  • socket关闭套接字，当另一端socket关闭后，尝试读会EOF返回0；尝试写会触发SIGPIPE信号，返回-1和err = EPIPE

网络库

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

image.png

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

第一种方式浪费线程（会占用内存和上下文切换开销），第二种方式浪费 CPU 做大量无效工作。而基于 IO 多路复用系统调用实现的 Poll 的意义在于将可读/可写状态通知和实际文件操作分开，并支持多个文件描述符通过一个系统调用监听以提升性能。

网络库的核心功能就是去同时监听大量的文件描述符的状态变化(通过操作系统调用)，并对于不同状态变更，高效，安全地进行对应的文件操作。

RPC框架核心指标

稳定性

保障策略

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

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

请求成功率

  • 负载均衡
  • 重试

重试会有放大故障的风险，也就是雪崩，会使下游负载大量升高，甚至直接打挂。防止重试风暴，限制单点重试和限制链路重试

长尾请求

长尾请求一般指明显高于均值的占比较小的请求，业界有常用的P99标准，意思是单个请求响应耗时从小到大排列，顺序处于99%位置的值即为P99值，后面的1%即为长尾请求。
造成长尾请求的原因非常多，常见有网络波动，GC，系统调度等

  • Backup Request
    先设定一个阈值T3（比超时时间小，通常建议是RPC请求延时的P99），当req发出去超过T3后立即发起重试请求req2，这样就相当于同时有两个请求，只要有一个返回成功就立即结束这次请求

相较于普通超时重试，这种机制可以大大减小整体耗时

image.png

易用性

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

扩展性

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

观测性

  • 三件套：Log、Metric 和 Tracing
  • 内置观测性服务，用于观察框架内部状态
    • 当前环境变量
    • 配置参数
    • 缓存信息
    • 内置 pprof 服务用于排查问题

高性能

  • 高性能意味着高吞吐和低延迟，两者都很重要，甚至大部分情况是低延迟重要
  • 连接池和多路复用：复用连接，减少频繁建联带来的开销，服务端吞吐可以提升30%
  • 高性能编解码协议：Thrift、Protobuf、Flatbuffer 和 Cap'n Proto 等
  • 高性能网络库：Netpoll 和 Netty 等

3.企业实践

字节整体架构Kitex

Kitex架构整体概览(概览 | CloudWeGo)

自研网络库

背景

  • 原生库无法感知连接状态，存在失效连接，影响连接池复用
  • 原生库存在 goroutine 暴涨的风险

Netpoll

[Netpoll](概览 | CloudWeGo)

性能优化

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

4.课后总结

  • 行业中RPC框架各有优劣
  • 字节开源的Kitex可以去GitHub上看
  • 了解RPC框架的核心指标
  • RPC框架的核心三层为重点

5.引用

字节内部课：RPC原理和实现
稀土掘金-后端学习资料
CloudWeGo文档

avatar
文章
阅读
粉丝