目录
- [Spring Cloud 5大组件](#Spring Cloud 5大组件)
- 服务雪崩、降级、熔断
- 微服务是怎么监控的？
- 有没有做过限流？怎么做
- CAP理论；BASE理论
- 采用哪种分布式事务解决方案
- xxl-job相关
Spring Cloud 5大组件
早期我们一般认为的Spring Cloud五大组件是
Eureka : 注册中心
Ribbon : 负载均衡
Feign : 远程调用
Hystrix : 服务熔断
Zuul/Gateway : 网关
随着SpringCloudAlibaba在国内兴起 , 我们项目中使用了一些阿里巴巴的组件
注册中心/配置中心 Nacos
负载均衡 Ribbon
服务调用 Feign
服务保护 sentinel
服务网关 Gateway
服务注册发现；nacos与eureka的区别
服务注册发现是什么意思？如何实现？
主要三块大功能，分别是服务注册 、服务发现、服务状态监控，我们当时项目采用的eureka作为注册中心，这个也是spring cloud体系中的一个核心组件
服务注册 ：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
服务发现 ：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除
nacos与eureka的区别？
选择nacos还有一个重要原因就是它支持配置中心，不过nacos作为注册中心，也比eureka要方便好用一些，主要相同不同点在于几点：
共同点:Nacos与eureka都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测
区别 ：
①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
②临时实例心跳不正常会被剔除，非临时实例则不会被剔除
③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
④Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
Nacos的服务实例分为两种类型：
临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。
负载均衡；Ribbon负载均衡策略；自定义负载均衡策略
你们项目负载均衡如何实现的 ?
在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现 ,Feign的底层已经自动集成了Ribbon , 使用起来非常简单。当发起远程调用时，ribbon先从注册中心拉取服务地址列表，然后按照一定的路由策略选择一个发起远程调用，一般的调用策略是轮询
Ribbon负载均衡策略有哪些 ?
| 内置负载均衡规则类 | 规则描述 |
|---|---|
| RoundRobinRule | 简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。 |
| AvailabilityFilteringRule | 对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为"短路"状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。 |
| WeightedResponseTimeRule | 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。 |
| ZoneAvoidanceRule | 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。 |
| BestAvailableRule | 忽略那些短路的服务器，并选择并发数较低的服务器。 |
| RandomRule | 随机选择一个可用的服务器。 |
| RetryRule | 重试机制的选择逻辑 |
如果想自定义负载均衡策略如何实现 ?
提供了两种方式：
1，创建类实现IRule接口，可以指定负载均衡策略，这个是全局的，对所有的远程调用都起作用
2，在配置文件中，可以配置某一个服务调用的负载均衡策略，只是对配置的这个服务生效远程调用
服务雪崩、降级、熔断
什么是服务雪崩，怎么解决这个问题？
服务雪崩 是指一个服务失败，导致整条链路的服务都失败的情形，一般我们在项目解决的话就是两种方案，第一个是服务降级，第二个是服务熔断，如果流量太大的话，可以考虑限流
服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑
服务降级是为了在服务器承受超高压力时，确保核心业务可用性而采取的一种策略。由于服务器的资源有限，但请求量通常是无限的，在并发访问高峰期，一些非核心服务可能因请求过多而导致响应变慢或宕机。通过服务降级，可以选择暂时停止对非核心服务的处理或以更简单的方式应对请求，从而释放资源。
具体而言，当系统监测到某些服务的负载达到临界点时，可以对高负载的服务进行降级处理，例如直接返回预设的错误信息（fallback），而不是处理所有请求。尽管用户可能会遭遇部分功能失效，但整体系统的稳定性和核心功能的可用性得以维持，以实现"舍小保大"的目标。
服务熔断：默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求
服务熔断则是防止微服务架构中雪崩效应的保护机制。当某个微服务故障或响应时间过长时，熔断机制能迅速中断对该服务的调用，避免发生层叠故障。其工作原理类似电路中的熔断器：电压过高时会切断电路以保护系统。在微服务环境中，如果某个服务（例如服务C）频繁出现故障或超时，熔断器就会捕捉到这种情况，自动停止对服务C的调用并返回错误信息给服务B，从而保护整个调用链的健全。当服务C恢复正常后，熔断器会自动重启，恢复对其的调用。
Sentinel会实时监控微服务之间的调用状态，一旦检测到失败调用的数量超过预设阈值，就会触发熔断。在熔断状态下，服务会迅速返回错误响应，从而避免等待造成的进一步资源浪费。
微服务是怎么监控的？
一些回答：我们项目中采用的skywalking进行监控的
1，skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。
2，我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复
我们通常会从以下几个方面进行监控：
- 性能监控：阿里的Sunfire设计用于实现对分布式系统中各类资源和应用的全方位监控，包括但不限于服务器性能指标（如CPU、内存、磁盘I/O）、网络状况、服务状态、应用程序性能指标等，并且能够实时收集和分析数据，一旦检测到预设的异常或阈值被突破，立即触发告警通知，确保问题能被及时发现和处理。
- 链路追踪：阿里的EagleEye（鹰眼）：是分布式调用跟踪系统，就是对一次前端请求产生的分布式调用都汇总起来作分析。TraceId: 是标明一次前端请求的全局唯一的调用链ID。在前端请求到达到服务器时，应用容器在执行实际业务处理之前，会先根据EagleEye的埋点逻辑，生成TraceId。
- 日志监控：阿里的SLS（Log Service）是专为大规模日志管理和分析打造的服务，能采集、存储、分析并可视化来自各类环境的日志数据，服务于运维监控、安全审计等多种场景。其核心功能包括：
-
- 灵活采集：通过Logtail、SDK、API及云产品集成自动推送，全面收集ECS、K8s、自建机房等环境日志。
实时处理：支持流式处理引擎，利用SQL、DataFlow进行数据即时清洗、转换和聚合，加速信息提取。
存储与索引优化：提供成本效益高、持久的存储方案，自动建立日志索引，提升查询效率。
强大查询分析：采用类SQL查询语言，支持复杂筛选、统计及分析，加速问题定位与解决。
可视化监控告警：可创建多样化仪表板，直观展示分析结果，并设定日志触发的实时监控与告警，确保快速响应。
数据流转与集成：便捷地将处理后的日志数据投递至其他阿里云服务或外部系统，促进深度分析与长期存储。
- 灵活采集：通过Logtail、SDK、API及云产品集成自动推送，全面收集ECS、K8s、自建机房等环境日志。
有没有做过限流？怎么做
我当时做的xx项目，采用就是微服务的架构，因为xx因为，应该会有突发流量，最大QPS可以达到2000，但是服务支撑不住，我们项目都通过压测最多可以支撑1200QPS。因为我们平时的QPS也就不到100，为了解决这些突发流量，所以采用了限流。
版本1
我们当时采用的nginx限流操作，nginx使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量，我们控制的速率是按照ip进行限流，限制的流量是每秒20
版本2我们当时采用的是spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法，可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量
常见限流算法。一般nginx限流采用的漏桶，spring cloud gateway中可以支持令牌桶算法
CAP理论；BASE理论
什么是CAP理论
CAP主要是在分布式项目下的一个理论。包含了三项，一致性、可用性、分区容错性
一致性 (Consistency)是指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致(强一致性)，不能存在中间状态。
可用性 (Availability) 是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容错性(Partition tolerance) 是指分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
为什么分布式系统中无法同时保证一致性和可用性？
对于分布式系统而言，分区容错性是一个最基本的要求，因此基本上我们在设计分布式系统的时候只能从一致性（C）和可用性（A）之间进行取舍。
如果保证了一致性（C）：对于节点N1和N2，当往N1里写数据时，N2上的操作必须被暂停，只有当N1同步数据到N2时才能对N2进行读写请求，在N2被暂停操作期间客户端提交的请求会收到失败或超时。显然，这与可用性是相悖的。
如果保证了可用性（A）：那就不能暂停N2的读写操作，但同时N1在写数据的话，这就违背了一致性的要求。
什么是BASE理论
BASE是CAP理论中AP方案的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。它的思想包含三方面：
1、Basically Available（基本可用）：基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。
2、Soft state（软状态）：即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
3、Eventually consistent（最终一致性）：强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
采用哪种分布式事务解决方案
我们当时是xx项目，主要使用到的seata的at模式解决的分布式事务seata的AT模型分为两个阶段：
1、阶段一RM的工作：① 注册分支事务 ② 记录undo-log（数据快照）③执行业务sql并提交 ④报告事务状态
2、阶段二提交时RM的工作：删除undo-log即可
3、阶段二回滚时RM的工作：根据undo-log恢复数据到更新前
at模式牺牲了一致性，保证了可用性，不过，它保证的是最终一致性
xxl-job相关
xxl-job路由策略有哪些？
xxl-job提供了很多的路由策略，我们平时用的较多就是：轮询、故障转移、分片广播...
xxl-job任务执行失败怎么解决？
有这么几个操作
第一：路由策略选择故障转移，优先使用健康的实例来执行任务
第二，如果还有失败的，我们在创建任务时，可以设置重试次数
第三，如果还有失败的，就可以查看日志或者配置邮件告警来通知相关负责人解决
如果有大数据量的任务同时都需要执行，怎么解决？
我们会让部署多个实例，共同去执行这些批量的任务，其中任务的路由策略是分片广播
在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行就可以了