软件设计：2020年你将会选择哪个微服务框架？

　　微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

　　微服务可以在"自己的程序"中运行，并通过"轻量级设备与HTTP型API进行沟通"。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。

　　前言

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

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

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

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

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

　　“我发现使用SpringBoot运行的基本Java应用程序至少需要1GB的RAM，开发中间件应用程序没关系，但是在微服务体系结构中，这非常糟糕！”

　　微服务框架介绍

　　1Spring

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

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

　　2Micronaut

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

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

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

　　3Quarkus

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

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

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

　　4HelidonMicroProfile

　　MicroProfile项目立项于2016年，与其前身JEE一样，MicroProfile是可以由各种供应商实施的规范。到目前为止，MicroProfile规范已经提出了多种实现方式，最著名的是PayaraMicro和HelidonMP。

　　Payara是从GlassFish派生的JakarteEE服务器，而PayaraMicro是其MicroProfile实现。Helidon是Oracle在2018年启动的运行时，提供了自己的MicroProfile规范实现。

　　由于它们是从JEE派生的，因此MicroProfile规范已经很成熟并且有据可查。但是，缺少用于现代技术的连接器或替代诸如SpringData和SpringSecurity之类的库的方法。

　　此外，由于同时开始了JakartaEE（也在EclipseFoundation中）的开发，MicroProfile的未来尚不清楚。因此，似乎两个项目将来可能会合并。

　　微服务框架全方位大PK！

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

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

　　1把上述的示例应用程序开发出来要多久？要实现这些框架，我必须查看框架官方文档以及在诸如StackOverflow之类的平台上搜索信息。

　　2**编译应用程序需要多长时间？**我已经测试了执行干净构建所需的时间，包括生成Docker映像。对于GraalVM，这包括生成本机映像的时间。

　　3启动应用程序需要多长时间？在这里，我测试了从运行dockerup到应用程序正确响应第一个HTTP请求之间的时间。另外，我还比较了启动后测试的空闲应用程序的内存占用量。

　　4应用程序支持请求负载情况如何？我使用JMeter进行负载测试，并对应用程序进行了测试，其中25％的请求执行数据库写入，而75％的请求仅执行数据库读取。然后，我再次根据其峰值性能来测量应用程序的内存占用量。

　　我在具有四个IntelHaswellCPU和15GB内存且运行Ubuntu19.01的GoogleCloudPlatform虚拟机上执行了所有测试。所有测量均已重复多次，以避免干扰因素。您可以在GitHub上找到使用的脚本以及原始数据。

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

　　测试结果

　　1上手难度

　　由于我以前就有SpringBoot的知识，所以这是一个不公平的比较。但是，在查询文档以及可用的信息和示例时，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启动运行时间

　　使用SpringData的SpringBoot应用程序平均花了8.16秒来启动。删除JPA和SpringData可以将其减少到5.8秒。

　　正如官方所说，Micronaut（使用JPA的时间为5.08秒，使用JDBC的时间为3.8秒）和Quarkus（5.7秒）都保证了缩短启动时间的承诺。

　　HelidonMP甚至比Spring慢-平均耗时为8.27秒。

　　但是，真正的赢家是GraalVM。本机映像的启动时间在1.39秒（Quarkus）和1.46秒（使用JDBC的Micronaut）之间，比OpenJDK实现要快得多。

　　所有框架运行时使用的内存使用情况非常相似。Spring分配了420MB内存（使用SpringData）和261MB（使用JDBC）。使用JPA时Micronaut的内存为262MB，使用JDBC时为178MB。197MB的Quarkus表现更好。HelidonMP耗时414MB，与SpringBoot类似。

　　同样，仅使用7MB（Quarkus）和27MB（Micronaut使用JPA）的内存，原生GraalVM映像的表现大大优于OpenJDK。

　　4峰值负载性能

　　在负载下，SpringBoot表现出色，能够处理每秒342（使用SpringData）和216（JDBC）请求（r/s），并使用581MB（SpringData）和484MB（JDBC）内存。Helidon显然是最后一名，只能提供175r/s的速度，同时分配超过1GB的内存。

　　其他框架能够在400r/s（Quarkus作为本机映像运行）和197r/s（OpenJDK上的Quarkus）之间提供服务。各种Micronaut实现介于两者之间，与JDBC相比，JPA和本机映像比OpenJDK略有优势。

　　在内存使用方面，OpenJDK上的Quarkus表现出色，仅消耗255MB内存。这甚至比同一个应用程序作为本机映像运行要少得多，该应用程序平均花费368MB的内存。

　　但是，Micronaut却非常浪费。在OpenJDK中运行的JPA实现平均使用880MB，比Spring的内存使用量高50％以上。但是，使用JDBC和本机映像有助于Micronaut将其内存占用空间减少到367.8MB。

　　结论

　　与Spring和MicroProfile之类的现有框架相比，新的Java框架Micronaut和Quarkus保证了更快的启动时间和更低的内存占用。

　　他们的确兑现了这一诺言-但只有在闲置或负载很小的情况下才可以。在这里，它们的性能优于Spring，特别是将它们与本地GraalVM图像结合使用时。但是，在高负载下，它们即使在作为本机映像运行时也无法提供太多优势。

　　到目前为止，Spring在开发上给Java开发者最佳体验，而且我认为它也仍然是最适合微服务应用程序的Java框架（即使启动时的性能比较差）。

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

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

　　在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。