（原创不易，你们对阿超的赞就是阿超持续更新的动力！）
（以免丢失，建议收藏，阿超持续更新中…）
Spring Cloud 是什么
Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的开发便利性简化了分布式系统的开发，比如服务发现、服务网关、服务路由、链路追踪等。Spring Cloud 并不重复造轮子，而是将市面上开发得比较好的模块集成进去，进行封装，从而减少了各模块的开发成本。换句话说：Spring Cloud 提供了构建分布式系统所需的“全家桶”。
Spring Cloud 优缺点
其主要优点有：
- 集大成者，Spring Cloud 包含了微服务架构的方方面面。
- 约定优于配置，基于注解，没有配置文件。
- 轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者。
- 开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发。
- 开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件。
它的缺点：
- 项目结构复杂，每一个组件或者每一个服务都需要创建一个项目。
- 部署门槛高，项目部署需要配合 Docker 等容器技术进行集群部署，而要想深入了解 Docker，学习成本高。
pring Cloud 五大组件
Eureka（Nacos）：服务发现，注册中心------>@EnableDiscoveryClient
作用：实现服务治理（服务注册与发现）
简介：Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。由两个组件组成：Eureka服务端和Eureka客户端。Eureka服务端用作服务注册中心。支持集群部署。Eureka客户端是一个java客户端，用来处理服务注册与发现。
在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。
Ribbon：
作用：负载均衡
简介：会帮你在每一次请求的时候选择一台机器，均匀的把请求发送到各个机器上 ，Ribbon的负载均衡默认的使用RoundRobin轮询算法，什么是轮询算法？如果订单服务对库存发起十次请求，那就先让你请求第一台机器，然后是第二台机器，第三台机器，…，接着循环到第十台机器
Gateway（zull）：网关，路由，过滤器，断言
作用：请求路由, 过滤校验, 负载均衡
位置：后端微服务请求入口
项目中使用：
网关全局过滤器 ----------> 校验token , 请求头添加userId ------> 两个接口: GlobalFilter , Ordered
Hystrix：断路器
作用：断路器，保护系统，控制故障范围。
简介：为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
Config：分布式配置
作用：配置管理
简介：SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。
这个是静态的，得配合Spring Cloud Bus实现动态的配置更新
Spring Cloud 和 Dubbo 对比
Dubbo 只是实现了服务治理，而 Spring Cloud 实现了微服务架构的方方面面，服务治理只是其中的一个方面
SpringBoot 和 SpringCloud
SpringBoot是Spring推出用于解决传统框架配置文件冗余，装配组件繁杂的基于Maven的解决方案，旨在快速搭建单个微服务。
而SpringCloud专注于解决各个微服务之间的协调与配置，服务之间的通信，熔断，负载均衡等。
技术维度并相同，并且SpringCloud是依赖于SpringBoot的，而SpringBoot并不是依赖与SpringCloud，甚至还可以和Dubbo进行优秀的整合开发
总结
SpringBoot专注于快速方便的开发单个个体的微服务
SpringCloud是关注全局的微服务协调整理治理框架,整合并管理各个微服务,为各个微服务之间提供,配置管理,服务发现,断路器,路由,事件总线等集成服务
SpringBoot不依赖于SpringCloud,SpringCloud依赖于SpringBoot,属于依赖关系
SpringBoot专注于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架
Eureka 和 ZooKeeper两个的区别
- ZooKeeper保证的是CP，Eureka保证的是AP
- ZooKeeper在选举期间注册服务瘫痪，虽然服务最终会恢复，但是选举期间不可用的
Eureka各个节点是平等关系，只要有一台Eureka就可以保证服务可用，而查询到的数据并不是最新的
ZooKeeper有Leader和Follower角色，Eureka各个节点平等
ZooKeeper采用过半数存活原则，Eureka采用自我保护机制解决分区问题
Eureka本质上是一个工程，而ZooKeeper只是一个进程
微服务之间是如何独立通讯的
- 远程过程调用（Remote Procedure Invocation）
也就是我们常说的服务的注册与发现- 直接通过远程过程调用来访问别的service。
优点：
简单，常见,因为没有中间件代理，系统更简单
缺点：
只支持请求/响应的模式，不支持别的，比如通知、请求/异步响应、发布/订阅、发布/异步响应
降低了可用性，因为客户端和服务端在请求过程中必须都是可用的
消息
使用异步消息来做服务间通信。服务间通过消息管道来交换消息，从而通信。
优点：
把客户端和服务端解耦，更松耦合
提高可用性，因为消息中间件缓存了消息，直到消费者可以消费
支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响应
缺点：
消息中间件有额外的复杂性
微服务的优缺点分别是什么
优点：
- 每一个服务足够内聚,代码容易理解
- 开发效率提高,一个服务只做一件事
- 微服务能够被小团队单独开发
- 微服务是松耦合的,是有功能意义的服务
- 可以用不同的语言开发,面向接口编程
- 易于与第三方集成
- 微服务只是业务逻辑的代码,不会和HTML,CSS或者其他界面组合
- 开发中,两种开发模式
- 前后端分离
- 全栈工程师
- 可以灵活搭配,连接公共库/连接独立库
缺点：
- 分布式系统的负责性
- 多服务运维难度,随着服务的增加,运维的压力也在增大
- 系统部署依赖
- 服务间通信成本
- 数据一致性
- 系统集成测试
性能监控
