什么是单体架构？

在软件设计中，会将软件分为三层模型：

1. 表示层：用于和用户交互，通常是网页
2. 业务逻辑层：简单说是我们的逻辑代码
3. 数据访问层：用户在网页（表示层）交互的信息，是数据访问层访问数据库拿到的

在这种模式下将所有业务场景的表示层、业务逻辑层、数据访问层放在一起，再经过编译、打包、部署，这就是我们所说的单体架构，架构图如下：

优点

开发速度快、成本低、测试简单明了、部署简单、容易上手。

缺点

1. 当需要修改项目中某个地方的话，必须要所有重新打包部署，部署效率低
2. 系统错误隔离性低，如一个功能出现了错误，可能会导致整个项目宕机
3. 代码混乱，比如一个utils包可能就有上百个工具类
4. 随着时间推移，人员更换，技术债务可能越堆越多，代码会变得难以更改，因为不知道别的某个模块会不会在使用
5. 当需要扩展模块的时候，代码和包变得越来越多，代码的可读性和维护性变得越来越低
6. 当用户量增大，流量增多的时候，这种架构在面对大量的请求的时候，并发能力不够

微服务架构

微服务架构就是将单一程序拆分成一个一个的微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。

简单的说，微服务就是讲单体项目根据业务拆分成一个一个的服务，彻底的去耦合，每个微服务只提供单一的功能服务。除了可以使用HTTP协议进行通信，也可以使用中间件进行通信，例如RabbitMQ，Kafaka等。初次之外，每个服务还可以使用不同的语言，不同的存储技术。

优势

1. 将复杂的业务拆分成多个业务，每个业务是一个独立的微服务，彻底的去耦合，利于分工，当需要增加业务的时候，可以方便创建新的微服务扩展业务，而不用担心有没有别的地方耦合
2. 每个微服务都是独立部署的，如果其中一个宕机了，不会影响整个系统；也方便功能变更时，服务的部署；当流量增大后，可以将服务集群化部署，增强抗击高并发的能力
3. 每个微服务之间可以使用不同的编程语言和不同的数据库

缺点

1. 在复杂程度上来说，微服务比单体建构要更为复杂些
2. 部署比单体项目复杂
3. 服务之间是用HTTP协议通信的，通信成本比单体项目高
4. 数据一致性问题

什么是SpringCloud？

SpringCloud简单来说是上述微服务架构技术落地实现的集合体，是微服务架构下的一站式解决方案

• 服务发现——Netflix Eureka
• 客服端负载均衡——Netflix Ribbon
• 断路器——Netflix Hystrix
• 服务网关——Netflix Zuul
• 分布式配置——Spring Cloud Config

SpringCloud和SpringBoot的关系

SpringBoot是组成微服务架构的一个微服务单位，SpringCloud是将由SpringBoot开发的一个一个的单体微服务整合并管理起来，并为他们提供服务发现、断路器、路由等。SpringCloud依赖于SpringBoot，SpringBoot可以单体运行，但是SpringCloud却不可以