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

一、 本堂课重点内容

1.1   基本概念

1.2   分层设计

1.3   关键指标

1.4   企业实践

二、 详细知识点介绍

2.1 基本概念

2.1.1 本地函数调用

1.将a和b的值压栈

2.通过函数指针找到calculate函数，进入函数

取出栈中的值2和3，将其赋予×和y

3.计算x*y,并将结果存在z

4.将z的值压栈，然后从calculate返回

5.从栈中取出z返回值，并赋值给result

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

RPC需要解决的问题

1.函数映射

2.数据转换成字节流

3.网络传输

函数映射：

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

客户端怎么把参数值传给远程的函数呢？

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

2.1.3 RPC概念模型

2.1.4 一次RPC的完整过程

lDL(Interface description language)文件

IDL通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信

生成代码

通过编译器工具把IDL文件转换成语言对应的静态库

编解码

从内存中表示到字节序列的转换称为编码，反之为解码，也常叫做序列化和反序列化

通信协议

规范了数据在网络中的传输内容和格式。除必须的请求/响应数据外，通常还会包含额外的元数据

网络传输

通常基于成熟的网络库走TCP/UDP传输

相比本地函数调用，远程调用的话我们不知道对方有哪些方法，以及参数长什么样，所以需要有一种方式来描述或者说声明我有哪些方法，方法的参数都是什么样子的，这样的话大家就能按照这个来调用，这个描述文件就是IDL文件。

编码只是解决了跨语言的数据交换格式，但是如何通讯呢？需要制定通讯协议，以及数据如何传输？我的网络模型如何呢？那就是这里的transfer要做的事情

2.1.5 RPC的好处

1.单一职责，有利于分工协作和运维开发

2.可扩展性强，资源使用率更优

3.故障隔离，服务的整体可靠性更高

2.1.6 RPC带来的问题

1.服务宕机，对方应该如何处理？

2.在调用过程中发生网络异常，如何保证消息的可达性？

3.请求量突增导致服务无法及时处理，有哪些应对措施？

2.2 分层设计

2.2.1分层设计-以Apache Thrift为例

2.2.2 编解码层

2.2.2.1 编解码层-生成代码

2.2.2.2 编辑码层-数据格式

语言特定的格式

许多编程语言都内建了将内存对象编码为字节序列的支持，例如Java有java.io.Serializable

文本格式

JSON、ML、CSV等文本格式，具有人类可读性

二进制编码

具备跨语言和高性能等优点，常见有Thrift的BinaryProtocol,Protobuf等

语言特定编码格式：这种编码形式好处是非常方便，可以用很少的额外代码实现内存对象的保存与恢复，这类编码通常与特定的编程语言深度绑定，其他语言很难读取这种数据。如果以这类编码存储或传输数据，那你就和这门语言绑死在一起了。安全和兼容性也是问题。 强行约定，这可能会给调试带来一些不便。由于JSON在一些语言中的序列化和反序列化需要采用反射机制，所以在性能比较差。

二进制编码：实现可以有很多种，TLV编码和Varint编码

2.2.2.3 二进制编码

TLV编码

Tag：标签，可以理解为类型

Length：长度

Value：值，Value也可以是个TLV结构

这里我们可以看到他的第一个byte是类型，主要用来表示是stringi还是int还是Iist等等。这里不写key的字符串了，比如上面的userName,favoriteNumber

等等，取而代之的是一个field tag的东西，这个会设置成1,2,3和上面的schema中key字符串前面的数字，也就是用这里来取代了具体的key值，从而减小的总体的大小，这里打包后压缩到59个字节

TLV编码结构简单清晰，并目扩展性较好，但是由于增加了Type和Length两个冗余信息，有额外的内存开销，特别是在大部分字段都是基本类型的情况下有不小的空间浪费。

2.2.2.4 选型

兼容性

支持自动增加新的字段，而不影响老的服务，这将提高系统的灵活度

通用性

支持跨平台、跨语言

性能

从空间和时间两个维度来考虑，也就是编码后数据大小和编码耗费时长

通用性：

通用性有两个层面的意义：

第一、技术层面，序列化协议是否支持跨平台、跨语言。如果不支持，在技术层面上的通用性就大大降低了。

第二、流行程度，序列化和反序列化需要多方参与，很少人使用的协议往往意味着昂贵的学习成本；另一方面，流行度低的协议，往往缺乏稳定而成熟的跨语言、跨平台的公共包。

兼容性：

移动互联时代，业务系统需求的更新周期变得更快，新的需求不断涌现，而老的系统还是需要继续维护。如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，而不影响老的服务，这将大大提供系统的灵活度。

2.2.3 协议层

2.2.3.1 概念

特殊结束符：一个特殊字符作为每个协议单元结束的标示

变长协议：以定长如不定长的部分组成，其中定长的部分需要描述不定长的内容长度

特殊结束符：过于简单，对于一个协议单元必须要全部读入才能够进行处理，除此之外必须要防止用户传输的数据不能同结束符相同，否则就会出现紊乱

HTTP协议头就是以回车(CR)加换行LF)符号序列结尾.

变长协议：一般都是自定义协议，有header和payload组成，会以定长加不定长的部分组成，其中定长的部分需要描述不定长的内容长度，使用比较广泛

2.2.3.2 协议构造

LENGTH：数据包大小，不包含自身

HEADER MAGIC：标识版本信息，协议解析时候快速校验

SEQUENCE NUMBER：表示数据包的segID可用于多路复用，单连接内递增

HEADER SIZE：头部长度，从第4个字节开始计算一直到PAYLOAD前

PROTOCOL ID：编解码方式，有Binary和Compact两种

TRANSFORM ID：压缩方式，如ZIib和snappy

INFO ID：传递一些定制的meta信息

PAYLOAD：消息体

LENGTH字段：32bits,包括数据包剩余部分的字节大小，不包含LENGTH自身长度

HEADER MAG1C字段：16bits,值为：0x1O00,用于标识协议版本信息，协议解析的时候可以快速校验

FLAGS字段：16bits,为预留字段，暂未使用，默认值为0x0000

SEQUENCE NUMBER字段：32bits,表示数据包的segld,可用于多路复用，最好确保单个连接内递增

HEADER SIZE字段：16bits,等于头部长度字节数/4，头部长度计算从第14个字节开始计算，一直到PAYLOAD前（备注：header的最大长度为64K)

PROTOCOL ID字段：uint8编码，取值有：~ ProtocollDBinary =0 、ProtocollDCompact 2

NUM TRANSFORMS字段：uint8编码，表示TRANSFORM个数

TRANSFORM ID字段：uint8编码，具体取值参考下文，表示压缩方式zlib or snappy

INFO ID字段：uint8编码，具体取值参考下文，用于传递一些定制的meta信息

PAYLOAD：消息内容

2.2.3.3 协议解析

2.2.4 网络通信层

2.2.4.1 网络通信层~Sockets APl

套接字编程中的客户端必须知道两个信息：服务器的IP地址，以及端口号。

socketl函数创建一个套接字，bind将一个套接字绑定到一个地址上。istn监听进来的连接，backlog的含义有点复杂，这里先简单的描述：指定挂起的连接队列的长度，当客户端连接的时候，服务器可能正在处理其他逻辑而未调用accept接受连接，此时会导致这个连接被挂起，内核维护挂起的连接队列，backlog则指定这个队列的长度，accept函数从队列中取出连接请求并接收它，然后这个连接就从挂起队列移除。如果队列未满，客户端调用connect马上成功，如果满了可能会阻塞等待队列未满（实际上在Linux中测试并不是这样的结果，这个后面再专门来研究）。Linux的backlog默认是128,通常情况下，我们也指定为128即可。

connect客户端向服务器发起连接，accept接收一个连接请求，如果没有连接则会一直阻塞直到有连接进来。得到客户端的fd之后，就可以调用read,

write函数和客户端通讯，读写方式和其他I/O类似

read从fd卖数活，socket默以是阻墨漠式的，如果对方安有写活，read会一直阻塞着：

write写fd写数据，socket默认是阻塞模式的，如果对方没有写数据，write会一直阻塞着：

socket关闭套接字，当另一端socket关闭后，这一端读写的情况：

尝试去读会得到一个EOF,并返回0。

尝试去写会触发一个SI1 GPIPE信号，并返回-1和errno:=EPIPE,SIGPIPE的默认行为是终止程序，所以通常我们应该忽略这个信号，避免程序终止。

如果这一端不去读写，我们可能没有办法知道对端的socket关闭了。

2.2.4.2 网络库

提供易用API：

封装底层Socket API

连接管理和事件分发

功能：

协议支持：tcp、udp和uds等

优雅退出、异常处理等

性能：

应用层buffer减少copy

高性能定时器、对象池等

2.3 关键指标

2.3.1稳定性

2.3.1.1 稳定性-保障策略

熔断：保护调用方，防止被调用的服务出现问题而影响到整个链路

限流：保护被调用方，防止大流量把服务压垮

超时控制：避免浪费资源在不可用节点上

熔断：

一个服务A调用服务B时，服务B的业务逻辑又调用了服务C,而这时服务C响应超时了，由于服务B依赖服务C,C超时直接导致B的业务逻辑一直等待，而这个时候服务A继续频繁地调用服务B,服务B就可能会因为堆积大量的请求而导致服务宕机，由此就导致了服务雪崩的问题

限流：

当调用端发送请求过来时，服务端在执行业务逻辑之前先执行检查限流逻辑，如果发现访问量过大并且超出了限流条件，就让服务端直接降级处理或者返回给调用方一个限流异常

超时：

当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，避免浪费资源

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

2.3.1.2 稳定性-请求成功率

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

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

2.3.1.3 长尾请求

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

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

2.3.1.4 稳定性-注册中间件

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

2.3.2 易用性

开箱即用

合理的默认参数选项、丰富的文档

周边工具

生成代码工具、脚手架工具

2.3.3 扩展性

2.3.4 观测性

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

2.3.5 高性能

这个图需要换一下

这里分两个维度，高性能意味着高吞吐和低延迟，两者部很重要，甚至大部分场景下低延迟更重要

多路复用可以大大减少了连接带来的资源消耗，并目提升了服务端性能，我们的测试中服务端吞吐可提升30%。

调用端向服务端的一个节点发送请求，并发场景下，如果是非连接多路复用，每个请求都会持有一个连接，直到请求结束连接才会被关闭或者放入连接池复用，并发量与连接数是对等的关系。

而使用连接多路复用，所有请求都可以在一个连接上完成，大家可以明显看到连接资源利用上的差异

2.4 企业实践

2.4.1 整体架构-Kitex

Kitex Core

核心组件

Kitex Byted

与公司内部基础设施集成

Kitex Tool

代码生成工具

core是它的的主干逻辑，定义了框架的层次结构、接口，还有接口的默认实现，如中间蓝色部分所示，最上面client和server是对用户暴露的

client,/server option的配置都是在这两个package中提供的，还有client/server的初始化，在第二节介绍kitex_gen生成代码时，大家应该注意到里面有

client.go和server..go,虽然我们在初始化client时调用的是kitex_gen中的方法，其实大家看下kitex_gen下service package代码就知道，里面是对这里的client/server的封装。

client/server下面的是框架治理层面的功能模块和交互元信息，remote:是与对端交互的模块，包括编解码和网络通信。

右边绿色的bytd是对字节内部的扩展，集成了内部的二方库还有与字节相关的非通用的实现，在第二节高级特性中关于如何扩展ktex里有介绍过，byted部分是在生成代码中初始化client和servert时通过suite集成进来的，这样实现的好处是与字节的内部特性解耦，方使后续开源拆分。

左边的tool则是与生成代码相关的实现，我们的生成代码工具就是编译这个包得到的，里面包括idl解析、校验、代码生成、插件支持、自更新等，未来生成代码逻辑还会做一些拆分，便于给用户提供更友好的扩展

2.4.2 自研数据库

2.4.2.1自研数据库-背景

原生库无法感知连接状态

在使用连接池时，池中存在失效连接，影响连接池的复用。

原生库存在goroutine暴涨的风险

一个连接一个goroutine的模式，由于连接利用率低下，存在大量goroutine占用调度开销，影响性能。

1.Go Net使用Epoll ET,Netpoll使用LT

2.Netpol在大包场景下会占用更多的内存。

3.GoNt只有一个Epo事件循环（因为ET模式被唤醒的少，且事件循环内无需负责读写，所以干的活少），而Netpoll允许有多个事件循环（循环内

需要负责读写，干的活多，读写越重，越需要开更多L0ops)。

4.Go Net一个连接一个Goroutine,Netpoll连接数和Goroutine数量没有关系，和请求数有一定关系，但是有Gopool重用

5.Go Net.不支持Zero Copy,甚至于如果用户想要实现BufferdConnection这类缓存读取，还会产生二次拷贝。Netpoll支持管理一个Buffer池直接交给

用户，且上层用户可以不使用Read(o [byte)接口而使用特定零拷贝读取接口对Buffer进行管理，实现零拷贝能力的传递。

2.4.2.2 自研数据库-Netpoll

解决无法感知连接状态题

引入epoll主动监听机制，感知连接状态

解决goroutine暴涨的风险

建立goroutine池，复用goroutine

提升性能

引入Nocopy Buffer,向上层提供NoCopy的调用接口，编解码层面零拷贝

1.go net无法检测连接对端关闭（无法感知连接状态）

1.在使用长连接池时，池中存在失效连接，严重影响了连接池的使用和效率。

2.希望通过引入epoll主动监听机制，感知连接状态。

2.go net缺乏对协程数量的管理

1.Kite采取一个连接一个goroutine模式，由于连接利用率低，服务存在较多无用的goroutine,占用调度开销，影跏响性能。

2.希望建立协程池，提升性能。

netpoll基于epoll,同时采用Reactort模型，对于服务端则是主从Reactor模型，如右图所示：服务端的主reactor用于接受调用端的连接，然后将建立好的

连接注册到某个从Reactor_上，从Reactorf负责监听连接上的读写事件，然后将读写事件分发到协程池里进行处理。

2.4.3扩展性设计

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

kitex支特多协议的并且也是可扩展的，交互方式上前面已经说过支持ping-pong、streaming、oneway

编解码支持thrift、Protobuf

应用层协议支持TTHeader、.Http2、也支持裸的thrift协议

传输层目前支持TCP,未来考虑支特UDP、kernel-bypass的RDMA

如上图所示，框架内部不强依赖任何协议和网络模块，可以基于接口扩展，在传输层上则可以集成其他库进行扩展。

目前集成的有自研的Netpoll,基于netpoll实现的http2库，用于mesh场景通过共享内存高效通信的shm-ipc,以后也可以增加对RDMA支持的扩展

2.4.4 性能优化

2.4.4.1 性能优化-网络库优化

调度优化

epoll wait在调度上的控制

gopool重用goroutine降低同附运行协程数

LinkBuffer

读写并行无锁，支持nocopy地流式读写

高效扩缩容

Nocopy Buffer池化，减少GC

Pool

引入内存池和对象池，减少GC开销

2.4.4.2 性能优化-编解码优化

Codegen

预计算并预分配内存，减少内存操作次数，包括内存分配和拷贝

Inline减少函数调用次数和避免不必要的反射操作等

自研了Go语言实现的Thrift IDL解析和代码生成器，支持完善的Thrift IDL语法和语义检查，并支持了插件机制-Thriftgo。

JIT

使用JIT编译技术改善用户体险的同时带来更强的编解码性能，减轻用户维护生成代码的负担

基于JIT编译技术的高性能动态Thrift编解码器-Frugal

序列化和反序列的性能优化从大的方面来看可以从时间和空间两个维度进行优化。从兼容已有的Bay协议来看，空间上的优化以乎不太可行，只能从

时间维度进行优化，包括下面的几点：

代码生成code-gen的优点是库开发者实现起来相对简单，缺点是增加业务代码的维护成本和局限性。

JT编译(Gust-in-time compilation)狭义来说是当某段代码即将第一次被执行时进行编译，因而叫"即时编译"。

即时编译JIT则将编译过程移到了程序的加载（或首次解析）阶段，可以一次性编译生成对应的code并高效执行，目前公司内部正在尝试，压测数据表明性能收益还是挺不错的，目的是不损失性能的前提下，威轻用户的维护负担生成代码的负担。

2.4.5 合并部署

微服务过微，传输和序列化开销越来越大

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

√中心化的部署调度和流量控制

√基于共享内存的通信协议

√定制化的服务发现和连接池实现

√定制化的服务启动和监听逻辑

三、 课后个人总结

本堂课介绍了Kitex的整体架构以及自研数据库Netpoll的背景和优势，并且从扩展性和性能优化两方面进行了相关介绍。

四、 引用参考

青训营官方课件