微服务Spring Cloud

Spring Cloud 5大组件有哪些

常规情况下

1. Eureka：注册中心
2. Ribbon：负载均衡
3. Feign：远程调用
4. Hystrix：服务熔断
5. Zuul、Gateway：网关

阿里巴巴组件

1. Nacos： 注册中心、配置中心
2. Ribbon： 负载均衡
3. Feign：服务调用
4. sentinel：服务保护
5. Gateway：服务网关

服务注册和发现什么意思？ Spring Cloud 如何实现服务的注册和发现

服务注册：服务的提供者需要把自己的信息注册到eureka，由euraka来保存这些信息，比如服务的名称、ip、端口等等

服务发现：消费者向eureka拉取服务列表的信息，如果服务提供者有集群，则消费者会利用负载均衡算法选择一个

服务监控：服务的提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没有收到心跳，会剔除服务

nacos与eureka的区别

1.nacos支持配置中心eureka只有注册中心

2.nacos支持服务端主动监测提供者的状态，临时实例采用心跳模式，非临时实例采用主动检测模式

3.临时实例心跳不正常会被剔除非临时实例则不会被剔除

4.nacos集群默认采用AP模式，当集群中存在非临时实例时，采用CP模式：eureka采用AP模式

Ribbon负载均衡策略有哪些？

• RoundRobinRule：简单轮询
• WeightedResponseTimeRule：按照权重来选择服务器，相应时间越长，权重越小
• RandomRule：随机选择一个可用的服务器
• ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择，如果服务器都在一个区域，进采用轮询的策略（默认） 

 什么是服务雪崩，怎么解决这个问题?

服务雪崩:一个服务失败，导致整条链路的服务都失败的情形
服务降级:服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑服务熔断:默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求

你们的微服务是怎么监控的

我们项目中采用的skywalking进行监控的
1，skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。

2，我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复

限流怎么做的?

1.nginx限流
控制速率(突发流量)，使用的桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量控制并发数，限制单个ip的链接数和并发链接的总数
2.网关限流
在spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量

Sentinel怎么实现限流的？

Sentinel通过动态管理限流规则，根据定义的规则对请求进行限流控制。具体实现步骤如下：

1. 定义资源：在Sentinel中，资源可以是URL、方法等，用于标识需要进行限流的请求。
2. 配置限流规则：在Sentinel的配置文件中定义资源的限流规则。规则可以包括资源名称、限流阈值、限流模式（令牌桶或漏桶）等。
3. 监控流量：Sentinel会监控每个资源的流量情况，包括请求的QPS（每秒请求数）、线程数、响应时间等。
4. 限流控制：当请求到达时，Sentinel会根据资源的限流规则判断是否需要进行限流控制。如果请求超过了限流阈值，则可以进行限制、拒绝或进行其他降级处理。

解释一下CAP和BASE

CAP 定理(一致性、可用性、分区容错性)
1.分布式系统节点通过网络连接，一定会出现分区问题(P）

2.当分区出现时，系统的一致性(C)和可用性(A)就无法同时满足

解决分布式事务的思想和模型:
1.最终一致思想:各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据(AP)

2.强一致思想:各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚(CP)

 你们采用哪种分布式事务解决方案?

1seata的XA模式，CP，需要互相等待各个分支事务提交，可以保证强一致性，性能差

2.seata的AT模式，AP，底层使用undolog 实现，性能好

3.seata的TCC模式，AP，性能较好，不过需要人工编码实现

接口幂等 

幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致

如果是新增数据，可以使用数据库的唯一索引

如果是新增或修改数据

分布式锁，性能较低
使用token+redis来实现，性能较好

1.第一次请求，生成一个唯-token存入redis，返回给前端·

2.第二次请求，业务处理，携带之前的token，到redis进行验证，如果存在，可以执行业务，删除token;如果不存在，则直接返回，不处理业务

 xx1-job路由策略有哪些?

xxl-job提供了很多的路由策略，我们平时用的较多就是:轮询、故障转移、分片广播.

xx1-job任务执行失败怎么解决?

路由策略选择故障转移，使用健康的实例来执行任务
设置重试次数
查看日志+邮件告警来通知相关负责人解决

如果有大数据量的任务同时都需要执行，怎么解决?

让多个实例一块去执行(部署集群)，路由策略分片广播
在任务执行的代码中可以获取分片总数和当前分片，按照取的方式分摊到各个实例执行

 查看更多

【微服务面试题（三十三道）】-CSDN博客