2026 最新微服务面试题总结：服务拆分、通信、数据一致性与可观测性
微服务面试很少停在“什么是微服务”。面试官通常会从一次架构拆分继续追问：服务为什么这样划分？跨服务调用失败怎么办？多个服务各自管理数据后怎样查询和保证一致性？服务上线、扩容和故障恢复又如何处理？
这篇文章是 JavaGuide 微服务内容的复习入口，按架构拆分、服务通信、数据一致性、稳定性与可观测性组织现有文章。它不会重复展开所有答案，而是帮助你确定复习范围，并把分散在分布式、高可用、消息队列和安全专题中的知识串起来。
时间比较紧的话，可以先看面试突击版的微服务常见面试题总结，标出不会的问题，再回到本文对应的专题文章补细节。
复习时先抓住哪些问题？
| 模块 | 需要讲清楚的内容 | 常见追问方向 |
|---|---|---|
| 架构与拆分 | 为什么拆、按什么拆、拆到什么粒度 | 单体、集群、分布式、限界上下文、服务边界、分布式单体 |
| 通信与基础设施 | 服务怎样调用和发现彼此，外部请求怎样进入系统 | REST、RPC、消息队列、注册发现、API 网关、配置中心 |
| 数据与一致性 | 服务各自管理数据后，跨服务查询和业务事务怎样处理 | Database per Service、聚合查询、Saga、事务消息、Outbox、幂等 |
| 稳定性与交付 | 局部故障怎样被控制，服务怎样安全发布和扩缩容 | 超时、重试、熔断、限流、隔离、探针、优雅停机、兼容性 |
| 可观测性与安全 | 出现问题后怎样定位调用链，身份和权限怎样跨服务传递 | 日志、指标、追踪、告警、网关鉴权、服务端授权 |
回答微服务问题时，组件名称只是方案的一部分。还要说明拆分依据、数据归属、失败时的处理方式，以及团队是否具备独立开发、部署和运维这些服务的能力。
微服务基础与服务拆分
微服务是一种按业务能力组织服务的架构方式。一个系统进程很多，并不等于服务边界合理；如果多个服务必须一起修改、一起发布，还直接共享数据库表，最终往往得到一个运维成本更高的分布式单体。
相关内容：
常见面试题：
- 单体架构、集群、分布式系统和微服务有什么区别？
- 微服务能够带来哪些收益？网络调用、数据一致性和运维成本会增加多少复杂度？
- 哪些团队和业务阶段不适合直接采用微服务？
- 服务应该按业务能力、领域边界还是数据表拆分？
- 限界上下文和服务边界是什么关系？
- 服务拆得过细会出现哪些问题？
- 什么是分布式单体？怎样判断系统是否已经陷入这种状态？
服务拆分需要同时考虑业务变化、数据归属和团队职责。按数据库表一张表拆一个服务，通常会让一次业务操作跨越大量网络调用；只按组织结构拆，又容易在团队调整后留下不自然的服务边界。
服务通信与基础设施
服务拆开以后，原来的进程内调用会变成网络通信。同步调用需要处理超时和结果不确定，异步消息需要处理重复、顺序和最终一致性；注册发现、网关和配置中心则负责支撑服务数量增加后的寻址、流量入口和配置变更。
相关内容：
常见面试题：
- 微服务之间应该选择 REST、RPC 还是消息队列？
- 同步调用链过长会怎样放大延迟和故障？
- 一个 RPC 框架为什么需要注册发现、负载均衡、序列化和超时机制？
- 客户端服务发现和服务端服务发现有什么区别？
- API 网关应该负责路由、认证、限流和协议转换中的哪些工作？
- 网关和 Nginx、负载均衡器、BFF 分别解决什么问题？
- 配置中心为什么不能只是一个远程配置文件目录？
- 配置变更怎样灰度发布？客户端获取配置失败时怎样启动和运行？
同步和异步通信可以同时存在。用户查询通常需要同步返回，订单创建后的通知、积分和数据同步则可以使用消息队列。选型要从业务时效、失败处理和一致性要求出发，不应只按团队熟悉的框架决定。
数据拆分与一致性
服务独立演进通常要求数据归属也清晰。多个服务直接读写同一张表虽然省掉了接口调用，但任何一方修改表结构或数据语义，都可能影响其他服务，服务也很难真正独立发布。
相关内容：
常见面试题：
- 为什么强调每个微服务拥有自己负责的数据？
- 多个服务共享数据库表会造成哪些耦合？
- 跨服务查询应该使用 API 聚合、读模型、搜索引擎还是数据同步？
- 跨服务业务怎样在强一致性和最终一致性之间选择？
- 2PC、TCC、Saga、事务消息和本地消息表分别适合什么场景？
- Transactional Outbox 怎样处理“数据库写成功但消息发送失败”？
- 补偿操作失败或重复执行时，怎样保证业务状态正确？
- 消费者为什么仍然需要幂等？
分布式事务方案要和业务动作一起讨论。库存预占可以回滚，已发送的短信无法撤回，外部支付也未必支持参与本地事务。补偿并不等于恢复到技术上的旧值，它需要符合业务允许的后续状态。
稳定性、发布与扩缩容
微服务把一次请求分散到多个节点，局部故障发生的频率会随调用环节增加。超时限制等待时间，重试处理短暂错误，熔断阻止持续调用异常下游，限流和隔离保护有限资源；这些机制需要放在同一条调用链中设置。
相关内容：
常见面试题：
- 超时、重试、熔断、限流、降级和隔离分别解决什么问题？
- 超时时间怎样结合上游 Deadline 和下游延迟分布设置？
- 多层服务同时重试为什么可能产生重试风暴？
- Liveness、Readiness 和 Startup 探针分别应该检查什么？
- 服务怎样完成优雅停机，避免仍在处理的请求被直接中断？
- API 和消息格式怎样保持向后兼容？
- 灰度发布出现异常后，流量和数据怎样回滚？
- 扩容消费者或服务实例前，为什么要先检查分区、连接池和下游容量？
健康检查不能把所有依赖都塞进一个探针。数据库短暂变慢时，如果所有实例同时因为 Liveness 失败而重启，原来的依赖故障会进一步扩大。探针、流量摘除、连接排空和应用停机顺序需要一起设计。
可观测性与安全
单体应用中的一次请求通常只经过一个进程，微服务调用则可能跨越网关、多个业务服务、缓存、数据库和消息队列。日志、指标和链路追踪需要使用统一的请求标识关联，否则只能看到每个服务各自报错，无法还原完整过程。
相关内容：
常见面试题：
- 日志、指标和链路追踪分别适合定位什么问题？
- 微服务应该监控请求量、错误率、延迟、资源和业务中的哪些指标？
- TraceId 怎样跨 HTTP、RPC 和消息队列继续传递？
- 认证应该放在网关还是业务服务？
- 网关完成身份校验后，业务服务为什么仍然要做资源级授权？
- 服务之间怎样传递身份，并防止内部接口被绕过网关直接访问？
网关适合完成统一的 Token 校验和粗粒度访问控制，订单归属、租户范围和数据权限仍要由拥有业务数据的服务判断。只在前端隐藏按钮或只在网关校验角色，无法覆盖对象级越权和服务间直接调用。
微服务迁移与方案回答
单体迁移到微服务通常从变化频繁、容量压力明显或团队边界相对清晰的模块开始。迁移期间新旧系统会同时存在，数据同步、流量切换、接口兼容和回滚比“拆出多少个服务”更需要提前设计。
常见面试题：
- 怎样识别最适合优先拆出的业务模块？
- 新旧服务并存期间，流量和数据应该怎样迁移？
- 怎样避免一次性重写导致交付周期和风险失控？
- 设计一个微服务方案时，应该说明哪些内容？
回答一道完整的微服务设计题，可以按业务目标、服务边界、接口与消息、数据归属、一致性、稳定性、可观测性、安全、发布迁移的顺序展开。题目没有给出流量、团队规模和一致性要求时，应先向面试官确认这些约束，再决定是否拆分以及使用哪些组件。
按准备时间安排复习
| 剩余时间 | 建议安排 | 复习目标 |
|---|---|---|
| 1～2 天 | 先过一遍微服务常见面试题总结，优先补服务拆分、通信、数据一致性和容错 | 能讲清微服务的收益、代价和一条完整调用链 |
| 3～7 天 | 补 RPC、网关、配置中心、分布式事务、消息队列和超时熔断，并画出一次下单或支付请求经过的服务与数据变化 | 能回答失败路径、方案取舍和常见基础设施追问 |
| 1 周以上 | 结合项目整理一次服务拆分或架构设计，补充接口兼容、灰度发布、监控告警、容量和回滚方案 | 能从业务约束讲到服务、数据、交付和运维 |
写在最后
如果内容对你有帮助的话，欢迎顺手给 JavaGuide 点一个免费的 Star 支持一下：GitHub | Gitee。
JavaGuide 已持续维护近七年，累计 6100+ 次提交，来自 620+ 位贡献者共同完善。你的 Star、反馈和 PR，都是这个项目继续更新的动力。
如果你正在准备后端/AI 应用开发面试，也可以了解一下我的知识星球，里面包括后端和 AI 实战项目、简历优化、一对一提问和高频考点资料，已经持续维护六年。