这是我参与「第三届青训营 -后端场」笔记创作活动的的第11篇笔记
基本概念
RPC调用需要解决的问题
本地函数调用和RPC调用之间的区别:
- 函数映射
- 数据转换成字节流
- 网络传输
RPC概念模型
RPC过程由5个模型构成:User、User-Stub、RPC-Runtime、Server-Stub、Server
一次RPC的完整过程
-
IDL (Interface description language)文件 IDL 通过一种中立的方式来描述接口,使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信
-
生成代码 通过编译器工具把 IDL 文件转换成语言对应的静态库
-
编解码 从内存中表示到字节序列的转换称为编码,反之为解码,也常叫做序列化和反序列化
-
通信协议 规范了数据在网络中的传输内容和格式。除必须的请求/响应数据外,通常还会包含额外的元数据
-
网络传输 通常基于成熟的网络库走 TCP/UDP 传输
RPC的好处
- 单一职责,有利于分工协作和运维开发
- 可扩展性强,资源使用率更优
- 故障隔离,服务整体可靠性更高
RPC框架
RPC存在的问题:
- 服务宕机,对方该如何处理?
- 在调用过程中发送网络异常,如何保证消息的可达性?
- 请求量突增导致服务无法及时处理,有哪些应对措施 上述问题均可通过RPC框架来解决
RPC框架
编解码层
生成代码
数据格式
- 语言特定格式:许多编程语言都内建了将内存对象编码为字节序列的支持,例如 java.io.Serializable
- 文本格式:例如 JSON、XML、CSV 等,具有人类可读性
- 二进制编码:具有跨语言和高性能等优点,常见有 Thrift 的 BinaryProtocol,Protobuf,实现可以有多种形式,例如 TLV 编码 和 Varint 编码
二进制编码-TLV编码
包含字段
- Tag:标签,可以理解为类型
- Length:长度
- Value:值,Value也可以是个TLV结构
Demo
数据格式选型标准
- 兼容性:支持自动增加新的字段,而不影响老的服务,这将提高系统的灵活度
- 通用性:支持跨平台、跨语言
- 性能:从空间和时间两个维度来考虑,也就是编码后数据大小和编码耗费时长
协议层
概念
- 特殊结束符:一个特殊字符作为每个协议单元结束的标识
- 变长协议:以定长加不定长的部分组成,其中定长的部分需要描述不定长的内容长度
协议构造-以 Thrift 的 THeader 协议为例
- LENGTH:数据包大小,不包含自身
- HEADER MAGIC:标识版本信息,协议解析时候快速校验
- SEQUENCE NUMBER:表示数据包的 seqlD,可用于多路复用,单连接内递增
- HEADER SIZE:头部长度,从第14个字节开始计算一直到 PAYLOAD前
- PROTOCOL ID:编解码方式,有 Binary 和 Compact 两种
- TRANSFORM ID:压缩方式,如 zlib 和 snappy
- INFO ID:传递一些定制的 meta 信息
- PAYLOAD:消息体
协议解析
逐渐读取,获取协议类型/版本,获取编解码方式,获取数据内容
网络通信层
基于Sockets API实现
使用不同的网络库进行对接
如使用字节自研网络库 Netpoll,网络库应具有如下功能:
- 提供易用API
- 封装底层SocketAPI
- 连接管理和事件分发
- 功能
- 协议支持:tcp、udp和uds等
- 优雅推出、异常处理等
- 性能
- 应用层buffer减少copy
- 高性能定时器、对象池等
RPC 框架核心指标
稳定性
- 保障策略
- 熔断:保护调用方,防止被调用的服务出现问题而影响到整个链路
- 限流:保护被调用方,防止大流量被服务压垮
- 超时控制:避免浪费资源在不可用节点上
从某种程度上讲超时、限流和熔断也是一种服务降级的手段
- 请求成功率
- 负载均衡
- 请求重试
- 长尾请求
- 注册中间件 各种额外服务均可以通过中间件的方式在实现
易用性
- 开箱即用
- 合理的默认参数选项、丰富的文档
- 周边工具
- 生成代码工具、脚手架工具
扩展性
- Middleware:middleware 会被构造成一个有序调用链逐个执行,比如服务发现、路由、负载均衡、超时控制等
- Option:作为初始化参数
- 核心层是支持扩展的:编解码、协议、网络传输层
- 代码生成工具也支持插件扩展
观测性
- 三件套:Log、Metric 和 Tracing
- 内置观测性服务,用于观察框架内部状态
- 当前环境变量
- 配置参数
- 缓存信息
- 内置 pprof 服务用于排查问题
高性能
场景
- 单机多机,单连接多连接,单client多client,单server多server
- 不同大小的请求包
- 不同请求类型:pingpong、streaming等
目标
- 高吞吐
- 低延迟
手段
- 连接池和多路复用:复用连接,减少频繁建联带来的开销
- 高性能编解码协议:Thrift、Protobuf、Flatbuffer 和 Cap'n Proto 等
- 高性能网络库:Netpoll 和 Netty 等
RPC框架Kitex
架构
- Kitex Core: 核心组件
- Kitex Byted:字节内部基础设施集成
- Kitex Tool:代码生成工具
文档
详见Kitex
自研网络库 Netpoll
背景
- 原生库无法感知连接状态:在使用连接池时,池中存在失效连接,影响连接池的复用
- 原生库存在 goroutine 暴涨的风险:一个连接一个goroutine的模式,由于连接利用率低下,存在大量goroutine占用调度开销,影响性能
Netpoll方案
-
解决无法感知连接状态问题 引入 epoll 主动监听机制,感知连接状态
-
解决 goroutine 暴涨的风险 建立 goroutine 池,复用 goroutine
-
提升性能 引入 Nocopy Buffer,向上层提供 NoCopy 的调用接口,编解码层面零拷贝
扩展性
支持多协议,也支持灵活的自定义协议扩展
性能优化
参考 字节跳动 Go RPC 框架 KiteX 性能优化实践
合并部署
- 微服务过微,引入的额外的传输和序列化开销越来越大
- 将强依赖的服务统计部署,有效减少资源消耗:通过将微服务调用形态与资源调度系统结合,将一些调用关系紧密、通信量大的服务部署在同一个机器上,并且使用 本地IPC 代替 远程RPC 的方式,降低网络通信带来的开销