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 进行服务间通信。

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 标头压缩。

迁移到 HTTP/2 后延迟减少（来源：LinkedIn Engineering Blog）

团队报告称，在所有这些定制化改进之后，迁移到 HTTP/2 带来了明显的性能改进，相较于 HTTP/1.1，TCP 连接数量减少了 88%，延迟降低了 65% 至 75%，垃圾回收时间减少了 75% 至 81%，获取连接的等待时间从 11 毫秒 降至 0.02 毫秒（改进了 99%）。

英文原文：

https://www.infoq.com/news/2023/12/linkedin-espresso-http2/