八股文-微服务相关面试题

1、Spring cloud组件有哪些？

通常情况下：

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

Spring cloud Alibaba的组件：

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

2、服务注册和发现是什么意思？Spring cloud如何实现服务注册和发现？

常见的注册中心：Eureka、Nacos、Zookeeper

我们当时项目采用的Eureka作为注册中心，这个也是Spring cloud体系中的一个核心组件

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

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

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

3、说一下Nacos和Eureka的区别？

1）Nacos和Eureka的共同点：

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

2）Nacos与Eureka的区别：

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

3）Nacos还支持配置中心，Eureka只有注册中心

4、你们项目负载均衡是如何实现的？

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

5、Ribbon负载均衡策略有哪些？

• RoundRobinRule：简单轮询服务列表来选择服务器
• WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
• RandomRule：随机选择一个可用的服务器
• ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房，一个机架等。而后再对Zone内的多个服务做轮询（默认）

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

提供了两种方式：

1）创建类实现IRule接口，可以指定负载均衡策略（全局）

@Bean
public IRule randomRule(){
    return new RandomRule();
}

2）在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略（局部）

userservice:
    ribbon:
        NFloadBalaancerRuleClassName:com.netflix.loadbalancer.RandomRule #负载均衡规则

7、什么是服务雪崩？怎么解决这个问题？

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

解决方案：

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

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

8、你们的微服务是怎么监控的？

我们项目中采用的是skywalking进行监控的

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

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

9、你们项目中有没有做过限流？怎么做的？

1）介绍一下业务，说明什么情况下要去做限流

• 并发确实大（应对突发流量）
• 常规限流，为了防止恶意攻击（用户恶意刷接口）

2）Nginx限流：

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

3）网关限流：

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

10、解释一下CAP和BASE

CAP定理（一致性、可用性、分区容错性）

        1）分布式系统节点通过网络连接，一定会出现分区问题（P）

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

BASE理论

        1）基本可用：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用

        2）软状态：在一定时间内，允许出现中间状态，比如临时的不一致状态

        3）最终一致：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致

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

     1）最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据(AP)

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

11、你们采用哪种分布式事务解决方案？

简历上写的微服务，只要是发生了多个服务之间的写操作，都需要进行分布式事务控制

描述项目中采用的哪种方案（Seata|MQ）

1）Seata的XA模式，CP，需要互相等待各个分支事务提交，可以保证强一致性，性能差，常用在银行业务

2）Seata的AT模式，AP，底层使用undo log 实现，性能好，常用在互联网业务

3）Seata的TCC模式，AP，性能较好，不过需要人工编码实现，常用在银行业务

4）MQ模式实现分布式事务，在A服务写数据的时候，需要在同一个事务内发送消息到另外一个事务，异步，性能最好，常用在互联网业务

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

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

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

2）如果是新增或修改数据

        ①：分布式锁，性能较低

        ②：使用token + redis来实现，性能较好

                （第一次请求，生成一个唯一token存入redis，返回给前端。第二次请求，业务处理，携带之前的token，到redis进行验证，如果存在，可以执行业务，删除token，如果不存在，则直接返回，不处理业务）