SpringCloud和SpringCloudAlibaba

阅读提示

建议先看题目目录，再按“概念 -> 原理 -> 场景 -> 优化”顺序复习。
每题先讲结论，再补关键机制和项目实践，回答会更稳。

适用版本

现代组件与下文 Gateway 示例以 Java 17、Spring Boot 3.2.4、Spring Cloud 2023.0.1、Spring Cloud Alibaba 2023.0.1.0 为说明基线；这是可核对的历史兼容组合，不代表最新版本或仍处于支持期。该 Alibaba 版本对应 Nacos 2.3.2、Sentinel 1.8.6、Seata 2.0.0，实际依赖由 BOM 管理，服务端兼容性另行核对。参见官方版本表。

Zuul、Ribbon、Hystrix 的问题保留用于理解旧系统：Spring Cloud 自 2020.0 起已移除对这三者的集成支持，不应把旧 starter 直接用于上述基线。参见官方发布说明。

1、SpringBoot和SpringCloud有何区别？

• 定位与关注点不同：

• Spring Boot 是一个用于快速构建单个、独立、生产级别的 Spring 应用的框架。它专注于简化 Spring 应用的开发过程，提供自动配置、嵌入式服务器等特性，使开发者能够快速、方便地创建单个微服务。

• Spring Cloud 是一套基于 Spring Boot 的工具集，用于构建分布式微服务架构。它关注全局的微服务协调和治理，提供了微服务之间的配置管理、服务发现、断路器、路由、负载均衡等集成功能；分布式锁和会话需按场景选择独立方案。

• 依赖关系：

• Spring Boot 可以独立使用，开发者可以使用它来开发和部署单个微服务应用。

• Spring Cloud 依赖于 Spring Boot，是在其基础上构建的。Spring Cloud 必须依赖 Spring Boot 才能运行，属于依赖关系。

• 功能侧重点：

• Spring Boot 专注于快速、便捷地开发单个微服务实例，简化配置和开发流程，提高开发效率。

• Spring Cloud 关注微服务架构的整体治理，将由 Spring Boot 构建的各个微服务整合并管理起来，解决分布式系统中的常见问题。

• 总结：

• Spring Boot 是用于创建独立应用（单体或微服务）的基础框架，旨在简化开发过程。

• Spring Cloud 是基于 Spring Boot 的微服务治理框架，提供构建和管理分布式系统所需的全套解决方案。

2、什么是Spring Cloud？（了解）

• Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如 服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
• Spring Cloud的主要目标是解决分布式系统中的常见问题，例如服务发现、负载均衡、配置管理、断路器、消息总线等。

3、Spring Cloud的主要组件有哪些？

以 Spring Cloud 2023.0 为例：

• Eureka / Spring Cloud Consul：服务注册与发现。
• Spring Cloud Gateway：API 网关。
• Spring Cloud LoadBalancer：客户端负载均衡。
• Spring Cloud OpenFeign：声明式 HTTP 客户端。
• Spring Cloud CircuitBreaker：熔断抽象，可集成 Resilience4j 等实现。
• Spring Cloud Config：集中式配置管理。
• Spring Cloud Bus：通过消息代理传播配置刷新等管理事件。

旧资料中的 Zuul、Ribbon、Hystrix 分别承担网关、负载均衡、容错职责，其版本边界见开头说明；Eureka 并未随它们一同移除。

4、 Spring Cloud的优缺点？

• 优点：

• 与 Spring Boot 生态集成紧密；更新与维护取决于各项目的支持周期，不能保证无限期维护

• 组件丰富，功能齐全。Spring Cloud 为微服务架构提供了非常完整的支持。例如、配置管理、服务发现、断路器、微服务网关等；

• Spring Cloud 社区活跃度很高，教程很丰富，遇到问题很容易找到解决方案

• 服务拆分粒度更细，耦合度比较低，有利于资源重复利用，有利于提高开发效率

• 可以更精准的制定优化服务方案，提高系统的可维护性

• 减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发

• 微服务可以是跨平台的，可以用任何一种语言开发

• 适于互联网时代，产品迭代周期更短

• 缺点：

• 微服务过多，治理成本高，不利于维护系统

• 分布式系统开发的成本高（容错，分布式事务等）对团队挑战大

5、什么是Eureka？

Eureka 是服务注册与发现组件。提供者用服务名注册 IP、端口和元数据并定期续约；消费者拉取注册表并缓存在本地，通过负载均衡选择实例，再直接向实例发起网络请求。注册中心通常不转发业务流量。

心跳只能说明租约是否续约，不能替代业务健康检查。RPC 也并非必须使用注册中心：静态地址、DNS 或其他发现机制都可以定位服务，远程调用不会因此变成本地调用。参见 Spring Cloud Netflix 官方文档。

6、Eureka自我保护机制是什么?

• 当Eureka Server 节点在短时间内丢失了过多实例的连接时（比如网络故障或频繁启动关闭客户端）节点会进入自我保护模式，保护注册信息，不再删除注册数据，故障恢复时，自动退出自我保护模式。

7、Rest和RPC有什么区别？

REST 是围绕资源、统一接口、无状态等约束的架构风格；RPC 是把远程操作抽象成过程或方法调用的交互方式，二者不是传输协议之间的对立。RPC 也可以基于 HTTP，例如 gRPC 使用 HTTP/2；HTTP API 也可能采用 RPC 风格。

两者都需要契约与兼容性管理。RPC 常用 IDL 或共享接口描述方法和数据类型；REST API 常用 HTTP 方法、状态码与资源表示表达契约。是否共享代码取决于实现方式，不能说 REST 没有耦合或总是更灵活。OpenAPI 可以描述契约、辅助生成文档和客户端，但不能自动消除实现与文档不一致。参见 HTTP 语义规范 RFC 9110 和 gRPC 核心概念。

8、什么是Zuul网关，有什么作用？

• Zuul网关（也称为Zuul Gateway）是Spring Cloud生态系统中的一个组件，用于提供动态路由、监控、弹性、安全等功能的API网关。Zuul在Spring Cloud Netflix栈中是一个重要的组件，但在Spring Cloud的后续版本中，Netflix栈的部分组件（包括Zuul）逐渐被Spring Cloud Gateway所取代，本文所述 Gateway 4.1 WebFlux 实现采用 Reactor 非阻塞模型，但性能仍取决于调用链和负载，不能据此断言必然更快；4.1 另有 MVC 实现。

• Zuul网关的作用：

• 路由和转发：Zuul网关可以作为请求的入口点，接收来自客户端的请求，并根据配置的路由规则将请求转发到相应的微服务实例。

• 动态路由：Zuul支持动态路由，这意味着你可以在不重启Zuul网关的情况下更改路由规则。

• 负载均衡：Zuul可以与Ribbon等负载均衡器结合使用，将请求分发到多个服务实例上，以提高系统的可扩展性和可用性。

• 安全：Zuul可以集成Spring Security等安全框架，实现身份验证、授权、限流等功能，保护后端服务免受非法访问。

• 监控和跟踪：Zuul可以与Spring Cloud的监控和跟踪组件（如Spring Cloud Sleuth和Zipkin）结合使用，收集和分析请求数据，帮助开发人员了解系统的运行情况和性能瓶颈。

• 静态响应：在某些情况下，Zuul可以直接返回静态响应，而无需将请求转发到后端服务。

• 压力测试：Zuul可以配置为模拟后端服务的响应，以便进行压力测试或故障模拟。

• 请求过滤：Zuul提供了请求过滤器（pre、route、post 和 error），可以在请求被路由到后端服务之前或之后执行自定义逻辑。

• 服务发现：Zuul可以与Eureka等服务发现组件结合使用，自动发现和路由到可用的服务实例。

9、什么是Ribbon，有什么作用？

• Ribbon是Netflix开源的一个负载均衡器，它有助于控制HTTP和TCP客户端的行为。在微服务架构中，Ribbon通常与Spring Cloud一起使用，以实现客户端侧的负载均衡。

• Ribbon的主要作用和功能包括：

• 客户端负载均衡：Ribbon可以作为一个客户端负载均衡器，它允许你在HTTP和TCP客户端上执行负载均衡。与传统的服务端负载均衡器（如Nginx）不同，Ribbon是在客户端实现的，这意味着每个服务消费者都会维护一份服务提供者的清单，并自己进行服务调用。

• 服务调用：在微服务架构中，服务之间经常需要进行远程调用。Ribbon可以与RestTemplate结合使用，为服务调用提供负载均衡功能。通过配置Ribbon，你可以指定服务调用的策略（如轮询、随机等），以及负载均衡的其他参数。

• 容错处理：Ribbon内置了多种容错处理机制，如快速失败、重试等。当某个服务提供者出现故障时，Ribbon可以根据配置的策略自动进行容错处理，避免因为某个服务的故障而导致整个系统的崩溃。

• 监控和统计：Ribbon还提供了监控和统计功能，可以收集服务调用的数据并进行统计和分析。这些数据可以帮助你了解系统的运行状况、发现潜在的性能问题并进行优化。

10、什么是Feign，有什么作用？

• Feign是一个声明式的Web服务客户端，它使得编写Web服务客户端变得更加容易。Feign的主要作用如下：

• 简化HTTP客户端开发：Feign通过创建接口并使用注解的方式，简化了对HTTP请求的封装和处理。开发者只需要定义接口并添加相应的注解，就可以实现对远程服务的调用，而无需编写大量的HTTP请求代码。

• 支持负载均衡：在本文基线中，Spring Cloud OpenFeign 可配合 Spring Cloud LoadBalancer 和 DiscoveryClient 按服务名选择实例；需引入相应依赖。旧版可使用 Ribbon；显式配置固定 URL 时不经过这种服务名负载均衡。这有助于平衡各个服务提供者的负载，提高系统的整体性能和可用性。

• 支持服务调用：Feign可以用于微服务架构中的服务调用。通过Feign，服务消费者可以轻松地调用其他服务提供者提供的接口，实现服务之间的通信和协作。

• 支持容错处理：Feign 本身不内置熔断器。OpenFeign 4.x 需引入 Spring Cloud CircuitBreaker 实现并设置 spring.cloud.openfeign.circuitbreaker.enabled=true（默认 false），再配置 fallback 或 fallbackFactory。Fallback 不等于自动切换实例；重试需单独配置，且应考虑幂等性。参见 OpenFeign 官方文档。

• 声明式调用：Feign的声明式调用使得开发者可以像调用本地方法一样调用远程方法，无需关注与远程服务的交互细节，降低了开发的复杂性和难度。

11、什么是Hystrix，有什么作用？

• Hystrix是Netflix开源的一款针对分布式系统的延迟和容错库，它的主要作用是提供容错能力，防止分布式系统中的雪崩效应。具体来说，Hystrix通过以下方式实现其功能：

• 服务隔离：通过线程池或信号量隔离策略，限制对某个依赖服务的并发请求数量，防止因单一依赖服务的故障导致整个系统资源耗尽。线程池隔离为每个依赖服务分配独立的线程池，信号量隔离则限制同时执行的请求数量。

• 服务降级：当一个服务无法正常工作时，Hystrix可以通过返回一个默认值或者执行预先定义的逻辑，代替原本的服务响应。这样可以避免整个系统因为一个服务的故障而崩溃。

• 熔断器模式：当滚动窗口内请求量达到最小门槛，且错误百分比达到阈值时，Hystrix会主动断开对该服务的调用，从而防止对该服务的连续调用，减轻服务器压力和响应时间。

• 实时监控和统计：支持实时监控和统计服务调用的性能指标，帮助开发人员及时发现和解决问题。

12、说一说什么是服务雪崩？

服务雪崩是依赖故障沿调用链传播：例如 A → B → C，C 响应变慢使 B 的线程、连接被长期占用，A 等待 B 又耗尽自身资源。缺乏超时、并发限制和熔断，或无节制重试，都可能扩大影响；并不需要形成循环调用。

13、什么是服务降级、服务熔断、服务隔离？

• 服务降级：用可接受的替代结果或缩减功能应对依赖失败、过载等情况，例如返回缓存；并非所有错误都适合伪装成成功。
• 服务熔断：按统计规则暂时拒绝对故障依赖的调用，等待后进入半开状态探测恢复。熔断可以触发降级，也可以快速返回错误。
• 服务隔离：为依赖或资源池设置独立的容量边界，例如线程池、信号量或并发舱壁，不是简单地为每个服务新建一个线程。

Hystrix 是历史实现；其熔断同时受最小请求量和错误比例约束，参见 Hystrix 官方配置说明。

14、在微服务中，如何保护服务?（了解）

为远程调用设置连接/读取超时，限制并发和排队长度，并根据业务配置熔断、限流、隔离及降级；重试应有次数上限并结合幂等设计。本文现代基线可选 Spring Cloud CircuitBreaker + Resilience4j，或使用 Sentinel 的资源规则。Hystrix 已进入维护模式，仅用于理解旧系统，见 Netflix 官方声明。资源分配属于隔离，返回替代结果属于降级，两者应配合设计。

15、服务降级底层是如何实现的？（了解）

旧版 Hystrix 中，HystrixCommand 实现 run() 与 getFallback()；响应式 HystrixObservableCommand 则实现 construct() 与 resumeWithFallback()。执行失败、超时、熔断或隔离拒绝等可进入配置的降级路径；若未实现 fallback 或 fallback 也失败，错误仍会向上传播。参见 Hystrix 执行机制。

16、什么是Spring Cloud Config？有什么作用？

Spring Cloud Config是一个基于Spring Cloud的配置管理工具，它的主要作用包括：

• 集中管理配置：在微服务架构中，服务数量众多，每个服务可能需要不同的配置信息。Spring Cloud Config 允许将所有的配置文件集中存储在一个地方（通常是一个 Git 仓库），方便地进行管理和维护。修改 Git 后，运行中的客户端不会自动实时更新：还需触发客户端刷新（例如受保护的 POST /actuator/refresh），或通过 Spring Cloud Bus 广播刷新事件；可刷新的 Bean 通常配合 @RefreshScope 或配置属性重绑定。参见 Spring Cloud 刷新机制。
• 支持多种环境和配置格式，实现不同环境的配置隔离：Spring Cloud Config 支持多种环境（如开发、测试、生产环境等）和多种配置格式（如 properties 文件、YAML 文件等）。它能够根据不同的环境加载对应的配置文件，避免了手动修改配置的繁琐过程，从而实现配置的集中化和环境隔离。
• 动态调整配置：在服务运行期间，可能需要调整一些配置参数。使用 Spring Cloud Config 可以实现配置的动态调整，而不需要重启服务，提高了系统的灵活性和可维护性。
• 加密和解密功能：为了保护敏感信息不被泄露，Spring Cloud Config 提供了对配置信息的加密和解密功能，确保配置的安全性。

17、Eureka保证是AP吗？（了解）

Eureka 通常被描述为偏 AP 的服务发现方案：节点之间复制注册信息，消费者也缓存注册表，网络分区时优先维持发现能力，允许短期读到旧数据。这不表示每个客户端请求都必然成功；缓存实例失效、首次启动没有缓存等情况仍可能导致调用失败。

• 客户端缓存：注册中心暂时不可达时，消费者可使用已有地址继续调用；地址可能过期，因此还需超时与容错。
• 租约与剔除：正常情况下客户端周期性续约，租约过期后由服务端剔除任务处理，并非一丢心跳就立即删除。
• 自我保护：服务端收到的续约数量低于预期阈值时，会抑制过期租约剔除，降低网络故障造成的大面积误删风险；续约恢复后退出保护。代价是不可用实例可能仍在列表中，心跳和自我保护不能保证业务健康。

参见 Spring Cloud Netflix 官方说明；CAP 中的可用性定义见第 28 题。

18、什么是Spring Cloud Alibaba？（了解）

• Spring Cloud Alibaba是一组基于Spring Cloud的开源框架，用于构建分布式微服务应用和微服务架构。它提供了一系列工具和组件，包括服务注册与发现、配置管理、熔断降级、限流、分布式事务等，以简化微服务应用的开发和部署。

19、Spring Cloud Alibaba与Spring Cloud有什么区别？

• Spring Cloud Alibaba 是基于 Spring Cloud 扩展点集成阿里巴巴中间件的项目，与 Spring Cloud 配合使用，并非替代关系。区别主要体现在以下几个方面：
• Spring Cloud Alibaba提供了更多与阿里巴巴云生态系统集成的组件，如Nacos、Sentinel、RocketMQ等。
• Spring Cloud Alibaba引入了更多分布式系统的解决方案，如通过 Seata 集成分布式事务；分布式锁需按业务另选实现。
• Spring Cloud Alibaba在微服务应用的开发和部署方面提供了更多便捷性。

20、Spring Cloud Alibaba有哪些组件？

以下介绍生态中的常见能力，不代表每个发布分支均包含全部 starter；OSS、SchedulerX 等云服务接入需核对所用版本的依赖与服务文档。

• 服务注册与发现组件（Nacos）：Nacos 是用于服务发现、配置和服务管理的平台。它支持动态配置服务、服务发现、服务健康检查、流量管理等功能。
• 服务降级与熔断组件（Sentinel）：Sentinel 是面向分布式、云原生系统的流量防卫兵。它提供了流量控制、熔断降级、系统自适应保护等多个维度保护服务的稳定性。
• 分布式配置中心组件（Nacos Config）：Nacos Config是一个用于实现分布式配置管理的组件。它可以集中管理应用程序的配置信息，并将其动态地推送到所有相关的服务实例。Nacos Config支持多种配置参数的管理和监控，可以帮助开发人员更好地管理和调试分布式系统。
• 消息驱动组件（RocketMQ）：RocketMQ是一个用于实现消息驱动的组件。它提供了可靠的消息传递机制，支持高吞吐量和低延迟的消息处理。RocketMQ支持多种消息模式的选择，如点对点模式和发布订阅模式，可以根据应用程序的需求来进行灵活调整。
• 阿里云对象存储服务（OSS）：是一个海量、安全、低成本、高可靠的云存储服务，数据持久性指标依存储类型及官方服务承诺而定。Spring Cloud Alibaba 提供了与 OSS 集成的组件，方便开发者在微服务应用中使用 OSS 存储数据。
• Seata： 是一个开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。它支持 AT、TCC、SAGA 和 XA 等事务模式，为微服务架构下的分布式事务提供一站式解决方案。
• SchedulerX：SchedulerX 是阿里云提供的分布式任务调度平台，支持定时、周期、依赖触发等多种任务调度模式。Spring Cloud Alibaba 提供了与 SchedulerX 集成的组件，方便开发者在微服务应用中进行任务调度和管理。

21、什么是Nacos？

• Nacos是Spring Cloud Alibaba生态系统的核心组件之一。它是一个开源的动态服务发现、配置管理和服务管理平台。Nacos支持服务注册与发现、配置管理、DNS和HTTP服务、流量管理等功能，为微服务应用提供了中心化的管理和配置。

22、Nacos 服务注册与发现的原理?

• 服务注册：在微服务架构中，服务实例启动时会将自己的网络位置（包括 IP 地址和端口号）注册到服务注册中心。以下是服务注册的过程：

• 服务提供者注册：服务提供者（例如一个微服务实例）在启动时，向 Nacos 服务器发送一个注册请求，请求通常包含服务标识、服务实例的地址、端口和元数据信息等。

• 服务清单更新：Nacos 服务器接收到注册请求后，会将该服务实例的信息添加到服务清单中。Nacos 使用内存中的数据结构来维护服务清单以便快速读写。

• 服务发现：服务消费者（例如另一个微服务）使用服务注册中心来发现可用服务的网络位置。以下是服务发现的过程：

• 服务消费者查询：服务消费者向 Nacos 服务器查询它所需要的服务提供者的信息。查询可以是基于服务名的静态查询，也可以使用更复杂的筛选规则。

• 服务信息响应：根据服务消费者的查询，Nacos 服务器返回一组服务提供者实例的信息，服务消费者可以根据这些信息调用服务提供者。

• 健康维护与订阅更新：不能把所有版本都描述为周期性 HTTP 心跳。Nacos 1.x 临时实例使用客户端心跳；使用 Nacos 2.x Java SDK 注册临时实例时，主要通过 gRPC 长连接维护存活状态，连接清理会关联清理临时注册数据。持久实例则采用服务端健康检查，不按临时实例的断连逻辑直接删除。

• 消费者可订阅服务变化，服务端推送后更新本地缓存，再由负载均衡器选择实例；注册中心不代理业务请求。发现信息传播和故障探测都有时间窗口，仍需调用超时与容错。

参见 Nacos SDK 运行时指南。

23、什么是GateWay？有什么作用？

这里指 Spring Cloud Gateway（API 网关），而不是 IP 网络的默认网关。它按路由断言匹配 HTTP 请求，通过过滤器执行路径改写、鉴权接入、限流等逻辑，再代理到目标服务。功能需通过对应依赖和规则配置，并非默认提供 HTTP 到 FTP 的任意协议转换。

以 Gateway 4.1 WebFlux 实现为例，核心流程是：

请求 → 匹配 Route 的 Predicate → 过滤器前置逻辑
     → 解析目标并转发 → 过滤器后置逻辑 → 响应

下面的路由把 /api/orders/42 转给 order-service 的 /orders/42：

spring:
  cloud:
    gateway:
      routes:
        - id: orders
          uri: lb://order-service
          predicates:
            - Path=/api/orders/**
          filters:
            - StripPrefix=1

该配置要求 Gateway WebFlux starter、spring-cloud-starter-loadbalancer 以及 Eureka/Nacos 等 DiscoveryClient 实现，并且目标服务已注册。lb:// 表示按服务名选择实例，不是 DNS 主机名；过滤器中执行阻塞 I/O 会阻塞事件循环，应避免直接这样做。此配置是机制示例，未实际启动验证。

参见 Gateway 4.1 官方工作原理 与 服务发现路由文档。

24、什么是Sentinel？有什么作用?

Sentinel是一个开源的分布式系统的流量控制和熔断降级组件，主要用于保护服务的稳定性。它提供了实时的流量控制、熔断降级、系统负载保护等功能，帮助开发者有效地保护应用程序，防止故障和异常情况的发生。

Sentinel的主要作用包括：

• 流量控制：通过配置不同的规则，对请求流量进行限制，以防止系统因流量过大导致崩溃或服务降级。
• 熔断降级：Sentinel 1.8.x 对配置规则的资源按慢调用比例、异常比例或异常数进行统计，达到规则门槛后暂时拒绝调用；熔断时长后进入半开探测，并非熔断整个系统。需要正确埋点和异常统计，业务替代结果仍须自行设计。参见 Sentinel 官方熔断说明。
• 系统负载保护：在系统负载高峰期间，Sentinel可以限制请求流量，避免系统资源耗尽，从而保护系统的稳定性。
• 实时监控：Sentinel可以实时监控系统的请求流量、响应时间、错误率等指标，帮助开发者及时发现并解决潜在问题。

25、讲述微服务架构下 Spring Cloud Alibaba 的最佳实践？（了解）

Spring Cloud Alibaba 是 Spring Cloud 体系结构的一部分，提供了一系列解决方案，用于快速构建分布式系统的微服务架构。它整合了阿里巴巴开源的中间件，如 Nacos、Sentinel、RocketMQ、Dubbo 等，以提供服务发现、配置管理、消息传递和流量控制等功能。以下是在微服务架构下使用 Spring Cloud Alibaba 的一些最佳实践：

• 服务发现和配置中心 - Nacos

• 动态服务发现：使用 Nacos 作为服务注册和发现中心，帮助微服务实例在启动时自动注册，并且在调用其他服务时可以通过服务名获取实时的服务列表。

• 集中化配置管理：通过 Nacos 实现集中化配置管理，动态调整微服务配置而无需重启，从而提高运维效率。

• 流量控制、熔断器和系统保护 - Sentinel

• 流量控制策略：配置合理的流量控制规则以处理突发流量和防止系统过载。

• 应用降级策略：当服务出现不稳定的行为时，自动进行服务降级，保护系统的整体稳定性。

• 实时监控和报警：结合 Sentinel 控制台实现实时监控，及时响应系统异常。

• 消息驱动 - RocketMQ

• 异步通信：使用 RocketMQ 异步处理消息，解耦服务间的通信，提高系统的扩展能力和可维护性。

• 可靠的消息传递：确保消息的可靠性和一致性，比如利用事务消息来实现最终一致性。

• 分布式事务管理 - Seata

• 分布式事务解决方案：对于需要跨服务共享事务状态的复杂业务流程，使用 Seata 管理分布式事务的提交或回滚。

• 服务间一致性保证：确保各个微服务之间数据一致性，防止系统出现数据不一致的现象。

• 微服务架构设计

• 服务拆分原则：基于业务领域对系统进行服务划分，每个微服务应有清晰的职责和边界。

• API 版本管理：设计可扩展的 API 版本管理策略，确保前后端分离和服务之间的兼容性。

• 安全和权限控制

• 身份验证和授权：使用 Spring Security、JWT 或 OAuth2 等机制实现微服务的安全访问控制。

• 敏感数据加密：对接口的敏感信息进行加密，确保数据传输的安全性。

• 弹性设计和监控

• 服务监控和日志：利用 Spring Boot Actuator、Micrometer Tracing、ELK Stack（Boot 3.x 使用 Micrometer Tracing；Sleuth 3.1 仅适用于 Boot 2.x，参见 官方迁移说明） 等工具记录、监控和分析服务运行状况和日志信息。

• 备份和灾难恢复：制定和实行灾难恢复计划，包括数据备份和服务快速恢复。

• DevOps 和持续集成/部署

• 持续集成/持续部署（CI/CD）：整合 CI/CD 系统如 Jenkins，自动化测试和部署流程，快速迭代产品功能。

• 容器化和编排：使用 Docker 和 Kubernetes 管理服务的容器化部署和自动化编排。

26、分布式事务实现方式?（可根据自身情况熟悉其中一种）

• 两阶段提交（2PC）：这是最常见的分布式事务实现方式之一。它包括两个阶段：在第一阶段，协调者向所有参与者发送prepare请求，每个参与者执行操作并返回ready消息；在第二阶段，协调者向所有参与者发送commit或者abort请求，参与者根据请求执行操作并返回结果。
• TCC（Try-Confirm-Cancel）：这种模式将分布式事务分为Try、Confirm和Cancel三个阶段。Try 阶段检查并预留业务资源，Confirm 确认使用资源，Cancel 释放预留资源；Confirm/Cancel 要支持幂等，并处理空回滚和悬挂问题。在Java中实现TCC模式的分布式事务可以使用一些成熟的框架，如Alibaba的Seata、TCC-Transaction、ByteTCC等。
• 本地消息表：这种方式是在本地事务中将要执行的消息插入到本地消息表中，然后异步地由消息发送者将消息发送出去，由消息接收者消费消息。本地事务提交后若投递失败，应保留记录并重试，不能直接回滚已经提交的事务；接收方须幂等处理，配合补偿与对账实现最终一致性。
• 最大努力通知（Best Effort Delivery）：这种方式是业务处理服务在业务处理完毕时，向下游服务“尽最大努力”发送应用内消息。如果消息接收方未能接收到消息，则消息发送方通过一定的机制重试发送消息，但不保证消息一定被接收方成功接收。
  Redis 分布式锁解决互斥，不能保证多个数据库操作一起提交或回滚，因此不应列为分布式事务方案。若业务另外需要锁，应使用原子 SET key token NX PX ttl 获取锁（token 每次获取唯一），并以比较 token 后删除的原子操作释放；拆成 SETNX 再 EXPIRE 存在崩溃窗口。锁超时后旧持有者仍可能继续执行，必要时还需资源端校验 fencing token。参见 Redis 官方分布式锁说明。

27、什么是SchedulerX？有什么作用？（了解）

• SchedulerX是阿里云提供的分布式任务调度平台。它提供了秒级、精准、高可靠、高可用的定时任务调度服务，并支持多种类型的任务调度，如简单单机任务、简单多机任务、脚本任务以及网格任务。

• SchedulerX的主要作用包括：

• 分布式任务调度：SchedulerX可以在分布式系统中进行任务调度，支持多种调度模式和异构计算框架，提供了灵活、高效、可靠的多种调度方式。

• 任务编排和运维自动化：通过SchedulerX，用户可以轻松地构建分布式任务和工作流调度，实现任务编排和运维自动化。这有助于提高系统的效率和可靠性，降低运维成本。

• 支持多种任务类型：SchedulerX支持多种任务类型，包括Java、Shell、Python、Go脚本、HTTP以及自定义任务类型。这使得用户可以根据实际需求选择适合的任务类型进行调度。

• 丰富的运维能力：SchedulerX提供了丰富的运维能力，包括数据大盘（可视化查看任务执行状况）、日志查看、原地重跑、标记成功、任务停止等功能。这些功能有助于用户更好地监控和管理任务调度过程。

• 高可用性和容错性：SchedulerX具有高可用性和容错性，能够确保在分布式系统中稳定运行。即使某个节点出现故障，SchedulerX也能够自动进行故障转移和恢复，确保任务调度的连续性和可靠性。

28、什么是CAP理论？（了解）

CAP 原理（也称为 CAP 理论）是分布式系统中的核心概念，由计算机科学家 Eric Brewer 提出。它包含三个基本要素：

1. 一致性（Consistency）：这里指线性一致性：操作表现为按一个符合真实时间先后关系的顺序作用于单份数据，而不是要求节点物理时刻同步。
2. 可用性（Availability）：非故障节点收到的每个请求最终都能获得符合操作语义的响应；仅返回错误不能算满足这里的可用性。
3. 分区容错性（Partition Tolerance）：讨论允许发生网络分区（节点间消息丢失或无限延迟）的故障模型，而非承诺分区时所有服务都正常。

CAP 原理的核心观点：在允许网络分区的系统中，发生分区时无法同时保证线性一致性与上述可用性，需要在 C 与 A 之间权衡；不能简化成任何时刻都任意“三选二”。

实际应用中的取舍：

• CP 系统：放弃可用性，保证一致性和分区容错性。例如，分布式数据库系统在网络分区时选择拒绝请求以保证数据一致性。
• AP 系统：放弃一致性，保证可用性和分区容错性。例如，某些数据库配置允许分区两侧继续接受请求，随后协调冲突；不能把所有 NoSQL 数据库都归为 AP。

重要性：理解 CAP 原理有助于设计和构建可靠的分布式系统，根据业务需求选择合适的架构和技术方案。

理论定义参见 Gilbert 与 Lynch 的 CAP 原始论文。