关于SpringCloud出生的前因

业务架构的演变

1.单体架构：一个war，一个进程

从运维者的角度：一个小小的改动，需要把整个项目重新打包部署

从业务的角度拆分：用户模块，订单模块，商品 模块------>单独部署成一个个war包

2.随着网民，并发数增加之后为了满足更高的要求：商品模块-------->N 个 商品模块-------->高可用，集群化部署的方式+负载均衡

负载均衡：

面向服务的架构：SOA架构

随着高可用，集群化+负载均衡的出现，这个架构依旧存在的着问题，比如通用性的功能（登录验证，天气，发送邮件）重复的开发和部署：人力资源的浪费从而出现了SOA架构

微服务时代

面对用户模块的代码量越来越多，维护的成本也越来越高，这时候需要更细粒度的拆分，这就是微服务时代。但是微的拆分是无法衡量的。

微服务的定义：
1.每个服务都有自己的进程
2.这些服务需要通信，我们通常采用轻量级的通信机制，采用HTTP网络请求这样的方式去通信
3.这些服务可自动化 ，可伸缩（随时可增加服务）
4.每个服务可以用不同的开发技术，不同的 数据库开发

微服务要解决的问题

（1）Http协议调用方式

（2）服务的名称 服务所在地址的URL关系维护，既服务的注册与发现（中间件）

（3）负载均衡

（4） 当user调用order失败的时候，是直接给user返回一个错误码，还是等待一段时间 重试（等着order 容错）

（5） 如果服务的资源有限，当并发量超过一定数的时候order可以就会崩溃，需要对order进行一定的保护：熔断，限流，降级

（6）单体时代，只需要在一个进程上面登录验证 ，但是微服务架构如何保证每个服务都进行了登录验证：统一安全认证入口（网关层面）
（7）等

Spring生态

由于微服务要解决很多问题，但是不同的公司对于某个问题有不同的组件去解决这个问题

1.SpringMVC 创建了一个order
(1)整合Mybatis CRUD
（2）lombok Bean
(3)xxx

2.SpringMVC user
(1)整合A组件完成http调用order服务
（2）整合B做服务的注册与发现

为何要使用Spring

管理Bean ( DI IOC ) AOP MVC，但是这样使用Spring并不方便，需要搭建很多配置，因此在Spring的基础上封装了SpringBoot
SpringBoot：一键创建工程和更高效地开发代码

SpringCloud

SpringCloud定义：为了解决微服务所遇到的问题提供的一个通用性解决方案，它定义好了各种接口和规范

SpringBoot整合各大公司的组件完成微服务的解决方案

如服务的注册与发现（中间件）：nacos ,eureka ,consul, zookeeper,etcd等

SpringBoot+各大组件的时候，由于组件太多，SpringBoot不可能一个个去整合，那样子会累死它，必须有一个 类似于中间人的东西去帮SpringBoot整和各种组件：这个东西就是SpringCloud

==因此在微服务架构时代，要解决微服务架构所遇到的问题，只需要SpringBoot整合SpringCloud就可以了，而各种组件实现SpringCloud接口 ，使整合难度大大减低 ==

SpringCloud

总结