2020年你将会选择哪一个微服务框架？

前言

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

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

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

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

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

“我发现使用Spring Boot运行的基本Java应用程序至少须要1GB的RAM，开发中间件应用程序不要紧，可是在微服务体系结构中，这很是糟糕！”

微服务框架介绍

1 Spring

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

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

2 Micronaut

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

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

Micronaut中的许多API均受Spring和Grails的启发。这无可厚非，毕竟这样有助于快速吸引Spring及Grails的开发人员。Micronaut提供了诸如Micronaut HTTP，数据，安全性和各类其余技术的链接器之类的模块。可是，这些库的成熟度仍落后于Spring的同类库。

3 Quarkus

Quarkus是Red Hat在2019年引入的Kubernetes原生Java框架。它基于MicroProfile，Vert.x，Netty和Hibernate等标准构建。

Quarkus的目标是经过在容器编排平台中容许更快的启动，较低的内存消耗和近乎即时的扩展来使Java成为Kubernetes中的领先平台。Quarkus经过使用自定义的Maven插件在编译时而不是在构建时执行尽量多的工做来达到此目的（在Quarkus中，这也称为编译时启动）。

Quarkus使用了大多数现有的标准技术，并且还支持扩展。可是，因为该项目仅在一年以前才开始，因此这些扩展的成熟度和兼容性并不老是很清楚。随着平台的发展，这种状况未来可能会改变。

4 Helidon MicroProfile

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的将来尚不清楚。所以，彷佛两个项目未来可能会合并。

微服务框架全方位大PK！

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

我在如下几个方面对比了它们的性能：

1. 把上述的示例应用程序开发出来要多久？要实现这些框架，我必须查看框架官方文档以及在诸如Stack Overflow之类的平台上搜索信息。
2. 编译应用程序须要多长时间？我已经测试了执行干净构建所需的时间，包括生成Docker映像。对于GraalVM，这包括生成本机映像的时间。
3. 启动应用程序须要多长时间？在这里，我测试了从运行docker up到应用程序正确响应第一个HTTP请求之间的时间。另外，我还比较了启动后测试的空闲应用程序的内存占用量。
4. 应用程序支持请求负载状况如何？我使用JMeter进行负载测试，并对应用程序进行了测试，其中25％的请求执行数据库写入，而75％的请求仅执行数据库读取。而后，我再次根据其峰值性能来测量应用程序的内存占用量。

我在具备四个Intel Haswell CPU和15 GB内存且运行Ubuntu 19.01的Google Cloud Platform虚拟机上执行了全部测试。全部测量均已重复屡次，以免干扰因素。您能够在GitHub上找到使用的脚本以及原始数据。

https://github.com/lizzyTheLizard/medium-java-framework-compare/tree/master/compare

测试结果

1 上手难度

因为我之前就有Spring Boot的知识，因此这是一个不公平的比较。可是，在查询文档以及可用的信息和示例时，Spring确实是迄今为止使用起来最简单的框架。

Micronaut的文档作得很好，而且具备与Spring和Grail相似的API。所以，Spring开发人员很容易开始使用它。

我认为，Quarkus的学习曲线较为陡峭，由于与Spring和Micronaut相比，库和API的成熟度较低。我特别缺乏简单的数据库访问权限。

在我看来，Helidon显然是最后一名，由于我为应用程序运行付出了很大的努力。

2 编译时间

全部框架，使用OpenJDK时的编译时间都很是类似，而且在6.98秒（使用JDBC的Spring）和10.7秒（Quarkus）之间。

可是，原始GraalVM映像的生成很是耗时，花费了231.2秒（使用JDBC的Micronaut）和351.7秒（使用JPA的Micronaut）之间。这使得本机映像对于开发基本上毫无用处，由于等待四分钟来编译一个简单的应用程序实在太多了。

3 启动运行时间

使用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。

4 峰值负载性能

在负载下，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架构中。

欢迎关注个人公众号：：一点教程。得到独家整理的学习资源和平常干货推送。

若是您对个人系列教程感兴趣，也能够关注个人网站：yiidian.com