迁移到Dubbo3

一、 平滑升级到Dubbo3版本

1. 升级到Dubbo3的收益

Dubbo3依旧保持了2.x的经典架构，以解决微服务进程间通信为主要职责，通过丰富的服务治理（如地址发现、流量管理等）能力来更好的管控微服务集群；Dubbo3对原有框架的升级是全面的，体现在核心Dubbo特性的几乎每个环节，通过升级实现了稳定性、性能、伸缩性、易用性的全面提升。

• 通用的通信协议。全新的RPC协议应摒弃私有协议栈，以更通用的HTTP/2协议为传输层载体，借助HTTP协议的标准化特性，解决流量通用性、穿透性等问题，让协议能更好的应对前后端对接、网关代理等场景；支持Stream通信模式，满足不同业务通信模型诉求的同时给集群带来更大的吞吐量。

• 面向百万集群实例，集群高度可伸缩。随着微服务实践的推广，微服务集群实例的规模也在不停的扩展，这得益于微服务轻量化、易于水平扩容的特性，同时也给整个集群容量带来了负担，尤其是一些中心化的服务治理组件；Dubbo3需要解决实例规模扩展带来的种种资源瓶颈问题，实现真正的无限水平扩容。

• 全面拥抱云原生。

2. 升级前的兼容性检查

在跨版本升级的过程中，存在的风险点从大到小分别有：直接修改Dubbo源码->基于Dubbo SPI扩展点进行扩展->基于API或者Spring的使用方式。

1) 直接修改Dubbo源码

对于直接修改Dubbo源码这部分的需要修改方自行判断是否在高版本中正常工作，对于这种非标准行为，Dubbo无法保证其先前的兼容性。此外，通过javagent或者asm等通过运行时对Dubbo的修改也在此范围内。此类修改大部分可以通过后文提供的扫描工具检测出来。

2) SPI扩展

a) 不兼容项

对于SPI扩展的，除了应用级服务方向和EventDispatcher两个机制在3.x中做了破坏性的修改，在2.7.x中提供的绝大多数的扩展在3.x中也都提供。此部分需要关注的有两个方面：

• 事件总线：出于事件管理的复杂度原因，EventDispatcher和EventListener在Dubbo 3.x的支持已经删除。如果有对应扩展机制的使用请考虑重构为对应Dubbo功能的扩展。

• 应用级服务发现：Dubbo 2.7中的应用级服务发现的整体机制在Dubbo 3.x中已经被完整重构，功能的性能与稳定性有了很大程度上的提高。因此我们建议您不要使用Dubbo 2.7中的应用级服务发现机制，如果有对应的扩展可以在升级到Dubbo 3.x之后基于新的代码重新验证实现（绝大多数应用级服务发现的API是向前兼容的）。

b) 优化项（可选）

此外，Dubbo 3.x中对部分扩展点的工作机制进行了优化，可以较大程度上提升应用的性能。

• 拦截器机制

Dubbo中可以基于Filter拦截器对请求进行拦截处理。在Dubbo 2.7中支持在路由选址后再对请求进行拦截处理。Dubbo 3.x中抽象了全新的ClusterFilter机制，可以在很大程度上降低内存的占用，对与超大规模集群有较大的收益。

如果您有一些Consumer侧的拦截器是基于Filter机制实现的，如果没有和远端的IP地址强绑定的逻辑，我们建议您将对应的org.apache.dubbo.rpc.Filter SPI扩展点迁移到org.apache.dubbo.rpc.cluster.filter.ClusterFilter这个新的SPI扩展点。两个接口的方法定义是完全一样的。

• Router->StateRouter

Dubbo中提供了Router这个可以动态进行选址路由的能力，同时绝大多数的服务治理能力也都是基于这个Router扩展点实现的。在Dubbo 3.x中，Dubbo在Router的基础上抽象了全新的StateRouter机制，可以在选址性能以及内存占用上有大幅优化。关于StateRouter的更多介绍我们会在后续的文档中发布。

3) API/Spring使用

对于基于API或者Spring的使用，Dubbo 3.x和2.7.x的使用方式是对齐的，在Dubbo 3.x中对部分无效的配置进行了强校验，这部分异常会在启动过程中直接报错，请按照提示修改即可。

总体上来说，在地址注册与发现环节，3.x是完全兼容2.x版本的，这意味着，用户可以选择将集群内任意数量的应用或机器升级到3.x，同时在这个过程中保持与2.x版本的互操作性。

如关心迁移背后工作原理，请参考迁移规则详情与工作原理。

《Apache Dubbo微服务开发从入门到精通》——迁移到 Dubbo3—— 一、 平滑升级到Dubbo3版本（下）：https://developer.aliyun.com/article/1223615