3.8 从SOA到微服务
从单体内所有模块同批发布走到自治服务围绕能力独立演进，沿服务合同、自治数据、部署和观测边界诊断分布式成本。
学习目标
- 能沿识别能力、定义合同、划分数据、独立部署和端到端观测追踪一次服务拆分
- 能解释 SOA 与微服务的服务合同边界，以及自治数据、网络、观测和运维成本如何随拆分出现
- 能在正常、边界和故障场景中回答：按代码层拆服务导致同步调用链变长时，哪一个合同或观测证据应先拒绝
为什么需要这一机制
本页依据刘欣《码农翻身》（2018 年第 1 版）及出版社公开书目信息，独立重构 3.8 从SOA到微服务。正文、代码、图示、实验和练习都是本课程重新设计的教学材料，不复制原书正文、插图、练习答案或代码。
3.8 从SOA到微服务 不能停在“把程序拆成更多进程”。真实系统要解决的变化是从 单体内所有模块同批发布 到 自治服务围绕能力独立演进；可执行机制是：SOA 与微服务都以服务合同拆分能力，微服务强调独立部署和自治数据，因此必须承担网络、观测、一致性与运维成本。
三个会让服务拆分失真的陷阱
一个目录节点到服务化证据
3.8 从SOA到微服务
在 ↡把服务化故事转换为可验收的边界合同：识别能力、定义接口、划分数据、独立部署并观测完整请求。 中，服务化不是进程数量，而是能力、合同、数据和运维责任的组合。可用近似约束表达为
请求路径上的任一依赖都会影响整体体验；拆分只有在变更独立性和边界清晰度足以抵消网络、观测、一致性与运维成本时才有价值。
识别能力
↡从业务目标、变化原因和责任边界中找出应被独立演进的能力单元。先回答“谁为哪种结果负责”。不要从代码目录开始；先记录业务动作、输入输出、变更频率和数据所有权，再决定服务边界。
定义合同
↡用版本化请求、响应、错误、超时和兼容规则明确服务之间的调用约定。把服务间依赖变成可审计接口。合同不仅有字段，还要说明认证、幂等、超时、重试、错误语义和版本兼容。
划分数据
↡为业务数据指定唯一所有者和访问方式，明确跨服务读取、写入与一致性策略。让自治真正落到责任上。共享数据库表会把迁移、锁和回滚重新绑在一起；跨边界访问要通过合同，并承认最终一致或补偿的代价。
独立部署
↡服务在不要求整套系统同批发布的前提下构建、发布、回滚和改变自身实现的能力。必须有构建、配置、版本和回滚证据。若数据库迁移或共享配置仍要求所有服务同时升级，独立部署只是表面现象。
端到端观测
↡用请求 ID、依赖、时延、错误、重试和版本沿完整业务路径关联一次请求的观测方式。才能回答“用户请求为什么失败”。单个服务健康不能替代跨服务的链路、业务结果和首个失败证据。
最小可重放实现
trace = request(fixed_case, request_id="case-01")
assert trace.contracts_compatible
assert trace.data_owner_is_unique
assert inject_fault("one-boundary").first_deviation
assert reset_and_request(fixed_case) == trace这段实现草图只表达服务化验收合同，不复制原书叙事或代码。实际运行时应保存能力、接口版本、数据所有者、部署版本、请求 ID、每个节点状态、首个失败和复位结果，使另一位读者能够从干净状态重放。
五步复核一次服务拆分
1. 识别能力并固定请求基线
记录业务目标、输入输出、责任、变更原因和最小请求链。先预测正常请求会经过哪些能力与依赖，再运行一次保存请求 ID和版本。
Lab
服务合同与端到端观测实验
先预测请求会经过哪些能力与依赖，再切换合同边界和链路故障并保存首错。
能力边界清晰，合同兼容，数据各有所有者
trace=case-01 → contract=ok → owner=unique → deploy=independent → replay=match
判定
accept：拆分与端到端证据闭环
当前样本：独立演进；保存请求 ID、合同版本、数据所有者、部署版本、链路、首错和复位轨迹。
正常、边界与故障证据矩阵
| 样本 | 只改变的变量 | 预期判定 | 必存证据 |
|---|---|---|---|
| 正常 | 能力、合同、数据所有者和版本均匹配 | 请求完成，服务可独立演进 | 请求 ID、合同版本、数据所有者、部署版本 |
| 边界 | 字段、版本、超时或一致性策略改变 | 协商、降级或拒绝均可解释 | 兼容规则、超时、重试、补偿策略 |
| 故障 | 一个依赖超时、错误版本或不可用 | 定位首个失败并交付可诊断结果 | 链路、节点状态、首错、业务结果 |
故障诊断：先分开边界成本与观测盲区
- 能力侧：查业务目标、责任、变更原因和请求链；代码层数量不是能力边界证据。
- 合同侧：查版本、错误、超时、认证、幂等和重试；字段能解析不代表语义兼容。
- 数据侧：查所有者、读写路径、复制位点和补偿；共享表会把独立部署重新绑住。
- 运行侧：查构建、版本、配置、请求 ID、依赖时延、重试和首个失败；单服务绿色不能替代端到端结果。
如果一次请求跨越很多同步服务，先找按代码层拆出的边界，再看能力和数据所有权；如果发布要等待所有服务，查共享迁移和合同兼容；如果服务都健康而用户失败，沿请求 ID寻找首个依赖错误。每次只改变一个边界，并重放可信基线。
术语表
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 3.8 从SOA到微服务
用能力、合同、数据、部署和观测责任解释服务化边界的机制。
- 识别能力
从业务目标、变化原因和责任边界中找出可独立演进的能力单元。
- 定义合同
用版本化请求、响应、错误、超时、重试和兼容规则明确调用约定。
- 划分数据
为业务数据指定唯一所有者，明确跨服务访问与一致性策略。
- 独立部署
服务可以独立构建、发布、回滚和改变实现而不要求全系统同批发布。
- 端到端观测
用请求 ID、依赖、时延、错误、重试和版本关联完整业务路径的观测方式。
练习
练习
问题 1（3.8 从SOA到微服务）： 为什么把单体按代码层拆成多个服务，不一定得到更好的微服务边界？
问题 2（定义合同、划分数据）： 一个服务要独立发布，接口和数据合同至少要记录哪些内容？
问题 3（独立部署、端到端观测）： 每个服务探针都正常，但用户请求超时。请设计诊断顺序并说明要保存的证据。
本页小结
3.8 从SOA到微服务 的关键不是进程数量，而是能力边界、服务合同、数据所有权、独立部署与端到端观测是否同时成立。完成标准是用请求 ID 重放基线，定位按代码层拆分或共享数据造成的首个偏离，并证明故障结果和复位轨迹可解释。