SpringCloud组件详解（对于基础的一些面试也是有用的）

SpringCloud组件介绍

这个组件我百度了一下，我看网上有些不一样的，我这里就不管那么多了。有问题欢迎各位大牛留言，谢谢。外附一个链接
链接: https://blog.csdn.net/xunjiushi9717/article/details/91988479?utm_source=app.

先介绍一下什么是SpringCloud的吧：SpringCloud通俗易懂的理解方式，就是一系列框架的集合，内部整合了很多组件。核心组件主要有：

Eureka（注册中心）

一个服务注册与发现的组件。Eureka的体系主要包括服务的提供者，服务的消费者，服务注册中心。服务的提供者和消费者都是Eureka的客户端，服务注册中心作为Eureka的服务端。我们在使用Eureka的时候，通过配置文件的方式，将我们的API接口注册到Eureka的注册中心上，我们的服务的消费者可以向Eureka注册中心拉取服务列表，然后根据获取的服务列表选择一个服务的提供者进行消费服务。

听起来可能有人会觉得这跟Zookeeper差不多，Dubbo就是以Zookeeper作为注册中心的。但是这两者还是有区别的，（要不岂不是没有Eureka什么事了）：

Dubbo只是实现了服务治理，而SpringCloud的子项目分别覆盖了微服务架构的很多组件。

Dubbo的效率略高于SpringCloud。因为Dubbo底层使用了RPC通信协议，而SpringCloud使用的RESTful完成的通信协议。大型的微服务架构项目，还是推荐使用SpringCloud。

Eureka可以通过搭建集群实现Eureka的高可用，防止Eureka挂掉，导致Eureka的不可用。这我们需要注意搭集群的时候，要保证每个Eureka服务注册中心之间要实现相互注册，防止数据的不一致或者数据丢失。这里主要是通过配置文件的方式进行实现，不过多解释，可以查询其他资料。

如何从EurekaServer中动态的获取服务提供方的IP和端口号

1.注入DiscoveryClient对象,激活
2.调用getInstances()方法

最后提一下Eureka的自我保护机制

Eureka的自我保护机制

Eureka的自我保护机制：Eureka客户端会定时的向 Eureka服务端发送心跳包，默认是30S发送一次，目的是告诉 Eureka服务端当前客户端实例还处于存活状态，如果Eureka服务端在一定时间内没有收到实例的心跳，便会把该实例从注册表中删除（默认是90S）,但是，如果短时间内丢失大量的实例心跳，便会触发Eureka服务端的自我保护机制的 ,默认自我保护机制处于开启状态。
这里不多解释了，参考这条链接
链接: https://blog.csdn.net/BruceLiu_code/article/details/104913775.
感谢https://blog.csdn.net/BruceLiu_code.

Ribbon（负载均衡）

一个基于HTTP和TCP的负载均衡工具，可以简化我们的远程调用。这里有必要提一下负载均衡：
服务端的负载均衡：负载均衡算法在服务端，由负载均衡器维护服务地址列表。在某些情况下，比如我们要搭集群，实现服务器端的高可用。我们需要配置多台服务器，每个服务器都有不同的服务请求地址。当我们的客户端向服务端发送请求的时候，不会直接去访问我们的服务器，会先经过一个负载均衡器，内部通过负载均衡算法，帮我们去访问不同的服务器。这主要是服务端的负载均衡。

还有客户端负载均衡：我们的服务的消费者通过Eureka访问我们的服务生产者（这里我们配置了多个生产者，实现了高可用的集群环境），然后我们的服务消费者通过Eureka将服务的提供者的路径地址保存在服务消费者内部，然后通过服务消费者自己写的负载均衡算法选择不同的节点，和服务的提供者建立连接。

这里我们提一下负载均衡的策略：随机，轮询（这也是Ribbon默认使用的负载均衡策略），最小并发，过滤，轮询重试，性能可用性等。而我们的Ribbon也可以通过配置文件的方式设置负载均衡策略。

这里由于是配置文件的方式，不过多阐述，有兴趣的可以去查阅资料了解一下。以下文章涉及编码和配置的全部省略。

那么Ribbon是怎么简化远程调用的呢？

这里我就只做简述，涉及的代码后期有时间再补上

1.我们在声明RestTemplate的时候，添加一个@LoadBalanced注解。
2.在使用RestTemplate发送请求，定义url时，host:port可以替换为服务提供者的应用名称。

这里就不过多阐述了，大家有时间可以去看其他的资料。

Feign

一个声明式的REST客户端，使用了基于注解的方式，方便了我们客户端的配置。简单总结一句话：Feign 的出现使得Eureka和Ribbon的使用更为简单，同时支持SpringMVC注解。引入feign依赖，编写Feign调用接口，启动类添加@EnableFeignClients注解，开启Feign功能。这里具体的配置和代码不做讲解了，后期有时间我会单独写一篇博客补上来。

Hystrix（熔断器）

这里先提一下服务雪崩：

服务雪崩

服务雪崩： 在分布式系统或者微服务的架构下，各个系统之间的关系错综复杂，相互依赖。如果一个服务出现问题，可能会导致整个系统出错，会造成一种雪崩的情况。所谓的雪崩就是一个服务失败了，导致整条链路的服务都失败的情形。这个时候，可以使用Hystrix（熔断器）隔离远程服务。

Hystrix（熔断器）就是一个延迟容错库，用于隔离远程服务、第三方库，防止出现级联失败（雪崩）。

服务隔离：
线程池隔离：我们将线程池中的线程分别进行隔离，拆分成多个小的线程池，每个线程池中有若干线程。当一个服务挂掉以后，只会导致当前服务相对应的线程池中无可用线程。不会影响其他的服务。

信号量隔离：限制我们的访问量，访问次数。

服务降级：
在进行程序开发的时候，我们要预判到我们的程序失败的情况并进行处理。当程序服务出现失败的情况后，我们采用我们的降级方案，屏蔽一下错误情况，进行一些友好提示。不管是服务的提供方还是消费方我们都需要进行降级方案的处理。防止消费方在对服务提供方调用之前就出现错误情况。

服务熔断：
可以监控我们微服务的调用情况，当失败的次数达到某个阈值的时候，会自动打开断路器，拒绝所有的请求，直到恢复正常。

这里简单提一下断路器：断路器有三种状态：关闭，打开，半开。默认是关闭的，当我们请求失败次数达到阈值的时候，断路器会自动打开，拒绝所有的请求，打开5秒以后，会切换为半开状态，判断请求是否正确。确定是否关闭断路器。

服务限流
技术不够，博客来凑
链接：http://c.biancheng.net/view/5543.html.

zull（微服务网关）

链接：https://blog.csdn.net/xunjiushi9717/article/details/91988479?utm_source=app.
感谢https://blog.csdn.net/xunjiushi9717.
Spring Cloud Zuul通过与Spring Cloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其他微服务的实例信息。对于路由规则的维护，Zuul默认会将通过以服务名作为ContextPath的方式来创建路由映射。Zuul提供了一套过滤器机制，可以支持在API网关无附上进行统一调用来对微服务接口做前置过滤，已实现对微服务接口的拦截和校验。

Spring Cloud Config

这个就不说了，直接看这个链接吧，我也不是特别的懂
链接：https://www.jianshu.com/p/d696fc89a331.

Gateway（网关）

​ 通过网关去配置后台微服务的地址，用户直接跟网关打交道，将请求发送给网关，网关再将请求发送给对应的微服务。旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。

​ 网关就是一个系统的入口，封装了程序的内部结构。一些认证、监控、权限验证、缓存等公共的逻辑可以在网关中实现。

Gateway的静态路由： 通过Gateway进行请求转发的时候，我们配置文件中的uri地址是写死的。

Gateway的动态路由（Gateway怎么实现动态路由）：

当我们的一个微服务的uri发生变化的时候，网关的配置就要进行更改，显然很不方便。所以我们需要配置动态路由。我们的微服务的IP端口会注册到Eureak，网关可以直接从Eureak中拉取就可以了，这里我们只需要让网关成为Eureak的一个客户端就行了。
将我们配置文件中的uri改为：

uri:lb://Eureak中注册的服务名称

Gateway（网关）过滤器

Gateway中可以定义多个过滤器，形成一种过滤器链，对我们的请求和相应进行拦截，然后完成一些通用的操作。

两种过滤器方式：pre 和 post

pre：在转发之前执行

post：在转发之后执行

两种类型的过滤器：

GatewayFilter（局部过滤器，针对的单个路由）：在配置文件中进行配置生效。

GlobalFilter（全局过滤器，针对所有路由）：不需要进行配置，系统初始化时加载。

如有不妥之处，希望各位技术大牛多多指教，及时留言，个人不吝赐教。
如有不妥之处，希望各位技术大牛多多指教，及时留言，个人不吝赐教。
如有不妥之处，希望各位技术大牛多多指教，及时留言，个人不吝赐教。