QPS 一万是否需要微服务拆分

日期：2026-07-11
标签：#面试 #八股 #后端 #系统设计 #场景题

一句话答案

不能仅凭一万 QPS 决定拆微服务；应根据容量瓶颈、团队边界、发布耦合、故障隔离和业务复杂度判断，能通过单体水平扩展解决时优先保持简单。

面试口语版

我会先看一万 QPS 的请求结构、峰值、延迟目标、读写比和资源利用率。如果单体无状态、可以横向扩容，数据库和缓存也没有瓶颈，那么一万 QPS 本身不构成拆分理由。真正需要拆分的信号是不同模块扩缩容差异巨大、发布互相阻塞、故障域过大、数据和团队边界已经清晰。即使要拆，也会先模块化单体，再按业务域逐步抽离高收益模块，通过观测和压测验证，而不是一次性重写。

决策维度

性能：瓶颈是否在应用层？若在数据库，拆服务可能只会增加 RPC 开销。
组织：多个团队是否需要独立开发、发布和负责？
弹性：是否只有少数模块需要独立扩容？
可靠性：是否需要隔离故障、资源和发布风险？
成本：能否承担服务治理、链路追踪、配置、容错、数据一致性和运维复杂度？

面试官追问

如何确定服务拆分边界？
数据库怎么拆？
单体模块化和微服务有什么区别？
拆分后分布式事务怎么办？

面试官追问参考答案

1. 如何确定服务拆分边界？

以业务能力和数据所有权为主，结合领域模型、变更频率、团队责任、扩缩容和故障隔离。高内聚业务及其数据放在同一服务，跨服务只暴露稳定契约；优先抽离边界清晰、收益高的模块，并用调用关系验证是否产生大量同步耦合。

2. 数据库怎么拆？

最终目标是每个服务拥有自己的数据，其他服务通过 API 或事件访问。迁移可先拆表和访问层，再双写/CDC 同步、校验、切读、切写和下线旧表；跨库查询转为数据冗余或分析库，跨库事务采用 Saga、Outbox 等最终一致方案。

3. 单体模块化和微服务有什么区别？

模块化单体在一个进程部署，模块通过代码边界协作，调用简单且事务一致性容易；微服务独立进程和部署，能独立扩缩容与隔离故障，但引入网络、治理、观测和分布式数据一致性成本。模块化单体常是更稳妥的演进起点。

4. 拆分后分布式事务怎么办？

先减少跨服务强事务，把一致性边界放进单服务。剩余场景按业务选择 Saga/TCC，或使用本地事务加 Outbox 可靠发布事件，消费者幂等处理；通过状态机、补偿、对账和人工兜底实现最终一致，而不是默认追求全局两阶段提交。