这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
基本概念
本地函数调用
func main(){
var a = 2
var b = 3
result := calculate(a,b)
fmt.Println(result)
return
}
func calculate(x, y int){
z := ×*y
return z
}
- 将a和b的值压栈
- 通过函数指针找到calculate函数,进入函数取出栈中的值2和3,将其赋予×和y
- 计算×*y,并将结果存在z
- 将z的值压栈,然后从calculate返回5.从栈中取出z返回值,并赋值给result
远程函数调用
RPC 实际上也是函数执行,不过函数执行和请求调用方分开了
RPC 需要解决的问题:
- 函数映射
- 数据转换为字节流(内存空间不同,怎么传输?)
- 网络传输
RPC 概念模型
web.eecs.umich.edu/~mosharaf/R…
1984年 Nelson 发表了论文《Implementing Remote Procedure Calls》,其中提出了RPC 的过程由5个模型组成:
User、User-Stub、RPC-Runtime、Server-Stub、Server
一次 RPC 的完整过程
IDL (Interface description language)文件
IDL通过一种中立的方式来描述接口,使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信
例如,常见的 thrift 和 protobuf,都是一种 IDL
生成代码
通过编译器工具把IDL文件转换成语言对应的静态库,不同的语言需要对应的编译器工具
编解码
从内存中表示到字节序列的转换称为编码,反之为解码,也常叫做序列化和反序列化
通信协议
规范了数据在网络中的传输内容和格式。除必须的请求/响应数据外,通常还会包含额外的元数据
网络传输
通常基于成熟的网络库走TCP/UDP传输
RPC 的好处
- 单一职责,有利于分工协作和运维开发
- 可扩展性强,资源使用率更优(还方便复用)
- 故障隔离,服务的整体可靠性更高
RPC 带来的问题
- 服务宕机,对方应该如何处理?
- 在调用过程中发生网络异常,如何保证消息的可达性?
- 请求量突增导致服务无法及时处理,有哪些应对措施?
而这些问题,都会交给 RPC 框架来处理
小结
- 本地函数调用和RPC调用的区别:函数映射、数据转成字节流、网络传输
- RPC的概念模型:User、User-Stub、RPC-Runtime、Server-Stub、Server
- 一次PRC的完整过程,并讲解了RPC的基本概念定义
- RPC 带来好处的同时也带来了不少新的问题,将由RPC框架来解决
分层设计
主要分为三层:编解码层、协议层、网络通信层
编解码层
生成代码
通过对统一格式的 IDL 文件解析生成不同语言的代码
数据格式
-
语言特定的格式
许多编程语言都内建了将内存对象编码为字节序列的支持,例如Java有 java.io.Serializable,但是不能跨语言,局限性较大
-
文本格式
JSON、XML、CSV等文本格式,具有人类可读性,但一般没有什么约束且调试困难,并且 JSON 在很多语言中多是以反射机制来解析,性能较差
-
二进制编码
具备跨语言和高性能等优点,常见有Thrift的 BinaryProtocol,Protobuf 等,实现可以有多种形式,例如 TLV 编码 和 Varint 编码
二进制编码
TLV 编码:
- Tag:标签,可以理解为类型
- Lenght:长度
- Value:值,Value 也可以是个TLV结构
例子:
struct Person {
1: required string userName,
2: optional i64 favoriteNumber,
3: optional list<string> interests
}
在编码中,字段名被抹去,取而代之的是 field name,这样可以减小长度,而像 int64 这种大家都知道的定长类型则抹去长度描述,list 类型可以类比普通类型进行嵌套。
但是 T 和 L 仍旧是对于值传递而言的冗余项
选型
-
兼容性
支持自动增加新的字段,而不影响老的服务,这将提高系统的灵活度
-
通用性
支持跨平台、跨语言(还有流行程度,是否成熟)
-
性能
从空间和时间两个维度来考虑,也就是编码后数据大小和编码耗费时长
协议层
概念
为了防止类似于粘包一类事件,大致有以下两种格式
-
特殊结束符
一个特殊字符作为每个协议单元结束的标示
-
变长协议
以定长加不定长的部分组成,其中定长的部分需要描述不定长的内容长度
协议构造
以 Thrift 的 THeader 协议为例:
- LENGTH:数据包大小,不包含自身
- HEADER MAGIC:标识版本信息,协议解析时候快速校验
- SEQUENCE NUMBER:表示数据包的seqID,可用于多路复用,单连接内递增
- HEADER SIZE:头部长度,从第14个字节开始计算一直到 PAYLOAD前
- PROTOCOL ID:编解码方式,有Binary和Compact两种
- TRANSFORM ID:压缩方式,如zlib 和snapp
- INFO ID:传递一些定制的 meta 信息
- PAYLOAD:消息体
协议解析
先读取 MagicNumber,获取协议版本信息,再获取编解码方式,最后去解析 Payload
网络通信层
Socket API
介于传输层和应用层
- 阻塞 IO 下,耗费一个线程去阻塞在 read(fd) 去等待用足够多的数据可读并返回。
- 非阻塞 IO 下,不停对所有 fds 轮询 read(fd) ,如果读取到 n <= 0 则下一个循环继续轮询。
第一种方式浪费线程(会占用内存和上下文切换开销),第二种方式浪费 CPU 做大量无效工作。而基于 IO 多路复用系统调用实现的 Poll 的意义在于将可读/可写状态通知和实际文件操作分开,并支持多个文件描述符通过一个系统调用监听以提升性能。 网络库的核心功能就是去同时监听大量的文件描述符的状态变化(通过操作系统调用),并对于不同状态变更,高效,安全地进行对应的文件操作。
网络库
-
提供易用API
- 封装底层Socket API
- 连接管理和事件分发
-
功能
- 协议支持:tcp、udp和uds等
- 优雅退出、异常处理等
-
性能
- 应用层buffer减少copy
- 高性能定时器、对象池等
小结
- RPC框架主要核心有三层:编解码层、协议层和网络通信层
- 二进制编解码的实现原理和选型要点
- 协议的一般构造,以及框架协议解析的基本流程
- 网络库的基本架构,以及选型时要考察的核心指标
关键指标
稳定性
保障策略
- 熔断:保护调用方,防止被调用的服务出现问题而影响到整个链路
- 限流:保护被调用方.防止大流量把服务压垮
- 超时控制:避免浪费资源在不可用节点上
请求成功率
保障手段:
- 负载均衡
- 重试
长尾请求
明显高于平均响应时间的请求,业界关于延迟有一个常用的P99标准,也就是99%的请求延迟要满足在一定耗时以内, 1%的请求会大于这个耗时, 而这1%就可以认为是长尾请求。
Backup Request(备份请求):
左图在请求得到响应后再发出请求会消耗较长时间,右图,在等待 t3 时间(即 99% 请求延迟)后还未收到响应则发送 retry
注册中间件
在创建 Client 和 Server 时就可以灵活地创建,可以看看 CloudWeGo 的官方文档
易用性
-
开箱即用
- 合理的默认参数选项、丰富的文档
-
周边工具
- 生成代码工具、脚手架工具
扩展性
-
Middleware
middleware 会被构造成一个有序调用链逐个执行,比如服务发现、路由、负载均衡、超时控制等
-
Option
作为初始化参数
-
编解码层
-
协议层
-
网络传输层
-
代码生成工具插件扩展
观测性
-
Log:方便定位错误
-
Metric:监控,通过监控面板查看 QPS、延迟等信息
-
Tracing:链路追踪,查看链路上各环节耗时等信息
-
内置观察服务:将内部信息部分暴露,方便观察内部状态
- 当前环境变量
- 配置参数
- 缓存信息
- 内置 pprof 服务用于排查问题
高性能
场景
- 单机多机
- 单连接多连接
- 单/多client 单/多server
- 不同大小的请求包
- 不同请求类型:例如pingpong、streaming等
目标
- 高吞吐
- 低延迟
手段
- 连接池
- 多路复用
- 高性能编解码协议
- 高性能网络库
- 连接池和多路复用:复用连接,减少频繁建联带来的开销
- 高性能编解码协议:Thrift、Protobuf、Flatbuffer 和 Cap'n Proto 等
- 高性能网络库:Netpoll 和 Netty 等
小结
- 框架通过中间件来注入各种服务治理策略,保障服务的稳定性
- 通过提供合理的默认配置和方便的命令行工具可以提升框架的易用性
- 框架应当提供丰富的扩展点,例如核心的传输层和协议层
- 观测性除了传统的Log、Metric和Tracing之外,内置状态暴露服务也很有必要
- 性能可以从多个层面去优化,例如选择高性能的编解码协议和网络库