SpringCloud

Spring Cloud

Spring Cloud Alibaba5大组件有哪些？

​ 服务注册和配置中心 Nacos，负载均衡 Ribbon，服务调用 Feign，服务保护（包括限流降级熔断） sentinel，服务的网关 Gateway

注：每个微服务都要注册和配置一些东西需要 Nacos，一个微服务部署集群即多个实例还要用到负载均衡Ribbon，服务间互相调用需要Feign，服务想对外暴露接口还要网关 Spring Cloud Gateway，为了不让服务挂需要限流，如果服务挂了为了防止服务雪崩导致整条链路的上游服务全都失败需要给服务降级，当降级次数超过阈值，就会触发服务熔断，都需要sentinel。

分布式项目的CAP理论

CAP（Consistency, Availability, Partition Tolerance）理论就是一致性，可用性和分区容错性，最多满足两个。而分区容错性必须要保证，所以要么CP（强一致性，等节点恢复），要么AP（就是最终一致性，先返回旧数据）。（比如一个mysql主库，俩从库。b从库与主库网络不通，分成两个区。p是分了区还能查，a是要能立刻查到但只能是旧数据。c等节点恢复，查询结果要正确。）

Base(Basically Available（基本可用类似A）,Soft State（软状态,短暂数据不一致）,Eventually Consistent（最终一致性）)理论是对CAP的一种解决方法，允许损失部分可用性，保证核心可用，允许出现软状态也就是临时不一致，保证最终一致性。

分布式事务

分布式事务
cp强一致性，等待彼此的结果，等统一提交或者回滚或者AP就是最终一致性，如果不一致，想办法恢复数据

分布式事务一般用Seata或MQ解决 。
TC（Transaction Coordinator）事务协调器，维护全局事务和分支事务状态，协调全局事务提交或者回滚
TM（Transaction Manager）事务管理器，定义全局事务的范围，开始和提交回滚全局事务，
RM（Resource Manager）资源管理器，一个服务就是一个资源管理器，管理分支事务提交或者回滚

XA模式，执行业务sql但是不提交，将状态报告给事务协调者，如果都成功都提交，反之回滚。 强一致性性能差
AT模式。执行sql直接提交，记录undolog日志，状态直接提交给事务管理器，成功就删除日志，失败就回滚 一致性差性能强
TCC模式。执行sql资源预留，成就直接confirm 失败cancel,性能较好，需要编码，一致性强

MQ实现 A事务操作的时候， 发送mq消息到另一个事务，异步操作，性能最好，一致性最差。

分布式服务的接口幂等怎么实现：保证每次调用接口和单次调用结果一致。

put请求，更新值是常量则幂等，增量更新不是幂等。

新增数据可用使用数据库唯一索引解决，新增或修改数据可用使用redis加token，进入页面时生成一个唯一token存入redis返回给前端，真正请求时，携带之前的token到redis进行验证，如果存在执行业务删除token，不存在不处理业务。

扩展

单体项目=应用部署在一个服务器上，或者把数据库单放另一个服务器。

微服务项目为提高并发量，把应用拆成多个服务，一个服务部署在一个服务器上，甚至一个服务部署集群即一个服务多个实例，一个实例一台服务器。

nacos的服务注册和发现如何实现的？
服务注册：服务提供者把自己的信息（比如服务名、ip、端口等）注册到nacos
服务发现：服务调用者要调A服务时就从nacos拉取A服务的信息，如果A服务部署了集群，调用者就用负载均衡算法，选一个服务实例去调用
服务监控：服务提供者每隔5秒向nacos发送心跳报告自己的状态，如果nacos15秒没收到服务心跳，剔除此服务

nacos特色：服务注册时默认是临时服务实例，使用心跳监测。如果设置为非临时实例，nacos会主动询问服务实例是否存活，而且非临时服务实例的信息改变后，nacos会给上游服务推送变更信息。

限流是怎么做的
tomcat设置最大连接数，nginx漏桶算法 比如一个漏桶大小为20，每秒可以处理10个请求，请求来了会进入漏桶，当漏桶满了多余的请求会等待或者抛弃（有规则可以设置）
还可以控制ip所持有的连接数进行限制和虚拟主机能同时并发处理的连接来限流
网关令牌桶算法 令牌桶的大小时固定的，以一定的速率生成令牌，满了会停止生成，只有请求申请到令牌才能继续向下运行，没有请求到的阻塞或者丢弃。
自定义拦截器 使用redis对单个用户进行限制。

Ribbon 如何实现负载均衡的 ?

Feign已经集成了Ribbon，服务调用者通过Feign远程调用A服务时，先请求ribbon，ribbon从nacos注册中心拉取A服务所有实例的信息，然后按负载均衡策略选一个服务实例发起远程调用

Ribbon负载均衡策略有哪些 ?

轮询，响应时间作为权重，随机选一个可用的服务，对可用的服务器数多的区域内的服务做轮询(默认)

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

如何自定义负载均衡策略 ?

1，创建类实现IRule接口，可以指定负载均衡策略，这个是全局的，对所有的远程调用都起作用

2，在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略，只是对配置的这个服务生效远程调用

服务雪崩就是一个服务失败导致整条链路的服务全都失败的情况。
服务降级就是在一个服务中如果一个服务变得不可以，为了确保服务不崩溃，不影响整个业务，做了降级处理，在开发中一般与feign接口一起使用，
服务熔断，默认是不会熔断的，当降级的次数过多时，超过了一定的阈值，就会触发服务熔断，之后每隔5s重新尝试请求服务，如果不响应继续熔断，如果有响应则关闭熔断。

网关的功能：转发请求到微服务（转发时也能负载均衡各实例）、安全认证（身份/权限认证）、流量控制、负载均衡、降级熔断、日志、监控、参数校验、协议转换、请求过滤。
Spring Cloud Gateway 基于 Netty 实现同步非阻塞的 I/O。基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，限流。客户端的请求符合断言匹配规则就请求经过过滤器处理后路由到具体的服务的uri。服务处理后，经过过滤器处理，最后返回给客户端。；
一个路由规则可以包含多个断言。需要同时满足。一个请求匹配多个路由，则映射第一个路由。；
基于配置文件或代码配置的方式需要重启。 Spring Cloud Gateway 基于 Nacos 注册中心获取服务的元数据，网关会自动地调整路由规则。
Spring Cloud Gateway 的过滤器 Pre 类型：在请求被转发到微服务之前，对请求进行拦截和修改，例如参数校验、权限校验、流量监控、日志输出以及协议转换等操作。Post 类型：微服务处理完请求后，返回响应给网关，网关可以再次进行处理，例如修改响应内容或响应头、日志输出、流量监控等。GatewayFilter：局部过滤器，应用在单个路由或一组路由上的过滤器。GlobalFilter：全局过滤器，应用在所有路由；
Spring Cloud Gateway 可以结合 Sentinel 实现限流（网关流量控制）；
Spring Cloud Gateway 提供了多种全局异常处理的方式，比较常用的一种是实现ErrorWebExceptionHandler并重写其中的handle方法。
UUID :优点：生成快、简单。缺点：存储空间大（32 位的16进制数，128 bit位）、无序（非自增）、没有具体业务含义、重复 ID （机器时间不对，可能会产生重复 ID）Snowflake(雪花算法):

说下nacos与eureka的区别？

我们当时xx项目就是采用的nacos作为注册中心，选择nacos还要一个重要原因就是它支持配置中心，不过nacos作为注册中心，也比eureka要方便好用一些，主要相同不同点在于几点：

• 共同点
  Nacos与eureka都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测
• Nacos与Eureka的区别
  ①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
  ②临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  ③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
  ④Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

使用的分布式任务调度xxl-job
提供了很多路由策略，任务去找机器运行的方式就是路由策略，我们常用的就是轮询，故障转移，分片广播
任务执行失败选择故障转移，选择健康的实例来执行任务，尝试重试，查看日志然后发送邮件给相关负责人去解决，
如果有大量的任务需要执行可以部署集群，分片广播，可以查询获取总分片数，和当前分片，这个时是按照取模的方式分摊到各个实例执行。

xxl-job任务执行失败怎么解决？

路由策略选故障转移，设置重试次数。如果还有失败的，就配置邮件告警来通知相关负责人查看日志解决

如果有大数据量的任务同时都需要执行，怎么解决？
部署多个执行器实例，共同去执行这些批量的任务，任务的路由策略是分片广播
在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行就可以了

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

服务雪崩是指一个服务失败，导致整条链路的服务都失败的情形，一般我们在项目解决的话就是两种方案，第一个是服务降级，第二个是服务熔断，如果流量太大的话，可以考虑限流

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

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

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

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

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

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

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

我当时做的xx项目，采用就是微服务的架构，因为xx因为，应该会有突发流量，最大QPS可以达到2000，但是服务支撑不住，我们项目都通过压测最多可以支撑1200QPS。因为我们平时的QPS也就不到100，为了解决这些突发流量，所以采用了限流。

【版本1】

我们当时采用的nginx限流操作，nginx使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量，我们控制的速率是按照ip进行限流，限制的流量是每秒20

【版本2】

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

限流常见的算法有哪些呢？

比较常见的限流算法有漏桶算法和令牌桶算法

漏桶算法是把请求存入到桶中，以固定速率从桶中流出，可以让我们的服务做到绝对的平均，起到很好的限流效果

令牌桶算法在桶中存储的是令牌，按照一定的速率生成令牌，每个请求都要先申请令牌，申请到令牌以后才能正常请求，也可以起到很好的限流作用

它们的区别是，漏桶和令牌桶都可以处理突发流量，其中漏桶可以做到绝对的平滑，令牌桶有可能会产生突发大量请求的情况，一般nginx限流采用的漏桶，spring cloud gateway中可以支持令牌桶算法

面试官：什么是CAP理论？

候选人：

CAP主要是在分布式项目下的一个理论。包含了三项，一致性、可用性、分区容错性

• 一致性(Consistency)是指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致(强一致性)，不能存在中间状态。

• 可用性(Availability) 是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。

• 分区容错性(Partition tolerance) 是指分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

面试官：为什么分布式系统中无法同时保证一致性和可用性？

候选人：

嗯，是这样的~~

首先一个前提，对于分布式系统而言，分区容错性是一个最基本的要求，因此基本上我们在设计分布式系统的时候只能从一致性（C）和可用性（A）之间进行取舍。

如果保证了一致性（C）：对于节点N1和N2，当往N1里写数据时，N2上的操作必须被暂停，只有当N1同步数据到N2时才能对N2进行读写请求，在N2被暂停操作期间客户端提交的请求会收到失败或超时。显然，这与可用性是相悖的。

如果保证了可用性（A）：那就不能暂停N2的读写操作，但同时N1在写数据的话，这就违背了一致性的要求。

面试官：什么是BASE理论？

候选人：

嗯，这个也是CAP分布式系统设计理论

BASE是CAP理论中AP方案的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。它的思想包含三方面：

1、Basically Available（基本可用）：基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。

2、Soft state（软状态）：即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3、Eventually consistent（最终一致性）：强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

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

我们当时是xx项目，主要使用到的seata的at模式解决的分布式事务

seata的AT模型分为两个阶段：

1、阶段一RM的工作：① 注册分支事务 ② 记录undo-log（数据快照）③ 执行业务sql并提交 ④报告事务状态

2、阶段二提交时RM的工作：删除undo-log即可

3、阶段二回滚时RM的工作：根据undo-log恢复数据到更新前

at模式牺牲了一致性，保证了可用性，不过，它保证的是最终一致性

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

嗯，我们当时有一个xx项目的下单操作，采用的token+redis实现的，流程是这样的

第一次请求，也就是用户打开了商品详情页面，我们会发起一个请求，在后台生成一个唯一token存入redis，key就是用户的id，value就是这个token，同时把这个token返回前端

第二次请求，当用户点击了下单操作会后，会携带之前的token，后台先到redis进行验证，如果存在token，可以执行业务，同时删除token；如果不存在，则直接返回，不处理业务，就保证了同一个token只处理一次业务，就保证了幂等性

xxl-job路由策略有哪些？

xxl-job提供了很多的路由策略，我们平时用的较多就是：轮询、故障转移、分片广播…

xxl-job任务执行失败怎么解决？

有这么几个操作

第一：路由策略选择故障转移，优先使用健康的实例来执行任务

第二，如果还有失败的，我们在创建任务时，可以设置重试次数

第三，如果还有失败的，就可以查看日志或者配置邮件告警来通知相关负责人解决

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

我们会让部署多个实例，共同去执行这些批量的任务，其中任务的路由策略是分片广播

在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行就可以了