LinkedIn 将其 Espresso 数据库从 HTTP/1.1 迁移到 HTTP/2，极大 提升 了可伸缩性和性能，减少了连接数量、降低了延迟并缩短了垃圾回收时间。为了获得这些好处，团队不得不优化 Netty 默认的 HTTP/2 栈来满足需求。
LinkedIn 使用 Espresso（构建在 MySQL 之上的文档平台）来存储和提供大部分数据。随着 LinkedIn 平台的有机增长，数据量不断增加，迫使公司不断扩展 Espresso 集群的规模，并进行优化工作，例如为 Espresso 引入 集中式缓存层 或者 采用 Protocol Buffers 进行服务间通信。
Espresso 的事务栈包括两个主要组件：路由器和存储节点。路由器负责将请求发送到正确的存储节点上，存储节点负责与 MySQL 集群进行交互，并相应地调整数据格式。这些组件之间的通信使用 HTTP 协议，更具体地说是使用了 Netty 框架。随着时间推移，团队发现到 Espresso 集群的规模增长导致可伸缩性下降。
最近增加的 100 个路由器节点导致存储节点内存使用量增加，额外的垃圾回收导致延迟增加了 15%。此外，由于增加了大量的 HTTP/1.1 连接，从连接池中获取连接所需的时间达到了几毫秒。最后，在发生网络事件（如交换机升级）期间，由于达到存储节点的连接限制，重新建立数千个连接可能会导致错误。
LinkedIn 的软件工程师 Abhishek Andhavarapu 解释了 HTTP/1.1 和 HTTP/2 之间的差异，以及这些差异如何影响 Espresso 平台的可伸缩性和性能：
开发人员通过修改几个内部的 Netty 实现细节来增强功能。他们创建了一个可以重复使用已有通道的处理程序，避免为每个请求创建新的处理通道。他们还引入了一个自定义的 EventLoopGroup 实现，可以更均匀地在工作线程之间平衡连接。为了减少获取连接时的上下文切换，团队重新设计了连接池实现，使用了高性能、线程安全的队列。
此外，SSL 处理使用原生的、基于 JNI 的 SSL 引擎进行了优化，并使用自定义的 SSL 初始化逻辑避免了冗长的 DNS 查找延迟。最后，团队通过创建自定义编解码器来优化编码 / 解码性能，编解码器将 HTTP/2 请求封装为 HTTP/1.1 请求，帮助处理 Espresso 使用的许多自定义 HTTP 标头，并禁用了 HPACK 标头压缩。
团队报告称，在所有这些定制化改进之后，迁移到 HTTP/2 带来了明显的性能改进，相较于 HTTP/1.1，TCP 连接数量减少了 88%，延迟降低了 65% 至 75%，垃圾回收时间减少了 75% 至 81%，获取连接的等待时间从 11 毫秒 降至 0.02 毫秒（改进了 99%）。
英文原文 ：
