《后端架构设计·演进与治理》前言

这本书假设你已经有什么

卷四不从头讲架构。它假设你已经读过前三卷，或者至少有等价经验：

• 知道质量属性、限界上下文、模块化单体和端口适配器，能说清一个订单系统为什么要这样切模块；
• 知道延迟、吞吐、缓存、限流、超时与重试的基本取舍，见过一次线上过载；
• 知道复制、共识、分片、一致性模型、Saga、outbox 和幂等对账的作用与边界。

如果你缺其中一块，不必停下来补完整卷。每章开头会用两三句话交代前提，并给出前三卷对应章节的链接。真正需要补齐的是卷三的交接篇 ，因为卷四的很多问题直接来自那张未证明项清单。

卷四也不假设你有平台团队、服务网格或云账单。书中所有治理动作都尽量落在“一个团队、一个订单系统、一套可运行检查”的范围内；需要更大规模环境时，正文会明确写“需真实环境”，而不是用虚构数字填充。

一卷四段的结构

13 章按四段组织，每段解决一类问题，段内章节可以按需跳读，段与段之间建议按顺序。

每章固定三节，三节之间是“判据 → 实现 → 边界”的关系，不是三个并列知识点。例如第 7 章：7.1 定义 SLI，7.2 把错误预算接进发布门禁，7.3 处理多服务依赖下的预算分配。只读 7.1 会知道怎么算，只读 7.2 会知道怎么卡发布，但只有三节一起读，才知道为什么“所有服务都达标”仍然可能是一次系统性故障。

arch-lab 在卷四的起点

arch-lab 是前三卷一直使用的 Go 订单系统。到卷三结束时，它大致长这样：

arch-lab/
  internal/order/            Order 聚合、状态机、领域事件
  internal/inventory/        InventoryReservation 聚合
  internal/payment/          Payment 聚合
  internal/ports/            仓储、支付、消息接口
  internal/adapters/memory/  L1/L2 默认适配器
  internal/platform/         前三卷加入的分布式能力
    clock/ replication/ consensus/ sharding/ tx/ outbox/ reconcile/ coord/ schedule/ dr/
  cmd/orderd/                订单服务入口
  cmd/loadgen/               压测与故障注入入口

卷四不改变领域层，也不重写前三卷的平台组件。它新增的是“运行与演进”能力：

领域层仍然不知道这些组件的存在。Order 聚合只感知“操作可能失败、可能重复、可能延迟生效”，以及“这次调用可能被网关、开关或租户策略改写”。这是卷四反复强调的边界：治理属于运行时，不应该渗进业务状态机。

L1–L4：每段代码到底跑在哪

本书沿用前三卷的可运行性分级。它不是一个装饰性标签，而是读者判断“这段结论能信到什么程度”的依据。

读到“L1”时，你可以相信代码逻辑和本机测试输出，但不能把它外推成生产性能；读到“L2”时，你可以相信进程内的完整链路，但不能相信网络、磁盘和真实并发；读到“L3/L4”时，本书只描述需要什么环境和怎么验收，不提供伪造的实测数字。

代码块的标记与抽取

所有 Go 代码块用三个注释标记组织，便于把文章里的代码抽出来独立编译：

// file: internal/platform/slo/budget.go
// tier: L1
// verify: go test ./internal/platform/slo/ -count=1
package slo

• file: 是抽取后的相对路径，必须在 arch-lab 目录白名单内；
• tier: 是 L1–L4 分级；
• verify: 是验证命令，通常就是该包的测试命令。

同一章的三篇共用一个 package，实现块与测试块都出现在正文里。这样做的代价是文章更长，好处是读者不必去别处找测试：每个断言的输入、输出和边界都在同一页上。

抽取脚本不随书发布，但规则很简单：按 // file: 把代码块写到对应路径，补一个 module archlab 和 go 1.26.0 的 go.mod，然后执行 gofmt -l . && go vet ./... && go test ./...。本书的每篇“本机实测”都是这样得到的。

三个固定场景

为了让 13 章不散成 13 个工具介绍，卷四用三个固定场景贯穿全卷。它们都发生在同一个订单系统上，只是关注点不同。

G1：把模块化单体拆成两个服务

起点是卷一收口的模块化单体：订单、库存、支付在同一个进程里，通过端口调用。目标是拆出独立的库存服务，同时保留回退到进程内调用的能力。

G1 会反复出现在：

• 第 1 章：拆分触发条件、依赖图、两服务演练；
• 第 2 章：订单与库存之间的契约、版本与消费者验证；
• 第 3 章：库存实例的注册、健康检查与负载均衡；
• 第 4 章：网关如何路由到两个服务，BFF 如何聚合；
• 第 13 章：完整的两服务端到端实验。

G1 的验收不是“拆成功了”，而是“拆完之后，订单创建的成功率、尾延迟和回滚时间仍在目标内；一旦超出，能在 5 分钟内退回单体路径”。

G2：一次带 SLO 门禁的发布

起点是 G1 拆出的两个服务。目标是让一次包含数据库字段变更的发布，在 SLO 约束下完成，并在指标恶化时自动回滚。

G2 会出现在：

• 第 5 章：配置与开关如何支持灰度；
• 第 6 章：需要哪些遥测信号来判断好坏；
• 第 7 章：SLI、错误预算与发布冻结；
• 第 8 章：发布前的混沌演练；
• 第 9 章：金丝雀、自动回滚与 expand-contract；
• 第 13 章：把门禁、演练和发布编排在一起。

G2 的验收是“发布过程可回滚、回滚有数据兼容保证、门禁的判定可复现”，不是“这次发布没出事”。

G3：把成本归因到团队与单位业务量

起点是 G1/G2 之后的运行账单（本书用模型数据，不伪造云账单）。目标是把每一笔资源成本归到服务、团队和单位订单，并让成本异常触发评审。

G3 会出现在：

• 第 10 章：多租户与隔离对成本的影响；
• 第 11 章：平台能力如何降低单位交付成本；
• 第 12 章：归因、容量模型、预算与责任；
• 第 13 章：路线图里如何平衡一致性与成本。

G3 的验收是“每一块钱都能找到归属，找不到归属的部分有明确上限和处置人”，不是“成本下降了 30%”。

三个场景共享同一套订单状态机和事件流，但各自只关注一组变量。这样安排是为了让读者看到：治理不是抽象原则，而是同一系统在不同约束下的连续决策。

章节的统一结构

每篇正文大致按下面的顺序展开，读多之后可以按需跳读：

1. 场景：一个具体的订单系统问题，通常带一次事故或一次决策；
2. 判据：两到四条可检查的条件，配对比表或决策矩阵；
3. 实现：一个标准库 Go 包，含实现与测试；
4. 实测：本机 go test 的命令、环境与原始输出；
5. 边界：这段实现不能证明什么，生产上还需要什么；
6. 常见错误：四到六条现场最容易犯的错；
7. 小结：把本节结论压缩成几句可执行的话。

这个结构对作者的限制大于对读者的限制：它强迫每一节都留下可验证的东西，避免写成“原则 + 案例”的散文。如果你发现某一节没有代码或没有判据表，那多半是我没写好，而不是治理不需要证据。

数字口径

治理领域的数字比性能和一致性数字更容易被滥用，因为它们经常缺少对照组。卷四统一用三种口径：

几条纪律：

• 本机 Go 测试的数字必须能由文章里的代码复现；不能复现的数字不写“实测”。
• SLO 达成率、发布成功率、成本节省比例，没有真实流量或账单时只写目标值与算式。
• 不把“行业常见值”写成“最佳实践”，更不写成“实测最优”。
• 没有接入真实服务网格、追踪后端或云平台时，正文写“需真实环境”，并给出验收口径。
• 第 13 章的综合实验是场景验收，不等于生产容量、生产故障率或真实组织效率。

测试环境与复现

本书的 Go 代码在以下环境运行并记录输出：

OS:     macOS darwin/arm64
Go:     go1.26.0
Module: archlab
测试:   go test ./... -count=1 -v

每个章节的原始测试输出保存在仓库的私有报告目录中，文章内只摘录与结论相关的行。读者复现时需要：

1. 按 // file: 标记抽取代码，保持目录结构；
2. 在模块根目录执行 go mod init archlab，写入 go 1.26.0；
3. 运行 gofmt -l .、go vet ./...、go test ./... -count=1。

Java 对照是另一套口径。本机默认 JDK 8，Docker 拉取 JDK 21 镜像在本轮验证中失败，因此附录 B 的 Java 代码全部标注“示例代码，未在本机运行”。它们只用于展示结构差异，不产生任何实测结论。

本书不覆盖的内容

为了不让篇幅失控，下面这些内容只在必要处点到，不展开：

• 云厂商产品的操作细节：Kubernetes、服务网格、配置中心、追踪后端的具体安装与调参，属于工具文档；本书只讨论它们在治理链中的位置和验收口径。
• 组织设计与绩效制度：团队拓扑、决策权在第 1、11 章会涉及，但本书不提供绩效考核、职级或汇报线方案。
• 安全合规的完整体系：第 10 章只覆盖多租户隔离、服务身份、密钥轮换与审计边界，不替代等保、SOC 2 或行业监管的专业评估。
• 财务与采购流程：第 12 章讨论成本归因与预算机制，但不涉及采购谈判、合同条款和税务处理。
• 生产级工具实现：书中的注册表、网关、金丝雀控制器都是教学实现，用于说明状态机与判据，不承诺性能、可用性和安全强度。

这些边界不是免责声明，而是阅读预期管理。治理领域很容易滑向“什么都重要”，本书选择把可验证的部分写深，把需要真实环境或专业职能的部分标清楚。

与站内专题的关系

卷四与站内的架构设计 、分布式系统 和 DevOps 专题是互补关系：

• 专题文章给概念地图、工具对比和历史脉络；
• 卷四给订单系统里的判据、状态机和可运行检查。

例如，平台工程 专题解释了平台团队的组织形态和能力清单，卷四第 11 章则把“平台即产品”落成能力目录、黄金路径状态机和采纳率计算；SLO 与错误预算 专题解释了指标体系和告警实践，卷四第 7 章则把错误预算接进发布门禁，并处理依赖级联。

如果你只想快速建立概念，可以先读专题；如果你要动手改造一个系统，卷四的顺序更合适。

阅读建议

• 第一次读：按 13 章顺序，至少完整跑通第 1 章的拆分演练、第 7 章的错误预算门禁和第 9 章的金丝雀状态机。
• 带着任务读：先看目录 里的症状表，跳到对应章节，再回到第 13 章看这些组件如何组合。
• 做评审：直接读每章的“常见错误与边界”和附录 C 的检查清单，把条目转成评审问题。
• 做平台：第 11、12 章可以独立读，但建议先读第 5–7 章，否则平台能力会缺少配置、观测和 SLO 的支撑。

卷四的每一章都可以单独使用，但四卷的价值在组合：卷一告诉你边界在哪，卷二告诉你代价多大，卷三告诉你保证有多强，卷四告诉你这些选择如何在组织里持续成立。缺少任何一卷，另外三卷的结论都会被高估。

最后提醒一句：本书的代码和测试是为了让结论可复现，不是为了提供一个可以直接上线的框架。把教学实现变成生产组件，还需要安全审计、性能压测、故障演练和长期维护；这些工作本身，就是卷四要讨论的治理内容。

读完之后，如果只能记住一句话，希望是这一句：治理不是给系统再加一层控制，而是让每一次变更都有依据、有边界、有退路。