选择Spring Boot 3.x的原因

随着微服务和云服务的流行，Java很多原有的优势已经不是那么突出了，甚至Java和Spring Boot 2.x原有的一些优势反倒成了累赘。我们之所以选择Spring Boot 3.x，是因为它提供了两大好处。

一是拥抱最新技术。随着时代的发展，Jakarta EE渐渐取代Java EE成为主流技术，Java 8的语法也已经严重落后于其他计算机编程语言。Spring Boot 3.x只支持Java 17及以上版本，而Java 17作为当前长期支持版本，容纳了许多新的语法，简化了开发，十分值得学习，毕竟Java 8臃肿的语法已经很难支撑项目的快速开发以及系统开发的不断迭代和交付了。

二是需要追上微服务和云服务的潮流。随着微服务和云服务的发展，越来越多的企业使用容器进行开发、测试和部署等工作。而容器的使用使得“Build once, Run anywhere”（一次构建，到处运行）成为现实，这使得Java最大的优势——“Write once, Run anywhere”（一次编写，到处运行）大大削弱了，因为计算机语言的平台无关性已经不是一个巨大的优势了。传统Java采用的是Java虚拟机解释字节码的运行模式，在微服务和云服务中，会造成两个难以解决的问题。

● Java虚拟机解释运行程序的速度太慢。这体现在启动、部署和运行上，采用云原生文件，程序可以是毫秒级启动项目，而采用Java虚拟机后，程序只能是秒级启动项目。Java虚拟机在云服务或者微服务中性能偏慢，而采用云原生文件后，可以获得很大的性能提升。这些问题在单体系统的时代并非大问题，但是在容器化的微服务和云服务时代则被开发者所诟病，因为这不利于容器的使用。

● 镜像太大，难以管理。传统Java项目需要使用Java虚拟机来运行，同时也依赖大量的第三方包，制作成为容器的镜像太大，不利于运维环节对镜像的管理。在我的测试中，只是制作一个简单的Spring Boot项目的镜像，文件大小居然达到了490 MB。大的镜像不仅占据的空间大，还会使镜像构建、部署的时间变长，运行也会变慢。

针对这两个问题，Spring Boot 3.x开始支持预先编译技术，这是一种可以将项目在运行前直接编译为二进制文件或者机器码文件的技术，这样编译出来的文件就是云原生文件了。操作系统可以直接运行编译出来的文件，且性能比传统Java虚拟机解释的运行方式要好很多。Spring Boot 3.x的预先编译技术主要采用的是甲骨文提供的GraalVM，使用它生成的云原生文件不仅可以在操作系统直接运行，性能也更佳，制作出来的容器镜像也比传统Java镜像小得多。虽然当前GraalVM技术还不够完善，且未得到广泛使用，但它是Java未来的重要发展方向之一。