这是我参与「第五届青训营 」伴学笔记创作活动的第17天。
基本概念
本地函数调用
func calculate(x, y int) int {
z := x * y
return z
}
func main() {
var a = 2
var b = 3
result := calculate(a, b)
fmt.Println(result)
return
}
- 将a和b的值压栈
- 通过函数指针找到calculate函数,进入函数取出栈中的值2和3,将其赋予x和y
- 计算x * y,并将结果存在z
- 将z的值压栈,然后从calculate返回
- 从栈中取出z的返回值,并赋值给result
远程函数调用
RPC需要解决的问题
- 函数映射(如何准确的调用不在同一内存空间且需要的函数)
- 数据转换成字节流
- 网络传输
初代RPC概念模型
1984年Nelson发表了论文《Ilplement Remote Proceduce Calls》,提出RPC的过程由五个模型组成,分别是User、User-Stub、RPC-Runtime、Sever-Stub、Server。
一次RPC的完整过程
- IDL(interface description language)文件
- IDL通过一种中立的方式来描述接口,使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信
- 是一个约定的描述文件,调用过程中的双方都依赖同一份IDL文件
- 生成代码
- 通过编译器工具把IDL文件转换成语言对应的静态库
- 编解码
- 从内存中表示到字节序列(流)的转换称为编码,反之为解码,也常叫做序列化和反序列化
- 通信协议
- 规范了数据在网络中的传输内容和格式。除必须的请求/响应数据外,通常还会包含额外的元数据
- 网络传输
- 通常基于成熟的网络库走TCP/UDP传输
RPC的好处
- 单一职责,有利于分工协作和运维开发
- 可扩展性强,资源使用率更优
- 故障隔离,服务的整体可靠性更高
RPC的问题
- 服务宕机,对方应该如何处理?
- 在调用过程中发送网络异常,如果保证消息的可达性?
- 请求量突增导致服务无法及时处理,有哪些应对措施?
而这些,将由RPC框架来处理!
分层设计
注:以Apache Thrift框架为例。
架构概览
编解码层
生成代码
Client和Server依赖同一份IDL文件可以生成各种语言的代码,由此各服务可以使用不同的语言与框架。
数据格式
- 语言特点的格式
- 许多编程语言都内建了将内存对象编码为字节序列的支持,例如java有java.io.Serializable
- 缺点:由于语言的特性,一些代码会被写死而不能转换
- 文本格式
- JSON、XML、CSV等文本格式,具有人类可读性
- 缺点:如JSON无法区分整型和浮点型、由于要反射故性能较差等
- 二进制编码
- 具备跨语言和高性能等优点,常见有Thrift的BinaryProtocol、Protobuf等
二进制编码
注:以BinaryProtocol为例。
// go Protobuf
struct Person {
1: required string userName,
2: optional i64 favoriteNumber,
3: optional list<string> interests
}
TLV编码
- Tag: 标签,可以理解为类型
- Length: 长度
- Value: 值,Value也可以是个TLV结构
如上述代码转换为字节流后是这样的:
选型
- 兼容性
- 支持自动增加新的字段,而不影响老的服务,这将提高系统的灵活度
- 通用性
- 支持跨平台、跨语言
- 性能
- 从空间和时间两个维度来考虑,也就是编码后数据大小和编码耗费时长
协议层
概念
- 特殊结束符
- 一个特殊字符作为每个协议单元结束的标识,参考了如HTTP协议(以回车+换行结尾)
- 变长协议
- 以定长加不定长的部分组成,其中定长的部分需要描述不定长的内容长度
协议构造
- LENGTH: 数据包大小,不包含自身
- HEADER MAGIC: 标识版本信息,协议解析时候快速校验
- SEQUENCE NUMBER: 标识数据包的seqID,可用于多路复用,单连接内递增
- 多路复用:从一个连接内可以有多个请求流在走
- HEADER SIZE: 头部长度,从第14个字节开始计算一直到PAYLOAD(消息体)前
- PROTOCOL ID: 编解码方式,有Binary和Compact两种
- TRANSFORM ID: 压缩方式,如zlib和snappy
- INFO ID: 传递一些定制的meta信息(元数据)
- PAYLOAD: 消息体
协议解析流程
网络通信层
Sockets API
其位于应用层和传输层之间。
通信流程为:
实际应用-网络库
- 提供易用API
- 封装底层Socket API
- 连接管理和事件分发
- 功能
- 协议支持:TCP、UDP和UDS等
- 优雅退出、异常处理等,对上层返回友好
- 性能
- 应用层Buffer减少copy
- 高性能定时器、对象池等
比如Go的net库。
RPC框架的关键指标
稳定性
保障策略
- 熔断:保护调用方,防止被调用的服务出现问题而影响到整个链路
- 限流:保护被调用方,防止大流量把服务压垮
- 超时控制:避免浪费资源在不可用节点上
请求成功率
- 负载均衡
- 均匀的调用下游节点
- 重试
- 调用失败后重试调用
长尾请求
指明显高于平均响应时间的请求,一般占到请求数中的1%。
- 设置阈值时间(规定请求返回的时间,99%的请求能满足此阈值)
- 若没有在阈值时间内返回,则会发送Res2,即Backup Request(备份请求),理论上会很快返回
实现方式-注册中间件
易用性
- 开箱即用
- 合理的默认参数选项、丰富的文档
- 周边工具
- 生成代码工具、脚手架工具(生成访问数据的原生语句
扩展性
- Middleware
- Option
- 编解码层
- 协议层
- 网络传输层
- 代码生成工具插件扩展
观察性
- Log、Metric(监控,获取qbs、延迟等)、Tracing(链路跟踪,如每个阶段的耗时是多少)
- 内置观测性服务
- 往往基于HTTP协议实现
高性能
场景
- 单机多机
- 单连接多连接
- 单/多Client 单/多Server
- 不同大小的请求包
- 不同的请求类型:例如pingpong、streaming等
目标
- 高吞吐
- 低延迟
手段
- 连接池
- 多路复用
- 选取高性能编解码协议
- 选取高性能网络库
企业实践
基于字节跳动自研开源框架Kitex。
整体架构-Kitex
- Kitex Core
- 核心组件
- Kitex BYTED
- 与公司内部基础设施集成
- Kitex Tool
- 代码生成工具
自研网络库-背景
- 原生库无法感知连接状态
- 在使用连接池时,池中存在失败连接,影响连接池的复用
- 原生库存在goroutine暴涨的风险
- 一个连接一个goroutine的模式,由于连接利用率低下,存在大量goroutine占用调度开销,影响性能
自研网络库-Netpoll
- 解决无法感知连接状态问题
- 引入epoll主动监听机制,感知连接状态
- 解决goroutine暴涨的风险
- 建立goroutine池,复用goroutine
- 提升性能
- 引入Nocopy Buffer,向上层提供NoCopy的调用接口,编解码层面零拷贝
扩展性设计
支持多协议,也支持灵活的自定义协议扩展。
性能优化
网络库优化
- 调度优化
- epoll_wait在调度上的控制
- gopool重用goroutine降低同时运行协程数
- LinkBuffer
- 读写并行无锁,支持nocopy地流式读写
- 高效扩缩容
- Nocopy Buffer池化,减少GC
- Pool
- 引入内存池和对象池,减少GC开销
编解码优化
- Codegen
- 预计算并预分配内存,减少内存操作次数,包括内存分配和拷贝
- Inline减少函数调用次数和避免不必要的反射操作等
- 自研了Go语言实现的Thrift IDL解析和代码生成器,支持完善的Thrift IDL语法和语义检查,并支持了插件机制-Thriftgo
- JIT
- 使用JIT编译技术改善用户体验的同时带来更强的编解码性能,减轻用户维护生成代码的负担
- 基于JIT编译技术的高性能动态Thrift编解码器-Frugal
合并部署
- 微服务过微,传输和序列化开销越来越大
- 将亲和性强的服务实例尽可能调度到同一个物理机,远程RPC调用优化为本地IPC调用
- 中心化的部署调度和流量控制
- 基于共享内存的通信协议
- 定制化的服务发现和连接池实现
- 定制化的服务启动和监听逻辑
以上内容若有不正之处,恳请您不吝指正!