RPC 框架分层设计、关键指标分析｜ 青训营笔记

Java星辰
370 阅读7分钟

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

前言

本文主要介绍RPC相关概念以及RPC框架的分层设计。

基本概念

RPC是远程过程调用（Remote Procedure Call），也就是说两台服务器A、B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

与远程过程调用相对的是本地函数调用。

本地函数调用

下面通过一个例子来看下本地函数调用的过程。

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

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

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

远程函数调用

远程函数调用涉及到多台机器，需要解决以下几个问题：

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

RPC概念模型

1984年Nelson发表了论文《Implementing Remote Procedure Calls》，其中提出了RPC的过程由5个模型组成：User、User-Stub、RPC-Runtime、Server-Stub、Server。

image.png

一次RPC完整过程

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

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

image.png

RPC优劣势

RPC的好处

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

RPC带来的问题

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

分层设计

RPC主要分为3层：编解码层、协议层、网络通信层。

以Apache Thrift为例来看下分层设计：

image.png

编解码层

生成代码

  • 根据IDL文件，生成需要的代码，可以是不同的语言

数据格式

一般地，数据格式可以分为几类

  • 语言特定的格式
    • 许多编程语言内建了将内存对象编码为字节序列的支持，例如Java的Serializable
  • 文本格式
    • JSON、XML、CSV等，具有可读性
  • 二进制编码
    • 具备跨语言和高性能等优点，常见有Thrift的BinaryProtocol、Protobuf等

image.png

编码格式选型

选择编码格式需要考虑的点：

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

协议层

基本概念

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

以 Thrift 的 THeader 协议为例

image.png

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

协议解析

image.png

网络通信层

Sockets API

image.png

网络库

在实际开发中，我们往往采用封装好的网络库来操作，对于网络库的选择可以参考以下几点：

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

关键指标

构建一个RPC框架需要考虑哪些指标呢？需要考虑：稳定性、易用性、扩展性、观测性、高性能。

稳定性

既然是稳定性，肯定要有保障策略，有以下几个策略：

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

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

请求成功率

提高请求成功率，要从负载均衡、重试方便出发。

在重试时，要防止重试风暴，限制单点重试和限制链路重试。

长尾请求

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

image.png

注册中间件

上面提到的是稳定性的措施和策略，那么如何把这些措施和错略进行串联起来呢？是通过中间件的形式。

易用性

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

扩展性

需要提供尽量多的扩展点，扩展点包括：

  • 中间件
  • Option、参数
  • 编解码层
  • 协议层
  • 网络传输层
  • 代码生成工具插件扩展

观测性

观测性可以方便追踪、排查问题，包括：Log、Metric、Tracing。

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

高性能

做到高性能，我们的目标是：高吞吐、低延迟。

衡量标准覆盖场景：

  • 单机多机
  • 单连接、多连接
  • 单/多client、单/多Server
  • 不同大小的请求包
  • 不同请求类型：例如pingpong、streaming等

要达到目标需要的手段：

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

引用

RPC 框架分层设计

RPC 关键指标分析与企业实践

avatar
文章
阅读
粉丝