这是我参与「第五届青训营」伴学笔记创作活动的第 14 天
零、前言
本文记录和整理了本人在跟随字节青训营学习的一些我个人感觉比较重要的内容和知识,也有一部分内容是我认为自己比较难理解或记忆的,也一并记录于此文。
撰写本文的目的主要是方便我自己的复习和查阅,倘若各位读者有与我相似的问题,也可以参考之,如果对各位有帮助那就是我莫大的荣幸,也期望各位不吝赐教,多多指出我的问题,可以在下方留言或者私信我。
一、RPC框架的基本概念
RPC 即 Remote Procedure Calls
远程过程调用;
它与本地过程调用相对;
举个例子吧:
本地函数调用:
假设有如下一段代码:
func main() {
var a = 2
var b = 3
res := calc(a, b)
fmt.Println(res)
return
}
func calc(x, y int) {
z := x * y
return z
}
过程说明:
- 将 a 和 b 的值压栈;
- 通过函数指针找到
calc
函数,进入函数取出栈中的值 2 和 3 ,将其赋予 x 和 y; - 计算 x * y ,并将结果存入 z;
- 将 z 的值压栈,然后从
calc
返; - 从栈中取出 z 返回值,并赋值给 res;
远程函数调用:
RPC需要解决的问题是:
- 函数映射
- 数据转换成字节流
- 网络传输
在本地调用中,函数体是直接通过函数指针来指定的,我们调用哪个方法,编译器就自动帮我们调用它相应的函数指针;
但是,在远程调用中,函数指针是不行的,因为两个进程的地址空间是完全不一样的;
所有函数都有一个自己的ID,
在做RPC的时候就要附上这个ID,以及ID和函数的对照关系表,以便通过ID找到对应的函数并执行。
那么问题来了,客户端要怎么把参数值传给远程的函数呢?
在远程过程调用的时候,客户端和服务端是两个不同的进程,不能通过内存来传递参数;
这时候就需要客户端先把参数转换成一个字节流,然后传给服务端后,服务端再转成自己能读取的格式。
接下来我们来观察一次完整的RPC过程
一次完整的RPC过程:
IDL文件:
即 Interface description language 文件,
通过一种中立的方式来描述接口,使得在不同平台上运行的对象和用不同语言编写的程序可以互相通信。
GenCode生成代码:
通过编译器工具把 IDL 文件转换成语言对应的静态库。
En / Decoder:
从内存中表示到字节序列的转换被称为编码,反之为解码,也称作序列化与反序列化。
Protocal通信协议:
规范了数据在网络中传输内容和格式,除了必须的请求 / 响应数据外,通常还会包含额外的元数据。
Transfer网络传输:
通常基于成熟的网络库走 TCP / UDP 传输。
graph TD
Caller-GenCode生成代码 --> Encoder --> Protocal_1 --> Transfer_1
Transfer_1 --> Transfer_2 --> Protocal_2 --> Decoder --> Callee-GenCode生成代码
RPC的好处:
- 单一职责,有利于分工协作和运维开发;
- 可扩展性强,资源使用率更优;
- 故障远离,服务的整体可靠性更高;
RPC带来的问题:
- 服务宕机,对方应该如何处理?
- 在调用过程中发生网络异常,如何保证消息的可达性?
- 请求量突增导致服务无法及时处理,有哪些应对措施?
解决办法:RPC框架
二、分层设计
下图是一个以Apache Thrift为例的示意图:
编解码层:
Client和Server都依赖同一份IDL文件,生成不同语言的CodeGen;
编解码层的数据格式:
-
语言特定编码格式:
许多编程语言都内建了将内存对象编码为字节序列的支持,如
java.io.Serializable
;好处是方便,用很少的额外代码实现内存对象的保存和恢复。
-
文本格式:
JSON、XML、CSV等文本格式具有人类可读性。
-
二进制编码:
具备跨语言和高性能等优点,有很多种实现方式。
编解码层的选型考量:
- 兼容性:支持自动增加新的字段,而不影响老的服务,这可以提高系统的灵活度
- 通用性:支持跨平台、跨语言
- 性能:从时间空间两个维度考虑
协议层:
协议是双方确定的交流语义;
特殊结束符:
以一个特殊字符作为每个协议单元结束的标志;
message body | \r\n | message body | \r\n |
---|
变长协议:
以定长加不定长的部分组成,其中定长的部分需要描述不定长的内容长度;
length | message body | length | message body |
---|
协议构造:
⭐解释说明:
- LENGTH:
32bit
包括数据包的字节大小,不包含LENGTH自身长度 - HEADER MAGIC:
16bits
值为0x1000
,用于标识协议版本信息,协议解析的时候可以快速校验 - FLAGS:
16bits
,为预留字段暂未使用,默认值为0x0000
- SEQUENCE NUMBER:
32bits
,表示数据包的seqID,用于多路复用,最好确保单个连接内递增 - HEADER SIZE:
16bits
,等于头部长度字节数 / 4
,头部长度计算从第14个字节开始,一直到PAYLOAD前(header的最大长度为64K) - PROTOCOL ID:
uin8编码
,编解码方式,有Binary和Compact两种 - NUM TRANSFORMS:
uint8编码
,表示TRANSFORM个数 - TRANSFORM ID:
uint8编码
,表示压缩方式,有zlib和snappy等方式 - INFO ID:
uint8编码
,用于传递一些定制的meta信息 - PAYLOAD:消息体
协议解析:
网络通信层:
Sockets API:
套接字编程中,客户端必须知道两个信息:
- 服务器的IP地址
- 端口号
网络库:
- 提供易用API
- 封装底层Socket API
- 连接管理和事件分发
- 功能
- 协议支持:TCP UDP UDS...
- 优雅退出、异常处理...
- 性能
- 应用层buffer减少copy
- 高性能定时器、对象池...
三、关键指标
稳定性
保障策略:
- 熔断:保护调用方,防止被调用的服务出现问题而影响到整个链路
- 限流:保护被调用方,防止大流量把服务压垮
- 超时控制:避免浪费资源在不可用节点上
graph TD
超时 --> 降级
熔断 --> 降级
限流 --> 降级
具体说明:
- 熔断:服务A调用服务B,服务B需要调用服务C,这时候服务C响应超时了,由于服务B依赖于服务C,C超时导致B的业务逻辑一直等待,这时候A又在不停地调用B,B可能就会因为堆积大量的请求而导致服务宕机。
- 限流:当调用段发送请求过来时,服务端在执行业务逻辑前先检查限流逻辑,如果发现访问量过大并且超出了限流条件,就让服务端直接降级处理或返回给调用方一个限流异常。
- 超时:当下游的服务因为某种原因响应过慢,下游服务主动停掉一些不太重要的业务,释放出服务器资源,避免资源浪费。
请求成功率:
重试有放大故障的风险:
首先,重试会加大直接下游的负载,假设A服务调用B服务,重试次数为r(包括首次请求),当B高负载时,很可能调用不成功,这时A调用失败,重试,B服务的被调用量会快速增大,最快情况会放大r倍,不仅不能请求成功,反而会导致B的负载继续升高,甚至宕机。
所以防止重试风暴,限制单点重试和限制链路重试。
如图所示:
长尾请求:
长尾请求一般是指明显高于均值的那部分占比较小的请求。
这里先不过多解释。
注册中间件:
易用性
- 开箱即用:合理的默认参数选项 + 丰富的文档
- 周边工具:生成代码工具 + 脚手架工具
扩展性
- Middleware
- Option
- 编解码层
- 协议层
- 网络传输层
- 代码生成工具插件扩展
观测性
- Log、Metric、Tracing
- 内置观测性服务
高性能
四、企业实践
Kitex
KiteX 是字节跳动框架组研发的下一代高性能、强可扩展性的 Go RPC 框架。
自研网络库-Netpoll
背景:
- 原生库无法感知连接状态:在使用连接池时,池中存在失效连接,影响连接池的复用;
- 原生库存在goroutine暴涨的风险:一个连接一个goroutine的模式,由于连接利用率低下,存在大量goroutine占用调度开销,影响性能;
Netpoll:
- 解决无法感知连接状态问题:引入epoll主动监听机制,感知连接状态;
- 建立goroutine池,复用goroutine;
- 引入Nocopy Buffer,向上提供NoCopy的调用接口,编解码层面零拷贝;
扩展性设计
性能优化
- 调度优化
- LinkBuffer
- Pool
- CodeGen
- JIT
合并部署
THE END