转载

关于Quarkus的思考

Quarkus，这个新的“超音速，亚原子”Java框架目前正受到很多关注。使用Quarkus有什么好处和缺点？

摆脱动态

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

Quarkus采用的方法是定制一个仅包含应用程序所需内容的运行时，并简化企业运行时的大部分动态。企业Java代码严重依赖于控制反转（IoC），又名“不要调用给我们，我们会调用你”。想一想依赖注入 @Inject，HTTP资源的@Path和@GET，或者事件观察者@Observes。我们开发人员声明性地指定应该发生什么，并且实现确保它发生。这能够有一个非常高效的编程模型，但在运行时也会带来繁重的工作，因为有人必须将所有这些松散的末端组合在一起。现在，我们的想法是，如果我们的应用程序不应该在运行时发生变异， 那么大多数动态都可以在构建时解决 。结果代码可以主要包括直接调用; 所有的魔力都被摧毁了。

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。EventBus例如，Vert.x的类型是可注入的@Inject。这符合我们在EE中习惯的开发人员体验。

我喜欢从已知的企业API开始的方法，并通过保持相同的声明性方法来扩展它们与应用程序所需的内容。

无服务器企业Java

Quarkus的独特卖点之一，本机运行Java应用程序是极短的启动时间。同样严肃地说，在几毫秒内开始的一切都是需求的游戏转换器，我们需要快速启动和拆除我们的应用程序。

这仍然是其他适合几乎所有Java世界的最大限制之一。在性能方面，JVM需要大量的时间来启动，更不用说预热HotSpot引擎并达到它的全部吞吐量。很公平，这是有原因的，因为运行时主要针对长时间运行的流程中的吞吐量进行了优化。随着应用程序应该快速启动的需求，以及快速启动以便用户可以等待它，仅仅以正常方式启动JVM是不够的。

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

然而，通常情况下，在实践中生活并不那么容易。GraalVM不支持常规JVM的整个功能集，例如，它不以通常的方式支持Reflection，并且许多企业运行时不会作为本机可执行文件运行。

话虽如此，通过开发具有此运行时限制的实现，Red Hat的朋友们为Quarkus的开发投入了多少工作，这令人印象深刻。只有这样我们才能组合这些部分并以本机方式运行我们的Java Enterprise应用程序。Quarkus应用程序在普通JVM上运行良好，启动速度“足够快”，至少在我看来，不到一秒。

尽管对于Enterprise Java来说都是好消息，并且要求缩小到零并因此快速启动，从我的角度来看，启动时间并不是一切。虽然这个新的运动当然很有趣，但我们不应忘记，绝大多数企业正在运行，并且可能会继续运行他们的工作量更长的时间。然而，在运行时摆脱大多数“动态”的方法也对整体资源消耗产生积极影响，并且肯定是有希望的。

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

最小的周转时间

Quarkus允许我们的开发人员通过极快的热重新加载来修改和测试我们的业务代码。quarkus:devMaven插件的目标使我们能够更改和保存文件，框架重新加载类并以自动方式交换正在运行的应用程序内的行为。我们可以在几毫秒之后，即在人类反应时间内，立即重新执行并测试已更改的功能。因此，开发周期和反馈环路的周转时间变得越来越短。正如我的朋友埃德森·亚纳加所说的那样：“这才是编码，激发了喜悦”。我完全同意。

总的来说，我是短暂延迟的忠实粉丝。战斗延迟的咒语是我认为使很多Google服务使用的乐趣。一般来说，在编码时，我们希望得到并留在流程中。开发人员的思考时间非常宝贵，我们不希望被这个流程中断并等待超过几秒钟; 否则一个人会分心，拿起另一杯咖啡，或者更糟糕的是，在社交媒体上看，并引起你的注意。

在我看来，这个 最小的周转时间是Quarkus框架的最大优势 。但是，即使没有Quarkus，如果使用现代应用程序容器和一些工具，您也可以实现热重新部署时间，从而实现保持流式开发模式。例如，Open Liberty可以在不到一秒的时间内部署应用程序，当与 WAD 等工具结合使用时，我们可以真正改善周转时间，如本视频所述。

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

持续交付周转时间

本机构建alàGraalVM的缺点之一是这个构建需要花费很多时间。取决于你的机器三十秒甚至更长时间。甚至比我们在Java世界中应该习惯的更长。在我们的开发流程中，这意味着我们不希望仅在Continuous Delivery管道内执行每次代码更改的本机构建。即使如此，我们还需要考虑到这将减慢我们的整体管道执行时间，否则可以更快地执行。遵循建立我们的应用程序只需一次并在我们投入生产之前对其进行全面测试的咒语，这意味着端到端/系统/验收测试周转时间也会增加。

除了本机可执行文件之外，Quarkus还支持精简部署工件，作为瘦JAR，它只包含由我们开发的实际业务逻辑类。Quarkus可以采用这种方法，因为它分离了库和我们自己的代码的关注点。看看内置的大小和内容*-runner.jar。实现和所需的库包含在lib/目录。与常规Java Enterprise应用程序一样，这使我们可以通过优化写时复制文件系统镜像层来利用Docker的优势。

如果您对这些镜像层有所了解，您会发现这在Docker化世界中确实有意义。容器镜像的构建和传输时间也会影响整个构建执行时间。在这种情况下，精简部署工件可提供最佳体验。根据我的经验，整体镜像尺寸很少重要; 重要的是我们能够多快地重新构建和重新传输实际变化的层。即使使用微小的原生图像，与薄的部署工件相比，这些尺寸和时间仍然要大几个数量级。

在项目中，我们需要在管道执行时间和容器启动时间之间进行权衡。除了扩展到零的方法之外，部署方案应该使用某种形式的蓝绿色部署，以避免用户的停机时间。考虑到这一点，生产启动时间变得不那么成问题，因为旧版本将始终保持活动状态，直到新版本准备好滚动。如果您参与具有足够用户的企业项目，以便无需考虑扩展到零，但是快速将新版本发布到生产中，那么精简部署工件的方法可能更合适。

目前的局限

目前的框架限制之一是Quarkus还不支持一些EE标准的全套。例如，不支持EJB。但是，支持事务，其他一些功能可以用Quarkus自己的功能代替。一个例子是调度Quarkus发布自己的@Scheduled注释。这似乎是一种合理的方法，试图实现项目可能需要的功能，并从我的角度提供已经支持大部分所需功能的框架。

然而，Quarkus的行动非常迅速，所以让我们看看这些差距是如何关闭的。再一次，我相信这个框架已经成熟和详尽，这是非常令人印象深刻的。

Maven插件声明，特别是它如何在Quarkus文档中做广告是可以改进的其他东西。很多人似乎都喜欢将大量的XML放入其中pom.xml，但是，我并没有那么多。我更喜欢保持Java应用程序关注点的清晰分离，而不是让Maven“构建所有东西”。如果我们允许项目使用Maven的默认值，我们将所需的LoC保持在pom.xml最低限度内，并且让所有内容都由CI基础结构处理。使用Quarkus，您至少可以摆脱其大部分pom.xml定义，并且仅在CI管道中定义和构建本机映像。然后可以pom.xml稍微归结一下。

但是，文档承诺有一个本地CLI“即将推出”，这听起来很有希望。

结论

Quarkus将云原生Enterprise Java提升到了一个新的水平，并支持以前无法实现的方案，特别是在应用程序启动时间方面。如果您计划将规模扩展为零，那么这肯定是您想要了解的技术。

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

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

有了“普通”Java EE的快速周转开发人员体验，您可以查看 WAD 以及如何将其集成到Docker中。

原文 https://www.jdon.com/52039

正文到此结束