关于夸克的思考

Quarkus是新的“超音速，亚原子” Java框架，目前引起了很多关注。对于企业Java的未来而言，此构建和运行时工具背后的思想确实比我们感兴趣。使用Quarkus有什么好处和缺点？

摆脱动力

Quarkus认为，在容器化的世界中，企业Java运行时的大多数动态并不是真正需要的。将应用程序构建到容器映像后，通常不应更改其功能。企业容器所带来的所有动态都允许进行功能强大且灵活的编程和部署模型，但是一旦我们的应用程序在容器内启动后，它们通常将不再更改。

Quarkus采取的方法是定制仅包含应用程序所需内容的运行时，并简化企业运行时的大部分动态。企业Java代码在很大程度上依赖于控制反转（IoC），也就是“不给我们打电话，我们给您打电话”。想依赖注入的ALA @Inject ，HTTP与资源@Path和@GET ，或与事件观察家@Observes 。我们的开发人员以声明方式指定应该发生的情况，并确保实现。这允许非常高效的编程模型，但在运行时也会带来繁重的工作，因为有人必须将所有这些松散的末端放在一起。现在，我们的想法是，如果我们的应用程序不应该在运行时发生变异，那么大多数这些动态因素都可以在构建时解决。然后，生成的代码主要可以包括直接调用。所有的魔法都被烧掉了。

现在，这是否与过去（从今天看来）不支持IoC且需要直接调用代码中功能的笨重的企业框架所实现的结果相同？从开发人员的角度来看，一点也不。在我们的代码中，我们仍然使用相同的有效声明式方法，相同的注释。构建过程负责将动力带回现实。

Quarkus还支持使用GraalVM构建本机可执行文件。通过这种方法，我们使用提前（AOT）编译来将应用程序预先构建和编译为本地可执行文件，而无需动态扫描所有类并将其加载到JVM中。与常规JVM相比，生成的可执行文件启动速度非常快，并且具有较低的资源消耗。

标准的力量

看一下Quarkus，我发现最吸引人的是它基于已知的企业标准（例如CDI，JAX-RS等）构建。我们可以通过本机可执行文件或Java运行时，在优化的运行时中运行应用程序，而不是使用成熟的应用程序服务器。

许多起义企业框架要求开发人员再次学习新的API，有时（有时甚至更少）重新发明方向，例如如何实现REST端点。但是，从开发人员和项目的角度来看，当现有的API和解决方案足够时，我看不到重新学习和重新编写应用程序的好处。使用Quarkus采用的方法，开发人员可以编写和采用基于CDI，JAX-RS和JPA的应用程序，并通过将运行时更改为Quarkus对其进行优化。

企业Java扩展

除了Java Enterprise中包含的功能外，Quarkus还扩展了项目中可能需要的可用功能。除了受支持的Java EE和MicroProfile规范外，还有用于响应消息传递的Quarkus扩展，Vert.x或Camel。例如，可以通过@Inject EventBus Vert.x的EventBus类型。这与我们在EE中习惯的开发人员经验相符。

我喜欢从已知的企业API开始，然后通过保持相同的声明性方法来扩展它们，以进一步满足应用程序的需求。

无服务器企业Java

Quarkus独特的卖点之一是在本地运行Java应用程序，它的启动时间极短。认真地说，几毫秒内开始的一切都会改变需求，我们需要快速启动和拆除我们的应用程序。

在几乎适用于所有Java的世界中，这仍然是最大的限制之一。从性能角度来看，JVM需要大量时间来启动，更不用说预热HotSpot引擎并达到其全部吞吐量了。相当公平，这是有原因的，因为运行时已针对长时间运行的流程中的吞吐量进行了优化。由于应用程序应该以快速启动为目标，以便用户可以等待它，因此，以常规方式启动JVM根本不够。

提到的AOT编译方法使我们能够在将Java应用程序作为本机映像执行时编写它们。通过这样做，我们使Java工作负载能够在“无服务器”环境中执行，在该环境中我们可以将工作负载扩展到零，并且能够快速启动，而不会以初始启动时间来惩罚用户。

但是，通常情况下，生活并不那么容易。 GraalVM不支持常规JVM的全部功能集，例如，它不以通常的方式支持Reflection，并且许多企业运行时都不会作为本机可执行文件开箱即用。

话虽如此，通过考虑到运行时的局限性来开发实现，在Red Hat的朋友们为Quarkus的开发付出了多少工作，这确实令人印象深刻。只有这样，我们才能结合这些部分并以本机方式运行Java Enterprise应用程序。 Quarkus应用程序在正常的JVM上也可以很好地运行，至少在我看来，启动过程“足够快”不到一秒钟。

尽管对于Enterprise Java而言，这是个好消息，但从我的角度来看，要求将其缩放到零并Swift启动，但启动时间并不是全部。尽管这一新举动当然很有趣，但我们不应该忘记，绝大多数企业正在运行，并且很可能会继续运行较长时间的工作量。但是，在运行时消除大多数“动态”的方法也对总体资源消耗产生积极影响，并且肯定是有希望的。

但是，在我看来，原生启动时间甚至不是最大的好处。

开发周转时间：“令人欣喜的编码”

Quarkus允许我们的开发人员以极快的热重载来修改和测试我们的业务代码。 Maven插件的quarkus:dev目标使我们能够更改和保存文件，框架可以自动方式重新加载类并在运行的应用程序内部交换行为。我们可以在几毫秒后重新执行并测试更改后的功能，这相当于在人类反应时间内立即完成。开发周期和反馈循环的周转时间因此变得尽可能短。正如我的朋友埃德森·柳永（Edson Yanaga）所说：“这是激发喜悦的编码”。我完全同意。

总的来说，我非常喜欢短延迟。我认为，应对延迟的口头禅是使许多Google服务使用起来令人愉悦。通常，在编码时，我们希望获得并留在流程中。开发人员的思考时间非常宝贵，我们不希望被这种流程打扰，而要等待几秒钟以上的时间；否则，一个人会分心，拿另一杯咖啡，或更糟糕的是，他们在社交媒体上转眼，便引起了您的注意。

在我看来，最短的周转时间是Quarkus框架的最大优势。但是，即使没有Quarkus，如果您使用现代的应用程序容器和某些工具，您也已经可以实现热重新部署时间，从而实现了按需开发模式。例如，Open Liberty可以在不到一秒钟的时间内部署应用程序，并且与WAD之类的工具结合使用时，我们可以真正缩短周转时间，如本视频所述。

有关集成测试的一些注意事项：很有帮助的是，整个Quarkus应用程序的快速启动使测试实际上更适合于在部署级别（而不是代码级别）进行集成测试。即，使用应用程序的通信接口部署和端到端测试单个应用程序。但是，构建时间缓慢的主要原因之一是测试阶段的运行时间长，每个阶段都会启动应用程序或应用程序的一部分。单。测试运行。即使Quarkus提供的启动时间很短，一旦越来越多的测试场景成为管道的一部分，这种影响也会变得巨大。通常，我们应该做的是在测试套件执行过程中定义一个或最多几个部署，在这些部署中，我们对应用程序进行端到端测试，而无需在这之间重新启动正在运行的被测应用程序。无论我们使用Quarkus的功能进行测试还是使用专门的测试项目来完善已启动的应用程序，这都无关紧要。

连续交货周转时间

GraalVM本机构建的缺点之一是该构建需要很长的时间。视您的机器而定，三十秒或更长时间。甚至比我们在Java世界中应该习惯的要更长的时间。在我们的开发管道中，这意味着我们不想在每次代码更改时都执行本机构建，而仅在持续交付管道中执行。即使如此，我们仍然需要考虑到这会减慢整体管道执行时间，否则可能会更快地执行。遵循只构建应用程序一次并在交付生产之前对完全构建的应用程序进行全面测试的口号，这意味着端到端/系统/验收测试的周转时间也会增加。

除了本地可执行文件之外，Quarkus还支持精简部署工件，如精简JAR，它仅包含由我们开发的实际业务逻辑类。 Quarkus可以使用这种方法，因为它将库和我们自己的代码分开。看一下构建的*-runner.jar的大小和内容。实现和所需的库包含在lib/目录下。与常规Java Enterprise应用程序一样，这使我们能够通过优化写时复制文件系统映像层来利用Docker的优势。如果您对这些图像层有所了解，您会注意到在容器化的世界中这当然是有道理的。容器映像的构建和传输时间也影响整个构建执行时间。在这种情况下，精简部署工件可提供最佳体验。根据我的经验，总体图像大小几乎没有关系；重要的是，我们可以多快地重建并重新传输实际更改的层。即使使用微小的本机映像，与精简的部署工件相比，这些大小和时间仍要大几个数量级。

在项目中，我们需要在管道执行时间和容器启动时间之间进行权衡。除了将规模缩减为零的方法外，部署方案还应使用某种形式的蓝绿色部署，以免用户无论如何都要停机。考虑到这一点，生产启动时间不再是问题，因为旧版本将始终保持活动状态，直到新版本准备推出为止。如果您参与的企业项目具有足够的用户，因此不必考虑将比例缩放到零，而是将新版本快速交付生产，则精简部署工件的方法可能更合适。

当前限制

当前框架的限制之一是Quarkus还不支持某些EE标准的全部集合。例如，不支持EJB。但是，支持事务，并且某些其他功能可以用Quarkus自己的功能代替。一个例子是调度，其中Quarkus附带了自己的@Scheduled注释。从我的角度来看，这似乎是一种合理的方法，可以尝试实现项目可能需要的功能并提供已经支持大多数必需功能的框架。

但是，Quarkus的发展非常Swift，所以让我们看看如何缩小这些差距。同样，我相信这个框架看起来多么成熟和详尽，令人印象深刻。

Maven插件声明，尤其是如何在Quarkus文档中进行广告宣传，还有其他可以改进的地方。很多人似乎都喜欢将大量XML放入其pom.xml ，但是我并不是那么多。我宁愿保持对Java应用程序关注点的清晰区分，而不是让Maven“构建一切”。如果我们允许项目使用Maven的默认值，我们将pom.xml内所需的LoC保持在最低限度，并由CI基础结构来处理最顶层的所有内容。例如，使用Quarkus，您至少可以摆脱其大部分pom.xml定义，而仅在CI管道中定义和构建本机映像。然后有可能将pom.xml稍微简化一下。

但是，该文档承诺将有一个本机CLI“即将推出”，这在我看来是有希望的。

结论

Quarkus将云原生企业Java提升到一个新的水平，并实现了以前不可能实现的方案，尤其是在应用程序启动时间方面。如果您打算将规模缩小到零，那么这无疑是您想要研究的技术。

我非常喜欢Quarkus如何跟进一些技术以前采用的方法，将它们进一步发展，并提供一个单一的框架，包括所有的保护伞。这使开发人员可以轻松上手，使用他们可能已经熟悉的企业标准，例如CDI或JAX-RS。在我看来，这是一个很大的好处：不是试图重塑企业世界，而是使用熟悉的技术，而是通过高度优化的实现。

作为开发人员，我发现AOT编译和其他JVM优化通常非常有趣。您还可以查看OpenJ9 JVM及其优化。将运行时与Quarkus应用程序的JVM执行模式结合起来可能会很有趣。

要获得“纯” Java EE的快速开发人员体验，您可以查看WAD以及如何将其集成到Docker中。