SpringCloud（5）大组件有哪些？
注册中心：Eureka (Nacos)
负载均衡：Ribbon
远程调用：Feign
服务熔断：Hystrix 服务保护（sentinel）
网关：Zuul/GateWay
配置中心SprngCloudConfig
注册中心
什么是服务注册和服务发现？服务SpringCloud如何实现服务注册发现？
服务注册：服务提供者需要把自己的信息注册到eureka,由eureka来保存这些信息，比如服务名称、ip、端口等等。
服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用。
服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除。
eureka和nacos的区别
eureka和nacos的共同点（注册中心）
1.都支持服务注册和服务发现
2.都支持服务提供者心跳方式做健康检测
区别：
1.naocs支付服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式。
2.临时实例心跳不正常会被剔除，非临时实例则不会被剔除。
3.nacos支持服务列表变更的消息推送模式，服务列表更新更及时
4.naocs集群默认采用ap方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
nacos还支持配置中心
负载均衡Ribbon
feign的底层就是使用ribbon实现的
Ribbon负载均衡策略有哪些
1.轮询
2.按照权重来选择服务器，响应时间越长，权重越小
3.随机选择
4.选择并发数较低的
5.重试机制，发现哪个服务不能用了，就按指定的时间进行重试
6.可用性敏感策略，先过滤非健康的，再选择连接数较小的实例
7.以区域可用的服务器为基础进行服务器选择，再对同一个机房中的多个服务轮询
如何自定义负载均衡策略
可以创建类实现IRule接口，然后通过配置类或者配置文件配置即可
什么事服务雪崩，怎么解决这个问题
服务雪崩：一个服务失败，导致整条链路的服务都失败的情形。
熔断降级（解决）：hystix服务熔断降级
限流（预防）
服务降级：确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在开发中与feign接口结合，编写降低逻辑。
服务熔断：默认关闭，需收到打开，如果检测到10s内请求的失败率超过50%，就会触发熔断机制，之后每隔5秒尝试请求微服务，如果不可以访问，继续熔断，如果可以访问，关闭熔断，恢复正常请求。
服务监控
skywalking
一个分布式系统的应用程序性能检测工具，提供了完善的链路追踪能力
1.skywolking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化
2.我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复。
微服务限流
nginx限流
采用漏桶算法，让请求以固定速率处理请求，可以应对突发的流量，也可以控制并发数
网关限流
springcloudgateway主要采用的是令牌桶算法，可以设置每秒填充的平均速率，和令牌桶总容量。
CAP与BASE
CAP定理（一致性、可用性、分区容错性）
1.分布式系统节点通过网络连接，一定会出现分区问题（p）
2.当分区出现时，系统的一致性（C）和可用性(A）就无法同时满足
BASE理论
1.基本可用
2.软状态
3.最终一致
解决分布式事务的思想和模型：
1.最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据（AP）
2.强一致性思想：各分支事务执行完业务不要提交，等待彼此结果，而后统一提交或回滚（CP）
如何解决分布式系统的事务
seata | MQ
1.seata的XA模式，CP，需要互相等待各个分支事务提交，可以保留强一致性，性能差
2.seata的AT，AP，底层使用undo log实现，性能好
3.seata的TCC模式，AP，性能较好，不过需要人工编码实现
4.MQ模式实现分布式事务，在A服务写数据的时候，需要在同一个事务内发送消息到另外一个事务异步，性能最好。
分布式服务如何保证接口的幂等性
幂等：多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单词调用的结果一致。
如果是新增数据，可以使用数据库的唯一索引
如果是新增或修改数据：
分布式锁，性能较低
使用token+redis来实现，性能较好。
第一次请求，生成一个唯一token存入redis，返回给前端
第二请求，业务处理，携带之前的token,到redis进行验证，如果存在，可以执行业务，删除token，如果不存在，则直接返回，不处理业务。