微服务面试题及原理

1. Springcould

spring could五大组件
注册中心负载均衡网关远程调用服务熔断

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

1.1 注册中心

1.1.1 eureka

eureka是spring的核心组件

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

1.1.2 nacos

nacos是spring couldAlibaba的核心组件；
nacos在心跳检测时可以选择非临时实例，默认临时实例则和eureka一样

临时实例心跳不正常会被剔除，非临时实例则不会被剔除
Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
Nacos集群默认采用AP（高可用）方式，当集群中存在非临时实例时，采用CP（强一致）模式；Eureka采用AP方式
Nacos还支持了配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因

1.2 负载均衡

1.2.1 实现

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

1.2.2 策略

Ribbon负载均衡策略有哪些？

RoundRobinRule：简单轮询服务列表来选择服务器
WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
RandomRule：随机选择一个可用的服务器
BestAvailableRule：忽略那些短路的服务器，并选择并发数较低的服务器
RetryRule：重试机制的选择逻辑
AvailabilityFiltering Rule:可用性敏感策略，先过滤非健康的，再选择连接数较小的实例
ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询

1.2.3 自定义负载均衡

在这里插入图片描述

1.3 服务雪崩

考察复杂场景

熔断降级（解決）
限流（预防）

1.3.1 服务降级

保存文件借口失败，通过feign接口远程调用做降级“您的网络有问题，请稍后再试”
如果请求加大，降级过多会触发熔断机制
在这里插入图片描述

1.3.2 服务熔断

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

1.4 监控

skywalking一个分布式系统的应用程序性能监控工具（Application Performance Managment），提供了完善的链路追踪能力，apache的顶级项目

你们的微服务是怎么监控的？
我们项目中采用的skywalking进行监控的
1. skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。
2. 我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复

2. 业务相关

2.1 限流方案

为什么要限流？

并发的确大（突发流量）
防止用户恶意刷接口
限流的实现方式：
Tomcat：可以设置最大连接数
Nginx：漏桶算法
网关：令牌桶算法
自定义拦截器

2.1.1 Nginx 限流

漏桶算法
在这里插入图片描述

2.1.2 网关限流

令牌桶用redis实现
漏桶算法平滑，令牌桶算法有波动——处理请求速度>生成令牌速度（使用存储令牌）
在这里插入图片描述

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

先来介绍业务，什么情况下去做限流，需要说明QPS具体多少
- 我们当时有一个活动，到了假期就会抢购优惠券，QPS最高可以达到2000，平时10-50之间，为了应对突发流量，需要做限流
- 常规限流，为了防止恶意攻击，保护系统正常运行，我们当时系统能够承受最大的QPS是多少（压测结果）
nginx限流
- 控制速率（突发流量），使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量
- 控制并发数，限制单个ip的链接数和并发链接的总数
网关限流
- 在spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法
- 可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量

2.2 分布式理论

2.2.1 CAP理论

分布式系统无法同时满足这三个指标。这个结论就叫做CAP定理。
指标：

Consistency（一致性）
Availability（可用性）
Partition tolerance（分区容错性）
结论：
分布式系统节点之间肯定是需要网络连接的，分区（P）是必然存在的，当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足
如果保证访问的高可用性（A），可以持续对外提供服务，但不能保证数据的强一致性–>AP
如果保证访问的数据强一致性（C），就要放弃高可用性–>CP

2.2.2 base理论

解决思路

最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据（AP）
强一致思根：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚（CP）
BASE理论是对CAP的一种解决思路，包含三个思想：

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

2.2 事务解决方案

Seata椎架（XA、AT、TCC）
MQ

2.2.1 Seata框架

模式：XA、AT、TCC
Seata事务管理中有三个重要的角色：

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

XA（CP模式）

强一致性，需要互相等待各个分支事务提交，可以保证强一致性，性能差（银行业务）
在这里插入图片描述

AT（AP模式）

高可用性，底层使用undokog 实现，性能好（互联网业务）
在这里插入图片描述

TCC(AP模式)

性能较好，且一致性有保障，不过需要人工编码实现（银行业务）
在这里插入图片描述

在AP模式下保证数据的强一致
XA，AT可以用框架自动生成，而TCC要手写代码维护。

2.2.2 MQ分布式事务

MQ是异步的，性能比较高，实时性最差，数据一致性不高可以使用MQ方案（互联网业务）

MQ模式实现分布式事务，在A服务写数据的时候，需要在同一个事务内发送消息到另外一个事务

2.3 接口幂等性

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

用户重复点击（网络波动）
MQ消息重复
应用使用失败或超时重试机制

基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析

请求方式	说明
GET	查询操作，天然幂等
POST	新增操作，请求一次与请求多次造成的结果不同，不是幂等的
PUT	更新操作，如果是以绝对值更新，则是幂等的。如果是通过增量的方式更新，则不是幂等的
DELETE	删除操作，根据唯一值删除，是幂等的
解决方案
数据库唯一索引：新增
token+redis：新增+更新
分布式锁：新增+更新