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

深度学习与Python

发布于 2023-12-14 18:36:42

1120

发布于 2023-12-14 18:36:42

文章被收录于专栏：深度学习与python深度学习与python

作者 | Rafal Gancarz

译者 | 明知山

策划 | 丁晓昀

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