深入浅出RPC框架 | 豆包MarsCode AI刷题

VksFeng
169 阅读8分钟

1.基本概念

1.1 本地函数调用

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

func calculate(x, y int) {
	z := x + y
	return z
}
  1. 将a和b的值压栈
  2. 通过函数指针找到calculate函数，进入函数取出栈中的值2，3，将其赋予x和y
  3. 计算x×yx \times y，并将结果存在z
  4. 将z的值压栈，然后从calculate返回
  5. 从栈中取出z的返回值，并赋值给result

1.2 远程函数调用(RPC-Remote Procedure Calls)

RPC电商例子.png

RPC需要解决的问题：

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

1.3 RPC概念模型

RPC概念模型.png

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

1.4 一次RPC的完整过程

一次RPC的完整过程.png

IDL(Interface description language)文件

  • IDL通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信

生成代码

  • 通过编译器工具把IDL文件转换成语言对应的静态库

编码器

  • 从内存中表示到字节序列的转换称为编码，反之为解码，也常叫做序列化和反序列化

通讯协议

  • 规范了数据在网络中的传输内容和格式。除必须的请求/响应数据外，通常还会包含额外的元数据

网络传输

  • 通常基于成熟的网络库走TCP/UDP传输

1.5 RPC的好处

RPC的好处.png

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

1.6 RPC带来的问题

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

这些问题将有RPC框架来解决

2.分层设计

  • 编解码层
  • 协议层
  • 网络通信层

2.1 以Apache Thrift为例

ApacheThrift.png

2.2 编解码层

RPC编解码层.png

2.2.1 编解码层-生成代码

RPC编解码层生成代码.png

2.2.2 编解码层-数据格式

IDL的数据格式

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

2.2.3 编解码层-二进制编码

TVL编码

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

例子

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

RPC编解码层二进制编码.png

2.2.4 编解码层-选型

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

2.3 协议层

RPC协议层.png

2.3.1 概念

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

2.3.2 协议构造

RPC协议层协议构造.png

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

2.3.3 协议解析

RPC协议层协议解析.png

2.4 网络通信层

RPC框架网络通信层.png

2.4.1 Sockets API

SocketAPI.png SocketAPI流程.png

2.4.2 网络库

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

3.关键指标

3.1 稳定性

3.1.1 保障策略

RPC稳定性保障策略.png

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

3.1.2 请求成功率

  1. 负载均衡 RPC稳定性请求成功率负载均衡.png
  2. 重试

RPC稳定性请求成功率重试.png

3.1.3 长尾请求

长尾请求：

  • 概念：一般指明显高于均值的那部分占比比较小的请求。
  • 存在原因：网络抖动、GC、系统调度等 P99：
  • 业内关于延迟的常用标准
  • P99单个请求响应耗时从小到大排序，排序处于99%位置的值即为怕P99值，那后面这1%就可以认为是长尾请求。

Backup Request RPC稳定性长尾请求.png

左图为正常方式 右图：

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

3.1.4 注册中间件

RPC稳定性中间件注册.png

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

3.2 易用性

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

3.3 扩展性

RPC框架扩展性.png

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

3.4 观测性

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

3.5 高性能

目标：

  • 高吞吐
  • 低延迟

场景：

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

手段：

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

4.企业实践

4.1 整体架构

4.1.1 Kitex

Kitex架构设计.png

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

4.2 自研网络库

4.2.1 背景

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

4.2.2 Netpoll

自研网络库Netpoll

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

4.3 扩展性设计

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

协议类型支持的协议
InteractionPing-Pong/Streaming/Oneway
CodecThrift/Protobuf
Application Layer ProtocolTTHeader/HTTP2
Transport LayerTCP/UDP/RDMA

Kitex协议.png

4.4 性能优化

4.4.1 网络库优化

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

4.4.2 编解码优化

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

4.5 合并部署

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

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