阿里巴巴微服务治理框架的终极PK！-编程知识

另外我的新书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技术成长领路人”这个技术奖项，这个奖项也是为了鼓励我继续通过技术直播的方式给技术人去布道技术，因此只要我有时间，我就会孜孜不倦的去讲和聊技术。

【四维口袋】2022 KVP最具价值技术专家

2022年，我开始涉足企业培训和相关技术直播，并和“四维口袋”合作了几次技术直播，并荣获了2022 KVP最具价值技术专家的技术奖项。

如果将阿里巴巴作为中国互联网公司微服务架构的继往开来者，我估计技术小伙伴应该没有人不服吧。确实是这个样子的，当Dubbo当年开放出来之后，估计很多公司就成为了Dubbo的忠实用户，但是阿里巴巴开源的微服务治理框架并不是只有Dubbo，还包括Spring Cloud Alibaba和SofaStack。

Spring Cloud Alibaba

Spring Cloud Alibaba是阿里巴巴开源的微服务框架，但是准确的来说是阿里和开源社区合作共赢的产物。

Spring Cloud Alibaba立项的初衷是为了整合Dubbo和Spring Cloud，也就是为了方便开发人员去开发基于Spring Cloud和Dubbo的应用服务，准确来说是为了给开发员人提效。

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模式，这样用同一套框架可以适配不同的编程语言。

Dubbo

Dubbo是阿里巴巴的老大哥，也是最成功的微服务框架，没有之一，毕竟在互联网上Dubbo的忠实用户太多了，很多公司自研的微服务框架其实都是基于Dubbo去改造的。

主要包括如下组件：

（1）Dubbo，Apache Dubbo是一款高性能Java RPC框架，github地址为https://github.com/apache/dubbo，关于Dubbo的介绍大家可以参考官网https://dubbo.apache.org/en/overview。

（2）dubbo-admin，dubbo-admin是Dubbo提供给开发者的一个管理Dubbo服务的控制台，目前支持Dubbo3.x和Dubbo2.7.x, Dubbo2.6.x 以及 Dubbo2.5.x，github地址为https://github.com/apache/dubbo-admin。

（3）dubbo-spring-boot-project，dubbo-spring-boot-project是Dubbo Spring Boot化的一个项目，开发者可以利用该工程快速的将基于Spring Boot的应用接入到Dubbo应用生态中，github地址为https://github.com/apache/dubbo-spring-boot-project。

（4）dubbo-samples，dubbo-samples是Dubbo官方提供的Dubbo最佳实践的实例代码工作，github地址为https://github.com/apache/dubbo-samples。

（5）dubbo-go，dubbo-go是Dubbo官方提供的基于Go语言的SDK，也就是Go开发者也可以将Go应用服务接入到Dubbo生态中，github地址为https://github.com/apache/dubbo-go。

（6）dubbo-php-framework，dubbo-php-framework是Dubbo官方提供的PHP语言的SDK，github地址为https://github.com/apache/dubbo-php-framework。

（7）dubbo-rust，dubbo-rust是Dubbo官方提供的Rust语言的SDK，github地址为https://github.com/apache/dubbo-rust。

（8）dubbo-initializer，dubbo-initializer是Dubbo官方提供的脚手架工程，开发者可以利用该框架快速的搭建基于Dubbo生态的应用服务，几乎是零成本。github地址为https://github.com/apache/dubbo-initializer。

（9）dubbo-kubernetes，dubbo-kubernetes是Dubbo官方提供的支持kubernetes的解决方案，也就是说基于Dubbo的应用服务，开发者可以一键的部署到任何基于kubernetes的运维系统中，非常的方便，github地址为https://github.com/apache/dubbo-kubernetes。

（10）dubbo-js，dubbo-js是Dubbo官方提供的 Node.js, Javascript语言的SDK，github地址为https://github.com/apache/dubbo-js。

（11）Dubbo Proxy，Dubbo Proxy是一个Dubbo网关，可以将Http请求转换成Dubbo的协议，调用Dubbo服务并且返回结果，后续还会集成熔断，限流，api管理等功能。github地址为https://github.com/apache/dubbo-proxy。

（12）dubbo-erlang，dubbo-erlang是Dubbo官方提供的erlang语言的SDK，github地址为https://github.com/apache/dubbo-erlang。

（13）dubbo-python，dubbo-python是Dubbo官方提供的python语言的SDK，github地址为https://github.com/apache/dubbo-python。

SofaStack

SOFAStack（Scalable Open Financial Architecture Stack）是一套用于快速构建金融级云原生架构的中间件，也是在金融场景里锤炼出来的最佳实践。

SOFAStack 包含了构建微服务体系的众多组件，包括研发框架、RPC 框架，服务注册中心，分布式链路追踪，Metrics监控度量、分布式事务框架、服务治理平台等，结合社区优秀的开源产品，可以快速搭建一套完善的微服务体系。

主要包括如下几个组件：

（1）SOFABoot，SOFABoot 基于 Spring Boot 的研发框架，在其基础上提供了诸如 Readiness Check，类隔离，日志空间隔离，Bean 异步初始化等能力。github地址为https://github.com/sofastack/sofa-boot。

（2）SOFARPC，SOFARPC 是一个高可扩展性、高性能、生产级的 Java RPC 框架。github地址为https://github.com/sofastack/sofa-rpc。

（3）SOFATracer，SOFATracer 是蚂蚁金服开发的基于 OpenTracing 规范的分布式链路跟踪系统。github地址为https://github.com/sofastack/sofa-tracer。

（4）SOFALookout，SOFALookout 是一个利用多维度的 metrics 对目标系统进行度量和监控的项目。github地址为https://github.com/sofastack/sofa-lookout。

（5）SOFARegistry ，SOFARegistry 是一个生产级、高时效、高可用的服务注册中心。github地址为https://github.com/sofastack/sofa-registry。

（6）SOFAMesh，SOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案。github地址为https://github.com/sofastack/sofa-mesh。

（7）SOFADashboard ，SOFADashboard 是 SOFAStack 生态的管控端，提供应用信息查看，服务治理，动态模块管控等功能。github地址为https://github.com/sofastack/sofa-dashboard。

（8）SOFABolt，SOFABolt 是一套基于 Netty 实现的网络通信框架。github地址为https://github.com/sofastack/sofa-bolt。

（9）SOFAJRaft，SOFAJRaft 是一个基于 RAFT 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。github地址为https://github.com/sofastack/sofa-jraft。

（10）ACTS，ACTS（AntCoreTest）是一款白盒测试框架，旨在为企业提供高效、精细化的接口自动化测试。github地址为https://github.com/sofastack/sofa-acts。

（11）SOFAArk，SOFAArk 是一款基于 Java 实现的轻量级类隔离和热部署容器。github地址为https://github.com/sofastack/sofa-ark。

（12）MOSN，MOSN 是一款使用 Go 语言开发的云原生网络代理。github地址为https://github.com/mosn/mosn。

（13）Occlum，Occlum 是一个内存安全的、支持多进程的 library OS，特别适用于 Intel SGX。github地址为https://github.com/occlum/occlum。

（14）Seata，Seata 是一款分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。github地址为https://github.com/seata/seata。

（15）Layotto，Layotto 是一款使用 Golang 开发的应用运行时，旨在帮助开发人员快速构建云原生应用，帮助应用和基础设施解耦。github地址为https://github.com/mosn/layotto。

为什么要推荐Spring Cloud Alibaba？

Spring Cloud Alibaba是阿里巴巴开源组织开源的一款，用于服务于微服务架构的基础中间件框架。从框架演变的角度去分析，开发人员大致经历了Spring Framework、Spring Boot和Spring Cloud。

Spring Boot 是一款非常优秀的基础框架，它的诞生几乎颠覆了整个后端的代码架构。技术人员几乎不需要关心基础组件的技术细节，通过简单的几行配置文件和几个Starter组件，就可以快速的搭建一个项目。这个是Spring Framework完全做不到的，所以Spring Boot几乎完全取代了Spring Framework的开发模式。

Spring Boot太香了，开发人员几乎都会把它当作大餐。笔者的公众号就是从Spring Boot开始的。

Spring Boot解决了最底层的开发效率问题，但是它没满足微服务架构中分布式服务治理的刚需。开发者可以基于Spring Boot做定制化开发，并封装各种适合公司业务场景的，各种中间件能力。当然也能封装分布式服务治理的能力，但是不能够定制化标准。一旦行业内标准规范变化，那么定制的功能，很容易被淘汰。于是，Spring Cloud诞生了，它依托强大的社区能力，定制了分布式服务治理的标准。

有了标准，Spring Cloud就疯狂的融合，疯狂的造轮子。就这样它几乎染指了所有的微服务架构的底层技术。

开发者如果使用Spring Cloud，更加如虎添翼，完全不用关心“如何去实现分布式架构所需要的技术功能”。但是这样也会存在问题，只关心功能，并不能解决所有的技术问题。

Spring Cloud Alibaba诞生了，它就这样诞生了。

Spring Cloud Alibaba在Spring Cloud的基础之上，做了改良。你可以这么理解，它并不是一个全新的框架，它只是更好的支撑Spring Cloud。

问题又来了，是不是阿里巴巴内部都在用Spring Cloud Alibaba呢。笔者在这里告诉大家——“肯定不是”，就是是Dubbo，阿里巴巴内部几乎都不用，他们用的都是自研的框架。

为什么又要搞那么多开源的框架，并且顶着阿里巴巴的光环呢。笔者认为，主要是与公司文化有关。

企业代码开源，是大势所趋。通过开源变现也是整个开源行业，公认的最难实现的。阿里巴巴之所以能够开源这么多优秀的框架，主要得利于阿里云平台，它才是最终的盈利输出点。

Spring Cloud Alibaba是Spring Cloud的超集，他底层依赖Spring Boot。Spring Cloud Alibaba不是万能的框架，但是它在演进，改良最终也会变成改革。