RPC 原理与实践 | 青训营笔记

guliwa
58 阅读14分钟

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

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

  1. 分布式定时任务整体架构
  2. 控制台Admin详细设计
  3. 触发器Trigger详细设计
  4. 调度器Scheduler详细设计
  5. 执行器Executor详细设计

课前部分主要罗列课程中涉及到的概念。对于不熟悉的概念，同学们可以提前查询预习；课中部分主要罗列每一部分的关键思路，帮助同学们跟上课程的进度；课后部分是一些问题，帮助同学们在课后梳理本课程的重点。

相比本地函数调用，远程调用的话我们不知道对方有哪些方法，以及参数长什么样，所以需要有一种方式来描述或者说声明我有哪些方法，方法的参数都是什么样子的，这样的话大家就能按照这个来调用，这个描述文件就是 IDL 文件。

刚才我们提到服务双方是通过约定的规范进行远程调用，双方都依赖同一份IDL文件，需要通过工具来生成对应的生成文件，具体调用的时候用户代码需要依赖生成代码，所以可以把用户代码和生成代码看做一个整体。

编码只是解决了跨语言的数据交换格式，但是如何通讯呢？需要制定通讯协议，以及数据如何传输？我的网络模型如何呢？那就是这里的 transfer 要做的事情。

概述

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

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

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

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

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

课前

RPC 的基本概念

  • RPC的概念模型：User、User-Stub、RPC-Runtime、Server-Stub、Server

  • IDL(Interface Definition Language) 文件

    • Thrift
    • Protobuf

  • 生成代码

  • 编解码（序列化/反序列化）

  • 通信协议

    • 应用层协议

  • 网络通信

    • IO 网络模型

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

    • 传输层协议

      • TCP
      • UDP

RPC 框架分层设计

  • 编解码层

    • 数据格式：

      • 语言特定格式

      • 文本格式

      • 二进制编码

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

    • 选项：

      • 兼容性
      • 通用型
      • 性能

  • 传输协议层

    • 消息切分

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

    • 协议构造

      • 以 Thrift 的 THeader 协议为例讲解

  • 网络通信层

    • 网络库

    • 核心指标

      • 吞吐高
      • 延迟低

RPC 框架的核心指标

  • 稳定性

    • 保障策略

      • 熔断
      • 限流
      • 超时

    • 请求成功率

      • 负载均衡
      • 重试

    • 长尾请求

      • BackupRequest

  • 易用性

    • 开箱即用
    • 周边工具

  • 扩展性

  • 观测性

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

  • 高性能

字节内部 Kitex 实践分享

课中

基本概念

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

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

  • 一次 RPC 的完整过程

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

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

RPC 框架分层设计

编解码层

  • 数据格式

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

  • 选型考察点

    • 兼容性

    • 通用型

    • 性能

      • 空间开销
      • 时间开销

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

协议层

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

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

HTTP 协议头就是以回车(CR)加换行(LF)符号序列结尾。

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

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

  • 协议解析

网络通信层

套接字编程中的客户端必须知道两个信息：服务器的 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关闭了。

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

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

02.小结

1.RPC框架主要核心有三层：编解码层、协议层和网络通信层

2.二进制编解码的实现原理和选型要点

3.协议的一般构造，以及框架协议解析的基本流程

4.Socket APl的调用流程，以及选型网络库时要考察的核心指标

RPC 框架核心指标

稳定性

  • 保障策略

    • 熔断
    • 限流
    • 超时控制
    •   熔断：
    •   一个服务 A 调用服务 B 时，服务 B 的业务逻辑又调用了服务 C，而这时服务 C 响应超时了，由于服务 B 依赖服务 C，C 超时直接导致 B 的业务逻辑一直等待，而这个时候服务 A 继续频繁地调用服务 B，服务 B 就可能会因为堆积大量的请求而导致服务宕机，由此就导致了服务雪崩的问题
    •   限流：
    •   当调用端发送请求过来时，服务端在执行业务逻辑之前先执行检查限流逻辑，如果发现访问量过大并且超出了限流条件，就让服务端直接降级处理或者返回给调用方一个限流异常
    •   超时：
    •   当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，避免浪费资源

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

  • 请求成功率

    • 负载均衡
    • 重试

  • 长尾请求

    • BackupRequest

长尾请求一般是指明显高于均值的那部分占比较小的请求。 业界关于延迟有一个常用的P99标准， P99 单个请求响应耗时从小到大排列，顺序处于99%位置的值即为P99 值，那后面这 1%就可以认为是长尾请求。在较复杂的系统中，长尾延时总是会存在。造成这个的原因非常多，常见的有网络抖动，GC，系统调度。

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

  • 注册中间件

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

易用性

  • 开箱即用

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

  • 周边工具

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

扩展性

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

观测性

  • 三件套：Log、Metric 和 Tracing

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

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

高性能

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

字节内部 Kitex 实践分享

core是它的的主干逻辑，定义了框架的层次结构、接口，还有接口的默认实现，如中间蓝色部分所示，最上面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是与对端交互的模块，包括编解码和网络通信。

右边绿色的byted是对字节内部的扩展，集成了内部的二方库还有与字节相关的非通用的实现，在第二节高级特性中关于如何扩展kitex里有介绍过，byted部分是在生成代码中初始化client和server时通过suite集成进来的，这样实现的好处是与字节的内部特性解耦，方便后续开源拆分。

左边的tool则是与生成代码相关的实现，我们的生成代码工具就是编译这个包得到的，里面包括idl解析、校验、代码生成、插件支持、自更新等，未来生成代码逻辑还会做一些拆分，便于给用户提供更友好的扩展

  1. 框架文档 Kitex
  2. 自研网络库 Netpoll，背景：

  1. a. 原生库无法感知连接状态 b. 原生库存在 goroutine 暴涨的风险
  2. 扩展性：支持多协议，也支持灵活的自定义协议扩展

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

  2. a. 网络优化

    1. i. 调度优化
    2. ii. LinkBuffer 减少内存拷贝，从而减少 GC
    3. iii. 引入内存池和对象池

  3. b. 编解码优化

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

  4. 合并部署

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

课程总结

1.从本地函数调用引出RPC的基本概念

2.重点讲解了RPC框架的核心的三层，编解码层、协议层和网络传输层

3.围绕RPC框架的核心指标，例如稳定性、可扩展性和高性能等，展开讲解相关的知识

4.分享了字节跳动高性能RPC框架Kitex的相关实践

课后

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

参考文献

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