LinkedIn 将 Espresso 从 HTTP1.1 迁移到 HTTP2，连接数减少 88%，延迟降低 75%

LinkedIn 将其 Espresso 数据库从 HTTP/1.1 迁移到 HTTP/2，极大提升了可伸缩性和性能，减少了连接数量、降低了延迟并缩短了垃圾回收时间。为了获得这些好处，团队不得不优化 Netty 默认的 HTTP/2 栈来满足需求。

LinkedIn 使用 Espresso（构建在 MySQL 之上的文档平台）来存储和提供大部分数据。随着 LinkedIn 平台的有机增长，数据量不断增加，迫使公司不断扩展 Espresso 集群的规模，并进行优化工作，例如为 Espresso 引入集中式缓存层或者采用 Protocol Buffers 进行服务间通信。

图0: HTTP2LinkedIn 将 Espresso 从 HTTP1.1 迁移到 HTTP2，连接数减少 88%，延迟降低 75%

Espresso 高层架构（来源：LinkedIn Engineering Blog）

Espresso 的事务栈包括两个主要组件：路由器和存储节点。路由器负责将请求发送到正确的存储节点上，存储节点负责与 MySQL 集群进行交互，并相应地调整数据格式。这些组件之间的通信使用 HTTP 协议，更具体地说是使用了 Netty 框架。随着时间推移，团队发现到 Espresso 集群的规模增长导致可伸缩性下降。

最近增加的 100 个路由器节点导致存储节点内存使用量增加，额外的垃圾回收导致延迟增加了 15%。此外，由于增加了大量的 HTTP/1.1 连接，从连接池中获取连接所需的时间达到了几毫秒。最后，在发生网络事件（如交换机升级）期间，由于达到存储节点的连接限制，重新建立数千个连接可能会导致错误。

LinkedIn 的软件工程师 Abhishek Andhavarapu 解释了 HTTP/1.1 和 HTTP/2 之间的差异，以及这些差异如何影响 Espresso 平台的可伸缩性和性能：

对于路由器与存储层之间的通信，我们早期的方法是使用了 HTTP/1.1，这是一种广泛用于 Web 服务器和客户端之间交互的协议。然而，HTTP/1.1 是基于每个请求连接的，在大规模集群中，这种方法会导致路由器和存储节点之间产生数百万个并发连接。这导致了可伸缩性、弹性和众多与性能相关的障碍。团队决定在进行 HTTP/2 迁移时继续使用 Netty 框架，但很快发现其性能并不理想（比 HTTP/1.1 实现的吞吐量低 45%，延迟高 60% 左右），因此工程师们不得不去解决 HTTP/2 栈的性能瓶颈。在经过一番诊断后，他们确定了两个改进方向：获取连接和处理请求，以及请求的编码 / 解码。

开发人员通过修改几个内部的 Netty 实现细节来增强功能。他们创建了一个可以重复使用已有通道的处理程序，避免为每个请求创建新的处理通道。他们还引入了一个自定义的 EventLoopGroup 实现，可以更均匀地在工作线程之间平衡连接。为了减少获取连接时的上下文切换，团队重新设计了连接池实现，使用了高性能、线程安全的队列。

此外，SSL 处理使用原生的、基于 JNI 的 SSL 引擎进行了优化，并使用自定义的 SSL 初始化逻辑避免了冗长的 DNS 查找延迟。最后，团队通过创建自定义编解码器来优化编码 / 解码性能，编解码器将 HTTP/2 请求封装为 HTTP/1.1 请求，帮助处理 Espresso 使用的许多自定义 HTTP 标头，并禁用了 HPACK 标头压缩。