作者:Dubbo 社区
咱们非常高兴地宣告,Dubbo 3.2 现已正式发布了!这个版别带来了许多新功用和改善,这也是 Dubbo 在面临云原生化的当下的一次重要的测验。
布景介绍
Apache Dubbo 是一款 RPC 服务开发结构,用于处理微服务架构下的服务办理与通讯问题,官方供给了 Java、Golang 等多语言 SDK 完成。运用 Dubbo 开发的微服务原生具有相互之间的长途地址发现与通讯才干, 利用 Dubbo 供给的丰厚服务办理特性,能够完成比如服务发现、负载均衡、流量调度等服务办理诉求。Dubbo 被设计为高度可扩展,用户能够便当的完成流量拦截、选址的各种定制逻辑。
01 Rest 协议支撑
1.1Why Rest?
随着移动互联网的普及,越来越多的使用程序需求与不同的体系进行集成。而这些体系或许运用不同的通讯协议,这就需求使用程序能够灵敏地适应各种协议。Rest 协议正是一种非常灵敏的协议,它运用 HTTP 进行通讯,能够与几乎任何体系进行集成。
在过去,RPC 结构通常运用二进制协议进行通讯,这种协议非常高效,但不够灵敏。相比之下,Rest 协议运用 HTTP 进行通讯,更便当与其他体系集成,也更简单与现代化的Web和移动使用程序集成。
除了灵敏性,Rest 协议还具有易读性和易用性。运用 Rest 协议,开发人员能够运用通用的 HTTP 东西(例如 cURL 或 Postman)测试和调试服务,而不需求特定的东西。此外,因为 Rest 协议运用规范的 HTTP 方法(例如 GET、POST、PUT 和 DELETE),因此开发人员能够更简单地了解和运用服务。
1.2How To?
在之前的 Dubbo 版别中,也供给了 Rest 协议的支撑,但存在以下问题:
- 仅支撑 JAX-RS 注解域,相较于采费用更高的 Spring Web 注解,复杂度更高
- 需求依靠很多外部组件,如 Resteasy、tomcat、jetty 等,才干正常作业,极大地增加了运用本钱。
因此,在 Dubbo 3.2 版别中,咱们引入了 Spring Web 注解域的支撑以及 Rest 协议的原生支撑,无需依靠任何外部组件。
最直观的区别是,假如你晋级到了 Dubbo 3.2,经过 Spring Web 发布的服务也能够直接经过 Dubbo 来发布。这一切只需求将 @Controller 注解改成 @DubboService 注解即可。
此外,关于本来运用 Spring Boot 或者 Spring Cloud 作为服务拆分的用户,也能够根据本功用滑润地迁移到 Dubbo 上来,以极低的本钱取得 Dubbo 强壮的才干。
1.3What’s next?
接下来 Dubbo 还将持续完善。除了现有的特性,咱们还将加入以下新的特性,以更好地满足需求:
- HTTP/2、HTTP/3 协议的原生支撑。这意味着,你能够愈加便当地运用 Dubbo 与其他体系进行通讯,无需担心协议的兼容性问题。
- 参阅 Spring Web 注解,Dubbo 原生供给 Web 注解的支撑,使得用户无需依靠 Spring Web 也能够取得与运用 Spring Web 相同的体会。
- 支撑现有服务零改造以 Rest 协议发布。这个特功用够让你愈加灵敏地办理你的服务,而无需对现有的服务进行任何改动。你能够经过 Rest 协议来发布你的服务,这样你的服务就能够愈加便当地被其他体系所运用了。
02 可观测体系
在微服务架构下,业务体系由越来越多的服务组成,服务之间互相调用,随之而来的问题是怎么快速地定位毛病,并及时处理。为了处理这一问题,咱们需求更多的东西和技术来确保整个体系的可靠性。其间一个处理方案是运用日志记录和剖析,以便能够更好地盯梢使用程序的运转情况,找到潜在的问题并及时处理。别的,运用可视化的监控东西能够协助咱们更好地了解整个体系的状态,然后更好地预测和处理问题。最终,咱们还能够运用主动化测试来确保每个服务的质量,以及整个体系的稳定性和可靠性,然后更好地满足客户的需求。
一套完整的可观测体系应该包含以下功用:
- Metrics 目标监控,用于收集和剖析各种目标数据,包含体系的功用、资源消耗情况等等。经过目标监控,用户能够及时了解体系的运转情况,发现异常并做出相应的处理。
- Tracing 分布式追寻,用于盯梢体系中各个服务之间的调用链路,协助用户发现和定位潜在的功用问题、瓶颈等等。经过分布式追寻,用户能够深化了解体系的运作过程,识别出或许存在的问题并进行有用的优化和调整。
- Logging 日志办理,用于记录体系中产生的各种事件和操作,包含错误日志、拜访日志、业务日志等等。经过日志办理,用户能够了解体系的运转情况、毛病信息等等,协助用户快速定位问题并进行相应的处理。
综上所述,以上三个功用不只能够协助用户快速定位毛病,提高体系的可靠性和稳定性,还能够协助用户深化了解体系的运转情况和功用情况,为用户供给全方位的监控和保障。
在 Dubbo 3.2 版别中,咱们主要就 Metrics 和 Tracing 两个方面进行了增强。
2.1Metrics
在 Metrics 方面,咱们运用 Micrometer 大幅增加了目标的埋点,包含但不限于 QPS、RT、调用总数、成功数、失利数、失利原因计算等中心服务目标。为了更好地监测服务运转状态,Dubbo 还供给了对中心组件状态的监控,例如线程池数量、服务健康状态等。此外,Dubbo 还支撑规范 Prometheus 的 Pull 和 Push 形式,并供给了若干个官方原生的 Grafana 面板,完成面向生产的 Metrics 全天候观测。
关于一切的用户,只需求晋级到 Dubbo 3.2 版别,并增加 dubbo-spring-boot-observability-starter 依靠即可取得 Metrics 才干。 在使用启动后,将在 Dubbo QoS 的 metrics 指令下露出相关的目标,本地能够经过 http://127.0.0.1:22222/metrics 获取。此外关于运用了 Spring Actuator 的用户,Dubbo 也将默许将这些数据露出出来。
2.2Tracing
在 Tracing 方面,咱们还根据 Micrometer 完成了恳求运转时的埋点盯梢。咱们经过 Filter 拦截器原生方法来完成这一功用。咱们支撑将盯梢数据导出到一些主流完成,例如 Zipkin、Skywalking、Jaeger 等。这样就能够完成全链路盯梢数据的剖析和可视化展现。
2.3Logging
此外,关于 Logging 方面,Dubbo 从 3.1 版别开端引入了错误码机制,完成了 WARN、ERROR 等级日志的全覆盖。在异常场景下,支撑快速索引官网处理文档。
03 Native Image 原生支撑
在 Native Image 方面,Dubbo 从 3.2 开端将正式根据 GraalVM 完成对 Native Image 的支撑,从 Dubbo3.0 开端,Dubbo 现已有一些 Native Image 支撑的探索,可是易用性和支撑程度都不太理想,从 3.2 版别开端,Dubbo 将会简化用户接入 Native Image 的运用方法。主要能够分为三个面:
- 编译插件装备晋级:从最初的 native-image-maven-plugin 改为 dubbo-maven-plugin +native-maven-plugin,区分了 Graalvm 官方供给的 native image 装备与 Dubbo 所需的 native image 装备,简化了用户所需求关怀的 native image 装备
- 旧版别中需求用户手动生成和补全 Dubbo 内独有的 Adaptive 代码,新版别用户将不需求关怀这些细节。
- 旧版别中 Dubbo 结构生成的 META-INF.native-image 下的装备文件会直接生成在用户的工程目录中,3.2 新版别将会被编译到 target 下,不影响用户的工程结构。除此之外,Dubbo 结构也将不再选用手动补全 native image 的方法,而且选用主动勘探和生成所需的装备文件的方法,简化了 Dubbo 开发者的体会。这也能够下降最终编译后的二进制包的巨细和提高编译速度。
除了易用性提高以外,Dubbo 将在 3.2 版别将在 native image 场景下支撑 API、注解以及 XML 装备方法,并支撑与 SpringBoot3 中的 native 兼容。
04 其他
4.1JDK 17 & Spring Boot 3 原生支撑
JDK 17 是继 JDK 11 之后现在 Java 的最新 LTS 版别,包含许多新功用和改善,例如 Sealed 类、废物收集器的改善等等。
自从 JDK 16 开端限制 Java 内部类反射以后,Dubbo 的序列化以及动态署理都受到了一定的影响。在 Dubbo 3.2 中,咱们经过 Fastjson2 以及 Javassist 的优化从底层处理了兼容性问题。现在 Dubbo 现已能够完美运转在 JDK17 之上,一切单元测试以及大多数集成测试也都在 JDK 17 平台上测试经过。
针对即将发布的 JDK 21 LTS,Dubbo 正在紧锣密鼓地进行适配。咱们将在 3.3 版别中加入对 JDK 21 和 Dubbo 协程(Project Loom)的支撑。
4.2RPC 功用大幅提高
在 3.2 版别中,咱们对 RPC 调用功用做了调优,其间优化内容如下。
- 消除了同步锁竞争以及会呈现堵塞的代码
- 减少了用同步堵塞调用方法的恳求呼应延迟
- 减少了线程切换的次数
- 优化了 I/O 功用
- 支撑在用户线程上序列化报文‘
3.2 对比 3.1 的功用提高如下:
- Triple 协议:较小报文场景 createUser、existUser、getUser 下,提高率约在 40-45%,提高后的功用与 gRPC 同场景的功用基本相等。较大报文场景 listUser 下提高了约 17%,相较于同场景下的 gRPC 还低 11%。
- Dubbo 协议:较小报文场景 createUser、getUser 下,提高率约 180%。极小报文 existUser(仅一个 boolean 值)下提高率约 24%,而较大报文 listUser 提高率最高,达到了 1000%!
怎么晋级到Dubbo3.2
5.1Pom 晋级最新的 Dubbo Maven 坐标为:
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo</artifactId>
<version>3.2.0</version>
</dependency>
5.2兼容性
关于绝大多数的用户,晋级到 Dubbo 3.2.0 是完全滑润的,仅需求修正依靠包版别即可。
1. 序列化校验逻辑的增强(重要)
如前文所述,在 Dubbo 3.2.0 版别中,Dubbo 将默许敞开序列化白名单的强校验,以提高 Dubbo 的安全性,避免长途指令履行的问题。现在的机制经过包名递归机制主动信任了部分类,但关于一些运用了泛型等或许存在扫描不全的用户,咱们建议您增加 -Ddubbo.application.serialize-check-status=WARN 装备。调查一段时间后(经过日志、QoS 指令),假如没有触发安全告警,则能够装备强校验形式。
关于自定义白名单的装备,能够参阅官网的文档 / SDK 手册 / Java SDK / 高级特性和用法 / 提高安全性 / 类查看机制 一文进行装备。
2. 默许序列化的修正
Dubbo 3.2.0 版别开端默许序列化方法从 hessian2 切换为 fastjson2,关于晋级到 3.2.0 的使用,Dubbo 会主动测验选用 fastjson2 进行序列化。请注意,无论是客户端仍是服务端,只需有一端还没有晋级到 3.2.0,都将降级为 hessian2 序列化,确保兼容性。
3. 默许封闭推空维护
推空维护的目的是在注册中心呈现毛病而且主动推送空地址的时候,Dubbo 保留最终一批 provider 信息,以确保服务可用。可是,在大多数情况下,即使注册中心呈现毛病,也不会推送空地址,只要在一些特别情况下才会呈现。假如敞开推空维护,则会对 Dubbo 的 Fallback 逻辑、心跳逻辑等形成较大的影响,给开发人员运用 Dubbo 带来困扰。
假如在生产环境中需求敞开推空维护以完成高可用性,能够将 dubbo.application.enable-empty-protection 装备为 true。可是请注意,已知敞开推空维护会导致服务端使用从仅支撑接口级服务发现的 2.6.x、2.7.x 版别晋级到 3.x 之后回滚到本来的版别时呈现异常,极端情况下或许会导致服务调用失利。
06 总结
Dubbo 3.2 是一个非常重要的版别,它带来了很多新功用和改善,使得 Dubbo 愈加强壮和易用。咱们非常感谢社区的支撑和奉献,希望大家能够赶快体会 Dubbo 3.2,享用其间带来的便当和优势。
点击此处进入 Dubbo 官网