§ 00概述
前七章都在扩「容量」，本章开始扩「组织」。当多个团队在同一个代码库、同一个数据库上开发，互相的合并冲突、发布排队、故障连带，会让迭代速度随团队人数反比例下降。解法是按业务域拆分：把单体切成边界清晰的服务群，每个域独立开发、独立部署、独立持有自己的数据。
业务拆分的本质不是技术重构而是组织与责任的重新划分——技术只是把组织边界固化下来。本章数据集给出领域划分方法、数据归属原则、服务间通信与最终一致性的完整工具箱，以及「什么时候不该拆」的清醒剂。
§ 01演进定位
拆分的时机信号从来不是性能，而是组织摩擦：两个团队因为同一张表的结构变更反复扯皮、发布排队排到下周、一次故障波及全部业务线。命中两条以上，拆分的组织收益已经覆盖技术成本。
拆分遵循「先垂直后水平」：第一刀按业务域垂直切（用户域、商品域、交易域），每个域内部仍是清晰的单体；先拥有独立数据库与独立部署能力，再谈域内继续细分。一上来就拆成几十个微服务是本章最大的反模式。
数据归属是拆分真正的难点：每个服务独占自己的数据库，别人只能通过接口或订阅事件拿数据。这一原则执行得越彻底，后续微服务化（09 章）越顺；执行不彻底，拆了也是「分布式单体」。
§ 02技术架构
领域划分：以业务能力为界（参考领域驱动设计的限界上下文），而非以技术分层为界。一个快速的验证法：如果某个功能变更总是同时牵动两个团队，它们大概率属于同一个域；如果某两张表总是被一起修改，它们不该被拆开。
服务通信：域间同步调用走 RPC/HTTP（查询类），域间状态传播走事件（Kafka），这是解耦的关键——下游订阅事件构建自己的读模型，而不是反过来调上游接口拼数据。
最终一致：跨域写场景放弃分布式事务，改用本地消息表 + 事件 + 幂等消费 + 对账补偿。为每个跨域流程写清楚「中间态对用户是什么样子」（如「订单已提交，库存确认中」），一致性不是黑与白，是用户体验设计。
§ 03实施路径
第一阶段（1-2 周）领域地图：梳理业务能力清单与数据表归属矩阵，圈出「变更共振」的功能簇，产出拆分方案并评审——这一步值 50% 的工作量。
第二阶段（2-4 周）第一刀：选择耦合最弱、团队最痛的域先行（通常从「营销/内容」这类边缘域开始，绝不从交易域开始），代码与数据一起走：库表随服务迁移，禁止跨域直连数据库。
第三阶段（持续）逐域推进：每个域一个节奏（迁移-稳定-复盘），配合 07 章的数据管道把跨域读模型建起来。整个拆分是季度级工程，按域滚动而非大爆炸。
§ 04客户价值与适用判断
该拆：多团队并行冲突常态化、发布互相排队、故障域互相牵连。三个信号齐了，拆分就是生产力投资。
不该拆：团队 < 10 人、业务边界还在剧烈变化（产品方向未定）。此时拆分锁死的边界很快会过时，维护成本反噬收益。
成本提醒：拆分后基础设施与服务治理成本显著上升（监控、链路、测试、运维面翻倍），这也是为什么治理体系（09 章）与容器化（10 章）通常紧随其后。
§ D01组件与选型清单
DATA业务拆分与服务化 · 标准组件栈垂直拆分起步
| 层级 | 组件 | 选型建议 | 职责与要点 |
|---|
| 服务边界 | 业务域（限界上下文） | 3-5 个域起步 | 用户/商品/交易/营销/内容，按变更共振划界 |
| 服务持有数据 | 每域独立数据库 | 禁止跨域直连 | 数据归属是拆分成败的第一判据 |
| 同步通信 | RPC / REST | 查询类调用 | 超时、重试、熔断默认值全局统一 |
| 事件通道 | Kafka | 按域分 Topic | 状态变更事件化，下游自建读模型 |
| 最终一致 | 本地消息表 + 对账 | 幂等消费 | 每个跨域流程定义中间态的用户体验 |
| API 门面 | BFF / 聚合层 | 面向端聚合 | 前端一次请求拿齐，避免扇出放大 |
| 调用观测 | 调用链标记 | traceId 贯穿 | 为 09 章全链路追踪预埋规范 |
拆分顺序铁律：先拆边缘域（内容、营销、日志），最后拆交易域——交易域的正确拆法通常是 09 章微服务化。
§ D02成本测算数据集
DATA成本测算示例（三域拆分增量 · 月度）月度 · CNY
| 项目 | 规格 | 月成本 | 说明 |
|---|
| 新域实例 | 4C8G × 3（每域 1-2 节点） | ≈ ¥780 | 从共享集群独立出来 |
| 新域数据库 | 2C4G × 3 | ≈ ¥990 | 数据归属独立化的直接成本 |
| Kafka | 3 分区 → 6 分区 | ≈ ¥100 | 事件通道扩容 |
| BFF 聚合层 | 2C4G × 2 | ≈ ¥260 | 面向端的聚合门面 |
| 监控增强 | 按服务维度 | ≈ ¥50 | 服务级看板与告警 |
增量合计 ≈ ¥2,180/月 · 换取多团队发布互不排队
拆分的最大成本其实在人力：迁移期的双倍维护与回归测试。组织收益若不能覆盖，宁缓勿急。
§ D03关键指标基准
DATA可用性与体验基线SLO 参考
| 指标 | 单体基线 | 本阶段目标 | 行业良好 |
|---|
| 跨团队发布冲突 | 每周 2-3 次 | ≈ 0（域内自治） | 0 + 独立流水线 |
| 单域故障爆炸半径 | 全站 | 限制在单域 | 熔断隔离自动生效 |
| 域内数据库独立率 | 0% | 100% | 100% + 事件化读模型 |
| 跨域调用 P99 | — | < 300ms | < 100ms |
| 对账差异修复时长 | — | < 1 工作日 | 自动补偿 < 10 分钟 |
§ D04演进触发信号
DATA什么时候必须走向下一阶段任一命中即评估
| 触发信号 | 判定阈值 | 演进方向 |
|---|
| 服务数量治理失序 | 手工管理 > 10 个服务 | 微服务治理（09） |
| 部署脚本互异 | 每个服务一套部署法 | 容器化统一交付（10） |
| 链路排障靠猜 | 跨域问题定位 > 2 小时 | 链路追踪体系（09） |
| 配置散落 | 配置文件散在各服务器 | 配置中心（09） |
| 环境漂移 | 测试与生产行为不一致 | 容器化环境一致（10） |
§ D05上线检查清单
领域地图评审业务能力清单 + 数据归属矩阵 + 变更共振分析，三方评审签字
第一刀选边缘域迁移对象是耦合最弱、痛感最强的域，不是最核心的域
数据随服务走库表归属与代码同步迁移，跨域直连数据库从第一天就禁止
事件契约成文Topic、Schema、幂等语义、保留期写入文档并版本化
中间态体验设计每个跨域流程明确定义「确认中/部分成功」的用户呈现
对账任务上线跨域数据的对账与自动补偿先于切流部署
§ D06高频翻车点
按技术分层拆拆成「接口服务/逻辑服务/数据服务」，每次需求穿三层，等于没拆
分布式单体服务拆了、数据库共享、发布还要一起排——拆分的成本全付，收益全无
大爆炸迁移一次性切换全部业务域，故障时无从回退；必须按域滚动
事件无契约Topic 结构随意变更，下游消费批量崩溃，事件 Schema 必须版本化
忽略组织配套拆了服务没拆责任，出故障还在「拉群等定位」，边界形同虚设
§ D07常见问答
DATA业务拆分与服务化 · 问答数据集4 组
| 问题 | 答案 |
|---|
| 微服务和业务拆分什么关系？ | 业务拆分是「按域垂直切开」（本章），微服务是「域内服务治理的完备体系」（09 章）。顺序通常是先垂直拆出 3-5 个域，再在域内微服务化。 |
| 拆分后数据不一致怎么办？ | 接受最终一致并设计中间态：本地消息表保证事件不丢、幂等消费保证不重、对账补偿兜底。把「确认中」的体验设计好，用户对秒级延迟毫无感知。 |
| 从哪个域开始拆？ | 变更共振高 + 耦合度低 + 非交易链路的域。营销、内容、日志类是经典首选；交易域留到最后，且往往以 09 章的方式处理。 |
| 拆多少个域合适？ | 初期 3-5 个。域的数量应该约等于能独立负责它的团队数量——一个团队维护三个域会疲于奔命，三个团队共享一个域会打架。 |
§ D8角色分工数据集
DATA角色分工数据集本阶段人员配置
| 角色 | 核心职责 | 投入度 | 备注 |
|---|
| 架构师 | 领域地图 · 边界裁决 · 拆分方案 | 60% | 组织级决策参与者 |
| 各域负责人 | 域内交付 · 数据归属 · 契约维护 | 100% | 责任到域 |
| 平台组 | 事件通道 · 对账任务 · 调用规范 | 50% | 跨域基础设施 |
| PMO | 拆分节奏 · 回归协调 · 复盘 | 30% | 滚动式推进 |
§ D9风险登记册
DATA风险登记册概率 × 影响
| 风险 | 概率 | 影响 | 缓解措施 |
|---|
| 拆成分布式单体 | 中 | 致命 | 数据归属独立一票否决，跨域直连库即违规 |
| 事件契约被上游随意变更 | 中 | 严重 | Schema 版本化 + 兼容期 + 契约测试 |
| 最终一致的中间态伤害体验 | 中 | 中 | 中间态体验设计前置到方案评审 |
| 大爆炸式切换 | 中 | 致命 | 按域滚动，单域可独立回退 |
§ D10监控告警清单
DATA监控告警清单阈值即责任
| 监控对象 | 指标 | 告警阈值 | 响应动作 |
|---|
| 跨域调用 | P99 延迟 | > 500ms | 工单 · 慢调用链分析 |
| 事件通道 | 消费积压 | > 阈值 | 短信 · 消费扩容 |
| 数据一致性 | 对账差异 | > 0 | 电话 · 补偿任务 |
| 发布秩序 | 跨域发布冲突 | ≥ 2 次/月 | 复盘 · 边界再裁决 |
| 域内错误率 | > 1% | 短信 | 域负责人响应 |
§ D12实施时间线
DATA实施时间线域为节奏
| 阶段 | 里程碑 | 责任角色 | 出口物 |
|---|
| P1 | 领域地图与方案评审 | 架构师 + 各域 | 归属矩阵 + 拆分方案签认 |
| P2 | 首个边缘域迁移 | 该域团队 | 数据随服务走 · 独立部署生效 |
| P3 | 事件化读模型 | 平台组 | 跨域读不再扇出调用 |
| P4 | 逐域滚动 | 全员 | 每域一份迁移复盘 |
§ D13SLA 与容灾基线
DATASLA 与容灾基线对内承诺
| 指标 | 基线承诺 | 度量方式 | 未达标处置 |
|---|
| 域内可用性 | 99.9% | 域看板 | 域内冗余补齐 |
| 跨域调用成功率 | > 99.5% | 调用链统计 | 超时重试与熔断核查 |
| 事件送达 | 最终一致 < 5 分钟 | 事件延迟监控 | 消费能力扩容 |
| 域数据独立率 | 100% | 架构巡检 | 违规直连即整改 |
§ D14应急预案
DATA应急预案一页纸预案
| 故障场景 | 典型现象 | 处置步骤 | 升级路径 |
|---|
| 上游域故障传导 | 多域连环报错 | ① 熔断隔离 ② 下游降级读模型 ③ 根因域修复 | 全站传导 → 架构师介入 |
| 事件丢失 | 对账差异持续 | ① 重放 Topic ② 补偿任务 ③ 幂等复核 | 资损 → 业务 + 架构双升级 |
| 域数据库故障 | 单域不可用 | ① 域内主备切换 ② 上游熔断降级 ③ 数据核对 | 交易域 → 最高级响应 |
| 契约破坏上线 | 下游批量解析失败 | ① 回滚发布 ② 兼容层热修 ③ 契约测试补齐 | 跨域事故 → 双域负责人联席 |
§ D15首年成本明细
DATA首年成本明细CNY
| 项目 | 月成本 | 年成本 | 备注 |
|---|
| 新域实例 4C8G × 3 | ≈ ¥780 | ≈ ¥9,360 | 三域起步 |
| 新域数据库 2C4G × 3 | ≈ ¥990 | ≈ ¥11,880 | 数据归属独立 |
| Kafka 扩容 | ≈ ¥100 | ≈ ¥1,200 | 6 分区 |
| BFF 聚合层 × 2 | ≈ ¥260 | ≈ ¥3,120 | 面向端聚合 |
首年增量 ≈ ¥25,560。最大成本其实在人力：迁移期双倍维护——组织收益必须算得过来。
§ D16团队能力要求
DATA团队能力要求按需补齐
| 能力项 | 要求级别 | 如何补齐 |
|---|
| 领域驱动设计 | 必须 | 领域地图工作坊 + 外部评审 |
| 事件驱动架构 | 必须 | 契约测试入 CI |
| 最终一致设计 | 必须 | 对账补偿实战一次 |
| 跨团队协同 | 建议 | PMO 节奏机制 |
§ D17关键决策速查（ADR）
DATA关键决策速查（ADR）本阶段 4 个决策
| 决策 | 备选方案 | 结论理由 |
|---|
| 第一刀选域 | 核心交易域 vs 边缘域 | 边缘域先行：耦合弱痛感强 |
| 拆分粒度 | 微服务 vs 域内单体 | 域内单体：先垂直后水平 |
| 数据归属 | 共享库 vs 域独立库 | 独立库：一票否决项 |
| 跨域通信 | 直连 API vs 事件 | 查询 RPC + 状态事件双轨 |
§ D18高频面试题
DATA高频面试题本阶段 4 题
| 问题 | 考察点 | 优秀回答特征 |
|---|
| 怎么判断两个功能属于同一域？ | 领域建模 | 变更共振/数据共振的判据 |
| 拆分后数据不一致怎么办？ | 一致性设计 | 中间态体验 + 对账补偿双管 |
| 为什么不从交易域开始拆？ | 演进策略 | 风险排序：先边缘后核心 |
| 分布式单体怎么识别？ | 反模式意识 | 数据库共享/发布互锁两个信号 |
§ D19命令与操作速查
DATA命令与操作速查协同专项
| 场景 | 命令/操作 | 说明 |
|---|
| 事件积压 | Kafka lag 监控 | 消费能力预警 |
| 对账任务 | 定时任务 + 差异工单 | 挂起-补偿-复核 |
| 调用拓扑 | traceId 检索 | 跨域问题定位 |
| 契约验证 | 契约测试入 CI | 破坏性变更被拦截 |
§ D20采购与商务要点
DATA采购与商务要点本阶段采购项
| 采购项 | 询价要点 | 商务注意 |
|---|
| 新域资源 | 独立实例 vs 共享集群切分 | 共享组件避免重复采购 |
| Kafka 扩容 | 分区扩容对客户端影响 | 滚动扩容方案 |
| BFF 资源 | 按端独立还是合一 | 先合后拆，避免过早分化 |
§ D21阶段 KPI 卡
DATA阶段 KPI 卡验收口径
| KPI | 口径 | 目标 |
|---|
| 数据独立率 | 架构巡检 | 100% |
| 跨域调用 P99 | 链路统计 | < 300ms |
| 发布冲突 | 跨域冲突计数 | ≈ 0 |
| 对账闭环 | 差异处置时长 | < 1 工作日 |
§ D22交接清单
DATA交接清单换人不换知识
| 交接项 | 载体 | 验收 |
|---|
| 领域地图 | Wiki | 归属矩阵经三方评审 |
| 事件契约仓库 | Git | Schema 版本化 |
| 对账任务清单 | 调度系统 | 差异处置有 SLA |
| 拆分复盘记录 | 归档 | 每域一份 |
§ D23演进检查点评审
DATA演进检查点评审走向 09 章前
| 检查项 | 达标标准 | 结果 |
|---|
| 数据归属独立 | 跨域直连数据库清零 | 通过/不通过 |
| 事件契约版本化 | Schema 仓库 + 兼容测试 | 通过/不通过 |
| 对账补偿上线 | 差异自动挂起与处置 | 通过/不通过 |
| 首域稳定运行 | 首拆域稳定运行 ≥ 4 周 | 通过/不通过 |