SpringCloud常见面试题（一）：SpringCloud 5大组件，服务注册和发现，nacos与eureka区别，服务雪崩、服务熔断、服务降级，微服务监控

Spring Cloud

一、Spring Cloud 5大组件有哪些

【基础的内容考察 ——回答原则：简单的问题不能答错（一道面试题就能淘汰一个人），新手和老手都要注意】

• Eureka ：注册中心
• Ribbon ：负载均衡
• Feign ：远程调用
• Hystrix ：服务熔断
• Zuul/Gateway ：网关

随着SpringCloudAlibba在国内兴起 , 我们项目中使用了一些阿里巴巴的组件

• 注册中心/配置中心 Nacos
• 负载均衡 Ribbon
• 服务调用 Feign
• 服务保护 sentinel
• 服务网关 Gateway

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

• 微服务中必须要使用的组件，考察我们使用微服务的程度
• 注册中心的核心作用是：服务注册和发现
• 常见的注册中心：eureka、nocas、zookeeper

我做过的哪个微服务项目，使用了哪个注册中心

2.1 Eureka的作用

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

• 我们当时项目采用的eureka作为注册中心，这个也是spring cloud体系中的一个核心组件
• 服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
• 服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
• 服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除

2.3 Nacos的工作流程

2.4 我看你之前也用过nacos、你能说下nacos与eureka的区别？

• 简历上有体现
• 面试官比较熟悉nacos和eureka

nacos与eureka的区别

• Nacos与eureka的共同点（注册中心）
  • 都支持服务注册和服务拉取
  • 都支持服务提供者心跳方式做健康检测
• Nacos与Eureka的区别（注册中心）
  • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
  • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
  • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
• Nacos还支持了配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因

三、你们项目负载均衡如何实现的

• 负载均衡 Ribbon，发起远程调用feign就会使用Ribbon
• Ribbon负载均衡策略有哪些？
• 如果想自定义负载均衡策略如何实现？

3.1 Ribbon负载均衡流程

3.2 Ribbon负载均衡策略有哪些 ?

• RoundRobinRule：简单轮询服务列表来选择服务器
• WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
• RandomRule：随机选择一个可用的服务器
• BestAvailableRule：忽略那些短路的服务器，并选择并发数较低的服务器
• RetryRule：重试机制的选择逻辑
• AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的，再选择连接数较小的实例
• ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询

3.3 如果想自定义负载均衡策略如何实现 ?

可以自己创建类实现IRule接口 , 然后再通过配置类或者配置文件配置即可 ，通过定义IRule实现可以修改负载均衡规则，有两种方式：

总结

（1）你们项目负载均衡如何实现的

微服务的负载均衡主要使用了一个组件Ribbon，比如，我们在使用feign远程调用的过程中，底层的负载均衡就是使用了ribbon

（2）Ribbon负载均衡策略有哪些 ?

• RoundRobinRule：简单轮询服务列表来选择服务器
• WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
• RandomRule：随机选择一个可用的服务器
• ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)

（3）如果想自定义负载均衡策略如何实现

提供了两种方式：

• 创建类实现IRule接口，可以指定负载均衡策略（全局）
• 在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略（局部）

四、什么是服务雪崩，怎么解决这个问题？

• 什么是服务雪崩？
• 熔断降级（解决） Hystix服务熔断降级
• 限流（预防）

在微服务的项目中，Spring Cloud进行接口调用时，一般是需要使用Feign进行接口调用，如果某个接口或者服务出现了请求错误或者服务故障，很有可能导致服务雪崩的问题，导致整个系统服务不可用。服务雪崩解决方案中主要有服务降级和服务熔断两个方式

4.1 服务雪崩

服务雪崩：一个服务失败，导致整条链路的服务都失败的情形。

在微服务之间进行通信服务调用由于某一个服务故障，导致级联服务故障的现象叫做雪崩效应。雪崩效应描述的是提供方不可用，导致消费方不可用并将不可用逐渐放大的过程。

比如有三个服务：用户服务调用商品服务，商品服务调用库存服务，调用关系如下图：

如果有一时刻用户服务的流量波动很大，流量经常会突然性增加，那么在这种情况下，就算用户服务能够扛着请求，但是商品服务或者库存服务也未必能够扛住这突发性的海量请求。这时候库存服务很可能因为扛不住请求，而变得不可用，那么商品服务的请求也会变得阻塞，慢慢耗尽商品服务的线程资源，这时候商品服务也会变得不可用了，同理会导致用户服务也变得不可用。

所以服务雪崩产生的根本原因是在调用链路中链路的某一个服务因为执行业务时间过长，或者大规模出现异常导致自身服务不可用，并且将这种不可用进行放大的情况。就像雪崩一样，雪崩的出现往往是因为山顶的一刻雪球的滚动，从而导致不断的放大，从而导致的雪崩的出现。

如果系统没有设计处理好，服务雪崩是微服务中很容易出现的情况，从而会导致整个系统的不可用性，造成难以估量的损失，那么如何解决微服务中如何解决服务雪崩的问题呢？

主要的解决方案有服务降级和服务熔断！

4.2 服务降级

服务降级是服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃。

服务压力剧增的时候根据当前业务的情况以及流量 对一些服务和页面进行策略的降级，以此来缓解服务器的压力，保证核心任务的进行，同时保证部分甚至大部分服务能够得到正确的响应，也就是当前请求处理不了了或者出错了， 给一个默认的返回。可以理解为牺牲小我，成就大我，即当网站服务的流量突然激增的时候，为了保证系统核心服务的正常进行，有策略地关闭微服务中某些小的边缘性的服务，从而保证系统核心服务的正常进行。降级的核心思想就是丢车保帅，优先保证核心业务

比如在双11的时候，为了保证下订单、付款、添加购物车等这些核心功能的正常，可能会牺牲一些确认收货、评价、删除订单等这些不是很核心、很紧急的服务，这些服务可以在以后网站的流量并不是很大的时候恢复对于系统的正常运行没有影响，往往这时候可能比如评价的时候会提示系统繁忙，请稍后再试等等。

如果降级太多，则会触发熔断机制

4.3 服务熔断

Hystrix 熔断机制，用于监控微服务调用情况， 默认是关闭的，如果需要开启需要在引导类上添加注解：@EnableCircuitBreaker

如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求

熔断器其实可以理解为类似于电表的保险丝，一旦某个时刻电压过载，那么保险丝就熔断了，跳闸；反之整个电路因为电力过载而烧掉，起火等灾难的出现。

这里的服务熔断指的就是当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。主要是用来在微服务系统中防止出现服务雪崩现象的。

微服务中的熔断器一般主要使用的Hystrix熔断器组件。熔断器本身是一种开关装置，当某个服务单元发生故障之后，通过熔断器Hystrix的故障监控，某个异常条件被触发，直接熔断整个服务，向调用方法返回一个符合预期的并且可以处理的备选响应，而不是长时间的等待或者抛出无法处理异常，就保证了服务调用方的线程不会长时间占用，避免故障在级联链路系统中的蔓延、扩大、直至产生服务的雪崩，并且如果目标服务转好，则恢复调用，服务熔断是解决服务雪崩的重要手段之一。

使用熔断器首先就需要在自己所有的微服务中引用Hystrix熔断器组件，一旦引用了Hystrix熔断器组件，并开启熔断器，那么就具有了服务的熔断功能。

服务熔断一般采用断路器模式。当某个服务被调用时，断路器就会监控这个调用，如果调用的时间太长，断路器将会介入并中断调用。此外，断路器将监视所有对远程资源的调用，如对某一个远程资源的调用失败次数足够多（默认是10s内20次请求调用失败或者10s内超过50%的请求失败），那么断路器会出现并采取快速失败，阻止将来调用此远程资源的请求。

总结

（1）什么是服务雪崩，怎么解决这个问题？

• 服务雪崩：一个服务失败，导致整条链路的服务都失败的情形
• 服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑
• 服务熔断：默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求

（2）熔断和降级的区别

• 区别
  • 熔断和降级触发的原因不一样，服务熔断一般是某个服务的故障引起的，而服务降级则是从整体的负荷考虑的；
  • 它们管理目标的层次不一样，熔断其实是一个框架级的处理，每个微服务都需要。而降级一般需要对业务进行层级区分，即核心服务、边缘服务，一般从外围的边缘服务开始进行降级。
• 共同点
  • 它们的目的一致，都是从系统的可用性和可靠性的角度考虑，为了防止整个系统的反应缓慢或者崩溃，而采用的策略。
  • 它们达到的目的都是某些服务不可用或者不可达，但是整体核心功能正常。
  • 它们的粒度一致，都是服务级别的，即影响的是服务。
  • 自治性要求高，熔断模式一般是由服务基于策略地自动触发，降级虽然可以人为处理，但是在微服务的架构下，完全依靠人为显然不可行，所以需要进行开关预设、配置中心。

服务熔断可以理解为服务降级的一种，因为熔断必然会触发降级，区别就是熔断在于对调用链路的保护，降级是对整个系统过载的一种保护。

五、你们的微服务是怎么监控的？为什么需要监控

5.1 为什么需要监控微服务

• 问题定位
• 性能分析
• 服务关系
• 服务告警

5.2 如何监控微服务

四种方法

• Springboot-admin
• prometheus+Grafana
• zipkin
• skywalking

后两者是链路追踪工具。

5.3 skywalking

一个分布式系统的应用程序性能监控工具（ Application Performance Managment ），提供了完善的链路追踪能力， apache的顶级项目（前华为产品经理吴晟主导开源）

• 服务（service）：业务资源应用系统（微服务）
• 端点（endpoint）：应用系统对外暴露的功能接口（接口）
• 实例（instance）：物理机

总结：

你们的微服务是怎么监控的？

我们项目中采用的skywalking进行监控的

• skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。
• 我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复

六、总结

1）Spring Cloud 5大组件有哪些

通常情况下：

• Eureka ：注册中心
• Ribbon ：负载均衡
• Feign ：远程调用
• Hystrix ：服务熔断
• Zuul/Gateway ：网关

随着SpringCloudAlibba在国内兴起 , 我们项目中使用了一些阿里巴巴的组件

• 注册中心/配置中心 Nacos
• 负载均衡 Ribbon
• 服务调用 Feign
• 服务保护 sentinel
• 服务网关 Gateway

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

• 我们当时项目采用的eureka作为注册中心，这个也是spring cloud体系中的一个核心组件
• 服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
• 服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
• 服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除

3）nacos与eureka的区别

• Nacos与eureka的共同点（注册中心）
  • 都支持服务注册和服务拉取
  • 都支持服务提供者心跳方式做健康检测
• Nacos与Eureka的区别（注册中心）
  • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
  • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
  • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
• Nacos还支持了配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因

（4）你们项目负载均衡如何实现的

微服务的负载均衡主要使用了一个组件Ribbon，比如，我们在使用feign远程调用的过程中，底层的负载均衡就是使用了ribbon

（5）Ribbon负载均衡策略有哪些 ?

• RoundRobinRule：简单轮询服务列表来选择服务器
• WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
• RandomRule：随机选择一个可用的服务器
• ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)

（6）如果想自定义负载均衡策略如何实现

提供了两种方式：

• 创建类实现IRule接口，可以指定负载均衡策略（全局）
• 在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略（局部）

（7）什么是服务雪崩，怎么解决这个问题？

• 服务雪崩：一个服务失败，导致整条链路的服务都失败的情形
• 服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑
• 服务熔断：默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求

（8）熔断和降级的区别

• 区别
  • 熔断和降级触发的原因不一样，服务熔断一般是某个服务的故障引起的，而服务降级则是从整体的负荷考虑的；
  • 它们管理目标的层次不一样，熔断其实是一个框架级的处理，每个微服务都需要。而降级一般需要对业务进行层级区分，即核心服务、边缘服务，一般从外围的边缘服务开始进行降级。
• 共同点
  • 它们的目的一致，都是从系统的可用性和可靠性的角度考虑，为了防止整个系统的反应缓慢或者崩溃，而采用的策略。
  • 它们达到的目的都是某些服务不可用或者不可达，但是整体核心功能正常。
  • 它们的粒度一致，都是服务级别的，即影响的是服务。
  • 自治性要求高，熔断模式一般是由服务基于策略地自动触发，降级虽然可以人为处理，但是在微服务的架构下，完全依靠人为显然不可行，所以需要进行开关预设、配置中心。

服务熔断可以理解为服务降级的一种，因为熔断必然会触发降级，区别就是熔断在于对调用链路的保护，降级是对整个系统过载的一种保护。

（9）为什么需要监控微服务

• 问题定位
• 性能分析
• 服务关系
• 服务告警

（10）如何监控微服务

四种方法

• Springboot-admin
• prometheus+Grafana
• zipkin
• skywalking

（11）你们的微服务是怎么监控的？

我们项目中采用的skywalking进行监控的

• skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。
• 我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复

参考 黑马程序员相关视频与文档、SpringCloud系列：服务雪崩、服务熔断、服务降级