微服务不是”拆越小越好”。本文整理拆分、通信与治理相关的面试要点，突出边界划分与运维复杂度之间的平衡。

要解决什么问题

团队常面临：如何拆服务、RPC 还是 MQ、数据如何归属、跨服务事务怎么办、如何灰度和观测。面试考察能否把架构决策与团队规模、发布频率、业务边界联系起来，而非背诵 Netflix 组件列表。

核心原理

拆分按 bounded context 和数据归属，每个服务拥有自己的数据库，通过 API 暴露能力。同步 RPC 适合查询链路和低延迟协作；异步 MQ 适合解耦、削峰和最终一致。可观测性靠日志、指标、链路追踪；容错靠超时、熔断、限流、舱壁和幂等。康威定律意味着组织架构会影响服务边界。

方案权衡

微服务换独立部署和弹性，换分布式测试、链路排障和基础设施成本。小团队慎拆；大团队需平台化网关、注册、CI/CD。Service Mesh 适合大规模多语言，小项目引入 Istio 可能 overkill。单体 modular monolith 有时是更优起点。

落地要点

拆分前事件风暴画上下文；禁止跨服务直连 DB；契约测试+Consumer Driven Contract；Canary 配合 golden metrics；定义 SLO 和 error budget。文档化服务依赖图和降级开关。面试准备 1 个”拆分过/合并过”的真实故事。

常见误区

误区：按技术层拆（所有 DAO 一个服务）；共享数据库耦合；无 traceId；链式同步调用导致延迟爆炸——“分布式单体”。忽视数据迁移和双写期一致性也是生产事故高发区。

小结

微服务面试的本质是边界设计能力：能否说明为什么拆、数据归谁、失败如何降级。准备时务必准备反例——何时合并服务、何时拒绝继续拆分。可观测性和发布策略与拆分决策同等重要，缺少 metrics/trace 的微服务会在第一个大促暴露问题。