微服务面试常问知识点总结

刘德崋

已于 2024-08-12 20:02:21 修改

阅读量731

点赞数 24

文章标签：微服务面试架构

于 2024-08-12 10:40:49 首次发布

本文链接：https://blog.csdn.net/Sabotd/article/details/141125135

版权

微服务

根据学习搜集的信息，结合网络内容进行的总结。

思维导图文档地址

错误和不足还请大佬指正ヽ(=･ω･=)丿

文章目录

微服务

一、Spring cloud

注册中心：Nacos、Eureka

服务注册

服务提供者需要把自己信息注册到注册中心，由注册中心来保存，比如服务名称、ip、端口等信息

服务发现

消费者向注册中心来取服务列表，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用

服务监控

服务提供者会定期向注册中心发送心跳，提供健康报告，如果注册中心长时间没有接收到心跳，就会将这个服务从注册中心中删除。 nacos还可以实时更新服务提供者的地址变更，将最新的地址推送给消费者

区别

①Nacos支持服务端主动检测提供者状态，临时实例才用心跳模式，非临时实例采用主动监测模式（在配置文件中更改）

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

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

④Nacos集群默认采用AP方式（高可用），当集群中存在非临时实例时，才用CP模式（强一致）。Eureka采用AP方式。

⑤Nacos支持配置中心，eureka只有注册中心

负载均衡：Ribbon

策略

①RoundRobinRule：简单轮询服务器列表选择服务器

②WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小

③RandomRule：随机选择一个可用的服务器

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

⑤RetryRule：重试机制的选择逻辑

⑥AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的，再选择连接数较小的实力

⑦ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后在对Zone内的多个服务器进行轮询。

自定义策略

创建一个类实现IRule接口，指定负载均衡策略，全局生效

在客户端配置文件中，可以配置某个服务调用的负载均衡策略，局部生效

远程调用：OpenFeign

OpenFeign是一个声明式的Web服务客户端，由Netflix开发的，后来成为了Spring Cloud项目的一部分，通过可插拔的注解支持（包括Feign注解和JAX-RS注解）来创建HTTP客户端。

注意点

①使用OpenFeign时，需要确保所有相关的依赖（如Spring Cloud、Ribbon、Hystrix等）版本兼容。

②如果使用服务发现（如Eureka），需要确保服务注册和发现的配置正确。

③需要合理设置请求超时时间，避免因为某个服务响应慢导致整个系统阻塞。

服务熔断（服务保护）：Hystrix、Sentinel

服务雪崩

一个服务失败，导致整条链路的服务都失败的情形，也叫级联故障

服务降级

服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受到请求突增影响变得不可用，确保服务不会崩溃，一般实际开发中与feign接口整合，编写降级逻辑

服务熔断

默认关闭，需要手动打开，如果检测到10秒内请求的失败率超过50%，就会触发熔断机制。之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求。 Sentinel可在控制台配置熔断参数

监控

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

功能：问题定位、性能分析、服务关系、服务告警

网关：Gateway、Zuul

网关就是网络的关口，数据在网络间传输，从一个网络传输到另一网络时就需要经过网关来做数据的路由和转发以及数据安全的校验。

作用

路由分发

根据请求的路径、方法、头部信息等将请求路由到相应的后端服务。这使得客户端无需知道后端服务的具体位置和细节。

服务发现

可以与服务注册中心（如Eureka、Consul）集成，动态发现和调用后端服务，使得服务实例的添加和移除对客户端透明。

身份校验和授权

可以对请求进行身份验证和授权，确保只有合法的请求才能访问后端服务。这包括验证API密钥、JWT令牌、OAuth2访问令牌等。

日志记录

可以记录请求和响应的日志，提供监控和分析功能，帮助开发者了解系统的运行状况和性能瓶颈。

负载均衡

可以在多个后端服务实例之间分配请求，以实现负载均衡，提高系统的处理能力和可用性。

注：

作为系统的入口点，其性能直接影响到整个系统的响应速度。因此，需要确保API Gateway的性能足够高，能够处理大量的并发请求。还要注意Gateway造成的系统的单点故障，为了提高系统的可用性，需要对API Gateway进行高可用性设计，例如使用集群部署。

二、业务相关

限流

作用

①并发流量突增

②防止恶意刷端口

实现方式

①使用Tomcat设置最大连接数

②使用Nginx基于漏桶算法或令牌桶算法实现。

③使用网关基于漏桶算法或令牌桶算法实现。

④自定义拦截器

漏桶算法

漏桶固定大小存储请求，固定速率漏出请求，多余请求等待或直接抛弃

令牌桶算法

以固定速率生成令牌，基于Redis存储令牌，请求获取到令牌才会被服务无处理，没有令牌的请求会被阻塞或抛弃

分布式事务

分布式理论：分布式系统的三个指标

Consistency（一致性）

用户访问分布式系统的任意节点，得到的数据必须一致

Availability（可用性）

用户访问集群中的任意健康节点，必须能得到响应

Partition tolerance（分区容错性）

Partition（分区）：因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立分区。 Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

Eric Brewer提出的观点：分布式系统无法同时满足三个指标。分布式系统节点之间需要网络链接，所以分区是必然存在的。如果保证范围跟的高可用性，就不能保证数据的强一致性。如果保证数据的强一致性，就要放弃高可用性。

BASE

Basically Available（基本可用）：分布式系统出现故障时，必须损失部分可用性，即保证核心可用

Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态

Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

分布式事务解决方案：seata

TC 事务协调者

维护全局和分支事务的状态，协调全局事务的提交和回滚

TM 事务管理器

定义全局事物的范围、开始全局事务、提交或回滚全局事务

RM 资源管理器

管理分支实物处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚

XA模式
保证数据的强一致性，效率较低
AT模式
弥补了XA模型中资源锁定周期过长的问题

分布式服务接口幂等

多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单词调用的结果一致

需要幂等的场景

①用户重复点击（网路波动）

②MQ消息重复

③应用使用失败或超市重试的机制

解决方式

①数据库唯一索引：可以用于实现新增的幂等

②token+redis
在这里插入图片描述

③分布式锁
在这里插入图片描述

分布式任务调度 xxl-job

可解决的问题（通过控制台进行设置）

①集群任务的重复执行问题

②cron表达式定义灵活

③定时任务失败了，重试和统计

④任务量大，分片执行

三、情景模拟

1、Spring Cloud 5大组件有哪些？

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

Eureka : 注册中心

Ribbon : 负载均衡

OpenFeign : 远程调用

Hystrix : 服务熔断

Zuul/Gateway : 网关

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

注册中心/配置中心 Nacos

负载均衡 Ribbon

服务调用 OpenFeign

服务保护 sentinel

服务网关 Gateway

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

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

3、说下nacos与eureka的区别？

我们当时xx项目就是采用的nacos作为注册中心，选择nacos还要一个重要原因就是它支持配置中心，不过nacos作为注册中心，也比eureka要方便好用一些，主要相同不同点在于几点：

共同点

Nacos与eureka都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测

Nacos与Eureka的区别

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

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

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

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

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

在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现 , Feign的底层已经自动集成了Ribbon , 使用起来非常简单当发起远程调用时，ribbon先从注册中心拉取服务地址列表，然后按照一定的路由策略选择一个发起远程调用，一般的调用策略是轮询

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

有很多种，我记得几个：

RoundRobinRule：简单轮询服务列表来选择服务器
WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
RandomRule：随机选择一个可用的服务器
ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。

使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)

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

提供了两种方式：

①创建类实现IRule接口，可以指定负载均衡策略，这个是全局的，对所有的远程调用都起作用

②在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略，只是对配置的这个服务生效远程调用

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

服务雪崩是指一个服务失败，导致整条链路的服务都失败的情形，一般我们在项目解决的话就是两种方案。

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

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

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

①skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。

②我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复

9、你们项目中有没有做过限流 ? 怎么做的 ?

我当时做的xx项目，采用就是微服务的架构，因为xx因为，应该会有突发流量，最大QPS可以达到2000，但是服务支撑不住，我们项目都通过压测最多可以支撑1200QPS。因为我们平时的QPS也就不到100，为了解决这些突发流量，所以采用了限流。

【版本1】我们当时采用的nginx限流操作，nginx使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量，我们控制的速率是按照ip进行限流，限制的流量是每秒20

【版本2】我们当时采用的是spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法，可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量

10、限流常见的算法有哪些呢？

比较常见的限流算法有漏桶算法和令牌桶算法漏桶算法是把请求存入到桶中，以固定速率从桶中流出，可以让我们的服务做到绝对的平均，起到很好的限流效果令牌桶算法在桶中存储的是令牌，按照一定的速率生成令牌，每个请求都要先申请令牌，申请到令牌以后才能正常请求，也可以起到很好的限流作用它们的区别是，漏桶和令牌桶都可以处理突发流量，其中漏桶可以做到绝对的平滑，令牌桶有可能会产生突发大量请求的情况，一般nginx限流采用的漏桶，spring cloud gateway中可以支持令牌桶算法

11、什么是CAP理论？

CAP主要是在分布式项目下的一个理论。包含了三项，一致性、可用性、分区容错性

一致性(Consistency)是指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致(强一致性)，不能存在中间状态。
可用性(Availability) 是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容错性(Partition tolerance) 是指分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

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

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

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

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

13、什么是BASE理论？

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

它的思想包含三方面：

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

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

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

14、你们采用哪种分布式事务解决方案？

我们当时是xx项目，主要使用到的seata的at模式解决的分布式事务 seata的AT模型分为两个阶段：

阶段一：RM的工作：

① 注册分支事务

② 记录undo-log（数据快照）

③ 执行业务sql并提交 ④报告事务状态
阶段二：提交时RM的工作：删除undo-log即可
阶段二：回滚时RM的工作：根据undo-log恢复数据到更新前 at模式牺牲了一致性，保证了可用性，不过，它保证的是最终一致性

15、分布式服务的接口幂等性如何设计？

嗯，我们当时有一个xx项目的下单操作，采用的token+redis实现的，流程是这样的第一次请求，也就是用户打开了商品详情页面，我们会发起一个请求，在后台生成一个唯一token存入redis，key就是用户的id，value就是这个token，同时把这个token返回前端第二次请求，当用户点击了下单操作会后，会携带之前的token，后台先到redis进行验证，如果存在token，可以执行业务，同时删除token；如果不存在，则直接返回，不处理业务，就保证了同一个token只处理一次业务，就保证了幂等性。