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有哪些期望？
- 为Kubernetes带来理想的容器优先体验
- 毫秒为单位的快速启动，从而实现无服务Java的冷启动，支持响应更快、可扩展的环境
- 最小内存占用可以达到标准Java流程的十分之一，可以带来更大的密度，从而提高系统的整体弹性。
- 架构基于12要素应用的理念，帮助开发更健壮和可靠的应用程序。
为开发者带来真正的乐趣
有态度，有良好集成的平台，支持命令式和反应式风格
基于最出色的标准和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聊天室
查看英文原文：Quarkus Java Framework: Q&A with John Clingan and Mark Little