微服务架构设计：服务拆分原则、数据一致性方案、分布式事务策略
📌 卡片一：服务拆分原则
面试问题：微服务拆分应遵循哪些核心原则？请结合一个真实业务场景说明。
🎯 面试官考察点：
- 是否理解领域驱动设计（DDD）与限界上下文
- 是否有过真实拆分经验，而非纸上谈兵
- 能否平衡拆分粒度与运维复杂度
📐 回答框架：
- 定边界：按 DDD 限界上下文划分，每个服务对应一个业务领域
- 定职责：单一职责原则，每个服务只负责一块完整业务能力
- 定数据：数据独立原则，每个服务拥有专属数据库
- 定团队：团队自治原则，一个服务由一个小团队全权负责
- 定演进：演进式拆分，先粗后细，避免过度设计
💬 简短示例回答：“以电商平台为例，按DDD限界上下文拆分为用户、商品、订单、支付、库存五个核心服务。每个服务拥有独立数据库，通过API通信。拆分粒度以‘一个小团队可独立维护’为标准，避免过度拆分导致运维成本激增。同时保留订单服务的核心聚合根，确保事务边界清晰。”
🔍 可能追问：
- 如果两个服务需要频繁交互（如订单和库存），是否应该合并？
- 拆分后出现“分布式耦合”如何发现和治理？
- 如何评估当前拆分粒度是否合理？
📌 卡片二：数据一致性方案
面试问题：微服务间如何保证数据一致性？请对比不同方案的适用场景与优缺点。
🎯 面试官考察点：
- 对 CAP 理论与 BASE 原则的深度理解
- 不同一致性级别的实际选型能力
- 对最终一致性落地方案的掌握程度
📐 回答框架：
- 明确需求：业务能否接受最终一致性？延迟窗口多长？
- 选型对比：TCC（强一致但侵入强）vs 消息表（最终一致高吞吐）vs SAGA（长事务编排）
- 落地关键：幂等设计、消息重试、补偿事务、对账机制
- 兜底策略：定时对账 + 人工介入 + 监控告警
💬 简短示例回答：“数据一致性方案需结合业务场景选择。对强一致性需求（如账户扣款）采用TCC模式，通过Try-Confirm-Cancel三阶段保证；对最终一致性容忍场景（如订单状态同步）采用消息队列+本地事务表，通过消息重试与幂等消费保障。核心原则：不追求全局强一致，而是结合业务选择恰当的一致性级别，并配套对账兜底。”
🔍 可能追问：
- TCC 的空回滚和悬挂问题如何解决？
- 消息队列方案中，如何保证消息不丢失、不重复？
- 如果最终一致性延迟过长，业务层面如何补偿？
📌 卡片三：分布式事务策略
面试问题：主流分布式事务方案（2PC、TCC、SAGA、消息表）的优缺点对比？你会如何选型？
🎯 面试官考察点：
- 是否深入理解每种方案的实现原理与代价
- 能否根据业务场景做出合理的技术决策
- 对分布式事务“四大难题”的认知（空回滚、悬挂、幂等、补偿）
📐 回答框架：
- 2PC：强一致，但同步阻塞，性能差，不适合高并发
- TCC：最终一致，业务侵入强，需处理空回滚与悬挂
- SAGA：长事务友好，补偿设计灵活，但事务隔离需额外保障
- 消息表：高吞吐，最终一致，需处理消息积压与重复消费
- 选型口诀：高并发选消息，强一致选TCC，长链路选SAGA，少用2PC
💬 简短示例回答：“2PC强一致但性能低，适合低频高价值交易；TCC通过业务补偿实现最终一致，但需业务方实现Try/Confirm/Cancel接口，侵入性强；SAGA将长事务拆为子事务+补偿，适合跨多服务编排；消息表基于本地事务+MQ，吞吐量高但存在消息延迟。选型核心：根据业务对一致性和性能的要求权衡，同时做好幂等与对账设计。”
🔍 可能追问：
- SAGA 的补偿事务如何保证幂等？反向补偿失败怎么办？
- TCC 中 Confirm 阶段失败，是重试还是回滚？
- 消息表方案如何解决消息重复消费导致的业务重复？
🏢 公司侧重点分析
| 公司 | 侧重点 | 常用技术栈 | 面试高频关注 |
|---|---|---|---|
| 阿里 | 分布式事务框架 SEATA，TCC + AT 模式 | SEATA、Dubbo、RocketMQ | TCC空回滚、AT模式全局锁 |
| 腾讯 | 最终一致性 + 消息队列，侧重支付场景 | TDMQ、CKafka、TDSQL | 消息可靠性、幂等设计、对账机制 |
| 字节 | 轻量级方案，避免强依赖分布式事务 | 自研MQ、Kitex、gRPC | 服务拆分粒度、最终一致性落地 |
| 美团 | SAGA 模式，餐饮订单长事务场景 | Leaf、SAGA、RabbitMQ | 补偿事务设计、事务隔离方案 |
👤 面试官画像说明
资深架构师 / 技术总监，8年以上经验，主导过大型分布式系统
由浅入深，先问原则再追细节，喜欢用“如果…怎么办”考察边界思考
实践经验 > 理论概念；异常处理 > 正常流程；选型依据 > 方案罗列
📁 项目案例：电商平台微服务拆分与数据一致性改造
| 项目名称 | 大型电商平台微服务化与数据一致性改造 |
| 业务背景 | 单体电商系统面临性能瓶颈，日均订单500万+，拆分后需解决跨服务数据一致性问题 |
| 规模指标 | 日订单800万，峰值QPS 1.2万，用户量1.2亿，核心服务12个 |
| 技术栈 | Spring Cloud 2020 + Dubbo + RocketMQ + SEATA + MySQL + Redis + XXL-Job |
| 核心难点 | ① 订单与库存一致性：防止超卖；② 分布式事务性能：TCC事务耗时优化；③ 补偿链路设计：失败后自动回滚与对账 |
| 面试高频追问 | 扣库存用TCC还是消息？如何保证库存不超卖？补偿事务失败后如何处理？ |
| 可迁移回答话术 | “在库存场景我们选择了TCC+本地缓存预扣的方案：Try阶段预扣库存并写流水，Confirm阶段正式扣减，Cancel阶段回滚。配合定时对账任务，发现不一致后自动触发补偿，将最终不一致率控制在0.001%以下。” |
🏛️ 大厂模拟面试
🎤 面试官提问：“假设你负责设计一个支付系统的微服务架构，交易链路涉及账户、订单、积分三个服务，你会如何保证数据一致性？请完整阐述你的方案设计思路。”
🧑💼 候选人回答（普通答案）
“可以用分布式事务，比如TCC或者2PC。账户扣钱、订单创建、积分增加这三个操作要么都成功要么都失败。我可能会用SEATA框架来实现TCC，保证数据一致性。”
面试官点评：❌ 只说了方案名称，没有选型理由，没有异常处理，没有细节。听起来像“背书”，缺乏实战深度。
🧑💼 候选人回答（优秀答案）
“我会选择TCC方案，因为支付场景对一致性要求高，但2PC性能太差。账户服务做Try扣钱，订单服务Try创建待支付订单，积分服务Try预增积分。Confirm阶段全部提交，任一失败则Cancel回滚。同时引入RocketMQ做异步对账，每天凌晨核对三方的数据，发现不一致自动补偿。”
面试官点评：✅ 有选型对比，有流程设计，有兜底机制。但未提及TCC的空回滚和悬挂问题，补偿细节不够深入。
🧑💼 候选人回答（专家答案）
“我会按业务特性分层决策：账户扣款采用TCC强一致，因为资金操作不可容忍最终一致；订单创建采用本地事务+异步消息，因为订单状态变更允许秒级延迟；积分增减采用消息队列最终一致性，因为积分场景对延迟最不敏感。三个服务间通过事务ID串联，统一由事务协调器管理。TCC层面，我在Try阶段写入事务流水并预扣资源，引入‘防悬挂表’防止空回滚，Confirm/Cancel通过重试+幂等表保证至少一次成功。此外，每15分钟运行对账Job，扫描状态异常的流水，自动触发补偿或告警人工介入。这套方案上线后，数据一致率达到99.999%，对账差异率低于0.001%。”
面试官点评：🏆 分层设计思路清晰，针对不同服务选择不同一致性级别；主动提出空回滚、悬挂、幂等等工程细节；有量化结果佐证。这才是架构师级别的回答。
🔁 面试官追问：
- 追问1：积分服务Try成功但Confirm超时，你怎么判断是成功还是失败？
- 追问2：