深入浅出RPC框架(Golang)
这是我参与「第三届青训营 -后端场」笔记创作活动的第3篇笔记
[TOC]
基本概念
本地函数调用
func main() {
var a = 2
var b = 3
result := calculate(a, b)
fmt.Println(result)
return
}
func calculate(a, b int) {
z := a * b
return z
}
远程函数调用
RPC - Remote Procedure Calls
RPC要解决的问题
- 函数映射
- 数据转换成字节流
- 网络传输
RPC相关基本概念
- IDL文件
Interface description language:通过一种中立的方式来描述接口,使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信
- 生成代码
通过编译器工具把IDL文件转换成语言对应的动态库
- 编解码
从内存中表示到字节序列的转换称为编码,反之为解码,也常叫做序列化和反序列化
- 通信协议
规范数据在网络中的传输内容和格式,除必须的请求/响应数据外,通常还包括额外的元数据
- 网络传输
通常基于成熟的网络库通过TCP和UDP协议传输
RPC概念模型

RPC的好处
- 单一职责,有利于分工协作和运维开发
- 可扩展性强,资源使用率优
- 故障隔离,服务整体的可靠性更好
RPC存在的问题
- 服务宕机,对方该如何处理?
- 在调用过程出现网络异常,如何保证消息的可达性?
- 请求量突增导致服务无法及时处理,有哪些应对措施?
分层设计
RPC框架分层设计(以Apache Thrift为例)
| Client | Server | 端 |
|---|---|---|
| Code | Code | 用户自己编写的业务逻辑代码 |
| Service.client read/write | Service.Processor read/write | 通过代码生成工具将IDL文件转换成不同语言对应的lib代码,封装了编解码逻辑 |
| TProtocal | TProtocal | 编解码层 |
| TTRansport | TTransport | 协议层 |
| ... | ... | ... |
| Network IO | Network IO | 网络通信层 |
编解码层
生成代码
Client和Server都依赖于同一份IDL文件,一份IDL文件可以生成不同语言(Golang,C++,Java)的CodeGen
数据格式
- 语言特定格式
语言自身将内存对象编码为字节序列的支持,如Java中的
java.io.Serializable - 文本格式
Json,XML,CSV等,具有
人类可读性 - 二进制编码
跨语言特性
二进制编码
TLV 编码 Tag:标签(类型) Length:长度 Value:值,也可以是一个TLV结构
struct Person {
1: required string userName,
2: optional i64 favoriteNumber,
3: optional list<string> interests
}

选型
- 兼容性
支持自动增加新的字段,不影响老的服务,提高系统的灵活度
- 通用性
支持跨平台,跨语言
- 性能
编码后数据的大小和编码耗费时长
协议层
协议层相关概念
- 特殊结束符
一个特殊的,作为每个协议单元结束的标识
- 变长协议
由定长和不定长的两部分组成,定长部分的内容需要描述不定长部分的长度
协议构造
| 字段 | 含义 |
|---|---|
| LENGTH | 数据包大小,不包含自身 |
| HEADER MAGIC | 标识版本信息,协议解析时快速校验 |
| SEQUENCE NUMBER | 数据包的seqID,用于多路复用,单连接内递增 |
| HEADER SIZE | 头部长度,从第14个字节开始计算一直到PAYLOAD前 |
| PROTOCOL ID | 编解码方式,Binary和Compact两种 |
| TRANSFORM ID | 压缩方式,如zlib和snappy |
| INFO ID | 传递定制的meta信息 |
| PAYLOAD | 消息体 |
网络通信层
Sockets API(传输层和应用层之间)

关键指标
稳定性
保障策略
- 熔断
保护调用方,防止被调用的服务出现问题而影响整个链路
- 限流
保护被调用方,防止大流量压垮服务
- 超时控制
避免浪费资源在不可用节点上
请求成功率
提高请求成功率主要有两种方式:负载均衡、重试
长尾请求
请求时间明显长于请求平均时间的请求
假设平均时间为a,某请求的调用需要b时间才能返回,且a<b
当发送请求并过了a时间后,系统会判断为“可能没有成功调用”并进行retry,但在b时间时,又接收到了返回的请求内容。
当系统retry时,由备份请求机制,更快速的返回相同请求得内容。
措施:备份请求
注册中间件
通过中间件得方式,应用各种稳定性维护措施
易用性
- 开箱即用
- 周边工具
扩展性
- 中间件
- Option
- 编解码层
- 协议层
- 网络通信层
- 代码生成工具扩展插件
观测性
- Log
- Metric
- Tracing
- 内置得观测性服务
高性能
- 高吞吐
- 低延迟
常见场景:
- 单机多机
- 单连接多连接
- 单/多Client,单/多Server
- 不同大小得请求包
- 不同得请求类型
手段:
- 连接池
- 多路复用
- 高性能编解码协议
- 高性能网络库
企业实践
整体架构(Kitex)
- Kitex Core
- Kitex Byted
- Kitex Tool

- register:注册中心
- discovery:服务发现
- loadbalance:负载均衡
- circuitbreak:熔断
- retry:重试
- limit:限流
自研网络库
背景
- 原生库无法感知连接状态
- 原生库存在Goroutine暴涨的风险
Netpoll
- 解决无法感知连接状态:引入epoll主动监听机制,感知连接状态
- 解决Goroutine暴涨的风险:建立goroutine,复用
- 提升性能:引入Nocopy Buffer,向上提供NoCopy的调用接口,编解码层零拷贝
扩展性设计
支持多协议,也支持灵活的自定义协议扩展
| item | content |
|---|---|
| Interaction | Ping-Pong/Steaming/Oneway |
| Codec | Thrift/Protobuf |
| Application Layer Protocol | TTHeader/HTTP2 |
| Transport Layer | TCP/UDP/RDMA |
性能优化
网络库优化
- 调度优化
epoll_wait在调度上的控制 gopool重用goroutine降低同时运行的携程数
- LinkBuffer
读写并行无锁,支持nocopy 高效扩容缩容 Nocopy Buffer池化,减少GC
- Pool
引入内存池和对象池,减少GC开销