探索Micronaut和Quarkus与Spring Boot的关系-它们有多好？
到2020年，Java仍然是构建Web应用程序的最流行的编程语言之一，尽管它必须面对来自Go，Python和TypeScript等新型语言的激烈竞争。
在Java世界内部，Spring框架已成为微服务开发的事实上的标准，通过诸如Spring Boot和Spring Data之类的库，该框架易于使用，并且可以进行高效且大部分情况下轻松进行开发。
但是，近年来，已经引入了新的框架，声称可以缩短Java应用程序的启动时间并减少其内存占用。 由于我目前正在使用Java开发基于微服务的大型应用程序，因此我想检查哪种Java框架最适合这种架构。
因此，我的主要重点是易于开发以及生成的微服务的资源管理。
关于资源管理，Spring（实际上是Java平台的大多数）从未有过最好的声誉，尤其是在涉及单个流程所需的开销方面。 在应用服务器时代，这并不是主要的问题，因为实例数量很少。 但是，随着微服务架构及其大量小型实例的兴起，这已成为越来越多的问题-或正如Christian Lusardi最近所说的那样：
"我发现在Spring Boot上运行的基本Java应用程序至少需要1GB的RAM才能运行，开发中间件应用程序没关系，但是在微服务架构中，这非常糟糕！"
响应于早期Java Enterprise的复杂性，Spring于2003年应运而生。 Spring的核心是依赖注入（DI）和面向方面的编程（AOP）框架，后来演变为易于使用的Web应用程序框架。 通过其广泛的文档，广泛的使用和无数的库，Spring使开发人员可以有效地创建和维护应用程序，并提供平坦的学习曲线。
Spring在运行时使用反射执行DI。 因此，当启动spring应用程序时，将在类路径中扫描带注释的类。 基于此，实例化并链接具体对象。
尽管这种方法非常灵活且对开发人员友好，但它会使启动速度变慢，并且非常消耗内存。 此外，由于该机制不支持反射，因此很难迁移到GraalVM。
Micronaut是现代的全栈微服务框架，由Grails框架的创建者于2018年引入。
它提供了构建功能全面的微服务应用程序所需的所有工具。 同时，它旨在提供快速启动并减少内存占用。 通过使用Java注释处理器执行DI，创建面向方面的代理并在编译时（而不是运行时）配置应用程序，可以实现此目标。
Micronaut中的许多API均受Spring和Grails的启发。 这是设计使然，有助于快速吸引新开发人员。 因此，Micronaut提供了诸如Micronaut HTTP，数据，安全性和各种其他技术的连接器之类的模块。 但是，这些库的成熟度仍落后于Spring的同类库。
Quarkus是Red Hat在2019年推出的Kubernetes原生Java框架。它基于MicroProfile，Vert.x，Netty和Hibernate等标准构建。
Quarkus的目标是通过在容器编排平台中允许更快的启动，较低的内存消耗和近乎即时的扩展来使Java成为Kubernetes中的领先平台。 Quarkus通过使用自定义的Maven插件在编译时而不是在构建时执行尽可能多的工作来达到此目的（在Quarkus中，这也称为编译时启动）。
Quarkus正在使用大多数现有的标准技术，但可以扩展。 但是，由于该项目仅在一年前才开始，所以这些扩展的成熟度和兼容性并不总是很清楚。 随着平台的发展，这种情况将来可能会改变。
MicroProfile项目始于2016年，当时尚不清楚Oracle是否以及如何继续在Java Enterprise上工作。
与其前身JEE一样，MicroProfile是可以由各种供应商实施的规范。
此后已经提出了多种这样的实现方式，最著名的是Payara Micro和Helidon MP。 Payara是从GlassFish派生的Jakarte EE服务器，而Payara Micro是其MicroProfile实现。 Helidon是Oracle在2018年启动的运行时，提供了自己的MicroProfile规范实现。
由于它们是从JEE衍生而来的，因此MicroProfile规范已经很成熟并且有据可查。 但是，缺少用于现代技术的连接器或替代诸如Spring Data和Spring Security之类的库的方法。
此外，由于同时开始了Jakarta EE（也在Eclipse Foundation中）的开发，MicroProfile的未来尚不清楚。 因此，似乎两个项目将来可能会合并或至少紧密协调。
为了比较上述框架，我使用了每个框架都实现了一个简单的应用程序。 该示例应用程序包括一个用于创建，读取，更新和删除对象的REST接口，以及一个将这些对象存储到表中的关系数据库连接器。
如果框架支持访问数据库的不同方法，那么我将尝试为不同的变体实现示例项目。 然后，我比较了这些应用程序的性能。
我使用OpenJDK Docker映像运行了该应用程序。 如果框架支持生成本机GraalVM映像，则我还比较了它们的性能。 另外，请查看我的文章"使用R2DBC，Micronaut和GraalVM进行响应式数据库访问"，以获取有关GraalVM的更多信息。 所有这些应用程序的源代码都可以在GitHub上找到。
我在三个关键阶段比较了这些应用程序的性能：
· 实施示例应用程序有多容易？ 要实现这些框架，我必须检查文档以及在诸如Stack Overflow之类的平台上搜索信息。
· 编译应用程序需要多长时间？ 我已经测量了执行干净构建所需的时间，包括生成Docker映像的时间。 对于GraalVM，这包括生成本机映像的时间。
· 启动应用程序需要多长时间？ 在这里，我测量了从运行docker到应用正确响应第一个HTTP请求之间的时间。 另外，我还比较了启动后测量的空闲应用程序的内存占用量。
· 负载：应用程序可以查看多少个请求？ 我使用JMeter进行负载测试，并对应用程序进行了测试，其中25％的请求执行数据库写入，而75％的请求仅执行数据库读取。 然后，我再次根据其峰值性能来测量应用程序的内存占用量。
我在具有四个Intel Haswell CPU和15 GB内存且运行Ubuntu 19.01的Google Cloud Platform虚拟机上执行了所有测试。 所有测量均已重复多次，以避免干扰因素。 您可以在GitHub上找到使用的脚本以及原始数据。
由于我以前只有使用Spring Boot的知识，所以这是一个不公平的比较。 但是，在检查文档以及可用的信息和示例时，Spring是迄今为止最简单的框架。
Micronaut的文档做得很好，并且具有与Spring和Grail类似的API。 因此，Spring开发人员很容易开始使用它。
我认为，Quarkus的学习曲线较为陡峭，因为与Spring和Micronaut相比，库和API的成熟度较低。 我特别缺少简单的数据库访问权限。
但是，在我看来，Helidon显然是最后一次，因为我为使应用程序运行付出了很多努力。
对于所有框架，使用OpenJDK时的编译时间都非常相似，并且在6.98秒（使用JDBC的Spring）和10.7秒（Quarkus）之间。
但是，原始GraalVM映像的生成非常耗时，并且花费了231.2秒（使用JDBC的Micronaut）和351.7秒（使用JPA的Micronaut）之间。 这使得本机映像对于开发基本上毫无用处，因为等待四分钟来编译一个简单的应用程序实在太多了。
使用Spring Data的Spring Boot应用程序平均花了8.16秒来启动。 删除JPA和Spring Data可以将其减少到5.8秒。
在这里，Micronaut（使用JPA的时间为5.08秒，使用JDBC的时间为3.8秒）和Quarkus（5.7秒）保持了缩短启动时间的承诺。
只有Helidon MP甚至比Spring慢-平均为8.27秒。
但是，真正的赢家是GraalVM。 本机映像的启动时间在1.39秒（Quarkus）和1.46秒（使用JDBC的Micronaut）之间，比OpenJDK实现要快得多。
引导后直接使用的内存使用情况非常相似。 Spring分配了420 MB内存（使用Spring Data）和261 MB（使用JDBC）。
使用JPA时Micronaut的内存为262 MB，使用JDBC时为178 MB。
197 MB的Quarkus表现更好。 Helidon MP具有414 MB，与Spring Boot类似。
同样在这里，仅使用7 MB（Quarkus）和27 MB（Micronaut使用JPA）的内存，本地GraalVM映像就大大优于OpenJDK实现。
在负载下，Spring Boot表现出色，能够每秒处理342（使用Spring Data）和216（JDBC）请求（r / s），并使用581 MB（Spring Data）和484 MB（JDBC）内存。 Helidon显然是最后一个，仅能以175 r / s的速度分配超过1 GB的内存。
其他框架能够在400 r / s（Quarkus作为本机映像运行）和197 r / s（OpenJDK上的Quarkus）之间提供服务。 各种Micronaut实现介于两者之间，与JDBC相比，JPA和本机映像比OpenJDK略有优势。
在内存使用方面，OpenJDK上的Quarkus表现出色，仅消耗255 MB内存。 这甚至比同一个应用程序作为本机映像运行要少得多，该应用程序平均花费368 MB的内存。
但是，Micronaut却非常浪费。 在OpenJDK中运行的JPA实现平均使用880 MB，比Spring的内存使用量高50％以上。 但是，使用JDBC和本机映像有助于Micronaut将其内存占用空间减少到367.8 MB。
与Spring和MicroProfile之类的现有框架相比，新的Java框架Micronaut和Quarkus保证了更快的启动时间和更低的内存占用。
他们的确兑现了这一诺言-但只有在闲置或负载很小的情况下才可以。 在这里，它们的性能优于Spring，特别是将它们与本地GraalVM图像结合使用时。 但是，在负载下，它们没有提供太多优势，即使当作为本机图像运行时也是如此。
到目前为止，尽管Spring仍然提供最佳的开发人员体验，但我认为它仍然是最适合微服务应用程序的Java框架-即使考虑到启动时的性能也很差。
让我感到惊讶的是使用Hibernate / JPA / Spring Data的巨额成本。 即使对于这个非常简单的应用程序，在内存（以及r / s）方面的开销也是巨大的。 在这里，我特别喜欢Micronaut Data的解决方案，该解决方案无需JPA即可自动生成存储库代码。 这确实可以添加到Spring Data中。
事实证明，原始GraalVM映像在启动时具有令人难以置信的快速性和内存效率，但是在负载下，它们并没有提供明显的优势。 由于本机GraalVM的生成会带来一些额外的困难，并且编译时间会急剧增加，因此该技术目前仅在需要快速启动的情况下才有用-例如，在无服务器架构中或非常快速地扩展。 在所有其他情况下，与负载下的类似性能相比，成本仍然太高。
(本文翻译自Matthias Graf的文章《Which Java Microservice Framework Should You Choose in 2020?》，参考：https://medium.com/better-programming/which-java-microservice-framework-should-you-choose-in-2020-4e306a478e58)