微服务面试题

1.SpringCloud五大组件有哪些

• 通常情况：
  • 注册中心：Eureka
  • 负载均衡：Ribbon
  • 远程调用：Feign
  • 服务熔断：Hystrix
  • 网关：Zuul/Gateway
• SpringCloudAlibba
  • 注册中心/配置中心：nacos
  • 负载均衡：Ribbon
  • 服务调用：Feign
  • 服务保护：sentinel
  • 服务网关：Gateway

2.服务注册和发现是什么意思，如何实现

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

3.nacos和eureka的区别

• 同：
  • 都支持服务注册和服务拉取
  • 都支持服务提供者心跳方式做健康检测
• 异：
  • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
  • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
  • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

4.负载均衡怎么实现

• 当发起远程调用时，Ribbon先从注册中心拉取服务地址列表，然后按照一定的路由策略选择一个发起远程调用，一般的调用策略是轮询

5.Ribbon的负载均衡策略有哪些

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

6.自定义负载均衡策略如何实现

• 创建类实现IRule接口，可以指定负载均衡策略，这个是全局的，对所有的远程调用都起作用
• 在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略，只是局部对配置的这个服务生效远程调用

7.什么是服务雪崩，怎么解决

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

8.微服务如何监控

• 链路追踪工具：skywalking
• 监控的作用：
  • 问题定位
  • 性能分析
  • 服务关系
  • 服务告警

9.项目中有没有做过限流，怎么做的

• 业务需求：

  • 并发大：我当时做的xx项目，抢优惠卷，有突发流量，最大QPS可以达到2000，因为我们平时的QPS也就不到100，为了解决这些突发流量，所以采用了限流。
  • 常规限流：防止恶意攻击，保护系统正常运行

• nginx限流

  • 控制速率（突发流量），使用漏桶算法实现过滤，以固定的速率处理请求，可以应对突发流量
  • 控制并发数：限制单个ip的链接数和并发链接的总数

• 网关限流

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

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

• 漏桶算法：是把请求存入到桶中，以固定速率从桶中流出，可以让我们的服务做到绝对的平均，起到很好的限流效果

• 令牌桶算法：在桶中存储的是令牌，按照一定的速率生成令牌，每个请求都要先申请令牌，申请到令牌以后才能正常请求，也可以起到很好的限流作用

• 同：漏桶和令牌桶都可以处理突发流量，

• 异：

  • 其中漏桶可以做到绝对的平滑，令牌桶有可能会产生突发大量请求的情况，
  • 一般nginx限流采用的漏桶，spring cloud gateway中可以支持令牌桶算法

11.解释一下CAP

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

12.解释一下BASE

• Basically Available（基本可用）：基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。
• Soft state（软状态）：即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• Eventually consistent（最终一致性）：强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

13.解释一下AP和CP

• AP(最终一致)：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据
• CP(强一致)：各分支事务执行完业务不要提交，等待彼此结果，而后统一提交或回滚

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

• Seata框架
  • XA：CP，需要互相等待各分支事务提交，可以保证强一致性，性能差
  • AT：AP，底层使用undo log实现，性能好
  • TCC：AP，性能较好，不过需要人工编码实现
• MQ：CP，异步，性能最好

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

• 幂等：多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单词调用的结果一致（新增，修改中常常不幂等）
• 解决方案：
  • 数据库唯一索引
  • token+redis：
    • 第一次请求，生成唯一token存入redis，返回给前端
    • 第二次请求，业务处理，携带之前的token到redis进行验证，如果存在，可以执行任务，删除token；如果不存在，直接返回，不处理业务
  • 分布式锁：性能比token低

16.分布式任务调度xxl-job有什么特点

• 解决集群任务的重复执行问题
• cron表的是定义灵活
• 定时任务失败了，重试和统计
• 任务量大，分片执行

17.xxl-job有哪些路由策略

• 轮询
• 故障转移
• 分片广播
• 第一个
• 最后一个
• 最近最久未使用

18.xxl-job任务执行失败怎么解决

• 路由策略选择故障转移，优先使用健康的实例来执行任务
• 如果还有失败的，我们在创建任务时，可以设置重试次数
• 如果还有失败的，就可以查看日志或者配置邮件告警来通知相关负责人解决

19.如果有大数据量的任务同时都需要执行，怎么解决

• 我们会让部署多个实例，共同去执行这些批量的任务，其中任务的路由策略是分片广播
• 在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行就可以了