探索云原生世界：Spring Cloud全方位解读—

探索云原生世界：Spring Cloud全方位解读——构建微服务架构的利器

一、微服务简介

二、微服务发展史

三、Spring Cloud

3.1 Spring Cloud 版本策略

3.2 Spring Cloud 发展历程

微服务是一种软件架构风格，将单一应用程序拆分成一组小型、独立的服务。每个服务运行在自己的进程中，服务之间采用轻量级通信机制进行交互。今天就来带大家全方位的窥探下微服务以及其实现方案 Spring Cloud。

一、微服务简介

微服务的体系非常庞大，框架组件多，微服务的部分学习路径如下图，主要包括三大功能和两大特性。

三大功能指微服务核心组件的功能维度，由浅入深层次递进；两大特性是构建在每个服务组件之上的高可用和高可扩展性。

从功能维度讲，服务间的通信是最基础的功能特性，当构建其服务通信能力之后，接下来就要考虑服务容错能力，提高服务调用的稳定性。在这之后，就可以从全局的角度构建一些分布式特性。

除了功能特性，还会从高可用性和高可扩展性两个维度来做扩展。

高可用性是系统设计首要考虑的目标，保障高可用性有两个方向，分别是：

避免单点故障：在做系统架构时，不能信任任何服务，服务器都有可能挂掉。如果某一个服务只有一台机器，那就会形成单点，一旦这个服务器挂掉，那整个服务都不可用，这时不能接受的。
故障机器状态恢复：尽快将故障机器恢复到故障前的状态。对于向 Nacos 这类中心化注册中心来说，因故障而下线的机器在重新上线后，应该有能力从某个地方获取故障发生前的服务注册列表。

二、微服务发展史

要想很好的了解一个事物，就需要先了解它的发展历史，这样才能知道来龙去脉，才能把握未来，学习微服务也是一样的道理。

微服务是由单体应用发展而来的，单体应用将所有的功能都维护在一个巨无霸的服务中，然后打包成一个 war 包扔到 Tomcat 中运行，对外提供服务。单体应用存在很多问题，比如：

开发中互相干扰
沟通成本高
无法快速迭代
无法单独回滚等

由于单体服务存在很多问题，计算机中的分治思想就产生了作用，将单体应用拆分成比较小的服务，分开维护。

微服务架构是在 SOA (面向服务架构)之上的进一步发展。在实践中，通过领域建模理论将一个大型应用拆分成更细粒度且边界清晰的服务模块，而且每个服务可以单独部署、单独测试、单独发布回滚，并借助 Docker 和 CI/CD (持续集成)完成快速上线。

每个微服务拥有独立的代码库和数据库，采用敏捷开发做快速迭代，微服务的优势：

快速迭代、快速回滚；
资源利用大大提高：可以将硬件资源定向分配给需要用到资源的微服务，实现差异化的资源利用；
降低协作成本：代码库、数据库、编译打包从共享变成独享，进一步降低了沟通成本；
高可用：高可用是系统设计的第一目标，我们可以通过很多技术手段对微服务施加个性化的保护措施，如：弹性机房水位调拨、流量整形、熔断降级。

了解完微服务后，我们再来了解下 Spring Cloud。

三、Spring Cloud

Spring Cloud 由 Spring 社区孵化而成，是专门解决微服务架构的一套全家桶微服务架构。最关键的是，Spring Cloud 除了采用 Spring 社区的研发力量外，还吸纳了众多一线大厂的开源组件，经过深度融合，使这些组件成为 Spring Cloud 的一部分。

以下是 Spring 社区提供的简易架构图

在上图中，可以看到有几个 Spring Boot Apps 的应用集群，这就是经过拆分后的微服务。Spring Cloud 和 Spring Boot 达成了一种默契的配合：Spring Boot 主内，通过自动装配和各种开箱即用的特性，搞定了数据层访问、RESTful 接口、日志组件、内置容器等等基础功能，让开发人员轻轻松松就可以搭建起一个应用；Spring Cloud 主外，在应用集群之外提供了各种分布式系统的支持特性，帮助你轻松实现负载均衡、熔断降级、配置管理等诸多微服务领域的功能。

3.1 Spring Cloud 版本策略

大部分开源项目以数字版本进行更新迭代，Spring Cloud 在诞生之初就别出心裁使用了字母序列，以字母 A 开头，按顺序使用字母表中的字母标识重大迭代发布的大版本号。

Spring Cloud版本
版本	发布时间
Angel	2015年3月
Brixton	2016年5月
Camden	2016年9月
Dalston	2017年4月
Edgware	2017年11月
Finchley	2018年6月
Greenwich	2019年1月
Hoxton	2019年11月
Ilford	2020年12月
Jubilee	2021年12月

SNAPSHOT 版本：正在开发中的快照版本，例如 2021.0.0-SNAPSHOT，快照版代表当前分支最新的代码进度，也是更新最为频繁的小版本类型，不推荐在线上正式环境使用；
Milestone 版本：在大版本正式发布前的里程碑版本，例如 2021.0.0-M1，M1 代表当前大版本的第一个里程碑版本，M2 代表第二个迭代里程碑，以此类推。在正式版本发布之前要经历多个里程碑的迭代，像 Spring Cloud Finchley 版足足经历了 9 个 M 版本之后，才过渡到了 RC 版。同样地，我也不推荐你在正式项目中使用 Milestone 版本；
Release Candidate 版本：这就是我们俗称的 RC 版，例如 2021.0.0-RC1。当一个版本迭代到 RC 版的时候，意味着离正式发布已经不远了。但是你要注意，RC 版是发布前的候选版本，走到这一步通常已经没有新的功能开发，RC 主要目的是开放出来让大家试用并尽量修复严重 Bug。
Release 版：稳定的正式发布版，比如 2020.0.1。你可以在自己的线上业务中放心使用 Release 稳定版。

3.2 Spring Cloud 发展历程

在 Spring Cloud 历史上有两家举足轻重的公司，分别是 Netflix 和 Alibaba。这两家公司分别为开源社区贡献了 Spring Cloud Netflix 组件库和 Spring Cloud Alibaba 组件库。

Netflix 是一家美国的流媒体巨头，它靠着自己强大的技术实力，开发沉淀了一系列优秀的组件，这些组件经历了 Netflix 线上庞大业务规模的考验，功能特性和稳定性过硬。如 Eureka 服务注册中心、Ribbon 负载均衡器、Hystrix 服务容错组件等。后来Netflix 将这些组件贡献给了 Spring 开源社区，构成了 Netflix 组件库。可以这么说，在 Spring Cloud的早期阶段，是Netflix打下了的半壁江山。

Netflix 和 Spring Cloud 度过了蜜月期之后，矛盾就逐渐发生了。先是 Eureka 2.0 开源计划的搁浅，而后 Netflix 宣布 Hystrix 进入维护状态，Eureka 和 Hystrix 这两款 Netflix 组件库的明星项目停止了新功能的研发，Spring 社区不得不开始思考替代方案，在后续的新版本中走向了“去 Netflix 化”。以至于 Netflix 的网关组件 Zuul 2.0 历经几次跳票千呼万唤始出来后，Spring Cloud 社区已经不打算集成 Zuul 2.0，而是掏出了自己的 Gateway 网关。在最新版本的 Spring Cloud 中，Netflix 的踪迹已经逐渐消散。

Spring Cloud Alibaba 是由 Alibaba 贡献的组件库，随着阿里在开源路线上的持续投入，近几年阿里系在开源领域的声音非常响亮。Spring Cloud Alibaba 凝聚了阿里系在电商领域超高并发经验的重量级组件，保持了旺盛的更新活力，成为了 Spring Cloud 社区的一股新生代力量。Spring Cloud Alibaba 组件秉承了“大而全”的特点，就像一个大中台应用一般包罗万象，在功能特性的丰富程度上做到了应有尽有。这也是本课程选择 Spring Cloud Alibaba 组件的一个重要原因。

下面我们看下 Spring Cloud 的组件库，后续会分别详细介绍这些组件，欢迎收藏关注。

Spring Cloud 组件
功能特性	Alibab组件库	Netflix组件库	Spring Cloud官方或三方组件库
服务治理	Nacos	Eureka	Consul
负载均衡		Ribbon	Loadbalancer
远程调用	Dubbo	Netflix Feign	*Openfeign*
服务容错	Sentinel	Hystrix	Resilience4j
分布式配置中心	Nacos		Spring Cloud Config
消息总线			Bus
服务网关		Zuul	Gateway
分布式链路追踪			Sleuth Zipkin
消息中间件	RocketMQ		Stream
分布式事务	Seata