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

一、本堂课重点内容

基本概念
分层设计
关键指标
企业实践

二、详细知识点介绍

1. 基本概念

1.1 本地函数调用

func main(){
    var a = 2
    var b = 3
    result := calculate(a,b)
    fmt.Println(result)
    return
}

func calculate(x, y int){
    z := x*y
    return z
}

将 a 和 b 的值压栈
通过函数指针找到 calculate 函数，进入函数取出栈中的值 2 和 3，将其赋予 x 和 y
计算 x * y，并将结果存在 z
将 z 的值压栈，然后从 calculate 返回
从栈中取出 z 返回值，并赋值给 result

编译器实际上会做优化，对于参数和返回值少的情况会直接将其存放在寄存器，而不需要压栈弹栈的过程，甚至都不需要调用 call ，而直接做 inline 操作

1.2 远程函数调用（RPC - Remote Procedure Calls）

RPC 需要解决的问题：

函数映射
- 我们怎么告诉支付服务我们调用付款这个函数，而不是退款或者充值呢？在本地调用中，函数体是直接通过函数指针来指定的，我们调用哪个方法，编译器就自动帮我们调用它相应的函数指针。但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以函数都有自己的一个ID，在做 RPC 的时候要附上这个 ID，还得有个 ID 和函数的对照关系表，通过 ID 找到对应的函数并执行。
数据转换成字节流
网络传输

客户端怎么把参数值传给远程函数呢？
- 在本地调用中，我们只需把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。这时候就需要客户端把参数先转换成一个字节流，传给服务端后，再把字节流转换成自己能读取的格式

1.3 RPC 概念模型

1984年，Nelson 发表了论文《Implementing Remote Procedure Calls》，其中提出了 RPC 的过程由5个模型组成：User、User-Stub、RPC-Runtime、Server-Stub、Server

1.4 一次 RPC 的完整过程

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

1.5 RPC 的好处

单一职责，有利于分工协作和运维开发
- 单一职责，开发（采用不同的语言）、部署以及运维（上线独立）都是独立的
可扩展性强，资源使用率更优
- 例如压力过大的时候可以独立扩展资源，底层基础服务可以复用，节省资源
故障隔离，服务的整体可靠性更高
- 某个模块发生故障，不会影响整体的可靠性

1.6 RPC 带来的问题

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

2. 分层设计

2.1 分层设计 - 以 Apache Thrift 为例

2.2 编解码层

2.2.1 生成代码

2.2.2 数据格式

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

2.2.3 二进制编码

TLV编码

Tag：标签，可以理解为类型
Length：长度
Value：值，也可以是个TLV结构

这里我们看到第一个byte是类型，主要是用来表示是string还是int还是list等，这里这里不写key的字符串，比如上面的userName,favoriteNumber等等，取而代之的是一个field tag的东西，这个会设置成1，2，3和上面的schema中key字符串前面的数字，也就是用这里来取代了具体的key值，从而减小的总体的大小，这里打包后压缩到59个字节
TLV编码结构简单清晰，并且扩展性较好，但是由于增加了Type和Length连个冗余信息，有额外的内存开销，特别是大部分字段都是基本类型的情况下有不小的空间浪费

2.2.4 选型

兼容性
- 支持自动增加新的字段，而不影响老的服务，这将提高系统的灵活度
- 移动互联时代，业务需求的更新周期变得更快，新的需求不断涌现，而老的系统还是需要继续维护。如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，而不影响老的服务，这将大大提高系统灵活度
通用性
- 支持跨平台、跨语言
- 有两个层面的意义：
  - 第一、技术层面，序列化协议是否支持跨平台、跨语言。如果不支持，在技术层面上的通用性就大大降低了
  - 第二、流行程度，序列化和反序列化需要多方参与，很少人使用的协议往往意味着昂贵的学习成本；另一方面，流行程度低的协议，往往缺乏稳定而成熟的跨语言、跨平台的公共包
性能
- 从空间和时间两个维度来考虑，也就是编码后数据大小和编码耗费时长

2.3 协议层

2.3.1 概念

协议是双方确定的交流语义，比如：我们设计一个字符串传输的协议，它允许客户端发送一个字符串，服务端接收到对应的字符串。这个协议很简单，首先发送一个4字节的消息总长度，然后再发送1字节的charset长度，接下来就是消息的payload，字符集名称和字符串正文。

特殊结束符
- 一个特殊字符作为每个协议单元结束的标示
- 过于简单，对于一个协议单元必须要全部读入才能进行处理，除此之外必须要防止用户传输的数据不能同结束符相同，否则就会出现紊乱
- HTTP协议头就是以回车（CR）加换行（LF）符号序列结尾
变长协议
- 一般都是自定义协议，有 header 和 payload 组成，会以定长加不定长部分组成，其中定长的部分需要描述不定长的内容长度，使用比较广泛

2.3.2 协议构造

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

2.3.3 协议解析

2.4 网络通信层

2.4.1 SOCKET API

2.4.2 网络库

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

2.5 总结

RPC框架主要核心有三层：编解码层、协议层和网络通信层
二进制编解码的实现原理和选型要点
协议的一般构造，以及框架协议解析的基本流程
Socket API 的调用流程，以及选型网络库时要考察的核心指标

3. 关键指标

3.1 稳定性

3.1.1 保障策略

熔断：保护调用方，防止被调用的服务出现问题而影响到整个链路
- 一个服务A调用服务B时，服务B的业务逻辑又调用了服务C，而这时服务C响应超时了，由于服务B依赖服务C，C超时直接导致B的业务逻辑一直等待，而这个时候服务A继续频繁地调用服务B，服务B就可能会因为堆积大量的请求而导致服务宕机，由此就导致了服务雪崩的问题
限流：保护被调用方，防止大流量把服务压垮
- 当调用端发送请求过来时，服务端在执行业务逻辑之前先执行检查限流逻辑，如果发现访问量大并且超出了限流条件，就让服务端直接降级处理或者返回给调用方一个限流异常
超时控制：避免浪费资源在不可用的节点上
- 当下游的服务因为某种原因响应慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，避免浪费资源。

从某种程度上讲，超时、限流、熔断也是一种服务降级的手段。

3.1.2 请求成功率

负载均衡、重试

注意，因为重试有放大故障的风险，首先重试会加大直接下游的负载。如上图，假设A服务调用B服务，重试次数为r（包括首次请求），当B高负载时很可能调用不成功，这时A调用失败重试B，B服务的被调用量快速增大，最坏情况下可能放大到r倍，不仅不能请求成功，还可能导致B的负载继续升高，甚至打挂。

防止重试风暴，限制单点重试和链路重试

3.1.3 长尾请求

Backup Request

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

我们先预先设定一个阈值t3（比超时时间小，通常建议是RPC请求延时的pct99），当Req1发出去后超过t3时间都没有返回，那我们直接发起重试请求Req2，这样相当于同时有两个请求运行。然后等待请求返回，只要Resp1或者Resq2任意一个返回成功的结果，就可以立即结束这次请求，这样整体的耗时就是t4，它表示从第一个请求发出到第一个成功返回之间的时间，相比于等待超时后再发出请求，这种机制大大减少整体延时。

3.2 稳定性 —— 注册中间件

Kitex Client 和 Server 的创建接口均采用Option 模式，提供了极大的灵活性，很方便就能注入这些稳定性策略。

3.3 易用性

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

简单易用的命令行工具：

生成服务代码脚手架
支持 protobuf 和 thrift
内置功能丰富的选项
支持自定义的生成代码插件

Kitex 使用 Suite 来打包自定义的功能，提供“一键配置基础依赖”的体验

3.4 扩展性

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

一次请求发起首先会经过治理层面，治理相关的逻辑被封装在middleware中，这些middleware会被构造成一个有序调用链逐个执行，比如服务发现、路由、负载均衡、超时控制等，mw执行后就会进入到remote模块，完成与远端的通信

3.5 观测性

Log、Metric、Tracing
内置观测性服务

除了传统的Log、Metric、Tracing三件套之外，对于框架来说可能还不够，还有些框架自身状态需要暴露出来，例如当前的环境变量、配置、Client/Server初始化参数、缓存信息等

3.6 高性能

目标
- 高吞吐
- 低延迟
场景
- 单机多机
- 单连接多连接
- 单/多client 单/多server
- 不同大小的请求包
- 不同的请求类型：例如pingpong、streaming等
手段
- 连接池
- 多路复用
  - 大大减少了连接带来的资源消耗，并且提升了服务端性能，我们的测试中的服务端吞吐可提升30%
  - 调用端向服务端一个节点发送请求，并发场景下，如果是非连接多路复用，每个请求都会持有一个连接，直到请求结束连接才会被关闭或者放入连接池复用，并发量与连接数是对等的关系。
  - 使用多路复用，所有请求都可以在一个连接上完成，大家可以明显看到连接资源利用上的差异
- 高性能编解码协议
- 高性能网络库

3.7 总结

框架通过中间件来注入各种服务治理策略，保障服务的稳定性
通过提供合理的默认配置和方便的命令行工具可以提升框架的易用性
框架应当提供丰富的扩展点，例如核心的传输层和协议层
观测性除了传统的Log、Metric、Tracing之外，内置状态暴露服务也很有必要
性能可以从多个层面去优化，例如选择高性能的编解码协议和网络库

4. 企业实践

企业内部大范围使用go语言进行开发，而 kitex 是内部多年最佳实践沉淀出来的一个高性能高可扩展的 go RPC 框架，在内部有几万个微服务在使用，在去年也开源了回馈给社区。本章节主要了解互联网内部的相关实践经验

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