题目重点：围绕 OCI IC4 系统设计追问，说明单体 profile、组件边界、独立扩缩容和数据库一致性迁移。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练场景是已有单体服务，尚未知道瓶颈属于 CPU、数据库、外部依赖还是发布耦合；不能默认拆微服务是第一步。
- 以不丢数据、可回滚、逐步迁移为约束；具体 QPS、租户数和数据模型须在面试中澄清。
解题路线
- 先用 tracing、profile、数据库慢查询、队列积压与错误率定位真实瓶颈，区别容量不足、热点和架构耦合。
- 低风险手段先尝试横向扩容无状态实例、缓存、数据库索引、异步化耗时任务、连接池和限流；记录成本与收益。
- 若模块资源曲线和发布节奏明显不同，再按业务能力抽出服务：先定义 API/事件契约和数据所有权，用旁路读、双写对账或事件同步渐进迁移。
- 数据拆分后避免跨服务共享表；跨服务事务用幂等命令、outbox、补偿和明确一致性目标。服务调用增多会增加网络延迟、故障域与运维复杂度。
- 用流量分级迁移、shadow 对比、回滚开关和 SLO 监控验证独立扩缩容是否真的降低瓶颈，而不是把单体问题搬到网络里。
手动走一遍
若单体 80% CPU 用于视频转码，而首页 API 只占 5%，可先把转码搬到异步 worker 并单独扩容；若数据库仍是瓶颈，拆服务不会自动解决，需处理查询/索引或读写负载。
规模与取舍
没有统一算法复杂度；容量模型应按各组件到达率 λ、平均服务时间 S、并发需求和依赖扇出估算。若每请求同步调用 M 个服务，尾延迟与失败概率会随链路增长。
易错点与追问
容易失分的边界
- 不测瓶颈就立刻拆成多个服务。
- 拆代码但继续共享同一数据库，无法获得真正独立部署和容量边界。
- 忽略网络调用、分布式事务与可观测性成本。
继续深挖
- 拆分期间新旧服务都写数据，如何发现和修复不一致？
- 一条用户请求必须调多个服务时，如何控制尾延迟与级联故障？
- 何时保持模块化单体反而更合适？
