第1章 逃离单体地狱

本课程对应Chris Richardson著、喻勇译《微服务架构设计模式》，机械工业出版社2019年出版，ISBN 9787111624127，馆藏著录为前置26页、正文455页。英文原版为Manning 2018年10月初版，ISBN 9781617294549、520页。课程固定该初版的13章与44个模式，不混入当前第二版MEAP重新编排和新增的章节。

全书权威分母为13章、52个二级节、177个三级节，共242个编号目录节点；另设学习地图和总复习，共15页、45个交互视图和90道独立复习题。本章覆盖7个二级节与16个三级节，连同章标题共24个编号节点。

从一个可证伪的问题开始

先预测：把单体按技术层机械切成大量网络服务，会同时保留业务耦合并增加远程调用、部署和运维成本，最终得到分布式单体。把预测写成可观察反例，再决定是否采用模式。模式不是技术标签，而是在特定约束中解决反复出现问题的决策；结果部分既包含收益，也包含采用后必须处理的新问题。

FTGO是全书贯穿案例。读者要沿同一订单标识追踪消费者、餐厅、厨房、配送、信用和通知状态，明确哪个服务拥有哪份事实、谁可修改、消息何时可重放、查询允许多旧、测试在哪层证明、发布如何停止和回退。验收不变量是：采用微服务必须改善大型复杂应用的持续交付能力；服务数量增加本身不是成功，独立开发、测试、部署与数据所有权才是验收事实。

核心词汇与初版边界

单体架构、微服务架构、扩展立方体、模式语言、DevOps

以上词汇都要回答六个问题：解决什么问题、受什么约束、状态由谁持有、失败如何传播、怎样恢复、用什么证据证明。2018/2019初版之后出现的第二版结构、云产品行为和模式补充只能作为迁移差异，不能改写本页正式目录。

原书目录逐节点重构

1.1 迈向单体地狱的漫长旅程

正式节点 1/7。 先承认单体在早期开发、测试、部署和横向扩展上的简单性，再用代码规模、团队冲突、长反馈环与技术栈锁定解释它何时越过适用边界。

本节的三级目录如下，均在本页展开而不合并成泛化主题：

• 1.1.1 FTGO应用程序的架构
• 1.1.2 单体架构的好处
• 1.1.3 什么是单体地狱

把“1.1 迈向单体地狱的漫长旅程”放回“从FTGO单体的交付困境出发，推导微服务架构的结构、收益、代价、模式语言以及组织前提”这条责任链：输入来自“本章输入与版本契约”，输出进入“1.2 为什么本书与你有关”。先写主体、拥有的数据、命令或查询、同步与异步边界、可见完成点，再画正常、超时、重复、乱序、部分失败和恢复轨迹。不能用框架名称替代协议语义，也不能用组件健康替代“采用微服务必须改善大型复杂应用的持续交付能力；服务数量增加本身不是成功，独立开发、测试、部署与数据所有权才是验收事实”。

实验固定FTGO业务样本、初版代码语义、数据、负载和观测窗口，只改变一个架构变量或故障。比较状态转移、P50/P95/P99、错误、队列滞后、重试放大、恢复时间和最终业务集合；若只有HTTP成功、消息已确认、Pod就绪或函数返回，而没有持久状态与业务对账，本节仍未通过。

1.2 为什么本书与你有关

正式节点 2/7。 把读者角色落到企业开发者与架构师：问题不是追逐潮流，而是大型复杂应用的交付速度、可靠性和组织自治。

本节的三级目录如下，均在本页展开而不合并成泛化主题：

• 本节没有三级编号，正文整体构成正式范围。

把“1.2 为什么本书与你有关”放回“从FTGO单体的交付困境出发，推导微服务架构的结构、收益、代价、模式语言以及组织前提”这条责任链：输入来自“1.1 迈向单体地狱的漫长旅程”，输出进入“1.3 你会在本书中学到什么”。先写主体、拥有的数据、命令或查询、同步与异步边界、可见完成点，再画正常、超时、重复、乱序、部分失败和恢复轨迹。不能用框架名称替代协议语义，也不能用组件健康替代“采用微服务必须改善大型复杂应用的持续交付能力；服务数量增加本身不是成功，独立开发、测试、部署与数据所有权才是验收事实”。

实验固定FTGO业务样本、初版代码语义、数据、负载和观测窗口，只改变一个架构变量或故障。比较状态转移、P50/P95/P99、错误、队列滞后、重试放大、恢复时间和最终业务集合；若只有HTTP成功、消息已确认、Pod就绪或函数返回，而没有持久状态与业务对账，本节仍未通过。

1.3 你会在本书中学到什么

正式节点 3/7。 把后续章节看成相互依赖的模式语言：拆分带来通信、数据一致性、查询、测试、部署和可观测性问题，后继模式逐一承担代价。

本节的三级目录如下，均在本页展开而不合并成泛化主题：

• 本节没有三级编号，正文整体构成正式范围。

把“1.3 你会在本书中学到什么”放回“从FTGO单体的交付困境出发，推导微服务架构的结构、收益、代价、模式语言以及组织前提”这条责任链：输入来自“1.2 为什么本书与你有关”，输出进入“1.4 拯救之道：微服务架构”。先写主体、拥有的数据、命令或查询、同步与异步边界、可见完成点，再画正常、超时、重复、乱序、部分失败和恢复轨迹。不能用框架名称替代协议语义，也不能用组件健康替代“采用微服务必须改善大型复杂应用的持续交付能力；服务数量增加本身不是成功，独立开发、测试、部署与数据所有权才是验收事实”。

实验固定FTGO业务样本、初版代码语义、数据、负载和观测窗口，只改变一个架构变量或故障。比较状态转移、P50/P95/P99、错误、队列滞后、重试放大、恢复时间和最终业务集合；若只有HTTP成功、消息已确认、Pod就绪或函数返回，而没有持久状态与业务对账，本节仍未通过。

1.4 拯救之道：微服务架构

正式节点 4/7。 沿X轴复制、Y轴功能拆分和Z轴数据分区定位服务边界；服务通过API封装业务能力并拥有数据，不能让其他服务越过API直接读表。

本节的三级目录如下，均在本页展开而不合并成泛化主题：

• 1.4.1 扩展立方体和服务
• 1.4.2 微服务架构作为模块化的一种形式
• 1.4.3 每个服务都拥有自己的数据库
• 1.4.4 FTGO的微服务架构
• 1.4.5 微服务架构与SOA的异同

把“1.4 拯救之道：微服务架构”放回“从FTGO单体的交付困境出发，推导微服务架构的结构、收益、代价、模式语言以及组织前提”这条责任链：输入来自“1.3 你会在本书中学到什么”，输出进入“1.5 微服务架构的好处和弊端”。先写主体、拥有的数据、命令或查询、同步与异步边界、可见完成点，再画正常、超时、重复、乱序、部分失败和恢复轨迹。不能用框架名称替代协议语义，也不能用组件健康替代“采用微服务必须改善大型复杂应用的持续交付能力；服务数量增加本身不是成功，独立开发、测试、部署与数据所有权才是验收事实”。

实验固定FTGO业务样本、初版代码语义、数据、负载和观测窗口，只改变一个架构变量或故障。比较状态转移、P50/P95/P99、错误、队列滞后、重试放大、恢复时间和最终业务集合；若只有HTTP成功、消息已确认、Pod就绪或函数返回，而没有持久状态与业务对账，本节仍未通过。

1.5 微服务架构的好处和弊端

正式节点 5/7。 收益来自小而松耦合的可独立部署单元，代价来自分布式系统、跨服务事务、测试和运维复杂性；两边必须在同一决策表中量化。

本节的三级目录如下，均在本页展开而不合并成泛化主题：

• 1.5.1 微服务架构的好处
• 1.5.2 微服务架构的弊端

把“1.5 微服务架构的好处和弊端”放回“从FTGO单体的交付困境出发，推导微服务架构的结构、收益、代价、模式语言以及组织前提”这条责任链：输入来自“1.4 拯救之道：微服务架构”，输出进入“1.6 微服务架构的模式语言”。先写主体、拥有的数据、命令或查询、同步与异步边界、可见完成点，再画正常、超时、重复、乱序、部分失败和恢复轨迹。不能用框架名称替代协议语义，也不能用组件健康替代“采用微服务必须改善大型复杂应用的持续交付能力；服务数量增加本身不是成功，独立开发、测试、部署与数据所有权才是验收事实”。

实验固定FTGO业务样本、初版代码语义、数据、负载和观测窗口，只改变一个架构变量或故障。比较状态转移、P50/P95/P99、错误、队列滞后、重试放大、恢复时间和最终业务集合；若只有HTTP成功、消息已确认、Pod就绪或函数返回，而没有持久状态与业务对账，本节仍未通过。

1.6 微服务架构的模式语言

正式节点 6/7。 模式用问题、约束、解决方案、结果和相关模式表达经验；采用一个模式会产生新问题，因此不能把44个模式当作互不相关的清单。

本节的三级目录如下，均在本页展开而不合并成泛化主题：

• 1.6.1 微服务架构不是银弹
• 1.6.2 模式和模式语言
• 1.6.3 微服务架构模式语言概述

把“1.6 微服务架构的模式语言”放回“从FTGO单体的交付困境出发，推导微服务架构的结构、收益、代价、模式语言以及组织前提”这条责任链：输入来自“1.5 微服务架构的好处和弊端”，输出进入“1.7 微服务之上：流程和组织”。先写主体、拥有的数据、命令或查询、同步与异步边界、可见完成点，再画正常、超时、重复、乱序、部分失败和恢复轨迹。不能用框架名称替代协议语义，也不能用组件健康替代“采用微服务必须改善大型复杂应用的持续交付能力；服务数量增加本身不是成功，独立开发、测试、部署与数据所有权才是验收事实”。

实验固定FTGO业务样本、初版代码语义、数据、负载和观测窗口，只改变一个架构变量或故障。比较状态转移、P50/P95/P99、错误、队列滞后、重试放大、恢复时间和最终业务集合；若只有HTTP成功、消息已确认、Pod就绪或函数返回，而没有持久状态与业务对账，本节仍未通过。

1.7 微服务之上：流程和组织

正式节点 7/7。 自治跨职能团队、持续交付和心理安全是架构可运行的前提；Conway定律说明服务边界与沟通结构会相互塑造。

本节的三级目录如下，均在本页展开而不合并成泛化主题：

• 1.7.1 软件开发和交付组织
• 1.7.2 软件开发和交付流程
• 1.7.3 采用微服务的人性因素

把“1.7 微服务之上：流程和组织”放回“从FTGO单体的交付困境出发，推导微服务架构的结构、收益、代价、模式语言以及组织前提”这条责任链：输入来自“1.6 微服务架构的模式语言”，输出进入“本章证据门与跨章连接”。先写主体、拥有的数据、命令或查询、同步与异步边界、可见完成点，再画正常、超时、重复、乱序、部分失败和恢复轨迹。不能用框架名称替代协议语义，也不能用组件健康替代“采用微服务必须改善大型复杂应用的持续交付能力；服务数量增加本身不是成功，独立开发、测试、部署与数据所有权才是验收事实”。

实验固定FTGO业务样本、初版代码语义、数据、负载和观测窗口，只改变一个架构变量或故障。比较状态转移、P50/P95/P99、错误、队列滞后、重试放大、恢复时间和最终业务集合；若只有HTTP成功、消息已确认、Pod就绪或函数返回，而没有持久状态与业务对账，本节仍未通过。

模式决策矩阵

选择模式时先写“未采用会怎样”，再写采用后的新成本。例如同步RPC需要超时、断路器和发现；异步消息需要事务性发件箱、顺序、去重和死信；Saga需要补偿和隔离对策；CQRS需要视图水位与重建。相关模式组成因果链，不能独立打勾。

机制、状态与不变量

责任与数据所有权

服务只能通过API或消息公开能力，数据表、聚合事件流和查询视图都有唯一写入责任。一个业务命令可跨越多个服务，但每一步本地事务、发出的消息、预期回复、补偿和终态都必须可追踪。共享数据库、跨库联表和绕过API的“临时读取”会让边界失真，必须记录退出日期和删除证据。

完成点与失败语义

客户端收到响应、网关完成组合、消息代理确认、消费者写库、Saga进入终态、CQRS视图追上水位、Pod通过就绪和业务对账完成是不同检查点。超时表示结果未知，不等于失败；至少一次消息表示可能重复，不等于恰好一次业务副作用。恢复从持久事实继续，而不是从易失内存猜测。

可用性与放大效应

串行依赖近似满足 $A_{path}=\prod_i A_i$。每次失败都重试 $r$ 次时，最坏尝试量接近 $N(1+r)$；多层重试会相乘而非相加。该估算只用于发现方向性风险，生产结论还必须固定业务、数据、负载、版本和观测窗口，测量P50/P95/P99、错误、饱和度、队列滞后、恢复时间和最终业务集合。

可复现实现与证据格式

decision:
  book: microservices-patterns-first-edition
  unit: msp-01-escaping-monolithic-hell
  problem: "从FTGO单体的交付困境出发，推导微服务架构的结构、收益、代价、模式语言以及组织前提"
  invariant: business-state-reconciled
  observe: [contract-version, state, trace, latency-p99, queue-lag, business]
  stop: [error-budget-exhausted, invariant-broken]
  rollback: verified-baseline

// 业务状态与待发消息在同一个本地事务中提交；发布器可重试，消费者按消息ID幂等。
@Transactional
Result handle(Command command) {
  Aggregate aggregate = repository.load(command.aggregateId());
  Events events = aggregate.decide(command);
  repository.save(aggregate, events.expectedVersion());
  outbox.append(events.withCorrelation(command.correlationId()));
  return Result.accepted(aggregate.id(), aggregate.version());
}

experiment = fixed(ftgo-case, data, load, version, observation-window)
           + change(one boundary | failure | retry | ordering variable)
           + observe(api + message + state + telemetry + business result)
           + reconcile(expected invariant, durable terminal state)

独立交接与跨章连接

交接包至少包含FTGO现状图、扩展立方体、收益代价账本、组织与交付能力表、初版目录映射、服务和数据所有权、API/事件模式、关联标识、失败状态机、测试层级、遥测查询、业务对账、停止与回退。另一位维护者必须能在无口头补充的情况下重放一个成功案例、一个超时未知案例、一个重复案例和一个恢复案例。

本页输出不是终点。它会成为后继模式的输入：边界产生通信，通信产生一致性与查询问题，分布式行为产生测试与可观测需求，运行单元产生部署问题，已有单体产生迁移问题。若后继问题没有负责人和证据门，当前选择尚未完成。

本章回顾

重新完成“从FTGO单体的交付困境出发，推导微服务架构的结构、收益、代价、模式语言以及组织前提”：从初版目录和FTGO问题开始，明确主体、数据与契约，推导模式并记录收益和代价；再通过正常、超时、重复、乱序、部分失败和恢复实验，验证“采用微服务必须改善大型复杂应用的持续交付能力；服务数量增加本身不是成功，独立开发、测试、部署与数据所有权才是验收事实”。只有目录节点、机制轨迹和最终业务状态均可独立复现，本页才算完成。

复习与运行验收

← 上一页：2019中文版初版权威学习地图 · 下一页：第2章 服务的拆分策略 →