SpringCloud 高频面试题（真实企业面试版）

SpringCloud高频面试题（真实企业面试版）一、SpringCloud基础认知（初级必问）1、简单说说你对SpringCloud的理解？和SpringBoot的区别？SpringCloud是一套微服务一站式解决方案，基于SpringBoot开发，用于解决分布式系统中的服务注册发现、配置管理、网关路由、熔断限流、远程调用等一系列问题，是目前国内最主流的微服务落地框架。和SpringBoot的核心区别：SpringBoot是单体快速开发框架，专注于简化单个项目的搭建、配置、部署，用来开发独立的微服务单体应用；SpringCloud是分布式微服务治理框架，依赖SpringBoot，专注于多个微服务之间的协调、通信、治理、容错。2、微服务和单体架构的优缺点，以及为什么要用SpringCloud？单体架构：所有业务代码在一个项目中，部署简单、测试简单，但后期业务庞大后，耦合严重、迭代慢、单点故障、无法单独扩容。微服务架构：按业务模块拆分独立服务，服务独立开发、部署、扩容、迭代，容错性高；但缺点是运维复杂、分布式问题多（事务、超时、重试、服务治理）。SpringCloud就是为了解决微服务的治理痛点，标准化了微服务开发的各类组件，不用自己手写服务注册、网关、熔断等基础能力，开箱即用、社区成熟、适配企业级开发。3、SpringCloud核心组件你用过哪些？各自作用是什么？日常开发最常用的核心组件：Nacos：服务注册中心+配置中心，替代传统Eureka、Config；OpenFeign：声明式远程调用，简化服务之间接口调用；LoadBalancer：客户端负载均衡，替代旧版Ribbon；Gateway：微服务网关，负责路由转发、鉴权、限流、过滤；Sentinel：熔断、限流、降级、流量整形，做服务容错；Seata：分布式事务解决方案，解决微服务跨库事务问题；SpringCloudStream：消息驱动框架，适配RabbitMQ、Kafka做服务异步通信。4、SpringCloud和SpringCloudAlibaba的关系？SpringCloud是原生的微服务规范，早期组件比如Eureka、Zuul、Hystrix大多已经停止更新，逐渐淘汰。SpringCloudAlibaba是阿里基于SpringCloud规范封装的一套全新替代组件，完全兼容原生SpringCloud，组件更稳定、持续迭代、适配国内企业场景，目前企业开发基本都以SpringCloudAlibaba为主。核心替代关系：Nacos替代Eureka+Config、Sentinel替代Hystrix、Gateway替代Zuul。二、注册配置中心（Nacos高频）1、Nacos相比Eureka、Consul的优势？Eureka已停止维护，功能单一，只支持服务注册，没有配置中心能力；Nacos同时支持服务注册发现+动态配置，一站式解决两个核心需求；支持AP、CP切换，集群稳定性更高，界面可视化，运维简单；支持配置热更新，无需重启服务即可更新配置，适配生产动态调整。2、Nacos服务注册原理、心跳机制是什么？服务启动后，会主动向Nacos服务端注册自身服务信息（服务名、IP、端口、健康状态）。心跳机制：客户端默认每5秒向服务端发送心跳包，上报健康状态；服务端如果15秒内未收到心跳，标记服务不健康；30秒未收到则直接剔除该服务实例。消费者拉取服务列表时，只会获取健康的实例，实现故障节点自动剔除。3、Nacos配置热更新原理？如何实现不重启刷新配置？Nacos客户端会长轮询服务端配置信息，一旦配置文件发生变更，服务端会推送变更通知到客户端，客户端实时加载新配置。项目中两种常用实现方式：使用@RefreshScope注解，修饰需要动态刷新的配置类，自动刷新；使用@ConfigurationProperties绑定配置，配合nacos自动刷新配置，无需手动干预。4、Nacos集群是AP还是CP？什么时候切换？Nacos在服务注册发现场景是AP模式（优先可用性），微服务注册更看重高可用，允许短暂数据不一致，保证服务不瘫痪；配置中心场景是CP模式（优先一致性），配置数据必须精准一致，不能出现多节点配置不同的情况。三、远程调用与负载均衡（OpenFeign+LoadBalancer）1、OpenFeign的工作原理？为什么比普通RestTemplate好用？OpenFeign是声明式远程调用框架，基于接口注解实现远程调用。开发时只需定义接口、写注解，不用手动拼接URL、处理请求参数，底层自动帮我们封装HTTP请求。优势：代码简洁、可维护性高、统一接口规范、天然集成负载均衡，适配微服务多实例调用。2、LoadBalancer负载均衡策略有哪些？默认策略是什么？SpringCloud新版移除Ribbon后，默认使用LoadBalancer做客户端负载均衡。默认策略：轮询，按顺序轮流调用服务实例。常用策略：轮询、随机、加权轮询、最小连接数，支持自定义负载均衡策略。3、OpenFeign调用超时怎么解决？重试机制了解吗？OpenFeign默认超时时间较短，生产环境容易出现调用超时异常，可手动配置连接超时、读取超时时间。重试机制：默认关闭，可手动开启。请求失败、超时、网络异常时，自动重试调用，规避临时网络抖动问题；但需要注意幂等性，非幂等接口禁止开启重试，避免重复提交数据。4、微服务调用出现接口超时、连接失败，怎么排查和优化？排查步骤：查看服务实例是否健康、Nacos注册状态是否正常；检查Feign超时时间配置是否过小，不满足业务耗时；查看被调用服务是否卡顿、GC频繁、线程池耗尽；排查网络、端口、防火墙问题。优化方案：合理配置超时时间、开启重试、添加熔断降级、异步调用、拆分耗时接口。四、网关Gateway核心面试题1、Gateway和Zuul的区别？为什么现在都用Gateway？Zuul基于Servlet阻塞模型，每一个请求占用一个线程，高并发场景下线程容易耗尽，性能较差，且已停止迭代更新。Gateway基于WebFlux非阻塞响应式编程，异步模型，高并发性能远超Zuul，支持动态路由、自定义过滤器、限流、重试，适配微服务高并发场景，是目前主流网关。2、Gateway的核心组件是什么？执行流程？三大核心组件：路由（Route）：核心规则，包含请求路径、匹配规则、目标服务地址；断言（Predicate）：根据请求参数、路径、时间、IP等匹配路由；过滤器（Filter）：对请求和响应进行拦截处理，比如鉴权、限流、日志、跨域。执行流程：客户端请求抵达网关->断言匹配路由->前置过滤器处理->转发到目标服务->后置过滤器处理->返回响应。3、Gateway如何实现全局限流、IP限流？项目中常用令牌桶算法+Redis实现分布式限流，自定义全局过滤器，拦截所有请求，根据IP、用户ID或者接口维度统计请求次数，超出阈值直接拦截返回限流提示，防止服务被打垮。4、网关跨域问题怎么解决？两种常用方案：yml配置全局跨域规则，统一放行前端请求头、请求方法；自定义跨域过滤器，优先级最高，统一处理跨域，避免各个微服务单独配置导致混乱。五、容错机制（Sentinel核心）1、熔断、降级、限流的区别和使用场景？限流：限制请求流量，防止瞬时高并发打垮服务，比如秒杀、活动场景；熔断：下游服务频繁超时、报错，直接熔断不再调用，避免级联故障、雪崩；降级：服务异常或流量过大时，放弃非核心业务，返回兜底数据，保证核心业务可用。2、Sentinel熔断规则有哪些？慢调用比例、异常比例、异常数？Sentinel核心熔断策略：慢调用比例：统计时间内，超时请求占比超过阈值，触发熔断；异常比例：请求报错比例超过阈值，触发熔断；异常数：异常请求数量达到阈值，直接熔断。熔断后会进入静默窗口期，窗口期内直接走降级兜底，窗口期结束后尝试半开探测，恢复正常则关闭熔断。3、Sentinel流量整形的两种方式？直接限流：超出流量直接拒绝，抛出异常；排队等待：匀速排队，让请求匀速进入服务，削峰填谷，避免瞬间流量冲击。六、分布式事务（Seata）1、微服务为什么会产生分布式事务问题？微服务按业务拆分后，一个业务操作可能涉及多个服务、多个数据库，本地事务只能控制单个库，无法保证跨服务、跨库的数据一致性，最终出现部分成功、部分失败的数据不一致问题，所以需要分布式事务解决。2、Seata四种事务模式？各自优缺点和适用场景？AT模式（默认）：无侵入、自动回滚，适合绝大多数业务，性能较好，企业最常用；TCC模式：手动实现确认、取消、预留，侵入性高，性能最好，适合核心高并发业务；SAGA模式：长事务、异步事务场景，适合耗时久的业务，无锁，一致性较弱；XA模式：强一致性，性能差，基本不用于生产。3、简单说下AT模式的执行流程？分为一阶段、二阶段提交、二阶段回滚：一阶段：执行业务SQL，同时记录undo日志（数据快照），本地事务提交，释放锁和连接；二阶段正常：全局事务提交，删除undo日志，流程结束；二阶段异常：根据undo日志回滚数据，保证所有服务数据一致。七、实战场景与进阶面试题（中高级必问）1、什么是服务雪崩、服务穿透、服务堆积？怎么解决？服务雪崩：下游服务故障，导致上游服务大量请求超时、阻塞，最终拖垮整个链路，解决方案：熔断、降级、隔离。服务穿透：大量空请求、无效请求直接打到数据库，解决方案：缓存预热、布隆过滤器、参数校验。服务堆积：请求处理速度慢，请求不断堆积，线程池耗尽，解决方案：限流、异步处理、拆分业务、优化接口性能。2、微服务接口幂等性怎么保证？微服务重试、重复提交很容易产生脏数据，必须保证幂等，常用方案：唯一索引、数据库去重；Token令牌机制，单次请求有效；分布式锁控制重复操作；业务唯一单号幂等校验。3、SpringCloud微服务怎么实现日志链路追踪？通过Sleuth+Zipkin或SkyWalking实现，一次请求生成唯一traceId，贯穿网关、所有微服务调用链路，所有日志携带同一个traceId，可快速串联整条调用链路，定位报错位置。4、微服务部署、扩容怎么做？