1.Spring Cloud组件有哪些?

通常情况下:
①Eureka ：注册中心
②Ribbon ：负载均衡
③Feign：远程调用
④Hystrix：服务熔断
⑤Zuul/Gateway ：网关

随着SpringCloudAlibba在国内兴起，我们项目中使用了一些阿里巴巴的组件
①注册中心/配置中心Nacos
②负载均衡Ribbon
③服务调用Feign
④服务保护sentinel
⑤服务网关Gateway

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

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

3.你能说下nacos与eureka的区别?

1.Nacos与eureka的共同点

①都支持服务注册和服务拉取
②都支持服务提供者心跳方式做健康检测

2.Nacos与Eureka的区别

①Nacos支持服务端主动检测提供者状态:

• 临时实例采用心跳模式，非临时实例采用主动检测模式
• 临时实例心跳不正常会被剔除，非临时实例则不会被剔除

②Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
③Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式; Eureka采用AP方式
④Nacos还支持了配置中心,eureka则只有注册中心，也是选择使用nacos的一个重要原因

4.负载均衡如何实现的?

1.Ribbon负载均衡流程

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

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

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

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

5.什么是服务雪崩，怎么解决这个问题?

服务雪崩:—个服务失败，导致整条链路的服务都失败的情形

1.服务降级

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

2.服务熔断

Hystrix 熔断机制，用于监控微服务调用情况，默认是关闭的，如果需要开启需要在引导类上添加注解:@EnableCircuitBreaker如果检测到10秒内请求的失败率超过50%，就触发熔断机制。之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求.

6.你们的微服务是怎么监控的?

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

skywalking

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

1.基本概念：

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

2.实现功能：

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

7.你们项目中有没有做过限流?怎么做的?

1.为什么要限流?

①并发的确大（突发流量)
②防止用户恶意刷接口

2.限流的实现方式:

①Tomcat:可以设置最大连接数
②Nginx:漏桶算法
③网关:令牌桶算法
④自定义拦截器

3.nginx限流

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

4.网关限流

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

8.解释一下CAP和BASE

1.CAP定理

1998年，加州大学的计算机科学家Eric Brewer提出，分布式系统有三个指标:

• Consistency (一致性):用户访问分布式系统中的任意节点，得到的数据必须一致
• Availability (可用性):用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝
• Partition tolerance (分区容错性):因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。在集群出现分区时，整个系统也要持续对外提供服务(容错性).

Eric Brewer说，分布式系统无法同时满足这三个指标。这个结论就叫做CAP定理。

结论:

①分布式系统节点之间肯定是需要网络连接的，分区(P）是必然存在的
②如果保证访问的高可用性(A),可以持续对外提供服务，但不能保证数据的强一致性$\to$AP
③如果保证访问的数据强一致性( C ),就要放弃高可用性$\to$ CP

2.BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想:
① Basically Available (基本可用)︰分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
②Soft State(软状态)︰在一定时间内，允许出现中间状态，比如临时的不一致状态。
③Eventually Consistent(最终一致性)︰虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

3.解决分布式事务的思想和模型:

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

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

1.Seata架构

Seata事务管理中有三个重要的角色:
①TC(Transaction Coordinator)-事务协调者:维护全局和分支事务的状态，协调全局事务提交或回滚。
②TM（Transaction Manager)-事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务。
③RM(Resource Manager)-资源管理器:管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

2.seata的XA模式

Seata是一个开源的分布式事务解决方案，可以与各种分布式数据库和消息队列等系统集成，实现分布式事务的一致性。

在Seata中，XA（eXtended Architecture）是一种常见的事务管理模式。XA模式是X/Open组织提出的一种分布式事务规范，通过使用两阶段提交（Two-Phase Commit，简称2PC）协议来保证多个资源管理器（如数据库）之间的事务一致性。需要互相等待各个分支事务提交，可以保证强一致性，性能差

在XA模式中，Seata作为事务协调器，负责协调各个参与者（资源管理器）的事务操作。当一个分布式事务涉及多个资源时，Seata会为每个参与者生成一个全局事务ID，并在事务开始时通知各个参与者开始事务。在事务执行过程中，各个参与者将事务操作记录在本地日志中，并等待事务协调器的指令。当所有参与者完成事务操作后，事务协调器会发起两阶段提交的过程：首先，事务协调器向所有参与者发起prepare请求，要求参与者将事务操作提交到本地资源中，并记录prepare日志；然后，事务协调器根据参与者的prepare结果，决定是否发起commit或rollback请求，以完成事务的最终提交或回滚。

通过使用XA模式，Seata可以实现分布式事务的一致性，并提供了高可用性和容错性。同时，Seata还提供了其他的事务模式，如TCC（Try-Confirm-Cancel）、SAGA等，以满足不同的业务场景需求。

3.AT模式原理

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
底层使用undo log 实现，性能好

4.TCC模式原理

①Try:资源的检测和预留;
②Confirm:完成资源操作业务;要求Try成功Confirm一定要能成功。
③Cancel:预留资源释放，可以理解为try的反向操作。

性能较好，不过需要人工编码实现

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

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

1.接口幂等

基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析

2.token+redis

使用token+redis来实现，性能较好
①第一次请求，生成一个唯一token存入redis，返回给前端
②第二次请求，业务处理，携带之前的token，到redis进行验证，如果存在，可以执行业务,删除token;如果不存在，则直接返回，不处理业务

3.分布式锁

分布式锁，性能较低

11.你们项目中使用了什么分布式任务调度?

xxl-job解决的问题:
①解决集群任务的重复执行问题
②cron表达式定义灵活
③定时任务失败了，重试和统计
④任务量大，分片执行

1.xxl-job路由策略有哪些?

1.FIRST(第一个)︰固定选择第一个机器;
2.LAST(最后一个)︰固定选择最后一个机器;
3.ROUND(轮询)
4.RANDOM(随机)︰随机选择在线的机器;
5.CONSISTENT_HASH (一致性HASH)︰每个任务按照Hash算法固定选择某一台机器，且所有任务均匀散列在不同机器上。
6.LEAST_FREQUENTLY_USED(最不经常使用)∶使用频率最低的机器优先被选举;
7.LEAST_RECENTLY_USED(最近最久未使用)︰最久未使用的机器优先被选举;
8.FAILOVER (故障转移)︰按照顺序依次进行心跳检测，第一个心跳检测成功的机器选定为目标执行器并发起调度;
9.BUSYOVER (忙碌转移)︰按照顺序依次进行空闲检测，第一个空闲检测成功的机器选定为目标执行器并发起调度;
10.SHARDING_BROADCAST(分片广播):广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数;可根据分片参数开发分片任务;

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

①路由策略选择故障转移，使用健康的实例来执行任务
②设置重试次数
③查看日志+邮件告警来通知相关负责人解决

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

①让多个实例一块去执行（部署集群)，路由策略分片广播
②在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行