概述
实际上，Apache Dubbo是一款高性能的Java RPC框架。而Apache Dubbo的前身是阿里巴巴公司开源的、轻量级的开源RPC框架，在2018年阿里巴巴把这个框架捐献给了Apache基金会。
那alibaba.dubbo和apache.dubbo我们应该怎么去选择呢?
- Dubbo Github地址（两个地址都能访问）：
目前alibaba.dubbo的最新版本最终为：2.6.12
<!-- https://mvnrepository.com/artifact/com.alibaba/dubbo -->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.6.12</version>
</dependency>
从com.alibaba.dubbo的maven仓库mvnrepository上面Note提示：
This artifact was moved to: org.apache.dubbo » dubbo
apache.dubbo的最新版本为：3.2.0-beta.5
<!-- https://mvnrepository.com/artifact/org.apache.dubbo/dubbo -->
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo</artifactId>
<version>3.2.0-beta.5</version>
</dependency>
🌈对于
alibaba.dubbo还是apache.dubbo选择：如果
2.6.x及以下版本，可以使用：com.alibaba.dubbo，2.7.0开始，直接使用org.apache.dubbo如果你目前选择了低版本的com.alibaba.dubbo后面如果想升级到org.apache.dubbo，需要考虑做好平滑升升级带来的影响和麻烦，所以必要时在选型时做好版本选择!
本篇文章主要是了解回顾Dubbo的发展历程、Alibaba Dubbo的涅槃重生！
Apache开源孵化器
Apache的顶级项目往往都需要经过孵化器孵化，满足一系列质量要求之后才可毕业。2016 年 12 月 15 日，阿里巴巴曾宣布将移动开源项目Weex捐赠给Apache基金会开始孵化，目前尚未毕业。Dubbo是否能正式成为 Apache的顶级项目，还有一段路要走。社区的加入，能否让Dubbo的实用性再上一层楼。
《从2019到2020，Apache Dubbo年度回顾与总结》
Dubbo的历史渊源
说起Dubbo框架，可能很多后端开发者都有所了解，它是国内比较早的、影响较大的开源项目，包括阿里巴巴、京东、当当网、去哪儿网、网易考拉、微店等电商平台都有其成功应用案例。
Dubbo于2011年开源，之后就迅速成为了国内该类开源项目的佼佼者。可以想象，2011年时，优秀的、可在生产环境使用的RPC框架很少，Dubbo的出现迅速给人眼前一亮的感觉，而同时它又有阿里巴巴背书，所以也迅速收到了开发者的亲睐。Dubbo目前在GitHub上有超过16000个star和超过12000的fork数，绝对是国内影响力最大的开源项目之一。
但奇怪的是，在 2014 年 10 月 30 日发布 2.4.11 版本后，Dubbo突然停止更新，当时社区一片哗然（其实是在 2012 年 10 月之后就基本停止了重要升级，改为阶段性维护）。具体原因现在也不得而知，知乎上也有一些讨论，包括团队调整、内部主推HSF等。不过可以确认的是，在 4 年前，国内企业对于开源的重视程度都远远没有今天高。
而在官方停止更新Dubbo之后，当当网（Dubbox）、网易考拉（Dubbok） 都有维护自己单独的分支，这也可以从另外一个侧面证明Dubbo确实应用到了这些企业的重点业务，并且规模不小。
随着阿里巴巴对于开源的逐步重视，2017 年 9 月 7 日，Dubbo悄悄的在GitHub发布了 2.5.4 版本。随后，没过多久，又迅速发布了 2.5.5、2.5.6、2.5.7 等版本。在 10 月举行的云栖大会上，阿里宣布Dubbo被列入集团重点维护开源项目，这也就意味着Dubbo起死回生，开始重新进入快车道。
阿里巴巴重启Dubbo
而对于为什么要重新启动维护 Dubbo，以及Dubbo和HSF的关系，Dubbo未来的计划，当时聊聊架构也采访了 Dubbo负责人、阿里巴巴中间件高级技术专家罗毅，感兴趣的读者可以点击阅读原文《阿里重启维护 Dubbo 了》。
这次采访中，令我印象深刻的是罗毅提到了Dubbo的愿景，他说开源就阿里巴巴集团在技术层面赋能的重要领域，阿里巴巴中间件团队今后不仅要聆听社区的声音，及时修复问题，及时合并优秀的pull request，还会力争将 Dubbo 打造成有国际影响力的RPC框架。国际影响力，让人一下子沸腾。
满血复活：Dubbo 3.0
Dubbo 3.0
Dubbo 3.0是下一代Dubbo架构的代号。一年前，最开始探索Reactive Stream之时，社区也曾有过对 Dubbo 3.0的广泛讨论。而这一次，在云原生大背景下，3.0 代表了更全面的Dubbo架构升级，涉及到下一代RPC协议、全新的服务治理模型和云原生基础设施适配等。
阿里巴巴是参与Dubbo 3.0开发建设的主要力量之一，这款始于阿里的开源项目正重新回归阿里内部落地。
去年开始，阿里巴巴就已经在逐步推动以Dubbo替换其内部的HSF框架的工作，通过将Dubbo与HSF两个框架融为一体，并在此基础上发展出适应云原生架构的Dubbo版本。Dubbo重回阿里巴巴的落地是拥抱社区、拥抱云原生、拥抱标准化的一次很好的实践。
阿里巴巴内部Dubbo 3.0的落地，对社区也是一个重大利好，这一方面有利于阿里巴巴将其在HSF上的丰富服务治理经验回馈输出到社区，另一方面也将直接推动Dubbo云原生架构的快速演进。除了阿里巴巴之外，包括斗鱼、工商银行、爱奇艺等厂商也都在参与下一代Dubbo 3.0的建设。
阿里巴巴升级 Dubbo3 全面取代 HSF2
作为Dubbo3的主要定义者以及核心用户，阿里巴巴内部的核心业务线目前均已或正在迁移到Dubbo3版本。众所周知，阿里巴巴内部业务一直运行在自研HSF2框架之上，HSF2与Dubbo2之间有很深的渊源，两者之间在设计理念上有很多相似之处，但实际上经过多年的发展已经演进成两个完全不同的框架，在Dubbo3设计的过程中完全汲取了HSF2与Dubbo2两者的优势，尤其是HSF2在阿里内部多年超大规模集群实践的经验。
面向企业生产实践痛点
Dubbo2仍旧是国内首选开源服务框架，被广泛应用在互联网、金融保险、软件企业、传统企业等几乎所有数字化转型企业中，久经规模化生产环境检验。以 Dubbo2 的贡献者和典型用户阿里巴巴为例，阿里巴巴基于 Dubbo2 在内部维护的 HSF2 框架经历了历次双十一峰值考验，每天数十亿次的 RPC 调用，治理着超过千万的服务实例。在长期的优化和实践积累中，阿里巴巴有了对下一代服务框架的设想与方案，在内部开始了快速演进，并快速的被贡献到 Apache 社区，如同阿里巴巴一样，其他用户的实践诉求与痛点也在开源社区快速的积累，形成了一致的方向和技术方案，可以说 Dubbo3 的诞生就来自于超大基数的企业用户积累，为了更好的满足他们的实践诉求。
Dubbo3 融合了阿里巴巴 HSF2 及其他社区企业的大量服务治理经验，当前 Dubbo3 已经被全面应用到生产实践环境，用户包括阿里巴巴电商、饿了么、钉钉、考拉、阿里云、小米、工商银行、风火递、平安健康等。社区与用户的合作形成的良性循环极大的促进了 Dubbo3 的发展，阿里巴巴已经以社区版 Dubbo3 完全取代了内部维护的 HSF2 框架，他们的实践经验一方面推动 Dubbo3 的稳定性，另一方面正够源源不断的将服务治理实践经验输出到开源社区。
面向百万集群实例，横向可扩容
随着微服务实践经验的积累，微服务被拆分成更细粒度，部署到越来越多的机器实例，以支撑不断增长的业务规模。在众多的 Dubbo2 企业用户中，尤其是以金融保险、互联网为代表的规模化企业开始遇到集群容量瓶颈问题（典型的请参照 工商银行实践案例 ）：
-
服务发现过程
- 注册中心数据存储规模达到容量瓶颈
- 数据注册&推送效率严重下降
-
Dubbo 进程
- 侵占更多机器资源，导致业务资源利用率降低
- 频繁 GC 影响业务稳定性
Dubbo3 在设计上很好的解决了这些问题，通过全新设计实现的服务治理（服务发现）模型，可以实现服务发现链路上的数据传输、数据存储量平均下降 90% 左右；同时 Dubbo3 自身在业务进程中变得更轻量、更稳定，实现提升资源利用率 50%。
Dubbo3 一个更大的优势在于其对整体架构稳定性的提升，新的服务发现架构使得对于整个集群容量、可伸缩性评估变得更容易、更准确。
如果将应用开发粗略划分为业务开发、运维部署两个层次，其中变化比较频繁的因素包括服务（接口）、应用、机器实例。在 2.x 时代，所有这三个因素的增长都会影响微服务集群的总体容量，尤其是接口增减带来的波动，对整体容量评估是非常不透明的。而在 3.0 中集群容量变化仅与应用名、机器实例两个因素相关，而容量评估的对象往往都是应用与实例，因此整个集群变的更稳定透明。
云原生
在云原生时代，底层基础设施的变革正深刻影响应用的部署、运维甚至开发过程，往上也影响了 Dubbo3 微服务技术方案的选型与部署模式。
下一代 RPC 协议
新一代的 Triple 协议基于 HTTP/2 作为传输层，具备更好的网关、代理穿透性，原生支持 Stream 通信语义，兼容 gRPC 协议。
多语言友好
Dubbo3 从服务定义、RPC协议、序列化、服务治理等多个方面都已经将多语言友好性作为重点考量因素，目前提供了 Java、Golang 稳定的多语言版本，更多语言版本的 3.0 实现如 Rust、Javascript、C/C++、C# 等在开发建设中。
Kubernetes
Dubbo3 开发的应用可以原生部署到 Kubernetes 平台，Dubbo3 在地址、生命周期等已设计可与 Kubernetes 等容器调度平台对齐；对于要进一步复用 Kubernetes 底层基础设施能力的用户来说，Dubbo3 也已对接到了原生的 Kubernetes Service 体系。
Service Mesh
Service Mesh 强调控制面在微服务治理中的作用，在一定程度上推动了控制面通信协议、职责范围的扩展与标准化；传统 Mesh 架构下的 Sidecar 模型强调旁路代理对于流量的统一管控，以实现透明升级、多语言无感、无业务侵入等特性。
Dubbo3 提供了基于自身思考的 Dubbo Mesh 解决方案，强调了控制面对微服务集群的统一管控，而在部署架构上，同时支持 sidecar 与无 sidecar 的 proxyless 部署架构，使用 Dubbo Mesh 的用户基于自身的业务特点将有更多的部署架构选择。
异构体系互通
我们正看到越来越多的异构微服务体系互通的诉求，典型如 Dubbo、Spring Cloud、gRPC 等。有些是因为技术栈迁移，有些是组织合并后需要实现业务互调，Dubbo3 借助于新的服务发现模型以及可灵活扩展的RPC协议，可以成为 Dubbo3 未来的发展目标。
