RPC学习 | 青训营笔记

91 阅读4分钟

这是我参与「第五届青训营」伴学笔记创作活动的第14天


1、基本概念

1.1、远程函数调用(RPC -Remote Procedure Calls)

image.png
RPC 需要解决的问题

  • 函数映射
  • 数据转换成字节流
  • 网络传输
1.2、一次RPC的完整过程
  • IDL (Interface description language)文件
    • IDL通过一种中立的方式来描述接口,使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信
  • 生成代码
    • 通过编译器工具把,IDL文件转换成语言对应的静态库
  • 编解码
    • 从内存中表示到字节序列的转换称为编码,反之为解码,也常叫做序列化和反序列化
  • 通信协议
    • 规范了数据在网络中的传输内容和格式。除必须的请求/响应数据外,通常还会包含额外的元数据
  • 网络传输
    • 通常基于成熟的网络库走TCP/UDP传输
1.3、 RPC的好处
  • 单一职责,开发(采用不同的语言)、部署以及运维(上线独立)都是独立的,有利于分工协作和运维开发
  • 可扩展性强,资源使用率更优。例如压力过大的时候可以独立扩充资源,底层基础服务可以复用,节省资源
  • 故障隔离,服务的整体可靠性更高

2、分层统计

2.1、分层设计–以Apache Thrift为例

image.png

2.2、编解码层–数据格式
  • 语言特定的格式
    • 许多编程语言都内建了将内存对象编码为字节序列的支持,例如Java有java.io.Serializable
    • 这种编码形式好处是非常方便,可以用很少的额外代码实现内存对象的保存与恢复,这类编码通常与特定的编程涯言深瘦绑定,其能语言很淮读取达种数据,。如果以这类编码存储或传输数据,那你就和这门语言绑死在一起了。安全和兼容性也是问题
  • 文本格式
    • JSON、XML、CSV等文本格式,具有人类可读性
    • 文本格式具有人类可读性,数字的编码多有歧义之处,比如XML和CSV不能区分数字和字符串,JSON虽然区分字符部和数字,但是不区分整数和浮点数,而且不能指定精度,处理大量数相时,这个何题更严重了;没有强制模型约束,实际操作中往往只能采用文档方式来进行约定,这可能会给调试带来一些不便。由于JSON在一些语言中的序列化和反序列化需要采用反射机制,所以在性能比较差;
  • 二进制编码
    • 具备跨语言和高性能等优点,常见有Thrift的 BinaryProtocol,Protobuf等
2.3、二进制编码

TLV编码

  • Tag:标签,可以理解为类型
  • Lenght:长度
  • Value:值,Value也可以是个TLV结构
2.4、选型
  • 兼容性
    • 支持自动增加新的字段,而不影响老的服务,这将提高系统的灵活度
  • 通用性
    • 支持跨平台、跨语言
  • 性能
    • 从空间和时间两个维度来考虑,也就是编码后数据大小和编码耗费时长
2.5、概念
  • 特殊结束符
    • 一个特殊字符作为每个协议单元结束的标示
  • 变长协议
    • 以定长加不定长的部分组成,其中定长的部分需要描述不定长的内容长度
2.6、网络库
  • 提供易用API
    • 封装底层Socket API
    • 连接管理和事件分发
  • 功能
    • 协议支持:tcp、udp和uds等
    • 优雅退出、异常处理等
  • 性能
    • 应用层buffer减少copy
    • 高性能定时器、对象池等

3、关键指标

3.1、稳定性–保障策略
  • 熔断:保护调用方,防止被调用的服务出现问题而影响到整个链路
  • 限流:保护被调用方,防止大流量把服务压垮
  • 超时控制:避免浪费资源在不可用节点上
3.2、稳定性–请求成功率
3.3、稳定性–长尾请求

长尾请求一股是指明显高于均值的那部分占比较小的请求。业界关于延迟有一个常用的P99标准,P99单个请求响应耗时从小到大排列,顺序处于99%位置的值即为P99值,那后面这1%就可以认为是长尾请求,在较复杂的系统中,长尾延时总是会存在。造成这个的原因非常多,常见的有网络抖动,GC,系统调度。

3.4、稳定性–注册中间件
3.5、易用性
  • 开箱即用
    • 合理的默认参数选项、丰富的文档
  • 周边工具
    • 生成代码工具、脚手架工具
3.6、扩展性
  • Middleware
  • Option
  • 编解码层
  • 协议层
  • 网络传输层
  • 代码生成工具插件扩展 image.png