转载声明：文章来源https://blog.csdn.net/qq_39740400/article/details/131138525

SpringCloud简介

SpringCloud是基于SpringBoot的一整套实现微服务的框架。它提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。

SpringCloud是一个开发工具集合，含有多个子项目，它利用SpringBoot简化了分布式系统基础设施的开发。

1、Eureka

（1）主要功能：服务注册与发现。采用的c-s架构，由两个组件组成：Eureka服务端和Eureka客户端。Eureka客户端向Eureka服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

（2）两大组件

EurekaServer用作服务注册服务器，提供服务注册服务,各个节点启动后，会在EurekaServer中进行注册， 这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在页面中看到。

EurekaClient是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。在应用启动后，将会向EurekaServer发送心跳(默认周期为30秒),以证明当前服务是可用状态。如果EurekaServer在一定的时间（默认90秒）未收到客户端的心跳，EurekaServer将会从服务注册表中把这个服务节点移除。

（3）Eureka的自我保护机制

自我保护机制的工作机制是如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制，此时会出现以下几种情况：

1、Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。

2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。

3、当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。

因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，而不会像ZK那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。

（4）Eureka和Zookeeper

CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。

Zookeeper保证CP

Zookeeper在一致性和可用性之间选择了一致性，因此集群里面的数据是全局一致的，每个 Server 都保存了一份相同的数据副本。客户端无论连接到哪一个 Server，数据都是一致的。这也意味着 Leader 只有将新数据同步给所有的 Follower 之后，整个 zookeeper 集群才能对外提供服务，否则客户端就有可能读到旧数据。当Leader 节点因为网络故障或者其他原因导致与其他节点失去联系，剩余节点则会发起选举，选举期间导致短暂不可用的情况，所以保证了强一致性而无法保证高可用性。

Eureka保证AP

Eureka保证了可用性，实现最终一致性。

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)，其中说明了，Eureka是不满足强一致性，但还是会保证最终一致性。

2、Ribbon和Feign

在微服务架构中，服务与服务的通讯是基于http的。SpringCloud有两种服务调用方式，一种是Ribbon+RestTemplate，另一种是Feign。

（1）Ribbon

作用：Ribbon主要提供客户侧的软件负载均衡算法。Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。

Ribbon 是 Netflix 发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将 Netflix 的中间层服务连接在一起，Ribbon 客户端组件提供一系列完善的配置项如连接超时，重试等，简单的说，就是在配置文件中列出 Load Balancer 后面所有的机器，Ribbon 会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器，我们也很容易使用 Ribbon 实现自定义的负载均衡算法。

（2）RestTemplate

传统情况下在java代码里访问restful服务，一般使用HttpClient，不过此种方法使用起来太过繁琐。Spring框架提供的RestTemplate类，简化了与 http 服务的通信方式，统一了 RESTful 的标准，封装了 http 链接， 我们只需要传入 url 及返回值类型即可。相较于之前常用的 HttpClient，RestTemplate 是一种更优雅的调用 RESTful 服务的方式。

（3）Feign

Feign是一个声明式http客户端。使用Feign能让编写http客户端更加简单,它的使用方法是定义一个接口,然后在上面添加注解，从避免了 调用目标微服务时，需要不断的解析/封装json 数据。SpringCloud中Feign默认集成了Ribbon，默认实现了负载均衡的效果。

（4）Ribbon和Feign的区别

Ribbon和Feign都是用于调用其他服务的，不过方式不同。

1.启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。

2.服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。

3.调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。

Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可，

不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。

（5）Ribbon和Nginx的区别

Nginx是服务器端负载均衡

Nginx是客户端所有请求统一交给Nginx，由Nginx进行实现负载均衡请求转发，属于服务器端负载均衡。

Ribbon是客户端负载均衡

Ribbon 是从 eureka 注册中心服务器端上获取服务注册信息列表，缓存到本地，然后在本地实现轮询负载均衡策略。

应用场景的区别：

Nginx 适合于服务器端实现负载均衡 比如 Tomcat

Ribbon 适合与在微服务中 RPC 远程调用实现本地服务负载均衡，比如 Dubbo、SpringCloud 中都是采用本地负载均衡。

3、Zuul

Zuul 是 NetFlix 开源的微服务网关，可以和 Eureka、Ribbon、Hystrix 等组件配合使用，其核心是一系列的过滤器；身份认证和安全：识别每个资源的验证要求，拒绝不符合要求的请求；审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图；动态路由：动态地将请求路由到不同的后端服务集群；压力测试：逐渐增加指向集群的流量；负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求；静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到集群内部；多区域弹性：跨越 AWS Region 进行请求路由，实现 ELB（AWS Elastic Load Balancing ---- 负载均衡服务）使用的多样化，以及让系统的边缘更贴近系统的使用者。

Zuul的核心是一系列的filters,过滤器之间没有直接进行通信,而是通过Request Context(上下文)进行数据传递。

Zuul的过滤器是由Groovy写成，这些过滤器文件被放在Zuul Server上的特定目录下面，Zuul会定期轮询这些目录，修改过的过滤器会动态的加载到Zuul Server中以便过滤请求使用。

Zuul负载均和：zuul拦截对应的api前缀请求做转发 转发到对应的 serverId上，在eureka服务上同一个serverId可以对应多个服务， 也就是说用同一个服务节点不同的端口注册两个实例，但是serverId是一样 Zuul做转发的时候会结合eureka-server起到负载均衡的效果。

（1）过滤器的种类

四种过滤器

PRE(前置)：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现鉴权、限流、参数校验调整等。

ROUTING(路由)：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfilx Ribbon请求微服务。

POST(后置)：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端、日志等。

ERROR(错误)：在其他阶段发生错误时执行该过滤器。

（2）Zuul和Nginx

Zuul虽然在性能上和nginx没法比,但它也有它的优点。Zuul 提供了认证鉴权,动态路由，监控，弹性，安全,负载均衡等边缘服务。

nginx和Zuul是可以配合使用的,发挥各自的优点,使用nginx作为负载均衡实现高并发的请求转发,Zuul用作网关

（3）Zuul和Ribbon实现负载均衡

Zuul是对外暴露的唯一接口相当于路由的是controller的请求，而Ribbon和Fegin路由了service的请求

Zuul做最外层请求的负载均衡 ，而Ribbon和Fegin做的是系统内部各个微服务的service的调用的负载均衡

4、Hystrix

Hystrix 断路器是一种开关装置，当某个服务单元发生故障之后，比如超时、异常等，通过断路器的故障监控，向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方不会长时间、不必要占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

雪崩效应：在微服务架构中，存在多个微服务，若其中一个微服务出现故障，就很容易因为依赖关系而引发故障蔓延，最终导致整个系统瘫痪，列举：电商系统中，存在用户、订单、库存、积分、评论等微服务，用户创建一个订单，请求库存系统出货，库存系统出现问题，导致订单服务挂起或失败，在高并发的情况下，被挂起的线程导致后续请求被阻塞，最终导致订单服务不可用。

服务熔断

服务熔断：当 A 服务去调用 B 服务，如果迟迟没有收到 B 服务的响应，那么就终断当前的请求，而不是一直等待下去，此时还要去监控 B 服务，当 B 服务恢复正常使用时，A 服务再发起请求；在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值,缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand.

服务降级：A 服务调用 B 服务，没有调用成功发生熔断，那么 A 服务拿一个默认值顶着，避免给我们的用户，响应一些错误的页面；请求缓存：对接口进行缓存，可以大大降低生产者的压力，适用更新频率低，但是访问又比较频繁的数据。

请求合并：将客户端多个请求合并成一个请求，只发送一个 HTTP 请求，得到响应后再将请求结果分发给不同的请求，这样就可以提供传输效率。

Netflix Hystrix 实现了断路器、线程隔离等一系列保护功能，用于隔离访问远程系统、服务或者第三方库，防止联级失败，从而提升系统的可用性与容错性。

Hystrix监控和断路器。

我们只需要在服务接口上添加Hystrix标签,就可以实现对这个接口的监控和断路器功能

Hystrix Dashboard监控面板,他提供了一个界面,可以监控各个服务上的服务调用所消耗的时间等。

Hystrix Turbine监控聚合

使用Hystrix监控,我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统查看。这样就不需要挨个打开一一个个的页面一个个查看。

5、config

微服务各自拥有自己的配置文件，当配置修改之后，我们需要重启项目，如果数量庞大，维护成本增加，针对这个问题，我们采用 Spring Cloud Config 来做配置。

Config Server：也被称为分布式配置中心，它是一个独立运行的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密信息和解密信息的访问接口。

Config Client：指的是微服务架构中的各个微服务，它们通过 Config Server 对配置进行管理，并从 Config Sever 中获取和加载配置信息。

Spring Cloud Config 默认使用 Git 存储配置信息，因此使用 Spirng Cloud Config 构建的配置服务器天然就支持对微服务配置的版本管理。我们可以使用 Git 客户端工具方便地对配置内容进行管理和访问。除了 Git 外，Spring Cloud Config 还提供了对其他存储方式的支持，例如 SVN、本地化文件系统等。

Spring Cloud Config 工作流程如下：

（1）开发或运维人员提交配置文件到远程的 Git 仓库。

（2）Config 服务端（分布式配置中心）负责连接配置仓库 Git，并对 Config 客户端暴露获取配置的接口。

（3）Config 客户端通过 Config 服务端暴露出来的接口，拉取配置仓库中的配置。

（4）Config 客户端获取到配置信息，以支持服务的运行。