面试篇-微服务-1-Spring-cloud+服务的主从与发现+服务雪崩+服务降级+服务熔断+服务限流+CAB和Base+分布式事务

---

前言

你们项目中有使用过Spring-cloud 框架进行微服务的治理吗，你都用过Spring-Cloud 的哪些组件；你知道服务雪崩，服务降级，服务熔断吗；你们的服务限流措施怎么做的；你了解过CAB和BASE理论吗。本文重点对面试的问题进行介绍，祝愿每位程序员都能顺利上岸！！！

---

一、Spring-cloud是什么，你都知道Spring-cloud 的哪些组件？

Spring Cloud是一系列框架的有序集合，它整合了现有的一些成熟技术，如服务发现、配置管理、智能路由、负载均衡、熔断器等，用于管理和协调微服务架构中的服务。
它利用Spring Boot的开发便利性，简化了分布式系统基础设施的开发，使得开发者能够更专注于业务逻辑的实现。

1.1 服务的注册和发现以及服务的通信：

1.1.1 服务的注册与发现

1.1.1.1 Eureka 进行服务注册与发现

• 我们当时项目采用的eureka作为注册中心，这个也是spring cloud体系中的一个核心组件
• 服务注册:服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
• 服务发现:消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
• 服务监控:服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除

1.1.1.2 Nacos 进行服务注册与发现

客户端通过向Nacos 注册临时实例（实例包括 实例的命名空间，分组，服务名称，地址等信息），然后Nacos 集群进行临时实例的维护，其它服务可用通过Nacos 服务端获取到同一个命名空间，分组下的其它微服务实例信息。

你知 道Nacos 的持久化实例吗，它的作用是什么：

• 运维监控与告警：持久化实例在健康检查失败后，虽然会被标记为不健康状态，但不会从服务端删除。这允许运维人员实时查看实例的健康状态，便于后续的告警、扩容等处理措施。例如，在发现实例状态变为不健康时，运维人员可以及时采取修复措施，确保服务的稳定运行。
• 高并发与大流量场景下的保护：在高并发、大流量的场景下，服务实例可能会因为各种原因出现不稳定状态。通过设置持久化实例，即使这些实例的健康状态出现问题，也不会立即从服务列表中删除，而是保留其不健康状态。这样，在触发保护阈值时，Nacos可以将所有实例信息（包括健康和不健康的实例）提供给消费者，防止因为健康实例过少而导致的雪崩效应。虽然这可能会导致部分请求失败，但整体上保证了系统的可用性。
• 流量突增场景的弹性扩容：对于需要应对流量突增的服务，临时实例可能更为适合。然而，在流量突增之后，为了确保服务的稳定性和可维护性，部分实例可能需要被保留下来。此时，可以将这些实例注册为持久化实例，以便在需要时能够迅速恢复服务。
• 特殊业务场景：在某些特殊业务场景下，如数据库的主备切换、负载均衡等，需要确保服务实例的稳定性和可靠性。通过注册持久化实例，可以确保这些关键服务实例在出现问题时不会被误删除，从而保证业务的连续性和稳定性

1.1.1.3 Nacos 和Eureka 有什么区别吗

Nacos与eureka的共同点(注册中心)：
① 都支持服务注册和服务拉取
② 都支持服务提供者心跳方式做健康检测

Nacos与Eureka的区别(注册中心)：
① Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式，非临时实例采用主动检测模式
② 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
③ Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
④ Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式;Eureka采用AP方式
Nacos还支持了配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因

1.1.2 你们服务之间是如何通信的

在我们项目中我们使用Openfeign 组件并且使用okhttp 进行服务之间的通信，那么当一个服务调用另外一个服务时，发现有多个服务实例，它是怎么进行负载均衡的呢

1.1.2.1 openfeign 底层使用了什么进行负载均衡

负载均衡 Ribbon，发起远程调用feign就会使用Ribbon

1.1.2.2 你都知道哪些负载均衡策略

1.1.2.3 如何自定义一个负载均衡策略

可以自己创建类实现IRule接口，然后再通过配置类或者配置文件配置即可，均衡规则，有两种方式:

二、你遇到过服务雪崩吗，又是怎么进行服务降级和服务限流的

2.1 你知道服务雪崩吗

项目中有些业务往往需要调用多个微服务的接口，才能最终拿到结果；如果某个微服务出现了故障，就会导致请求全部累积到这个服务，这个服务的资源就会被逐步使用完毕，从而使得链路上调用的其它服务被拖垮。

2.2 为了避免服务雪崩你们项目中如何处理

我们项目中使用了服务降级的措施，服务降级是服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用确保服务不会崩溃。

因为openFeign 中继承hystrix组件 ，在项目中可以对feign接口定义fallbackFoctory 来实现服务的降级；

2.3 服务熔断你了解吗

Hystrix 熔断机制，用于监控微服务调用情况，默认是关闭的，如果需要开启需要在引导类上添加注解:@EnableCircuitBreaker如果检测到 10秒内请求的失败率超过50%，就触发熔断机制。之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求.

2.4 你们项目中如果对接口进行限流的

2.4.1 在网关中使用令牌桶限流

在gateway 网关服务中，我们通过redis 定义令牌桶的数量和每秒令牌桶的填充速度来控制某个服务接口的访问。

2.4.2 针对于特定的接口使用Semaphore 信号量

在Semaphore 中我们使用acquire() 或者tryAcquire() 来获取资源，在获取到资源处理业务之后通过release() 方法进行资源的释放；

import org.springframework.beans.factory.annotation.Value;  
import org.springframework.stereotype.Component;  
import org.springframework.web.bind.annotation.GetMapping;  
import org.springframework.web.bind.annotation.RestController;  
  
import java.util.concurrent.Semaphore;  
  
@RestController  
public class LimitedController {  
  
    // 假设我们在配置文件中设置了一个最大并发请求数  
    @Value("${api.max-concurrent-requests}")  
    private int maxConcurrentRequests;  
  
    // 使用Semaphore进行限流  
    private final Semaphore semaphore;  
  
    public LimitedController(@Value("${api.max-concurrent-requests}") int maxConcurrentRequests) {  
        this.maxConcurrentRequests = maxConcurrentRequests;  
        this.semaphore = new Semaphore(maxConcurrentRequests);  
    }  
  
    @GetMapping("/limited-api")  
    public String limitedApi() throws InterruptedException {  
        // 尝试获取一个许可，如果Semaphore中没有许可，则当前线程会被阻塞，直到有许可可用  
        semaphore.acquire();  
        try {  
            // 模拟接口处理逻辑  
            // ...  
            return "Processed successfully!";  
        } finally {  
            // 释放许可，无论是否出现异常  
            semaphore.release();  
        }  
    }  
}

2.5 服务雪崩，服务降级，服务雪崩，服务限流

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

三、你了解CAP和BASE理论吗

3.1 CAP理论：

3.1.1 一致性

3.1.2 可用性

3.1.3 分区容错性

3.2 BASE理论：

3.3 CAP和BASE

CAP 定理(一致性、可用性、分区容错性)

• 分布式系统节点通过网络连接，一定会出现分区问题§
• 当分区出现时，系统的一致性©和可用性(A)就无法同时满足

BASE理论

• 基本可用
• 软状态
• 最终一致

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

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

四、你们系统中用过分布式事务吗，它是怎么实现的

在项目中我们使用Seata 组件进行分布式任务的实现，它的本质还是2pc

4.1 Seata 分布式事务

Seata事务管理中有三个重要的角色:

• TC(Transaction Coordinator)-事务协调者:维护全局和分支事务的状态，协调全局事务提交或回滚。
• TM (Transattion Manager)-事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务
• RM (Resource Manager)-资源管理器:管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
  

4.2 你都用过seata 的哪些模式进行分布式事务的实现

4.2.1 XA模式

4.2.2 AP模式

4.2.3 TCC模式

---

总结

本文对微服务架构下，常用的组件面试题进行总结。