这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天
字节内部 Kitex 实践分享
- 框架文档 Kitex
-
自研网络库 Netpoll，背景：
a. 原生库无法感知连接状态
b. 原生库存在 goroutine 暴涨的风险
- 扩展性：支持多协议，也支持灵活的自定义协议扩展
-
性能优化，参考 字节跳动 Go RPC 框架 KiteX 性能优化实践
a. 网络优化
- i. 调度优化
- ii. LinkBuffer 减少内存拷贝，从而减少 GC
- iii. 引入内存池和对象池
b. 编解码优化
- i. Codegen：预计算提前分配内存，inline，SIMD等
- ii. JIT：无生产代码，将编译过程移到了程序的加载（或首次解析）阶段，可以一次性编译生成对应的 codec 并高效执行
-
合并部署
a. 微服务过微，引入的额外的传输和序列化开销越来越大
b. 将强依赖的服务统计部署，有效减少资源消耗
epoll_wait 调度延迟优化
Netpoll 在刚发布时，遇到了延迟 AVG 较低，但 TP99 较高的问题。经过认真研究 epoll_wait，我们发现结合 polling 和 event trigger 两种模式，并优化调度策略，可以显著降低延迟。
首先我们来看 Go 官方提供的 syscall.EpollWait 方法：
func EpollWait(epfd int, events []EpollEvent, msec int) (n int, err error)
这里共提供 3 个参数，分别表示 epoll 的 fd、回调事件、等待时间，其中只有 msec 是动态可调的。
通常情况下，我们主动调用 EpollWait 都会设置 msec=-1，即无限等待事件到来。事实上不少开源网络库也是这么做的。但是我们研究发现，msec=-1 并不是最优解。
epoll_wait 内核源码(如下) 表明，msec=-1 比 msec=0 增加了 fetch_events 检查，因此耗时更长。
static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, int maxevents, long timeout){ ... if (timeout > 0) { ... } else if (timeout == 0) { ... goto send_events; }
fetch_events: ... if (eavail) goto send_events;
send_events: ...
Benchmark 表明，在有事件触发的情况下，msec=0 比 msec=-1 调用要快 18% 左右，因此在频繁事件触发场景下，使用 msec=0 调用明显是更优的。
而在无事件触发的场景下，使用 msec=0 显然会造成无限轮询，空耗大量资源。
综合考虑后，我们更希望在有事件触发时，使用 msec=0 调用，而在无事件时，使用 msec=-1 来减少轮询开销。伪代码如下：
var msec = -1
for {
n, err = syscall.EpollWait(epfd, events, msec)
if n <= 0 {
msec = -1
continue
}
msec = 0
...
}
Thrift 序列化/反序列化优化
序列化是指把数据结构或对象转换成字节序列的过程，反序列化则是相反的过程。RPC 在通信时需要约定好序列化协议，client 在发送请求前进行序列化，字节序列通过网络传输到 server，server 再反序列进行逻辑处理，完成一次 RPC 请求。Thrift 支持 Binary、Compact 和 JSON 序列化协议。目前公司内部使用的基本都是 Binary，这里只介绍 Binary 协议。
Binary 采用 TLV 编码实现，即每个字段都由 TLV 结构来描述，TLV 意为：Type 类型， Lenght 长度，Value 值，Value 也可以是个 TLV 结构，其中 Type 和 Length 的长度固定，Value 的长度则由 Length 的值决定。TLV 编码结构简单清晰，并且扩展性较好，但是由于增加了 Type 和 Length，有额外的内存开销，特别是在大部分字段都是基本类型的情况下有不小的空间浪费。
序列化和反序列的性能优化从大的方面来看可以从空间和时间两个维度进行优化。从兼容已有的 Binary 协议来看，空间上的优化似乎不太可行，只能从时间维度进行优化，包括：
-
减少内存操作次数，包括内存分配和拷贝，尽量预分配内存，减少不必要的开销；
-
减少函数调用次数，比如可调整代码结构和 inline 等手段进行优化；
