全栈JVM框架Micronaut通向1.0版本之路

Graeme Rocher: 在过去的几年里,技术领域发生了巨大的变化,特别地,如果你看看类似Docker、Kubernetes这样的系统以及无服务器运动,你会发现,它们实际上都针对低内存微服务和低开销应用程序而进行了优化。其结果是,像Go和Node这样的语言在这些平台上体现出了比Java更显著的吸引力,因为它们具有出色的冷启动性能和内存消耗。有一个非常好的问题,可以问下自己,如果Docker和Kubernetes团队有各种技术选项,为什么要选择Go而不是Java来实现这些平台?在我看来,答案很简单:如果他们用Java编写了那些技术栈,并且有了今天这些技术选项,那么我们就都需要一台超级计算机才能让笔记本电脑在本地运行它们。

原因是多种多样的。一方面是语言层面的限制。JVM是一项惊人的技术成果,但对于短时间运行的操作(如无服务器函数),它提供的优化往往就不存在了,但是,你仍然需要拖着整个JVM来运行你的应用程序。像GraalVM这样的项目有可能通过将Java应用程序编译成本地镜像来解决这些限制,但是,坦率地说,框架设计人员在提高Java应用程序的效率方面有很大的作用。

在框架层,传统的JVM框架(如Spring和Java/Jakarta EE)已经有超过10年的历史了,那时,每个人都在部署单体应用程序,它们主要是围绕着反射和注解的运行时分析来构建。这种方法的问题在于,由于各种各样的问题,从类型擦除,到有限的注解API,再到反射逻辑的相对缓慢,所以,几乎不可能构建一个Java框架,启动速度超快,而内存消耗超低。框架运行时的负担是巨大的。如果你观察一下Spring在运行时所做的工作,就会发现这有些不可思议,从用ASM解析字节代码来生成注解元数据,到积极缓存反射信息以避免不可避免的重复读取减慢速度。在缓存所有这些运行时生成的信息与实现快速启动和低内存消耗的目标之间存在着不可调和的冲突。

我们相信,Micronaut是面向未来的框架的基础,通过消除所有反射的使用,以及在编译时通过一组注解处理器和执行预编译(AOT)的AST转换,生成所有注解元数据、代理和框架基础设施,消除这种矛盾。这使得Micronaut能够实现极快的启动速度、低内存消耗,并且实现与GraalVM本地镜像兼容性的重大改进。

当然,Java生态系统有大量的项目是基于Java的,像Spring、Kafka、Cassandra、Hadoop、Grails等,它还有一个丰富的语言生态系统,包括Groovy、Scala、Kotlin、Java、Clojure等。因此,这也不全是和低内存占用的微服务与无服务器应用程序有关,有许许多多的工作负载仍然受益于JVM和JIT。然而,即使对于这些工作负载,我们也相信,通过在启动时间和内存消耗方面比其他框架更高效,Micronaut可以提供很多东西。

来源: 全栈JVM框架Micronaut通向1.0版本之路

发布者

jahentao

坚定信念,创造工具

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据