微服务面试题
课程内容架构
- Spring Cloud 部分
- 服务注册：重点讲解（Nacos）和（Eureka），这是微服务架构中实现服务发现与注册的关键组件，确保服务间能够相互定位与通信。
- 负载均衡：涵盖 ribbon 的负载均衡策略及自定义负载均衡方法。ribbon 可依据不同规则将请求合理分配到多个服务实例，如轮询、随机等策略，自定义负载均衡则能根据特定业务需求灵活调整分配方式。
- 熔断和降级：在微服务系统面临高并发或部分服务故障时，熔断机制可及时切断故障服务调用链路，防止故障蔓延；降级策略则通过暂时关闭或简化非关键服务功能，保障核心服务稳定运行，确保系统整体可用性。
- 监控：介绍 sky working 链路追踪技术，它能够对微服务调用链路进行跟踪记录，帮助开发人员快速定位问题根源，如请求延迟、错误发生位置等，有效提升系统运维与故障排查效率。
- 业务相关内容
- 限流：随着业务快速发展，流量可能超出服务承载能力，需进行限流。主要讲解漏桶算法和令牌桶算法，漏桶算法以固定速率处理请求，令牌桶算法则是按一定速率生成令牌，请求需获取令牌才能被处理，通过这些算法可有效控制进入系统的流量。
- 分布式事务：先阐述 CAP 和 BASE 理论，CAP 强调强一致性和分区容错性，BASE 则在牺牲一定一致性的基础上保证可用性和分区容错性。接着讲解分布式事务的解决方案，最后介绍主流分布式事务框架 SEATA，其为解决微服务架构下分布式事务问题提供了可靠的实现方式，确保跨多个服务的事务操作数据一致性。
- 分布式服务接口幂等：在分布式环境中，由于网络波动等原因可能导致同一请求多次发送，幂等方案可保证同一操作多次执行结果与一次执行结果相同，避免重复操作带来的数据不一致等问题。
- 分布式任务调度：基于插槽 job 讲解如何在分布式系统中合理安排任务执行时间、顺序及资源分配，确保任务高效、准确执行，满足业务定时或触发式任务处理需求。
- 消息中间件部分
- 主要包含 RabbitMQ 和 Kafka。消息中间件在微服务架构中起着重要的异步通信、解耦作用，RabbitMQ 以其丰富的消息路由机制和可靠性保障在企业级应用中广泛使用，Kafka 则擅长处理高吞吐量的实时数据流场景。
一、Spring Cloud 面试题引入
- 面试官常问 Spring Cloud 5 大组件相关问题，如"spring cloud 5 大组件有哪些"或"spring cloud 组件有哪些"，旨在考查对 Spring Cloud 的基本认识。
- 此题为送分送命题，即使经验丰富也需充分准备，若回答不出可能导致面试无法继续。
二、基于架构图分析组件
- 展示微服务项目简易架构图，微服务按业务划分（如用户、文章等）。
- 微服务间远程调用需管理服务地址，引出注册中心组件。
- 远程调用组件在服务集群场景下需结合 ribbon 进行负载均衡。
三、Spring Cloud 五大组件详解
- 注册中心：管理微服务地址，是重要基础组件。
- Feign：实现微服务间通信。
- ribbon：用于服务集群的负载均衡。
- hystrix：在远程调用中处理降级和熔断。
- 网关：作为微服务对外暴露接口的统一入口。
- 虽 Spring Cloud 组件不止 5 个，但面试时这 5 个必须回答，可结合项目架构图或示例图进行说明。
四、回答面试题及阿里体系组件对比
- 回答 Spring Cloud 五大组件为注册中心（如 Eureka）、负载均衡（ribbon）、远程调用（Feign）、熔断（Hystrix）、网关（Gateway）。
- 对比阿里巴巴体系组件：注册中心和配置中心可用 Nacos，负载均衡仍为 ribbon，服务保护是 Sentinel，网关为 Gateway。
注册中心面试题
一、面试题引入
- 核心问题：服务注册和发现的含义以及 Spring Cloud 如何实现。此问题用于考察应聘者对微服务中注册中心的理解与运用，常见注册中心有（Eureka）、（Nacos）、Zookeeper（常与 Dubbo 搭配），重点讲解 Eureka 和 Nacos。
- 回答要点：先说明项目所用注册中心，再分别阐释服务注册与发现机制。
二、Eureka 注册中心详解
- 作用阐释：在微服务架构中，如订单服务（Order Service）调用用户服务（User Service）场景下，若用户服务存在集群，注册中心可管理服务地址。服务提供者（如 User Service）启动时将自身信息（服务名、IP、端口等）注册到 Eureka，服务消费者（如 Order Service）从 Eureka 拉取信息，并经负载均衡选择服务器调用。
- 工作流程：服务提供者启动注册信息，注册中心存储；服务消费者从注册中心拉取信息，通过负载均衡确定调用目标。
- 健康监控：服务提供者每隔 30 秒向 Eureka 发送心跳报告健康，若 90 秒未收到心跳，Eureka 认定实例宕机并从服务列表删除。
- 回答面试官问题要点：告知项目采用 Eureka 作为 Spring Cloud 核心组件，解释服务注册是提供者信息注册到 Eureka 保存，服务发现是消费者拉取信息，有集群和消费者时利用负载均衡算法选择调用，同时提及服务监控的心跳机制及宕机处理。
三、Nacos 与 Eureka 对比
- 相同点：均支持服务注册、拉取及以心跳方式进行健康检测。
- 不同点
- 实例类型与监测方式：Nacos 有临时实例（默认创建，采用心跳监测健康）和非临时实例（需设置，由 Nacos 主动探测）之分，Eureka 无此概念。
- 信息变更处理：服务地址变更时，Nacos 注册中心主动推送更新信息，Eureka 仅依靠服务消费者拉取信息。
- 集群模式与功能扩展 ：Nacos 集群默认 AP 模式，存在非临时实例时为 CP 模式，且 Nacos 3 支持配置中心，Eureka 仅为注册中心。
- 回答面试官问题要点：先指出共同点，再详细说明不同点，包括实例类型差异、信息变更处理、集群模式及功能扩展等方面。
