微服务架构
SpringCloud
1.SpringCloud的五大常用组件是什么？
第一个，是服务注册和发现的组件，一般用阿里巴巴的Nacos。第二个是网关组件，这个一般用Gateway。第三个是服务之间远程调用的组件，一般有Fegin。第四个是服务之间负载均衡的组件，这个一般用Ribbon。第五个是服务之间保护或者降级的组件，一般有sentinel
2.讲一讲Nacos
Nacos是一种服务注册、发现和配置的组件。他主要有服务注册、服务发现和服务监控的三大功能。
第一个服务注册，每一个微服务都会把自己的信息比如说ip地址、端口都发送给Naco，
第二个，服务发现，另一个服务调用者也就是消费者可以从这个Nacos直接获取
第三个就是服务监控，每一个微服务都会定时向Naco发送心跳函数，如果一定时间内Nacos收不到，就会认为这个微服务挂了，就会从名单中剔除。
其中Nacos有一个特点就是会主动Push，比如这个服务监控，如果对面是非临时实例，会主动发送信号去检测他是否存活，没存活也不会删除，并且主动通知调用者，这个不可用了。
3.讲一讲负载均衡有哪些策略？如何实现？
负载均衡一般用的比较多的是Ribbon这个微服务的组件。他有很多种的负载均衡的策略，最简单的就是轮询策略，第一次请求给A，第二次请求给B，第三次请求给C，第四次再给A，就这么循环下去。第二种就是随机分配的策略。第三种就是优先级策略，会根据心跳来测算每一个服务的延迟，优先去分配那些低延时的服务。最后一种就是根据区域的性质来分配，一般来说可以是机房、可以是base地等等，然后再根据轮询策略去做分配。如何实现，一般来说有两种方式，第一种方式就是全局配置，这种方式需要写一个类继承IRule类，第二种方式是在配置文件里面去配置，配置每一个文件的相关轮询方式的参数。
4.什么是服务雪崩。如何解决？
服务雪崩指代的是一个服务彻底不可用的时候，导致他的下游服务也不可用，最终通过链式传导导致整个链条上的服务都不可用。
一般有两种解决方案，一种是熔断机制，一种是降级机制。一般会通过Hystrix组件来实现，
其中降级机制是一种服务自我保护的机制，确保服务不会受到突然增多影响而不可用，一般实际中会与Feign接口整合，编写降级的逻辑。服务熔断默认关闭，默认10s内请求有超过50%以上的失败率就触发熔断，关闭整个服务，之后每隔5s去重新尝试链接微服务，不响应就继续熔断，否则的话就恢复正常的请求。
5.你们的微服务是怎么进行监控的，能否讲一讲？
一般是采用skywalking进行监控，可以对接口、服务和实例进行监控，可以看到众多的服务中哪些服务和接口比较慢来进一步做性能的优化和分析。我们还在skywalking设置了告警，项目上线以后，如果报错了，可以给第一时间对相关的负责人进行通知进行bug的修复。
业务问题
1.如何去做限流的？怎么做
一般来说，我们的接口是有qps上限的，这个可以通过压测测出来，正常情况下请求都不会到达这个上限，但是可能会有突发流量，这个时候qps会大于这个上限，所以这个时候就要去使用限流。一般来说有两种限流方式，第一种就是nginx限流，一般是使用漏桶算法。另一种就是springcloud中gateway中的局部过滤器来限流，这一般是用令牌桶算法来进行限流。
2.限流算法说一说
第一种就是漏桶算法，这种算法的原理是把所有的请求放到桶中，然后这个桶只能以一定的速率去处理桶里面的请求，应对突发流量的时候可以做到平滑。另一种算法就是令牌桶算法
一个桶里面会按照一定的速度生成令牌并存放，面对大量的请求，每一个请求都必须拿到令牌才可以正常发出。他们的区别是漏桶算法可以做到绝对的平滑，而令牌桶算法有可能回去处理突发大量请求的情况。
3.讲一讲CAP理论和BASE理论
CAP分别代表的是一致性consistency、availablty可用性、partion分区。其中partion在分布式事务下是一定存在的。而一致性和可用性只能二选一，因此就有了两种模式，一种是AP，和CP，其中AP强调高可用性、CP强调高一致性。其中BASE是一种对应CAP理论问一种解决方案的理论，其中BA是Basically available基本可用 ，允许损失部分可用性。S代表SoftSate代表软状态，这是一个再达到最终状态的中间状态，代表一种中间的状态E代表Eventually consistency最终一致性。
4.介绍一下分布式事务的解决方案
我比较了解seata组件，seata组件有一种at模式来解决分布式事务。
第一阶段每个微服务的RM会注册自己的分支事务，然后记录undo-log，最后去执行sql然后报告自己的事务状态
第二阶段：如果所有RM的事务状态都ok，就会提交，最后删除undo-log的相关日志，如果有问题，就会根据之前记录的undo-log进行数据的回滚。at模式牺牲了一致性，保证了可用性，不过他保证的是最终的一致性
5.如何设计接口的幂等性？
首先接口幂等指的是，多次调用接口，不会去改变业务状态，可以保证重复调用和单次调用结果的一致性。对于restful风格的接口，一般get不会有这个问题，delete也不会用这个问题。主要是新增和修改。
对于新增可以采用唯一索引的方式，如果之前已经插入了相关数据，那么就没办法第二次插入重复的信息。对于新增或者修改，还有基于分布式锁的解决方案，来保证同一个时间只能有一个操作来进行执行，不过这种效率一般都比较低下。最后一种就是基于token+redis的方案，在第一次请求的时候。会获取相应的token，第二次再请求的时候会携带之前的token，如果存在token就可以去执行相应的业务，但是如果不存在就直接返回。这样的话就保证了同一个token只去处理一次业务，保证了幂等性。
6.xxl-job的路由策略是什么？
xxl的路由策略有很多，第一种就是轮询。第二种就是故障转移，这个的意思就是去按照顺序发送心跳函数去检测，如果心跳函数检测正常就转发到正常的那个机器上。第三种就是分片广播模式，广播触发对应集群的所有机器执行一次任务，同时自动传递分片的参数，根据分片的参数去执行任务。
7.xxl-job执行失败，怎么解决？
路由策略可以选择故障转移，如果还是有失败的，就去再设置重试次数，是还还是有失败的就去设置一下负责人，进行告警通知去进行人工排查和通知
8.xxl-job，如果有大数据量的任务同时都需要执行，该如何解决？
可以多设置几个实例机器，并且采取分片集群的方式去执行