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

三个熟悉的场景

先说三个场景。它们由多个团队里的常见问题拼合而成，不对应任何一家公司，也不指向任何具体个人。三个场景分别发生在拆分、值守和平台建设三个时刻，表面上属于不同职能，根因却是同一个：系统已经进入持续演进，组织仍在用一次性交付的方式做决定。

场景一：拆完服务，发布开始互相拖累

订单系统原本是一个模块化单体。一次组织调整后，订单、库存、支付被拆成三个服务，各自有仓库、流水线和值班表。拆分的第一周，团队感受到的是“自治”：订单服务可以独立发布，不用再等库存团队。

第三周问题出现。订单服务给 InventoryReservation 加了一个必填字段，自己的测试全过，灰度也正常；库存服务的反序列化直接失败，预占接口 100% 报错。订单侧看到的是库存超时，触发重试；重试把库存的错误率进一步放大；网关的连接池被占满，连不相关的商品查询也开始超时。

复盘时三个团队各自都有道理：订单说“字段是新增的，按兼容原则应该能忽略”；库存说“契约文档没有更新，我不知道有这个字段”；平台说“网关限流是按服务配的，没料到重试会打满”。没有人能回答一个更基本的问题：谁有权判断一次契约变更是否兼容，依据是什么，什么时候执行？

这个场景的关键不是“某个人忘了通知”，而是拆分把一次编译期检查变成了跨团队的运行时协商。没有契约门禁，兼容性就只是一句口头约定；没有统一的超时与重试预算，一个服务的错误会沿着调用链变成全站故障。

场景二：SLO 全绿，用户仍在投诉

第二个场景发生在一个已经做了可观测性建设的团队。订单创建有 SLO：99.9% 的请求在 300 毫秒内成功。仪表盘连续一个月是绿色，错误预算还剩很多。但客服工单里，“下单按钮转圈”“支付后订单没出现”的投诉一直在涨。

团队先怀疑 SLO 定得太松，把阈值收紧到 200 毫秒，绿色依旧。后来把链路拆开看，才发现三件事：第一，SLO 只统计了订单服务自己的 HTTP 状态码，库存和支付的下游错误被订单服务“降级成功”吞掉了；第二，指标按分钟聚合，持续 20 秒的尖峰在平均值里看不见；第三，移动端 BFF 的重试让用户实际等待超过 2 秒，而 SLO 只算第一次请求。

这不是监控工具的问题，而是 SLI 的定义问题。“服务返回 200”与“用户成功下单”之间隔着降级、重试、异步确认和端到端时延。 SLO 如果只从服务内部视角定义，就会系统性地高估健康度；错误预算如果只用来展示，就不会触发任何决策，团队也就没有动力去修那些“指标上看不见”的问题。

场景三：平台建好了，工单没有减少

第三个场景发生在一个平台团队。他们花了一个季度做内部开发者平台：服务模板、流水线、配置中心、日志查询、告警接入，能力清单很长。上线时做了培训，文档写了 60 页。

半年后统计：新服务里只有 30% 用了平台模板，其余仍然复制旧仓库；配置中心的使用率不到一半，很多团队还在用环境变量；平台工单量没有下降，反而多了“平台怎么用”的咨询。平台团队很委屈：能力都做了，为什么没人用？

把用户旅程画出来才看清：创建一个服务要走 7 个页面，其中 3 个需要等审批；模板生成的代码跑不起来，因为默认依赖版本过期；日志查询要求填一套平台自定义的标签，而团队已有的日志格式不兼容。平台提供的是“能力集合”，用户需要的是“从想法到上线的一条路径”。

这个场景的关键不是“平台做得不好”，而是平台被当成了项目，而不是产品。平台的价值不由能力数量决定，而由采纳率、交付周期和反悔成本决定。 没有用户旅程、没有黄金路径、没有采纳度量，平台就会变成另一套需要维护的遗留系统。

三个场景的对照

把三个场景放在一张表里，会发现它们的“技术症状”完全不同，但失效位置高度相似。

这张表后来会反复出现。第 2 章处理第一行，第 7 章处理第二行，第 11 章处理第三行。它们不是三个独立问题，而是同一条治理链上的三个断点：变更前没有判定，运行时没有正确观测，能力交付后没有采纳反馈。

这三个场景的共同点

三个场景的职能不同、触发条件不同，但都可以归结为同一句话：机制已经正确，组织还没有能力让它持续正确。

卷三结束时，arch-lab 已经能证明：跨库下单在重复、超时和崩溃下会收敛；分片迁移有回退条件；对账能把差异修到零。但这些证明都发生在确定性环境里，而且只覆盖“系统怎么工作”，不覆盖“人怎么改它”。一旦系统进入持续演进，新的变量出现了：

• 边界会变：今天的模块边界，可能明天就因为团队调整或流量结构变化而失效；
• 契约会变：字段、语义、错误码、超时都在变，兼容性不能靠记忆；
• 流量会变：大促、直播、爬虫和重试会把平均值变成尖峰；
• 组织会变：值班表、审批权、预算归属都会影响系统的实际行为。

卷四要处理的正是这些变量。它不再问“这个机制对不对”，而是问“这个机制在真实组织里能不能被持续执行”。这两个问题都重要，但后者更容易被忽略，因为它不产生漂亮的架构图，只产生发布记录、告警、工单和账单。

四个反复出现的失效点

把过去几年常见的治理事故按“失效发生在哪一步”归类，会得到四个反复出现的失效点。它们不是四个部门的问题，而是同一条决策链上的四个断点。

失效点一：变更前没有兼容性判定

拆分之后，一次字段改名、一次错误码调整、一次超时缩短，都可能跨团队生效。大多数团队依赖文档、群通知和“应该不会有人用”的假设；真正能拦住破坏性变更的，只有自动化的兼容性检查和消费者验证。

这个断点的典型特征是：变更方测试全过，受影响方在灰度或全量后才报错。事后追责没有意义，因为没有任何一方拥有完整的判定依据。

失效点二：运行时没有端到端视角

服务内部的成功率、延迟和错误码，只能证明“服务自己认为正常”。用户是否成功下单，取决于网关、BFF、重试、异步确认和下游降级的组合。缺少端到端 SLI，团队会持续优化局部指标，而用户体感不变。

这个断点还会制造一种危险的错觉：仪表盘越做越漂亮，故障发现却越来越晚。因为看板展示的是“我们采集了什么”，不是“用户经历了什么”。

失效点三：变更没有可回滚的边界

发布、配置、开关、数据库迁移，本质上都是变更。很多团队为代码准备了回滚，却没有为配置、开关和数据迁移准备回滚；一旦新版本写入了旧版本读不懂的数据，回滚代码也无法恢复服务。

这个断点的核心不是“回滚脚本写得好不好”，而是变更顺序：先扩展、再迁移、后收缩。第 9 章会把这条顺序拆成可检查的阶段。

失效点四：能力交付后没有采纳反馈

平台、工具、规范都属于“能力”。能力交付不等于被使用；没有被使用，就没有降低组织的交付成本，反而增加了维护面。缺少采纳率、用户旅程和反悔成本，平台团队只能靠“又做了一套”来回应抱怨。

这个断点最难修，因为它需要平台团队承认自己是产品团队，而不是项目团队。第 11 章会给出能力目录、黄金路径和采纳度量的最小实现。

四个失效点对应四类证据：契约检查、端到端指标、变更阶段、采纳数据。卷四的每一章，最终都要落到其中一类证据上。

卷三留下的交接表

卷三第 13.3 节把未证明项拆成四类：共识性能、跨单元冲突、演练覆盖和组织成本。前两类需要真实磁盘、网络和流量，后两类需要真实的排班、审批和预算。卷四不假装能替读者完成这些测量，而是给出测量的口径和治理动作：

这张表说明卷四与卷三的关系：卷三给机制，卷四给机制运行的约束。没有卷三，卷四的治理会变成流程空转；没有卷四，卷三的机制会在第一次组织调整后失效。

如果你还没有读卷三，建议至少先读卷三的交接篇 ，理解那四类未证明项的来源。卷四的很多章节会直接引用那张表，而不是重新解释背景。

这本书的四个立场

第一，治理是可测量的工程，不是流程名词的堆叠。 拆分、SLO、混沌、平台、成本，每一章都要落到一个可运行组件、一张带阈值的表或一次可复现的检查。写不出指标和退出条件的治理动作，不进入本书。

第二，先证明收益，再承担分布式成本。 拆分、网关、服务网格、平台都不是默认正确。每一次“加一层”都要回答：它解决了什么具体问题，带来了什么新的失败模式，什么时候应该撤掉。本书反复使用“触发条件 + 退出条件”的结构，就是为了防止架构只进不退。

第三，默认系统会变更，而且变更会出错。 配置会推错，开关会过期，契约会破坏，发布回滚会失败，演练会伤到生产。治理的目标不是消除变更，而是让变更的影响可限定、可观察、可回滚。第 5、8、9 章都在处理这个前提。

第四，组织是系统的一部分。 值班表、审批权、预算归属、平台采纳率不是“软话题”，它们直接决定故障恢复时间和架构演进速度。第 10–12 章把租户、平台和成本放进技术书，不是为了凑管理内容，而是因为这三件事会反向塑造技术选择。

技术栈与口径

本书沿用前三卷的 arch-lab 订单系统：Order、InventoryReservation、Payment 三个聚合，状态机 CREATED → INVENTORY_RESERVED → PAID → FULFILLED，分支 CANCELLED／REFUNDED。

• Go 1.26.0 是主线。所有 Go 代码只在标准库范围内实现，抽取后可在本机独立编译测试。测试环境为 macOS darwin/arm64。
• Java 21 只做结构对照。本机默认 JDK 8，Docker 拉取 eclipse-temurin:21-jdk 在本轮验证中失败，因此附录 B 的 Java 代码统一标注“示例代码，未在本机运行”。凡是没有实际运行的 Java 结论，不写成实测。
• L1–L4 分级沿用前三卷。L1 是纯逻辑单包，L2 是进程内端到端，L3 需要真实依赖，L4 需要多环境与故障注入。卷四以 L1 为主，L2 只出现在拆分、BFF、SLO 门禁、金丝雀和综合实验。
• 数字口径分实测值、目标值和示例值。没有命令和原始输出的数字，不写“实测”；没有真实流量或账单的 SLO、RTO、成本，只写目标值与算式。

这些口径看起来繁琐，但它们是本书与“架构散文”的分界线。治理领域尤其容易被漂亮的原则掩盖空洞，所以每一章都要留下可以被别人复跑的东西。

治理不是架构的下一层

很多人把治理理解成架构完成之后的“管理动作”：架构师画图，平台团队建工具，SRE 定 SLO，财务看账单。这个分工看似清晰，实际会制造三个新的断点。

第一，架构决策失去运行反馈。架构师选择了一个拆分方案，但没有人把拆分后的发布频率、故障恢复时间和单位成本反馈回来，下一次决策只能靠经验。

第二，平台能力脱离真实约束。平台团队按“最佳实践”建设能力，却不知道业务团队的真实发布路径、审批瓶颈和遗留系统限制，最后交付的是一套正确但不好用的工具。

第三，成本与架构脱钩。财务看到的是月度账单，架构师看到的是服务拓扑图，两者之间没有归因关系；等到成本压力出现，只能做全局削减，而不是针对高成本的设计做调整。

卷四把这些断点接起来：第 1 章要求拆分决策带验收指标，第 7 章要求 SLO 触发发布决策，第 11、12 章要求平台与成本反向影响架构。治理不是架构的下一层，而是架构决策的反馈回路。

这张表的右列，就是本书 13 章存在的理由。没有反馈机制，架构会不断做加法，直到组织无法承担维护成本。

四卷的分工

四卷不是四个独立主题，而是一条决策链：边界决定代价，代价决定一致性方案，一致性方案决定治理动作。卷四会不断回指前三卷，因为治理的对象不是抽象系统，而是前三卷做出的那些具体选择。

本书不做什么

• 不写微服务、SRE、平台工程的百科式综述；这些内容站内专题已有，本书只保留与订单系统相关的判据和实现。
• 不伪造云上实测。没有真实 Kubernetes、服务网格、追踪后端、账单数据时，正文只写“需真实环境”与验收口径。
• 不把工具当答案。网关、注册中心、配置中心、混沌平台都是手段；本书优先讨论“没有这个工具时，问题能不能被定义”。
• 不承诺一套放之四海而皆准的组织方案。团队规模、监管要求和业务节奏不同，治理的粒度必须跟着变；书中给出的是判据和状态机，不是模板。

几个容易混淆的词

治理领域的很多争论，其实源于同一个词被赋予了不同含义。本书在下面几组词上给出明确用法，后续章节不再重复解释。

拆分与服务化。 拆分是把一个模块的边界变成可独立部署、独立演进的单元；服务化是拆分的一种实现方式。拆分的目的是降低变更耦合，不是让部署单元越多越好。第 1 章会用“变更频率、扩缩容、故障与合规隔离”三个触发条件判断是否值得拆。

SLO 与 SLA。 SLA 是对外承诺，通常带赔付条款；SLO 是内部目标，用来驱动工程决策。本书只讨论 SLO，不讨论合同条款。SLO 的关键不是数字，而是它是否触发发布冻结、预算评审和优先级调整。

错误预算与可用性。 错误预算是一个时间窗口内允许的失败量，通常写成 1 - SLO 乘以请求量；可用性是结果指标。错误预算的价值在于把“还剩多少失败额度”变成可消耗的资源，而不是月底回看一个百分比。

功能开关与配置。 配置改变系统行为参数，功能开关改变代码路径。两者的生命周期不同：配置长期存在，开关应当过期。第 5 章会把开关分成发布开关、实验开关、权限开关和运维开关，并给出过期检测。

可观测性与监控。 监控回答“系统是否在已知的故障模式里”，可观测性回答“能否从外部信号推断出未预料的问题”。本书把日志、指标、追踪统称为遥测信号，再用语义约定把它们变成可关联的数据。

平台与工具链。 工具链是能力的集合，平台是有用户、有边界、有采纳指标的产品。第 11 章会把平台能力目录、黄金路径和采纳率放在一起讨论，避免“工具建好了就等于平台成功”。

这些用词约定会贯穿全卷。如果你在其他资料里看到不同定义，不必争论对错，先确认它讨论的是哪一层问题。

本书如何验证

卷四的每一章都要留下至少一类证据。下面这张表是写作时的自检清单，也可以当作读者判断一章是否值得精读的标准。

这张表也解释了本书为什么反复出现表格和状态机：不是喜欢形式，而是治理结论必须能被别人检查。一段没有判据的“最佳实践”，在不同团队里会得到完全不同的执行结果。

如果某一章只有原则没有证据，读者有理由怀疑它；如果某一章只有代码没有边界，读者同样有理由怀疑它。两者都齐了，才构成一次可复用的治理动作。

一个简单的治理成熟度测试

在开始读正文之前，可以用下面五个问题给当前系统做一次快速体检。每个问题只回答“有、没有、不知道怎么验证”，不要急着给分数。

五个问题里，“不知道怎么验证”比“没有”更危险。没有可以补，无法验证意味着团队失去了判断自己是否在改善的能力。卷四的很多章节，本质上是在把“不知道怎么验证”变成“有一个可运行的检查”。

这五个问题也对应本卷的五条主线：契约、观测、发布、诊断、平台与成本。读完之后，建议用同一张表再测一次，看看哪些格子从“不知道”变成了“有证据”。

怎么读这本书

第一次读，从目录与学习路径 进入，按 13 章顺序走。手上有具体问题，直接查目录里的症状表：发布互相拖累看第 1、2 章，SLO 失真看第 7 章，平台没人用看第 11 章，账单失控看第 12 章。

第 13 章会把前面所有组件装进同一次演进实验：把模块化单体拆成两个服务，用契约门禁、SLO 门禁和混沌演练做一次发布，最后整理四卷的路线图。读完那一章，你应该能给出一份带触发条件、退出条件和责任人的演进计划，而不是一份“微服务改造方案”。

治理的难点从来不是知道该做什么，而是知道什么时候不做、什么时候撤回、由谁承担代价。这本书想训练的，就是这三种判断。

如果读完之后，你能在自己的系统里指出一处“看起来正常、实际上没有反馈”的治理断点，并给出一个可验证的修复动作，那么这本序就完成了它的任务。

如果时间有限，也可以倒着读：先看第 13 章的综合实验，知道自己最终要交出的产物长什么样；再回到第 1 章，从拆分判据开始补齐。顺序可以变，但证据不能跳步——每一章的结论都要能在你的系统里找到对应的检查、记录或回滚路径。

最后一个提醒：不要把这本书当成“治理清单大全”。清单只能覆盖已经发生过的问题；真正难的是在你自己的系统里，发现那些还没有被命名的失效点。卷四提供的不是答案，而是一套提问方式。