SpringCloud-微服务架构演变

1、微服务架构演变

1.1、传统架构

概念：简单来说我们以前传统的应用的就是单体架构，即所有的模块，组件等都在一个应用中，应用最终打成一个war或jar包，使用一个容器(Tomcat或Jetty)进行部署，通常一个应用对应一个数据库，如下：

这样的单体项目我们知道，一般会分成三个层面去做：持久层，业务层，表现层，这样的结构在项目初期，业务较少的情况下没有任何问题，但是随着业务需求不断的增加，单体应用中的业务逻辑，业务组件就会日益扩张，应用就会变得越来越臃肿，越往后，开发和维护工作就越难开展，加上访问量的增加，并发也越来越高，面对海量的用户无论从应用性能还是从数据库方面都会吃不消

所以单体应用在数据量，并发量到一定程度的时候一定会遇到瓶颈

我们来简单总结一下单体架构的优缺点：

优点：

1. 易于开发 ：架构简单，技术成本低
2. 易于测试 ：所有功能在一个项目，方便测试
3. 易于部署 ：一个Tomcat就可以实现部署，简单方便

缺点：

1. 代码臃肿，不方便开发维护，代码可读性差
2. 代码编译慢，系统启动变慢(往往需要几分钟)
3. 系统扩展性变差(牵一发而动全身)
4. 无法针对某一个业务做扩展(集群)
5. 对大数据量，高并发量的处理不占优势
6. 技术选型单一
7. 模块/业务耦合度高，一个模块瘫痪，整个系统瘫痪

1.2、分布式架构

概念：将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互

如下图所示：

为什么要部署到不同的机器中的Tomcat呢？

因为之前整个系统都部署在一个Tomcat中的话，压力太大了，现在这样分开部署的话，将压力可以分摊开来，针对某一个系统，还可以并发较大时做集群处理，这样就将单体应用的很多缺点解决掉了

这里举个例子帮助大家理解：

我老婆一个人在厨房做饭的话，她就得：理菜 — 洗菜 — 切菜 — 炒菜，就会很累，这个时候，如果我进去帮着洗菜，儿子帮着切菜的话，那老婆是不是就轻松多了呢？这样我们每个人各司其职，做好自己的事情就可以了，每个人都没那么累了

总结

分布式就是将应用按照业务拆分成多个子应用，多个子应用部署在不同的服务器中，多个子应用组成一个完整的系统，所有的子系统一起工作，相互通信相互协调才能完成最终的业务流程，缺一不可。

简单理解：多个人在一起做着不同的小事情，这些小事情合在一起才算一件大事情

1.3、SOA-面向服务架构

概念：面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，通过这些服务之间定义良好的接口和契约联系起来；分为三层结构：表现层、服务层、数据访问层

SOA架构模式特点：

1. SOA架构通讯中，采用XML方式实现通讯、在高并发下通讯过程中协议存在非常大冗余性，所以在后面微服务架构中使用JSON格式替代了XML
2. SOA架构实现方案为WebService或者是ESB企业服务总线，底层通讯协议SOAP协议（Http+XML）实现传输

如下图所示：

给大家举一个例子来理解SOA：

统一文字，在秦始皇统一六国之前，各国的文字都是不同的，许多常用的文字有十几种写法和读音，很大程度影响了各国之间的文化交流，就像SOA之前，各种软件平台、各种开发工具和各种接口的组件之间，没有统一的标准，对软件系统之间的整合造成巨大的困难。

因此，伟大的始皇统一了六国文字，“书同文、车同轨”就是通过标准解决“复用”和“互操作”等问题。这也为大规模的印刷和文明发展提供了一个良好的基础，这种“统一封装”的文字，对文化交流起到了一个“互操作”的标准作用

那为什么需要SOA三层架构呢？

1. 粗粒度的服务接口分级，松散耦合，可重用的服务，服务接口设计管理，标准化的服务接口，支持各种消息模式，精确定义的服务契约等
2. SOA可以使每个模块独立出来，用什么取什么。即使模块出现问题，也可以用备份模块代替即可。不影响系统的整个运行。每个人的分工也非常明确，各司其职

我们来总结一下SOA的优缺点：

优点：

1. 模块拆分，使用API通信，降低模块之间的耦合度
2. 项目拆分多个子应用，每个子应用业务简单，代码简单，方便维护开发
3. 不同技术人员可以负责不同的子应用
4. 提高服务之间的重用性，业务逻辑可组合

缺点：

1. 服务之间的API接口开发增加了工作量
2. SOA服务之间的网络通信调用对性能有一定的影响
3. 相对于单体应用来说，技术人力等成本较高
4. 部署和运维相对麻烦

1.4、微服务架构

微服务架构可以认为是在SOA架构上的一种发展，最早由“Martin Fowler”提出：

就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style ) 。但通常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。

另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。
1
2
3

我们从这段描述中可以看出，微服务架构和SOA架构很像，总体来说，微服务就是把单一应用进行细粒度的拆分成多个小(微)的服务，每个服务独立运行，每个服务只需要专注一个业务即可，并且每个服务都可以有自己的数据库(分库)，服务之间互协调配合完成整个系统的业务

我们用一个图来理解微服务架构:

为什么需要在SOA基础上做进化，到SOA呢？因为在传统的WebService架构中有如下问题：

1. 依赖中心化服务发现机制
2. 使用soap通讯协议，通常使用XML格式来序列化通讯数据，xml格式非常重，比较占宽带传输
3. 服务化管理和治理设施不完善

下面我们来总结一下微服务的优缺点：

优点：

1. 单个服务业务简单，代码简单方便开发维护
2. 服务之间无耦合，服务之间升级维护互不影响
3. 不同的服务可以使用不同的编程语言，使用不同的数据库
4. 轻量级HTTP通信机制，使得的不同的服务可以采用不同的编程语言
5. 微服务有极强的扩展能力，业务量大的服务可以再次拆分服务，也可以进行集群部署，剔除服务也很方便
6. 更大的系统负载能力和容错能力
7. 对于开发人员来说，通常只需要关注单一服务，新员工上手比较快

缺点：

1. 分布式事务：服务通信机制增加了事务的复杂性，架构师要选择合适的分布式方案
2. 部署麻烦：微服务众多，部署麻烦，需要借助容器化技术和自动化部署工具，这又增加了开发人员的学习成本
3. 技术成本高：微服务架构本身比较复杂，技术成本高，开发人员需要花更多的时间学习相关技术
4. 服务通信对性能的损耗：微服务架构一定要考虑服务通信延迟对服务调用性能的损耗问题，开发人员需要选择合适的通信方式解决这一问题

1.5、微服务架构与 SOA 架构的区别

1. 微服务架构基于SOA架构演变过来，继承SOA架构的优点，在微服务架构中去除SOA架构中的ESB企业服务总线，采用 http+json（restful）进行传输，微服务是真正的分布式的、去中心化的
2. 微服务架构比 SOA 架构粒度会更加精细，让专业的人去做专业的事情（专注），目的是提高效率，每个服务与服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级
3. 微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成

1.6、架构如何选型？

上面介绍了这么多架构，那么真实项目我们该如何选型呢？是不是一定用最流行微服务就最好呢？

不是的，选用什么架构完全取决于需求和业务场景，如果就是做一个简单的内部系统，用户量和并发不管用多久都不会很大的话，那就用单体，搭建简单，开发简单，部署简单。如果项目愿景是做成全中国最大的电商网站，那前期架构就必须要考虑后期高并发，大数据的场景了，就必须要用微服务了

2、SpringCloud介绍

2.1、基本概念

1. SpringCloud是一个基于Spring Boot实现的服务治理工具包，用于微服务架构中管理和协调微服务的
2. SpringCloud是一系列框架的有序集合，如：服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等
3. SpringCloud是业界微服务架构成熟的落地方案，有了SpringCloud之后，让微服务架构的落地变得更简单

2.2、SpringCloud发展史

1. 最开始的SpringCloud全家桶组件中，很多都是来自于Netflix(网飞)公司，但是在2018年Netflix 公司宣布其核心组件Hystrix 、Ribbon 、Zuul 、Eureka 等进入维护状态 ，不再进行新特性开发，只维修BUG
2. 这直接影响了Spring Cloud 项目的发展路线，Spring 官方不得不采取了应对措施，在2019年的在 SpringOne 2019 大会中，Spring Cloud 宣布 Spring Cloud Netflix 项目进入维护模式 ，并在2020年移除相关的Netflix组件

目前SpringCloud Alibaba组建成为主流了，也受到各公司的青睐，最开始的SpringCloud Netflix那一套技术，我们可以理解为SpringCloud的第一代技术，现在比较流行的SpringCloud Alibaba可以理解为是SpringCloud的第二代技术，这里给大家梳理了一下：

2.3、常见组件介绍

2.3.1、第一代

Netflix Eureka：服务注册与发现

当我们的微服务很多的时候，管理各个微服务的通信地址，将是一个非常麻烦的事情，Eureka就是用来管理微服务的通信地址清单的，有了Eureka之后我们通过服务的名字就能实现服务的调用，非常简单方便

Netflix Ribbon\Feign：客户端负载均衡

Ribbon和Feign都是客户端负载均衡器，其作用是在服务发生调用的时候，帮我们将请求按照某种规则分发到多个目标服务器上，简单理解就是用来解决微服务之间的通信问题

Netflix Hystrix：熔断器

微服务之间的调用是非常复杂的，有时候一个请求需要很多的微服务共同一起完成，那么一旦某个服务发生故障，就会导致整个调用链上的微服务全都出现异常，甚至导致整个微服务架构瘫痪。Hystrix就是用来解决微服务故障，保护微服务安全的组件。类似于我们家里电箱里的保险开关跳闸的道理

Netflix Zuul：服务网关

作为服务网关，我们可以把它看作是微服务的大门，所有的请求都需要经过Zuul之后才能到达目标微服务，根据这一特性，我们可以把所有微服务都需要做的公共的事情可以交给Zuul统一处理，如：用户鉴权，请求监控，限流，黑白名单校验等

Spring Cloud Config：分布式配置

微服务架构中的服务实例非常的多，服务的配置文件分散在每个服务中，每次修改服务的配置文件和重新启动服务都是一个很麻烦的工作，Spring Cloud Config作为分布式配置管理中心就是用来统一的管理服务的配置文件，让配置文件的更新变得非常简单

Spring Cloud Bus：消息总线

消息总线是在微服务中给各个微服务广播消息的一个组件，我们使用消息总线构建一个消息中心，其他微服务来接入到消息中心，当消息总线发起消息，接入的微服务都可以收到消息从而进行消费，做对应业务的处理

Spring Cloud Sleuth：链路追踪

当我们的应用采用微服务架构之后，后台可能有几十个甚至几百个微服务在运行，一个请求可能需要做多次的服务调用最后才能完成，链路追踪的作用就是来监控维护多个微服务之间的调用关系，让程序员方便直观的感受到一个请求经历了哪些微服务，以及服务的请求时间，是否有异常等

2.3.2、第二代

Nacos

一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台

Sentinel

阿里巴巴源产品，把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性

RocketMQ

一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务

Seata

阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案

Alibaba Cloud OSS

阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据

Alibaba Cloud SchedulerX

阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务

Alibaba Cloud SMS

覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道

2.4、SpringCloud版本

2.4.1、官网介绍

1. SpringCloud采用了 英国伦敦地铁站 的名称来命名，并由地铁站名称首字母 A-Z 一次类推的形式来发布迭代版本。例如 Angel 是第一个版本，Brixton 是第二个版本…，目前最新版本是Hoxton
2. 当SpringCloud的发布内容积累到临界点或者一个重大BUG被解决后，会发布一个“service releases” 版本，简称 SRX 版本，比如当前的 Hoxton SR12，就是SpringCloud发布的Hoxton版本的第12个SRX版本

官网查看最新版本：https://spring.io/projects/spring-cloud#learn

由上图可知，SpringCloud官方目前最新稳定版是：2021.0.4，如果单独使用SpringCloud的话，建议选择官方指定的稳定版Hoxton.SR12

2.4.2、如何确定SpringBoot版本

那么我们如何根据SpringCloud版本确定SpringBoot版本呢？

1、方式一

列表方式查找对应的SpringBoot版本

进入SpringCloud官网首页，往下滚动鼠标，找到如下图位置，即是Spring Cloud版本对应的Spring Boot版本

上图说的很清楚了，这里我将SpringCloud和SpringBoot的版本对应关系整理出来了，如下图所示：

一般现在项目中的SpringBoot版本最低是2.0往上了

2、方式二

根据具体版本查找对应的SpringBoot版本

以Hoxton.SR12 版本为例，进入SpringCloud官网首页，依次点击【LEARN】——>Hoxton.SR12版本后的【Reference Doc.】，如下图

点击【Reference Doc.】之后，跳转到如下图页面，可以看到Hoxton.SR12对应的springboot版本为2.3.12.RELEASE

3、方式三

更详细的查找对应的SpringBoot版本

打开浏览器，访问此链接：https://start.spring.io/actuator/info，如下图

由上图可知，SpringCloud的Hoxton.SR12版本对应的springboot版本 大于2.2.0.RELEASE并且小于2.4.0.M1版本

3、小结

具体在微服务项目中该如何引入SpringCloud和SpringBoot，我们后面案例实战时，会讲到，此文仅仅是对微服务架构演变和SpringCloud概念做了一定介绍，有了这些基础，我们再继续往后面学习就会轻松一点了