共计 5054 个字符，预计需要花费 13 分钟才能阅读完成。
咱们非常高兴地发表，Dubbo 3.2 曾经正式公布了！这个版本带来了许多新性能和改良，这也是 Dubbo 在面对云原生化的当下的一次重要的尝试。
背景介绍
Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官网提供了 Java、Golang 等多语言 SDK 实现。应用 Dubbo 开发的微服务原生具备相互之间的近程地址发现与通信能力，利用 Dubbo 提供的丰盛服务治理个性，能够实现诸如服务发现、负载平衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩大，用户能够不便的实现流量拦挡、选址的各种定制逻辑。
01 Rest 协定反对
1.1 Why Rest？
随着挪动互联网的遍及，越来越多的应用程序须要与不同的零碎进行集成。而这些零碎可能应用不同的通信协议，这就须要应用程序可能灵便地适应各种协定。Rest 协定正是一种非常灵活的协定，它应用 HTTP 进行通信，能够与简直任何零碎进行集成。
在过来，RPC 框架通常应用二进制协定进行通信，这种协定十分高效，但不够灵便。相比之下，Rest 协定应用 HTTP 进行通信，更不便与其余系统集成，也更容易与现代化的 Web 和挪动应用程序集成。
除了灵活性，Rest 协定还具备易读性和易用性。应用 Rest 协定，开发人员能够应用通用的 HTTP 工具（例如 cURL 或 Postman）测试和调试服务，而不须要特定的工具。此外，因为 Rest 协定应用规范的 HTTP 办法（例如 GET、POST、PUT 和 DELETE），因而开发人员能够更容易地了解和应用服务。
1.2 How 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.3 What’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.1 Metrics
在 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.2 Tracing
在 Tracing 方面，咱们还基于 Micrometer 实现了申请运行时的埋点跟踪。咱们通过 Filter 拦截器原生形式来实现这一性能。咱们反对将跟踪数据导出到一些支流实现，例如 Zipkin、Skywalking、Jaeger 等。这样就能够实现全链路跟踪数据的剖析和可视化展现。
2.3 Logging
此外，对于 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.1 JDK 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.2 RPC 性能大幅晋升
在 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%！
05 如何降级到 Dubbo 3.2
5.1 Pom 降级最新的 Dubbo Maven 坐标为：
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo</artifactId>
<version>3.2.0</version>
</dependency>5.2 兼容性
对于绝大多数的用户，降级到 Dubbo 3.2.0 是齐全平滑的，仅须要批改依赖包版本即可。
- 序列化校验逻辑的加强（重要）
如前文所述，在 Dubbo 3.2.0 版本中，Dubbo 将默认开启序列化白名单的强校验，以晋升 Dubbo 的安全性，防止近程命令执行的问题。目前的机制通过包名递归机制主动信赖了局部类，但对于一些应用了泛型等可能存在扫描不全的用户，咱们建议您增加 -Ddubbo.application.serialize-check-status=WARN 配置。察看一段时间后（通过日志、QoS 命令），如果没有触发平安告警，则能够配置强校验模式。
对于自定义白名单的配置，能够参考官网的文档 / SDK 手册 / Java SDK / 高级个性和用法 / 晋升安全性 / 类查看机制 一文进行配置。
- 默认序列化的批改
Dubbo 3.2.0 版本开始默认序列化形式从 hessian2 切换为 fastjson2，对于降级到 3.2.0 的利用，Dubbo 会主动尝试采纳 fastjson2 进行序列化。请留神，无论是客户端还是服务端，只有有一端还没有降级到 3.2.0，都将降级为 hessian2 序列化，保障兼容性。
- 默认敞开推空爱护
推空爱护的目标是在注册核心呈现故障并且被动推送空地址的时候，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 社区
原文链接
本文为阿里云原创内容，未经容许不得转载。