转载声明 : 该文章出处为 扛麻袋的少年
在学习 Spring Cloud 之前，如果你还对微服务架构不是很了解的话，我们就先来了解一下什么是 微服务架构。
在2014年3月， 由 Martin Fowler 提出一种新的架构体系----"微服务架构"。 （图片来自：https://martinfowler.com/aboutMe.html）
微服务架构，是一种架构模式。它提倡 将单一应用程序划分成一组小的服务，服务之间相互协调、互相配置，为用户提供最终价值。每个服务运行在器独立的进程中，服务与服务之间采用 轻量级的通信机制 互相协作（通常是基于 HTTP 协议的 Restful API）。每个服务都围绕着具体业务进行构建，并且 能够被独立的部署到生产环境、类生产环境 等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具来对其进行构建。
既然已经了解了微服务架构体系，那我们再来了解一下 Spring Cloud 。首先提示一下：我们第一印象一定不要将 Spring Cloud 认为是一种技术或者框架。
Spring Cloud 其实是一系列框架的有序集合。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 Spring Boot 的开发风格做到一键启动和部署。
Spring Cloud 并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。（概念性文字，来自 百度百科：Spring Cloud）
我们可以这样理解：Spring Cloud = 分布式微服务架构的一站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶。 首先先来贴张图介绍一下微服务架构体系内的一些组件： 在没有 Spring Cloud 之前，我们如果要开发微服务架构项目。在框架使用方面，就需要我们手动来进行选择了。比如说：
功能框架/组件选择服务调用Ribbon服务熔断Central服务消息Rocket MQ自动化构建部署Docker/Jenkins… 等其他…等其他在选完框架框架以后，由于这些框架都是一个个不同的公司开发的产品。在使用的过程中难免会经常遇到 版本兼容性、多个框架之间的协调性 等问题。显然这是非常棘手的问题，而且有时遇到的 Bug 我们更是无从下手，这么糟糕的体验，烂透了。
他来了，他来了，Spring 带着 微服务全家桶 Spring Cloud 向我们走来了 。此时，我们不再需要去一个个的选择框架，只需要一个 Spring Cloud 全都可以搞定，显然是我们程序界的一大福音。
Spring Cloud 既然这么牛，就需要有多个 组件/框架 在背后作技术支撑，而且在兼容性，协调性方面都要有很好的结合。我们就来瞧瞧 Spring Cloud 这个大集合到底集成有多少（21）种 技术：（图片来自：Spring Cloud中文网-官方文档中文版）
Spring Cloud 俨然已经成为了微服务开发的主流技术栈，在国内开发者社区也是非常的火爆。虽然 Dubbo 也可以做微服务。Dubbo 是在 2012年开源的，距今也 8 年有余了，在Dubbo 开发中途，阿里也在曾经有过放弃 Dubbo 的维护，处于某些原因，后来将其捐献给了 Apache。
Dubbo 框架年代久远。 现在 Spring Cloud Alibaba 也已经正式的加入到了 Spring Cloud 大家庭。并且 Spring Cloud 是最新出来的技术，一定会比 Dubbo 更受宠幸。
在接下来的开发中，微服务项目，推荐您使用 Spring Cloud 2.x + Spring Cloud Alibaba 来搞。（根据公司需求，也可以使用 Dubbo 来搞哦，技术这方面吧，就是用新不用旧呗，哈哈）
Spring CloudDubbo服务注册发现Eureka,zk,consulzk服务调用方式rest方式rpc服务监控spring boot admindubbo monitor熔断降级Hystrix/Sentinel不完善(Mock)服务网关Zuul/Gateway无分布式配置中心Config/nacos无消息总线Bus无MQ消息数据流Stream无在之前介绍的图中，我们看到 Spring Cloud 这个大集合中一共集成有 21 种技术，那么这么多技术/框架我们都需要来学吗？？（满脸懵逼，头大中…）
这么多技术，显然也不需要我们全拿来学习。根据大厂的使用情况，我们只需要学其中的一部分即可，各个服务相对应的技术/框架。如下图所示： 但是好景不长，伴随着 2018 年 Eureka 2.0 版本的闭源，开源版本停止更新。（Eureka 来自 Netflix 公司）。在这之后，断断续续很多技术都有所 变更/停更/升级。几乎全套都停更了!!!。导致 Spring Cloud 一度变得很难。
图中介绍的这些，在 2020 年 2 月以前还都是主流技术。伴随着各个技术 停更引发的"惨案"，Spring Cloud 被迫只能选择其他技术来替代了。
伴随着Spring Cloud 体系各种技术的停更，几乎全套都停更了，Spring Cloud 被迫选择其他技术来替代升级。Spring Cloud 升级后的技术架构，如下图所示：
服务注册中心： 推荐使用 Spring Cloud Alibaba Nacos ，不推荐使用 Consul（如果公司不想用新的技术，也可以使用 ZK 作为服务注册中心）服务调用： 使用的是 Ribbon。但是这个小伙伴也有点小问题，是个半生不熟的玩意，也进入到了维护的状态。Spring 官方还在继续用，但是后续会推出一个 Spring Cloud LoadBalancer ，它会慢慢取代 Ribbon（官方说明：Ribbon 可以继续使用，但停止更新）（用一句搞笑话来说：Ribbon 停更是轻度患者，Eureka 是进ICU了，已经挂了。）服务调用2： 跟 Ribbon 齐名的 Feign，这哥们差不多也挂了。这哥们长期不更新，Spring 社区实在是等不起了，就自己新出了一个 OpenFeign。（Feign 可以不用了，死翘翘了，2020年推荐使用 OpenFeign）服务降级： 服务降级领域，当属 豪猪哥 Hystrix了 。但是豪猪哥也寿终正寝了。官网已经不推荐使用。但是在国内 Hystrix 豪猪哥 是 Spring Cloud 自带的一套服务降级和熔断框架，还在大规模的使用。Hystrix 停更后，国外老外推荐使用 resilience4j，但是在国内，我们还是推荐使用Spring Cloud Alibaba 的 Sentinel（强烈推荐，比 Hystrix 还好用）服务网关： Zuul，也属于 Netflix。它就有点搞笑了，内部开发团队产生分裂，自己把自己作死了。 Netflex 公司后台想自己再出一个 Zuul2，但是没有开发出来便胎死腹中。此时，Spring 便自己开发出了一个新的服务网关 gateway ，这也是目前推荐的主流网关服务组件。服务配置： Spring Cloud Config 。它也不再使用了。现在主流推荐：1.携程网的 apolo 2. 强烈推荐使用 Spring Cloud Alibaba Nacos(强烈推荐)。服务总线： Spring Cloud 原生，使用的是 Bus，现在也慢慢的被 Spring Cloud Alibaba Nacos替换了。微服务架构 与 Spring Cloud 的相关内容，就先介绍到此。
下一篇： Spring Boot 与 Spring Cloud 之间版本选择问题
