一、Spring Cloud5大组件:
通常情况下:
Eureka:注册中心
Ribbon:负载均衡
Feign:远程调用
Hystrix:服务熔断
Zuul/Gateway:网关
二、服务注册和发现:
1.Eureka的作用:
(1).服务注册:服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
(2).服务发现:消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
(3).服务监控:服务提供者会每隔30s向eureka发送心跳，报告健康状态等，如果eureka服务90s没有接收到心跳，从eureka中删除
2.nacos与eureka的区别:
共同点:
a.都支持服务注册和服务拉取
b.都支持服务提供者心跳方式做健康检测
区别:
a.Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式，非临时实例采用主动检测模式
b.临时心跳模式不正常会被剔除，非临时实例则不会被剔除
c.Nacos支持服务列表变更的消息推送模式，服务列表更新更加及时
d.Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式，Eureka采用AP方式
Nacos还支持配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因
三、项目负载均衡:
1.Ribbon负载均衡策略:
(1).RoundRobinRule:简单轮询服务列表来选择服务器
(2).WeightedResponseTimeRule:按照权重来选择服务器，响应时间越长权重越小
(3).RandomRule:随机选择一个可用的服务器
(4).BestAvailableRule:忽略那些短路的服务器，并选择并发数较低的服务器
(5).RetryRule:重试机制的选择逻辑
(6).AvailablilityFilteringRule:可用性敏感策略，先过滤非健康的，再选择连接数较小的实力
(7).ZoneAvoidanceRule:以区域可用的服务器为基础进行服务器的选择，使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等，而后再对Zone内的多个服务做轮询
2.自定义负载均衡策略:
可以自己实现IRule接口，然后再通过配置类或配置文件配置即可，通过定义IRule实现可以修改负载均衡规则，有两种方法:
(1).全局:创建类实现IRule接口，可以指定负载均衡策略
(2).局部:在客户端的配置文件中可以配置某一个服务调用的负载均衡策略
3.项目的负载均衡如何实现:
微服务的负载均衡主要使用了一恶搞组件Ribbon，比如在使用feign远程调用的过程中底层的负载均衡就是使用了ribbon
四、服务雪崩:
1.服务雪崩:
一个服务的失败导致整条链路的服务都失败的情形
2.服务降级:
服务降级是服务自我保护的一种方式，或保护下游服务的一种方式，用于确保服务不会受请求突然增加的影响变得不可用，确保服务不会崩溃。一般在实际开发中与feign接口整合，编写降级逻辑
3.服务熔断:
Hystrix熔断机制用于监控微服务调用情况，默认是关闭的，如果需要开启要在引导类上添加注解:@EnableCircuitBreaker，如果检测到10秒内请求的失败率超过50%，就触发熔断机制，之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制，如果微服务可达，则关闭熔断机制，恢复正常请求
四、微服务的监控:
1.为什么需要服务监控:
问题定位、性能分析、服务关系、服务告警
2.skywalking:
一个分布式系统的应用程序性能监控工具，提供了完整的链路追踪能力，是apache的顶级项目
服务:业务资源应用系统
端点:应用程序对外暴露的功能接口
实例:物理机
项目中可以采用skywalking进行监控，skywalking主要可以监控接口、服务、物理实例的一些状态，特别是在压力测试的时候可以看到众多服务中哪些服务和接口比较慢，可以针对性的进行分析和优化。还可以在skywalking中设置告警规则，在项目上线后如果报错可以设置给相关负责人发送短信和邮件，第一时间告知项目的bug情况并及时修复
五、业务相关:
1.项目限流:限流的原因在于并发大并且需要防止用户恶意刷接口
2.限流的方式:
(1).Tomcat:设置最大连接数
(2).Nginx:漏桶算法、控制速率(突发流量)
(3).网关、令牌桶算法
(4).自定义拦截器
六、CAP和BASE
1.CAP理论:
分布式系统有三个指标:一致性、可用性、和分区容错性，分布式系统无法同时满足这三个指标
Consistency(一致性):用户访问分布式系统中的任意节点得到的数据必须是一致的
Availability(可用性):用户访问集群中的任意健康节点，必须能够得到相应，而不是超时或拒绝
Partition(分区):因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立分区
容错(Tolerance):在集群出现分区时整个系统也要持续对外提供服务
结论:
分布式系统节点之间肯定是需要网络链接，分区是必然存在的
如果保证访问的高可用性，可以持续对外提供服务，但不能保证数据的强一致性
如果保证数据的强一致性，就要放弃高可用性
2.BASE理论:
BASE理论是对CAP的一种解决思路，包含三个思想:
Basically Available:分布式系统在出现故障时，允许损失部分可用性，确保核心可用
Soft State:在一定时间内允许出现中间状态，比如临时的不一致性
Eventually Consistent(最终一致性):虽然无法保证强一致性，但是在软状态结束后最终达到数据一致
七、分布式事务解决方案:
Seata架构:
Seata事务管理中有三个重要的角色:
TC(Transaction Coordinator)事务协调者:维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager)事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM(Resource Manager)资源管理器:管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
Seata的XA模式:
Seata的AT模式:
TCC模式:
八、接口幂等性:
幂等:多次调用方法或接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致
需要幂等的场景:用户重复点击、MQ消息重复、应用使用失败或超时重试机制
如果是新增数据，可以使用数据库的唯一索引确保幂等性
如果是新增数据或修改数据，可以使用分布式锁或Token+redis实现
基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析:
token+redis解决幂等问题:
第一次请求:生成一个唯一的token存入redis，返回给前端
第二次请求:业务处理，携带之前的token到redis中进行验证，如果存在这可以执行业务，删除token，若不存在则直接返回，不处理业务
分布式锁解决幂等问题:
九、分布式任务调度:xxl-job
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.如果有大数据量的任务同时都需要执行，如何解决？
执行器集群部署时，任务路由策略选择分片广播情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务
