微服务进阶篇

King Gigi.

已于 2023-08-14 16:01:02 修改

阅读量783

点赞数

文章标签：微服务架构云原生

于 2023-06-29 14:32:18 首次发布

本文链接：https://blog.csdn.net/qq_56265207/article/details/131455309

版权

思维导图

在这里插入图片描述

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最高可以达到1000，平时10-50之间，为了应对突发流量，需要做限流
常规限流（爱心雨伞项目），为了防止恶意攻击，保护系统正常运行，我们当时系统能够承受最大的QPS是多少（1500）

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分布式事务

在这里插入图片描述
1、生产者发送消息做可靠性检查，确保消息真正投递出去；

2、消费者做幂等，确保业务没有重复执行；

3、消费者做异常重试，设置重试次数，当次数达到了以后，如果消息依然失败，将消息投递到异常交换机，交由人工处理；

小总结

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

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

描述项目中采用的哪种方案（seata | MQ）(四选一)

seata的XA模式，CP，需要互相等待各个分支事务提交，可以保证强一致性，性能差银行业务
seata的AT模式，AP，底层使用undo log 实现，性能好互联网业务 (爱心雨伞)
seata的TCC模式，AP，性能较好，不过需要人工编码实现银行业务
MQ模式实现分布式事务，在A服务写数据的时候，需要在同一个事务内发送消息到另外一个事务，异步，性能最好互联网业务

面试快速答法

在这里插入图片描述

2.3、接口幂等

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

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

一句话：
幂等是指一个方法被多次重复执行的时候所期望的结果和第一次执行所期望的结果保持一致，也就是说，一个逻辑即使被重复执行多次，也不影响结果的最终一致性。

需要幂等场景

用户重复点击(网络波动)
超时重试机制
MQ重复消费

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

请求方式	说明
GET	查询操作，天然幂等
POST	新增操作，请求一次与请求多次造成的结果不同，不是幂等的
PUT	更新操作，如果是以绝对值更新，则是幂等的。如果是通过`增量`的方式更新，则不是幂等的
DELETE	删除操作，根据`唯一值`删除，是幂等的

那么如何解决呢，这里提供三种解决方案

在这里插入图片描述

小总结

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

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

如果是新增数据，可以使用数据库的唯一索引，比如创建订单，订单号是唯一的，多次调用就会触发数据库的唯一约束异常。
如果是新增或修改数据
- Redis提供的setNX指令，比如对于MQ消费的场景，为了避免MQ重复消费导致数据多次被修改的问题，可以在收到MQ消息时，把这个消息写入redis，一旦这个消息被消费过，就不会再次消费。
- 使用状态机来实现幂等。状态机是指一条数据的完整运行状态的转换流程，它的状态只会向前变更，所以多次修改同一条数据的时候，一旦状态发生变更，那么对这条数据修改造成的影响只会发生一次。
- 使用token+redis来实现，性能较好
  - 第一次请求，生成一个唯一token存入redis，返回给前端
  - 第二次请求，业务处理，携带之前的token，到redis进行验证，如果存在，可以执行业务，删除token；如果不存在，则直接返回，不处理业务