8-RPC框架
[TOC]
8.1 基本概念
8.1.1 本地函数调用
func main(){
var a=2
var b=3
result := calculate(a,b)
fmt.Println(result)
return
}
func calculate(x,y int) int {
z :=x*y
return z
}
过程：
- 将a,b的值压栈
- 通过函数指针找到calculate函数，进入函数取出栈中的值2，3，将其赋予给x，y
- 计算x*y，结果存在z
- 将z的值压栈，从calculate函数返回
- 栈中取出z返回值，赋值给result
8.1.2 远程函数调用RPC
RPC ：Remote Procedure Calls
例子：网上购物时，需要支付时，去调用支付服务，再返回
解决问题：
- 函数映射：调用哪个函数，每个函数有自己的id，而不像本地一样使用函数指针
- 数据转换成字节流：本地时通过压栈即可，远程是不同的进程不共享内存
- 网络传输：高效、稳定
8.1.3 RPC概念模型
五个模块：
- User
- User-Stub
- RPC-Runtime
- Server-Stub
- Server
8.1.4 一次RPC的完整过程
-
IDL文件
IDL：Interface decription language
通过一种中立的方式来描述接口，使得不同平台上运行的对象和用不同语言编写的程序可以相互通信。是一种约定。
-
生成代码
通过编译器工具把 DL 文件转换成语言对应的静态库。
-
编解码
编码/序列化：内存中表示->字节序列
解码/反序列化：反之
-
通信协议
规范了数据在网络中的传输内容和格式。除必须的请求/响应数据外，通常还会包含额外的元数据。
-
网络传输
通常基于成熟的网络库，走 TCP/UDP 传输。
caller：调用方
callee：被调用方
8.1.5 RPC的好处
- 单一职责，有利于分工协作和运维开发。不同服务可以用不同语言开发，部署和上线都是独立的。
- 可扩展性强，资源使用率更优。
- 故障隔离，服务的整体可靠性更高。
8.1.6 RPC的问题
由RPC框架进行处理
- 服务宕机，对方如何处理
- 网络异常，如何保证消息的可达性
- 请求量突增导致服务无法及时处理，有哪些应对措施
8.2 分层设计
三层：① 编解码层 ② 协议层 ③ 网络通信层
8.2.1 分层
8.2.2 编解码层
生成代码+框架的编解码层
-
生成代码
client和server依赖同一份IDL文件，生成不同语言的代码
-
数据格式
-
语言特定的格式
许多编程语言都内建了将内存对象编码为字节序列的支持，例如 Java 有Java.io.Serializable。
缺点：跟语言绑死了
-
文本格式
JSON、XML、CSV 等文本格式具有人类可读性。
缺点：描述不严谨，可能无法区分
-
二进制编码
具备跨语言和高性能等优点，常见有 Thrift 的 BinaryProtocol，Protobuf 等。
数据->二进制流
-
-
二进制编码
TLV编码
Tag：标签，可以理解为类型
Length：长度
Value：值，value也可以是TLV结构，可嵌套
缺点：有冗余，tag，length额外开销
编码前：
编码后：
-
选型
选择编码格式需要进行的考量
- 兼容性：支持自动增加新的字段，而不影响老的服务，这将提高系统的灵活度。
- 通用性：支持跨平台、跨语言。
- 性能：从空间和时间两个维度来考虑，，也就是编码后数据大小和编码耗费时长。尽量小尽量少
8.2.3 协议层
将数据转换成字节流了，但不是将字节流直接打包了
-
概念
特殊结束符，如\r\n
变长协议：定长+不定长，定长的部分描述不定长部分内容的长度
-
协议构造
-
协议解析
通过magic number得知是什么类型的协议，payload codec得知用什么方式去解码，得到payload。
封装：逆向过程
8.2.4 网络通信层
-
Sockets API
介于应用层和传输层之间
-
网络库
通常使用封装好的网络库
衡量尺标：
-
提供易用API
封装底层Socket API
连接管理和事件分发
-
功能
协议支持：tcp、udp、uds等
优雅退出、异常处理等
-
性能
使用应用层buffer减少copy
高性能定时器、对象池等
-
8.3 关键指标
8.3.1 稳定性
-
保障策略
-
熔断：保护调用方，防止被调用的服务出现问题而影响到整个链路
服务A调用服务B，服务B的业务逻辑依赖服务C，若C响应超时了，由于B依赖C，C超时将直接导致B的业务逻辑一直等待，此时A继续频繁地调用B，B就可能因堆积大量的请求而导致服务宕机。
-
限流：保护被调用方，防止大流量把服务压垮；降级处理或返回异常。
-
超时控制：被调用端响应过慢，调用端及时停止不太重要的请求，快速返回，避免资源浪费在不可用的服务上。
-
以上都可被称为降级
-
-
请求成功率
请求发出去要尽可能是成功的，有返回的。
提高成功率的方式
-
负载均衡：避免某一节点压力过大
-
重试
-
-
长尾请求
指明显高于平均响应时间的那部分占比比较小的请求。
总是存在的
如何提高长尾请求的成功率：Backup Request 备份请求
左边：普通情况，失败后重试，花费t1+t2
右边：设置阈值t3，Req2就是备份请求，只花费t4<t1+t2
减少了长尾请求的延时
-
注册中间件
client和server都可以通过可选的方式把功能加上，灵活地注入稳定性策略，尽可能保障请求和服务的稳定性。
框架通过中间件来注入各种服务治理策略，保障服务的稳定性。
8.3.2 易用性
-
开箱即用：合理的默认参数选项、丰富的文档。拿到RPC框架，不需要做过多地配置就可以使用
-
周边工具：生成代码工具-提高简单易用的命令行工具、脚手架工具-辅助生成一些比较重复的代码；
8.3.3 扩展性
- 中间件
- 参数
- 编解码层
- 协议层
- 网络传输层
- 代码生成工具插件扩展
8.3.4 观测性
观察我的服务当前的什么状况
- Log日志、Metric监控、Tracing链路跟踪
- 内置观测性服务
8.3.5 高性能
- 场景，不同场景下，同一个RPC的表现可能不同
- 单机多机
- 单连接多连接
- 单/多client 单/多server
- 不同大小的请求包，影响编解码的速度和耗时
- 不同请求类型，pingpong，streaming...
- 目标
- 高吞吐
- 低延迟
- 手段
- 连接池，尽可能提高连接的复用率
- 多路复用，尽可能提高连接的复用率
- 高性能编解码协议
- 高性能网络库
8.4 企业实践
公司内部的goRPC：Kitex
8.4.1 整体架构
-
Kitex
-
Kitex Core 核心组件
-
Kitex Byted 与公司内部基础设施集成，公司内部使用的相关组件
-
Kitex Tool 代码生成工具
-
8.4.2 自研网络库
- 背景
- go原生库无法感知连接状态：使用连接池时，池中存在失效连接，影响连接池的复用。
- go原生库存在goroutine暴涨的风险：一个连接一个goroutine的模式，由于连接利用率低下，存在大量goroutine占用调度开销，影响性能。
- Netpoll
- 解决无法感知连接状态问题：引入 epoll 主动监听机制，感知连接状态。
- 解决 goroutine 暴涨的风险：建立 goroutine 池，复用 goroutine。
- 提升性能：引入 Nocopy Buffer，向上层提供 NoCopy 的调用接口，编解码层面零拷贝。...
8.4.3 Kitex扩展性设计
支持多协议，可支持灵活的自定义协议扩展
8.4.5 性能优化
- 网络库优化
- 调度优化
- epoll wait 在调度上的控制
- gopool 重用 goroutine 降低同时运行协程数
- LinkBuffer
- 读写并行无锁，支持 nocopy 地流式读写
- 高效扩缩容
- Nocopy Buffer 池化，减少 GC
- Pool
- 引入内存池和对象池，减少 GC 开销
- 调度优化
- 编解码优化
- Codegen
- 预计算并预分配内存，减少内存操作次数，包括内存分配和拷贝
- 对函数进行Inline操作， 减少函数调用次数和避免不必要的反射操作等
- 自研了 Go 语言实现的 Thrift IDL 解析和代码生成器，支持完善的 Thrift IDL 语法和语义检查，并支持了插件机制 - Thriftgo
- JIT just in time 及时编译
- 使用JIT 编译技术改善用户体验的同时带来更强的编解码性能，减轻用户维护生成代码的负担
- 基于JIT 编译技术的高性能动态 Thrift 编解码器- Frugal
- Codegen
8.4.6 合并部署
微服务过微，传输和序列化开销越来越大，给公司带来资源浪费。
将亲和性强的服务实例尽可能调度到同一个物理机，远程RPC调用优化为本地IPC调用。
如：抖音的开屏服务和广告服务
- 中心化的部署调度和流量控制
- 基于共享内存的通信协议
- 定制化的服务发现和连接池实现
- 定制化的服务启动和监听逻辑
