深入浅出RPC框架|青训营笔记

doris_dan
145 阅读1小时+

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记。

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png 这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png 这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。 image.png 这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png 这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同

  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

      ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/af0ef390778b428f9ff3c8f769c111b2~tplv-k3u1fbpfcp-watermark.image?)
    • 重试 image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。 image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。 image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。 image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。 image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png

扩展性设计

image.png

性能优化

image.png

image.png

这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记」

基本概念

本地函数调用

远程函数调用

  • RPC需要解决的问题
    • 函数映射
      • 本地根据函数指针指定函数体，远程是两个进程，地址空间完全不一样，每个函数需要自己的id，根据id对应关系映射）
    • 数据转换成字节流
      • 本地参数可压栈（本地通过内存传参）， 远程的客户端服务器地址不同，需要转换字节流
    • 网络传输

RPC 概念模型

  • 组成：User， User-stub,RPC-Runtime,Server-Stub, Server

一次RPC的完整过程

  • IDL：双方不知道对方有哪些调用方法，需要协商调用方式

RPC的好处

  • 单一职责，有利于分工协作和运维开发，每个服务都是可独立进行开发
  • 可扩展性强，资源使用率更优
    • 资源利用率：底层服务可复用，双十一只需对shopping服务进行改进扩容等等
  • 故障隔离，服务的整体可靠性更高

RPC带来的问题

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

RPC框架

分层设计

编解码层

  • 生成代码

  • 数据格式

    • 语言特定的格式，内置将内存对象编码为字节序列的支持，java.io.Serializable，缺点是语言限制
    • 文本格式， 人类可读性，但描述不严谨，json字符串无法区分整数浮点数
    • 二进制编码，具备跨语言和高性能等优点，Thrift的BinaryProtocol，Protobuf等

  • 二进制编码 TLV编码缺点：增加了typeof length 冗余信息，开销增大。 自行了解改进空间。

  • 选型

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

协议层

  • 概念

  • 协议构造

  • 协议解析 MagicNumebr？

网络通信层

  • Sockets API

  • 网络库，使用封装好的工具

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

关键指标（构建RPC框架）

稳定性

  • 保障策略
    • 熔断：保护调用方，防止被调用的服务出现问题（一直超时等待，堆积大量请求）而影响整个链路
    • 限流，防止大流量把服务（被调用方）压垮
    • 超时控制：避免浪费资源在不可用节点上
  • 请求成功率（如何提高）
    • 负载均衡，防止每个节点压力过大
  • 长尾请求 backup request提高请求成功率 req1发出后，认为应在t3时间内返回
  • 注册中间件

易用性

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

扩展性

  • 中间件
  • 可选参数
  • 编解码层- 不同，可选
  • 协议层- 不同，可选
  • 传输层- 不同，可选
  • 生成工具插件扩展

观测性

  • 三件套： log metric tracing
  • 内置观测性服务，了解框架内部的运行状况，例如：linux中的top

高性能

  • 目标：高吞吐和低延迟
  • 场景
    • 单机多机
    • 单连接 多连接
    • 单、多client or server
    • 不同大小的请求包
  • 手段
    • 连接池 （复用，提高资源利用率）
    • 多路复用
    • 高性能编解码协议
    • 高性能网络库
    • 不同请求类型

企业实践

整体架构（Kitex）

  • kitex core 核心组件
  • kitex byted 与公司内部基础设施集成
  • kitex tool 代码生成工具

自研网络库

背景

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

合并部署

  • 微服务过微，传输和序列化开销越来越大，但不可能把已经上线的服务进行合并，每个服务负责的团队也不同
  • 将亲和性强的服务实例尽可能调度到同一个物理机上，远程RPC调用优化为本地IPC调用。

image.png

avatar
文章
阅读
粉丝