学校资源网站的建设方案,西安房产网站大全,浏网站建设补贴,手机网站 切图夸克代码Quarkus#xff0c;新的“超音速#xff0c;亚原子” Java框架目前正受到广泛关注。 对于企业Java的未来而言#xff0c;此构建和运行时工具背后的思想确实比我们感兴趣。 使用Quarkus有什么好处和缺点#xff1f; 摆脱动力 Quarkus认为#xff0c;在容器化的世… 夸克代码 Quarkus新的“超音速亚原子” Java框架目前正受到广泛关注。 对于企业Java的未来而言此构建和运行时工具背后的思想确实比我们感兴趣。 使用Quarkus有什么好处和缺点 摆脱动力 Quarkus认为在容器化的世界中企业Java运行时的大多数动态并不是真正需要的。 将应用程序构建到容器映像后通常不应更改其功能。 企业容器带来的所有动态都允许使用功能强大且灵活的编程和部署模型但是一旦我们的应用程序在容器中启动后它们通常将不再更改。 Quarkus采取的方法是定制仅包含应用程序所需内容的运行时并简化企业运行时的大部分动态。 企业Java代码在很大程度上依赖于控制反转IoC也就是“不给我们打电话我们给您打电话”。 想依赖注入的ALA Inject HTTP与资源Path和GET 或与事件观察家Observes 。 我们的开发人员以声明方式指定应该发生什么并且实现可以确保实现。 这允许非常高效的编程模型但在运行时也会带来繁重的工作因为有人必须将所有这些松散的末端放在一起。 现在我们的想法是如果我们的应用程序不应该在运行时发生变异那么大多数这些动态因素都可以在构建时解决。 然后生成的代码主要可以包括直接调用。 所有的魔法都被烧掉了。 现在这与过去从今天看来不支持IoC且需要直接调用代码中功能的笨重的企业框架所实现的结果相同吗 从开发人员的角度来看一点也不。 在我们的代码中我们仍然使用相同的有效声明式方法相同的注释。 构建过程负责将动态重新带回现实。 Quarkus还支持使用GraalVM构建本机可执行文件。 通过这种方法我们使用提前AOT编译将应用程序预先构建并编译为本机可执行文件而这些本机可执行文件无需动态扫描所有类并将其加载到JVM中。 与常规JVM相比生成的可执行文件启动速度非常快并且资源消耗较低。 标准的力量 在Quarkus上我发现最吸引人的是它基于已知的企业标准构建例如CDIJAX-RS等。 我们可以通过本机可执行文件或使用Java运行时在优化的运行时中运行应用程序而不是使用成熟的应用程序服务器。 许多起义企业框架要求开发人员再次学习新的API有时有时甚至更少重新发明方向例如如何实现REST端点。 但是从开发人员和项目的角度来看当现有的API和解决方案足够时我看不到重新学习和重新编写应用程序的好处。 使用Quarkus所采用的方法开发人员可以编写和采用基于CDIJAX-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目标使我们能够更改和保存文件框架可以自动方式重新加载类并在运行的应用程序内交换行为。 我们可以在几毫秒后重新执行并测试更改后的功能这在人类的React时间内即刻完成。 开发周期和反馈回路的周转时间因此变得尽可能短。 正如我的朋友埃德森·柳永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中。 翻译自: https://www.javacodegeeks.com/2019/04/thoughts-quarkus.html夸克代码
