字节跳动在 Go 网络库上的实践

本文选自“字节跳动基础架构实践”系列文章。

“字节跳动基础架构实践”系列文章是由字节跳动基础架构部门各技术团队及专家倾力打造的技术干货内容，和大家分享团队在基础架构发展和演进过程中的实践经验与教训，与各位技术同学一起交流成长。

RPC 框架作为研发体系中重要的一环，承载了几乎所有的服务流量。本文将简单介绍字节跳动自研网络库 netpoll 的设计及实践；以及我们实际遇到的问题和解决思路，希望能为大家提供一些参考。

前言

字节跳动框架组主要负责公司内 RPC 框架的开发与维护。RPC 框架作为研发体系中重要的一环，承载了几乎所有的服务流量。随着公司内 Go 语言使用越来越广，业务对框架的要求越来越高，而 Go 原生 net 网络库却无法提供足够的性能和控制力，如无法感知连接状态、连接数量多导致利用率低、无法控制协程数量等。为了能够获取对于网络层的完全控制权，同时先于业务做一些探索并最终赋能业务，框架组推出了全新的基于 epoll 的自研网络库 —— netpoll，并基于其之上开发了字节内新一代 Golang 框架 KiteX。

由于 epoll 原理已有较多文章描述，本文将仅简单介绍 netpoll 的设计；随后，我们会尝试梳理一下我们基于 netpoll 所做的一些实践；最后，我们将分享一个我们遇到的问题，以及我们解决的思路。同时，欢迎对于 Go 语言以及框架感兴趣的同学加入我们！

新型网络库设计

Reactor - 事件监听和调度核心

netpoll 核心是 Reactor 事件监听调度器，主要功能为使用 epoll 监听连接的文件描述符（fd），通过回调机制触发连接上的 读、写、关闭 三种事件。

Server - 主从 Reactor 实现

netpoll 将 Reactor 以 1:N 的形式组合成主从模式。

1. MainReactor 主要管理 Listener，负责监听端口，建立新连接；

2. SubReactor 负责管理 Connection，监听分配到的所有连接，并将所有触发的事件提交到协程池里进行处理。

3. netpoll 在 I/O Task 中引入了主动的内存管理，向上层提供 NoCopy 的调用接口，由此支持 NoCopy RPC。

4. 使用协程池集中处理 I/O Task，减少 goroutine 数量和调度开销。

Client - 共享 Reactor 能力

client 端和 server 端共享 SubReactor，netpoll 同样实现了 dialer，提供创建连接的能力。client 端使用上和 net.Conn 相似，netpoll 提供了 write -> wait read callback 的底层支持。

Nocopy Buffer

为什么需要 Nocopy Buffer ?

在上述提及的 Reactor 和 I/O Task 设计中，epoll 的触发方式会影响 I/O 和 buffer 的设计，大体来说分为两种方式：

1. 采用水平触发(LT)，则需要同步的在事件触发后主动完成 I/O，并向上层代码直接提供 buffer。