1.SpringBoot和SpringCloud的区别？

1. SpringBoot专注于快速方便的开发单个个体微服务

2. SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务,SpringBoot可以离开SpringCloud独立使用开发项目， 但是SpringCloud离不开SpringBoot ，属于依赖的关系,SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

2.使用 Spring Boot 开发分布式微服务时，我们面临以下问题

1. 与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题

2. 服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务

3. 冗余-分布式系统中的冗余问题。

4. 负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。

5. 性能-问题 由于各种运营开销导致的性能问题。

6. 部署复杂性-Devops 技能的要求。

3.服务注册和发现是什么意思？Spring Cloud 如何实现？

1. 当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂.有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。

• 简单的理解就是：通过服务注册机制将启动服务的信息上传至服务注册表，服务发现机制通过服务注册表实时获取可用服务的信息

• 服务注册有自注册和第三方注册

  • 自注册：顾名思义，就是服务提供方在启动服务时自己把提供服务的IP和端口发送到注册中心，并通过心跳方式维持健康状态；服务下线时，自己把相应的数据删除。典型的像使用eureka客户端发布微服务

  • 第三方注册是指，存在一个第三方的系统负责在服务启动或停止时向注册中心增加或删除服务数据。典型的用法是devops系统或容器调度系统主动调注册中心接口注册服务

• 服务发现的意思：真正发起服务调用前，调用方需要从注册中心拿到相应服务可用的IP和端口列表，即服务发现

2. Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理

4.springcloud有哪些组件？springcloud核心组件及其作用? ======+1

1. springcloud组件：

• Eureka : 服务注册与发现

• Ribbon : 负载均衡

• Hystrix : 服务保护与熔断机制

• Feign : 声明式接口

• Zuul/Gateway : 网关

• Integration/Stream : MQ接口绑定

• Bus : 事件监听

• Sleuth+Zipkin : 分布式链路追踪

• Config : 配置中心

• 可替换组件：注册中心、配置中心：Zookeeper、Consul

2. springcloud核心组件及其作用：

• Eureka：这个服务启动时,Eureka会将服务注册到EurekaService,并且EurakeClient还可以返回过来从EurekaService拉去注册表,从而知道服务在哪里

• Feign: 基于fegin的动态代理机制,根据注解和选择机器,拼接Url地址,发起请求

• Ribbon: 服务间发起请求的时候,基于Ribbon服务做到负载均衡,从一个服务的对台机器中选择一台

• Hystrix: 发起的请求是通过Hystrix的线程池来走,不同的服走不同的线程池,实现了不同的服务调度隔离,避免服务雪崩的问题

• zull: 如果前端后端移动端调用后台系统,统一走zull网关进入,有zull网关转发请求给对应的服务

5.Spring Cloud 和dubbo区别?======被问+1

1. 服务调用方式 dubbo是RPC springcloud Rest Api

2. 注册中心,dubbo 是zookeeper springcloud是eureka，也可以是zookeeper

3. 服务网关,dubbo本身没有实现，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发,springcloud支持断路器，与git完美集成配置文件支持版本控制，事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素

6.什么是负载均衡以及负载均衡有哪几种策略？负载均衡的意义什么？

1. 负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA (高用)

2. 负载均衡的策略：

• 轮询策略：轮询选择服务器（Rabbon默认）

• 随机策略：随机选择一个服务器

• 重试策略：根据轮询的方式重试

• 权重策略：据响应时间去分配一个weight ，weight越低，被选择的可能性就越低

• 最低并发策略：选择最小请求数

• 可用过滤策略：过滤掉连接失败的服务节点，并且过滤掉高并发的服务节点，然后从健康的服务节点中，使用轮询策略选出一个节点返回

• 区域权衡策略：根据服务器的zone区域和可用性来轮询选择

• 当然，我们可以自定义策略：自定义方法代码

// 第一步：在你的启动类上级新建一个文件夹，切记，不能跟启动类同级，因为启动类里的ComponentScan注解会扫描它所在包或者子包下的所有bean注入到容器。自定义的这个配置类就会被所有的Ribbon客户端所共享，也就是我们达不到特殊化指定的目的了

// 第二步
@Configuration
public class MyRule {

    @Bean
    public IRule myRule(){
		// 默认是轮询
		// return new RoundRobinRule();
		// 切换为随机
		// return new RandomRule();
		// 自定义
        return new MyRandomRule();
    }
}


// 第三步：自定义策略（这是我从网上copy的，当个了解）
 public class MyRandomRule extends AbstractLoadBalancerRule
{
 // total = 0 // 当total==5以后，我们指针才能往下走，
 // index = 0 // 当前对外提供服务的服务器地址，
 // total需要重新置为零，但是已经达到过一个5次，我们的index = 1
 // 分析：我们5次，但是微服务只有8001 8002 8003 三台，OK？

 private int total = 0;    // 总共被调用的次数，目前要求每台被调用5次
 private int currentIndex = 0; // 当前提供服务的机器号

public Server choose(ILoadBalancer lb, Object key)
{
  if (lb == null) {
   return null;
  }
  Server server = null;
  while (server == null) {
   if (Thread.interrupted()) {
    return null;
   }

   List<Server> upList = lb.getReachableServers();
   List<Server> allList = lb.getAllServers();
   int serverCount = allList.size();
   if (serverCount == 0) {
    return null;
   }
 if(total < 5)
            {
             server = upList.get(currentIndex);
             total++;
            }else {
              total = 0;
             currentIndex++;
             if(currentIndex >= upList.size())
             {
               currentIndex = 0;
             }
            } 
 if (server == null) {
    Thread.yield();
    continue;
   }
 if (server.isAlive()) {
    return (server);
   }  
   server = null;
   Thread.yield();
   }
   return server;
   }
@Override
 public Server choose(Object key)
 {
  return choose(getLoadBalancer(), key);
 }

@Override
 public void initWithNiwsConfig(IClientConfig clientConfig)
 {
 }
 }

3. 在计算中，负载均衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载均衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载均衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载均衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程

7.什么是 Hystrix？它如何实现容错？

1. Hystrix是一个应用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等。Hystrix 能够保证在一个依赖出问题的情况下，不会导致整个体系服务失败，避免级联故障，以提高分布式系统的弹性

2. 如何实现容错！可以查看文章，后面的问题也可以查看

PS：因为目前面试遇到的问题基本没有springcloud方面的，所以该文章主要是收集上面文章的内容，目的就是统一，方便我背面试题！后续面试到的题我会加上去的！比如第四题和第五题被问到过，第五题这个上面的文章有，第四题没有，但是熟springcloud的都知道这个问题不背也肯定会

8.什么是 Hystrix 断路器？

1. Hystrix"断路器"本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控 (类似熔断保险丝) ，向调用方返回一个服务预期的，可处理的备选响应 (FallBack) ，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间。不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

9.什么是服务熔断？

1. 熔断机制是赌赢雪崩效应的一种微服务链路保护机制。

2. 当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阀值缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是：@ HystrixCommand

10.什么是服务降级？服务降级主要用于什么场景呢？

1. 服务降级是指 当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理，或换种简单的方式处理，从而释放服务器资源以保证核心业务正常运作或高效运作。说白了，就是尽可能的把系统资源让给优先级高的服务

2. 当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，可以将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用

11.服务熔断和降级的区别？

1. 服务熔断--》服务端：某个服务超时或异常，引起熔断~，类似于保险丝(自我熔断)

2. 服务降级----》客户端：从整体网站请求负载考虑，当某个服务熔断或者关闭之后，服务将不再被调用，此时在客户端，我们可以准备一个 FallBackFactory ，返回一个默认的值(缺省值)。会导致整体的服务下降，但是好歹能用，比直接挂掉强

3. 触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）

4. 实现方式不太一样，服务降级具有代码侵入性(由控制器完成/或自动降级)，熔断一般称为自我熔断

12.什么是 Spring Cloud Bus？我们需要它吗？

13.Spring Cloud断路器的作用

14.什么是SpringCloud config分布式配置中心？它能干嘛？

1. spring cloud config 为微服务架构中的微服务提供集中化的外部支持，配置服务器为各个不同微服务应用的所有环节提供了一个中心化的外部配置

2. spring cloud config 分为服务端和客户端两部分

• 服务端也称为 分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密，解密信息等访问接口

• 客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息；配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理。并且可用通过git客户端工具来方便的管理和访问配置内容

2. 它能干嘛：

• 集中式管理配置文件

• 不同环境，不同配置，动态化的配置更新，分环境部署，比如 /dev /test /prod /beta /release

• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息

• 当配置发生变动时，服务不需要重启，即可感知到配置的变化，并应用新的配置

• 将配置信息以REST接口的形式暴露

15.什么是Spring Cloud Gateway?

16.分布式事务如何处理，怎么保证事务的一致性？

17.Eureka对比和Zookeeper区别?

1. 首先了解一下CAP原则：

• C：强一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值

• A: 可用性：在一个分布式系统的集群中一部分节点故障后，该集群是否还能够正常响应客户端的读写请求

• P: 分区容错性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

2. CAP理论的核心：

• 一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求

• 根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类

  • CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差

  • CP：满足一致性，分区容错的系统，通常性能不是特别高

  • AP：满足可用性，分区容错的系统，通常可能对一致性要求低一些

3. 区别：ZooKeeper 基于 CP，不能保证高可用，Eureka 基于AP，能保证高可用。Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

PS：ZooKeeper-》CP：

• 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接收服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30-120s，且选举期间整个zookeeper集群是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zookeeper集群失去master节点是较大概率发生的事件，虽然服务最终能够恢复，但是，漫长的选举时间导致注册长期不可用，是不可容忍的。

PS：Eureka-》AP：

• Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有之中自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

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

  • Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 (即保证当前节点依然可用)

  • 当网络稳定时，当前实例新的注册信息会被同步到其他节点中