SpringCloud常见面试题

SpringCloud常见面试题

目录

1. 什么是SpringCloud？

2. SpringCloud 的优缺点？

3. SpringCloud你用过哪些组件？

4. Spring Cloud 与 Dubbo 对比

5.断路器 Hystrix

谈谈服务雪崩效应

服务雪崩效应产生的原因

什么是服务熔断?什么是服务降级?

Hystrix 实现容错机制

Hystix 主要功能

6.服务器中间件 RabbitMQ

RabbitMQ特点：

为什么使用MQ？

MQ优势

MQ劣势

说一下 rabbitmq 的延迟消息以及使用场景？

rabbitmq 持久化原理，工作原理

RabbitMQ运转流程

rabbitmq 有哪几种集群搭建方式？

MQ 能否保证消息必达，即消息的可靠性如何？

7.负载平衡 Ribbon

Ribbon 负载平衡的意义什么？

如何开启客户端负载均衡？

Ribbon是什么？

Ribbon底层实现原理

Nginx与Ribbon的区别

ribbon 负载均衡策略

8.网关 gateway

什么是网关？作用是什么？

什么是Spring Cloud Gateway（服务网关）

网关解决跨域：

自定义全局过滤：

9.注册中心 Eureka

什么是Eureka?

Eureka如何实现高可用

Eureka的自我保护模式

Eureka和ZooKeeper都可以提供服务注册与发现的功能,请说说两个的区别

10.MyCat

MyCat 的原理？

---

1. 什么是SpringCloud？

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

 

2. SpringCloud 的优缺点？

微服务的框架那么多比如：dubbo、Kubernetes，为什么就要使用 Spring Cloud 的呢？

优点：

产出于 Spring 大家族，Spring 在企业级开发框架中无人能敌，来头很大，可以保 证后续的更新、完善;组件丰富，功能齐全。Spring Cloud 为微服务架构提供了非常完整的支持。例如、 配置管理、服务发现、断路器、微服务网关等；Spring Cloud 社区活跃度很高，教程很丰富，遇到问题很容易找到解决方案;服务拆分粒度更细，耦合度比较低，有利于资源重复利用，有利于提高开发效率;可以更精准的制定优化服务方案，提高系统的可维护性;减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发;微服务可以是跨平台的，可以用任何一种语言开发;适于互联网时代，产品迭代周期更短;

缺点：

微服务过多，治理成本高，不利于维护系统;分布式系统开发的成本高（容错，分布式事务等）对团队挑战大;

 

3. SpringCloud你用过哪些组件？

Eureka：服务注册与发现

GateWay：服务网关

Ribbon：客户端负载均衡

Feign：声明性的Web服务客户端

Hystrix：断路器

Config：分布式统一配置管理

Bus：消息总线

 

4. Spring Cloud 与 Dubbo 对比

相同点：Spring Cloud 与 Dubbo 都是实现微服务有效的工具。

不同点：

Dubbo 只是实现了服务治理，而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件。注册中心,dubbo 是zookeeper， springcloud是eureka，也可以是zookeeper。Dubbo 使用 RPC 通讯协议，Spring Cloud 使用 RESTful 完成通信，Dubbo 效率略高于 Spring Cloud。

小结

微服务就是将项目的各个模块拆分为可独立运行、部署、测试的架构设计风格。Spring 公司将其他公司中微服务架构常用的组件整合起来，并使用 SpringBoot 简化其开发、配置。称为 Spring Cloud。Spring Cloud 与 Dubbo都是实现微服务有效的工具。Dubbo 性能更好，而 Spring Cloud 功能更全面。

5.断路器 Hystrix

Hystix 是 Netflix 开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败（雪崩）。

在分布式系统，我们一定会依赖各种服务，那么这些个服务一定会出现失败的情况，就会导致雪崩，Hystrix就是这样的一个工具，防雪崩利器，它具有服务降级，服务熔断，服务隔离，监控等一些防止雪崩的技术。Hystrix有四种防雪崩方式：

服务降级：接口调用失败就调用本地的方法返回一个空。服务熔断：接口调用失败就会进入调用接口提前定义好的一个熔断的方法，返回错误信息。服务隔离：隔离服务之间相互影响。服务监控：在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来。

 

谈谈服务雪崩效应

雪崩效应是在大型互联网项目中，当某个服务发生宕机时，调用这个服务的其他服务也会发生宕机，大型项目的微服务之间的调用是互通的，这样就会将服务的不可用逐步扩大到各个其他服务中，从而使整个项目的服务宕机崩溃.发生雪崩效应的原因有以下几点。

单个服务的代码存在bug。请求访问量激增导致服务发生崩溃(如大型商城的q红包，秒杀功能)。服务器的硬件故障也会导致部分服务不可用。

 

服务雪崩效应产生的原因

因为Tomcat默认情况下只有一个线程池来维护客户端发送的所有的请求，这时候某一接口在某一时刻被大量访问就会占据tomcat线程池中的所有线程，其他请求处于等待状态，无法连接到服务接口。

 

什么是服务熔断?什么是服务降级?

服务降级：当客户端请求服务器端的时候，防止客户端一直等待，不会处理业务逻辑代码，直接返回一个友好的提示给客户端。服务熔断是在服务降级的基础上更直接的一种保护方式，当在一个统计时间范围内的请求失败数量达到设定值（requestVolumeThreshold）或当前的请求错误率达到设定的错误率阈值（errorThresholdPercentage）时开启断路，之后的请求直接走fallback方法，在设定时间（sleepWindowInMilliseconds）后尝试恢复。服务隔离就是Hystrix为隔离的服务开启一个独立的线程池，这样在高并发的情况下不会影响其他服务。服务隔离有线程池和信号量两种实现方式，一般使用线程池方式。

 

Hystrix 实现容错机制

Hystrix 是一个实现了超时机制和断路模式的工具类库。 Hystrix 是由 Netflix 开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。Hystrix 主要通过以下几点实现延迟和容错。

1 包裹请求：使用 HystrixCommand 包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。

2 跳闸机制：当某服务的错误率超过一定的阈值时，Hystrix 可以自动或手动跳闸，停止请求该服务一段时间。

3 资源隔离：Hystrix 为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等待，从而加速失败判定。

4 监控：Hystrix 可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等。

5 回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑由开发人员自行提供，例如返回一个缺省值。

6 自我修复：断路器打开一段时间后，会自动进入“半开”状态。

 

Hystix 主要功能

隔离

1.线程池隔离

2.信号量隔离

降级：异常，超时

熔断

限流

6.服务器中间件 RabbitMQ

RabbitMQ 是使用 Erlang 编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了 Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

RabbitMQ特点：

使用简单，功能强大。基于AMQP协议。 跨语言 c node.js->mq->java python c#社区活跃，文档完善。
高并发性能好，这主要得益于Erlang语言。 c 底层语言，性能强。java 好开发。构建一个web 。
Spring Boot默认已集成RabbitMQ

 

为什么使用MQ？

在项目中，可将一些无需即时返回且耗时的 *** 作提取出来，进行异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。

MQ优势

1、应用程序解耦

MQ相当于一个中介，生产方通过MQ与消费方交互，它将应用程序进行解耦合。

2、任务异步处理

将不需要同步处理的并且耗时长的 *** 作由消息队列通知消息接收方进行异步处理。提高了应用程序的响应时间。

3、削峰填谷

如订单系统，在下单的时候就会往数据库写数据。但是数据库只能支撑每秒1000左右的并发写入，并发量再高就容易宕机。低峰期的时候并发也就100多个，但是在高峰期时候，并发量会突然激增到5000以上，这个时候数据库肯定卡死了。

消息被MQ保存起来了，然后系统就可以按照自己的消费能力来消费，比如每秒1000个数据，这样慢慢写入数据库，这样就不会卡死数据库了。

但是使用了MQ之后，限制消费消息的速度为1000，但是这样一来，高峰期产生的数据势必会被积压在MQ中，高峰就被“削”掉了。但是因为消息积压，在高峰期过后的一段时间内，消费消息的速度还是会维持在1000QPS，直到消费完积压的消息,这就叫做“填谷”。

 

MQ劣势

系统可用性降低

系统引入的外部依赖越多，系统稳定性越差。一旦 MQ 宕机，就会对业务造成影响。如何保证MQ的高可用？

系统复杂度提高

MQ 的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过 MQ 进行异步调用。如何 保证消息没有被重复消费？怎么处理消息丢失情况？那么保证消息传递的顺序性？

一致性问题

A 系统处理完业务，通过 MQ 给B、C、D三个系统发消息数据，如果 B 系统、C 系统处理成功，D 系统处理 失败。如何保证消息数据处理的一致性。

 

说一下 rabbitmq 的延迟消息以及使用场景？

使用RabbitMQ来实现延迟消息必须先了解RabbitMQ的两个概念：消息的TTL和死信 Exchange，通过这两者的组合来实现。

消息的TTL 消息的TTL就是消息的存活时间。RabbitMQ可以对队列和消息分别设置TTL。对队列设置就是队列没有消费者连着的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间，我们认为这个消息就死了，称之为死信。 死信交换器 一个消息在满足如下条件下，会进死信路由，记住这里是路由而不是队列，一个路由可以对应很多队列。

（1） 一个消息被Consumer拒收了，并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。

（2）上面的消息的TTL到了，消息过期了。

（3）队列的长度限制满了。排在前面的消息会被丢弃或者扔到死信路由上。Dead Letter Exchange其实就是一种普通的exchange，和创建其他exchange没有两样。只是在某一个设置Dead Letter Exchange的队列中有消息过期了，会自动触发消息的转发，发送到Dead Letter Exchange中去。 我们可以使用延迟消息来实现超时未支付订单的处理。

 

rabbitmq 持久化原理，工作原理

生产者发消息到rabbitmq的exchange

一个消费者监听“一个” “队列”

Broker：消息队列服务进程，此进程包括两个部分：Exchange和Queue。Exchange：消息队列交换机，按一定的规则将消息路由转发到某个队列，对消息进行过滤。Queue：消息队列，存储消息的队列，消息到达队列并转发给指定的消费方。Producer：消息生产者，即生产方客户端，生产方客户端将消息发送到MQ。Consumer：消息消费者，即消费方客户端，接收MQ转发的消息。

消息发布接收流程：

-----发送消息-----

1、生产者和Broker建立TCP连接。

2、生产者和Broker建立通道。

3、生产者通过通道消息发送给Broker，由Exchange将消息进行转发。

4、Exchange将消息转发到指定的Queue（队列）

----接收消息-----

1、消费者和Broker建立TCP连接

2、消费者和Broker建立通道

3、消费者监听指定的Queue（队列）

4、当有消息到达Queue时Broker默认将消息推送给消费者。

5、消费者接收到消息。

 

RabbitMQ运转流程

生产者发送消息

生产者创建连接（Connection），开启一个信道（Channel），连接到RabbitMQ Broker；声明队列并设置属性；如是否排它，是否持久化，是否自动删除；将路由键（空字符串）与队列绑定起来；发送消息至RabbitMQ Broker；关闭信道；关闭连接；

消费者接收消息

消费者创建连接（Connection），开启一个信道（Channel），连接到RabbitMQ Broker向Broker 请求消费相应队列中的消息，设置相应的回调函数；等待Broker回应闭关投递响应队列中的消息，消费者接收消息；确认（ack，自动确认）接收到的消息；RabbitMQ从队列中删除相应已经被确认的消息；关闭信道；关闭连接；

 

rabbitmq 有哪几种集群搭建方式？

我们这里给大家介绍RabbitMQ集群的四种模式

 主备模式

也称为 Warren (兔子窝) 模式。实现 rabbitMQ 的高可用集群，一般在并发和数据量不高的情况下，这种模式非常的好用且简单。也就是一个主/备方案，主节点提供读写，备用节点不提供读写。如果主节点挂了，就切换到备用节点，原来的备用节点升级为主节点提供读写服务，当原来的主节点恢复运行后，原来的主节点就变成备用节点。可以一主多备。

 远程模式

远程模式简称 shovel 模式，所谓的 shovel 就是把消息进行不同数据中心的复制工作，可以跨地域的让两个 MQ 集群互联，远距离通信和复制。有两个异地的 MQ 集群（可以是更多的集群），当用户在地区 1 这里下单了，系统发消息到 1 区的 MQ 服务器，发现 MQ 服务已超过设定的阈值，负载过高，这条消息就会被转到 地区 2 的 MQ 服务器上，由 2 区的去执行后面的业务逻辑，相当于分摊我们的服务压力。 镜像模式

非常经典的 mirror 镜像模式，保证 100% 数据不丢失。在实际工作中也是用得最多的，并且实现非常的简单，一般互联网大厂都会构建这种镜像集群模式。mirror 镜像队列，目的是为了保证 rabbitMQ 数据的高可靠性解决方案，主要就是实现数据的同步，一般来讲是 2 - 3 个节点实现数据同步。对于 100% 数据可靠性解决方案，一般是采用 3 个节点。

 多活模式

也是实现异地数据复制的主流模式，因为 shovel 模式配置比较复杂，所以一般来说，实现异地集群的都是采用这种双活 或者 多活模型来实现的。这种模式需要依赖 rabbitMQ的 federation 插件，可以实现持续的，可靠的 AMQP 数据通信，多活模式在实际配置与应用非常的简单。

 

MQ 能否保证消息必达，即消息的可靠性如何？

为了降低消息丢失的概率，MQ 需要进行超时和重传

(1) MQ-client-sender 发送消息给 MQ-server

(2) MQ-server 接收到消息后，发送 ACK 消息给发送方

(3) MQ-client-sender 接收到 ACK 消息后，则 消息已经投递成功 如果上述 2 消息丢失或者超时，MQ-client-sender 内的 timer 会重发消息，直到收到 ACK消息，如果重试 N 次后还未收到，则回调发送失败。需要注意的是，这个过程中 MQ-server可能会收到同一条消息的多次重发。

7.负载平衡 Ribbon Ribbon 负载平衡的意义什么？

简单来说： 先将集群，集群就是把一个的事情交给多个人去做，假如要做1000个产品给一个人做要10天，我叫10个人做就是一天，这就是集群，负载均衡的话就是用来控制集群，他把做的最多的人让他慢慢做休息会，把做的最少的人让他加量让他做多点。在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。 如何开启客户端负载均衡？

@LoadBalanced

 

Ribbon是什么？

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

Ribbon使用discoveryClient从注册中心读取目标服务信息，对同一接口请求进行计数，使用%取余算法获取目标服务集群索引，返回获取到的目标服务信息。

 

Nginx与Ribbon的区别

Nginx是反向代理同时可以实现负载均衡，nginx拦截客户端请求采用负载均衡策略根据upstream配置进行转发，相当于请求通过nginx服务器进行转发。Ribbon是客户端负载均衡，从注册中心读取目标服务器信息，然后客户端采用轮询策略对服务直接访问，全程在客户端 *** 作。

 

ribbon 负载均衡策略

RoundRobinRule 简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。AvailabilityFilteringRule 对以下两种服务器进行忽略：

（1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。注意：可以通过修改配置loadbalancer..connectionFailureCountThreshold来修改连接失败多少次之后被设置为短路状态。默认是3次。

（2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上线，可以由客户端的..ActiveConnectionsLimit属性进行配置。

WeightedResponseTimeRule 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。RandomRule 随机选择一个可用的服务器。BestAvailableRule 忽略哪些短路的服务器，并选择并发数较低的服务器。

8.网关 gateway 什么是网关？作用是什么？

网关相当于一个网络服务架构的入口，所有网络请求必须通过网关转发到具体的服务。

统一管理微服务请求，权限控制、负载均衡、路由转发、监控、安全控制黑名单和白名单等。

 

什么是Spring Cloud Gateway（服务网关）

Spring Cloud Gateway旨在为微服务架构提供简单、有效和统一的API路由管理方式，Spring Cloud Gateway作为Spring Cloud生态系统中的网关，目标是替代Netflix Zuul，网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。(路由和过滤)。

网关解决跨域：

在application.yml里配置：

cloud:
    gateway:
      globalcors:
        cors-configurations:

          '[/**]': # 匹配所有请求
            allowedOrigins: "*" #跨域处理 允许所有的域

            allowedMethods: # 支持的方法
            - GET
            - POST
            - PUT
            - DELETE

 

自定义全局过滤：

定义接口实现GlobalFilter, Ordered，通过

@Component
public class MyFilter implements GlobalFilter, Ordered{

   @Override
   public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) {
       return chain.filter(exchange);//放行
   }

    //过滤器排序
    //@return 数值越小 越先执行
   @Override
   public int getOrder() {
       return 0;
   }
}

9.注册中心 Eureka 什么是Eureka?

Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址提供者：启动后向 Eureka 注册自己信息（地址，提供什么服务）消费者：向 Eureka 订阅服务，Eureka 会将对应服务的所有提供者地址列表发送给消费者，并且定期更新心跳(续约)：提供者定期通过 http 方式向 Eureka 刷新自己的状态

 

Eureka如何实现高可用

准备多个Eureka Server 进行配置；把SpringCloud服务分别相互注册；Eureka Client 分别注册到这两个 Eureka Server中，按照Eureka的顺序来访问。

 

Eureka的自我保护模式

默认情况下，如果Eureka Service在一定时间内没有接收到某个微服务的心跳，Eureka Service会进入自我保护模式，在该模式下Eureka Service会保护服务注册表中的信息，不在删除注册表中的数据，当网络故障恢复后，Eureka Servic 节点会自动退出自我保护模式。

 

Eureka和ZooKeeper都可以提供服务注册与发现的功能,请说说两个的区别

ZooKeeper中的节点服务挂了就要选举。 在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的，选举就是该微服务做了集群，必须有一台主其他的都是从。Eureka各个节点是平等关系,服务器挂了没关系，只要有一台Eureka就可以保证服务可用，数据都是最新的。 如果查询到的数据并不是最新的，就是因为Eureka的自我保护模式导致的。Eureka本质上是一个工程,而ZooKeeper只是一个进程。Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper 一样使得整个注册系统瘫痪。ZooKeeper保证的是CP，Eureka保证的是AP
CAP理论：

C：一致性>Consistency; 取舍：(强一致性、单调一致性、会话一致性、最终一致性、弱一致性)

A：可用性>Availability;

P：分区容错性>Partition tolerance;

10.MyCat

MyCat 是一个开源的分布式数据库系统，是一个实现了 MySQL 协议的服务器。但是因为数据库一般都有自己的数据库引擎，而 Mycat 并没有属于自己的独有数据库引擎，所有严格意义上说并不能算是一个完整的数据库系统，只能说是一个在应用和数据库之间起桥梁作用的中间件。

 

MyCat 的原理？

MyCat 技术原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的 SQL 语句，首先 对 SQL 语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然 后将此 SQL 发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。