微服务进阶篇
文章目录
- 1、SpringCloud
-
-
- 面试快速答法
- 1.1、Eureka
- 1.2、Nacos
-
- 面试快速答法
- 1.3、Ribbon负载
-
- 小总结
- 面试快速答法
- 1.4、服务雪崩
-
- 小总结
- 面试快速答法
- 1.5、服务监控
-
- 小总结
- 面试快速答法
-
- 2、业务相关
-
- 2.1、限流
-
- Nginx限流
- 网关限流
-
- 小总结
- 面试快速答法
- 2.2、分布式事务
-
- 分布式理论CAP、BASE
-
- 小总结
- 面试快速答法
- 分布式事务解决方案
-
- 小总结
- 面试快速答法
- 2.3、接口幂等
-
- 小总结
- 面试快速答法
- 2.4、分布式任务调度
-
- 小总结
- 面试快速答法
思维导图
1、SpringCloud
Spring Cloud 5大组件有哪些？
服务注册和发现是什么意思？Spring Cloud 如何实现服务注册发现？
- 微服务中必须要使用的组件，考察我们使用微服务的程度
- 注册中心的核心作用是：服务注册和发现
- 常见的注册中心：eureka、nocas、zookeeper
面试快速答法
1.1、Eureka
服务注册和发现是什么意思？Spring Cloud 如何实现服务注册发现？
我们当时项目采用的eureka作为注册中心，这个也是spring cloud体系中的一个核心组件
-
服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如
服务名称、ip、端口等等 -
服务发现：消费者向eureka
拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用 -
服务监控：服务提供者会每隔30秒向eureka发送
心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除
1.2、Nacos
我看你之前也用过nacos、你能说下nacos与eureka的区别？
Nacos与eureka的共同点（注册中心）
①都支持服务注册和服务拉取
②都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别（注册中心）
①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
②临时实例心跳不正常会被剔除，非临时实例则不会被剔除
③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
④Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
Nacos还支持了配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因
面试快速答法
1.3、Ribbon负载
你们项目负载均衡如何实现的 ?
- 负载均衡 Ribbon，发起远程调用feign就会使用Ribbon
- Ribbon负载均衡策略有哪些 ?
- 如果想自定义负载均衡策略如何实现 ?
Ribbon负载均衡策略有哪些 ?
-
RoundRobinRule：简单轮询服务列表来选择服务器 -
WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小 -
RandomRule：随机选择一个可用的服务器 -
BestAvailableRule：忽略那些短路的服务器，并选择并发数较低的服务器
-
RetryRule：重试机制的选择逻辑
-
AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的，再选择连接数较小的实例
-
ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询
如果想自定义负载均衡策略如何实现 ?
可以自己创建类实现IRule接口 , 然后再通过配置类或者配置文件配置即可 ，通过定义IRule实现可以修改负载均衡规则，有两种方式：
小总结
你们项目负载均衡如何实现的 ?
微服务的负载均衡主要使用了一个组件Ribbon，比如，我们在使用feign远程调用的过程中，底层的负载均衡就是使用了ribbon
Ribbon负载均衡策略有哪些 ?
-
RoundRobinRule：简单轮询服务列表来选择服务器
-
WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
-
RandomRule：随机选择一个可用的服务器
-
ZoneAvoidanceRule：
区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)
如果想自定义负载均衡策略如何实现 ?
提供了两种方式：
-
创建类实现IRule接口，可以指定负载均衡策略（全局）
-
在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略（局部）
面试快速答法
1.4、服务雪崩
什么是服务雪崩，怎么解决这个问题？
-
什么是服务雪崩？
-
熔断降级（解决） Hystix 服务熔断降级
-
限流（预防）
服务降级
服务降级是服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃
其实啊，我们在项目中已经用过服务降级啦，微服务之间通过feign远程调用的时候，给它一个兜底的方案，这就是服务降级
服务熔断
Hystrix 熔断机制，用于监控微服务调用情况， 默认是关闭的，如果需要开启需要在引导类上添加注解：@EnableCircuitBreaker
如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求
小总结
什么是服务雪崩，怎么解决这个问题？
-
服务雪崩：一个服务失败，导致整条链路的服务都失败的情形
-
服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受
请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑 -
服务熔断：默认关闭，需要手动打开，如果检测到
10 秒内请求的失败率超过50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求
面试快速答法
1.5、服务监控
你们的微服务是怎么监控的？ 为什么需要监控？
我们重点看一下skywalking
skywalking：一个分布式系统的应用程序性能监控工具（ Application Performance Managment ），提供了完善的链路追踪能力， apache的顶级项目（前华为产品经理吴晟主导开源）
这里有三个概念：
- 服务（service）：业务资源应用系统（微服务）
- 端点（endpoint）：应用系统对外暴露的功能接口（接口）
- 实例（instance）：物理机
小总结
你们的微服务是怎么监控的？
我们项目中采用的skywalking进行监控的
1，skywalking主要可以 监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。
2，我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复
面试快速答法
2、业务相关
2.1、限流
你们项目中有没有做过限流 ? 怎么做的 ?
为什么要限流？
-
并发的确大（突发流量）
-
防止用户恶意刷接口
限流的实现方式：
-
Tomcat：可以设置最大连接数 单机应用可以，微服务不行
-
Nginx，漏桶算法
-
网关，令牌桶算法
-
自定义拦截器
Nginx限流
使用漏桶算法
控制速率（突发流量）
语法：limit_req_zone key zone rate
-
key：定义限流对象，binary_remote_addr就是一种key，基于客户端ip限流
-
Zone：定义共享存储区来存储访问信息，10m可以存储16wip地址访问信息
-
Rate：最大访问速率，rate=10r/s 表示每秒最多请求10个请求
-
burst=20：相当于桶的大小
-
Nodelay：快速处理
控制并发连接数
-
limit_conn perip 20：对应的key是 $binary_remote_addr，表示限制单个IP同时最多能持有20个连接。
-
limit_conn perserver 100：对应的key是 $server_name，表示虚拟主机(server) 同时能处理并发连接的总数。
网关限流
网关采用令牌桶算法限流
yml配置文件中，微服务路由设置添加局部过滤器RequestRateLimiter
-
key-resolver ：定义限流对象（ ip 、路径、参数），需代码实现，使用spel表达式获取
-
replenishRate ：令牌桶每秒填充平均速率。
-
urstCapacity ：令牌桶总容量。
小总结
你们项目中有没有做过限流 ? 怎么做的 ?
1，先来介绍业务，什么情况下去做限流，需要说明QPS具体多少
-
我们当时有一个活动（学视界项目），到了假期就会抢购课程优惠券，QPS最高可以达到2000，平时10-50之间，为了应对突发流量，需要做限流
-
常规限流（爱心雨伞项目），为了
防止恶意攻击，保护系统正常运行，我们当时系统能够承受最大的QPS是多少（压测结果）
2，nginx限流
-
控制速率（突发流量），使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量
-
控制并发数，限制单个ip的链接数和并发链接的总数
3，网关限流
-
在spring cloud gateway中支持局部过滤器
RequestRateLimiter来做限流，使用的是令牌桶算法 -
可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量
限流常见的算法有哪些呢？
比较常见的限流算法有漏桶算法和令牌桶算法
-
漏桶算法是把请求存入到桶中，以固定速率从桶中流出，可以让我们的服务做到绝对的平均，起到很好的限流效果
-
令牌桶算法在桶中存储的是令牌，按照一定的速率生成令牌，每个请求都要先申请令牌，申请到令牌以后才能正常请求，也可以起到很好的限流作用
它们的区别是，漏桶和令牌桶都可以处理突发流量，其中漏桶可以做到绝对的平滑，令牌桶有可能会产生突发大量请求的情况，一般nginx限流采用的漏桶，spring cloud gateway中可以支持令牌桶算法
面试快速答法
2.2、分布式事务
分布式理论CAP、BASE
解释一下CAP和BASE
-
分布式事务方案的指导
-
分布式系统设计方向
-
根据业务指导使用正确的技术选择
CAP定理
1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：
-
Consistency（一致性）
-
Availability（可用性）
-
Partition tolerance （分区容错性）
Eric Brewer 说，分布式系统无法同时满足这三个指标。
这个结论就叫做 CAP 定理。
CAP定理- Consistency
Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致
CAP定理- Availability
Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝
CAP定理-Partition tolerance
Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务
结论：
-
分布式系统节点之间肯定是需要网络连接的，
分区（P）是必然存在的 -
如果保证访问的高可用性（A）,可以持续对外提供服务，但不能保证数据的强一致性–>
AP -
如果保证访问的数据强一致性（C）,就要放弃高可用性 -->
CP
BASE理论
小总结
解释一下CAP和BASE
CAP 定理(一致性、可用性、分区容错性)
-
分布式系统节点通过网络连接，一定会出现分区问题（P）
-
当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足
BASE理论
-
基本可用
-
软状态
-
最终一致
解决分布式事务的思想和模型：
-
最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据（AP）
-
强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚（CP）
面试快速答法
分布式事务解决方案
你们采用哪种分布式事务解决方案？
-
简历上写的是微服务项目
-
Seata框架(XA、AT、TCC)
-
MQ
Seata架构
Seata事务管理中有三个重要的角色：
-
TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
-
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
-
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
seata的XA模式（CP：保证事务的强一致性）
RM一阶段的工作：
①注册分支事务到TC
②执行分支业务sql但不提交
③报告执行状态到TC
TC二阶段的工作：
TC检测各分支事务执行状态
a. 如果都成功，通知所有RM提交事务
b. 如果有失败，通知所有RM回滚事务
RM二阶段的工作：
接收TC指令，提交或回滚事务
AT模式原理（AP:高可用）
AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
阶段一RM的工作：
-
注册分支事务
-
记录undo-log（数据快照）
-
执行业务sql并提交
-
报告事务状态
阶段二提交时RM的工作：
- 删除undo-log即可
阶段二回滚时RM的工作：
- 根据undo-log恢复数据到更新前
TCC模式原理（AP:高可用）
1、Try：资源的检测和预留；
2、Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
3、Cancel：预留资源释放，可以理解为try的反向操作。
MQ分布式事务
小总结
你们采用哪种分布式事务解决方案？
简历上写的微服务，只要是发生了多个服务之间的写操作，都需要进行分布式事务控制
描述项目中采用的哪种方案（seata | MQ）(四选一)
-
seata的XA模式，CP，需要互相等待各个分支事务提交，可以保证强一致性，性能差 银行业务
-
seata的AT模式，AP，底层使用undo log 实现，性能好 互联网业务 (爱心雨伞) -
seata的TCC模式，AP，性能较好，不过需要人工编码实现 银行业务
-
MQ模式实现分布式事务，在A服务写数据的时候，需要在同一个事务内发送消息到另外一个事务，异步，性能最好 互联网业务
面试快速答法
2.3、接口幂等
分布式服务的接口幂等性如何设计？
幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。
需要幂等场景
-
用户重复点击(网络波动)
-
MQ消息重复
-
应用使用失败或超时重试机制
基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析
| 请求方式 | 说明 |
|---|---|
| GET | 查询操作，天然幂等 |
| POST | 新增操作，请求一次与请求多次造成的结果不同，不是幂等的 |
| PUT | 更新操作，如果是以绝对值更新，则是幂等的。如果是通过增量的方式更新，则不是幂等的 |
| DELETE | 删除操作，根据唯一值删除，是幂等的 |
那么如何解决呢，这里提供三种解决方案
小总结
分布式服务的接口幂等性如何设计？
幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致
-
如果是新增数据，可以使用数据库的唯一索引
-
如果是新增或修改数据
- 分布式锁，性能较低
- 使用token+redis来实现，性能较好
- 第一次请求，生成一个唯一token存入redis，返回给前端
- 第二次请求，业务处理，携带之前的token，到redis进行验证，如果存在，可以执行业务，删除token；如果不存在，则直接返回，不处理业务
面试快速答法
2.4、分布式任务调度
你们项目中使用了什么分布式任务调度 xxl-job
首先，还是要描述当时是什么场景用了任务调度
xxl-job解决的问题
-
解决集群任务的重复执行问题
-
cron表达式定义灵活
-
定时任务失败了，重试和统计
-
任务量大，分片执行
1.xxl-job路由策略有哪些？
2.xxl-job任务执行失败怎么解决？
3.如果有大数据量的任务同时都需要执行，怎么解决？
小总结
xxl-job路由策略有哪些？
xxl-job提供了很多的路由策略，我们平时用的较多就是：轮询、故障转移、分片广播…
xxl-job任务执行失败怎么解决？
-
路由策略选择故障转移，使用健康的实例来执行任务
-
设置重试次数
-
查看日志+邮件告警来通知相关负责人解决
如果有大数据量的任务同时都需要执行，怎么解决？
-
让多个实例一块去执行（部署集群），路由策略分片广播
-
在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行
面试快速答法
