Quarkus Java 框架答疑

Red Hat 最近发布了Quarkus，这是一个为 GraalVM 和 OpenJDK HotSpot 量身定制的 Kubernetes 原生 Java 框架。继 InfoQ 对其发布所做的初步报道之后，我们又与 Red Hat 的几位专家做了进一步交流，以了解该项目的开发动机、应用场景和未来的发展方向。

在云时代，容器、Kubernetes、微服务、功能即服务（Faas）和云原生应用正在提供更高水平的生产力和效率，而 Quarkus 成为了其中一个非常有趣的选择。

为此，InfoQ 采访了 Red Hat 首席高级产品经理John Clingan和 Red Hat 工程副总裁Mark Little。

InfoQ：Quarkus 旨在使 Java 成为 Kubernetes 和无服务环境中的领先平台。这个想法是如何产生的？你们为此研究了多少年？

Red Hat：Red Hat 是最早发现在容器中使用 JVM 存在某些局限的组织之一，我们已经并且仍在设法解决其中的一些局限。我们在最近的Red Hat开发者博客文章中讨论了这件事。今天，JVM 上的 Java 应用可以在容器中正常运行，我们的客户也可以在生产环境中使用这种组合。但仅仅改进 JVM 是很难解决某些局限的。

其中一个例子是，在 JVM 上运行企业级 Java 应用所需的漫长初始启动时间和庞大内存消耗。我们 Red Hat 一直在寻找类似于 Java 的 GNU 编译器和 Avian 项目这样的解决方案，但是当 Java 社区中出现了 GraalVM 后，我们意识到与这个项目合作有很大的潜力。

InfoQ：Red Hat 开发 Quarkus 的灵感源自哪里？

Red Hat：当我们搞明白 GraalVM 的工作原理时，我们意识到为了获得所有的收益就必须从整体层面考虑问题，不仅要从 VM 的层面入手，还要考虑框架层面的情况。使用 Java 为 GraalVM 开发原生应用时会有一些限制，主要是围绕 Java 的一些更动态的功能，例如反射等；而 GraalVM 的优势又需要这些限制为基础。对于几乎没有依赖关系的应用来说，问题并不是很难解决；但在开发企业级 Java 应用时问题规模很快就会超出预期了。

开发者们倾向于使用许多不同的框架。其中流行的一个框架是 Hibernate，它是最常用的对象关系映射框架，用于轻松访问数据库内容。若要让 Hibernate 在 GraalVM 上完美工作，需要对 Hibernate 的原理有很深入的了解，还需要深入了解 JVM 和 GraalVM 的运行机制。在这个实验中，我们发现了一个创建通用架构的机会，使其它框架可以更容易地接受 GraalVM 的特质。

我们使用 Quarkus 中的扩展系统来移植更多的项目，比如我们的 Eclipse MicroProfile 实现项目（SmallRye）和 RESTEasy。该列表现在大约有 40 个扩展，数量还在增加之中。 Quarkus 甚至获得了 swagger-ui 带来的第一次社区扩展。现在，无论企业级 Java 开发者是在使用 Java EE、MicroProfile 还是 Spring，都会很容易熟悉并上手这个 Java 栈。

InfoQ：在 Quarkus 发布后不久，Thorntail 4.x 的开发就宣告结束，Thorntail 2.x 的支持将截止到 2020 年 11 月。Quarkus 对 Payara 和 Tomitribe 等其他 Java 中间件项目会有何影响？

Red Hat：Quarkus 带来了一些非常创新的功能，如扩展 API、扩展生态系统，以及统一命令式和反应式编程模型。对其他项目的最大影响在于 Eclipse MicroProfile，这里我们用上了下一代企业级 Java 规范。MicroProfile 的目标是云原生 Java。而 Quarkus 是一个使用统一的命令式和反应式编程模型实现更先进的云原生部署方案的示例。

我们可以将自己在 Quarkus 中的这些想法与其他实现（如 Payara 和 Tomitribe）的经验结合起来，通过 MicroProfile 和 Jakarta EE 推动行业向前发展。需要注意的是，在我们尝试创建规范之前，必须首先进行创新。将一个想法确定为规范可能需要几个月甚至几年的时间，因此要花的时间肯定会很久。

InfoQ：开发者对 Quarkus 有哪些期望？

1. 为 Kubernetes 带来理想的容器优先体验

• 毫秒为单位的快速启动，从而实现无服务 Java 的冷启动，支持响应更快、可扩展的环境

• 最小内存占用可以达到标准 Java 流程的十分之一，可以带来更大的密度，从而提高系统的整体弹性。

• 架构基于 12 要素应用的理念，帮助开发更健壮和可靠的应用程序。

2. 为开发者带来真正的乐趣

3. 有态度，有良好集成的平台，支持命令式和反应式风格

4. 基于最出色的标准和 OSS 创建

InfoQ：GraalaVM 当前支持的语言（如 Scala 和 Python）可以与 Quarkus 一起使用吗？如果是的话，你能举一些例子吗？如果不能，它们将来会得到支持吗？

Red Hat：Java 仍然是企业和 Red Hat 客户主要使用的语言，因此我们现在还是会把精力集中于此。在 Java 之外我们也会在实验中考虑 Kotlin，并会注意社区的反馈。

InfoQ：能否多介绍一些 Quarkus Metrics 的信息？

Red Hat：Quarkus 通过 Eclipse MicroProfile Metrics 规范下的 SmallRye Metrics 实现来应用的监控。它为应用暴露了一组默认的基本指标，同时还使开发者能够添加自定义应用指标。所有指标均可从应用的/metrics 端点访问，并可由 Prometheus 等监控系统筛选。Quarkus 还提供健康检查支持和分发追踪功能，使应用更易操作。

InfoQ：Quarkus 的发布周期是怎么安排的？

Red Hat：Quarkus 引起了人们极大的兴趣，所以我们希望尽可能积极响应。我们大约每隔几周就会提供功能和错误修复，直到我们认为反馈已经够好，也有足够多的开发者上手使用前都会这样做。

我们的主要目标之一是帮助社区编写扩展。Quarkus 对我们来说是一个生态系统。

InfoQ：你们是否计划保持对早期版本的向后兼容性？

Red Hat：向后兼容对我们 Red Hat 和我们的社区非常重要。但我们是一个年轻的项目，创新速度很快，很难这么早就对此下结论。但我们将与社区共同来决定“何时、为何与怎样做”的内容。

好的一面是 Quarkus 站在巨人的肩膀上：Hibernate、Vert.x、Camel、Netty、RESTEasy 等等，它们都是有着向后兼容历史的成熟框架。Quarkus 简单地暴露了这些框架的 API。我们已经看到很多社区成员以极快的速度将 Java EE 应用程序移植到 Quarkus 中。这就是优秀的成熟框架与标准的威力所在。

InfoQ：Quarkus 的路线图是怎样的？

Red Hat：首先，这个社区成立不久，我们想听听人们对 Quarkus 的用途和需求。

我们认为生态系统也非常重要；我们希望 Java 生态系统能够接受 Java 的这种新范式转变，因为我们认为它是未来趋势。因此我们将许多精力投入到为开发人员使用和喜爱的框架编写扩展上。

这里正是困难所在。我们推出 Quarkus 是要实现一个远大目标，而要达成这一目标还有很多工作要做。我会列出主要的任务，但请记住，社区及其需求是推动路线图发展最重要的因素：

• 无服务器：Quarkus 的低内存使用率和极快的启动时间使其成为 FaaS 功能框架的理想选择。

• 命令和响应：在云原生弹性应用中响应是至关重要的。我们已经通过统一编程模型来展示了我们的目标。现在是时候扩张地盘了。例如，我们正在探索响应式非阻塞方法来提升持久性。

• 安全性：如何应对行业不得不习惯的大量 CVE？ 我们从 Wildfly 的经验中学到了很多东西，并期待在不久的将来 Quarkus 能做到很多事情。

• 容器和 Kubernetes：应用没有部署则毫无价值。Quarkus 应用程序在容器平台和 Kubernetes 上的部署有很多可以改进的空间。

InfoQ：你们在 Quarkus 中编译时使用的是什么启动技术？

Red Hat：这里有很多技巧，说一下我们认为最有趣的方面吧。Quarkus 的一个关键点是将许多传统框架在启动时做的事情转移到了编译阶段：包括类路径扫描、反射、解析配置、收集元数据和构建运行时模型等。这样做有如下好处：

• 只在编译时把工作做一次就够了，不用在每次应用启动时再来一遍；

• 以往在 JVM 中，引导框架所需的所有代码都会占用内存（类元数据等），现在则根本不需要。

• 这样我们就能使 Quarkus 应用飞快启动、高速接受请求，并尽可能压缩内存开销。

• Quarkus 扩展的另一个有趣之处在于，它们可以尽量帮助 GraalVM 执行冗余代码清除算法。 GraalVM 在检测不必要的调用路径方面做得非常出色，但它需要框架的帮助才能知道可选的依赖项对于特定应用程序是否真的可供选择。这可能有点无趣，但它的确会带来回报。

InfoQ：开发者获得该技术的最佳方式是什么？ 开发者与社区互动并提出问题最好的途径有哪些？

获取 Quarkus：请参阅入门指南

Twitter：@QuarkusIO

聊天：Zulip聊天室

问答：StackOverflow

查看英文原文：Quarkus Java Framework: Q&A with John Clingan and Mark Little