技术硬实力，阿里巴巴为什么要开源Spring Cloud Alibaba？

Spring Cloud Alibaba是阿里巴巴开源的一款高性能的微服务RPC框架，关于Spring Cloud Alibaba的详细介绍我这里就不啰嗦了，大家可以参考官网及相关源码，我这里只是想聊的是“阿里巴巴为什么要开源Spring Cloud Alibaba”，只要追根朔源之后，我们才能真正的去理解技术的本质，你觉得我说的对吗？欢迎来拍砖。

如果面试官问你这个问题，你可以从如下几个方面来回答：

阿里巴巴微服务技术的演进路线;
微服务生态技术的演进路线；
HSF、Dubbo、Spring Cloud和Spring Cloud Alibaba之间的关系；
Spring Cloud Alibaba能够解决什么技术痛点问题。

阿里巴巴微服务技术的演进路线

为了搞清楚具体的原因，我们可以先来追溯一下阿里巴巴的微服务技术的演进路径。

（1）几乎同时诞生了早期的Dubbo和HSF框架

Dubbo 则在 2011 年开源后，迅速成为业界广受欢迎的微服务框架产品，在国内外均有着广泛应用。Dubbo 项目诞生于 2008 年，起初只在一个阿里内部的系统使用;2011 年，阿里 B2B 决定将整个项目开源，仅用了一年时间就收获了来自不同行业的大批用户;2014 年，由于内部团队调整，Dubbo 暂停更新;2017 年 9 月，Dubbo 重启开源，在 2019 年 5 月由 Apache 孵化毕业，成为第二个由阿里巴巴捐献至 Apache 毕业的项目。

HSF 在阿里巴巴使用更多，承接了内部从单体应用到微服务的架构演进，支撑了阿里历年双十一的平稳运行;自 2008 年 5 月发布第一个版本 1.1 后，经历数年迭代，HSF 从一个基础的 RPC 框架逐渐演变成为日支撑十万亿级别调用的易于扩展的微服务框架。内部场景中，用户既可以选择少量配置轻松接入微服务体系，获取高性能的稳定服务调用。也可以按照自身业务需求对 HSF 进行扩展，获取整条链路的能力增强。

对于集团内的需求而言，稳定和性能是核心，因此，当时选型了在电商这种高并发场景久经考验的 HSF 做为新一代服务框架核心。随后，HSF 推出了 2.0 的版本，并针对 HSF 之前版本的主要问题进行重构改造，降低了维护成本，进一步提高了稳定性和性能。HSF2.0 解决了通讯协议支持不透明，序列化协议支持不透明等框架扩展性问题。基于 HSF2.0 的 Java 版本，集团内也演进出了 CPP/NodeJs/PHP 等多语言的客户端。由于 HSF 还兼容了 Dubbo 的协议，原有的 Dubbo 用户可以平滑地迁移到新版本上，所以 HSF 推出后很快就在集团全面铺开，部署的 server 数量达到数十万，基本完成了阿里巴巴内部微服务框架的统一，并经历了多年双十一零点流量洪峰的验证。

也就是说在阿里巴巴内部，HSF是一统天下的，也就是说它是才阿里巴巴业务体中统一的微服务框架，那么Dubbo又是一个什么样的地位呢？可以这样和大家来说，HSF是阿里巴巴的亲儿子，而Dubbo则是干儿子。

HSF是淘系业务体主要使用的RPC框架，而Duboo则诞生于阿里巴巴的B2B事业部，也就是说前者是最核心的业务，那当然是亲儿子了，所以就会有阿里巴巴曾经想用HSF取代Dubbo的想法，才会导致Dubbo停止维护，并错过了开源领域中RPC框架技术疯长的那几年，这样才会让Spring Cloud钻了一个大空档，从而间接的助长了Spring Coud成为微服治理领域中又一个比较成熟的体系化的技术方案。

（2）诞生Pandora 与 HSF这对⻩金搭档组合

HSF 的顺利落地离不开其丰富的周边生态，服务注册中心、配置中心、限流降级、流量调度、功能开关、分布式事务、预案平台这些都是 HSF 的好伙伴，除了一起完成基本的微服务调用功能之外，也在多次的双十一中进行保驾护航。

这么多的组件，他们的 SDK 之间的升级和依赖管理是一个很难规避的问题。如果没有进行很好的管理，就可能出现两种组件之间的三方依赖互相冲突的情况。也有可能出现某些组件需要特定的版本组合才能正确使用，这些对于开发者来说，分辨起来是一个不小的成本。如果某一个版本的组件出现高危 bug，需要推动全量升级，这些开发、构建、发布的成本，更是难以预估。

为了解决这些问题，Pandora 孕育而生。Pandora 是一个轻量级的隔离容器，它用来隔离 Webapp 和中间件的依赖，也用来隔离中间件之间的依赖。Pandora 会在运行时通过类隔离的方式，将各个中间件之间的三方依赖隔离开来，有效地避免了三方依赖互相冲突的情况。同时，Pandora 还会在运行时导出中间件的类，来替换 SDK 中所引入的中间件类，这样就可以实现运行时的中间件版本和开发时的中间件版本分离。应用升级 SDK 只需升级 Pandora 容器即可，只有在大版本升级时才需要修改 BOM 和重新打包。

（3）整合HSF和Dubbo2之后，并诞生了Dubbo3

随着业务的发展，阿里集团也因为同时存在 HSF 与 Dubbo 框架而导致的不少问题。原有部⻔或公司的技术栈如何更快地融入到现有技术体系是一个绕不开的问题。

一个典型的例子就是 2019 年加入阿里巴巴的考拉。考拉之前一直使用 Dubbo 作为微服务框架，基于 Dubbo 构建了大规模的微服务应用，迁移的成本高，⻛险也大。需要集团和考拉的基础架构部⻔耗费较⻓的时间进行迁移前调研、方案设计，确保基本可行后再开始改动。从分批灰度上线，再到最终全量上线。这种换血式的改动不仅需要耗费大量人力，时间跨度也很⻓，会影响到业务的发展和稳定性。

同时由于历史原因，集团内部始终存在着一定数量的 Dubbo 用户。为了更好的服务这部分用户，HSF 框架对 Dubbo 进行了协议层和 API 层的兼容。但这种兼容仅限于互通，随着 Dubbo 开源社区的多年发展，这种基础的兼容在容灾、性能和可迭代性方面，都有着较大的劣势，同时很难对⻬ Dubbo 的服务治理体系。在稳定性方面也存在⻛险，更无法享受到集团技术发展和 Dubbo 社区演进的技术红利。

也就是说只有将HSF和Dubbo内核整合在一起，才能真正打通整个集团微服务技术栈以及开源领域的微服务技术栈，从而做到微服务生态的技术统一，这个也就是Dubbo3诞生的原因，目前Dubbo3已经趋于稳定，感兴趣的开发人员可以下载下来去体现，但是目前Spring Cloud Alibaba还不支持Dubbo3.0。

微服务生态技术的演进路线

主要包括 SDK模式、Java Agent模式和Mesh模式。

（1）SDK模式

在这个阶段的服务治理，主要依赖于各个 SDK 提供的能力。比如 HSF/Dubbo 提供了同可用区优先、标签路由能力;消息队列提供了高可用能力;数据库分库分表提供了读写分离、动态分库能力。我相信绝大部分公司的微服务治理都停留在这个阶段，业务开发过程中必须要先定义Dubbo的SDK规格，这样依赖方才能够依赖规格去做mock开发。

当然为了给业务提效率，还支持Fat SDK模式，也就是说可以将中间件的POM依赖管理起来（包括业务服务中使用的所有中间件，比如消息中间件、分库分表中间件和服务治理中间件等），在阿里内部这个项目叫做Pandora。

（2）Java Agent模式

中间件作为提供方，苦于业务方不能及时升级中间件到最新版。业务方作为使用方，苦于升级成本比较高。Java Agent 技术，能够在运行时动态修改 Java 字节码，动态的改变 Java 程序的行为，能够很好的满足这种需求。

利用Java Agent就可以将与服务治理相关的功能下沉到Agent包中，并将公共部分抽出一个独立的SDK，供调用者依赖，这样业务服务基本不用改代码。为什么不用改代码呢？主要是抽离出去的SDK是一些契约相关的功能，具体的实现都在Java Agent中，而这些都是通过字节码技术零侵入到业务服务中的，所以当需要升级服务治理框架时，只需要升级Java Agent包就行了。

当然业务服务不仅仅会用到服务治理，也会用到消息中间件等，那么将所有这些中间件都改造成Java Agent模式，那么业务服务就可以完全的从技术中释放出来，它们就可以将精力完全投入到业务需求开发中，从而能过为公司创造更多的业务价值。

（3）Mesh模式

Java Agent 通常只能解决 Java 语言构建的微服务，针对非 Java 语言构建的微服务体系，阿里也借助 Service Mesh 的方式，把服务治理能力下沉到 Sidecar，实现了和业务的解耦。通过 Sidecar 的方式，不同语言的能力无需重复开发，sidecar 的升级也可以做到透明，对业务无感。值得注意的是，无论是 SDK 的形态，还是 Agent 的形态，还是 Sidecar 的形态，对于服务治理的控制台来说，都需要统一的控制面对多种数据面进行控制。

也就是说Mesh模式为服务治理提供了一些全新的思路，它能过完全统一微服务架构中所使用的技术栈，当然开源领域的微服务技术，比如Spring Cloud Alibaba、Duboo和Spring Cloud等都在拥抱云原生和服务网格（Service Mesh）。

HSF、Dubbo、Spring Cloud和Spring Cloud Alibaba之间的关系

用一张图来概括它们之间的关系，你就应该能够发现，Spring Cloud Alibaba是它们的终极版本，但是目前Spring Cloud Alibaba还不支持Dubbo3。

Spring Cloud Alibaba能够解决什么技术痛点问题

好吧给大家聊了这么多，那么Spring Cloud Alibaba究竟能够做什么呢？如果面试官问你，你可以这样回答他。

（1）Spring Cloud Alibaba可以开发基于Restful协议的Spring Cloud应用服务；

（2）Spring Cloud Alibaba可以开发基于Dubbo协议的Dubbo应用服务；

（3）Spring Cloud Alibaba可以同时的去开发Restful协议和Dubbo协议的应用服务；

（4）中间件团队可以借助Spring Cloud Alibaba去整合自研的注册中心，因为Spring Cloud Alibaba就整合了不同的注册中心；

（5）Spring Cloud Alibaba标准化了RocketMQ的使用方式；

（6）Spring Cloud Alibaba标准化了Sentinel的使用方式；

（7）Spring Cloud Alibaba标准化了Seata的使用方式；

（8）Spring Cloud Alibaba提供了一种面向异构微服务的Sidcar模式，这样用同一套框架可以适配不同的编程语言。

好吧，今天就和大家聊到这里，关于更多Spring Cloud Alibaba的使用的细节，大家可以参考本人的技术类书籍《Spring Cloud Alibaba微服务架构实战派上下册》。

总之Spring Cloud Alibaba主要的目的是给咱们微服务架构去舔砖揭瓦的，它是为了给业务开发人员做技术成本的减法的，大家放心去用就是了，目前Spring Cloud Alibaba最新的版本为2.2.8.RELEASE，可以点击如下链接去下载最新版本的源码。

https://github.com/alibaba/spring-cloud-alibaba/releases/tag/2.2.8.RELEASE

另外我的新书RocketMQ消息中间件实战派上下册，在京东已经上架啦，目前都是5折，非常的实惠。

https://item.jd.com/14337086.html编辑https://item.jd.com/14337086.html

“RocketMQ消息中间件实战派上下册”是我既“Spring Cloud Alibaba微服务架构实战派上下册”之后，又一本历时超过1年半的巨无霸技术实战类型的书籍。

为了提高读者阅读本书的体验性，本书总共设计了十个特色，下面我一一的给技术小伙伴阐述一下。

【特色一】由浅到深

本书将RocketMQ的技术原理和最佳实践体系化，按照由浅到深的顺序呈现给读者，使读者可以按照章节顺序按部就班地学习。当学习完全书内容之后，读者不仅能熟悉RocketMQ的核心原理，还能充分理解RocketMQ的“根”。

【特色二】技术新

本书不仅包括RocketMQ4.x（4.9.2版本）的核心原理分析和最佳实践，还包括RocketMQ5.x（5.1. 0版本）的新特性分析和最佳实践。

【特色三】精心设计的主线：零基础入门，循序渐进，直至彻底掌握RocketMQ

本书精心研究了程序类、架构类知识的认知规律，全书共分为6篇：①基础；②进阶；③高级；④高并发、高可用和高性能；⑤应用；⑥新特性，是一条相对科学的主线，让读者快速从“菜鸟”向“RocketMQ分布式架构实战高手”迈进。

【特色四】绘制了大量的图，便于读者理解RocketMQ的原理、架构、流程

一图胜于文，书中在涉及原理、架构、流程的地方配有插图，以便读者更加直观地理解。

【特色五】从架构师和技术专家的视角分析RocketMQ

本书创造性地分析了RocketMQ具备高并发、高可用和高性能的功能及原理，并从架构的视角展开分析，这些也是程序员进阶为技术专家或架构师必备的技能。

以下为从架构师和技术专家的视角分析RocketMQ典型案例，读者阅读完本书之后，也能够达到这样的水准。

【特色六】不仅有原理分析，还有大量的实战案例

本书介绍了大量的实战案例，能让读者“动起来”，在实践中体会功能，而不只是一种概念上的理解。

在讲解每一个知识模块时，我在思考：在这个知识模块中，哪些是读者必须实现的“标准动作”（实例）；哪些“标准动作”是可以先完成的，以求读者能快速有一个感知；哪些“标准动作”具有一定难度，需要放到后面完成。读者在实践完书中的案例之后，就能更容易理解那些抽象的概念和原理了。

本书的目标之一是，让读者在动手中学习，而不是“看书时好像全明白了，一动手却发现什么都不会”。通过体系化的理论和实战案例去培养读者的主动学习能力，这样本书的价值就会被最大化。

本书相信“知行合一”的理念，而不是“只知，而不行”，避免开发人员出现眼高手低的现象。尤其是在技术面试过程中，面试官更加看重的是既懂原理，又能够主动是实践技术的技术人。

【特色七】深入剖析原理

本书以系统思维的方式，从业务功能视角剖析 RocketMQ 底层的技术原理，使读者具备快速阅读 RocketMQ 框架源码的能力。读者只有具备了这种能力，才能举一反三，实现更复杂的功能，应对更复杂的应用场景。

【特色八】从运维的视角分析 RocketMQ 的最佳实践

【特色九】参与开源

本书向读者展示了如何修改 RocketMQ 源码，并快速验证案例分析。这样，读者可以从中学到参与开源的技能，并为后续自己能够参与开源做准备。

【特色十】双色印刷，读者体验会更好

为了提高读者阅读本书的体验，在有上下两册的前提下（巨无霸，超过800页），出版社不吝啬印刷成本，依然采用双色印刷。

【推荐】本书的最佳学习路径

为了提高读者学习RocketMQ的效率，我这边结合我自身从RocketMQ小白到RocketMQ专家的经历，为读者汇总了一条最佳学习路径。

【寄语】作者寄语

RocketMQ是我深度参与研究的一款开源消息中间件，无论是从源码，还是架构场景，我都提炼了很多最佳实践。

在开源领域，技术小伙伴可以使用的开源消息中间件非常的多，比如Kafka、Pulsar等，我之所以选择研究RocketMQ，除了工作内容和角色需要之外，更多的还是自己感兴趣，因此我建议技术小伙伴一定要先培养自己的兴趣，兴趣才是提升技术硬实力的第1要素。

当然我并不止研究了RocketMQ，还研究了Pulsar和Kafka等（包括开源消息中间件生态中的主流框架），只是本书作为一本关于RocketMQ实战派的书籍，我必须要以RocketMQ为主。

假如技术小伙伴想成为Java领域的架构师或者技术专家，我强烈建议你去研究RocketMQ，它会给你带来很多意想不到的技术和架构方法论的收获，这个也是我写本书的主要目的之一。

建议技术小伙伴按照本书设计的学习路线，逐章的去阅读和实战，这样学习效果会更好。

如果技术小伙伴有技术交流的，可以通过博文视点官方的读者群找到我的联系方式，并与我沟通，我会实时的解答读者的疑问。

本文公众号“架构随笔录”

本人视频号“架构随笔录”

【博文视点】2021年度优秀作者

2021年我和博文视点合作了一本技术类型的书籍“Spring Cloud Alibaba微服务架构实战派上下册”，它是我涉足知识输出领域以来的第一本书，同时它也是我自己积累的技术池中部分技术的产出。

为了写好那本书，我几乎花费了所有的休息时间，并主动的承担了书的售后技术辅导和咨询的职责（几乎是有问必答，坚持了整整两年）。

所谓有付出总会有回报，Alibaba这本书的销量还不错，我也因此获得了博文视点颁发的2021年度优秀作者。

我很清楚，这个是博文视点为了鼓励我继续去用心写书，因此我又花了接近1年半的时间去写了RocketMQ消息中间件实战派上下册这本书。

所谓一分耕耘一份收获，我将我对RocketMQ的理解体系化的输出给喜欢技术的技术人，希望真的对大家有帮助。

【博文视点】2023技术成长领路人

2022年，我开始涉足技术直播和技术讲师领域，并和博文视点合作几次技术直播，直播效果还不错，再加上我孜孜不倦的布道“Spring Cloud Alibaba微服务架构实战派上下册”这本书相关的技术，并且这些技术都是有助于“技术人”快速成长的，因此也获得了博文视点颁发的“2023技术成长领路人”这个技术奖项，这个奖项也是为了鼓励我继续通过技术直播的方式给技术人去布道技术，因此只要我有时间，我就会孜孜不倦的去讲和聊技术。