Java面试题【必知必会】SpringCloud常见面试题（2024）

近期一直在准备面试，所以为了巩固知识，也为了梳理，整理了一些java的基础面试题！同时也希望各位英雄和女侠能够补充！不胜荣幸！！！

名称	地址
Java面试题【必知必会】基础（2024）	Go-Go-Go
Java面试题【必知必会】常见基础题（2024）	Go-Go-Go
Java面试题【必知必会】MySQL常见面试题（2024）	Go-Go-Go
Java面试题【必知必会】Spring常见面试题（2024）	Go-Go-Go
Java面试题【必知必会】Mybatis常见面试题（2024）	Go-Go-Go
Java面试题【必知必会】SpringMVC常见面试题（2024）	Go-Go-Go
Java面试题【必知必会】SpringBoot常见面试题（2024）	Go-Go-Go
Java面试题【必知必会】SpringCloud常见面试题（2024）	Go-Go-Go
Java面试题【必知必会】Redis常见面试题（2024）	Go-Go-Go
Java面试题【必知必会】Linux常用命令面试题（2024）	Go-Go-Go

1.SpringBoot和SpringCloud的区别？

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

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

与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题
服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务
冗余-分布式系统中的冗余问题。
负载平衡 ---负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。
性能-问题由于各种运营开销导致的性能问题。
部署复杂性-Devops 技能的要求。

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

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

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

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

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

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

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

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

springcloud组件：

Eureka : 服务注册与发现
Ribbon : 负载均衡
Hystrix : 服务保护与熔断机制
Feign : 声明式接口
Zuul/Gateway : 网关
Integration/Stream : MQ接口绑定
Bus : 事件监听
Sleuth+Zipkin : 分布式链路追踪
Config : 配置中心
可替换组件：注册中心、配置中心：Zookeeper、Consul

springcloud核心组件及其作用：

Eureka：这个服务启动时,Eureka会将服务注册到EurekaService,并且EurakeClient还可以返回过来从EurekaService拉去注册表,从而知道服务在哪里
Feign: 基于fegin的动态代理机制,根据注解和选择机器,拼接Url地址,发起请求
Ribbon: 服务间发起请求的时候,基于Ribbon服务做到负载均衡,从一个服务的对台机器中选择一台
Hystrix: 发起的请求是通过Hystrix的线程池来走,不同的服走不同的线程池,实现了不同的服务调度隔离,避免服务雪崩的问题
zull: 如果前端后端移动端调用后台系统,统一走zull网关进入,有zull网关转发请求给对应的服务
config 提供的一个分布式配置中心，用于集中管理和存储分布式系统和微服务架构中的配置信息。它可以帮助开发者将应用的配置信息独立于应用本身进行管理，实现配置的集中化管理、版本管理、动态刷新等功能

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

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

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

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

轮询策略：轮询选择服务器（Rabbon默认）
随机策略：随机选择一个服务器
重试策略：根据轮询的方式重试
权重策略：据响应时间去分配一个weight ，weight越低，被选择的可能性就越低
最低并发策略：选择最小请求数
可用过滤策略：过滤掉连接失败的服务节点，并且过滤掉高并发的服务节点，然后从健康的服务节点中，使用轮询策略选出一个节点返回
区域权衡策略：根据服务器的zone区域和可用性来轮询选择
当然，我们可以自定义策略：自定义方法代码

java 复制代码

// 第一步：在你的启动类上级新建一个文件夹，切记，不能跟启动类同级，因为启动类里的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)
 {
 }
 }

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

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

Hystrix 是 Netflix 开源的一种容错框架，用于处理分布式系统中的故障和延迟问题。它实现了断路器模式，可以在出现故障时快速地将请求转发到预定的备用服务，避免故障在系统中蔓延，从而提高系统的稳定性和可靠性。

Hystrix 的主要特点和实现容错的方式包括：

断路器机制：Hystrix 实现了断路器模式，当请求失败率或错误率超过设定的阈值时，断路器会触发开启断路器状态，并执行预设的降级逻辑。在一段时间后，断路器会尝试重新闭合，重新允许请求通过，以检查后端服务是否已经恢复正常。
超时机制：Hystrix 为每个服务调用设置了一个超时时间，当服务调用时间超过设定的时间时，Hystrix 会中断该请求，并执行预设的降级逻辑，避免长时间的阻塞。
资源隔离：Hystrix 使用线程池对不同的服务进行隔离，避免某个服务的故障影响到其他服务，保持系统的稳定性。
服务降级：Hystrix 可以根据配置设置，在后端服务发生故障或超时时，返回一个备用的、预设的响应，而不是抛出异常或无限等待。这样，前端服务或客户端可以继续得到响应，不会受到后端服务故障的影响。
故障快速失败：Hystrix 使用快速失败机制，可以立即快速失败并返回预设的响应，而不是让请求在后端服务上无限等待。这样可以快速释放资源，避免系统资源的浪费。
监控和指标收集：Hystrix 提供了实时的监控和指标收集功能，可以通过 Hystrix Dashboard 或者其他监控系统查看断路器的状态、故障率、请求量等信息，便于系统运维和故障排查。

PS：通过这些机制，Hystrix 可以防止故障在系统中蔓延，保持系统的稳定性和可靠性，同时提供了强大的监控和管理功能，帮助开发者更好地理解和掌控系统的状态。在分布式系统和微服务架构中，Hystrix 是构建健壮系统的重要组件之一。

8.什么是 Hystrix 断路器？

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

9.什么是服务熔断？

熔断机制是一种容错机制，用于保护分布式系统中的服务免受故障的影响
服务熔断的主要目的是防止故障在系统中蔓延，保护系统的稳定性和可用性。它通过监控服务的请求和响应，当服务出现故障或不可用时，熔断器会打开，拒绝新的请求，并执行预设的降级逻辑，而不是将请求转发给出现故障的服务。熔断器会在一段时间后尝试重新闭合，允许部分请求通过以检查后端服务是否已经恢复正常。熔断机制的注解是：@ HystrixCommand

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

服务降级是一种容错机制，在分布式系统和微服务架构中使用。当后端服务出现故障、性能下降或超时等问题时，服务降级会暂时屏蔽一些不重要的功能或是返回预设的默认值，保证系统的基本可用性，从而避免整个系统的崩溃或性能下降。
服务降级的主要目的是在出现故障或异常情况时，通过舍弃某些功能或改变服务行为，保证核心功能的可用性，并尽量保持系统的稳定性和可靠性。

服务降级的主要应用场景包括：

后端服务故障或超时：当后端服务发生故障、性能下降或请求超时时，服务降级可以返回一个备用的响应，避免让前端服务或客户端等待过长时间或发生异常。
高并发情况下的请求处理：在高并发情况下，服务可能会面临过多的请求，如果无法及时响应，服务降级可以返回一个简单的响应，保证基本的服务可用性。
第三方服务故障：当系统依赖于第三方服务，并且第三方服务出现故障时，服务降级可以采用备用方案或返回缓存数据，避免系统因第三方服务故障而不可用。
流量控制：在系统资源有限或负载过大的情况下，服务降级可以限制并控制流量，确保系统不会被过多的请求压垮。
避免级联故障：服务降级可以防止故障在系统中蔓延，保持整个系统的稳定性，避免级联故障导致整个系统崩溃。

PS：总的来说，服务降级是一种应对不可预知情况的安全措施，它可以在出现异常或故障时采取预设的措施，保证系统的可用性和稳定性，提供更好的用户体验。在复杂的分布式系统中，服务降级是构建健壮系统的一部分，对于保障系统的稳定性和可靠性非常重要。

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

服务熔断（Circuit Breaking）：

熔断是一种保护机制，用于防止故障在系统中蔓延，保护系统免受故障的影响。
当后端服务发生故障或不可用时，熔断会暂时关闭对该服务的访问，拒绝新的请求，并执行预设的降级逻辑。
熔断器会在一段时间后尝试重新闭合，允许部分请求通过以检查后端服务是否已经恢复正常。
目的是快速失败并保护系统不受故障影响，同时避免向不可用的服务发送大量的请求。

服务降级（Service Degradation）：

降级是一种从性能角度考虑的处理策略，用于保证核心功能的可用性，并尽量保持系统的稳定性和可靠性。
当系统出现异常或高负载时，服务降级会暂时屏蔽一些不重要的功能或改变服务行为，例如返回预设的默认值或简化响应。
降级是一种应对不可预知情况的安全措施，通过舍弃一些功能来保障系统的基本可用性。
目的是保障核心功能的可用性，并尽量保持系统的稳定性，以避免整个系统的崩溃或性能下降。

PS：总的来说，服务熔断和服务降级都是在分布式系统中处理容错的重要策略。服务熔断主要用于防止故障在系统中蔓延，快速失败并保护系统不受故障影响；而服务降级主要用于保证核心功能的可用性，并尽量保持系统的稳定性，以避免整个系统的崩溃或性能下降。两者可以结合使用，帮助构建健壮和高可用的分布式系统。

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

Spring Cloud Bus 是 Spring Cloud 提供的一个组件，用于在分布式系统中传播状态变化和事件消息。它基于消息代理（如 RabbitMQ 或 Kafka）实现，可以将状态变化的消息广播到所有连接到消息代理的微服务实例，从而实现微服务之间的消息传递和通信。

Spring Cloud Bus 主要有两个核心概念：

消息代理：Spring Cloud Bus 使用消息代理作为消息传递的中间件。常见的消息代理有 RabbitMQ 和 Kafka。消息代理负责接收、存储和转发消息，使得消息能够在微服务之间传递。
事件和消息：Spring Cloud Bus 使用事件和消息来传播状态变化和配置更新。当配置中心的配置发生变化时，或者其他需要传播的事件发生时，Spring Cloud Bus 会将消息广播到所有连接到消息代理的微服务实例，这些微服务实例会接收到消息并执行相应的处理。

Spring Cloud Bus 的好处在于，它可以减少微服务之间的耦合，并提供了一种简单的方式来在分布式系统中传播事件和状态变化。例如，当配置中心的配置发生变化时，不需要每个微服务都主动轮询配置中心来获取更新，而是通过 Spring Cloud Bus 将配置更新消息广播到所有微服务，从而实现统一的配置更新。

需要 Spring Cloud Bus 的情况取决于项目的具体需求。在以下情况下，使用 Spring Cloud Bus 可能是一个不错的选择：

配置更新广播：如果你的项目使用了 Spring Cloud Config Server 来管理配置，并且需要实时将配置更新广播到所有微服务，那么可以考虑使用 Spring Cloud Bus。
需要消息驱动：如果你的项目需要实现消息驱动微服务架构，即微服务之间通过消息来通信和传递状态变化，那么可以考虑使用 Spring Cloud Bus 结合消息代理实现。
事件传播：如果你需要将事件或状态变化传播到多个微服务实例，那么 Spring Cloud Bus 可以帮助简化事件传播的过程。

如果你的项目不需要上述功能或者只是一个简单的微服务架构，可能并不需要引入 Spring Cloud Bus。它并不是必需的组件，只有在特定的场景下才会为你带来便利。在决定是否使用 Spring Cloud Bus 时，建议根据项目需求来评估是否需要这个组件。

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

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

服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密，解密信息等访问接口
客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息；配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理。并且可用通过git客户端工具来方便的管理和访问配置内容

它能干嘛：

集中式管理配置文件
不同环境，不同配置，动态化的配置更新，分环境部署，比如 /dev /test /prod /beta /release
运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息
当配置发生变动时，服务不需要重启，即可感知到配置的变化，并应用新的配置
将配置信息以REST接口的形式暴露

14.什么是Spring Cloud Gateway?

Spring Cloud Gateway 是一个基于 Spring Framework 5、Spring Boot 2 和 Project Reactor 等技术构建的轻量级、高性能、可扩展的网关服务。它是 Spring Cloud 生态系统中的一部分，用于构建和管理微服务架构中的 API 网关。

路由和代理： Spring Cloud Gateway 可以根据路由规则将传入的请求转发到不同的微服务实例。它支持动态路由，可以根据服务的运行状态和配置信息自动进行路由。
请求过滤：可以通过预定义的过滤器或自定义过滤器来处理请求，如身份验证、鉴权、日志记录等。
负载均衡： Spring Cloud Gateway 集成了负载均衡的功能，可以根据负载均衡策略将请求分发到多个服务实例。
熔断和降级：提供了熔断器和降级的支持，可以在服务不可用或超时时进行自动切换和处理。
限流：可以配置请求的限流策略，防止某个服务被过多的请求拖垮。
请求重写：可以修改请求的路径、参数、头部等信息，以适应后端服务的要求。
集成 Spring Cloud Discovery：可以与 Spring Cloud 的服务注册与发现组件集成，自动获取服务的地址信息。

PS：Spring Cloud Gateway 的设计理念是轻量级和灵活性，它使用了 Project Reactor 来实现非阻塞的异步编程模型，以便在高负载情况下保持高性能。它还提供了丰富的扩展机制，允许开发人员自定义路由、过滤器等行为。

总之，Spring Cloud Gateway 是一个强大的 API 网关，可以帮助开发人员构建和管理微服务架构中的请求路由、负载均衡、安全认证等功能，从而更好地管理和维护分布式系统。

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

两阶段提交（Two-Phase Commit，2PC）：2PC 是一种经典的分布式事务处理协议。它包含两个阶段：准备阶段和提交阶段。在准备阶段，事务协调者（通常是一个中心化的组件）会向所有参与者（即各个分布式服务）发送准备请求，要求各个参与者准备好提交或回滚事务。只有当所有参与者都准备好时，事务协调者才会向各个参与者发送提交请求。这种方式可以保证所有参与者要么都提交事务，要么都回滚事务，从而保证事务的一致性。但是，2PC 有一定的性能和可用性问题，因为需要在整个事务过程中保持所有参与者的状态，同时事务协调者可能成为单点故障。
补偿事务（Compensating Transaction）：补偿事务是一种基于补偿机制的分布式事务处理方式。在补偿事务中，每个分布式服务在执行事务之前，先执行一个补偿操作，用于撤销该事务的效果。当事务失败时，系统可以通过执行补偿操作来回滚之前的操作，从而保证事务的一致性。补偿事务可以灵活地适应各种异常情况，但是需要开发者额外编写补偿逻辑，增加了系统的复杂性。
消息队列：使用消息队列可以实现异步处理分布式事务。当需要进行跨多个服务的事务操作时，将事务操作转换为消息发送到消息队列，然后由消息消费者（各个分布式服务）异步处理事务。这样可以减少事务的锁竞争，提高系统的性能和可扩展性。消息队列通常提供消息的持久化机制，确保消息不会丢失，从而保证事务的一致性。

PS：以上是处理分布式事务的几种常见方式，每种方式都有其优劣和适用场景。在实际应用中，需要根据系统的特点、业务需求和性能要求来选择合适的处理方式。同时，也可以采用分布式事务管理框架，如 Atomikos、Seata 等，来简化分布式事务的处理。

16.Eureka对比和Zookeeper区别?

首先了解一下CAP原则：

C：强一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值
A: 可用性：在一个分布式系统的集群中一部分节点故障后，该集群是否还能够正常响应客户端的读写请求
P: 分区容错性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

CAP理论的核心：

一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求
根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类
CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
CP：满足一致性，分区容错的系统，通常性能不是特别高
AP：满足可用性，分区容错的系统，通常可能对一致性要求低一些

区别：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仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 (即保证当前节点依然可用)
当网络稳定时，当前实例新的注册信息会被同步到其他节点中