# Micronaut 概述
Micronaut 的英文名字由两部分拼接而成，“micro” 是“微小”，代表微服务，“naut”是船，代表的是载体。两部分的字面意思合并起来，可以理解为微服务的载体、微服务的运载之船。
Micronaut 官方的介绍为：Micronaut 是一个现代的，基于 JVM 的全栈框架，可用于构建模块化、易测试的微服务和无服务器应用。 Micronaut 的核心设计愿景在于解决应用的启动时间和内存占用。
目前我们使用得较多的、常见的框架设计思路是：当使用基于反射的 IoC 框架构建应用程序时，框架会加载和缓存应用程序上下文中每个 bean 的反射数据。在这个思路下，应用会随着代码量而膨胀，需要处理更多的 bean 的缓存数据，进而导致启动时间和内存占用也将增加。
而 Micronaut 能让应用程序启动时间和内存消耗不受代码量的影响，使得启动时间的有了巨大飞跃，并拥有极快吞吐量和最小的内存占用。
Micronaut 框架具有以下关键特性：
- 语言的原生框架
- 云原生
- 快速数据库访问配置
- 平滑学习曲线
- 快速易用的单元测试
- 支持面向切面编程
- 无缝集成 OpenAPI
- 运行前编译
Micronaut 作为开发语言的原生框架，支持 Java、Groovy、Kotlin 和 Scala 语言。这些开发语言本身也都是支持 JVM 的。
Micronaut 内置了云相关的支持特性，包括服务发现、分布式追踪以及云运行时。具体来说，就是支持服务发现 Consul 和链路追踪 Zipkin，以及原生支持 Oracle Cloud、AWS、Google Cloud 和 Azure。
数据库方面，Micronaut 则提供了丰富的数据库配置项，方便开发者使用自己最熟悉的数据库及 API。
在注解的设计上，Micronaut 则选择了大量标准注解，如 @Inject 、@Singleton 注解都是非常熟悉的标准注解名字，另外 Micronaut 还参考了大量常用框架的注解名字来设计注解，使得开发者在框架入门时感觉非常亲切，学习曲线比较平滑。
单元测试是 Web 应用中另开发者非常头疼的事，由于 Web 应用涉及到大量服务端会话、认证、数据库访问的逻辑，单元测试的书写一般非常麻烦。Micronaut 在设计时，就考虑实现高性能的 Web 应用框架，单元测试尽量能直接做到集成测试。因而它原生提供了一个快速易用的单元测试框架。 AOP，即面向切面编程，是现代编程语言不可或缺的一个重要特性，有了这个特性，语言的代码实现可以有更大的灵活性。像 Java 开源框架 Spring 就是支持 AOP 的，而 Micronaut 也设计支持这一特性。
不论是软件还是项目的开发，最终都离不开 API 文档的交付。目前 OpenAPI 已经成为一种事实上的 http 协议下的 API 规范，像我们用得很多的 Swagger 工具就提供了对 OpenAPI 规范定义等支持。Micronaut 在设计时即支持了 OpenAPI。
Java 程序长期以来给人的印象就是臃肿、缓慢，根因在于很多 Java 程序的动态特性依赖 JVM 的运行时解析。动态下，运行速度就一定不会快速。为了解决这个问题，Oracle 实验室提出了新一代的 Java 虚拟机 GraalVM。
GraalVM 的高性能 JIT 编译器生成优化的本机代码，由于一系列高级编译器优化和激进而复杂的内联技术，能使代码运行得更快，产生更少的垃圾，并使用更少的 CPU 资源，并且提前编译的应用程序仅需要使用 JVM 所需资源的一小部分，意味着应用更容易优化。
通过以上核心特性的实现，Micronaut 得以实现解决应用内存占用和启动时间的问题。
虽然我们也看到，Micronaut 的特性实现依赖了 GraalVM 的支持，但是框架本身的设计也是围绕相关问题解决的。而目前开源框架中，我们使用比例很高的 Spring 框架，包括 Spring Framework、Spring Boot 和 Spring Cloud，在设计时的设计目标就不同于 Micronaut，这使得在当下的微服务、云原生的环境下，Spring 框架越发不太适合。
一是 Spring 框架的应用非常容易膨胀，随意代码量的增长和依赖项的增多，编译后的制品文件会极速增大，二是 Spring 框架的设计上，需要对 IoC 框架生成的大量 bean 进行缓存，并且还有大量通过反射实现的运行时动态加载，导致应用启动缓慢，运行时也容易卡顿，三则是在第二点的基础上，引发应用占用内存资源居高不下。
以上三点，是云原生理念提出后，正好背道而驰的缺点。
云原生计算基金会，对云原生有一个共识的官方定义，如下：
“云原生技术使组织能够在新式动态环境（如公有云、私有云和混合云）中构建和运行可缩放的应用程序。 容器、服务网格、微服务、不可变基础结构和声明性 API 便是此方法的范例。
这些技术实现了可复原、可管理且可观察的松散耦合系统。 它们与强大的自动化相结合，使工程师能够在尽量减少工作量的情况下，以可预测的方式频繁地进行具有重大影响力的更改。”
这个定义表明，云原生的目的是在云的基础上实现速度与敏捷性。软件产品提供的用户业务系统，已经变得越来越复杂，用户要求也就越来越高。用户希望有更快的响应速度、实现创新的工作，甚至期望业务系统能够拥有零故障时间。 以上的期望也表明软件产品的用户再也无法接受问题：性能问题、不断复现的错误以及不能快速迁移。如果出现这些问题，用户将会替代使用竞品。
这就一步表明，云原生系统需要支持快速变更、大规模操作和复原能力。结合前文所述的 Micronaut 的关键特性，可知 Micronaut 框架确实提供了云原生的能力。而在云原生的未来里，Micronaut 一定会占有一席之地。
Micronaut 目前提供有核心的几大组件：core、security、test 和 data，另外还提供了若干扩展支持，内容非常丰富。
从 2018 年，Micronaut 发布 1.0.0.M1 版本起，截止 2023 年 9 月 13 日发布了 4.1.5 版本，Micronaut 发版频率非常高，迭代非常快。一方面说明 Micronaut 还比较年轻不够稳定，另一方面也说明它干劲十足，未来可期。
从目前 Micronaut 的规划来看，它的野心很大，期望能用扩展组件囊括尽可能多的特性。这个一方面是由于目前的很多开源框架不符合云原生的设计目标，也不能很好的支持 GraalVM 相应特性，使得 Micronaut 不得不自己造轮子，另一面是由于 Micronaut 希望组件的设计更能契合自己的设计愿景。