【上海校区】2020年你将会选择哪个微服务框架？ - 黑马程序员技术交流社区

截至2020年，Java仍然是构建Web应用程序的最流行的编程语言之一，尽管它必须面对来自Go，Python和TypeScript等新型语言的激烈竞争。

在Java世界内部，Spring框架已成为微服务开发的事实上的标准，通过诸如Spring Boot和Spring Data之类的库，该框架易于使用，并且可以进行高效且大部分情况下轻松进行开发。

但是，近年来，已经引入了新的框架，声称可以缩短Java应用程序的启动时间并减少其内存占用。由于我目前正在使用Java开发基于微服务的大型应用程序，因此我想测试哪种Java框架最适合这种架构。

因此，我的主要重点是开发的易用性以及微服务的资源消耗两个方面。

对于资源消耗方面，Spring一直都被人诟病，尤其是在涉及单个流程所需的资源开销。在应用程序服务器时代，由于实例数量很少，因此这并不是主要问题。但是，随着微服务架构及其大量小型实例的兴起，这个问题变得越来越明显。正如Christian Lusardi最近所说的那样：

为了解决早期Java Enterprise的复杂性，Spring于2003年应运而生。Spring核心是依赖注入（DI）和面向切面编程（AOP），后来衍生出易于使用的Spring MVC等Web应用框架。通过其良好的文档，全面的各方面整合类库，Spring使开发人员可以有效地创建和维护应用程序，并提供平坦的学习曲线。

Spring在运行时使用反射执行DI。因此，当启动spring应用程序时，将在类路径中扫描带注解的类。基于此，实例化并链接到具体对象。这种做法非常灵活且对开发人员很友好，但它可能使得启动过程缓慢并占用大量内存。另外，将这种机制迁移到GraalVM非常困难，因为GraalVM不支持反射。

Micronaut是比较新的全栈微服务框架，由Grails框架的创建者于2018年引入。

Micronaut提供了构建功能全面的微服务应用程序所需的所有工具。同时，它旨在提供快速启动并减少内存占用。通过使用Java注解处理器执行DI，创建面向切面的代理（而不是运行时）配置应用程序，可以实现此目标。

Micronaut中的许多API均受Spring和Grails的启发。这无可厚非，毕竟这样有助于快速吸引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年，与其前身JEE一样，MicroProfile是可以由各种供应商实施的规范。到目前为止，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的未来尚不清楚。因此，似乎两个项目将来可能会合并。

为了比较上述4个微服务框架，我已经使用它们实现了一个简单的应用程序。该示例应用程序包括一个用于创建，读取，更新和删除对象的REST接口，以及将这些对象存储到表中的接口。我使用OpenJDK Docker映像运行了所有应用程序。如果该框架支持生成本机GraalVM映像，我也比较了它们的性能。

我在具有四个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秒）都保证了缩短启动时间的承诺。

但是，真正的赢家是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开发者最佳体验，而且我认为它也仍然是最适合微服务应用程序的Java框架（即使启动时的性能比较差）。

让我感到惊讶的是，使用Hibernate / JPA / Spring Data的成本非常高。即使对于这个非常简单的应用程序，在内存（以及r/s）方面的开销也是巨大的。在这里，我特别喜欢Micronaut Data的解决方案，该解决方案无需JPA即可自动生成Dao代码。我认为Micronaut Data以后可以添加到Spring Data方案中。

事实证明，本机GraalVM映像在启动时具有令人难以置信的快速性和内存效率，但是在负载下，它们并没有明显的优势。由于本机GraalVM的生成会带来一些额外的困难，并且编译时间会急剧增加，因此该技术目前仅在需要快速启动时才有用。例如在Serviceless架构中。