Dubbo 正式支持 Spring 6 & Spring Boot 3-阿里云开发者社区

Dubbo 正式支持 Spring 6 & Spring Boot 3

2023-01-13 344

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云原生网关 MSE Higress，422元/月

注册配置 MSE Nacos/ZooKeeper，118元/月

服务治理 MSE Sentinel/OpenSergo，Agent数量不受限

简介： Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java、Golang 等多语言 SDK 实现。

作者：Dubbo 社区

Dubbo 简介

Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java、Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力，利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑。

背景

Spring Framework 6.0 于 11 月 16 日正式发布 GA 版本，Spring Boot 3.0 也于11月25日正式发布 GA 版本，并且 Spring 6 & SpringBoot 3 最低支持 JDK17，意味着如果升级使用 Spring 6 & Spring Boot 3 时就必须需要升级使用 JDK17。

然而Java 8 目前是国内主流生产环境 Java 版本之一。虽然近几年陆续发布了 Java 11、Java 17 官方 LTS 版本，但是大部分开发者依然本着 “你发任你发，我用 Java8” 的看法看待JDK的升级。不过 Java 17 版本在性能上确实做了大量的优化特别是 ZGC 的发布，促进了国内不少企业升级到 Java 17。

而 Spring 框架在 Java 生态中的重要程度不言而喻，我们相信在 Spring 这波“最低支持 JDK17” 推动下，Spring Framework 6.0 & Spring Boot 3.0 一定会在不久的将来被大家接受，并成为主流技术栈。

Dubbo 社区非常重视 Spring 社区的更新迭代，总会积极支持适配，这点在最近 Spring 6.0 和 Spring Boot 3.0 发布中同样得到了验证。Dubbo 社区早在 Spring 6.0.0-RC4 和 Spring Boot 3.0.0-RC2 时已经做好了大致的兼容适配，但是为了保证 Dubbo 能够完全适配 Spring 6 和 Spring Boot 3.0 的正式版，我们一直等到 Spring Boot 3.0 GA 后，才选择宣布这个令人高兴的事情。

为什么要升级到 Spring 6.0 & Spring Boot 3.0

首先是，升级到 Spring 6.0 & Spring Boot 3.0 将获得未来很长年限的由官方提供的免费技术支撑。Spring 6 和 Spring Boot 3 是 Spring 下一代技术框架基石，尽管官方当前同时维护了 Spring 5.3 和 Spring Boot 2.6.x 和 Spring Boot 2.7.x，但它们最终都会在 2025 年和 2026 年结束其 OSS support（Open Source Software Support）。

其次是，您将在新一代框架中获得大量新特新，这些新特性都可以在 Spring Boot 3.0 Release Notes^[^1]和 What's New in Spring Framework 6.x^[2^] 中获得。

最后是，Spring 6.x 和 Spring Boot 3.x 将会最广泛的支持 JDK 17-29，需要额外说明的是 JDK17 作为当前最新的 LTS 版本，它提供了一组累积的最新语言、API 和 JVM 增强功能，使其成为更具吸引力的编译版本的升级，这也是为什么最低支持 JDK17 的原因。

Dubbo 支持 Spring 6 & Spring Boot 3

现在很高兴向大家宣布，Dubbo 已经开始兼容 Spring 6 & Spring Boot 3，所以当前 Dubbo 3.2.0-beta.3 版本可以同时兼容支持 Spring Boot 1.x、2.x、3.x。您现在可以使用 dubbo-3.2.0-beta.3 版本体验其兼容性。

<dependency>
  <groupId>org.apache.dubbo</groupId>
  <artifactId>dubbo-spring-boot-starter</artifactId>
  <version>3.2.0-beta.3</version>
</dependency>

更多关于 Spring Boot 3.0 集成 Dubbo 使用示例可参见 apache/dubbo-sample：

https://github.com/apache/dubbo-samples/tree/master/1-basic

升级总结

我们根据 Dubbo 兼容适配 Spring 6 & Spring Boot 3 过程中总结的经验整理如下，其他组件维护者也可以参考以下经验进行适配或者升级，更早适配升级到最新版本：

Jakarta EE

Jakarta EE 9 将所有API包名从 javax.* 命名空间变更到了 jakarta.*。而造成这一变化的原因是 Oracle 拒绝交出相关权益，详情可以查看：

https://www.oschina.net/news/106465/oracle-killed-java-ee

因为 Jakarta EE 的迁移，对于 Web Apps，确保升级使用 Tomcat 10, Jetty 11, or Undertow 2.2.19。

以下列出了一系列工具可以帮助你完成这部分的迁移：

OpenRewrite recipes^[3^].
The Spring Boot Migrator project^[4^].
Migration support in IntelliJ IDEA^[5^].

移除 META-INF/spring.factories 文件对 Auto-configuration 的支持

Spring Boot 3.0 移除了 META-INF/spring.factories 文件对 Auto-configuration 的支持，为了兼容性，SpringBoot 2.7.x 是最后一个支持的版本。

适配支持按照下面两个步骤即可完成

Step1：[可选] 使用 @AutoConfiguration 注解代替 @Configuration(proxyBeanMethods = false)

@AutoConfiguration 注解是 SpringBoot 2.7 中的新引入的注解，旨在专门标识 Auto-configuraton class name。

依然使用 @Configuration 注解标识自动适配类也是可以的，Dubbo 正是基于这个便利点完美支持了 Spring Boot 1.x、2.x、3.x 所有版本。

Step2：使用 AutoConfiguration.imports 文件代替 META-INF/spring.factories 文件

Spring Boot 2.7 是最后一个依然兼容使用 spring.factories 的版本，SpringBoot 3 以后不再兼容，此时您应该使用 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件替换。

在该文件列举你所有的 configuration classes，每行一个 class name，例如：

com.mycorp.libx.autoconfigure.LibXAutoConfiguration
com.mycorp.libx.autoconfigure.LibXWebAutoConfiguration

为了对齐 ISO-8601，使用 yyyy-MM-dd'T'HH:mm:ss.SSSXXX 作为默认日志日期格式

原来默认日志日期格式：yyyy-MM-dd HH:mm:ss.SSS
当前默认日志日期格式：yyyy-MM-dd'T'HH:mm:ss.SSSXXX

原来的默认日志日期格式不具有 timezone / offset 信息。

yyyy-MM-dd'T'HH:mm:ss.SSSXXX >>> e.g.: 2014-12-03T10:06:04.646+08:00

移除 YamlJsonParser

Spring Boot 官方测试发现 YamlJsonParser 并不能很好的解析 JSON，Spring Boot 3 决定不再支持使用它来作为解析 JSON 的备选。

YamlJsonParser 封装的是 snakeyaml。

Spring Boot 3 解析 JSON 的解析器使用优先级如下：

1）JacksonJsonParser
2）GsonJsonParser
3）BasicJsonParser

移除 spring.session.store-type 配置键

移除了 spring.session.store-type 配置项，当存在多个可用存储库，将会按照 Redis，JDBC，Hazelcast，Mongo 顺序使用。

更新 Spring data 配置键使其清楚地反应该配置键是否依赖 Spring Data

如果存储库（redis、mongo 等）相关的配置键不依赖 Spring Data 存在，则只需要 spring 前缀，否则需要使用 spring.data 前缀。

举例说明：

spring.redis.host >> spring.data.redis.host
spring.redis.port >> spring.data.redis.port
spring.data.cassandra.port >> spring.cassandra.port

重构 HttpMethod 枚举为类

根据最新的 rfc2616^[6^]，HTTP Method 已经属于不可枚举属性，所以重构 HttpMethod enum 类为 class 类。

除了我们熟知的 GET, HEAD, PUT, POST 等方法，现在还存在了可扩展方法，当前可扩展方法包含了 LOCK, COPY, 和 MOVE。这些扩展方法定义在 WebDAV。

不允许 URI 尾部斜杠匹配

Spring 6 之前，访问 “/resources” 和 “/resources/” 都可以进入 resources() 方法。

@GetMapping("/resources")
String resources() {
    return "Hello from /resources";
}

Spring 6 之后，您只能通过看到的 path “/resources” 进入 mapping 方法。

如果您依然想让“/resources/” 和 “/resources” 进入相同的 mapping 方法，可以通过其他手段，诸如“反向代理”、“Servlet/Web 过滤器”或“在控制器配置显式重定向”。

提供基于 @HttpExchange 服务接口的 HTTP 客户端

Spring 6 介绍了 @HttpExchange 注解，基于 @HttpExchange 注解可以简化 HTTP 远程调用。

增强 Spring SPI 加载器 SpringFactoriesLoader 允许加载多自定义文件

Spring 6 之前，SpringFactoriesLoader 只允许加载"META-INF/spring.factories"文件内容。

Spring 6 之后，SpringFactoriesLoader 可以加载自定义文件或文件名文件，并且可以通过链式编程加载多个文件。

早期兼容 JDK19 预览版的虚拟线程（virtual threads）

可以在 Spring 6 和 Spring Boot 3 中使用虚拟线程处理请求来提前体验。

这部分详细说明参见：

https://spring.io/blog/2022/10/11/embracing-virtual-threads

支持 RFC 7807 Problem Details

Spring 6 以后，Spring MVC 可以使用 application/problem+json media 类型自定义错误信息响应体，像下面这样：

{
  "type": "https://example.org/problems/unknown-project",
  "title": "Unknown project",
  "status": 404,
  "detail": "No project found for id 'spring-unknown'",
  "instance": "/projects/spring-unknown"
}

展望

在云原生时代，Java 的跨平台特性，已经不算是其亮眼特性了，而其 Jar 包体积大、启动慢、占用内存多、需要另装 JVM 是 Java 应用的痛点问题。

而通过使用 GraalVM 可以很好的解决这些问题。并且通过 GraalVM 的 AOT（Ahead-Of-Time）可以将应用编译成单独可执行文件并直接运行。

未来 Dubbo 将会积极地在 Native 方面做一些工作以此能够使应用程序达到下面的目标：

支持 Spring & Spring Boot native-image
较小的本地应用程序和容器镜像占用空间
快速启动，快速启动（几十毫秒）
低内存消耗，减少 RSS（驻留集大小），低内存有助于优化需要多个容器的微服务架构部署中的容器密度
快速的第一请求响应，避免 Hotspot 的预热问题