SpringCloud的知识入门详解——干货满满~
前言：
在讲解之前，希望大家先思考几个问题：
什么是微服务？
SpringCloud如何学习？
Eureka、Ribbon、Feign、Hystrix、Zuul，五大组件如何使用？ 如何将项目的配置放置到远程的Github进行管理，通过SpringCloudConfig？
未来的路该如何走！
注：在学习下面的内容之前，必须要掌握springBoot不然是没法进行学习的！——springCloud是基于springBoot的。
微服务的理解：
就是把一个项目拆分为多个项目， 项目之间进行独立运行。 通过Http或者Socket来进行通信处理数据和调用。
注：微服务最大的瓶颈就是网络，所以5G的到来，微服务可能会有质的提升。
微服务概括：
所以每个微服务都是一个独立的进程！
微服务技术栈：
为什么选择springCloud作为微服务架构？
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8vBkjDVz-1583649273297)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20200308134931790.png)]
springCloud入门：
springCloud和springBoot的关系：
传统一个网站的架构图：
springCloud和Dubbo的对比：
社区活跃度对比：
注：Dubbo现在重启了，以后能走多远我们还不知道！
springCloud入门：
Eureka注册中心：
服务治理： 服务治理是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册和发现。
服务注册： 在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，包括服务的主机与端口号、服务版本号、通讯协议等一些附加信息。注册中心按照服务名分类组织服务清单，同时还需要以心跳检测的方式去监测清单中的服务是否可用，若不可用需要从服务清单中剔除，以达到排除故障服务的效果。
服务发现： 在服务治理框架下，服务间的调用不再通过指定具体的实例地址来实现，而是通过服务名发起请求调用实现。服务调用方通过服务名从服务注册中心的服务清单中获取服务实例的列表清单，通过指定的负载均衡策略取出一个服务实例位置来进行服务调用。
Eureka服务端：Eureka服务端，即服务注册中心。它同其他服务注册中心一样，支持高可用配置。依托于强一致性提供良好的服务实例可用性，可以应对多种不同的故障场景。Eureka服务端支持集群模式部署，当集群中有分片发生故障的时候，Eureka会自动转入自我保护模式。它允许在分片发生故障的时候继续提供服务的发现和注册，当故障分配恢复时，集群中的其他分片会把他们的状态再次同步回来。集群中的的不同服务注册中心通过异步模式互相复制各自的状态，这也意味着在给定的时间点每个实例关于所有服务的状态可能存在不一致的现象。
Eureka的自我保护机制：
重点：CAP以及和Zookeeper的对比：
Ribbon 客户端负载均衡：
客户端与服务端级别的负载均衡：
服务器端负载均衡： 例如Nginx，通过Nginx进行负载均衡过程如下：先发送请求给nginx服务器，然后通过负载均衡算法，在多个业务服务器之间选择一个进行访问；即在服务器端再进行负载均衡算法分配。
客户端负载均衡： 客户端会有一个服务器地址列表，在发送请求前通过负载均衡算法选择一个服务器，然后进行访问，即在客户端就进行负载均衡算法分配。
Feign面向接口负载均衡：
Hystrix 服务熔断：
分布式的问题：
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。
熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作继续，或者立即返回错误。
断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。
服务熔断：
服务降级：
流监控：
Zuul服务网关：
Config服务：
其实就是项目上线了，很有多配置，我们希望能够对他们进行统一管理。
Bus（消息总线）:
Spring Cloud Bus 将分布式的节点用轻量的消息代理连接起来。它可以用于广播配置文件的更改或者服务之间的通讯，也可以用于监控。
消息总线是一种通信工具，可以在机器之间互相传输消息、文件等。消息总线扮演着一种消息路由的角色，拥有一套完备的路由机制来决定消息传输方向。发送段只需要向消息总线发出消息而不用管消息被如何转发。Spring cloud bus 通过轻量消息代理连接各个分布的节点。管理和传播所有分布式项目中的消息，本质是利用了MQ的广播机制在分布式的系统中传播消息，目前常用的有Kafka和RabbitMQ。
1、提交代码触发post请求给bus/refresh
2、server端接收到请求并发送给Spring Cloud Bus
3、Spring Cloud bus接到消息并通知给其它客户端
4、其它客户端接收到通知，请求Server端获取最新配置
5、全部客户端均获取到最新的配置
Stream（消息驱动微服务）:
消息驱动理解： Windows消息是，当一个窗体或者控件需要让另外一个窗体或者消息执行某个动作，就向那个窗体发一个消息，放到对方的消息队列中，然后对方有一个消息循环不停的读取消息队列，并执行相应的动作。
简单的讲就是一种生产者，消费者模式。发布者是生产，将输出发布到数据中心，订阅者是消费者，订阅自己感兴趣的数据。当有数据到达数据中心时，就把数据发送给对应的订阅者。
Sleuth（分布式服务跟踪）:
在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。
Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案。
这些都是高频的面试题，大家抽空整理一下吧！