这是我参与「第三届青训营 -后端场」笔记创作活动的的第5篇笔记
RPC框架
RPC框架核心层次
- 编解码层
- 协议层
- 网络通信层
编解码层
IDL
Client与Server依赖同一份IDL文件，生成对应语言的编解码层。定义了不同服务之间的接口与响应内容
数据格式
- 语言特点格式: 兼容性不强(不同语言不互通)，但是许多编程语言内建了将内存对象编码为字节序列的支持
- 文本格式: 约束不强，精度不高，性能强
- 二进制编码： 跨语言高性能等。 eg. Thrift的 BinaryProtocol Protobuf等
二进制编码--TLV编码
- Tag：标签，可以理解为类型
- Lenght： 长度
- Value: 值 也可以是一个TLV结构 示例：
Tag存储传输属性的序号，减少消耗
编码格式选择
从以下几点加以考虑
- 兼容性：支持自动新增字段，不影响现有服务，提高系统灵活度
- 通用性： 支持跨平台、跨语言，以及流行程度
- 性能： 空间：编码后数据大小 时间：编码耗费时长
协议层
约定通讯协议，还可以添加额外的元数据
- 特殊结束符：以特殊字符作为每个协议单元结束的表示
- 边长协议：以定长加不定长的部分组成，其中定长部分需要描述不定长的内容长度
协议构造
协议解析
网络通信层
通过Sockets API传输
实际使用封装好的网络库
- 提供建议API
- 封装底层Socket API
- 连接管理和事件分发
- 功能
- 协议支持： tcp、udp 和 uds等
- 优雅退出、异常处理等
- 性能
- 应用层buffer减少copy
- 高性能定时器、对象池等
关键指标
稳定性
保障策略
- 熔断：保护调用方，防止被调用的服务出现问题而影响到整个链路
- 限流: 保护背调用方，防止大流量把服务压垮
- 超时控制：避免浪费资源在不可用结点上
请求成功率
- 负载均衡，防止单个结点压力过大
- 重试 出错时请求重试
长尾请求
长尾请求：明显高于平均时间，占比较少的请求
如何提高：BackupRequest
正常在resp1后才会进行req2 总时间 = t1 + t2
设置时间t3 超过t3则进行第二次尝试 总时间 = t4
实现方式
通过注册中间件添加稳定性策略
易用性
- 易用性
- 合理默认参数选项、丰富的文档
- 周边工具
- 生成代码工具、脚手架工具
扩展性
通过中间件注入
观测性
- Log、Metric、Tracing
- 内置观测服务
高性能
目标
- 高吞吐
- 低延迟 在不同场景下加以考虑(单机多机、单连接多连接等)
手段
- 连接池
- 多路复用
- 高性能编解码协议
- 高性能网络库
