Quarkus是为GraalVM和OpenJDK HotSpot量身定制的Kubernetes本机Java框架,现已达到1.0版 。 Quarkus的目标是将Java带入云原生应用程序开发的未来,并使之成为无服务器,云和Kubernetes环境的领先平台,为开发人员提供统一的响应式和命令式编程模型。
Quarkus通过利用Java开发人员使用的一系列库(例如Eclipse MicroProfile和Vert.x)带来了一个全栈框架。 Quarkus依赖注入基于CDI,使开发人员能够使用JPA / Hibernate,JAX-RS / RESTEasy等。 此外,Quarkus包含一个扩展框架,第三方框架的作者可以利用它来扩展它。 该扩展框架还可以帮助开发人员编写可编译为GraalVM本机二进制文件的扩展。
在云时代,容器,Kubernetes,微服务,功能即服务(Faas)和云本机应用程序提供了更高水平的生产力和效率,Quarkus成为了一个非常有趣的选择。
InfoQ与Red Hat的高级首席产品经理Thomas Qvarnstrom进行了交谈 ,以了解Quarkus的旅程,向后兼容性,扩展以及项目的未来方向。
InfoQ:Quarkus于今年三月首次发布,它是一个非常年轻的框架。 您能否分享从第一个版本到1.0版的旅程?
Thomas Qvarnstrom :几年来,在我们对Kubernetes和Red Hat OpenShift的大量投资和客户采用的推动下,Red Hat一直在研究如何改进容器中的Java。 最初,我们专注于改进Java Runtime(JVM)本身和我们的中间件库,并且大多数工作已在OpenJDK和其他上游社区中提供。 在OpenJDK的情况下,Red Hat从Java 11开始,并且还将这些改进移植到Java 8,从而提高了性能并降低了内存使用量。 但是,JVM的一些最重要的功能(例如一次运行并部署到任何地方)以及运行时发生的动态可发现性,对于部署到不可变容器中的应用程序没有意义。
当在容器外运行并且几乎无限制地访问内存时,动态可发现性的开销从来就不是真正的问题,并且这些功能已在CDI和Spring DI等框架中大量使用。 但是,容器和分布式体系结构的后期趋势成为这些框架的开销已成为一个问题。 过去几年中出现了新的框架和运行时,但最简单的是将其分层放置在现有堆栈(JVM,框架,应用程序)的顶部。 我们必须完全重新考虑堆栈,以使Java成为Kubernetes上的一等公民。 在Red Hat,一段时间以来,我们一直在尝试各种技术,例如提前(AOT)编译优化和将字节码编译为本地可执行文件。 2018年,我们启动了一个内部研究项目,以了解如何将这些努力结合起来。 其中最重要的要求之一是不需要完全重写现有框架。
Quarkus扩展系统旨在允许现有框架优化其JVM运行时占用空间,并解决将Java代码编译为静态链接的本机可执行文件的局限性。 同时,另一个开源项目GraalVM开始受到关注,其中一部分是本机编译器。 但是,使用GraalVM创建的本机可执行文件的缺点之一是,它不支持JVM最受欢迎的Java框架的运行时动态行为。 使用Quarkus扩展系统来优化框架,我们能够快速移植流行的框架,例如Hibernate(JPA),RESTEasy,CDI,Camel,Narayana(Transaction),Undertow(Servlet和Web),Vert.x和Eclipse MicroProfile。 基于研究项目的成功,红帽创建了Quarkus开源社区项目。 低内存使用量和快速启动时间只是Quarkus获得的部分好处。 Quarkus最初还包括其他好处,例如实时编码体验,使开发人员无需等待重新部署即可继续工作,以及React式和命令式编程的结合。
在过去的八个月中,Quarkus取得了巨大的成功,最初的8-10扩展现已发展到80个不同的扩展,包括Kafka客户端,OpenID Connect,MicroProfile API,Spring API等。
InfoQ:既然Quarkus已经达到1.0版,开发人员可以期望向后兼容吗? 是否有计划为将来的里程碑版本保持向后兼容性?
Qvarnstrom :我们想在创新和向后兼容性之间取得平衡。 两者对用户都很重要,但是您不能在不替换旧版的情况下引入新功能。 在1.0之前,我们从未真正地将我们知道会破坏向后兼容性的更改与其他不中断的更改分开。 在1.0中,我们将更加小心,不要引入已知会破坏用户应用程序的更改,并等待这些更改直到下一个重要版本发布。 但是,Quarkus社区的重点仍然是创新,我们期望发布节奏与1.0之前大致相同。 为了帮助生态系统成熟,我们引入了扩展状态的概念:预览或稳定。 标有预览的扩展程序可以根据需要随意破坏兼容性,而稳定的扩展程序将保持向后兼容性。
从用户的角度来看,向后发布的发行版将更清晰地传达出来,并且更加罕见。 当然,当Quarkus产品化时,将发布具有向后兼容性承诺的已发布产品生命周期。
InfoQ:今年早些时候在QCon SP 2019上,Sanne Grinovero就Quarkus作了演讲,并谈到了关于Reflection和I / O的一些限制。 您能详细解释一下Quarkus中的一些限制吗? 您将来有什么计划解决这些问题?
Qvarnstrom :Sanne谈到了使用GraalVM生成本地可执行文件的限制,特别是在编译依赖于从JVM动态发现类,配置等的框架时。 Sanne还显示了在没有Quarkus的情况下克服其中一些问题的麻烦和复杂性。 Quarkus不仅帮助克服了将Java作为本机映像运行的局限性,而且还包含了这些局限性,无论您是在Java上还是作为本机可执行文件运行它,都可以通过产生超高效应用程序的方式轻松解决它们。
InfoQ:有80多个优化的Java框架扩展,它们支持将应用程序编译为本地二进制文件。 您认为每个开发人员都应该了解哪些扩展?
Qvarnstrom : Quarkus的主要好处之一是,开发人员不必学习新的API,因为以前使用的大部分内容都可以无需更改就可以使用。 因此,开发人员可以立即开始工作。 但是,Quarkus在先前已知的API之外采用了并进行了创新,包括Panache之类的东西,它是在JPA之上的一种改进,可以启用活动记录模式 。
另一个创新是MicroProfile Reactive Streams,它首先在Quarkus / SmallRye中实现,然后又被推回MicroProfile社区。 扩展功能本身也很有趣,它使用户能够创建自己的扩展,这适用于较大的开发组织,在该组织中,基于代码和配置的通用模式可以在团队之间共享为扩展。
InfoQ:特别是在扩展方面,Hibernate是一个众所周知的ORM框架,我们知道要使Hibernate为Quarkus做好准备,需要做大量的工作。 您能否分享需要进行哪些更改?
Qvarnstrom :除了使用扩展系统来解决上述问题外,Hibernate团队还花费大量工作将以前在启动时完成的大部分工作移到了构建时完成,从而大大缩短了启动时间,并且减少内存占用。
InfoQ:不断发展的Quarkus面临的主要挑战是什么? 您是否收到了许多扩展提交信息?
Qvarnstrom :外部开发人员一直在提供许多扩展,但是Red Hat开发人员已经对其进行了优化。 像许多社区一样,在授予某人访问权限以接受代码更改之前,在Quarkus中实际批准代码更改(拉动请求)的权利基于信任模型,该信任模型基于捐款的先前历史。 在过去的几个月中,我们“促进”了外部贡献者,使其能够查看和批准更改。 这是一个重要的里程碑,对我们来说,这是社区成熟的标志。
扩展的扩展生态系统面临的挑战是验证扩展的质量。 为此,我们正在研究分级系统,以便最终用户可以在将质量添加到他们的应用程序之前看到它。
InfoQ:Quarkus即将出现什么? 有可以分享的路线图吗?
Qvarnstrom :随着用户需求的确定,不断发展的健康扩展生态系统。 我们正在寻求添加更多扩展,例如Spring Security,Spring Config,gRPC客户端/服务器,其他JDBC客户端,其他NoSQL客户端,视图模板引擎,React式编程API的改进,React式Panache,改进的可观察性和CLI工具等。我们还正在研究针对容器编排开发的改进的开发人员体验,我们正在研究在实时编码功能的基础上进行扩展,以提供一种直接在容器中进行远程实时编码的方法。 但是,在我们发言时,社区正在讨论所有这些问题。
InfoQ:您还有什么想对InfoQ的读者说的吗?
Qvarnstrom :如果还没有,请访问Quarkus.io并亲自尝试。 许多用户从使用他们已经熟悉的框架API(例如MicroProfile,Vert.x和Spring Boot)构建应用程序开始。 他们经常对实时编码产生多快的效果,启动速度有多快,使用的内存少以及扩展生态系统的丰富程度感到惊喜。 另外,请在quarkusio.zulipchat.com上分享您的经验(好坏)。
Thomas Qvarnstrom是Red Hat Runtimes中间件的高级首席产品经理。 自2007年以来,他一直在Red Hat工作,在Red Hat JBoss中间件小组中担任过各种职务。 Thomas位于瑞典。 在Twitter上@t_millstream找到他。
翻译自: https://www.infoq.com/articles/redhat-release-quarkus-1-0/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1