Spring Boot 3.0.0正式发布，Banner不再支持图片&增强可观测性

,2014年发布Spring Boot 1.0； 2018年发布Spring Boot 2.0； 2022年发布Spring Boot 3.0； 这节奏，是要跟世界杯/奥运会的频率杠上呀？,Spring Boot 3.0.0是是首个支持Spring Framework 6以及支持GraalVM的版本。官方对各个版本支持时间表：,如果把2014年发布1.0版比作Spring团队的再次创业，发布后火爆程度可谓风靡全球。到2018年发布2.0版本，已经完全没有对手了。今年刚发布的3.0版本直接上Java 17以及Jakarta EE 9起步，可谓站稳脚跟后的引领风骚。,老规矩，将我们关心的功能爽一遍。,Spring Boot 3.0.0对外部依赖有最低版本要求：,据说，Spring Boot内部有专门一个“团队”来做应用的可观性，本次的借助Micrometer的升级，使得可观测这件事在Spring Framework 6和Spring Boot 3.0.0内部都变得更加简单、易用！通过可观测性，能更好的了解系统内部的运行状态，做到胸有成竹。,Micrometer 1.10中引入的新的Observation API，它使得一个API就能搞定：metrics、tracing、logging指标观测，并且还能传递上下文、传播元数据等等，对使用者非常友好。,笔者窥探了一下Spring Boot针对Micrometer源代码级别的变化，觉得值得用专题来做较为完整的表述，结合自己的一些使用经验，尽量去说清楚在项目中如何使用它来方便的观测你的Application。,一句话：配置性更灵活、和Spring环境整合得更好了。,声明：这项特性更改和Spring Boot无关，属于Spring Framework 6的变更。,包含Spring MVC和WebFlux在内的URL 尾部斜杠 匹配方式，本次有调整：可参见PathMatchConfigurer类。,,为了下掉trailingSlashMatch这个属性，从Spring Framework 6开始将默认值由之前的true改为了fasle。虽然仅仅只是改了一个默认值，但这个变动其实还蛮大的，影响到了URL的匹配。,譬如，@GetMapping("/api/demo")之前版本即可匹配/api/demo亦可匹配上/api/demo/，自Spring Boot 3.0.0（其实是Spring Framework 6）版本后就不行了，只能匹配上前者，后者404。Spring Framework目前将此属性只标记为了@Deprecated(since = "6.0")过期，并未删除。因此若你从老项目里升级过来，那么请务必做好兼容，方式有两种：,在Spring Boot 2.7版本，引入了全新的INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件作为自动配置的文件，但那会依旧保留着对spring.factories的支持。,到了Spring Boot 3.0.0版本，删除掉了spring.factories作为自动配置文件的支持。这个差异在AutoConfigurationImportSelector文件里体现出来：,,值得注意的是：只是删除了spring.factories作为自动配置文件的支持，而不是不再支持这种SPI语法了。毕竟像什么EnvironmentPostProcessor、AutoConfigurationImportFilter、FailureAnalyzer等加载实现类的方式用spring.factories还是非常方便的。,从源代码的角度看，改注解已经不能再被标注在类上了（编译不通过）：,,至于Spring Boot为何这么做？下面继续说完就懂了。,现在，当使用@ConfigurationProperties注解进行属性绑定时，如果类只有1个构造器，则可以省略注解@ConstructorBinding，不需要标注在构造器上。,这样一句话描述体感还是不强，还是来个demo跑一跑。标注有@ConfigurationProperties注解的属性类（一般有称作属性类，不叫配置类），如下：,配置文件里写好属性的k-v：,通过@ConfigurationPropertiesScan将@ConfigurationProperties属性文件加载进容器：,文件结构如下：,,以上示例代码，在Spring Boot 2.7.x里运行结果为：报错,,在Spring Boot 3.0.0版本运行结果为：正常,,见识到了Spring Boot 3.0.0升级的威力。,令我，对于有多个构造器的case，笔者这里就不试了，建议有兴趣者自行动手跑跑Demo，加强理解比看文章100遍都强。,先说一个数据：据笔者所见所闻，至少**95%**程序员使用@ConfigurationProperties的姿势是错的，并且不知道怎么做才是对的。,关于这个话题，在笔者之前有篇文章之前花大篇幅聊过，这里可再简单提一提，避免你在使用时候还出现些七七八八的问题。,比如上例中，如果我这么使用：如下截图，如果笔者没猜错的话，这大概率是你的使用方式吧。,,从IDEA飘红提示来看，这种用法就不对嘛。再次运行容器：,在Spring Boot 2.7.x里运行结果为：报错,,在Spring Boot 3.0.0版本运行结果为：报错,,我在网上看到一篇写Spring Boot 3.0.0新特性的文章说到：改进的@ConstructorBinding检测能力这项新特性部分支持，不建议使用！嗨，这个误导性就比较强了。,说白了不是Spring Boot 3.0.0部分支持，而是使用者对属性类Bean的使用姿势不对：这从Spring Boot 3.0.0的报错提示能看出端倪，明显比2.7.x版本的报错指向性更好，明确告诉了你原因依旧修复方式。,值得一提的是，如果编码时这么使用，连IntelliJ IDEA都不同意：非常明显的指出了问题所在：,,在属性类Bean上标注@Configuration注解（或者@Component及其所有派生注解），是大多数程序员的错误使用方式。因为这里其实犯了几大错误：,倘若走捷径只需程序Run起来即可，那么这种问题积累多了，必将反噬。,如何发现最佳实践？对于Spring内部的组件，参考Spring Boot内置实现即可，它自己的东西自己的使用姿势就是绝对的权威。当然本质还是对实现原理的理解（但理解曲线比较长），有兴趣的可以看笔者之前的文章哈。,在KafkaProperties.Listener属性配置类里，新增了asyncAcks属性：,,注意：此属性只在当KafkaProperties.Listener.ackMode = MANUAL/MANUAL_IMMEDIATE的时候才生效。,,异步ack可对应Kafka中间件的同步(sync)、异步(async)、oneway三种发送方式理解。,我们的Spring Boot应用入口是main方法，而@SpringBootTest测试时它并没有执行我main方法，而是自己启的容器。这对于有些在main方法还写了些代码逻辑（比如设置个系统属性啥的）的时候就比较难受了。,这次在@SpringBootTest注解上新增了一个属性：,,它的含义为：,,下面我们来体验一把：在main函数上输出一行日志,,测试类：,,运行测试类，日志为：,,可以看到完完整整的执行了main方法（启动了应用），因此只要main方法能够执行到的代码、扫到的配置、加载到的Bean，都会被放入到测试上下文里。,2.7.x版本：启动日志包含主机名。,,3.0.0版本：启动日志不再包含主机名。,,代码差异体现在：,,为何要干掉这段逻辑呢？看下这段代码的实现就知道了，还是比较耗时的：,,这段逻辑干掉后，Spring Boot应用的启动速度应该会有比较明显的提升，收获比较大。,Java 17中，SecurityManager遭到弃用。同理，最低要求Java 17的Spring Boot 3.0.0也无理由再使用它了。,以Spring Boot的TomcatEmbeddedWebappClassLoader类举例：上下对比可看出区别。,先看看代码差异（上为2.7.x版本，下为3.0.0版本）：可以看到，Spring Boot 3.0.0直接干掉了ImageBanner这个实现类。因此现在类路径下的banner.gif、banner.jpg、banner.png等图片文件都将被忽略，反馈归真，只支持文本类Banner了！,从Spring Boot 2.7开始，web端点默认只暴露health，这次JMX也来跟着保持一致了。,如若需要显示控制其它端点，你可通过management.endpoints.jmx.exposure.include和management.endpoints.jmx.exposure.exclude属性来自定义控制。,在直线版本中，端点返回的序列化方式和MVC接口的并不一致，因此可能出现一些怪异现象。现在好了：所有端点的返回值序列化，统一使用ObjectMapper来完成。,这个标准是通过：统一实现OperationResponseBody接口实现的。,,值得注意的事：若你有自定义的endpoint，那么也可通过实现OperationResponseBody接口，来保持和内置端点序列化的一致性。,由于spring.data这个前缀保留给了Spring Data项目，因此之前Spring Boot上的有些配置需要做修改。,,,新增管理的组件：,基本上都是大版本号升级，毕竟命名空间从javax.* -> jakarta.*这一步影响还是蛮大的。,Spring Boot管理上的为基于Jakarta EE 10（基线是Jakarta EE 9）,自从用上Spring Boot，程序员基本很少再需要关心三方依赖的版本号了，交给Spring Boot既省心又放心。,Spring Boot已然成为Java开发的基石，本次大版本升级，并且还是明确的阻断式的，因此可以看到大多建议都是清一色：正确的废话，所以笔者也来几句废话建议：,技术向前的大船，浩浩荡荡不可逆。作为技术人，我们能做的是keep moving，不管是技术架构师还是业务架构师，还是开发工程师！