spring cloud
1.nacos eureka
2.负载均衡 ribbon
1.ribbon的负载均衡策略
1)轮询
2)随机
3)最空闲
4)并发最低
5)重试
6)连接数最少
7)按属性ZONE适配 如区域 默认策略 ZONE里面再轮询
2.自定义策略
1)实现iRule接口 全局
2)配置文件中配置某个服务调用的负载均衡策略
3.熔断降级 sentinal
什么是服务雪崩，怎么解决这个问题？
服务雪崩：一个服务失败，导致整条链路的服务都失败的情形
服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，
确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑
服务熔断：默认关闭，需要手动打开，如果检测到10秒内请求的失败率超过50%，就触发熔断机制。之后每隔5秒重新尝试
请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求
4.限流
你们项目中有没有做过限流？怎么做的？
1,先来介绍业务，什么情况下去做限流，需要说明QPS具体多少
我们当时有一个活动，到了假期就会抢购优惠券，QPS最高可以达到2000，平时10-50之间，为了应对突发流量，
需要做限流
常规限流，为了防止恶意攻击，保护系统正常运行，我们当时系统能够承受最大的QPS是多少（压测结果）
2,nginx限流
控制速率
（突发流量），使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量
控制并发数，限制单个ip的链接数和并发链接的总数
3，网关限流
在spring cloud gatewayl中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法
可以根据p或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量
5. 微服务监控
常用的链路追踪器有skywolking zipkin
6.CAP、BASE 理论
解释一下CAP和BASE
CAP定理（一致性、可用性、分区容错性）
1.分布式系统节点通过网络连接，一定会出现分区问题(P)
2.当分区出现时，系统的一致性(C)和可用性(A)就无法同时满足
BASE理论
1.basically available 服务基本可用
2.soft state：中间态
3.Eventually Consistent: 最终一致性
解决分布式事务的思想和模型：
1.最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据(AP)
2.强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚(CP)
7.分布式事务
分布式事务
●描述项目中采用的哪种方案(seata|MQ)
1.seata的XA模式，CP,需要互相等待各个分支事务提交，可以保证强一致性，性能差
2.seata的AT模式，AP底层使用undo log实现，性能好
3.seatal的TCC模式，AP,性能较好，不过需要人工编码实现
4.MQ模式实现分布式事务，在A服务写数据的时候，需要在同一个事务内发送消息到另外一个事务
,异步，性能最好
