微服务面试题

你读过各种模式的名称，能背出熔断器的作用，却依然说不清面试官到底在考察什么。本节按面试官通常考察的顺序，列出他们评分的四个领域。每一个问题看似在考词汇，实则在考判断力。

• 拆分方式。你从哪里切分，为什么这样切？面试官希望看到按业务能力或数据归属划定的边界，而不是按技术分层划分。
• 通信方式。同步的请求/响应还是异步事件，各自在什么情况下会出问题？他们想要的答案是权衡取舍，而不是个人偏好。
• 数据管理。每个服务一个数据库，意味着没有跨服务联表查询，也没有分布式事务。那要如何保证系统整体正确？
• 运维。部署、版本管理、链路追踪，以及凌晨三点某个服务变慢而非彻底宕机时该怎么办。

注意，这些都与具体框架无关。能讲清楚为什么把结账和库存拆开的候选人，永远比只会罗列注解的候选人得分更高。

以下是大多数微服务面试环节开场时会问的问题，附上面试官实际在考察什么。

• 你会如何把这个单体应用拆分成多个服务？考察你是按业务能力和数据归属拆分，还是按 controller、service、repository 这样的技术分层拆分。后一种答案会做出一个分布式单体。
• 两个服务之间如何通信？考察你能否说出每种选择的代价：同步调用给你一个简单的心智模型，但会耦合可用性；异步事件解耦了可用性，却带来最终一致性，需要向产品负责人解释清楚。
• 什么是分布式单体，如何避免？考察你是否明白，必须一起部署的服务其实并没有真正拆开。
• 一个服务应该多大？考察你是否会拒绝给出一个具体数字。规模应该跟随边界和负责的团队走。
• 需要 API 网关吗？它的作用是什么？考察你能否把路由、身份验证和限流从业务逻辑中分离出来。
• 服务之间如何互相发现？考察你对服务发现的基本了解，以及为什么硬编码主机地址在规模化环境中会失效。

在每个回答中都把权衡取舍说出口。面试官无法为你在脑子里默默做的比较打分。

面试的成败往往就在这里，因为这些问题没有干净利落的标准答案，候选人却总想搬出背好的说辞。

• 如何保证跨服务的数据一致性？先说明约束条件：没有跨服务事务。然后描述一个 Saga，可以是通过事件编排的协同式，也可以是由协调者统一调度的编排式，并明确说明系统是最终一致的，以及用户在这段间隙里会看到什么。
• 下游服务变慢时会发生什么？超时、带退避的重试，以及熔断器，防止一个变慢的依赖耗尽你的线程池。变慢比彻底宕机更糟，能说出这一点就说明你有生产环境经验。
• 如何让重试变得安全？幂等性。在写入路径上加一个幂等键，这样被重试的支付只会扣款一次。
• 多步骤流程中出现部分失败该怎么处理？用补偿操作，而不是回滚。解释清楚退款或释放预留资源具体是什么样子。
• 如何调试一个经过六个服务的请求？用分布式链路追踪，让关联 ID 在每一跳之间传递，再配合结构化日志和指标。

一位应聘某公有云厂商 L5 平台岗位的后端工程师被问到 Saga 问题，一口气用模式词汇答完，却完全没提到用户端会看到什么。追问「订单页面在不一致的这段时间里显示什么」，才是真正决定这一轮面试结果的问题。要准备的是第二个答案，而不只是第一个。

更多按岗位和主题整理的题库，见按岗位划分的面试题。

读完这份清单只会带来「眼熟」的感觉，而这种眼熟感，在陌生人真正问出这个问题并等你回答时，会立刻消失。知道一个模式和在轻微压力下把它讲清楚之间的落差，正是系统设计面试的全部难度所在，而这个落差只能靠开口说话来弥合。

挑一个你熟悉的流程，比如下单或注册，把完整的拆分过程大声讲出来：边界在哪、通信方式怎么选、一致性怎么讲、失败场景怎么处理。反复练习，直到你不再频繁重新开口。你可以在模拟面试模式中，对着会追问、并能让你用语音作答的 AI 面试官练习这些问题，这比重读笔记更接近真实场景。

SubcueAI 创始人 Aaron Cao 围绕这个落差而不是围绕内容分发来设计这个练习模式。题目清单到处都能免费找到，候选人真正缺的是在有人等待时反复把答案说出口的练习。在真实面试中，桌面应用和浏览器扩展的侧边栏可以在面试官说话时同步给出结构化提示，但一段练熟的讲解永远胜过第一次临场阅读的内容。助手能做什么、不能做什么，详见产品概览页面。