RPC框架学习了解 ｜ 青训营

kanier
139 阅读6分钟

RPC框架

基本概念

远程过程调用

RPC（ Remote procedure call）是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

RPC需要解决的问题

  1. 函数映射
  2. 数据转换成字节流
  3. 网络传输

RPC概念模型

RPC概念模型.png

RPC过程

  1. IDL (Interface description language)文件
    IDL通过—种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信
  2. 生成代码
    通过编译器工具把,IDL文件转换成语言对应的静态库
  3. 编解码
    从内存中表示到字节序列的转换称为编码，反之为解码，也常叫做序列化和反序列化
  4. 通信协议
    规范了数据在网络中的传输内容和格式。除必须的请求/响应数据外，通常还会包含额外的元数据
  5. 网络传输
    通常基于成熟的网络库走TCP/UDP传输

使用好处

  1. 单一职责，有利于分工协作和运维开发
  2. 可扩展性强，资源使用率更优
  3. 故障隔离，服务的整体可靠性更高

有什么问题

  1. 服务宕机，对方应该如何处理?
  2. 在调用过程中发生网络异常，如何保证消息的可达性?
  3. 请求量突增导致服务无法及时处理，有哪些应对措施?

分层设计

分层-ApacheThrift

分层设计-ApacheThrift.png

编解码层

客户端和服务端依赖同一份IDL文件生成不同语言（Golang、C++、java等）的CodeGen。

数据格式：

  • 语言特定的格式
    • 许多编程语言都内建了将内存对象编码为字节序列的支持，例如Java有java.io.Serializable
  • 文本格式
    • JSON、XML、CSV等文本格式，具有人类可读性
  • 二进制编码
    • 具备跨语言和高性能等优点，常见有Thrift的 BinaryProtocol，Protobuf 等
    • TLV编码：
      • Tag:标签，可以理解为类型
      • length:长度
      • Value:值，Value 也可以是个TLV结构

选型：

  • 兼容性
    • 支持自动增加新的字段，而不影响老的服务，这将提高系统的灵活度
  • 通用性
    • 支持跨平台、跨语言
  • 性能
    • 从空间和时间两个维度来考虑，也就是编码后数据大小和编码耗费时长

协议层

概念：

  • 特殊结束符
    • 一个特殊字符作为每个协议单元结束的标示
  • 变长协议
    • 以定长加不定长的部分组成，其中定长的部分需要描述不定长的内容长度

协议构造：

LENGTH:数据包大小，不包含自身
HEADER MAGlC:标识版本信息，协议解析时候快速校验
SEQUENCE NUMBER:表示数据包的seqlD,可用于多路复用，单连接内递增
HEADER SIZE:头部长度，从第14个字节开始计算一直到PAYLOAD前
PROTOCOL ID:编解码方式，有Binary和Compact 两种
TRANSFORM ID:压缩方式，如zlib 和snappy
INFO ID:传递一些定制的meta 信息
PAYLOAD:消息体

协议解析.png

网络通信层

Sockets API：位于应用层；

SocketAPI.png

网络库：

  • 提供易用API
    • 封装底层Socket API
    • 连接管理和事件分发
  • 功能
    • 协议支持: tcp、udp 和uds 等
    • 优雅退出、异常处理等
  • 性能
    • 应用层 buffer 减少copy
    • 高性能定时器、对象池等

RPC指标

稳定性分析

保障策略：

  • 熔断:保护调用方，防止被调用的服务出现问题而影响到整个链路
  • 限流:保护被调用方，防止大流量把服务压垮
  • 超时控制:避免浪费资源在不可用节点上

重试策略

长尾请求：长尾请求一般是指明显高于均值的那部分占比较小的请求。 业界关于延迟有一个常用的P99标准， 也就是99%的请求延迟要满足在一定耗时以内， 1%的请求会大于这个耗时， 而这1%就可以认为是长尾请求。

注册中间件

易用性

  • 开箱即用
    • 合理的默认参数选项、丰富的文档
  • 周边工具
    • 生成代码工具、脚手架工具

扩展性

  • Middleware
  • Option
  • 编解码层
  • 协议层
  • 网络传输层
  • 代码生成工具插件扩展

观测性

  • Log打印日志、Metric观测面板、Tracing链路追踪
  • 内置观测性服务

高性能

根据不同场景（单机多机、单连接多连接、单/多 client/server）需求不一致。

目标： 高性能、低延迟
手段：

  • 连接池
  • 多路复用
  • 高性能编解码协议
  • 高性能网络库

企业实践

一脸懵逼.png

Kitex

  • Kitex Core核心组件
  • Kitex Byted与公司内部基础设施集成
  • Kitex Tool代码生成工具

自研网络库

背景:

  1. 原生库无法感知连接状态 在使用连接池时，池中存在失效连接，影响连接池的复用。
  2. 原生库存在goroutine暴涨的风险 一个连接一个qoroutine的模式，由于连接利用率低下，存在大量 goroutine占用调度开销，影响性能。

Netpoll

  • 解决无法感知连接状态问题
    • 引入epoll主动监听机制，感知连接状态
  • 解决goroutine暴涨的风险
    • 建立goroutine池，复用goroutine
  • 提升性能
    • 引入Nocopy Buffer，向上层提供NoCopy的调用接口，编解码层面零拷贝

扩展性设计

支持多协议，也支持灵活的自定义协议扩展

扩展性.png

性能优化

网络库优化

  • 调度优化
    • 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

合并部署

  • 微服务过微，传输和序列化开销越来越大
  • 将亲和性强的服务实例尽可能调度到同一个物理机，远程RPC调用优化为本地IPC调用

优化：

  • 中心化的部署调度和流量控制
  • 基于共享内存的通信协议
  • 定制化的服务发现和连接池实现
  • 定制化的服务启动和监听逻辑
avatar
文章
阅读
粉丝