浅谈：SpringCloud框架总结《Java-2021面试谈资系列》

Spring Cloud 是一套完整的微服务解决方案，基于 Spring Boot 框架，准确的说，它不是一个框架，而是一个大的容器，它将市面上较好的微服务框架集成进来，从而简化了开发者的代码量。

一、核心

SpringCloud框架的核心其实就是基于Http协议，这也是它与Dubbo最本质的区别。
Dubbo：基于RPC
SpringCloud：基于Http

二、组件介绍

SpringCloud有几个重要的组件：

• 注册中心：Eureka
• 客户端负载均衡：Ribbon
• 声明式远程方法调用：Feign
• 服务降级、熔断：Hystrix
• 网关：Zuul
  

三、Eureka注册中心

3.1配置文件

3.2启动类

一定不能忘记了注解！！！

3.3对比Zookeeper

我们知道zookeeper也是注册中心，那么它和Eureka又有什么区别呢？
回顾一下CAP原则：

• C(consistency) :强一致性
• A(availability) :可用性
• P(partition tolerance) :分区容错性
  CAP原则遵循三选二：CA,CP,AP

	Zookeeper	Eureka
遵循的原则	CP：一致性、容错性	AP：可用性、容错性
理解	当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用，也就是说，服务注册功能对可用性的要求要高于一致性，但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩下节点会重新进行leader选举，问题在于，选举leader的时间太长，30-120s且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫瘫，在云部署的环境下，因为网络问题使得zk集群失去掌握节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的.	Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况： 1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上(即保证当前节点依然可用) 3.当网络稳定时，当前实例新的注册信息会被同步到其他节点中

Eureka可以很好的应对因为网络故障导致部分节点失去联系的情况，而不会像zookeeper那样，是整个注册服务瘫痪

四、Ribbon客户端负载均衡

4.1Ribbon是什么？

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

4.2Ribbon能干嘛？

• LB，即负载均衡(Load Balance)，在微服务或分布式集群中经常用的一种应用。
• 负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA(高可用)。·常见的负载均衡软件有 Nginx，Lvs等等
• dubbo、SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义·
• 负载均衡简单分类：
  1.集中式LB
  即在服务的消费方和提供方之间使用独立的LB设施，如Nginx，由该设施负责把访问请求通过某种策略转发至服务的提供方！
  2.进程式LB
  将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器。
  Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址！

4.3集群的搭建

1.创建多个注册中心：

2.配置文件绑定：

3.启动集群：

五、Feign负载均衡

5.1简介

feign是声明式的web service客户端，它让微服务之间的调用变得更简单了，类似controller调用service。SprinCloud集成了Ribbon和Eureka，可在使用Feign时提供负载均衡的http客户端。
只需要创建一个接口，然后添加注解即可！
feign，主要是社区，大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问两种方法
1.微服务名字【ribbon】
2.接口和注解【feign】

5.2feign能干嘛？

• Feign旨在使编写Java Http客户端变得更容易
• 前面在使用Ribbon + RestTemplate时，利用RestTemplate对Http请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步封装，由他 来帮助我们定义和实现依赖服务接口的定义，在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它(类似于以前Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解即可。完成对服务提供方的接口绑定，简化了使用Spring Cloud Ribbon时，自动封装服务调用客户端的开发量

5.3对比之前的客户端

之前的客户端controller：

feign的controller：

启动类：

六、服务熔断Hystrix

6.1什么是Hystrix？

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控(类似熔断保险丝)，向调用方返回一个服务预期的，可处理的备选响应(FallBack)，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩

6.2服务熔断

说简单了就是：提供给客户端一个备选方案，如果用户在查询时，出现了异常，不会让用户向之前一样一直等待响应，而是跳转备选方案，提示用户
例如：

6.3服务降级

客户端的备选方案：降级处理，只需要在配置文件中添加即可

七、路由网关Zuul

7.1概述

Zuul包含了对请求的路由和过滤两个最主要的功能：

其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础，而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

注意：Zuul服务最终还是会注册进Eureka
提供：代理+路由+过滤三大功能！

7.2配置文件

7.3启动类