Spring Cloud微服务（面试题）

Spring Cloud 5大组件有哪些？

• Eureka：注册中心
• Ribbon：负载均衡
• Feign：远程调用
• Hystrix：服务熔断
• Zuul/Gateway：网关

SpringCloudAlibba：

• Nacos：注册中心/配置中心
• Ribbon：负载均衡
• 服务调用：Feign
• 服务保护：sentinel
• 服务网关：Gateway

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

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

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

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

nacos与eureka的区别？

•  nacos与eureka的共同点（注册中心）

1. 都支持服务注册和服务拉取
2. 都支持服务提供者心跳方式做健康检测

• Nacos与Eureka的区别（注册中心）

1. Nacos支持服务端主动检查提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
2. 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
3. Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
4. Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式。Eureka采用AP方式

• Nacos还支持配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因

负载均衡怎么实现？

 微服务的负载均衡主要使用了一个组件Ribon，比如，我们在使用Feing远程调用的过程中，底层的负载均衡就是使用了Ribbon

负载均衡的策略有哪些？

RoundRobinRule：简单轮询服务列表来选择服务器

WeightedResponseTimeRule：按权重来选择服务器，响应时间越长，权重越小

RandomRule：随机选择一个可用的服务器

BestAvailableRule：忽略那些短路的服务器，并选择并发数较低的服务器

RetryRule：重试机制的选择逻辑

AvailabilityFilteringRule：以区域可用的服务器为基础进行服务器的选择，使用Zone对服务器进行分类，这个Zone可以理解为一个机房，一个机架等，而后再对Zone内的多个服务器做轮询

如果想自定义负载均衡策略如何实现？

可以自己创建类实现Rule接口，然后再通过配置类或者配置文件配置即可，通过定义IRule实现可以修改负载均衡规则，在两种方式：

1. 创建类实现IRule接口，可以指定负载均衡策略（全局）
2. 在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略（局部）

什么时服务雪崩，怎么解决这个问题？

服务雪崩：一个服务失败，导致整条链路的服务都失败的情形

服务降级：服务自我保护的一种方式，或者保护下游的一种方式，用于确保服务不会请求突增影响得不可用，确保服务不会奔溃，一般实际开发中与feign接口整合，编写降级逻辑

服务熔断：默认关闭，需要手动打开，如果监测到10秒内请求得失败率超过50%，就触发熔断机制。之后每隔5秒重试尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求

微服务是怎么监控的？

skywalking

一个分布式系统的应用程序性能监控工具（Application Performacce Managment），提供了完善的链路追踪能力。

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

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

项目中有没有做过限流？怎么做的？

nginx限流

• 控制速率（突发流量），使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量
• 控制并发数，限制单个ip的链接数和并发连接数的总数

网关限流

• 在spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法
• 可以根据ip或路径进行限流，可以设置每秒填充平均速率和令牌总容量

解释一下CAP和BASE？

CAP定理

• Consistency（一致性）

        用户访问分布式系统中的任意节点，得到的数据必须一致

• Availability（可用性）

        用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝

• Partition tolerance（分区容错性）

        Partition：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区

        tolerance：在集群出现分区时，整个系统也要持续对外提供服务

1. 分布式系统节点之间肯定是需要网络连接的，分区（P）是必然存在的
2. 如果保证访问的高可用性（A），可以持续对外提供服务，但不能保证数据的强一致性 ---> AP
3. 如果保证访问的数据强一致性（C），就要放弃高可用性  --->  CP

BASE理论

• Basically Available（基本可用）：分布式系统在出现故障时，运行损失部分可用性，即保证核心可用
• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致性状态。
• Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终到达数据一致

解决分布式事务的思想和模型：

1. 最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据（AP）
2. 强一致思想：各分支事务执行完业务不提交，等待彼此结果，而后统一提交或回滚（CP）

采用那种分布式事务解决方案？

1. Seata的XA模式：CP，需要相互等待各个分支事务提交，可以保证强一致性，性能差
2. Seata的AT模式：AP，底层使用undo log实现，性能好
3. Seata的CCT模式：AP，性能较好，不过需要人工编写实现
4. MQ模式实现分布式事务，在A服务写数据的时候，需要在同一个事务内发送消息到另外一个事务，异步，性能最好

分布式服务的接口幂等性如何设计？

• 幂等：多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。
• 如果是新增数据，可以使用数据库的唯一索引
• 如果时新增或修改数据
  • 分布式锁，性能较低
  • 使用token+redis来实现，性能较好

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

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

分布式任务调度

xxl-job路由策略有哪些？

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

xxl-job任务执行失败怎么解决？

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

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

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