微服务面试题及原理

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：新增+更新分布式锁：新增+更新 2.3.1 token+redis（性能较好）

保证只有一个请求而非多个请求拿到token，从而正常处置惩罚业务，保证幂等性

2.3.2 分布式锁（性能较低）

• 快速失败（抢不到锁的线程）
  
• 控制锁的粒度（越小越好，防止壅闭其他线程）
  

2.4 任务调度

XXL-JOB是一个分布式任务调度平台，其核心计划目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用
xxl-job解决的题目

• 解决集群任务的重复执行题目
  
• cron表达式界说灵活
  
• 定时任务失败了，重试和统计
  
• 任务量大，分片执行
  

• xxl-job路由策略有哪些？
  处置惩罚背景定时任务（负载均衡）
  xxl-job提供了很多的路由策略，我们平常用的较多就是：轮询、故障转移、分片广播…
  
  
  
  
• xxljob任务执行失败怎么解决？
  

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

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

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。