在微服务架构中，网关（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的事务执行流程是什么样的？