微服务相关面试题

最新推荐文章于 2023-03-31 11:54:58 发布

北辰小朋友呀

最新推荐文章于 2023-03-31 11:54:58 发布

阅读量316

点赞数

分类专栏： Java 文章标签：微服务 java spring boot

本文链接：https://blog.csdn.net/weixin_43798629/article/details/127023949

版权

Java 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

微服务相关面试题

1 Springboot

**1.1 讲一讲SpringBoot自动装配的原理

难易程度：☆☆☆

出现频率：☆☆☆☆

嗯，好的，它是这样的。

在Spring Boot项目中的引导类上有一个注解@SpringBootApplication，这个注解是对三个注解进行了封装，分别是：

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan

其中@EnableAutoConfiguration是实现自动化配置的核心注解。

该注解通过@Import注解导入对应的配置选择器。关键的是内部就是读取了该项目和该项目引用的Jar包的的classpath路径下META-INF/spring.factories文件中的所配置的类的全类名。

在这些配置类中所定义的Bean会根据条件注解所指定的条件来决定是否需要将其导入到Spring容器中。

一般条件判断会有像@ConditionalOnClass这样的注解，判断是否有对应的class文件，如果有则加载该类，把这个配置类的所有的Bean放入spring容器中使用。

1.2 讲一讲SpringBoot启动流程

难易程度：☆☆☆

出现频率：☆☆☆

springboot项目在启动的时候, 首先会执行启动引导类里面的

SpringApplication.run(AdminApplication.class, args)方法

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6DhLTAew-1663995643698)(微服务相关面试题.assets/image-20220821224248791.png)]

这个run方法主要做的事情可以分为三个部分 :

第一部分进行SpringApplication的初始化模块，配置一些基本的环境变量、资源、构造器、监听器

第二部分实现了应用具体的启动方案，包括启动流程的监听模块、加载配置环境模块、及核心的创建上下文环境模块

第三部分是自动化配置模块，该模块作为springboot自动配置核心

1.3 你们常用的SpringBoot起步依赖有哪些

难易程度：☆☆

出现频率：☆☆☆☆

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-h71VwUff-1663995643699)(微服务相关面试题.assets/image-20220821224354029.png)]

1.4 springBoot支持的配置文件有哪些 ? 加载顺序是什么样的

难易程度：☆☆☆

出现频率：☆☆☆

1 properties文件
2 YAML文件
3 系统环境变量
4 命令行参数

如果有相同的配置参数, 后加载的会覆盖先加载的

1.5 运行一个SpringBoot项目有哪些方式

难易程度：☆☆

出现频率：☆☆☆

直接使用jar -jar 运行
开发过程中运行main方法
可以配置插件 , 将springboot项目打war包, 部署到Tomcat中运行
直接用maven插件运行 maven spring-boot：run

1.6 Spring Boot的核心注解是哪个？他由哪几个注解组成的？

难易程度：☆☆☆

出现频率：☆☆☆

Spring Boot的核心注解是@SpringBootApplication , 他由几个注解组成 :

@SpringBootConfiguration：组合了- @Configuration注解，实现配置文件的功能；
@EnableAutoConfiguration：打开自动配置的功能，也可以关闭某个自动配置的选项
@ComponentScan：Spring组件扫描

1.7 你们项目中使用的SpringBoot是哪个版本 ?

难易程度：☆☆

出现频率：☆☆

SpringBoot : 2.3.9.RELEASE
SpringCloud : Hoxton.SR10
SpringCloudAlibaba : 2.2.5.RELEASE

1.8 Spring Boot如何定义多套不同环境配置？

难易程度：☆☆

出现频率：☆☆

提供多套配置文件，如：

application.properties
application-dev.properties
application-test.properties
application-prod.properties

然后在applcation.properties文件中指定当前的环境spring.profiles.active=test,这时候读取的就是application-test.properties文件。

2 SpringCloud

**2.1 什么是微服务?微服务的优缺点是什么?

难易程度：☆☆☆

出现频率：☆☆

分布式和微服务的区别

微服务就是分布式的实现（其中一种）

微服务就是一个独立的职责单一的服务应用程序，一个模块

优点：松耦合，聚焦单一业务功能，无关开发语言，团队规模降低。在开发中，不需要了解多有业务，只专注于当前功能，便利集中，功能小而精。微服务一个功能受损，对其他功能影响并不是太大，可以快速定位问题。微服务只专注于当前业务逻辑代码，不会和 html、css 或其他界面进行混合。可以灵活搭配技术，独立性比较好。

缺点：随着服务数量增加，管理复杂，部署复杂，服务器需要增多，服务通信和调用压力增大，运维工程师压力增大，人力资源增多，系统依赖增强，数据一致性，性能监控。

**2.2 Spring Cloud 5大组件有哪些？

难易程度：☆☆☆

出现频率：☆☆☆☆

早期我们一般认为的Spring Cloud五大组件是

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

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

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

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

难易程度：☆☆☆

出现频率：☆☆☆

各种注册中心组件的原理和流程其实大体上类似

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E58SH7dX-1663995643699)(微服务相关面试题.assets/image-20220520105342636.png)]

核心的功能就一下几个 :

服务注册 : 服务启动的时候会将服务的信息注册到注册中心, 比如: 服务名称 , 服务的IP , 端口号等
服务发现 : 服务调用方调用服务的时候, 根据服务名称从注册中心拉取服务列表 , 然后根据负载均衡策略 , 选择一个服务, 获取服务的IP和端口号, 发起远程调用
服务状态监控 : 服务提供者会定时向注册中心发送心跳 , 注册中心也会主动向服务提供者发送心跳探测, 如果长时间没有接收到心跳, 就将服务实例从注册中心下线或者移除

使用的话, 首先需要部署注册中心服务 , 然后在我们自己的微服务中引入注册中心依赖, 然后再配置文件中配置注册中心地址就可以了

spring:
  application:
    name: leadnews-admin
  cloud:
    nacos:
      # 注册中心地址
      discovery:
        server-addr: 124.221.75.8:8848
      # 配置中心地址
      config:
        server-addr: 124.221.75.8:8848
        file-extension: yml

2.4 你们项目中微服务之间是如何通讯的?

难易程度：☆☆

出现频率：☆☆

1．同步通信：通过Feign发送http请求调用

2．异步：消息队列，如RabbitMq、KafKa等

2.5 你们项目负载均衡如何实现的 ?

难易程度：☆☆☆

出现频率：☆☆☆

服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现 , Feign的底层已经自动集成了Ribbon , 使用起来非常简单

客户端调用的话一般会通过网关, 通过网关实现请求的路由和负载均衡

spring:
  cloud:
    gateway:
      routes:
        # 平台管理
        - id: wemedia
          uri: lb://leadnews-wemedia
          predicates:
            - Path=/wemedia/**
          filters:
            - StripPrefix= 1

**2.6 Ribbon负载均衡策略有哪些 ? 如果想自定义负载均衡策略如何实现 ?

难易程度：☆☆☆☆

出现频率：☆☆☆☆

常用的负载均衡算法：

1、RoundRobinRule：简单轮询服务列表来选择服务器

2、AvailabilityFilteringRule：对以下两种服务器进行忽略：

（1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。

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

3、WeightedResponseTimeRule：为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。

4、ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。

而后再对Zone内的多个服务做轮询。它是Ribbon默认的负载均衡规则。

5、BestAvailableRule：忽略那些短路的服务器，并选择并发数较低的服务器。

6、RandomRule：随机选择一个可用的服务器。

7、RetryRule：重试机制的选择逻辑。

默认的负载均衡算法：ZoneAvoidanceRule

自定义负载均衡

如果想要自定义负载均衡 , 可以自己创建类实现IRule接口 , 然后再通过配置类或者配置文件配置即可 :

通过定义IRule实现可以修改负载均衡规则，有两种方式：

代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：

@Bean
public IRule randomRule(){
    return new RandomRule();
}

配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

**2.7什么是Spring Cloud Gateway以及在你们的项目中如何去应用该组件的？

难易程度：☆☆☆

出现频率：☆☆☆

Spring Cloud Gateway：是Spring Cloud中所提供的一个服务网关组件，是整个微服务的统一入口，在服务网关中可以实现请求路由、统一的日志记录，流量监控、权限校验等一系列的相关功能！

netty

项目应用：权限的校验

具体实现思路：使用Spring Cloud Gateway中的全局过滤器拦截请求(GlobalFilter、Order)，从请求头中获取token，然后解析token。如果可以进行正常解析，此时进行放行；如果解析不到直接返回。

2.8 你们项目的配置文件是怎么管理的 ?

难易程度：☆☆☆

出现频率：☆☆☆

大部分的固定的配置文件都放在服务本地 , 一些根据环境不同可能会变化的部分, 放到Nacos中apllo

==2.9 你们项目中有没有做过限流 ? 怎么做的 ?

难易程度：☆☆☆☆

出现频率：☆☆☆

常见的限流算法：漏桶算法、令牌桶算法

漏桶算法：漏桶算法其实很简单，可以粗略的认为就是注水漏水过程，往桶中以一定速率流出水，以任意速率流入水，当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。

如下图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-phweusoz-1663995643700)(微服务相关面试题.assets/image-20220823223012283.png)]

令牌桶算法：令牌桶是一个存放固定容量令牌的桶，按照固定速率r往桶里添加令牌；桶中最多存放b个令牌，当桶满时，新添加的令牌被丢弃；当一个请求达到时，会尝试从桶中获取令牌；如果有，则继续处理请求；如果没有则排队等待或者直接丢弃；可以发现，漏桶算法的流出速率恒定，而令牌桶算法的流

出速率却有可能大于r；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TUySAREZ-1663995643701)(微服务相关面试题.assets/image-20220823222550372.png)]

从作用上来说，漏桶和令牌桶算法最明显的区别就是是否允许突发流量(burst)的处理，漏桶算法能够强行限制数据的实时传输（处理）速率，对突发流量不做额外处理；而令牌桶算法能够在限制数据的平均传输速率的同时允许某种程度的突发传输。

限流算法区别

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dyonWAdn-1663995643701)(微服务相关面试题.assets/image-20220823223142337.png)]

==2.10 断路器/熔断器用过嘛 ? 断路器的状态有哪些？

难易程度：☆☆☆☆

出现频率：☆☆☆

我们项目中使用Hystrix实现的断路器 ,默认是关闭的，如果需要开启需要在引导类上添加注解：

@EnableCircuitBreaker

断路器状态机包括三个状态：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EYXOUGnL-1663995643702)(微服务相关面试题.assets/image-20220520113844464.png)]

closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
- CPU 的使用率超过 90%
- 请求错误率超过 5%
- 请求延迟超过 500ms
open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态5秒后（默认值）会进入half-open状态
half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
- 请求成功：则切换到closed状态
- 请求失败：则切换到open状态

2.11 你们项目中有做过服务降级嘛 ?

难易程度：☆☆☆

出现频率：☆☆☆

我们项目中涉及到服务调用得地方都会定义降级, 一般降级逻辑就是返回默认值 , 降级的实现也非常简单 , 就是创建一个类实现FallbackFactory接口 , 然后再对应的Feign客户端接口上面 , 通过@FeignClient指定降级类

**2.12 nacos、eureka的区别？

难易程度：☆☆☆

出现频率：☆☆☆☆

① Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式

② 临时实例心跳不正常会被剔除，非临时实例则不会被剔除

③ Nacos支持服务列表变更的消息推送模式，服务列表更新更及时

④ Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；

总结：

Eureka采用AP方式
naocs默认是AP模式，可以采用CP模式

2.13 你们的微服务是这么监控的？

难易程度：☆☆☆

出现频率：☆☆☆

skywalking

3 分布式事务篇

3.1 什么是分布式事务？

难易程度：☆☆☆

出现频率：☆☆☆

概述：在分布式系统上一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务节点上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

如下所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rthLonVi-1663995643702)(微服务相关面试题.assets/image-20220824001744594.png)]

某电商系统的下单操作，需要请求三个服务来完成，这三个服务分别是：订单服务，账户服务，库存服务。当订单生成完毕以后，就需要分别请求账户服务和库存服务进行进行账户余额的扣减和库存扣减。假设都扣减成功了，此时在执行下单的后续操作时出现了问题，那么订单数据库就进行事务回滚，订单生成失败，而账户余额和扣减则都扣减成功了。这就出现了问题，而分布式事务就是解决上述这种不一致问题的。

==3.2 哪些场景下都会产生分布式事务？

难易程度：☆☆☆☆

出现频率：☆☆☆

场景1：跨库事务

跨库事务指的是，一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。如下所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dvQSkAPa-1663995643702)(微服务相关面试题.assets/image-20220824001721789.png)]

场景二：分库分表

通常一个库数据量比较大或者预期未来的数据量比较大，都会进行水平拆分，也就是分库分表。如下图，将数据库B拆分成了2个库：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jxqK2Ug7-1663995643703)(微服务相关面试题.assets/image-20220824001809018.png)]

对于分库分表的情况，一般开发人员都会使用一些数据库中间件来降低sql操作的复杂性。

如，对于sql：insert into user(id,name) values (1,“tianshouzhi”),(2,“wangxiaoxiao”)。这条sql是操作单库的语法，单库情况下，可以保证事务的一致性。

但是由于现在进行了分库分表，开发人员希望将1号记录插入分库1，2号记录插入分库2。所以数据库中间件要将其改写为2条sql，分别插入两个不同的分库，此时要保证两个库要不都成功，要不都失败，因此基本上所有的数据库中间件都面临着分布式事务的问题。

场景三：跨服务事务

跨服务事务指的是，一个应用某个功能需要调用多个微服务进行实现，不同的微服务操作的是不同的数据库。如下所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HOW12ht2-1663995643703)(微服务相关面试题.assets/image-20220824001829706.png)]

Service A完成某个功能需要直接操作数据库，同时需要调用Service B和Service C，而Service B又同时操作了2个数据库，Service C也操作了一个库。需要保证这些跨服务的对多个数据库的操作要不都成功，要不都失败，实际上这可能是最典型的分布式事务场景。

**3.3 什么是CAP理论？

难易程度：☆☆☆☆

出现频率：☆☆☆

CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：

1、一致性(Consistency) ：更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致(强一致性)，不能存在中间状态。

2、可用性(Availability) ：系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。

3、分区容错性(Partition tolerance) ：分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

如下所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-groDHFv0-1663995643704)(微服务相关面试题.assets/image-20220824001910278.png)]

3.4 为什么分布式系统中无法同时保证一致性和可用性？

难易程度：☆☆☆☆

出现频率：☆☆☆

首先一个前提，对于分布式系统而言，分区容错性是一个最基本的要求，因此基本上我们在设计分布式系统的时候只能从一致性（C）和可用性（A）之间进行取舍。

如果保证了一致性（C）：对于节点N1和N2，当往N1里写数据时，N2上的操作必须被暂停，只有当N1同步数据到N2时才能对N2进行读写请求，在N2被暂停操作期间客户端提交的请求会收到失败或超时。显然，这与可用性是相悖的。

如果保证了可用性（A）：那就不能暂停N2的读写操作，但同时N1在写数据的话，这就违背了一致性的要求。

3.5 什么是BASE理论？

难易程度：☆☆☆

出现频率：☆☆☆

CAP是分布式系统设计理论，BASE是CAP理论中AP方案的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。它的思想包含三方面：

1、Basically Available（基本可用）：基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。

2、Soft state（软状态）：即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3、Eventually consistent（最终一致性）：强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统

保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

**3.6 分布式事务的常见的解决方案有哪些？

难易程度：☆☆☆

出现频率：☆☆☆

方案一：2PC

两阶段提交又称2PC，2PC是一个非常经典的强一致、中心化的原子提交协议。

中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和 N个参与者节点（partcipant）。

两个阶段：

1、第一阶段：投票阶段

2、第二阶段：提交/执行阶段。

举例订单服务A，需要调用支付服务B 去支付，支付成功则处理订单状态为待发货状态，否则就需要将购物订单处理为失败状态。那么看2PC阶段是如何处

理的。

阶段一：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-l36wWlLz-1663995643704)(微服务相关面试题.assets/image-20220824001942000.png)]

阶段一执行流程：

1、事务询问协调者向所有的参与者发送事务预处理请求，称之为Prepare，并开始等待各参与者的响应。

2、执行本地事务各个参与者节点执行本地事务操作，但在执行完成后并不会真正提交数据库本地事务，而是先向协调者报告说：“我这边可以处理了/我这边不能处理”。

3、各参与者向协调者反馈事务询问的响应如果参与者成功执行了事务操作,那么就反馈给协调者Yes响应,表示事务可以执行,如果没有参与者成功执行事务,那么就反馈给协调者 No 响应,表示事务不可以执行。

阶段二：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YOYgES12-1663995643705)(微服务相关面试题.assets/image-20220824002000947.png)]

阶段二执行流程：

1、所有的参与者反馈给协调者的信息都是Yes,那么就会执行事务提交协调者向所有参与者节点发出Commit请求

2、事务提交参与者收到Commit请求之后,就会正式执行本地事务Commit操作,并在完成提交之后释放整个事务执行期间占用的事务资源。

方案三：TCC

TCC（Try-Confirm-Cancel）又称补偿事务。其核心思想是：“针对每个操作都要注册一个与其对应的确认和补偿（撤销操作）”。

它分为三个操作：

1、Try阶段：主要是对业务系统做检测及资源预留。

2、Confirm阶段：确认执行业务操作。

3、Cancel阶段：取消执行业务操作。

如下所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-52r8l6d7-1663995643705)(微服务相关面试题.assets/image-20220824002205655.png)]

TCC事务的处理流程与2PC两阶段提交类似，不过2PC通常都是在跨库的DB层面，而TCC本质上就是一个应用层面的2PC，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口还必须实现幂等。

方案四：MQ分布式事务

上面的三种分布式事务的解决方案适用于对数据一致性要求很高的场景。如果数据强一致性要求没那么高，可以采用消息中间件（MQ）实现事务最终一致。在支付系统中，常常使用的分布式事务解决方案就是基于MQ实现的，它对数据强一致性要求没那么高，但要求数据最终一致即可。

例如：向借呗申请借钱，借呗审核通过后支付宝的余额才会增加，但借呗和支付宝有可能不是同一个系统，这时候如何实现事务呢？实现方案如下图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hD74VMjo-1663995643705)(微服务相关面试题.assets/image-20220824002222856.png)]

执行流程如下所示：

1、找花呗借钱

2、花呗借钱审核通过，同步生成借款单

3、借款单生成后，向MQ发送消息，通知支付宝转账

4、支付宝读取MQ消息，并增加账户余额

上图最复杂的其实是如何保障2、3在同一个事务中执行（本地事务和MQ消息发送在同一个事务执行），借款结束后，借呗数据处理就完成了，接下来支付宝才能读到消息，然后执行余额增加，这才完成整个操作。如果中途操作发生异常，例如支付宝余额增加发生问题怎么办？此时需要人工解决，没有特别好的办法，但这种事故概率极低。