您听说过 Azul Optimizer Hub,并且想知道它如何融入您的 AWS 架构。作为一名 AWS 架构师,您可能熟悉在容器化云原生环境中运行 Java 工作负载的性能挑战,尤其是 JIT 编译带来的启动延迟和资源开销。Optimizer Hub 是一款运行于 Amazon EKS 的 Kubernetes 原生解决方案,它从根本上改变了这一现状,从第一个请求开始就能实现最佳应用程序性能。以下是您需要了解的有关将这项颠覆性技术集成到您的 AWS 环境中的所有信息。
传统的 Java 以较慢的解释模式执行代码,直到它能够构建优化配置文件。这意味着它只有在应用程序处理流量并触及关键代码路径后才能开始优化。因此,正当您为了应对流量激增而进行横向扩展时,机器却处于运行最慢的状态,在处理请求和执行高开销的 JIT 优化之间分摊有限的 CPU 资源。
凭借 Optimizer Hub,Java 应用程序可以更快地达到全速运行,同时最大程度地降低客户端 CPU 负载。
什么是 Optimizer Hub? |
---|
Optimizer Hub 是一组可扩展的 JVM 外部服务,可在部署和管理运行在 Azul Platform Prime 的 Zing JVM 上的 Java 实例集时,提升应用程序性能和运营效率。 |
Optimizer Hub 提供两项服务来解决传统的 Java 预热问题:
- ReadyNow Orchestrator:监控整个实例集的使用模式,以构建优化配置文件来驱动 JVM 上的编译。新启动的 JVM 会跳过性能分析阶段,在初始化后立即编译方法,从而使大部分 JIT 编译工作在应用程序初始化期间进行,然后再处理流量。
- Cloud Native Compiler (CNC):通过将 JIT 编译任务卸载到单独的专用 JIT 集群,提供服务器端优化。CNC 会缓存优化结果,避免数百次重复相同的优化操作,从而使客户端能够将 100% 的 CPU 资源用于处理请求,而无需为初始 JIT 编译峰值预留容量。
结合使用这些服务,您可以更快地达到全速运行,在预热期间提高 CPU 利用率,并减少容量浪费。与 Graal Native Image 等其他预热技术不同,Optimizer Hub 可以在任何 JDK 版本上使用,并且可以处理所有 Java 代码模式,并且无需更改代码。
架构是怎样的?
Optimizer Hub 作为 Kubernetes 集群提供,您可以在 VPC 中运行它,通常位于 Elastic Kubernetes Service 中 [图 1]。

重要详细信息:
- 最佳安装方式是使用我们的 Helm Chart(版本为 v3.8.0 或更高版本)。
- 所有映像均位于 dockerhub 上,但大多数客户会将其下载到其内部工件管理系统中,然后更新 Helm Chart 以指向新位置。
- 控制器负责所有扩展,并需要调用 Kubernetes API 的权限。Optimizer Hub 不使用 HPA 扩展。
- Optimizer Hub 需要连接到 S3。您可以授予所需节点对 S3 存储桶的 RW 权限,或设置 AWS 服务账户来管理访问权限。
- Optimizer Hub 是一种共享服务,其中一个实例可以为该可用区内运行的所有 JVM 提供服务。您无需为每个应用程序单独部署 Optimizer Hub 实例。理想情况下,Optimizer Hub 实例应该与其所服务的应用程序位于同一可用区内。
- Optimizer Hub 提供完全的高可用性,即使完全失去对 Optimizer Hub 的访问权限,JVM 仍可运行。

在 EKS 上安装
基础设施要求:
- 实例类型:按需或预留 EC2 实例(无竞价型实例)
- 规模评定:每个节点至少有 8 个 vCore 和 32GB RAM
- 推荐实例:m6 或 m7 实例系列
- 部署选项:在现有的 EKS 集群中安装或使用提供的eksctl 脚本创建专用集群
eksctl 脚本会在您的 AWS 账户中创建以下内容:
- 用于主 EKS 集群和集群中每个 NodeGroup 的 CloudFormation 堆栈。
- 名为 eksctl-{cluster-name}-cluster/VPC 的虚拟私有云。如果您选择使用现有的 VPC,则不会创建 VPC。您可以在 AWS VPC 控制台中探索 VPC 及其相关网络组件。VPC 已配置所有必需的网络组件:
- 一组三个公共子网和三个私有子网
- 互联网网关
- 每个子网的路由表
- 集群的弹性 IP 地址
- NAT 网关
- 一个 EKS 集群,包括四个节点组,其中配置了一个 m5.2xlarge 实例:
- infra – 用于运行 Grafana 和 Prometheus
- opthubinfra – 用于运行 Optimizer Hub 基础设施组件
- opthubcache – 用于运行 Optimizer Hub 缓存
- opthubserver – 用于运行 Optimizer Hub 编译代理设置
- 自动扩展组的 IAM 工件:
- 集群和每个子网的 Autoscaler 组的角色
- EKS 自动缩放程序的策略
自动扩展
Optimizer Hub 有两种模式:仅 ReadyNow 模式和完整模式(包含 ReadyNow 和 CNC)。仅 ReadyNow 模式不需要很多资源,也无法扩展。而 CNC 模式则会在 JVM 启动的短时间内扩展大量资源,然后随着编译请求的逐渐减少而缩减资源。
与基于 CPU/内存指标扩展的传统 HPA 不同,Optimizer Hub 控制器会根据编译工作负载扩展网关、编译代理和缓存组件。系统会监控编译队列深度,并调整资源规模,使传入的编译请求与处理能力相匹配。
Optimizer Hub 中的负载均衡和高可用性
在生产系统中,您必须在 Optimizer Hub 实例前面部署负载均衡器或服务网格。连接到 Optimizer Hub 的 JVM 需要一个稳定的单一入口点来与服务进行通信。您可以使用基于 DNS 的负载均衡器(即 Amazon Route 53)或 Kubernetes 服务网格(即 Istio)。Optimizer Hub 网关包含标准就绪检查,您可以使用它来确定何时向集群发送流量。
注 |
---|
我们建议在生产环境中至少使用两个 Optimizer Hub 实例。通常,每个可用区中都会有一个实例以减少延迟,每个实例都充当其他可用区中实例的备份,以防这些实例发生故障。 |
Optimizer Hub 实例可以配置为在彼此之间自动同步 ReadyNow 配置文件;因此,如果应用程序的最近实例不可用,其他实例将具有确保平稳预热所需的配置文件。
如果 Optimizer Hub 变得不可用,新启动的 JVM 将继续运行,但预热速度会变慢,在某些情况下代码速度会降低。
- ReadyNow 配置文件将不可用,因此 JVM 无法在周期的早期预先加载 JIT 编译。当应用程序处理流量时,这会导致更高的 CPU 负载和更短的响应时间。
- Cloud Native Compiler 将不可用,这意味着所有编译都在本地进行。如果 CNC 不可用,您可以将 JVM 配置为使用较低级别的编译,以最大限度地减少本地编译的影响。
亲自尝试
Optimizer Hub 可免费与任何 Azul Platform Prime 许可实例一起使用。Azul Platform Prime Stream 版本可用于评估和测试。我们的 Java 性能专家可随时帮助您使用 Azul Platform Prime 获得最佳客户体验和最低的 AWS 云成本。