经过一年的发展,随着Object Computing(OCI)发布候选版本RC1、RC2和RC3,Micronaut 1.0在过去三周内加速了。Micronaut是一个基于JVM的全栈框架,用于创建可以用Java、Groovy和Kotlin编写的基于微服务的应用程序。
\u0026#xD;\n\u0026#xD;\n在今年早些时候的Greach大会上,OCI首席软件工程师Graeme Rocher和Grails\u0026amp;Micronaut产品主管介绍了Microaut。随后,在5月底,Micronaut 开放了源代码。
\u0026#xD;\n\u0026#xD;\n三个候选版本包括以下新特性:GraalVM本地镜像支持、Swagger(OpenAPI)编译时支持、编译时验证以及编译时映射注解。Micronaut的测试框架Micronaut Test 1.0 RC1也是在RC3中发布的。
\u0026#xD;\n\u0026#xD;\nMicronaut使用了依赖注入和预编译(AOT)。以下是来自其网站的介绍:
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n基于反射的IoC框架为代码中的每个字段、方法和构造函数加载和缓存反射数据,而使用Micronaut,应用程序的启动时间和内存消耗将不受代码库大小的限制。
\u0026#xD;\n
以Netty为基础,Micronaut提供了他们自己的非阻塞Web服务器。为了减少内存消耗,Micronaut反应式客户端可以用声明的方式构建,并在编译时实现。
\u0026#xD;\n\u0026#xD;\nMicronaut内置了几个配置文件,用于生成可以运行的应用程序框架,作为开发Web或命令行应用程序的构建块。每个配置文件由一个模板和特定于该配置文件的附加命令组成。例如,create-app启动服务的配置文件,其中包含用于构建控制器(create-controller)和客户端(create-client)类的附加命令,这些命令在其他配置文件中可能不可用。
\u0026#xD;\n\u0026#xD;\n在下载并安装Micronaut之后,可以通过命令行或Microaut shell创建应用程序。受到Grails中人们熟知的命令行接口的启发,Micronaut遵循了同样的应用程序创建概念。考虑以下命令:
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n$ mn create-app org.redlich.demo
\u0026#xD;\n\u0026#xD;\n
如下所示,这将创建一个Java应用程序和Gradle项目,根文件夹为demo,包名为org.redlich。
\u0026#xD;\n\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n注意,其中包含了测试目录结构、Dockerfile和YAML配置文件。文件micronaut-cli.yml提供了关于项目的具体信息:
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nprofile: service\u0026#xD;\ndefaultPackage: org.redlich\u0026#xD;\n---\u0026#xD;\ntestFramework: junit\u0026#xD;\nsourceLanguage: java
\u0026#xD;\n\u0026#xD;\n
生成的Java源代码文件Application.java启动了一个Micronaut服务器:
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\npackage org.redlich;\u0026#xD;\n\u0026#xD;\nimport io.micronaut.runtime.Micronaut;\u0026#xD;\n\u0026#xD;\npublic class Application {\u0026#xD;\n\u0026#xD;\n public static void main(String[] args) {\u0026#xD;\n Micronaut.run(Application.class);\u0026#xD;\n }\u0026#xD;\n }\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n
构建并运行这个初步应用:
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n$ ./gradlew run \u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n
向上面的项目中添加一个控制器:
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n$ mn create-controller HelloController\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n
如下所示,文件HelloController.java和HelloControllerTest.java被添加到项目。
\u0026#xD;\n\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n在生成的HelloController.java文件中,注意下@Controller注解中的端点如何根据HelloController控制器的名称命名为“/hello”:
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\npackage org.redlich;\u0026#xD;\n\u0026#xD;\nimport io.micronaut.http.annotation.Controller;\u0026#xD;\nimport io.micronaut.http.annotation.Get;\u0026#xD;\nimport io.micronaut.http.HttpStatus;\u0026#xD;\n\u0026#xD;\n@Controller(\"/hello\")\u0026#xD;\npublic class HelloController {\u0026#xD;\n\u0026#xD;\n @Get(\"/\")\u0026#xD;\n public HttpStatus index() {\u0026#xD;\n return HttpStatus.OK;\u0026#xD;\n }\u0026#xD;\n }\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n
Java和Gradle是默认的语言和构建工具。要生成Groovy和Kotlin应用程序,请执行下面的命令:
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n$ mn create-app org.redlich.demo --lang groovy\u0026#xD;\n$ mn create-app org.redlich.demo --lang kotlin\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n
也支持生成Maven项目:
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n$ mn create-app org.redlich.service --build maven\u0026#xD;\n$ ./mvnw compile exec:exec\u0026#xD;\n
\u0026#xD;\n\u0026#xD;\n
在Micronaut教程第一部分中,OCI软件工程师Sergio del Amo Caballero演示了如何使用Java、Groovy和Kotlin三种语言创建三个微服务。Rocher向InfoQ介绍了这个最新版本。
\u0026#xD;\n\u0026#xD;\nInfoQ:是什么促使OCI开发了这个新的微服务框架?
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nGraeme Rocher: 在过去的几年里,技术领域发生了巨大的变化,特别地,如果你看看类似Docker、Kubernetes这样的系统以及无服务器运动,你会发现,它们实际上都针对低内存微服务和低开销应用程序而进行了优化。其结果是,像Go和Node这样的语言在这些平台上体现出了比Java更显著的吸引力,因为它们具有出色的冷启动性能和内存消耗。有一个非常好的问题,可以问下自己,如果Docker和Kubernetes团队有各种技术选项,为什么要选择Go而不是Java来实现这些平台?在我看来,答案很简单:如果他们用Java编写了那些技术栈,并且有了今天这些技术选项,那么我们就都需要一台超级计算机才能让笔记本电脑在本地运行它们。
\u0026#xD;\n\u0026#xD;\n原因是多种多样的。一方面是语言层面的限制。JVM是一项惊人的技术成果,但对于短时间运行的操作(如无服务器函数),它提供的优化往往就不存在了,但是,你仍然需要拖着整个JVM来运行你的应用程序。像GraalVM这样的项目有可能通过将Java应用程序编译成本地镜像来解决这些限制,但是,坦率地说,框架设计人员在提高Java应用程序的效率方面有很大的作用。
\u0026#xD;\n\u0026#xD;\n在框架层,传统的JVM框架(如Spring和Java/Jakarta EE)已经有超过10年的历史了,那时,每个人都在部署单体应用程序,它们主要是围绕着反射和注解的运行时分析来构建。这种方法的问题在于,由于各种各样的问题,从类型擦除,到有限的注解API,再到反射逻辑的相对缓慢,所以,几乎不可能构建一个Java框架,启动速度超快,而内存消耗超低。框架运行时的负担是巨大的。如果你观察一下Spring在运行时所做的工作,就会发现这有些不可思议,从用ASM解析字节代码来生成注解元数据,到积极缓存反射信息以避免不可避免的重复读取减慢速度。在缓存所有这些运行时生成的信息与实现快速启动和低内存消耗的目标之间存在着不可调和的冲突。
\u0026#xD;\n\u0026#xD;\n我们相信,Micronaut是面向未来的框架的基础,通过消除所有反射的使用,以及在编译时通过一组注解处理器和执行预编译(AOT)的AST转换,生成所有注解元数据、代理和框架基础设施,消除这种矛盾。这使得Micronaut能够实现极快的启动速度、低内存消耗,并且实现与GraalVM本地镜像兼容性的重大改进。
\u0026#xD;\n\u0026#xD;\n当然,Java生态系统有大量的项目是基于Java的,像Spring、Kafka、Cassandra、Hadoop、Grails等,它还有一个丰富的语言生态系统,包括Groovy、Scala、Kotlin、Java、Clojure等。因此,这也不全是和低内存占用的微服务与无服务器应用程序有关,有许许多多的工作负载仍然受益于JVM和JIT。然而,即使对于这些工作负载,我们也相信,通过在启动时间和内存消耗方面比其他框架更高效,Micronaut可以提供很多东西。
\u0026#xD;\n
InfoQ:你们有计划在Micronaut中支持JVM语言Scala和/或Clojure吗?
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nRocher::我们在构建Micronaut时已经考虑了多种语言,实际上,我们现在已经通过为每种语言创建一个公共的AST来支持Java、Kotlin和Groovy。我们计划在某个时候通过Scala编译器插件(参见这里)添加Scala支持,不过,如果Scala社区有人希望帮助我们加速这个过程,我们很乐意听取他们的建议。Clojure很有趣,关于如何实现Clojure支持,我们当然需要Clojure社区的输入。
\u0026#xD;\n
InfoQ:既然GraalVM支持非JVM语言,是不是有一天可以使用GraalVM支持的语言构建Micronaut应用程序?
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nRocher:我想可以肯定,它将促成“挎斗模式(sidecars)”,并且更容易与其他语言一起集成到一个Micronaut应用程序中。
\u0026#xD;\n
InfoQ:您预计Micronaut正式版会在何时发布?
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nRocher:Micronaut 1.0正式版将于10月23日发布。
\u0026#xD;\n
InfoQ:Micronaut的路线图是什么样子,尤其是在正式版本发布之后?
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nRocher:Micronaut 1.0就是要建立一个稳定的基线。由于Micronaut使用AOT编译,所以预编译元数据格式需要一个稳定的1.0版本。一旦1.0发布,我们计划与更多的技术(如RabbitMQ、Kubernetes、GRPC、GraphQL等)进行集成。
\u0026#xD;\n
查看英文原文:The Road to Micronaut 1.0 - A JVM-Based Full-Stack Framework