改善 Kubernetes 上的 JVM 预热问题

作者：Vikas Kumar

翻译：Bach（才云）

校对：木子（才云）

JVM 预热是一个非常头疼而又难解决的问题。**基于 JVM 的应用程序在达到最高性能之前，需要一些时间来“预热”。**当应用程序启动时，通常会从较低的性能开始。这归因于像即时（JIT）编译这些事儿，它会通过收集使用配置文件信息来优化常用代码。最终这样的负面影响是，与平均水平相比，预热期间接收的 request 将具有非常高的响应时间。在容器化、高吞吐量、频繁部署和自动伸缩的环境中，这个问题可能会加剧。

在这篇文章中，我们将讨论在运行在 Kubernetes 集群中的 Java 服务如何解决 JVM 预热问题的经验。

起因

几年前，我们逐步从整体中分离出服务，开始在 Kubernetes 上进行迁移到基于微服务的体系结构。大多数新服务都是在 Java 中开发的。当我们在印度市场上运行一个这样的服务时，我们第一次遇到了这个问题。我们通过负载测试进行了通常的容量规划过程，并确定 N 个 Pod 足以处理超过预期的峰值流量。

尽管该服务在轻松处理高峰流量，但我们在部署过程中发现了问题。我们的每个 Pod 在高峰时间处理的 RPM 都超过 10k，而我们使用的是 Kubernetes 滚动更新机制。在部署过程中，服务的响应时间会激增几分钟，然后再稳定到通常的稳定状态。在我们的仪表板中，会看到类似的图表：

与此同时，我们开始收到来自部署时间段内的大量投诉，几乎都关于高响应时间和超时错误。

第一步：花钱解决问题

我们很快意识到这个问题与 JVM 预热阶段有关，但当时有其他的重要事情，因此我们没有太多时间进行调查，直接尝试了最简单的解决方案——增加 Pod 数量，以减少每个 Pod 的吞吐量。我们将 Pod 数量增加了近三倍，以便每个 Pod 在峰值处理约 4k RPM 的吞吐量。我们还调整了部署策略，以确保一次最多滚动更新 25%（使用 maxSurge 和 maxUnavailable 参数）。这样就解决了问题，尽管我们的运行容量是稳定状态所需容量的 3 倍，但我们能够在我们的服务中或任何相