怎么用这张速查
本附录不引入新概念，只把卷四 13 章的判据压成表格，方便评审、排查和写方案时回查。每张表都标注来源章节；阈值是起点，不是普适常数，落地时要结合业务量、团队规模和监管要求调整。
使用顺序建议：先查“问题属于哪一类”，再查对应表的“触发条件”，最后确认“退出条件”。只看触发条件不看退出条件，治理动作就会只进不退。
A.0 一条判据的四个部分
本附录所有表格都按同一个结构组织。缺任何一部分，判据都不完整。
| 部分 | 回答的问题 | 反例 | 合格写法 |
|---|---|---|---|
| 触发条件 | 什么情况下要采取动作 | “感觉拆分更好” | 两个模块 50% 以上发布需同时上线 |
| 观测信号 | 用什么数据判断 | “看监控” | 发布记录与资源曲线，30 天窗口 |
| 退出条件 | 什么情况下停止或回退 | “持续优化” | 连续 3 个月可独立发布 |
| 责任人 | 谁维护判据与证据 | “团队共同负责” | 订单组架构负责人，季度复核 |
判据不是一次性文档。业务量、团队规模和监管要求变化后，同一个阈值可能从合理变成有害；因此每张表都应当在季度评审时重新确认一次，而不是复制到新项目里长期使用。
A.1 拆分判据
来源：第 1 章。
| 触发条件 | 可观测信号 | 建议动作 | 退出/回退条件 |
|---|---|---|---|
| 变更频率冲突 | 两个模块 50% 以上的发布需要一起上线 | 先拆模块边界，再评估独立部署 | 连续 3 个月可独立发布 |
| 独立扩缩容 | 单模块占用 60% 以上资源且波动独立 | 拆为独立部署单元 | 资源曲线与主服务解耦 |
| 故障隔离 | 单模块故障导致整体不可用 | 拆出并加舱壁/超时 | 故障影响面收敛到单服务 |
| 合规/数据边界 | 监管要求数据或团队物理隔离 | 拆服务或拆部署域 | 审计确认隔离有效 |
| 组织边界 | 两个团队长期争用同一发布窗口 | 先改团队契约，再决定拆分 | 发布协调成本低于拆分成本 |
拆分前必须回答的五个问题：
- 共享数据是什么，拆开后由谁拥有？
- 跨服务调用是同步还是事件，失败如何处理？
- 拆开后发布、回滚、值班由谁负责？
- 观测、告警、SLO 是否覆盖新边界？
- 如果收益不成立，退回单体路径需要多久？
任何一题答不上来，说明拆分条件还不成熟。拆分不是“先进架构”，而是一次带利息的借贷：自治是本金，分布式成本是利息。
A.2 契约兼容矩阵
来源：第 2 章。
| 变更 | 向后兼容 | 向前兼容 | 处理方式 |
|---|---|---|---|
| 新增可选字段 | 是 | 视消费者而定 | 默认值 + 忽略未知字段 |
| 新增必填字段 | 否 | 否 | 先可选、双写、再收紧 |
| 删除可选字段 | 通常否 | 是 | 先标记弃用，观察调用量 |
| 删除必填字段 | 否 | 否 | 禁止直接删，走版本化 |
| 字段改名 | 否 | 否 | 新旧字段并存至少一个弃用窗口 |
| 类型收窄（int64→int32） | 否 | 否 | 禁止；新增字段替代 |
| 枚举新增值 | 视消费者 | 是 | 消费者必须有 unknown 分支 |
| 错误码语义变化 | 否 | 否 | 新增错误码，旧码保留 |
弃用窗口的三个输入：消费者清单、调用量趋势、合同/监管要求。没有消费者清单的弃用，不是弃用，是赌博。
A.3 服务发现与负载均衡
来源：第 3 章。
| 参数 | 常见起点 | 过低的风险 | 过高的风险 |
|---|---|---|---|
| 健康检查间隔 | 2–5 秒 | 故障实例滞留 | 检查流量与抖动 |
| 摘除宽限期 | 10–30 秒 | 在途请求被切断 | 故障实例继续接流量 |
| TTL 租约 | 3× 心跳间隔 | 网络抖动导致误摘 | 实例宕机后仍被路由 |
| 重试预算 | 成功请求的 10% | 故障时放大流量 | 正常时重试不足 |
| 退避 | 指数 + 抖动 | 同步重试打满 | 恢复变慢 |
| 局部性策略 | 同可用区优先 | 跨区延迟与流量费 | 单区故障影响面扩大 |
重试必须和超时预算一起配。单次超时 1 秒、重试 3 次，意味着最坏 4 秒；如果上游只给了 2 秒预算，重试就是把失败变成超时叠加。
A.4 网关与 BFF
来源：第 4 章。
| 关注点 | 网关负责 | BFF 负责 | 服务负责 |
|---|---|---|---|
| 路由 | 路径/域名/租户到服务 | 端到端聚合路径 | 业务路由 |
| 认证 | 边缘令牌校验 | 会话与端特定声明 | 细粒度授权 |
| 限流 | 租户/租户组配额 | 端特定配额 | 资源级并发 |
| 超时 | 入口总预算 | 聚合子预算 | 下游调用预算 |
| 降级 | 统一错误页/兜底 | 端特定部分失败 | 业务降级 |
| 观测 | 入口指标与追踪起点 | 聚合耗时拆分 | 服务内部信号 |
网关最常见的错误是把“统一”做成“全知”：认证、限流、路由、聚合、协议转换全塞进网关，最后网关变成不可发布的单体。BFF 的边界是“按端裁剪”，不是“把业务逻辑搬上来”。
A.5 配置与开关
来源：第 5 章。
| 类型 | 生命周期 | 变更频率 | 回滚方式 | 典型风险 |
|---|---|---|---|---|
| 环境配置 | 长期 | 低 | 版本回退 | 环境漂移 |
| 实例配置 | 跟随实例 | 中 | 重启/重新下发 | 实例间不一致 |
| 发布开关 | 天到周 | 高 | 关闭开关 | 开关过期未删 |
| 实验开关 | 周到月 | 高 | 关闭并清理 | 实验组残留 |
| 权限开关 | 长期 | 低 | 策略回退 | 越权 |
| 运维开关 | 小时到天 | 高 | 恢复默认 | 忘记恢复 |
开关债的三个信号：超过 90 天仍在使用、没有负责人、没有过期时间。三者占其二，就应进入清理队列。
A.6 可观测性
来源：第 6 章。
| 信号 | 必须统一的字段 | 用途 | 常见缺口 |
|---|---|---|---|
| 日志 | trace_id、tenant_id、order_id、level、service | 事件细节与审计 | 字段名各写各的 |
| 指标 | service、route、status、tenant、version | 聚合与告警 | 高基数标签 |
| 追踪 | trace_id、span_id、parent_id、status、duration | 跨服务路径 | 上下文丢失 |
| 事件 | change_id、deploy_id、actor | 变更关联 | 没有变更记录 |
语义约定的最小验收：给定一个 order_id 和一个时间窗口，能在 5 分钟内拉出完整链路、相关日志和同期变更。做不到，说明字段或关联键缺失。
A.7 SLI 与错误预算
来源：第 7 章。
| 项目 | 定义 | 示例 | 注意 |
|---|---|---|---|
| SLI | 好事件/总事件 | 成功下单请求占比 | 分母要包含失败与超时 |
| SLO | 窗口内目标 | 30 天 99.9% | 窗口越长，预算越大 |
| 错误预算 | (1-SLO)×总事件 | 30 天约 43 分钟 | 按请求量还是时间要统一 |
| 燃尽率 | 实际消耗/预算 | 1 小时烧掉 10% | 用于告警与冻结 |
| 冻结条件 | 预算低于阈值 | 剩余 < 20% 停止非紧急发布 | 必须有解冻流程 |
多服务依赖时，用户可用性近似为路径上各服务可用性的乘积。每个服务都 99.9%，十个串联服务的理论可用性只有约 99.0%。预算分配要按关键路径，不是平均分。
A.8 混沌演练
来源：第 8 章。
| 层次 | 注入手段 | 爆炸半径 | 必须先有的保护 |
|---|---|---|---|
| 进程 | 杀进程、暂停、CPU/内存压力 | 单实例 | 健康检查与摘流 |
| 网络 | 延迟、丢包、分区、DNS 故障 | 单服务/单可用区 | 超时、重试预算、舱壁 |
| 依赖 | 下游错误、慢响应、连接拒绝 | 单依赖 | 降级与熔断 |
| 区域 | 机房/可用区隔离 | 单区域 | 多活切换与数据校验 |
一次合格实验必须写清：稳态假设、注入范围、持续时间、止损条件、回滚动作、观测信号。缺一项，就不是实验，是事故演练。
A.9 发布阶段
来源：第 9 章。
| 阶段 | 代码 | 数据库 | 开关 | 退出条件 |
|---|---|---|---|---|
| Expand | 新旧兼容 | 加字段/加表，双写 | 新路径默认关 | 双写校验差异为 0 |
| Migrate | 读新写新可灰度 | 回填历史数据 | 按租户/比例放量 | 回填完成、指标达标 |
| Contract | 删除旧路径 | 删旧字段/旧表 | 移除开关 | 观察窗口结束、无回滚需求 |
发布顺序不能倒：先删旧字段再发新代码，会让旧实例读不到数据；先关开关再回填，会让部分租户永久停在旧状态。
A.10 租户与身份
来源：第 10 章。
| 隔离级别 | 数据 | 计算 | 成本 | 适用 |
|---|---|---|---|---|
| 共享库共享表 | tenant_id 行级隔离 | 共享进程 | 最低 | 小租户、SaaS 长尾 |
| 共享库独立 schema | schema 隔离 | 共享进程 | 中 | 中租户、合规要求一般 |
| 独立库 | 库级隔离 | 共享或独立进程 | 较高 | 大租户、数据敏感 |
| 独立部署 | 完全隔离 | 独立资源 | 最高 | 监管、专属实例 |
服务身份的最小要求：每个服务有独立身份、权限按操作而非按服务粗放授予、密钥可轮换、调用有审计。共享长期密钥是治理债，不是捷径。
A.11 平台与成本
来源：第 11、12 章。
| 指标 | 定义 | 用途 | 反指标 |
|---|---|---|---|
| 采纳率 | 使用黄金路径的新服务/新服务总数 | 判断平台是否被使用 | 只统计访问量 |
| 交付周期 | 从创建到首次上线 | 判断是否真的提效 | 只统计流水线时长 |
| 反悔成本 | 迁回旧路径所需人天 | 判断锁定风险 | 不统计迁移成本 |
| 单位成本 | 成本/订单或成本/租户 | 判断规模经济 | 只看总账单 |
| 未分摊比例 | 无标签成本/总成本 | 判断归因质量 | 把未分摊塞进“其他” |
成本归因的最低标准：每一笔资源至少有一个 owner 标签；没有 owner 的成本进入未分摊桶，并设上限与处置人。没有上限的未分摊桶，会变成永久黑洞。
A.12 一张总表
| 治理动作 | 最小证据 | 失败信号 | 回退动作 |
|---|---|---|---|
| 拆分 | 触发条件 + 验收指标 | 发布更慢、故障面扩大 | 合并回单体路径 |
| 契约变更 | 兼容矩阵 + 消费者验证 | 下游反序列化失败 | 保留旧字段/旧版本 |
| 服务发现 | 健康检查 + 摘流验证 | 5xx 随实例上下线抖动 | 固定实例列表兜底 |
| 网关改造 | 超时预算 + 级联测试 | 入口故障扩散 | 绕过网关直连（临时） |
| 配置变更 | 版本 + 灰度 + 回滚 | 配置推错导致全量异常 | 回退上一版本 |
| 开关上线 | 负责人 + 过期时间 | 开关债累积 | 关闭并删除 |
| SLO 门禁 | SLI + 预算 + 冻结流程 | 全绿但用户投诉 | 重定义 SLI |
| 混沌演练 | 稳态 + 爆炸半径 + 止损 | 演练伤及生产 | 立即停止并回滚 |
| 金丝雀发布 | 指标门禁 + 自动回滚 | 回滚不干净 | 蓝绿/全量回退 |
| 多租户 | 隔离级别 + 越权测试 | 跨租户数据泄漏 | 提升隔离级别 |
| 平台建设 | 黄金路径 + 采纳率 | 能力多但没人用 | 收敛能力，做用户旅程 |
| 成本治理 | 归因 + 预算 + 责任人 | 账单涨但找不到主 | 未分摊桶封顶 |
这张总表适合放在评审文档的第一页。评审时逐行问“我们的证据是什么”，比讨论“要不要做治理”有效得多。
A.13 判据怎么写
写一条可执行的判据，比收集一堆“最佳实践”更难。下面是一个五步模板，适用于本附录的任何一张表。
- 从症状出发：先写“什么现象让我们决定采取动作”，不要从工具或方案出发；
- 选一个主指标：能直接反映症状的指标，允许多个但必须有一个主指标；
- 给阈值和窗口：阈值要能写进查询，窗口要覆盖至少一个业务周期；
- 写退出条件：明确什么情况下停止、回退或合并，避免动作只进不退；
- 指定责任人与复核周期：谁维护数据，多久复核一次，过期怎么办。
一个反例和改写：
| 反例 | 问题 | 改写 |
|---|---|---|
| “服务拆分后要持续优化性能” | 无指标、无阈值、无退出 | “拆分后订单创建 p99 不超过拆分前 1.2 倍，连续 30 天；否则回退到单体路径” |
| “上 SLO 提升稳定性” | 把工具当目标 | “订单创建 SLI 达到 99.9%，错误预算低于 20% 时冻结非紧急发布” |
| “加强成本管理” | 无归属、无口径 | “关键资源 owner 标签覆盖 100%，单位订单成本按周对比，连续两周上涨 10% 触发评审” |
| “推进平台建设” | 无用户、无采纳 | “新服务黄金路径采纳率 80%，创建到首次上线中位数不超过 1 天” |
模板不能保证判据一定正确，但能挡住大部分“听起来很对、实际上无法验收”的治理目标。评审时如果一条判据写不出主指标和退出条件，就应当退回重写，而不是先上线再说。
常见错误
- 把阈值当常数。表中的数字是起点，业务量、团队规模和监管要求不同，阈值必须重新校准。
- 只查触发条件，不写退出条件。治理动作没有退出条件，就会变成永久负担。
- 用工具名代替判据。“我们上了服务网格”不是证据，“配置冲突检查通过、级联故障演练通过”才是。
- 把未分摊成本藏进“其他”。未分摊比例本身就是一个需要治理的指标。
- 把附录当规范。附录是索引，具体推导和代码在正文；脱离正文引用表格，容易断章取义。
小结
本附录把卷四的判据压成 12 张表，覆盖拆分、契约、发现、网关、配置、观测、SLO、混沌、发布、租户、平台与成本。每张表都包含触发条件、观测信号和退出条件，目的是让治理动作可以被评审、被执行、被撤回。
表格不能替代判断。真正要带走的是三个习惯：先定义证据，再决定动作；先写退出条件，再开始改造；先找责任人，再谈指标。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。