SpringCloud 常见面试题（三）

服务网关

在微服务架构中，网关的作用是什么

在微服务架构中，网关（Gateway）具有以下作用：

• 统一入口：网关为所有的微服务提供一个唯一的入口点，从而简化了客户端与服务的交互，同时保障了后台服务的安全性。
• 鉴权校验：网关能够识别每个进来的请求，并根据其权限进行校验，阻止不符合要求的请求通过。
• 动态路由：根据需要，网关可以动态地将请求路由到不同的后端集群中，实现服务的灵活调度。
• 降低耦合度：通过在网关层做映射，可以将客户端与服务解耦，使服务可以独立发展，减少两者之间的依赖。
• 提供附加功能：网关不仅可以保护微服务，还可以为服务提供和沉淀更多附加功能，如熔断、限流等。

什么是API网关？

API网关（API Gateway）是一种中间层服务器，用于集中管理、保护和路由对后端服务的访问。它充当了客户端与后端服务之间的入口点，提供了一组统一的接口来管理和控制API的访问。

API网关的主要功能包括：

• 路由转发：API网关根据请求的URL路径或其他标识，将请求路由到相应的后端服务。通过配置路由规则，可以灵活地将请求分发给不同的后端服务。
• 负载均衡：API网关可以在后端服务之间实现负载均衡，将请求平均分发到多个实例上，提高系统的吞吐量和可扩展性。
• 安全认证与授权：API网关可以集中处理身份验证和授权，确保只有经过身份验证的客户端才能访问后端服务。它可以与身份提供者（如OAuth、OpenID Connect）集成，进行用户认证和授权操作。
• 缓存：API网关可以缓存后端服务的响应，减少对后端服务的请求次数，提高系统性能和响应速度。
• 监控与日志：API网关可以收集和记录请求的指标和日志，提供实时监控和分析，帮助开发人员和运维人员进行故障排查和性能优化。
• 数据转换与协议转换：API网关可以在客户端和后端服务之间进行数据格式转换和协议转换，如将请求从HTTP转换为WebSocket，或将请求的参数进行格式转换，以满足后端服务的需求。
• API版本管理：API网关可以管理不同版本的API，允许同时存在多个API版本，并通过路由规则将请求正确地路由到相应的API版本上。
  ……

通过使用API网关，可以简化前端与后端服务的交互，提供统一的接口和安全性保障，同时也方便了服务治理和监控。它是构建微服务架构和实现API管理的重要组件之一。

SpringCloud可以选择哪些API网关？

使用SpringCloud开发，可以采用以下的API网关选型：

• Netflix Zuul（已停止更新）：Netflix Zuul是Spring Cloud早期版本中提供的默认API网关。它基于Servlet技术栈，可以进行路由、过滤、负载均衡等功能。然而，自2020年12月起，Netflix宣布停止对Zuul 1的维护，转而支持新的API网关项目。
• Spring Cloud Gateway：Spring Cloud Gateway是Spring Cloud官方推荐的API网关，取代了Netflix Zuul。它基于非阻塞的WebFlux框架，充分利用了响应式编程的优势，并提供了路由、过滤、断路器、限流等特性。Spring Cloud Gateway还支持与Spring Cloud的其他组件集成，如服务发现、负载均衡等。
• Kong：Kong是一个独立的、云原生的API网关和服务管理平台，可以与Spring Cloud集成。Kong基于Nginx，提供了强大的路由、认证、授权、监控和扩展能力。它支持多种插件和扩展，可满足不同的API管理需求。
• APISIX：APISIX基于Nginx和Lua开发，它具有强大的路由、流量控制、插件扩展等功能。APISIX支持灵活的配置方式，可以根据需求进行动态路由、负载均衡和限流等操作。

说说你对Spring Cloud Gateway的理解

Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul 1.0网关。网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。

使用了一个RouteLocatorBuilder的bean去创建路由，除了创建路由RouteLocatorBuilder可以让你添加各种predicates和filters，predicates断言的意思，顾名思义就是根据具体的请求的规则，由具体的route去处理，filters是各种过滤器，用来对请求做各种判断和修改。

Spring Cloud Gateway核心概念？

在Spring Cloud Gateway里，有三个关键组件：

• Route（路由）：路由是Spring Cloud Gateway的基本构建块，它定义了请求的匹配规则和转发目标。通过配置路由，可以将请求映射到后端的服务实例或URL上。路由规则可以根据请求的路径、方法、请求头等条件进行匹配，并指定转发的目标URI。
• Predicate（断言）：断言用于匹配请求的条件，如果请求满足断言的条件，则会应用所配置的过滤器。Spring Cloud Gateway提供了多种内置的断言，如Path（路径匹配）、Method（请求方法匹配）、Header（请求头匹配）等，同时也支持自定义断言。
• Filter（过滤器）：过滤器用于对请求进行处理和转换，可以修改请求、响应以及执行其他自定义逻辑。Spring Cloud Gateway提供了多个内置的过滤器，如请求转发、请求重试、请求限流等。同时也支持自定义过滤器，可以根据需求编写自己的过滤器逻辑。

我们再来看下Spring Cloud Gateway的具体工作流程：

两个比较重要的概念：

• Gateway Handler（网关处理器）：网关处理器是Spring Cloud Gateway的核心组件，负责将请求转发到匹配的路由上。它根据路由配置和断言条件进行路由匹配，选择合适的路由进行请求转发。网关处理器还会依次应用配置的过滤器链，对请求进行处理和转换。
• Gateway Filter Chain（网关过滤器链）：网关过滤器链由一系列过滤器组成，按照配置的顺序依次执行。每个过滤器可以在请求前、请求后或请求发生错误时进行处理。过滤器链的执行过程可以修改请求、响应以及执行其他自定义逻辑。

什么是限流算法，网关如何实现限流

限流算法是指用于限制单位时间内服务的请求数量的算法，目的是防止服务被过高的请求压力所击垮。常见的限流算法包括计数器算法、滑动窗口算法、漏桶算法、令牌桶算法。

网关如何实现限流：

• 利用限流算法插件/模块：网关可以集成限流算法插件/模块，通过配置相关参数（如令牌桶大小、令牌生成速率等）来实现限流。例如，Spring Cloud Gateway可以使用Redis的RateLimiter限流算法插件来实现限流。
• 自定义限流逻辑：网关可以通过编程方式自定义实现限流逻辑。例如，在微服务架构中，可以在每个服务的网关层（如Nacos、Eureka等）实现限流逻辑，或者使用限流SDK（如Sentinel）对请求进行限流。
• 利用云平台提供的限流功能：一些云平台提供了自动化的限流功能，例如AWS CloudWatch、Azure Application Insights等，网关可以利用这些云平台的功能来实现限流。

你项目里为什么选择 Gateway 作为网关?

选择 Spring Cloud Gateway 的原因主要有两个：

• 以前用得比较多的是 Spring Cloud 官方开源的Zuul，其用得比较多的还是1.0 的版本，不过1.0版本 Netflix很早就宣布进入维护状态了，虽然Zuul已经出了2.0版本，但是 Spring Cloud 官方团队好像没有整合的计划，并且 Netflix 很多相关的组件，如 Eureka、Hystrix 都已经进入维护期了，所以不知道前景如间，然后 Sping doud 官方自己研发了Spring Cloud Gateway，并且大力支持和推荐，所以相比与Zuul， Gateway是一个更好的选择。
• Spring Cloud Gateway 有很多的特性：
  • 基于 Spring5和 Spring Boot 2 进行构建，与 Spring 生态兼容较好
  • 动态路由：可以根据配置条件，如 URL、请求方法等实现动态配置
  • 可以对路由指定断言(Predicate)和过滤器(Filter)
  • 集成 Hystrix 断路器功能，可以实现服务熔断
  • 集成 Spring Cloud 相关组件，如 Eureka、Nacos、Consule 等实现服务的注册与发现
  • 内置了限流模块，可以根据配置实现服务限流

Dubbo和 Spring Cloud Gateway 有什么区别?

Dubbo 是一个RPC(远程过程调用)框架，主要用于服务之间的通信。它提供高性能的 RPC 调用、负载均衡、服务发现、服务注册、服务治理等功能。适用于需要高性能 RPC 调用的分布式系统，常用于内部服务通信。

Spring Cloud Gateway是一个API 网关，用于处理外部客户端请求并将其路由到后端服务。它提供请求路由、负载均衡、协议转换、安全管理、流量控制、日志和监控等功能。适用于微服务架构中的统一入口管理，常用于外部请求的入口层。

所以说它们不是一个层级的东西。

链路追踪

为什么要用微服务链路追踪？

在微服务中，有的上下游可能有十几个服务，如果某一环出了问题，排查起来非常困难，所以，就需要进行链路追踪，来帮助排查问题。

通过链路追踪，可以可视化地追踪请求从一个微服务到另一个微服务的调用情况。除了排查问题，链路追踪黑还可以帮助优化性能，可视化依赖关系、服务监控和告警。

SpringCloud可以选择哪些微服务链路追踪方案？

Spring Cloud提供了多种选择的微服务链路追踪方案。以下是一些常用的方案：

• Zipkin：Zipkin 是一个开源的分布式实时追踪系统，由 Twitter 开发并贡献给开源社区。Spring Cloud Sleuth 提供了与 Zipkin 的集成，可以通过在微服务中添加相应的依赖和配置，将追踪信息发送到 Zipkin 服务器，并通过 Zipkin UI 进行可视化展示和查询。
• Jaeger：Jaeger 是 Uber 开源的分布式追踪系统，也被纳入了 CNCF（云原生计算基金会）的维护。通过使用 Spring Cloud Sleuth 和 Jaeger 客户端库，可以将追踪信息发送到 Jaeger 并进行可视化展示和查询。
• SkyWalking：Apache SkyWalking 是一款开源的应用性能监控与分析系统，提供了对 Java、.NET 和 Node.js 等语言的支持。它可以与 Spring Cloud Sleuth 集成，将追踪数据发送到 SkyWalking 服务器进行可视化展示和分析。
• Pinpoint：Pinpoint 是 Naver 开源的分布式应用性能监控系统，支持 Java 和 .NET。它提供了与 Spring Cloud Sleuth 的集成，可以将追踪数据发送到 Pinpoint 服务器，并通过其 UI 进行分析和监控。

这些方案都可以与 Spring Cloud Sleuth 进行集成，Spring Cloud Sleuth 是 Spring Cloud 中的一个组件，提供了在微服务调用时生成追踪信息的能力。

分布式事务

什么情况下需要用到分布式事务？有哪些方案？

分布式事务是指在多个网络节点或服务之间进行数据一致性处理的情况。以下是一些可能需要使用分布式事务的场景：

• 微服务之间通过远程调用完成事务操作：当不同的微服务之间需要进行数据一致性保证时，就需要使用分布式事务。例如，一个电商微服务中的订单服务和库存服务需要通过远程调用进行事务操作，保证库存数量和订单信息的同步更新，避免出现超卖或缺货的情况。
• 单体系统访问多个数据库实例：当一个系统需要访问多个数据库实例时，例如用户信息和订单信息分别存储在两个不同的数据库实例中，需要通过分布式事务保证数据一致性，避免出现数据不一致的情况。
• 多服务访问同一个数据库实例：当多个服务访问同一个数据库实例时，例如订单微服务和库存微服务都需要访问同一个数据库，也可能需要使用分布式事务。因为跨JVM进程的多个服务同时持有不同的数据库连接进行数据库操作，可能会出现数据不一致的情况。

在这些场景下，我们需要使用分布式事务来保证数据的一致性。常用的分布式事务方案包括两阶段提交（2PC）、三阶段提交（3PC）、TCC、Saga、本地消息表等。其中，两阶段提交和三阶段提交都是基于锁机制实现的，而TCC、Saga和本地消息表则是基于业务逻辑实现的。选择哪种方案取决于业务需求、系统复杂性和性能等多个因素。

详情可以看这篇文章：深度解析分布式事务的七大核心方案

什么是分布式事务的防悬挂，空回滚?

防悬挂是指在分布式事务的第一阶段，防止在没有对应的 Try 操作的情况下出现 Confirm 或 Cancel 操作。这是为了保证事务的正确性和一致性。

分布式事务中最常见的模型是 TCC(Try-Confirm-Cancel)模型。在 TCC 模型中，事务分为三个步骤：

• Try：资源的预留操作。
• Confirm：确认操作，完成业务逻辑
• Cancel：取消操作，回滚预留资源。

防悬挂机制的作用是确保在分布式事务中，Confirm 和 Cancel 操作只会在 Try 操作成功执行后才会触发。

防悬挂的场景通常是以下情况：

• Confirm 操作悬挂：如果 Confirm 操作在没有执行过 Try 操作的情况下被调用，可能会导致数据不一致。
• Cancel 操作悬挂：类似地，如果 Cancel 操作在没有 Try 操作的情况下被调用，也会破坏数据的一致性。

为了防止这种情况，需要通过某些机制来检测和防止悬挂。例如:

• 幂等性检查：Confirm 和 Cancel 操作应该具备幂等性，避免多次调用引发问题。
• 状态校验：在执行 Confirm 或 Cancel之前，可以先检査是否有对应的 Try 操作成功过，如果没有，则拒绝执行 Confirm 或 Cancel 操作

空回滚是指在没有执行成功的Try操作时，Cancel 操作仍然被调用了。Cancel 操作实际上就是 Try操作的回滚操作，如果 Try 操作根本没有成功，则Cancel 操作实际不会对任问资源产生影响，这就是空回滚

空回滚一般发生在分布式系统中的异常情况下，比如：

• 网络超时：Try 操作还没执行成功，网络就超时了，分布式事务协调器可能误认为 Try 操作失败，因此会调用 Cancel。
• 网络分区或中断：Try 操作请求未到达相应的服务端，客户端误认为 Try 操作已经失败并发起 Cancel。

在这些情况下，Cancel 操作会被执行，但因为 Try 操作并没有成功，所以 Cancel 实际上什么都不需要做。这就是空回流,。为了支持空回滚，Cancel操作必须具备以下能力：

• 幂等性：即使 Cancel 操作被多次调用，它的效果也只能是执行一次，不会对系统产生额外影响。
• 空回滚兼容性：Cancel 操作在发现没有Try 操作执行成功时，不做任何修改，直接返回成功状态

什么是Seata？谈谈你对Seata的理解

Seata是一款开源的分布式事务解决方案，它主要用于解决在分布式系统中全局事务的一致性问题。
在分布式系统中，由于一次业务操作需要跨多个数据源或进行远程调用，往往会产生分布式事务问题。例如，在一个电商微服务系统中，订单服务和库存服务需要协同工作，如果订单服务已经创建成功，但库存服务因为某些原因失败了，就会导致数据不一致的问题。Seata就是为解决这个问题而产生的。

Seata的主要特点是无侵入以及高性能。它对业务无侵入，可以减少技术架构上的微服务化所带来的分布式事务问题对业务的侵入，同时高性能则是减少分布式事务解决方案所带来的性能消耗。

在Seata的事务处理中主要有三个重要的角色：事务的协调者（TC）、事务的管理者（TM）和事务的作业管理器（RM）。

• 事务协调者（TC）主要负责管理全局的分支事务的状态，用于全局性事务的提交和回滚。它会对所有的分支事务进行注册，然后根据各个分支事务的状态来决定是否提交或者回滚全局事务。
• 事务管理者（TM）用于开启、提交或回滚事务。它会根据业务逻辑来决定何时开启一个新的事务，并在适当的时候提交或回滚该事务。
• 资源管理器（RM）用于分支事务上的资源管理，向TC注册分支事务，上报分支事务的状态，接收TC的命令来提交或者回滚分支事务。

Seata支持哪些模式的分布式事务？

Seata以下几种模式的分布式事务：

• AT（Atomikos）模式：AT模式是Seata默认支持的模式，也是最常用的模式之一。在AT模式下，Seata通过在业务代码中嵌入事务上下文，实现对分布式事务的管理。Seata会拦截并解析业务代码中的SQL语句，通过对数据库连接进行拦截和代理，实现事务的管理和协调。
• TCC（Try-Confirm-Cancel）模式：TCC模式是一种基于补偿机制的分布式事务模式。在TCC模式中，业务逻辑需要实现Try、Confirm和Cancel三个阶段的操作。Seata通过调用业务代码中的Try、Confirm和Cancel方法，并在每个阶段记录相关的操作日志，来实现分布式事务的一致性。
• SAGA模式：SAGA模式是一种基于事件驱动的分布式事务模式。在SAGA模式中，每个服务都可以发布和订阅事件，通过事件的传递和处理来实现分布式事务的一致性。Seata提供了与SAGA模式兼容的Saga框架，用于管理和协调分布式事务的各个阶段。
• XA模式：XA模式是一种基于两阶段提交（Two-Phase Commit）协议的分布式事务模式。在XA模式中，Seata通过与数据库的XA事务协议进行交互，实现对分布式事务的管理和协调。XA模式需要数据库本身支持XA事务，并且需要在应用程序中配置相应的XA数据源。

了解Seata的实现原理吗？

Seata的实现原理主要包括三个核心组件：事务协调器（Transaction Coordinator）、事务管理器（Transaction Manager）和资源管理器（Resource Manager）。

• 事务协调器（Transaction Coordinator）：事务协调器负责协调和管理分布式事务的整个过程。它接收事务的开始和结束请求，并根据事务的状态进行协调和处理。事务协调器还负责记录和管理事务的全局事务 ID（Global Transaction ID）和分支事务 ID（Branch Transaction ID）。
• 事务管理器（Transaction Manager）：事务管理器负责全局事务的管理和控制。它协调各个分支事务的提交或回滚，并保证分布式事务的一致性和隔离性。事务管理器还负责与事务协调器进行通信，并将事务的状态变更进行持久化。
• 资源管理器（Resource Manager）：资源管理器负责管理和控制各个参与者（Participant）的事务操作。它与事务管理器进行通信，并根据事务管理器的指令执行相应的事务操作，包括提交和回滚。

Seata的实现原理基于两阶段提交（Two-Phase Commit）协议，具体的机制如下：

• 一阶段：在事务提交的过程中，首先进行预提交阶段。事务协调器向各个资源管理器发送预提交请求，资源管理器执行相应的事务操作并返回执行结果。在此阶段，业务数据和回滚日志记录在同一个本地事务中提交，并释放本地锁和连接资源。
• 二阶段：在预提交阶段成功后，进入真正的提交阶段。此阶段主要包括提交异步化和回滚反向补偿两个步骤：
  • 提交异步化：事务协调器发出真正的提交请求，各个资源管理器执行最终的提交操作。这个阶段的操作是非常快速的，以确保事务的提交效率。
  • 回滚反向补偿：如果在预提交阶段中有任何一个资源管理器返回失败结果，事务协调器发出回滚请求，各个资源管理器执行回滚操作，利用一阶段的回滚日志进行反向补偿。

Seata的事务执行流程是什么样的？

Seata事务的执行流程可以简要概括为以下几个步骤：

• 事务发起方（Transaction Starter）发起全局事务：事务发起方是指发起分布式事务的应用程序或服务。它向Seata的事务协调器发送全局事务的开始请求，生成全局事务ID（Global Transaction ID）。
• 事务协调器创建全局事务记录：事务协调器接收到全局事务的开始请求后，会为该事务创建相应的全局事务记录，并生成分支事务ID（Branch Transaction ID）。
• 分支事务注册：事务发起方将全局事务ID和分支事务ID发送给各个参与者（Participant），即资源管理器。参与者将分支事务ID注册到本地事务管理器，并将事务的执行结果反馈给事务协调器。
• 执行业务逻辑：在分布式事务的上下文中，各个参与者执行各自的本地事务，即执行业务逻辑和数据库操作。
• 预提交阶段：事务发起方向事务协调器发送预提交请求，事务协调器将预提交请求发送给各个参与者。
• 执行本地事务确认：参与者接收到预提交请求后，执行本地事务的确认操作，并将本地事务的执行结果反馈给事务协调器。
• 全局事务提交或回滚：事务协调器根据参与者反馈的结果进行判断，如果所有参与者的本地事务都执行成功，事务协调器发送真正的提交请求给参与者，参与者执行最终的提交操作；如果有任何一个参与者的本地事务执行失败，事务协调器发送回滚请求给参与者，参与者执行回滚操作。
• 完成全局事务：事务协调器接收到参与者的提交或回滚结果后，根据结果更新全局事务的状态，并通知事务发起方全局事务的最终结果。

全局事务ID和分支事务ID是怎么传递的？

全局事务ID和分支事务ID在分布式事务中通过上下文传递的方式进行传递。常见的传递方式包括参数传递、线程上下文传递和消息中间件传递。具体的传递方式可以根据业务场景和技术选型进行选择和调整。

Seata的事务回滚是怎么实现的？

Seata的事务回滚是通过回滚日志实现的。每个参与者在执行本地事务期间生成回滚日志，记录了对数据的修改操作。

当需要回滚事务时，事务协调器向参与者发送回滚请求，参与者根据回滚日志中的信息执行撤销操作，将数据恢复到事务开始前的状态。

回滚日志的管理和存储是Seata的核心机制，可以选择将日志存储在不同的介质中。通过回滚日志的持久化和恢复，Seata确保了事务的一致性和恢复性。

Sentinel 与Hystrix的区别是什么

Hystrix和Sentinel都是微服务架构中实现熔断和限流的工具，它们有以下区别和特点：

Hystrix是Netflix开源的熔断器实现，主要用于保护分布式系统中的服务调用。它的主要特点包括线程隔离、资源保护和降级处理。Hystrix通过将每个服务调用放入独立的线程池中来实现线程隔离，防止一个服务的延迟或故障影响其他服务。它通过监控服务调用的成功率、延迟等指标来保护后端资源，并在失败的请求或响应超时达到一定阈值时自动打开熔断器，避免连锁故障。此外，Hystrix还提供了降级处理功能，可以在服务不可用或响应过慢时返回预定义的降级响应，保证系统的可用性。

Sentinel是阿里巴巴开源的流量控制和系统保护工具，主要用于实现微服务架构中的流量控制、熔断、降级和系统负载保护等。它的主要特点包括实时监控和动态规则配置、丰富的流量控制策略、细粒度的服务保护以及支持多种编程语言。Sentinel可以实时监控服务的请求流量和各项指标，并提供实时的仪表盘和可视化的监控界面。它还支持通过API动态配置流量控制和熔断规则，可以根据实际情况进行动态调整。Sentinel提供了多种流量控制策略，包括基于QPS、线程数、并发连接数等多种指标进行的流量控制。此外，Sentinel还支持对每个具体的服务接口进行熔断、降级和限流等操作，以实现精确的服务保护策略。同时，Sentinel不仅支持Java，还支持Go、Python等多种编程语言，使其适用于跨语言的微服务架构。

总的来说，Hystrix注重线程隔离和资源保护，适用于保护单个服务调用。而Sentinel注重流量控制和动态规则配置，适用于对整个系统的流量进行监控和保护。根据实际需求和技术栈，可以选择适合的工具来实现微服务架构中的熔断和限流功能。

如果 Sentinel 的异常处理规则不满足需求，应该怎么办？

如果 Sentinel 的默认异常处理机制无法满足需求，可以选择自定义异常处理规则。

Sentinel 允许通过自定义实现 BlockedExceptionHandler 接口，然后将自定义的异常处理器对象交给 Spring 容器进行管理。 可以根据实际业务需求，定制化异常处理策略，例如全局兜底处理、日志打印、空指针检查等。 同时，还可以在处理器中加入自定义的业务逻辑，例如对异常进行分类、统计和反馈等。 这样，可以根据具体的应用场景和业务需求，灵活地扩展 Sentinel 的异常处理能力。

什么是分布式事务的防悬挂，空回滚

在分布式事务中，防悬挂和空回滚是两个重要的概念，它们通常在实现分布式事务时涉及的锁定机制、隔离性、错误处理等方面。下面对这两个概念进行详细解释

1. 防悬挂
   防悬挂是指在分布式事务的第一阶段，防止在没有对应的 Try 操作的情况下出现 Confirm 或 Cancel操作。这是为了保证事务的正确性和一致性。

分布式事务中最常见的模型是 TCC(Try-Confirm-Cancel)模型。在 TCC 模型中，事务通常分为三个步骤：

• Try：资源的预留操作。
• Confirm：确认操作，完成业务逻辑
• Cancel：取消操作，回滚预留资源。

防悬挂机制的作用是确保在分布式事务中，Confirm 和 Cancel 操作只会在 Try 操作成功执行后才会触发。防悬挂的场景通常是以下情况：

• Confirm 操作悬挂：如果 Confirm 操作在没有执行过 Try 操作的情况下被调用，可能会导致数据不一致
• Cancel 操作悬挂：类似地，如果 Cancel 操作在没有 Try 操作的情况下被调用，也会破坏数据的一致性。

为了防止这种情况，通常需要通过某些机制来检测和防止悬挂。例如:

• 幂等性检查：Confirm 和 Cancel 操作应该具备幂等性，避免多次调用引发问题。
• 状态校验：在执行 Confirm 或 Cancel 之前，可以先检查是否有对应的 Try 操作成功过，如果没有，则拒绝执行 Confirm 或 Cancel 操作

2. 空回滚
   空回滚是指在没有执行成功的Try操作时，Cancel操作仍然被调用了。Cancel操作实际上就是 Try操作的回滚操作，如果 Try 操作很本没有成功，则 Cancel 操作实际不会对任何资源产生影响，这种情况下称为空回滚

空回滚通常发生在分布式系统中的异常情况下，比如:

• 网络超时：Try 操作还没执行成功，网络就超时了，分布式事务协调器可能误认为 Try 操作失败，因此会调用 Cancel。
• 网络分区或中断：Try 操作请求未到达相应的服务端，客户端误认为 Try 操作已经失败并发起 Cancel。

在这些情况下，Cancel 操作会被执行，但因为 Try 操作并没有成功，所以 Cancel 实际上什么都不需要做。这就是空回滚。

为了支持空回滚，Cancel 操作必须具备以下能力:

• 幂等性：即使 Cancel 操作被多次调用，它的效果也只能是执行一次，不会对系统产生额外影响。
• 空回滚兼容性：Cancel操作在发现没有 Try 操作执行成功时，不做任何修改，直接返回成功状态

当前有个本地操作 A，远程操作 B，我需要保证 A和 B事务的一致性，你会如何实现？

这个题目经常有人会直接踩坑，然后就被面试官绕进去出不来了

要保证本地操作A和远程操作B的事务一致性，这是一个分布式事务问题。不能在本地事务中直接嵌入远程 RPC调用(这就是坑)，而是通过异步解耦+补偿机制实现最终一致性。

常见方案是本地消息表：本地事务A执行时，先记录一条“待执行远程操作B”的日志(与A在同一事务中)，本地事务提交后，通过异步线程或消息队列触发远程调用B、若B失败，通过定时任务重试(因为有日志，可以扫描日志重试)，直到成功或人工介入。

为什么不能在本地事务中直接调用远程 RPC?

begin transactionupdate A 本地数据库调用远程服务B（RPC）
commit

举个例子：本地操作A是“扣库存”(数据库事务)，远程操作B是“调用支付接口扣款”。如果在本地事务中直接调用B，若 B超时 则本地事务回滚，但B实际执行了，导致库存与支付状态不一致。

除此之外，还有长事务问题，毕竟外部系统不可控(即使是公司其他部分的接口)，若B执行时间过长，会导致 A 操作本地事务锁持有时间延长，引发数据库连接耗尽或死锁问题。

所以，不建议将 RPC调用嵌入本地事务中。同理，像发MQ、更新外部系统(如缓存)等操作，都不建议放在事务内。

现在需要你设计一个将已登录的用户踢下线的功能，如何实现?

可以通过标记用户 token 为失效或者直接移除其 session来实现踢下线功能

简单来说，就是让后续请求中带的登录凭证不再被系统接受。标记失效和直接删除都行，这样用户下次请求就会被拦截或要求重新登录

分布式系统

把单体项目进行了多机部署，多台服务器是如何共享用户登录信息的？

目前主流有两个方案：

1. 将 Session 放置第三方共享存储中，例如 Redis、Memcached 等分布式缓存 或数据库中，所有的服务器统一访问第三方。
2. JWT，即服务器不存储会话，用户登录后返回签名令牌(含用户信息)，每次请求携带令牌验证即可。不过现在很多项目会把 JWT 存在 Redis 中

因为单机时候会话(Session)会存储在本地，比如 Tomcat 的 HttpSession 默认存在当前服务器内存中。多机部署后，同一个用户多次请求可能会被负载均衡到其他服务器，新服务器无法读取原会话数据，这时候登录态就丢了有些人会采用 粘性会话，比如利用 Nginx 根据用户 IP 或 Cookie 哈希固定转发到同一台服务器。这个方式有局限性，如果服务器宕机了会话就丢失(登录态就掉了)，且扩容缩容时会导致负载不均，无法实现真正的弹性伸缩。所以普遍会采用第三方共享存储 Session，比如用 Redis 存放 Session，这样一来所有的服务都可以共享访问到同一个 Session。

举个例子

1. 用户登录后，服务端生成 SessionID，并将用户数据(如用户ID、权限)写入Redis(Key=SessionID，Value=序列化数据)。
2. 响应中设置 Cookie(如SESSION=abc123)或 Header 返回 Token。
3. 用户下次请求携带 Session ID，任意服务器从 Redis 读取数据，还原用户上下文

服务监控

你们的服务怎么做监控和告警？

我们使用Prometheus和Grafana来实现整个微服务集群的监控和告警：

• Prometheus：Prometheus 是一个开源的监控系统，具有灵活的数据模型和强大的查询语言，能够收集和存储时间序列数据。它可以通过HTTP协议定期拉取微服务的指标数据，并提供可扩展的存储和查询功能。
• Grafana：Grafana 是一个开源的可视化仪表板工具，可以与 Prometheus 结合使用，创建实时和历史数据的仪表板。Grafana 提供了丰富的图表和可视化选项，可以帮助用户更好地理解和分析微服务的性能和状态。

你们的服务怎么做日志收集？

日志收集有很多种方案，我们用的是ELK：

• Elasticsearch：Elasticsearch是一个分布式搜索和分析引擎，用于存储和索引大量的日志数据。它提供了快速的搜索和聚合功能，可以高效地处理大规模的日志数据。
• Logstash：Logstash是一个用于收集、过滤和转发日志数据的工具。它可以从各种来源（如文件、网络、消息队列等）收集日志数据，并对数据进行处理和转换，然后将其发送到Elasticsearch进行存储和索引。
• Kibana：Kibana是一个用于日志数据可视化和分析的工具。它提供了丰富的图表、仪表盘和搜索功能，可以帮助用户实时监控和分析日志数据，发现潜在的问题和趋势。

简单说，这三者里Elasticsearch提供数据存储和检索能力，Logstash负责将日志收集到ES，Kibana负责日志数据的可视化分析。

使用ELK进行微服务日志收集的一般流程如下：

1. 在每个微服务中配置日志输出：将微服务的日志输出到标准输出（stdout）或日志文件。
2. 使用Logstash收集日志：配置Logstash收集器，通过配置输入插件（如文件输入、网络输入等）监听微服务的日志输出，并进行过滤和处理。
3. 将日志数据发送到Elasticsearch：配置Logstash的输出插件，将经过处理的日志数据发送到Elasticsearch进行存储和索引。
4. 使用Kibana进行可视化和分析：通过Kibana连接到Elasticsearch，创建仪表盘、图表和搜索查询，实时监控和分析微服务的日志数据。

除了应用最广泛的ELK，还有一些其它的方案比如Fluentd、Graylog、Loki、Filebeat，一些云厂商也提供了付费方案，比如阿里云的sls。

其它

说一下你对于 DDD 的了解?

DDD全名叫做 Domain-driven design，即领域驱动设计，它是一种软件开发方法，其主要目的就是让开发人员和领域专家可以更好地协作，从而开发出满足业务需求的系统

DDD 的关键概念包括领域模型和限界上下文。

• 领域模型描述了业务领域的规则和逻辑，让开发人员能够更好地理解业务需求。
• 限界上下文则定义了一个特定的业务领域内的模型和代码，使得其可以独立于其他上下文进行开发和维护。

除此之外，DDD还强调分层架构和事件溯源的重要性，分层架构将系统划分为不同层次的结构，每个层次的职责和角色各有不同，从而方便业务代码的开发和维护。事件溯源则是一种存储和处理业务事件的技术，支持审计、合规和业务分析等需求。

总得来说，DOD是一种设计和开发复杂软件系统的方法，一般情况下 MVC 已经能够完成许多软件业务的开发了，如果项目本身比较简单，引入 DDD的话不仅不能降低开发成本，还会增加开发的复杂程度，所以 DDD 在使用之前需要一定的思考。

什么是灰度发布、金丝雀部署以及蓝绿部署?

灰度发布、金丝雀部署和蓝绿部署是三种常见的软件发布策略，它们用于在系统升级时降低风险，确保在新版本上线过程中服务的稳定性和可控性

• 灰度发布

灰度发布是一种新进式的发布方式，它通过将新版本逐步推送给部分用户进行试用，逐步扩大使用范围，直到新版本完全替换旧版本，其目的是通过小范围的用户测试，验证新版本的稳定性，降低发布新版本的风验

实现方式：通常通过流量控制的方式，将一部分用户请求引导到新版本实例上。如果新版本表现正常，可以逐步增加新版本的用户群体，直到全量用户使用新版本。

适用场景：适合在业务逻辑变动较大的场景中使用，通过灰度发布可以发现新版本中的潜在问题，并在影响范围较小的情况下进行回滚。

• 金丝雀部署

金丝雀部署(Ccanary Deployment)是一种特殊的灰度发布策略，通常是指将新版本部署到少量的实例上，并仅将部分流量引导至这些实例，以验证新版本在实际生产环境中的表现。

和灰度发布的区别：金丝雀部署更强调在生产环境中逐步验证新版本的表现，类似于让“金丝雀”先进入矿井检测安全性，一旦检测到问题，可以快速回滚。

实现方式：可以通过负载均衡器或服务网格，将一定比例的流量引导到运行新版本的实例上。若新版本稳定，再逐步增加其流量占比。

适用场景：适用于需要在生产环境中验证新功能或配置变更的场景。通过金丝雀部署，可以提前发现新版本在生产环境中的潜在问题，降低对全量用户的影响,

• 蓝绿部署

蓝绿部署(Blue-Green Deployment)是一种无缝切换的部署策略，在这种模式下，生产环境中始终存在两个版本：蓝色版本(当前的生产版本)和绿色版本(新版本)。当绿色版本准备就绪时，通过负载均衡或路由切换，将所有流量从蓝色版本切换到绿色版本。

特点：在蓝绿部署中，旧版本(蓝色版本)始终保持可用，可以在新版本(绿色版本)出现问题时，快速切换回旧版本，实现快速回滚。

实现方式：通常通过负载均衡器、DNS 切换或 API网关，来切换蓝色版本和绿色版本之间的流量指向。

适用场景：适用于需要快速切换和回滚的场景，特别是在对系统稳定性要求较高的应用中，通过蓝绿部署，可以实现无停机升级。