微服务与分布式系统面试题
生成时间：2026-06-19 16:24 | 共 10 题 | 难度递进：基础 → 进阶 → 高阶
【面试题】1. 什么是微服务？和单体架构相比，核心区别在哪？
【标准答案】微服务就是把一个大应用拆成一组独立的小服务，每个服务只负责一个业务领域，可以独立开发、部署、扩展。跟单体最大的区别有三个：一是部署维度——单体改一行要全量发布，微服务只发布那个改动的服务就行；二是团队维度——单体只能一个团队统一节奏，微服务可以多个团队并行开发各管各的服务，互不阻塞；三是技术栈——单体绑定一种语言一套框架，微服务不同服务可以用不同技术栈最合适的。但微服务不是免费的，引入了分布式复杂性，比如网络通信、数据一致性、运维成本都会上去。一句话总结：单体是"把鸡蛋放一个篮子里省事"，微服务是"分筐放但得管好篮子间的关系"。
【面试题】2. 服务注册与发现的核心流程是怎样的？Nacos 如何保证注册中心自身高可用？
【标准答案】流程分三步：服务提供者启动时把自己的 IP、端口、元数据注册到注册中心（注册）；消费者从注册中心拉服务列表并本地缓存（发现）；提供者定时发心跳续约，注册中心检测到心跳超时就剔除（健康检查）。Nacos 做高可用靠两点：一是 AP 模式的集群部署——多个 Nacos 节点通过 Raft 协议选主写入，节点间异步同步数据，挂一个不影响读写；二是 CP 模式可选——对一致性要求高的场景（如服务元数据配置）可以切到 CP，牺牲部分可用性保证强一致。实际生产建议 3 节点集群起步，分别部署在不同机器或机架上。配合客户端缓存机制——即使注册中心全挂了，消费者还能用本地缓存兜底一段时间，不至于服务全不可用。
【面试题】3. 配置中心解决了什么问题？Apollo 和 Nacos 配置管理怎么选？
【标准答案】配置中心解决的核心痛点是"改配置不用重启"。没配置中心时，配置硬编码在代码或 properties 文件里，改个数据库地址要重新构建部署，风险大、周期长。配置中心让配置集中管理、动态刷新，改完实时生效。Apollo 和 Nacos 的选择看场景：Apollo 在配置治理上更成熟——有完善的权限体系（按环境+集群+Namespace 三级隔离）、灰度发布、版本回滚、操作审计，适合大型组织多团队协作。Nacos 的优势是注册中心+配置中心一体，部署维护简单，适合中小团队或已用 Nacos 做服务发现的场景。一句话：如果只做配置管理且团队规模大选 Apollo，如果注册和配置想一套搞定选 Nacos。
【面试题】4. 请解释 CAP 理论，并举例说明不同的业务场景如何取舍？
【标准答案】CAP 理论是说分布式系统最多同时满足一致性（C）、可用性（A）、分区容错性（P）中的两个。实际系统里 P 基本没法回避，所以本质是在 C 和 A 之间做权衡。CP 系统优先一致性：典型如银行转账——宁可暂时不可用让你等下，也不能出现余额算错。ZooKeeper 在 Leader 重新选举期间拒绝写入就是 CP 的做法。AP 系统优先可用性：典型如电商下单——你下完单看到库存扣了，用户爽了，后面库存对账微调一下就行。Nacos AP 模式、Eureka 都是 AP 思路。BASE 理论就是 AP 的落地指南：基本可用 + 软状态 + 最终一致。面试官爱听一句话：没有银弹，选 CP 还是 AP 取决于"你更怕数据错还是服务挂"。
【面试题】5. 服务熔断、降级、限流分别是什么？Sentinel 怎么实现三者统一？
【标准答案】三者都是流量防护手段，但层次不同。熔断是"这服务不行了，我先断掉别让它更惨"——下游连续失败达到阈值就切断调用，过段时间试探性放开，类似电闸跳闸。降级是"主流程走不通，给个兜底方案"——查商品详情的推荐服务挂了，返回静态热门商品列表，不让用户看到报错。限流是"不管你有多少请求，我只处理这么多"——QPS 超过 100 就直接拒绝排队。Sentinel 用资源名 + 规则链来统一实现：定义资源（@SentinelResource），配置熔断规则（慢调用比例/异常比例/异常数）、降级规则、流控规则（QPS/线程数/关联流控/热点参数），一条链路打完。它的滑动窗口统计比 Hystrix 的固定窗口更精准，而且支持控制台实时调整规则不用重启。
【面试题】6. 分布式锁的实现方案有哪些？Redisson 的看门狗机制是怎么防止锁超时的？
【标准答案】业界主要有三种：Redis 方案（SET NX + Lua 解锁，Redisson 封装）、ZooKeeper 方案（临时顺序节点 + Watch 机制）、etcd 方案（Lease 租约）。Redis 方案性能最高但只是 AP 最终一致，ZK 方案 CP 强一致但吞吐低。实际项目 90% 用 Redis/Redisson 就够。Redisson 的看门狗核心是锁续期：你设了 30 秒锁超时，如果业务没执行完，看门狗每 10 秒自动续到 30 秒，直到你主动解锁。这样就解决了"业务超时锁被释放，别的线程抢到锁"的问题。原理是后台起一个定时任务（Netty 的 HashedWheelTimer），在锁释放前循环续期。注意：必须用 Redisson 的 tryLock 不带 leaseTime 参数时才会触发看门狗，自己设了过期时间就不会启动。
【面试题】7. 分布式事务有哪几种主流方案？什么场景用 TCC 而不是可靠消息最终一致性？
【标准答案】主流方案四种：2PC（两阶段提交）、TCC（Try-Confirm-Cancel）、可靠消息最终一致性、SAGA（补偿事务）。选 TCC 不选可靠消息的关键判据：业务是否需要"同步响应"。TCC 适合对一致性要求高且需要即时反馈的场景，比如下单扣库存——扣减成功/失败必须立刻告诉用户，不能异步等消息。Try 阶段锁定资源，Confirm 真正扣减，Cancel 回滚。可靠消息适合不需要实时反馈的场景，比如下单后加积分——加分慢半拍用户感知不到，用 MQ 异步发消息 + 本地消息表保证投递就行。面试亮点：TCC 的难点是空回滚、悬挂、幂等，实践中常用 Seata TCC 模式的 @TwoPhaseBusinessAction 注解 + 状态机来规避。
【面试题】8. 灰度发布/金丝雀部署的核心理念是什么？在微服务网关层怎么落地？
【标准答案】核心理念是"先让少部分用户帮你测，没问题再全量"。灰度发布关注流量维度——5% 的流量打到新版本，95% 走老版本；金丝雀部署关注实例维度——先起一个新版实例，观察一段时间没问题再逐步替换全部实例。网关层落地常用三招：一是请求头路由——网关读取请求里带的 version header 或 cookie，按规则路由到对应版本的上游；二是权重路由——网关按配置比例随机分发到不同版本，比如 v1 占 90%、v2 占 10%；三是用户维度路由——根据 userId 哈希，特定用户固定走某个版本。Spring Cloud Gateway 可以通过自定义 GlobalFilter + LoadBalancer 的 hint 机制实现。Nacos 的 metadata 灰度标签配合即可。关键提醒：灰度一定要配合可观测性，新版本错误率、RT 一异常立刻回滚。
【面试题】9. 分布式链路追踪的核心原理是什么？SkyWalking 怎么做到零侵入？
【标准答案】核心原理是 Trace（一次请求的完整链路）+ Span（链路里的每一步调用），通过全局唯一的 TraceId 串联所有 Span，记录每个 Span 的调用关系、耗时、状态。比如一个下单请求：网关 → 订单服务 → 库存服务 → 数据库，每个边界都生成一个 Span，通过透传 TraceId 和 SpanId（父子引用）还原调用树。SkyWalking 零侵入靠 Java Agent 字节码增强：启动时加 -javaagent:skywalking-agent.jar，它在类加载阶段对主流框架（Spring MVC、Dubbo、Feign、MySQL 驱动等）的插件拦截点织入埋点代码，自动提取 TraceId、记录耗时。你代码一行不改，重启 JVM 即可接入。这就是字节码增强的威力——Hook 了框架的关键方法，而不是你手动埋点。
【面试题】10. 事件溯源和 CQRS 是什么？在什么场景下你会选这种架构而不是传统的 CRUD？
【标准答案】事件溯源的核心是"不存当前状态，存所有变更事件"。账号余额不存成 1000 元，而是存 [开户+1000, 提现-200, 转账+500...]，当前余额是事件流回放算出来的。CQRS 是读写分离：把写模型和读模型拆成两套，写走事件流，读走专门优化的查询视图。适用场景三条：一是审计合规要求高的——金融交易、订单流转，谁改了什么一清二楚；二是复杂业务逻辑——一个操作要联动多个聚合，传统 CRUD 事务耦合太深，事件驱动天然解耦；三是读写模型差异大——写很复杂（多规则校验），读很简单但 QPS 极高，CQRS 各管各互不拖累。代价是架构复杂、最终一致、学习成本高。一句话：普通增删改查别用，金融核心链路、复杂状态机场景才值得上。