不支持Dubbo了，Spring Cloud Alibaba为什么要去掉 Dubbo Spring Cloud？

学习是一件需要长期投入的事情，尤其是在当下大环境恶劣的背景下，我们程序员必须要多多的投资自己，去加强自己的技术硬实力和软实力。

Spring Cloud Alibaba在最新的2.2.8.RELEASE版本中将组件spring-cloud-starter-dubbo去掉了，并且在Master分支中直接将这个模块也去掉了，其实我也很好奇，在2.2.7.RELEASE版本中都还保留了这个组件，为什么2.2.8.RELEASE版本就去掉了？

这里结合我的理解我来给大家分析一下。

首先，这个与Spring Cloud Alibaba本身的定位没关系，Spring Cloud Alibaba就是为了融合Spring Cloud和Dubbo的，让基于这两个框架开发的业务服务能够零成本的接入Spring Cloud Alibaba，并给业务提效；

其次，Spring Cloud Alibaba自定义的组件spring-cloud-starter-dubbo是依赖的Dubbo的2.7.x系列，也就是说它重新定义的注册中心Dubbo-Cloud是依赖的Dubbo 2，但是目前Dubbo已经全面支持Dubbo3.x，很多公司都已经在尝试使用Dubbo 3，所以当业务服务想利用Spring Cloud Alibaba去整合Dubbo 3的时候，就会出现很多问题，没办法做到向下兼容，这个笔者是尝试过的。

最后，官方为了摈弃歧义，就暂时将这个组件spring-cloud-starter-dubbo去掉了，我相信后面官方找到了兼容Dubbo 3的技术解决方案，并验证通过之后，会将这个模块重新开放出来的。

Dubbo 3是阿里巴巴整合Dubbo2和HSF 2之后的产物，全面兼容Dubbo和HSF，它的诞生是有背景的。

首先，如何更好的满足企业实践诉求。Dubbo 自 2011 由阿里巴巴捐献开源以来，一直是众多大型企业微服务实践的首选开源服务框架。在此期间，企业架构经历了从 SOA 架构到微服务架构变迁，Dubbo 社区自身也在不断的更新迭代以更好的满足企业诉求。然而 Dubbo2 架构上的局限逐渐在实践中凸显：1.协议，Dubbo2 协议以性能、简洁著称，但却在云原生时代遇到越来越多的通用性、穿透性问题；2.可伸缩性，Dubbo2 在可伸缩性上依旧远超很多其他框架，但随着微服务带来更多应用与实例我们不得不思考如何应对更大规模集群的实战；3.服务治理易用性，如更丰富的流量治理、可观测性、智能负载均衡等。

其次，适配云原生技术栈的发展。微服务让业务开发演进更灵活、快捷的同时，也带来了一些它独有的特征和需求：如微服务之后组件数量越来越多，如何解决各个组件的稳定性，如何快速的水平扩容等，以 Docker、Kubernetes、Service Mesh 为代表的云原生基础设施为解决这些问题带来了一些新的选择。随着更多的微服务组件及能力正下沉到以 Kubernetes 为代表的基础设施层，传统微服务开发框架应剔除一些冗余机制，积极的适配到基础设施层以做到能力复用，微服务框架生命周期、服务治理等能力应更好地与 Kubernetes 服务编排机制融合；以 Service Mesh 为代表微服务架构给微服务开发带来的新的选择，Sidecar 给多语言、透明升级、流量管控等带来的优势，但同时也带来运维复杂性、性能损耗等弊端，因此基于服务框架的传统微服务体系还将是主流，长期仍将占据半壁江山，在长时间内将会维持混合部署将会维持混合部署状态。

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

Dubbo 3的主要特性包括如下几点：

• 通用的通信协议。 全新的 RPC 协议应摒弃私有协议栈，以更通用的 HTTP/2 协议为传输层载体，借助 HTTP 协议的标准化特性，解决流量通用性、穿透性等问题，让协议能更好的应对前后端对接、网关代理等场景；支持 Stream 通信模式，满足不同业务通信模型诉求的同时给集群带来更大的吞吐量。
• 面向百万集群实例，集群高度可伸缩。随着微服务实践的推广，微服务集群实例的规模也在不停的扩展，这得益于微服务轻量化、易于水平扩容的特性，同时也给整个集群容量带来了负担，尤其是一些中心化的服务治理组件；Dubbo3 需要解决实例规模扩展带来的种种资源瓶颈问题，实现真正的无限水平扩容。
• 更丰富的编程模型，更小的业务侵入。在开发态业务应用面向 Dubbo SDK 编程，在运行态 SDK 与业务应用运行在同一个进程，SDK 的易用性、稳定性与资源消耗将在很大程度上影响业务应用；因此 3.0 应该具备更抽象的 API、更友好的配置模式、更少的侵占业务应用资源、具备更高的可用性。
• 更易用、更丰富的服务治理能力。微服务的动态特性给治理工作带来了很高的复杂性，而 Dubbo 这方面一直做的不错，是最早的一批治理能力定义者与实践者；3.0 需面向更丰富的场景化，提供诸如可观测性、安全性、灰度发布、错误注入、外部化配置、统一的治理规则等能力。
• 全面拥抱云原生。

总之，将业务服务从Duubo 2升级到Dubbo 3需要踩很多坑，并且很难做到零侵入和零技术成本的升级，所以Spring Cloud Alibaba才会将Dubbo Spring Cloud去掉。

总结

一定做一名合格的35岁程序员，这样才能够将自己立于不败之地。