1.Spring Cloud 5大组件有哪些?
随着SpringCloudAlibba在国内兴起，我们项目中使用了一些阿里巴巴的组件
注册中心/配置中心 Nacos
负载均衡 Ribbon
服务调用 Feign
服务保护 sentinel
服务网关 Gateway
2. 我看你之前也用过nacos、你能说下nacos与eureka的区别?
Nacos与eureka的共同点(注册中心)
① 都支持服务注册和服务拉取
② 都支持服务提供者心跳方式做健康检测Nacos与Eureka的区别(注册中心)
Nacos与eureka的不同点
1.Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式，非临时实例采用主动检测模式
2.在nacos中临时实例心跳不正常会被剔除，非临时实例则不会被剔除
3.Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
4.Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式:Eureka采用AP方式 Nacos还支持了配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因
3.服务注册和发现是什么意思?Spring Cloud 如何实现服务注册发现?
我们当时项目采用的nacos作为注册中心，这个也是spring cloud体系中的一个核心组件服务注册:服务提供者需要把自己的信息注册到nacos，由nacos来保存这些信息，比如服务名称、ip、端口等等服务发现:消费者向nacos拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用。
服务监控:服务提供者会每隔5秒向nacos发送心跳，报告健康状态，如果nacos服务30秒没接收到心跳，从nacos中剔除。
4.你们项目负载均衡如何实现的?
微服务的负载均衡主要使用了一个组件Ribbon，比如，我们在使用feign远程调用的过程中，底层的负载均衡就是使用了ribbon
5.Ribbon负载均衡策略有哪些?
5.1 简单轮询服务列表来选择服务器
5.2 按照权重来选择服务器，响应时间越长，权重越小
5.3 随机选择一个可用的服务器
5.4 区域敏感策略（服务器的就近原则），以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这 个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)
6.如果想自定义负载均衡策略如何实现 ?
提供了两种方式:
1，创建类实现IRule接口，可以指定负载均衡策略(全局)
2，在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略(局部)
7. 什么是服务雪崩，怎么解决这个问题?
服务雪崩:一个服务失败，导致整条链路的服务都失败的情形
解决方法：
7.1 服务降级:服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑
7.2 服务熔断:默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求
8.你们的微服务是怎么监控的?
我们项目中采用的skywalking进行监控的
1，skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。
2，我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复。
9.你们项目中有没有做过限流?怎么做的?
先来介绍业务，什么情况下去做限流，需要说明QPS具体多少
1.我们当时有一个活动，到了假期就会抢购优惠券，QPS最高可以达到2000，平时10-50之间，为了应对突发流量需要做限流
常规限流，为了防止恶意攻击，保护系统正常运行，我们当时系统能够承受最大的QPS是多少(压测结果)
2.nginx限流：
2.1 控制速率(突发流量)，使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量
2.2 控制并发数，限制单个ip的链接数和并发链接的总数
3，网关限流
3.1 在spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算
3.2 可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令桶总容量
10.解释一下CAP和BASE
CAP 定理(一致性、可用性、分区容错性).
1. 分布式系统节点通过网络连接，一定会出现分区问题(P)，当分区出现时，系统的一致性(C)和可用性(A)就无法同时满足
BASE理论：基本可用、软状态、最终一致
2. 解决分布式事务的思想和模型:
最终一致思想:各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据(AP)
强一致思想:各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚(CP)
11.你们采用哪种分布式事务解决方案?
简历上写的微服务，只要是发生了多个服务之间的写操作，都需要进行分布式事务控制
11.1 描述项目中采用的哪种方案(seata、MQ)
11.1.1seata的XA模式，CP，需要互相等待各个分支事务提交，可以保证强一致性，性能差 11.1.2 seata的AT模式，AP，底层使用undolog实现，性能好
11.1.3 seata的TCC模式，AP，性能较好，不过需要人工编码实现
11.1.4 MQ模式实现分布式事务,AP,在A服务写数据的时候，需要在同一个事务内发送消息到另外一个事务，异步，性能最好
12.分布式服务的接口幂等性如何设计?
幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致如果是新增数据:可以使用数据库的唯一索引
如果是新增或修改数据:1. 分布式锁，性能较差。 2. 使用token+redis来实现，性能较好
13.你们项目中使用了什么分布式任务调度（xxl-job）
xxI-job解决的问题：
解决集群任务的重复执行问题
cron表达式定义灵活
定时任务失败了，重试和统计
任务量大，分片执行
14.xxl-job路由策略有哪些?
xxl-job提供了很多的路由策略，我们平时用的较多就是:轮询、故障转移、分片广播...
15. xxl-job任务执行失败怎么解决?
路由策略选择故障转移，使用健康的实例来执行任务
设置重试次数
查看日志+邮件告警来通知相关负责人解决
16.如果有大数据量的任务同时都需要执行，怎么解决?
让多个实例一块去执行(部署集群)，路由策略分片广播
在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行