一、基础认知类（必问，入门级）
1. 什么是 Spring Cloud？它的核心价值是什么？
答案：
Spring Cloud 是基于 Spring Boot 构建的微服务架构生态体系，不是一个单一框架，而是一系列组件的集合，核心价值是“简化微服务架构的搭建与运维”，提供了服务注册发现、配置管理、负载均衡、熔断降级、网关路由等一站式解决方案，让开发者无需关注分布式通信、容错等底层细节，专注于业务开发。
2. 微服务架构的核心特点是什么？与单体架构的核心区别？
答案：
（1）微服务核心特点： ① 单一职责：每个服务聚焦一个业务领域，不追求“大而全”； ② 独立部署：每个服务可单独开发、测试、部署，不影响其他服务； ③ 低耦合：服务间通过轻量级协议（HTTP/REST）通信，无直接代码依赖； ④ 可扩展：按需水平扩容，高并发服务可单独扩容，资源利用率高； ⑤ 容错性：单个服务故障不影响整体业务，配合熔断降级机制保障稳定。
（2）与单体架构的核心区别： ① 单体架构：代码耦合度高、整体部署、扩展能力弱、单点故障风险高，适合小型项目； ② 微服务架构：代码耦合度低、独立部署、扩展灵活、容错性强，适合中大型项目，核心是“拆分”与“协同”。
3. Spring Cloud 与 Spring Boot 的关系是什么？
答案：
二者是“基础与生态”的关系，不可分割，核心区别与联系： ① 联系：Spring Cloud 依赖 Spring Boot 实现服务的快速开发，每个微服务本质都是一个 Spring Boot 应用；Spring Boot 提供单体应用的快速开发能力（简化配置、一键启动），Spring Cloud 在此基础上实现微服务的协同治理（如注册发现、负载均衡）。 ② 区别：Spring Boot 聚焦“单个服务的开发”，解决单体应用的配置、启动问题；Spring Cloud 聚焦“多个服务的协同”，解决微服务架构的分布式问题。
4. Spring Cloud 与 Dubbo 的核心区别？选型建议是什么？
答案：
（1）核心区别： ① 定位不同：Spring Cloud 是微服务生态体系，提供一站式解决方案（注册、配置、网关、容错等）；Dubbo 是RPC 通信框架，仅专注于服务间的高性能通信。 ② 通信协议：Spring Cloud 默认基于 HTTP/REST（开发简单、跨语言）；Dubbo 基于自定义 Dubbo 协议（二进制传输，性能更高）。 ③ 生态完善度：Spring Cloud 组件丰富，无需额外集成其他工具；Dubbo 生态较单一，需配合 Zookeeper（注册）、Sentinel（容错）等组件使用。
（2）选型建议： ① 中小型微服务、跨语言场景、追求开发效率：选 Spring Cloud（生态完善、易用）； ② 大型企业、高并发、低延迟场景、内部服务通信：选 Dubbo（性能优）； ③ 折中方案：Spring Cloud 集成 Dubbo，兼顾生态完整性和通信高性能。
5. Spring Cloud 的版本体系有什么特点？常用版本有哪些？
答案：
① 版本特点：Spring Cloud 没有统一的版本号，采用“伦敦地铁站名”命名，每个版本对应一套稳定的组件版本组合，避免组件版本冲突（如 Hoxton、Ilford、Jubilee）。 ② 常用版本： - Spring Cloud Hoxton：稳定版，对应 Spring Boot 2.2.x-2.4.x，组件成熟，适配传统微服务场景； - Spring Cloud 2020.0.x（Ilford）：对应 Spring Boot 2.4.x+，移除 Netflix 过时组件（Eureka、Zuul），推荐 Spring Cloud Alibaba； - Spring Cloud 2021.0.x（Jubilee）：对应 Spring Boot 2.6.x+，强化云原生支持，简化组件。
二、核心组件类（必问，进阶级）
1. 服务注册发现的核心作用是什么？Spring Cloud 中有哪些常用的注册中心？对比区别？
答案：
（1）核心作用：解决“服务之间如何找到对方”的问题，服务启动时注册自身信息（IP、端口、服务名）到注册中心，服务调用时通过服务名查询目标服务地址，实现动态寻址，无需硬编码服务地址。
（2）常用注册中心及对比： ① Eureka（Netflix 组件）： - 原理：C/S 架构，支持集群部署、自我保护机制（网络波动时不删除服务）； - 缺点：已停止维护，不支持云原生，性能一般。 ② Nacos（Spring Cloud Alibaba）： - 原理：支持 AP/CP 模式切换，集“注册中心+配置中心”于一体，基于 Raft 协议实现高可用； - 优势：功能全面、性能优、支持动态配置刷新、国内文档完善，企业首选。 ③ Consul（HashiCorp）： - 原理：CP 模式，支持服务注册、配置管理、服务网格，适配云原生； - 优势：多数据中心支持，缺点：国内使用较少，配置复杂。
2. Nacos 的核心功能是什么？AP 模式和 CP 模式的区别？什么时候用哪种模式？
答案：
（1）核心功能： ① 服务注册发现：支持服务注册、心跳检测、服务列表查询，适配微服务通信； ② 配置管理：支持集中式配置管理、动态配置刷新、多环境配置隔离，替代 Spring Cloud Config； ③ 高可用：集群部署，基于 Raft 协议实现数据一致性，单个节点宕机不影响服务。
（2）AP 与 CP 模式区别： - AP 模式（默认）：优先保证高可用和分区容错性，数据最终一致，适合服务注册发现（允许短暂数据不一致，优先保证服务可用）； - CP 模式：优先保证数据一致性和分区容错性，牺牲部分可用性，适合配置管理（配置必须一致，否则会导致服务异常）。
3. Spring Cloud Gateway 的核心作用是什么？核心组件有哪些？与 Zuul 的区别？
答案：
（1）核心作用：作为微服务架构的统一入口，负责路由转发、请求过滤、身份认证、限流熔断、日志监控，实现服务的统一管控，隔离外部请求与内部服务。
（2）核心组件： ① Route（路由）：网关核心配置，包含 ID、目标服务地址、路由规则、过滤器； ② Predicate（断言）：用于匹配请求（如路径、请求方法、请求头），决定是否触发路由； ③ Filter（过滤器）：对请求/响应进行处理（如添加请求头、限流、熔断），分为全局过滤器和局部过滤器。
（3）与 Zuul 的区别： ① 底层实现：Gateway 基于 Spring WebFlux（响应式编程），非阻塞 IO，性能高；Zuul 基于 Servlet（阻塞 IO），性能差； ② 维护状态：Gateway 是 Spring Cloud 官方推荐，持续维护；Zuul 是 Netflix 组件，已停止维护； ③ 功能：Gateway 支持非阻塞、动态路由、限流，适配云原生；Zuul 功能简单，仅支持基础路由和过滤。
4. OpenFeign 的核心作用是什么？原理是什么？与 Feign 的区别？
答案：
（1）核心作用：基于 Ribbon 的声明式服务调用组件，简化服务调用代码，无需手动编写 RestTemplate 代码，通过注解驱动实现服务间的 HTTP 通信。
（2）核心原理： ① 主类添加 @EnableFeignClients 注解，开启 Feign 支持； ② Feign 根据 @FeignClient（指定服务名）注解生成动态代理对象； ③ 动态代理将接口方法（如 @GetMapping）转换为 HTTP 请求，调用目标服务； ④ 自动集成 Ribbon，实现负载均衡；支持集成 Sentinel/Resilience4j，实现熔断降级。
（3）与 Feign 的区别： - Feign：Netflix 开源组件，需使用自身注解，已停止维护； - OpenFeign：Spring Cloud 对 Feign 的增强版，支持 Spring MVC 注解（@GetMapping、@PostMapping），集成 Spring 生态，持续维护，是官方推荐。
5. Ribbon 的核心作用是什么？常用的负载均衡算法有哪些？
答案：
（1）核心作用：客户端负载均衡器，在服务调用方（OpenFeign/RestTemplate）实现负载均衡，将请求分发到多个服务实例，提升服务可用性和并发处理能力。
（2）常用负载均衡算法： ① RoundRobinRule（默认）：轮询，依次分发请求到每个实例，均衡分配负载； ② RandomRule：随机选择实例，适合服务实例性能一致的场景； ③ WeightedResponseTimeRule：加权轮询，根据实例响应时间分配权重（响应时间越短，权重越高），优化响应速度； ④ RetryRule：重试机制，请求失败后，重试其他实例，提升请求成功率。
6. Sentinel 的核心功能是什么？熔断和降级的区别是什么？
答案：
（1）核心功能：阿里开源的企业级流量控制组件，解决微服务的容错、限流问题，核心功能包括： ① 流量控制：QPS 限流、并发数限流、热点参数限流； ② 熔断降级：服务故障时，熔断服务、返回兜底结果，防止故障扩散； ③ 系统自适应保护：监控系统负载，避免系统被压垮； ④ 可视化控制台：动态配置规则、实时监控流量。
（2）熔断和降级的区别： - 熔断：被动触发，当服务调用失败率达到阈值（如50%），熔断器打开，拒绝请求，防止故障扩散；一段时间后进入半打开状态，尝试恢复服务； - 降级：主动触发，当系统压力过大（如高并发）或服务不可用时，主动返回兜底结果（如默认数据），牺牲非核心功能，保证核心功能可用。
7. Spring Cloud Config 与 Nacos Config 的区别？为什么推荐 Nacos Config？
答案：
（1）核心区别： ① 功能：Spring Cloud Config 仅支持配置管理，需配合 Spring Cloud Bus 实现动态刷新；Nacos Config 集“配置管理+服务注册”于一体，原生支持动态刷新； ② 高可用：Spring Cloud Config 需额外搭建集群，配置更新延迟；Nacos Config 集群部署，基于 Raft 协议，高可用、配置更新实时； ③ 易用性：Spring Cloud Config 配置复杂，需关联 Git/SVN；Nacos Config 可视化控制台，配置简单，支持多环境隔离。
（2）推荐 Nacos Config 的原因：功能全面、配置简单、动态刷新、高可用、适配国内场景，无需集成多个组件，简化架构。
三、架构设计类（高频，实战级）
1. 企业级微服务架构的经典分层是什么？各层的核心职责是什么？
答案：
经典四层架构（按请求流向），各层职责清晰、低耦合： ① 接入层：API Gateway（Gateway/Sentinel），核心职责：路由转发、限流、身份认证、日志监控，是客户端唯一入口； ② 业务服务层：核心业务微服务（如用户服务、订单服务），核心职责：聚焦单一业务领域，实现业务逻辑，独立开发、部署； ③ 公共服务层：通用服务（如认证服务、消息服务），核心职责：供所有业务服务调用，实现功能复用； ④ 数据层：数据库（MySQL、Redis）、消息队列（RabbitMQ），核心职责：数据存储、异步通信，解耦服务。
2. 微服务架构的核心设计原则有哪些？
答案：
核心6大原则，确保架构稳定、可扩展： ① 单一职责原则：每个微服务仅负责一个业务领域，不追求“大而全”； ② 高内聚低耦合原则：服务内部逻辑高度内聚，服务间仅通过接口通信，无直接代码依赖； ③ 去中心化原则：注册中心、配置中心集群部署，避免单点故障； ④ 容错原则：每个服务必须实现熔断、降级、限流，防止故障扩散； ⑤ 可扩展原则：服务支持水平扩容，适配高并发场景； ⑥ 可监控原则：所有服务接入监控系统，实时监控运行状态，快速定位故障。
3. 微服务架构中，为什么需要 API 网关？网关的核心作用有哪些？
答案：
（1）需要网关的原因： 微服务架构中，服务数量多、地址不固定，客户端直接调用多个服务会导致：请求分散、身份认证复杂、无法统一限流监控，网关作为“统一入口”，解决以上问题，简化客户端调用和服务管控。
（2）网关核心作用： ① 路由转发：根据请求路径，将请求分发到对应服务，隐藏服务地址； ② 身份认证：统一校验 Token、权限，避免每个服务单独实现认证； ③ 限流熔断：限制请求QPS，熔断异常服务，保护系统； ④ 日志监控：统一记录请求日志，便于排查问题； ⑤ 请求过滤：修改请求/响应头、参数，适配服务需求。
4. 微服务架构中，如何实现服务之间的通信？有哪些方式？
答案：
核心分为两类通信方式，按需选择： ① 同步通信（常用）： - OpenFeign + Ribbon：声明式调用，开发简单，适配大多数场景； - RestTemplate + Ribbon：编程式调用，灵活度高； - gRPC：基于 HTTP/2，二进制传输，高性能，适合高频、低延迟场景。 ② 异步通信（解耦）： - 消息队列（RabbitMQ、Kafka）：服务间通过消息通信，无需同步等待，解耦服务，应对高并发、削峰填谷； - 适用场景：非核心业务（如消息通知、日志异步处理）。
四、实战问题类（必问，难点）
1. 微服务架构中，服务雪崩是什么？如何解决？
答案：
（1）服务雪崩定义：一个服务故障（如响应超时、宕机），导致依赖该服务的所有服务都故障，像雪崩一样扩散，最终导致整个系统崩溃。
（2）解决方案（核心4点）： ① 熔断：使用 Sentinel/Resilience4j，当服务失败率达到阈值，熔断服务，拒绝请求，防止故障扩散； ② 降级：服务不可用时，返回兜底结果（如默认数据），保证核心功能可用，牺牲非核心功能； ③ 隔离：使用线程池隔离或信号量隔离，避免单个服务占用过多资源，影响其他服务； ④ 限流：限制服务的并发请求数，防止服务过载，避免因高并发导致服务故障。
2. 微服务中的分布式事务问题如何解决？常用方案有哪些？
答案：
（1）问题定义：多个服务之间的数据库操作，需要保证“要么全部成功，要么全部失败”，否则会出现数据不一致（如订单服务创建订单，库存服务扣减库存，一方成功、一方失败）。
（2）常用解决方案（按优先级排序）： ① 最终一致性方案（推荐，企业常用）：基于消息队列实现，采用“本地事务 + 消息通知”模式，服务执行本地事务后，发送消息通知其他服务，失败则重试，保证数据最终一致； ② Seata（阿里开源）：支持 AT（自动事务）、TCC（补偿事务）模式，简化分布式事务开发，适合复杂场景； ③ 2PC/3PC 方案：传统分布式事务方案，性能较差，存在阻塞问题，不推荐用于高并发场景。
3. 微服务接口的幂等性如何保证？常用方案有哪些？
答案：
（1）问题定义：同一请求多次调用，结果一致，不会出现重复数据（如重复下单、重复支付）。
（2）常用解决方案： ① 唯一标识：为每个请求生成唯一 ID（如 UUID、雪花算法），服务端存储请求 ID，重复请求直接返回结果； ② 数据库唯一约束：在数据库表中添加唯一索引（如订单号、用户ID+业务类型），防止重复插入； ③ 乐观锁：使用 version 字段，更新数据时判断版本号，版本不一致则拒绝更新，避免重复修改； ④ Redis 缓存：将请求 ID 存入 Redis，设置有效期，有效期内拒绝重复请求。
4. 微服务中，服务调用超时问题如何解决？
答案：
核心从“超时配置、重试、性能优化”三个维度解决： ① 配置合理的超时时间：OpenFeign、Gateway 配置 connect-timeout（连接超时）和 read-timeout（读取超时），避免无限等待； ② 重试机制：使用 Resilience4j 配置重试策略，请求失败后，重试其他服务实例，提升成功率； ③ 异步调用：非核心业务采用异步调用（如消息通知），避免阻塞主流程； ④ 性能优化：优化服务接口（减少数据库查询）、缓存热点数据（Redis）、优化数据库索引，提升服务响应速度。
5. 微服务配置中心的高可用如何保证？
答案：
核心3点，避免配置中心宕机导致服务不可用： ① 集群部署：Nacos/Apollo 集群部署，基于 Raft 协议实现数据一致性，单个节点宕机，其他节点正常提供服务； ② 本地缓存：服务启动时，将配置缓存到本地，配置中心宕机时，服务使用本地缓存的配置继续运行，不影响核心功能； ③ 降级策略：配置中心宕机时，服务启动默认配置，保证服务能正常启动，后续配置中心恢复后，同步最新配置。
五、进阶拓展类（高频，提升竞争力）
1. Spring Cloud 如何适配云原生？核心方案有哪些？
答案：
云原生是微服务的发展方向，Spring Cloud 适配云原生的核心方案： ① 容器化部署：使用 Docker 打包微服务，保证环境一致性；使用 K8s 实现服务编排、自动扩容、自愈； ② 服务网格（Service Mesh）：使用 Istio 替代传统组件（Ribbon、Feign），实现服务通信、熔断、限流的统一管控，降低服务耦合； ③ 原生镜像：Spring Cloud 3.x 支持 GraalVM 原生镜像，实现服务毫秒级启动、低内存占用，适配云原生轻量化需求； ④ Serverless：基于 Spring Cloud Function，实现无服务器部署，按需付费，降低运维成本。
2. Spring Cloud 3.x 有哪些核心新特性？
答案：
核心新特性，适配云原生和 Java 新版本： ① 移除过时组件：移除 Netflix Eureka、Zuul、Hystrix 等停止维护的组件，推荐 Nacos、Gateway、Resilience4j； ② 支持 GraalVM 原生镜像：实现服务快速启动、低内存占用，提升部署效率； ③ 强化响应式编程：基于 Spring WebFlux，提升服务并发处理能力，适配高并发场景； ④ 简化配置：优化自动配置，减少配置冗余，提升开发效率； ⑤ 增强云原生支持：更好适配 K8s、Istio 等云原生组件，支持多云部署。
3. 微服务链路追踪的核心作用是什么？Spring Cloud 中如何实现？
答案：
（1）核心作用：追踪请求的调用链路，记录每个服务的调用顺序、响应时间、错误信息，快速定位服务故障和性能瓶颈（如某个接口响应慢，定位到具体哪个服务出问题）。
（2）实现方案：Spring Cloud Sleuth + Zipkin ① Spring Cloud Sleuth：为每个请求生成唯一 Trace ID（链路ID）和 Span ID（跨度ID），标记请求的调用链路； ② Zipkin：收集 Sleuth 生成的链路数据，提供可视化界面，展示请求的调用流程、每个服务的响应时间，便于排查问题。
4. 微服务监控体系如何搭建？核心组件有哪些？
答案：
企业级微服务监控体系，核心分为3层，组件搭配如下： ① 基础监控：Spring Cloud Actuator，暴露服务运行指标（JVM内存、CPU、接口响应时间）、健康状态； ② 数据收集：Prometheus，收集 Actuator 暴露的指标，存储时序数据； ③ 可视化与告警：Grafana，对接 Prometheus，提供可视化监控面板，支持自定义仪表盘、告警配置（如CPU过高、接口报错率过高，触发告警）； 补充：链路追踪用 Sleuth + Zipkin，日志监控用 ELK（Elasticsearch + Logstash + Kibana）。
