分治、架构演进、平台化与技术债治理

本册回答“为什么在此时、以这个顺序改变系统，以及何时停止”，不重复注册发现、消息可靠性、容器编排或监控组件原理。机制细节分别复用单体到微服务演进、契约兼容与灰度和发布与回滚。

1. 事实边界与演进总纲

本文统一使用四级事实：E1（源码与可复现证据）只证明本地文件、真实渲染资产与可重复审计结果；E2（已有材料映射）说明简历项目可支撑候选叙述，不证明生产已经采用；E3（演练证据）公开输入、公式、过程与结论；E0（待核对）明确缺少源码、配置、指标、事故记录或组织访谈。涉及产能、收益和故障率的数字若无可追溯来源，一律降为 E3（演练证据）或 E0（待核对）。

1.1 分治思想、问题规模、耦合与停止条件

分治不是把代码平均切小，而是把一个超出团队认知、交付或恢复能力的问题，按稳定不变量、变化原因和责任边界拆成可独立求解的子问题，再通过最少且明确的契约组合。拆分收益来自并行认知、局部变更、资源与故障隔离；代价来自跨边界协调、数据一致性、版本兼容、观测和值班。若子问题仍共享同一事务、同一发布节奏、同一故障命运和同一负责人，物理切开只会把内部耦合搬到网络上。

判断问题规模要同时看五个量：认知规模、变化规模、运行规模、故障规模和组织规模。代码行数只是弱信号。停止拆分条件也必须预先写出：跨边界协调成本连续高于独立收益；一次业务变更总要同时改多个单元；独立扩容比例不显著；值班和平台能力不足；关键不变量被迫跨资源维护。满足这些条件时应保持模块化单体，或把已拆错的服务合并回迁。拆分与合并都是正常的架构动作，不代表技术升降级。

flowchart TD
    A["业务问题与不可接受损失"] --> B["按不变量和变化原因分组"]
    B --> C{"子问题能独立决策和恢复吗"}
    C -->|"否"| D["保持模块化单体"]
    C -->|"是"| E["核算交付、容量、故障和组织收益"]
    E --> F{"收益覆盖分布式成本吗"}
    F -->|"否"| D
    F -->|"是"| G["小范围提升为独立部署边界"]
    G --> H{"协调成本持续反弹吗"}
    H -->|"是"| I["停止拆分或合并回迁"]
    H -->|"否"| J["保留边界并持续复审"]

图解读：节点从问题和损失开始，箭头先验证逻辑独立性再评估物理拆分；前提是已有模块接口和责任人；失败分支是收益不足或协调反弹时停止；结论是“可拆”不等于“应拆”。

数据演绎 1：拆分收益何时被协调成本吃掉

E3（演练证据）：一个 8 人团队维护订单、库存和履约三个模块，每月 40 次变更，其中 8 次因共同发布各等待 2 小时，损失 8 x 2 = 16 人时。若拆为三个服务，独立发布节省 12 人时，但每月增加契约联调 10 人时、值班与流水线维护 14 人时，总新增 24 人时，净结果为 12 - 24 = -12 人时。此时应先模块化和自动化发布；只有独立容量或故障损失再提供超过 12 人时等价收益，才重开拆分评审。

热门面试题

1. 问题：分治思想在架构设计中到底分什么？
   • 考点：子问题独立性与组合成本。
   • 回答思路：从不变量、变化原因、责任和恢复回答。
   • 详细答案：分的是可以独立理解、决策、验证和恢复的业务子问题，不是平均分代码或按技术层切服务。先聚合同一不变量和变化原因，再明确输入、输出、失败语义和所有者；若组合时需要大量同步协调，说明边界仍不稳定。
   • 进阶追问：目录拆开是否算分治完成？
   • 进阶回答：不算；还要用依赖规则、数据权限、测试和责任验证边界，目录只是表达形式。
2. 问题：为什么代码量大不等于必须微服务化？
   • 考点：规模维度。
   • 回答思路：区分代码、变化、运行、故障和组织规模。
   • 详细答案：大代码库可以通过模块接口、增量构建和所有权治理降低认知成本；若模块仍共同变化、没有独立热点或故障隔离收益，服务化只会增加网络、契约、数据和值班成本。应让真实瓶颈而非行数触发物理拆分。
   • 进阶追问：什么时候代码规模会成为强信号？
   • 进阶回答：当它已导致构建、测试、所有权和变更范围持续失控，并且模块化治理无法收敛时，才与其他证据共同支持拆分。
3. 问题：如何定义“停止拆分”？
   • 考点：停止规则与回迁。
   • 回答思路：用收益阈值、协调反弹和恢复能力回答。
   • 详细答案：在决策前写出停止阈值，例如跨服务共同变更率、联合故障率、值班负担和单位请求成本连续两个周期恶化；触发后冻结新增服务，优先修边界，必要时合并部署。停止不是否定历史，而是防止沉没成本继续扩大。
   • 进阶追问：已经投入很多还能合并吗？
   • 进阶回答：要忽略沉没成本，比较未来维护现金流；保留模块边界与契约测试，合并部署和数据路径也能降低成本。

1.2 从模块化单体到平台抽取的演进连续谱

架构演进不是单向阶梯，而是六种可组合状态。模块化单体用本地事务和一次发布换低协调成本；垂直切分先按端到端业务能力隔离代码、数据访问和负责人；服务拆分只把最有独立变化、容量或故障证据的边界提升为进程；事件化用于传播已经发生的事实，不能把所有同步决策改成广播；CQRS（命令查询职责分离）读模型在权威写模型无法经济满足多样查询时建立可重建投影；平台抽取则把多个团队反复解决的非差异化摩擦产品化。

每一步都增加新的运行责任。事件化引入陈旧、重复、乱序和回放；CQRS（命令查询职责分离）读模型引入差异年龄、重建和查询降级；平台引入路线图、支持、兼容和内部垄断风险。因此演进顺序应尽量从低成本、可逆的逻辑边界开始，只有当前约束被真实证据击穿才提升物理边界。平台不是终点，某能力若只有一个用户、需求仍剧烈变化或差异化本身就是竞争力，就留在产品团队。

sequenceDiagram
    participant 业 as 业务约束
    participant 单 as 模块化单体
    participant 服 as 独立服务
    participant 事 as 事件化协作
    participant 读 as CQRS（命令查询职责分离）读模型
    participant 平 as 内部平台
    业->>单: 边界、依赖与数据访问先收敛
    单->>服: 独立变化/容量/故障证据达阈值
    服->>事: 可恢复副作用需要解耦
    事->>读: 多样查询压迫权威写模型
    读->>平: 多团队重复摩擦且接口稳定
    alt 任一步收益不足
        平-->>单: 停止抽取、合并或退回局部实现
    else 门禁持续满足
        平-->>业: 以采用率和交付结果复审
    end

图解读：节点表示能力状态而非技术等级；箭头由约束证据触发；前提是上一阶段已有稳定契约；失败路径允许停止和回迁；结论是演进价值来自解决当前瓶颈，不来自阶段数量。

数据演绎 2：读模型与平台抽取不是同一阶段

E3（演练证据）：订单写库峰值 800 次写入每秒，客服组合查询产生 2,400 次读取每秒且包含三表聚合。建立可重建读模型后，权威库读取降至 600 次每秒，但投影 P99（99 分位响应时间）年龄为 18 秒。若客服可接受 30 秒并提供“查权威”入口，CQRS（命令查询职责分离）成立。此时只有客服一个用户，每月需求变化 6 次，抽成企业查询平台会把变化协调从 1 个团队扩大到 4 个团队，因此应停在产品内读模型，而非立即平台化。

热门面试题

1. 问题：模块化单体、服务拆分和平台抽取的本质差别是什么？
   • 考点：边界层次。
   • 回答思路：按部署、责任和用户关系区分。
   • 详细答案：模块化单体保护逻辑边界但共享部署；服务拆分增加独立运行和端到端责任；平台抽取进一步把能力作为面向多个内部用户的产品经营。三者依次增加网络、值班、兼容、支持和路线图成本，不能互相替代。
   • 进阶追问：公共库算平台吗？
   • 进阶回答：通常不算；没有自助接口、服务目标、用户反馈和生命周期责任的公共库只是共享资产。
2. 问题：什么时候引入 CQRS（命令查询职责分离）读模型？
   • 考点：权威写模型与查询投影。
   • 回答思路：从查询压力、陈旧容忍和重建能力回答。
   • 详细答案：当多样查询迫使权威写模型增加大量索引、联表或副本，且用户能接受明确陈旧窗口时，引入按查询优化的可重建投影。必须保留权威查询、差异指标、回放和重建路径，不能把读模型误当第二权威。
   • 进阶追问：所有读写分离都是 CQRS（命令查询职责分离）吗？
   • 进阶回答：不是；普通只读副本仍共享同一模型，只有命令模型和查询模型在职责与形态上明确分离才符合该决策。
3. 问题：事件化为什么不是演进的默认下一步？
   • 考点：异步边界。
   • 回答思路：比较即时裁决与事实传播。
   • 详细答案：只有已经发生的事实适合异步传播；库存是否允许扣减、支付是否成功等权威裁决不能靠广播后猜测。事件化会新增重复、乱序、积压、回放和最终一致窗口，接收方没有幂等与恢复能力时反而降低可靠性。
   • 进阶追问：怎样避免事件变成远程命令？
   • 进阶回答：用过去时命名、携带事实版本、不指定某个消费者必须执行，并让接收方自主决定本地动作。

1.3 Strangler Fig Pattern（绞杀者模式）、Branch by Abstraction（抽象分支）与渐进切流

Strangler Fig Pattern（绞杀者模式）适合从系统边缘按能力逐段接管：先建立可控入口，再让新旧路径并存，最后退役旧能力。Branch by Abstraction（抽象分支）适合同一代码库内部替换实现：先把调用方收敛到稳定抽象，再在抽象后挂新旧实现，通过开关逐步切换。两者可以组合，但都要求旧路径仍可运行、同一请求有稳定业务键、外部副作用可隔离或补偿。

双运行是同一业务请求让新旧路径都计算并比较；影子流量是复制真实请求给新路径但不让其产生真实副作用；灰度是让一小部分真实业务由新路径权威处理；回滚是停止新增新路径事实并把业务恢复到可信状态。四者验证能力不同，不能用影子读结果证明真实写副作用正确，也不能把“代码版本退回”当成数据和外部承诺已经恢复。迁移控制面必须记录流量分组、版本、开关、差异、回退容量和所有者。

sequenceDiagram
    participant 调 as 调用方
    participant 抽 as 稳定抽象/迁移入口
    participant 旧 as 旧实现
    participant 新 as 新实现
    participant 校 as 差异校验器
    participant 控 as 迁移控制面
    调->>抽: 请求与稳定业务键
    控->>抽: 下发影子/双运行/灰度规则
    alt 影子或双运行
        抽->>旧: 权威执行
        抽->>新: 隔离副作用后计算
        旧-->>校: 权威结果与版本
        新-->>校: 候选结果与版本
        校-->>控: 差异分类
    else 小流量灰度
        抽->>新: 权威执行
        新-->>抽: 结果与审计标识
    end
    alt 高价值差异或门禁失败
        控->>抽: 冻结扩面并切回旧实现
    else 观察窗满足
        控->>抽: 逐级扩面
    end

图解读：抽象或入口同时承载路由和证据关联；影子分支隔离副作用，灰度分支才产生真实事实；失败时先冻结再切回；结论是渐进迁移依赖可观测控制面，而不是一个布尔开关。

数据演绎 3：灰度比例小不等于风险小

E3（演练证据）：订单新路径灰度 1%，日订单 300 万，则每天仍有 3 万个真实订单。若高价值订单只占 0.2%，随机灰度每天约命中 30000 x 0.2% = 60 个高价值订单。即使总体差异率仅 0.01%，也可能在十天观察窗出现 3 个差异；若任何一个涉及库存超卖，门禁应为零容忍并立即停止，而不是用总体成功率稀释业务风险。

热门面试题

1. 问题：Strangler Fig Pattern（绞杀者模式）与 Branch by Abstraction（抽象分支）怎样选择？
   • 考点：迁移控制点。
   • 回答思路：按系统边缘和代码内部两类替换回答。
   • 详细答案：跨系统或按业务能力接管入口时优先 Strangler Fig Pattern（绞杀者模式）；同一代码库替换实现且调用方众多时先用 Branch by Abstraction（抽象分支）收敛调用。大型迁移常先内部建抽象，再由外部入口分批切流。
   • 进阶追问：抽象会不会永久留下？
   • 进阶回答：会，所以决策必须写删除条件；新实现稳定且旧实现退役后，若抽象不再隔离真实变化就应简化。
2. 问题：影子流量和双运行有什么关键区别？
   • 考点：验证范围与副作用。
   • 回答思路：比较请求来源、执行结果和权威性。
   • 详细答案：影子流量强调复制真实输入并隔离新路径副作用，适合性能和纯计算验证；双运行强调同一业务键下新旧结果可比，通常只有一方权威。两者都不能自动证明真实外部写和回滚正确。
   • 进阶追问：支付可以做影子写吗？
   • 进阶回答：不能触达真实渠道扣款；可验证到提交前、使用沙箱或只比较构造出的请求，其余风险留给受控灰度。
3. 问题：回滚为什么不等于回退制品？
   • 考点：业务恢复。
   • 回答思路：从数据、中间态、消息和外部副作用回答。
   • 详细答案：制品回退只改变代码，迁移期间已写入的新格式、已发消息、已调用物流或支付的事实仍存在。完整回滚要冻结新增流量、识别影响范围、恢复兼容读写、对账补偿并验证业务不变量。
   • 进阶追问：何时宁可向前修复？
   • 进阶回答：旧路径容量不足、数据已不可逆迁移或外部承诺无法撤销时，应冻结扩面后向前修复，并提高人工核验和风险批准等级。

1.4 数据库拆分、双写分叉、CDC（变更数据捕获）、回放与权威切换

数据库拆分先拆所有权，再拆物理存储。第一步禁止新旁路写并为目标事实确定单写者；第二步建立全量基线和可持续增量；第三步由旧权威通过 CDC（变更数据捕获）或事务内事件向新库投影；第四步回放历史并按业务键、版本、不变量和聚合金额校验；第五步让新库承担影子读或小流量权威写；最后迁移修复任务、权限、备份、告警和值班后才撤旧库。

应用双写最危险之处不是“偶尔失败”，而是两个成功顺序都可能分叉：旧成功新失败、新成功旧失败，以及超时后调用方不知道哪边成功。仅以重试不能消除未知态，还可能放大重复。CDC（变更数据捕获）把增量建立在旧权威提交之后，减少双权威窗口，但会引入日志保留、模式兼容、顺序、重复和消费积压风险。切换时必须用栅栏版本阻止旧写者越权，并保留可回放原始事实；校验不能只比行数，还要比业务守恒、状态合法性和高价值样本。

sequenceDiagram
    participant 调 as 调用方
    participant 旧 as 旧权威库
    participant 捕 as CDC（变更数据捕获）链路
    participant 新 as 新候选库
    participant 校 as 校验与对账
    participant 控 as 切换控制面
    调->>旧: 单写命令与业务键
    旧-->>调: 本地提交结果与版本
    旧->>捕: 提交日志
    捕->>新: 幂等投影版本
    新-->>校: 候选事实
    旧-->>校: 权威事实
    校-->>控: 行级、聚合与不变量差异
    alt 差异或积压超阈值
        控->>调: 保持旧库权威并暂停切换
        控->>捕: 修复后按检查点回放
    else 门禁满足
        控->>旧: 设置写栅栏并冻结旧写者
        控->>新: 提升为新权威
        控->>调: 切换写入口
    end

图解读：旧库在切换前始终是单写者；CDC（变更数据捕获）链路只复制已提交事实；失败时按检查点重放，不让应用临时双权威；结论是权威切换必须是受控状态机。

数据演绎 4：CDC（变更数据捕获）追平窗口

E3（演练证据）：切换前积压 900 万条变更，持续新增 2,000 条每秒，消费能力 5,000 条每秒，净恢复能力为 5000 - 2000 = 3000 条每秒，理论追平约 9000000 / 3000 = 3000 秒，即 50 分钟。若日志只保留 45 分钟，任何重启都可能越过可回放窗口，因此门禁失败；方案应延长日志保留、降低新流量或提高消费能力，并在真实故障注入后再切换。

热门面试题

1. 问题：数据库拆分为什么先拆所有权？
   • 考点：单写者与物理边界。
   • 回答思路：从写责任、权限和恢复回答。
   • 详细答案：物理分库但多方仍可写，只会把共享数据库变成跨库双写。先确定谁解释字段、维护不变量、接受命令和负责修复，再迁移权限、接口、对账和人员责任，物理存储才有稳定边界。
   • 进阶追问：能先复制表再慢慢治理吗？
   • 进阶回答：可作为只读候选，但必须明确旧库唯一权威；不能让复制表提前承接写入或被业务当第二事实源。
2. 问题：应用双写为何容易永久分叉？
   • 考点：部分成功与未知态。
   • 回答思路：枚举两个顺序和超时。
   • 详细答案：两个独立提交没有共同原子边界，任一顺序都可能一边成功一边失败；超时还让调用方不知道实际结果。重试若没有幂等键和版本会重复写，即使有也需要对账识别长期差异，所以不应把应用双写当稳态。
   • 进阶追问：短期双写可以接受吗？
   • 进阶回答：只在限时迁移、单权威明确、差异可检测可修复且有停止日期时接受，并优先让第二写成为非权威投影。
3. 问题：CDC（变更数据捕获）切换前必须证明什么？
   • 考点：回放、校验和恢复窗口。
   • 回答思路：按位点、容量、兼容、不变量和栅栏回答。
   • 详细答案：要证明位点可追溯、重复可幂等、模式可兼容、积压能在日志保留内追平、全量和增量可重放、业务不变量及聚合金额一致，并证明旧写者会被栅栏拒绝。缺任一项都不能提升新库为权威。
   • 进阶追问：行数一致为什么不够？
   • 进阶回答：重复行、错误状态、金额偏差和版本倒退都可能保持行数相同；必须按业务语义校验。

1.5 契约兼容、版本迁移与消费者退出

契约演进的目标不是让所有版本永久兼容，而是在生产者、消费者和历史数据无法原子升级时，提供有期限的安全迁移窗口。优先使用 Expand and Contract（扩展与收缩）顺序：先增加可选字段或新端点，让旧消费者继续工作；再升级消费者并观测真实使用；随后让生产者开始依赖新语义；最后删除旧字段、旧事件或旧端点。破坏性变化必须提升主版本或建立并行契约，不能靠口头通知跨越兼容期。

兼容包含语法、语义、时间和失败四层。字段能反序列化只证明语法兼容；同名状态含义变化会造成语义破坏；新消费者若假设事件零延迟，会被历史回放击穿；错误码、重试和幂等语义改变则会放大故障。迁移账本应记录生产者版本、消费者所有者、最后观测时间、数据保留、截止日和强制退出方式。消费者“调用量很低”不等于可以删除，高价值低频调用、离线任务和灾备路径必须单独确认。

sequenceDiagram
    participant 生 as 契约生产者
    participant 注 as 契约注册与兼容检查
    participant 旧 as 旧消费者
    participant 新 as 新消费者
    participant 观 as 使用观测与迁移账本
    生->>注: 先发布兼容扩展版本
    注-->>生: 兼容规则通过
    生-->>旧: 旧字段与旧语义继续可用
    生-->>新: 新字段与版本标识
    旧-->>观: 真实调用与最后使用时间
    新-->>观: 新版本采用与失败结果
    alt 仍有未知或高价值旧消费者
        观-->>生: 延长窗口或提供适配层
    else 旧消费者清零且保留期结束
        观-->>生: 批准收缩并删除旧契约
    end

图解读：扩展先于消费者迁移，收缩晚于真实使用清零；兼容检查只负责语法门禁，观测与账本负责语义退出；失败分支保留适配但必须更新截止日；结论是版本迁移完成由消费者证据定义。

数据演绎 5：百分之九十九迁移仍可能不能下线

E3（演练证据）：某物流契约有 200 个消费者，198 个已升级，采用率 99%；剩余两个分别是每月一次的关账任务和灾备接管任务。若只看七天调用量，两者均为零，但删除旧字段会在月末造成账单缺失，并在灾备时阻断接管。退出门禁应按消费者清单、最长业务周期和灾备演练确认，而不是以百分比或短窗流量代替责任签署。

热门面试题

1. 问题：为什么兼容不只是字段能否解析？
   • 考点：四层契约。
   • 回答思路：按语法、语义、时间和失败说明。
   • 详细答案：字段可解析仅证明语法层；若状态含义、事件顺序、延迟承诺、错误码或重试语义变化，消费者仍可能做出错误业务动作。契约测试必须覆盖场景和失败路径，不能只跑模式检查。
   • 进阶追问：新增可选字段一定兼容吗？
   • 进阶回答：也不一定；旧消费者若拒绝未知字段，或新生产者开始依赖该字段驱动语义，仍会产生破坏。
2. 问题：Expand and Contract（扩展与收缩）怎样避免永久双版本？
   • 考点：迁移生命周期。
   • 回答思路：强调账本、截止日、观测和强制退出。
   • 详细答案：扩展时就登记消费者、所有者、采用指标、最长业务周期和删除日期；迁移中对未知消费者升级阻断，收缩前演练低频任务和回放。逾期未迁移要升级责任，而不是默认无限兼容。
   • 进阶追问：适配层应保留多久？
   • 进阶回答：只保留到已知消费者完成迁移和保留期结束，并以调用清零、错误预算和负责人签署共同决定。
3. 问题：如何迁移一个破坏性物流接口？
   • 考点：并行版本和合作方迁移。
   • 回答思路：从新版本、适配、灰度、回放和退役回答。
   • 详细答案：建立明确新版本或防腐适配，先让平台同时接受新旧契约，按合作方分组灰度；保存请求响应和业务键做回放校验，监控失败语义而非只看状态码；最后按合作方签署和业务周期退役旧版。
   • 进阶追问：合作方永远不升级怎么办？
   • 进阶回答：比较隔离适配成本与商业价值，给出收费、限期或终止接入方案，不能让核心模型永久迁就单一遗留方。

1.6 组织、团队拓扑与架构演进

架构边界若没有匹配的团队所有权，会退化为跨团队排队。团队演进应从价值流和认知负荷出发：Stream-aligned Team（流对齐团队）端到端拥有某条业务价值流；Platform Team（平台团队）提供可自助的内部产品；Enabling Team（赋能团队）限时帮助产品团队跨越能力缺口；Complicated-subsystem Team（复杂子系统团队）拥有需要深专业知识的部分。这里的类型是责任设计，不是固定组织头衔，也不要求一次重组全部人员。

服务数量不能超过团队的运行承载力。一个团队若拥有几十个服务，却无法独立发布、值班和恢复，只会形成名义所有权。组织迁移应与系统迁移同节奏：先明确单一责任人和接口，再转移文档、权限、告警、预算和轮值；双运行期允许原团队护航，但必须有结束日期。铺路团队负责减少新路径摩擦，例如提供模板、迁移工具和现场辅导，目标是让流对齐团队具备能力后退出，而不是长期代操作。

sequenceDiagram
    participant 业 as Stream-aligned Team（流对齐团队）
    participant 铺 as Enabling Team（赋能团队）
    participant 平 as Platform Team（平台团队）
    participant 专 as Complicated-subsystem Team（复杂子系统团队）
    业->>铺: 提出迁移能力缺口与截止目标
    铺->>业: 限时结对、模板和演练
    业->>平: 通过自助接口申请环境与交付能力
    平-->>业: 标准路径、服务目标与审计证据
    业->>专: 通过稳定契约请求专业裁决
    专-->>业: 结果、版本和失败语义
    alt 团队已能独立交付和恢复
        铺-->>业: 移交材料并退出
    else 仍需人工代操作
        铺-->>平: 把重复摩擦反馈为平台改进
    end

图解读：流对齐团队保留业务结果责任，赋能团队限时铺路，平台团队产品化重复路径，复杂子系统团队守专业边界；失败分支把重复人工摩擦变成平台需求；结论是组织演进目标是降低认知与等待，不是增加团队类型。

数据演绎 6：服务数量与团队承载力

E3（演练证据）：一个 7 人团队拥有 28 个服务，每服务每月平均 0.5 次告警和 0.4 次发布协调，则每月约 14 次告警、11.2 次协调。若每次平均占 2 人时，运行协调约 50.4 人时；其中只有 6 个服务具备独立扩容收益，其余 22 个总是共同发布。把后者合并为 5 个清晰模块后，责任对象从 28 降至 11，预计协调次数显著下降。该算例支持回迁评审，但最终仍要以真实变更拓扑和事故数据验证。

热门面试题

1. 问题：组织结构为什么会影响系统架构？
   • 考点：沟通路径与责任边界。
   • 回答思路：从变更等待、接口和恢复说明。
   • 详细答案：系统接口往往复制团队沟通路径；一个业务动作若需四个团队排队，代码也会形成多次交接和模糊责任。通过端到端所有权、稳定契约和共享运行责任，可以让组织边界与业务变化边界更一致。
   • 进阶追问：应该先改组织还是先改系统？
   • 进阶回答：通常小步并行：先设临时跨职能责任单元验证边界，再逐步迁移代码、数据、权限和值班，避免大爆炸重组。
2. 问题：铺路团队与平台团队有什么区别？
   • 考点：赋能和产品责任。
   • 回答思路：按期限、输出和成功标准回答。
   • 详细答案：铺路团队通过结对、模板和迁移辅导消除阶段性能力缺口，成功标准是自己可以退出；平台团队长期经营自助产品，成功标准是用户采用和交付结果。铺路发现的重复摩擦可转为平台需求。
   • 进阶追问：铺路团队长期不退出说明什么？
   • 进阶回答：可能是平台缺口、产品团队认知过载或责任设计错误，应复审而不是把代操作制度化。
3. 问题：一个团队能拥有多少服务？
   • 考点：认知负荷与运行能力。
   • 回答思路：拒绝固定数字，用证据约束。
   • 详细答案：没有通用上限，要看变更频率、告警量、依赖复杂度、自动化和人员经验。若团队无法说清每个服务的不变量、发布、容量、故障和恢复，或大量服务总是共同变更，就已超过承载力。
   • 进阶追问：怎样止损？
   • 进阶回答：冻结新增服务，按变更拓扑和故障命运合并，降低告警噪声，并让责任对象与团队能力重新匹配。

1.7 平台化产品边界、内部价值与反平台陷阱

内部平台是面向内部开发者的产品，不是基础设施清单。它应服务一组高频、共性、非差异化的工作，提供清晰“铺好的路”：自助入口、默认安全配置、可观测反馈、服务目标、文档、支持和退出方式。平台产品边界由用户旅程决定，例如“从代码到可回滚发布”可以是一条完整能力，而把镜像、配置、网关和监控各建一个门户会把集成成本重新推给用户。

平台价值应测结果而非资源数量：首次交付时间、变更前置时间、失败恢复时间、认知负荷、合规自动化覆盖和自愿采用率。采用率必须与替代路径、用户分层和支持成本一起看，强制接入带来的百分之百不能证明价值。反平台陷阱包括大一统门户、最低公分母接口、平台团队替用户值班、过早抽象单一项目、隐藏成本转移和禁止产品团队合理偏离。平台应提供 golden path（推荐路径）而非 golden cage（黄金牢笼）；偏离需要风险说明，但允许创新和退出。

sequenceDiagram
    participant 用 as 内部开发者
    participant 门 as 平台自助入口
    participant 路 as golden path（推荐路径）
    participant 控 as 安全与成本门禁
    participant 反 as 反馈与产品路线图
    用->>门: 声明服务目标与工作负载
    门->>路: 生成可运行、可观测、可回滚路径
    路->>控: 校验权限、预算、恢复和证据
    alt 默认路径满足需求
        控-->>用: 自动交付并返回运行证据
    else 合理偏离
        控-->>用: 风险说明、限时例外与复审日
    end
    用-->>反: 摩擦、采用和交付结果
    反-->>门: 调整产品边界或删除低价值能力

图解读：用户声明目标而非选择底层组件；推荐路径把默认值和门禁组合起来；偏离分支不是禁止，而是限时管理；反馈回到路线图；结论是平台靠减少用户认知负荷产生价值。

数据演绎 7：平台投资何时产生正价值

E3（演练证据）：10 个团队每月各做 3 次环境与发布配置，每次手工耗 5 小时，总摩擦为 10 x 3 x 5 = 150 人时。平台首期投入 600 人时，月维护 45 人时；若自助路径把单次降至 1 小时，月节省 10 x 3 x 4 = 120 人时，净节省 75 人时，回收期约 600 / 75 = 8 个月。若真实采用只有 40%，净节省降为 120 x 40% - 45 = 3 人时，回收期失去意义，应先解决产品边界和采用摩擦，而不是继续扩功能。

热门面试题

1. 问题：什么能力值得平台化？
   • 考点：共性、频率、稳定性和差异化。
   • 回答思路：按用户问题和投资回报回答。
   • 详细答案：多个团队高频重复、接口相对稳定、非业务差异化且可形成完整自助旅程的能力值得平台化。先用铺路和模板验证，再按节省时间、风险与采用证明投资，而不是看到重复代码就抽公共平台。
   • 进阶追问：只有两个团队能做吗？
   • 进阶回答：可以从共享产品试点开始，但要限制范围和投入；若需求差异持续扩大，就退回各自实现。
2. 问题：如何衡量内部平台价值？
   • 考点：结果指标。
   • 回答思路：从交付、恢复、认知、风险和成本回答。
   • 详细答案：比较接入前后的首次交付时间、变更前置时间、恢复时间、开发者认知负荷、合规覆盖和单位工作负载成本，同时看自愿采用、弃用和支持工单。机器数和接口数只是活动，不是价值。
   • 进阶追问：采用率百分之百是否最好？
   • 进阶回答：不一定；若靠强制、用户绕路或大量人工支持获得，可能掩盖低价值，必须结合替代路径和用户结果解释。
3. 问题：怎样避免平台大一统？
   • 考点：边界与退出。
   • 回答思路：强调薄平台、推荐路径、例外和退役。
   • 详细答案：平台只吸收稳定共性，业务差异留给流对齐团队；提供组合式推荐路径和限时例外，接口版本化并允许能力退役。每项能力要有用户、成本、服务目标和停止规则，不能无限吞并。
   • 进阶追问：平台和中台有什么关系？
   • 进阶回答：名称不重要；只要缺少明确用户、自助产品、责任和价值反馈，所谓中台也可能只是集中式共享系统。

1.8 技术债本金、利息、风险、预算与停止规则

技术债不是所有“不完美代码”，而是为了提前获得业务价值而选择的未来额外成本。本金是恢复到目标状态的一次性投入；利息是每个周期因债务产生的额外变更、故障、支持和认知成本；风险是债务触发严重损失的概率与影响；机会成本是偿债占用的产品能力。只有能写清债务对象、借债理由、受益窗口、所有者、利息信号、到期条件和退出方案，才是可治理负债，否则只是模糊抱怨。

偿还优先级不能只按代码难看程度排序。先过硬门禁：资金、安全、合规、不可恢复数据和单点故障超过阈值立即处理；其余可用 优先分 = 周期利息 x 预计剩余周期 + 风险敞口 - 偿还本金 做敏感性比较。预算可以采用固定容量加事件触发：每个周期预留基础偿债比例，高风险阈值、迁移窗口或平台变更触发额外预算。停止规则同样重要：若连续投入后利息未下降、目标边界已变化、替代系统即将退役，或继续偿还超过重建/退出成本，就暂停并重新决策。

sequenceDiagram
    participant 产 as 产品与业务责任人
    participant 债 as 技术债账本
    participant 工 as 工程团队
    participant 风 as 安全/运行/成本评审
    产->>债: 登记借债收益窗口与到期条件
    工->>债: 估算本金、周期利息和偿还路径
    风->>债: 标记硬风险与不可接受阈值
    债->>产: 给出维持、分期偿还、重建或退出候选
    alt 硬风险越界
        产->>工: 立即止损并优先偿还
    else 经济性偿还
        产->>工: 按预算分期并监测利息
    end
    alt 利息未下降或目标已失效
        工-->>债: 触发停止规则并重新评审
    else 收益达到验收
        工-->>债: 关闭债务并保留验证证据
    end

图解读：业务说明借债收益，工程估算经济性，风险角色守硬边界；偿还不是工程单方决定；失败分支允许停止无效投入；结论是技术债应像投资组合一样有预算、收益和退出。

数据演绎 8：偿还还是继续付利息

E3（演练证据）：某共享数据库债务偿还本金 480 人时；每月因跨团队联调多花 55 人时，预计系统还运行 18 个月，风险事件期望损失折算 160 人时。拖延总成本为 55 x 18 + 160 = 1150 人时，净偿还价值为 1150 - 480 = 670 人时，值得启动。若系统 4 个月后退役，则拖延成本 55 x 4 + 160 = 380 人时，小于本金，应优先加写权限、审计和恢复护栏，避免完整重构。

热门面试题

1. 问题：怎样区分技术债和普通复杂度？
   • 考点：有意借债与可治理成本。
   • 回答思路：看替代状态、提前收益和额外利息。
   • 详细答案：技术债应有一个可说明的目标状态，并且当前选择曾换取时间或价值，却持续产生可测额外成本；业务本身必要的复杂规则不是债。无法说明本金、利息、所有者和到期条件的“债”不能进入优先级模型。
   • 进阶追问：历史遗留但没人有意选择呢？
   • 进阶回答：仍可作为无主负债登记，但要补当前影响和责任，不能虚构当年动机。
2. 问题：技术债偿还优先级如何排？
   • 考点：硬风险与经济模型。
   • 回答思路：先硬门禁，再比较利息、风险、本金和机会成本。
   • 详细答案：资金、安全、合规和不可恢复风险先处理；其余比较剩余生命周期内的累计利息与风险是否超过本金，再结合业务窗口和可逆性排序。分数用于暴露假设，不代替责任人批准。
   • 进阶追问：高利息低本金一定先还吗？
   • 进阶回答：通常优先，但仍要看迁移冲突、系统寿命和业务窗口；即将退役时加护栏可能更经济。
3. 问题：为什么技术债需要停止规则？
   • 考点：避免偿债项目失控。
   • 回答思路：从目标变化、收益验证和替代路径回答。
   • 详细答案：偿债也会形成沉没成本。若投入后变更时间和事故没有下降、目标架构已经改变、依赖无法迁移或系统即将退役，应暂停并比较重建、隔离或退出，不能因为“已经做了一半”无限追加。
   • 进阶追问：停止后债务怎么办？
   • 进阶回答：保留最小护栏、风险接受、到期日和观测，待触发条件变化再重开，而不是从账本删除。

1.9 迁移门禁、反模式、线上排障与恢复闭环

迁移门禁不是“测试通过”一项，而是业务正确性、成本、安全、可观测性和恢复能力的联合准入。业务门禁检查权威事实与不变量；成本门禁比较单位请求、双运行和长期维护成本；安全门禁检查最小权限、敏感数据、租户隔离与审计；可观测性门禁要求版本、业务键、差异、积压和用户结果可关联；恢复门禁必须真实演练回切、回放、补偿和人工接管。任何硬门禁失败都冻结扩面，不能用其他维度高分抵消。

典型反例有四类。过度拆分让一次变更穿越大量服务；分布式单体表现为同步调用链、共同发布和联合故障；共享数据库让服务绕过所有者写表；平台大一统把所有团队锁进最低公分母。排障时先冻结发布和迁移开关，按业务键确定权威事实，再关联版本、路由、契约、数据位点与依赖；识别是入口漏路由、兼容破坏、投影积压、旧写者未栅栏还是平台控制面失灵。恢复以用户事实和差异清零为终点，指标恢复只是必要条件。

sequenceDiagram
    participant 发 as 发布/迁移控制面
    participant 门 as 联合门禁
    participant 新 as 新路径
    participant 旧 as 旧路径
    participant 证 as 业务证据与观测
    participant 应 as 应急与恢复负责人
    发->>门: 申请扩大流量与版本范围
    门->>证: 查询正确性、成本、安全、观测、恢复证据
    证-->>门: 阈值、差异与未知项
    alt 任一硬门禁失败
        门-->>发: 拒绝扩面并冻结变更
        应->>旧: 校验回切容量和兼容
        发->>旧: 恢复权威流量
        应->>证: 对账、回放、补偿与观察
    else 全部门禁通过
        门-->>发: 限定范围和观察窗批准
        发->>新: 扩大流量
        新-->>证: 返回版本、业务键与结果
    end

图解读：联合门禁先查证据再放量；任何硬失败都冻结扩面并验证旧路径容量；恢复包含对账和观察而非只切路由；结论是迁移控制面与观测面同时失灵时必须进入保守模式。

数据演绎 9：联合门禁不能用平均分放行

E3（演练证据）：某迁移用五项各 20 分评分，正确性 20、成本 18、安全 8、可观测性 18、恢复 16，总分 80，看似通过。安全低分来自新库写账号能访问全部租户，这是不可抵消硬约束；即使总分提高到 95 也不能放量。修复权限后还要验证审计和回滚账号，说明门禁应先做布尔准入，再对可交换偏好评分。

热门面试题

1. 问题：一次架构迁移放量前最少检查什么？
   • 考点：联合门禁。
   • 回答思路：按正确性、成本、安全、观测和恢复回答。
   • 详细答案：确认权威事实和不变量可校验，单位成本与双运行预算可承受，权限和租户边界正确，版本、业务键、差异和积压可关联，并真实演练回切、回放、补偿和人工接管。硬门禁失败直接停止。
   • 进阶追问：性能压测通过够吗？
   • 进阶回答：不够；它只覆盖部分运行容量，不能证明数据、兼容、安全和恢复正确。
2. 问题：如何识别分布式单体？
   • 考点：物理分散与逻辑耦合。
   • 回答思路：看共同变更、同步链、数据库和故障命运。
   • 详细答案：若一次需求要同时改多个服务，发布必须锁步，调用链依赖同步成功，多个服务共享表并互相越权，任一下游失败都使整体不可用，就是分布式单体。服务数量多不代表边界清晰。
   • 进阶追问：怎样修？
   • 进阶回答：先恢复单写者和本地不变量，缩短同步链；无法形成独立收益的服务合并部署，保留内部模块边界。
3. 问题：迁移事故排障为什么先找权威事实？
   • 考点：证据优先级。
   • 回答思路：区分技术信号和业务结果。
   • 详细答案：错误率和延迟只能说明路径状态，不能判断订单、库存或资金是否正确。先按业务键定位权威记录和版本，再沿路由、契约、投影和位点查差异，才能决定回切、补偿或向前修复，避免恢复错误副本。
   • 进阶追问：监控也失灵怎么办？
   • 进阶回答：冻结自动晋级，使用审计流水、数据库记录、外部回执和人工抽样建立最低证据面，平台恢复后补查失明窗口。

1.10 订单增长：从模块化单体到事件化读模型的完整演进线

订单增长演进线以业务损失而非流量数字开场。阶段一在一个模块化单体中明确交易、库存、支付、履约模块及数据访问规则，利用本地事务保护订单创建和请求唯一性；此时团队小、状态仍变化，不拆。阶段二订单读取与报表拖慢写路径，先建立同库只读视图或可重建 CQRS（命令查询职责分离）读模型，并保留权威查询。阶段三促销使库存写热点、订单与履约发布节奏分化，先垂直切出有单写者和恢复责任的库存边界，再让已发生的订单事实事件化传播，避免把扣减裁决异步外包。

阶段四通过 Strangler Fig Pattern（绞杀者模式）让新订单入口接管小流量：旧路径权威、影子计算、同键双运行、按租户灰度，数据库通过 CDC（变更数据捕获）投影并做不变量校验。只有库存不超卖、订单状态合法、单位成本、权限、差异年龄和回切演练全部过门禁，才提升新路径为权威。停止条件是跨服务共同变更率和联合故障率上升、读模型新鲜度不能满足业务、或团队值班承载不足；此时保持当前边界，不继续拆支付或履约，必要时合并无独立收益的薄服务。

flowchart LR
    A["模块化单体\n交易/库存/支付/履约模块"] --> B["订单查询读模型\n权威写保持不变"]
    B --> C["库存热点边界\n单写者与局部不变量"]
    C --> D["订单事实事件化\n副作用可恢复"]
    D --> E["新订单入口影子与双运行"]
    E --> F["按租户灰度和联合门禁"]
    F --> G["稳定边界与平台复用候选"]
    F -->|"共同变更/联合故障反弹"| H["停止拆分或合并薄服务"]

图解读：读模型先于写边界拆分，库存因热点和不变量先独立，事件只传播事实；失败箭头明确停止拆分；结论是订单增长不自动推导全量微服务化。

数据演绎 10：订单增长不等于服务数量线性增长

E3（演练证据）：日订单从 20 万增至 200 万，峰值从 300 次每秒增至 2,400 次每秒；库存写占 65% 峰值资源，报表占 55% 数据库读取，而支付与履约峰值不足整体 15%。先拆库存并隔离读模型，可针对约 80% 的资源矛盾；若再拆 12 个低流量服务，每月增加约 120 人时运行成本但容量收益不足 5%，应触发停止规则。规模增长需要定位资源和变化热点，不是按十倍流量配十倍服务。

热门面试题

1. 问题：订单量增长时为什么先做读模型而非拆全部服务？
   • 考点：最小有效演进。
   • 回答思路：从瓶颈位置和可逆性回答。
   • 详细答案：若主要矛盾是组合查询和报表拖慢权威写库，读模型能在不改变写所有权的前提下隔离负载，成本和回退都更低。只有写热点、变化和故障边界也独立时，才继续拆写服务。
   • 进阶追问：读模型延迟怎么办？
   • 进阶回答：声明差异年龄，关键确认回查权威源；超过阈值降级查询或暂停依赖该投影的动作。
2. 问题：订单事件化时哪些动作不能异步裁决？
   • 考点：事实与命令。
   • 回答思路：用库存扣减和支付确认举例。
   • 详细答案：库存是否允许承诺、支付是否已有渠道成功证据等必须由权威边界裁决；事件只能传播“已预占”“已确认”等事实。通知、索引和可恢复履约准备可以异步，但要有幂等、积压与回放。
   • 进阶追问：订单创建能否先成功再慢慢扣库存？
   • 进阶回答：可以返回“已受理待确认”，不能伪装为已承诺；状态机和用户文案必须表达不确定性。
3. 问题：订单演进线何时停止拆分？
   • 考点：收益成本与团队能力。
   • 回答思路：看热点覆盖、共同变更、联合故障和值班。
   • 详细答案：当主要热点已隔离，剩余模块没有独立扩容或发布收益，继续拆分导致共同变更和同步链增加，或团队无法独立值班，就冻结服务数量。优先修契约和自动化，薄服务可回迁。
   • 进阶追问：停止后如何支持继续增长？
   • 进阶回答：可通过分区、缓存、批处理、队列保护和整体扩容解决运行规模，不必把所有容量问题都转成业务服务拆分。

1.11 第三方物流接入：从适配器到接入产品的完整演进线

第三方物流接入的复杂度来自外部契约差异和失败责任，不来自接口数量本身。阶段一只有一两家承运商时，在履约模块内建立 ACL（防腐层）适配外部状态、认证、时区和错误语义，保留原始报文与内部标准模型；此时不建平台。阶段二承运商增加，先抽稳定的接入模板、契约测试、沙箱回放和凭证隔离，仍由履约团队拥有业务规则。阶段三多个业务线都重复做签名、限流、回调验真、轨迹归一和故障切换，才把非差异化接入路径产品化，由平台团队提供自助注册、版本和观测。

迁移采用按承运商的 Strangler Fig Pattern（绞杀者模式）：新平台先影子解析历史报文，双运行比较标准事件，再灰度接管低风险查询，最后接管下单和取消等真实副作用。每个合作方独立版本、开关、预算和回滚，不按全局比例混合。平台不拥有承运商选择、运价策略和履约承诺，这些继续属于业务团队；若某合作方高度定制且复用低，允许留在专用适配器。停止平台化条件是新增接入仍需大量平台改码、用户只能提工单、共性不足或维护成本超过复用收益。

sequenceDiagram
    participant 业 as 履约业务
    participant 适 as ACL（防腐层）适配器
    participant 平 as 物流接入平台
    participant 商 as 第三方承运商
    participant 校 as 契约回放与差异校验
    业->>适: 内部标准命令与业务键
    适->>商: 合作方版本请求
    商-->>适: 外部状态/错误/回调
    适-->>业: 内部标准事实
    适->>平: 复制历史报文做影子解析
    平-->>校: 候选标准事实
    适-->>校: 当前权威标准事实
    alt 差异未清或副作用不可回退
        校-->>业: 保持专用适配器并停止扩面
    else 单合作方门禁通过
        业->>平: 灰度该合作方真实请求
        平->>商: 带版本和幂等键调用
    end

图解读：防腐层先保护内部模型，平台通过历史报文影子验证；灰度单位是合作方而非随机请求；失败时允许专用适配继续存在；结论是平台化吸收稳定共性，不吞并履约决策。

数据演绎 11：接入数量不是平台化充分条件

E3（演练证据）：已有 12 家承运商，其中 9 家共享约 80% 的签名、回调和轨迹归一流程，3 家各有复杂专用规则。通用接入每家平均 120 人时，平台化首期 600 人时、后续每家 30 人时，则 9 家总成本由 9 x 120 = 1080 人时降为 600 + 9 x 30 = 870 人时，仅节省 210 人时；若计入月维护 40 人时，一年反而增加。应先用模板验证，等新增频率或多业务线复用提高再平台化，三家专用规则不强塞公共模型。

热门面试题

1. 问题：第三方物流接入何时从适配器演进为平台？
   • 考点：稳定共性与多用户复用。
   • 回答思路：从合作方数量、业务线、频率和产品能力回答。
   • 详细答案：只有多个业务线反复解决同类认证、契约、回调、轨迹和观测问题，且标准接口已通过多家验证，平台投资才可能成立。单纯接口多但每家高度定制，应继续使用受控适配器。
   • 进阶追问：先做统一大模型行吗？
   • 进阶回答：不应；先保留外部原始语义与内部最小标准，无法稳定归一的字段通过扩展或专用模型隔离。
2. 问题：物流平台灰度为什么按合作方分组？
   • 考点：契约和故障域。
   • 回答思路：说明版本、凭证和回滚的一致单位。
   • 详细答案：同一合作方共享接口版本、认证、限额和错误语义，随机请求灰度会让同一运单跨两套状态机。按合作方与业务能力分组，才能保持可比样本、独立回滚和责任清晰。
   • 进阶追问：同一合作方流量很大怎么办？
   • 进阶回答：再按租户、仓或明确业务键稳定分片，但必须保证同一运单生命周期固定落在同一路径。
3. 问题：物流平台不应该拥有哪些能力？
   • 考点：平台产品边界。
   • 回答思路：区分接入共性和业务差异。
   • 详细答案：平台可拥有认证、契约、限流、回调验真、轨迹标准化和技术观测；承运商选择、运价、时效承诺、赔付和履约策略仍由业务团队负责，避免平台变成大一统业务中台。
   • 进阶追问：边界争议怎么裁决？
   • 进阶回答：看规则变化原因、最终业务损失和用户是谁；频繁随业务策略变化的内容留在流对齐团队。

1.12 IoT（物联网）报警风暴：从单链路止血到治理能力的完整演进线

IoT（物联网）报警风暴演进必须先保护“高危报警不被吞没”的不变量。阶段一在现有应用内分离采集、规则判断和通知模块，设置有界队列、优先级、租户配额与人工应急开关；低优先级重复通知可抑制，高危事件走独立容量，原始事件保留以便重放。此时故障模型和规则仍快速变化，不急于服务化。阶段二设备与规则规模扩大，规则计算成为独立热点，才垂直切出计算边界；事件化传播已发生的报警事实，通知渠道异步消费并保持幂等。

阶段三为查询和运营建立 CQRS（命令查询职责分离）报警读模型，按设备、区域和根因签名聚合，但权威原始事件与高危状态不由投影替代。新规则引擎通过影子流量回放原始事件，双运行比较漏报、误报、延迟和资源，再按租户灰度。多个产品团队若重复需要规则发布、压测、配额和回放，才抽成报警治理平台；平台提供安全默认和自助能力，不统一业务风险规则。停止条件包括高危漏报非零、观测盲区、恢复时间超过窗口、平台强制统一导致业务规则失真，或降噪收益低于复杂度。

sequenceDiagram
    participant 设 as IoT（物联网）设备入口
    participant 旧 as 旧规则路径
    participant 新 as 新规则路径
    participant 原 as 原始事件存储
    participant 校 as 漏报/误报/延迟校验
    participant 通 as 分级通知与人工升级
    设->>原: 保存事件、租户、设备与规则版本
    原->>旧: 权威规则计算
    原->>新: 影子回放同一事件
    旧-->>校: 权威报警事实
    新-->>校: 候选报警事实
    alt 高危漏报或观察盲区
        校-->>通: 保持旧路径并触发人工核验
    else 差异在分级预算内
        校-->>新: 按租户灰度权威计算
        新->>通: 高危独立通道/低危聚合抑制
    end
    通-->>原: 回写送达、升级与恢复结果

图解读：原始事件先持久化，新旧规则使用同一输入；高危漏报直接阻断灰度；通知结果回到证据链；结论是报警平台先保障可回放和高危独立容量，再谈降噪与复用。

数据演绎 12：降噪率不能掩盖高危漏报

E3（演练证据）：一分钟进入 120 万条设备事件，其中 90% 为同根因低危重复，聚合后通知从 108 万降至 1.8 万，降噪率约 98.33%。但高危事件 600 条，新规则漏掉 1 条，高危召回率约 99.83%。若安全门禁要求高危漏报为零，则总体降噪再高也不能放量；应保持旧高危路径、回放漏报样本并修复规则。队列恢复还要按净消费能力计算，不能以通知下降推断采集已恢复。

热门面试题

1. 问题：IoT（物联网）报警风暴为什么先模块化而非立刻拆服务？
   • 考点：问题不确定性和最小止血。
   • 回答思路：从规则变化、队列保护和可逆性回答。
   • 详细答案：风暴早期最急的是有界队列、优先级、配额、原始事件和应急开关，这些可在应用内快速建立；若故障模型尚未稳定，过早服务化会固化错误边界。等规则计算形成独立热点和责任后再拆。
   • 进阶追问：单体会不会一起被拖垮？
   • 进阶回答：先用线程池、队列、资源配额和高危独立通道隔离；这些仍不足且有真实故障证据时，物理拆分才有收益。
2. 问题：报警规则引擎如何安全迁移？
   • 考点：同输入双运行与风险分级。
   • 回答思路：从原始事件、影子回放、差异和租户灰度回答。
   • 详细答案：保存原始事件与规则版本，新旧引擎同输入计算，按高危漏报、误报、延迟和资源分类差异；高危漏报零容忍，低危差异按预算。通过后按租户稳定灰度，并保留旧路径和人工核验。
   • 进阶追问：为什么不随机按事件灰度？
   • 进阶回答：同一设备和根因链会跨两套状态，破坏抑制窗口和样本可比性；应按租户、设备组或规则版本稳定分组。
3. 问题：报警治理平台的边界在哪里？
   • 考点：平台共性与业务风险。
   • 回答思路：区分交付治理和风险规则。
   • 详细答案：平台提供规则版本、发布、影子回放、压测、配额、审计和通知通道；危险等级、业务阈值、升级责任由各产品团队拥有。平台统一安全默认，但不能用一个公共规则模型覆盖所有业务。
   • 进阶追问：何时停止平台化？
   • 进阶回答：当每个用户都需平台团队改码、采用靠强制、高危语义被削平或维护成本超过复用收益时，收缩为工具和模板。

1.13 架构评审、项目话术与“不拆”的设计权衡

架构评审要审的是问题、证据、迁移和退出，而不是图画得是否复杂。会前要求目标、非目标、业务不变量、量级、候选方案、维持现状、事实等级、失败路径、联合门禁、技术债和停止规则齐全；会中先淘汰违反硬约束的候选，再攻击推荐项，检查过度拆分、分布式单体、共享数据库和平台大一统反例；会后把条件批准、所有者、截止日和自动失效写入决策记录。评审应允许结论是“不拆”“暂缓”或“合并”，否则只是为既定方案背书。

项目表达按“背景约束 -> 现状证据 -> 候选取舍 -> 渐进迁移 -> 失败恢复 -> 结果边界 -> 下一触发器”组织。WMS（仓储管理系统）库存防超卖强调权威扣减和对账；支付资金一致性强调未知态、唯一账务事实和渠道核验；异步任务与 Runner（执行器）调度强调租约、栅栏、检查点和副作用幂等；跨境物流强调外部契约与防腐；IoT（物联网）强调高危不漏和风暴恢复。没有生产数字时明确标 E2（已有材料映射）与 E3（演练证据），列出 E0（待核对）项，不把候选设计冒充上线成果。

flowchart TD
    A["背景、约束与事实等级"] --> B["现状瓶颈和维持现状候选"]
    B --> C["拆分/不拆/合并/平台化候选"]
    C --> D["硬门禁与反例攻击"]
    D --> E{"证据足以承担迁移吗"}
    E -->|"否"| F["暂缓、补证或保持模块化"]
    E -->|"是"| G["影子、双运行、灰度和回滚"]
    G --> H["业务结果、技术债和停止规则"]
    H --> I["运行反馈触发复审"]

图解读：维持现状与“不拆”是正式候选；硬门禁先于加权比较；迁移后继续观察债务和停止条件；结论是架构评审是持续证伪，不是一次性批准。

数据演绎 13：不拆方案也必须可复算

E3（演练证据）：WMS（仓储管理系统）某模块每月 30 次变更，只有 3 次因整体发布等待各 1 小时；拆分预计节省 3 人时，却新增契约、流水线和值班 28 人时。报表慢查询每月造成约 12 人时故障影响，可通过读模型和资源隔离以 8 人时/月维护成本解决。选择“不拆写服务、只隔离读模型”的净成本约 8 人时，明显低于服务化 28 人时；复审触发器设为独立发布等待超过 25 人时/月或故障损失超过 20 人时/月。

热门面试题

1. 问题：架构评审如何避免只为既定方案背书？
   • 考点：候选完整性与反权威。
   • 回答思路：要求维持现状、反例、异议和停止规则。
   • 详细答案：会前必须包含维持现状与替代项，证据分级；会中由独立质疑者攻击推荐方案，硬约束角色有否决权；结论允许拒绝、暂缓和不拆。异议、条件、所有者与逾期失效必须记录。
   • 进阶追问：时间很紧怎么办？
   • 进阶回答：缩小首次范围并提高可逆性，不能删除正确性、安全和恢复门禁；未决风险由有权限者明确接受。
2. 问题：如何在项目话术中讲“我决定不拆”？
   • 考点：证据化权衡。
   • 回答思路：比较真实瓶颈、候选成本和复审触发器。
   • 详细答案：先说明发布、容量、故障和组织数据，再比较模块化优化、读模型、服务拆分的收益成本；若拆分净收益为负，就选择更可逆的局部治理，并给独立发布等待、热点比例或故障损失设复审阈值。
   • 进阶追问：会不会显得缺少架构能力？
   • 进阶回答：不会；能拒绝无收益复杂度、保留演进路径并用指标复审，正是架构判断而非技术堆叠。
3. 问题：没有真实生产数字如何讲架构成果？
   • 考点：事实等级和诚实边界。
   • 回答思路：区分 E1（源码与可复现证据）、E2（已有材料映射）、E3（演练证据）、E0（待核对）。
   • 详细答案：只把本地可复现内容说成 E1（源码与可复现证据），简历关联说成 E2（已有材料映射），容量与收益算例公开假设并标 E3（演练证据），缺失日志、配置和线上指标列为 E0（待核对）。重点讲决策和验证方法，不编造上线比例。
   • 进阶追问：面试官追问提升多少怎么办？
   • 进阶回答：明确没有可核验生产数字，给出演练公式、需要补的分母与采集计划，并说明哪些结论会因数据变化而翻转。

知识小节收口（非知识型）

以上 13 个知识型三级标题各含一张图、一张表、一组可复算数据演绎和三道六字段题，共 39 道章节题。以下综合题用于 3 至 5 分钟架构口述，不计入知识型小节。

2. 综合面试题库

1. 问题（综合题 01）：请完整说明如何用分治思想做架构设计，并判断何时不拆。

   • 口述答案：我会先把分治理解成降低问题耦合，而不是增加服务数量。第一步明确业务目标、不可接受损失和事实等级，再列出认知、变化、运行、故障和组织五种规模；代码行数只作弱信号。第二步沿业务事件和不变量分组，要求每个候选子问题能说明输入、输出、权威事实、失败语义、所有者和恢复方式。第三步判断耦合：若两个候选必须同一事务提交、总是共同变化、共享同一故障命运且由同一团队值班，它们即使目录不同也不适合物理拆开；先用模块接口、依赖检查和数据权限形成模块化单体。第四步为服务化列收益与成本，收益包括独立发布、扩容、隔离和合规，成本包括网络、契约、跨域一致性、流水线、观测和值班；只有连续多个周期净收益为正，才选择最有证据的一块小范围拆分。第五步把停止规则写进决策，例如共同变更率、同步链长度、单位成本、联合故障和值班负担越界就冻结新增服务，必要时合并回迁。最后用影子、灰度、回滚和业务对账验证，结论允许“不拆”“暂缓”或“只隔离读模型”。这样分治解决的是团队可理解、可变更和可恢复的问题，而不是把单体复杂度搬到网络上。评审记录还要保存假设来源、适用范围、复审日期和风险接受人；上线后按同一口径连续观察，若收益只来自短期样本或故障转移到别处，就撤销原结论并重画边界。 实施前我还会让非方案作者复算收益与成本，避免边界结论只反映方案作者偏好；实施后用相同分母对照基线，确保所谓局部优化没有把等待和风险转移给下游团队。
   • 追问一：大代码库一定要拆吗？
   • 直答一：不一定；先看模块化能否收敛构建、测试、所有权和变化范围，再看独立运行收益。
   • 追问二：拆错了是否说明架构失败？
   • 直答二：发现指标恶化后及时合并是正常演进，真正失败是因沉没成本拒绝纠错。
   • 追问三：最关键的停止指标是什么？
   • 直答三：没有单一指标；共同变更、联合故障、单位成本和值班负担应联合判断。
   • 详细章节：分治与停止条件

2. 问题（综合题 02）：如何选择模块化单体、垂直切分、服务拆分、事件化、CQRS（命令查询职责分离）读模型和平台抽取？

   • 口述答案：我把这些形态看成可组合的连续谱，不把它们排成技术等级。业务早期边界和团队都在变化时，模块化单体最经济：同进程、本地事务和一次发布降低协调成本，但用接口、依赖方向和单写者保护未来可拆性。垂直切分先按端到端业务能力重组代码和责任，让交易、库存、履约不再按控制层、服务层、数据层横向交接。只有某个边界具备独立变化、容量热点、故障隔离或合规收益，且团队能独立发布和值班时，才提升为服务。事件化用于传播已经发生的事实和可恢复副作用，不能把库存是否可扣或支付是否成功这类权威裁决广播出去。若组合查询和报表压迫权威写模型，而且用户能接受明确陈旧窗口，就建立可重建的 CQRS（命令查询职责分离）读模型，并保留权威回查、差异年龄和重建路径。平台抽取放在更后面：多个团队反复遭遇同类非差异化摩擦、接口经过多个场景验证、能形成自助产品和明确服务目标时才成立。每一步都写回迁条件；若只有一个用户、规则剧烈变化、共同发布仍很多或运行成本大于收益，就停在当前阶段。这种选择方式让架构随约束演进，而不是提前支付所有分布式和平台成本。我还会为每次跃迁设置单独观察窗，只比较它针对的原始瓶颈，防止读模型降低数据库压力却把事件恢复成本藏起来，也防止平台把产品团队节省的时间转成平台团队的工单负担。 各阶段的证据必须独立归因：读负载、写热点、发布等待和平台采用分别验收；一项改善不能替另一项背书，任一新增责任也必须有明确所有者和退出日期。
   • 追问一：读写分离就是 CQRS（命令查询职责分离）吗？
   • 直答一：不是；只读副本仍共享模型，命令与查询模型职责和形态明确分开才是该决策。
   • 追问二：事件越多解耦越好吗？
   • 直答二：不是；事件会增加重复、乱序、积压和回放，只有接收方可异步恢复时才有价值。
   • 追问三：平台能否和服务拆分同时做？
   • 直答三：可以试点共性工具，但不应在业务边界未验证时同步建设大平台，否则两类不确定性相互放大。
   • 详细章节：演进连续谱

3. 问题（综合题 03）：请设计一次使用 Strangler Fig Pattern（绞杀者模式）和 Branch by Abstraction（抽象分支）的迁移。

   • 口述答案：我会先确定迁移控制点和可逆边界。若替换发生在同一代码库内部，先用 Branch by Abstraction（抽象分支）把散落调用收敛到稳定业务接口，旧实现继续权威运行，新实现挂在抽象后；若要跨系统按能力接管入口，再用 Strangler Fig Pattern（绞杀者模式）按租户、仓或合作方逐段路由。第二步建立稳定业务键、版本标识和迁移账本，让同一生命周期始终落在同一路径。第三步先做影子流量，新路径隔离支付、物流等真实副作用，只验证解析、纯计算和容量；再做同键双运行，由旧路径权威，新路径输出进入差异校验，按不变量、金额、状态和高价值样本分类。第四步进入小流量灰度，新路径开始产生真实事实，联合检查正确性、成本、安全、观测和恢复，任一硬门禁失败即冻结扩面。第五步执行回滚时不只退制品，还要停止新增新路径事实，处理消息、中间态与外部副作用，按权威源对账。最后只有旧调用清零、数据和消费者完成迁移、回切观察窗结束，才删除旧实现和临时抽象；若抽象不再隔离真实变化也一并简化。整个过程要求旧路径容量可用、开关有权限审计、差异可追溯，避免永久双运行。每次放量还要记录样本是否覆盖高峰、低频高价值和异常分支，不能因平均差异低就跳过长尾；控制面故障时默认停在当前比例，禁止自动晋级。 迁移结束后还要删除临时开关、重复告警和双运行资源，撤销旧路径权限并更新值班手册；否则技术切换虽完成，组织和成本仍处于永久迁移态。
   • 追问一：影子流量能验证支付扣款吗？
   • 直答一：不能触达真实扣款；只能验证到提交前、使用沙箱或比较构造请求，真实副作用留给受控灰度。
   • 追问二：灰度为何不能完全随机？
   • 直答二：有状态业务应按稳定业务键分组，避免同一订单生命周期跨新旧状态机。
   • 追问三：何时删除迁移抽象？
   • 直答三：旧实现、旧消费者和回退窗口都退出，且抽象不再保护独立变化时删除。
   • 详细章节：渐进迁移模式

4. 问题（综合题 04）：数据库拆分时如何避免双写分叉，并完成 CDC（变更数据捕获）切换？

   • 口述答案：我先拆所有权而不是先搬表。明确哪个边界解释字段、维护不变量、接受写命令和负责修复，收紧数据库账号，禁止新旁路写；切换前旧库保持唯一权威。然后做全量基线，把原始事实按稳定业务键回放到新库，记录版本和检查点；增量通过 CDC（变更数据捕获）读取旧库已提交日志，按业务键和版本幂等投影，避免应用同时对两个权威库提交。校验分三层：行级抽样检查字段与版本，聚合层核对数量、金额和状态分布，业务层验证库存守恒、资金平衡和状态合法性。还要压测净恢复能力，证明积压能在日志保留窗口内追平，进程重启后可从检查点继续。接着开放影子读，同一查询比较新旧语义；若差异可解释且门禁满足，选择低风险租户做新库权威写，并给旧写者设置栅栏版本，防止切换后继续越权。失败时先冻结扩面，若旧路径兼容且容量足够则回切，否则向前修复并提高人工对账。最后迁移备份、恢复、修复任务、告警、权限和值班，确认旁路写为零并经过最长业务周期，旧库才转只读和退役。应用双写只能作为限时、可检测、可修复的迁移手段，绝不能成为稳态。切换前还要模拟日志中断、模式升级和消费者重启，核对位点不会越过保留期；切换后保留旧库只读观察窗，任何高价值差异都能定位到原始提交和修复责任人。 数据所有者还需签署切换后的修复流程，确保差异由谁判定、谁回放、何时升级人工都可执行；若只有迁移脚本而没有运行责任，权威切换仍不完整。
   • 追问一：为什么行数一致不够？
   • 直答一：重复、金额偏差、非法状态和版本倒退都可能保持行数一致。
   • 追问二：CDC（变更数据捕获）会丢顺序吗？
   • 直答二：跨分区或并行消费可能改变观察顺序，消费者要按业务键版本处理并拒绝倒退。
   • 追问三：切换点如何防旧写者？
   • 直答三：用写权限撤销、栅栏版本和入口开关联合作为硬门禁，并监控拒绝记录。
   • 详细章节：数据库拆分与权威切换

5. 问题（综合题 05）：如何设计契约兼容和版本退役，避免永久双版本？

   • 口述答案：我先把契约兼容拆成语法、语义、时间和失败四层。模式检查只能证明字段可解析，还要验证状态含义、默认值、顺序和延迟，以及错误码、重试与幂等是否变化。迁移采用 Expand and Contract（扩展与收缩）：生产者先发布兼容扩展，例如增加可选字段或新端点，旧语义继续有效；随后逐个升级消费者，用契约测试、真实调用和业务结果观测采用；只有消费者都能处理新语义后，生产者才开始依赖新字段。迁移账本列出所有消费者、负责人、版本、最后使用时间、最长业务周期、历史数据保留和截止日，未知消费者会阻断破坏性发布。低频关账、离线回放和灾备路径不能因短窗流量为零而忽略，必须实际演练。对于无法同步升级的外部物流伙伴，提供版本化防腐适配，按合作方灰度并保留商业退出方案。收缩前要确认旧调用清零、历史消息不再回放旧格式、保留期结束、错误预算稳定，并让责任人签署；随后删除旧字段、适配、告警和文档。逾期消费者要升级责任或执行限期策略，不能默认平台永久兼容。这样兼容是有时间边界的迁移能力，而不是把所有历史设计变成永久技术债。我还会把契约样例与业务场景绑定，保存新旧版本对同一输入的结果；若字段兼容但金额、状态或重试行为变化，语义门禁仍会拒绝发布，并把解除条件回写到账本。 对公共契约还要公布弃用节奏、测试样例和支持渠道，让消费者能在截止日前自助验证；生产者不得静默改变默认值，也不能把未迁移风险留给事故现场处理。
   • 追问一：新增字段一定向后兼容吗？
   • 直答一：不一定；旧消费者可能拒绝未知字段，新生产者也可能错误地立即依赖它。
   • 追问二：采用率 99% 能下线吗？
   • 直答二：不能单看比例；剩余可能是低频高价值或灾备消费者，需逐个确认。
   • 追问三：外部伙伴拒绝升级怎么办？
   • 直答三：隔离适配并核算商业价值，给出收费、限期或终止，而不是污染核心模型。
   • 详细章节：契约版本迁移

6. 问题（综合题 06）：系统演进时如何同步设计组织和团队责任？

   • 口述答案：我不会把组织调整放到系统拆完之后，因为没有责任迁移的服务只会制造跨团队排队。先沿价值流识别谁对业务结果负责，让 Stream-aligned Team（流对齐团队）拥有从需求、代码、数据到发布、值班和恢复的端到端责任；对于多个团队共同需要的交付能力，由 Platform Team（平台团队）经营自助产品；阶段性能力缺口由 Enabling Team（赋能团队）限时结对和铺路；真正需要深专业知识的算法或协议放给 Complicated-subsystem Team（复杂子系统团队），通过稳定接口协作。迁移顺序是先设单一责任人和临时跨职能小组，验证业务边界，再逐步转移仓库权限、数据库账号、告警、预算、运行手册和轮值。双运行期原团队可以护航，但必须有截止日和退出验收，否则会形成两套名义所有者。团队服务数量也要按认知与运行负荷复审：若大量服务共同发布、告警无人理解或恢复总需多团队会战，冻结新增服务并按变化拓扑合并。铺路团队的成功是产品团队能独立完成任务后退出；若长期代操作，应把重复摩擦转为平台能力或重画责任。最终用变更等待、独立发布、事故升级路径和团队认知负荷验证组织边界，而不是用组织图是否整齐判断。组织切换还要安排演练：新团队独立完成一次发布、一次回退和一次业务对账，原团队只观察不代操作；若无法完成，责任尚未真正迁移，系统切流也应暂停。
   • 追问一：应该先改组织还是先拆系统？
   • 直答一：小步并行，先用临时端到端责任单元验证，再迁移系统和正式责任。
   • 追问二：铺路团队为什么必须退出？
   • 直答二：它的目标是转移能力；长期代操作会隐藏平台缺口并制造新依赖。
   • 追问三：团队拥有服务是否等于只负责代码？
   • 直答三：不等于；还要拥有数据语义、发布、服务目标、成本、值班和恢复。
   • 详细章节：团队拓扑与演进

7. 问题（综合题 07）：如何从零设计一个有价值的内部平台，并避免平台大一统？

   • 口述答案：我从内部用户的工作旅程开始，而不是从已有组件清单开始。先访谈多个团队，找出高频、共性、非差异化且可量化的摩擦，例如从代码到可回滚发布需要反复手配权限、观测和审计；单一项目的特殊规则不进入平台。第二步用铺路团队、模板和人工服务验证需求，收集首次交付时间、变更前置时间、恢复时间、认知负荷和支持成本，接口尚不稳定时不急于建大平台。第三步把验证过的路径做成内部产品：自助入口、明确输入、默认安全和成本约束、可观测结果、服务目标、文档、支持和版本生命周期都要齐全。平台提供 golden path（推荐路径），但允许产品团队通过风险说明获得限时例外，避免变成 golden cage（黄金牢笼）。第四步定义共享责任：平台保证路径和控制面可靠，产品团队仍对业务配置、容量声明和用户结果负责；平台不替所有团队值班。第五步用自愿采用和交付改善验证价值，百分之百强制采用不算成功。每项能力都有用户、维护成本、退役与退出条件；采用低、工单高、平台频繁为单一用户改码或单位成本无改善时，收缩为工具、模板或删除。平台只吸收稳定共性，业务差异和创新空间留给流对齐团队，从而避免大一统中台。试点必须保留非平台基线和用户分层，同一任务比较接入前后的人时、等待、失败与恢复；节省若只是成本转移到平台团队，或依赖工单才能完成，就不计入平台收益。 平台路线图每个季度都应接受用户代表和成本责任人复审；若某项能力只方便平台实现，却增加产品团队等待和认知负担，就应降低优先级或直接退役。
   • 追问一：公共库算平台吗？
   • 直答一：通常不算；平台还需要自助体验、服务目标、反馈、支持和生命周期责任。
   • 追问二：采用率如何防止被强制失真？
   • 直答二：结合自愿试点、替代路径、用户任务完成时间和支持工单一起看。
   • 追问三：平台何时应该删除能力？
   • 直答三：用户和价值消失、维护成本长期高于收益，且迁移与数据保留完成时删除。
   • 详细章节：平台产品边界

8. 问题（综合题 08）：如何建立技术债账本、排偿还优先级并设置预算？

   • 口述答案：我先拒绝把所有不完美都叫技术债。每笔债要写当前选择、目标状态、当初换取的业务窗口、所有者、到期条件和事实等级；本金包括代码、数据迁移、验证、培训和回滚的一次性投入，利息是每周期额外变更、故障、工单和认知成本，风险则是概率、影响与暴露时间。排序先过硬门禁：资金、安全、合规、不可恢复数据和严重单点一旦越界，不能被成本低或业务忙抵消。其余用剩余生命周期内的累计利息加风险敞口，与偿还本金和业务机会成本比较，并改变系统寿命、利息和事故概率做敏感性分析，避免伪精确。预算采用基础容量加事件触发，例如每个迭代预留固定比例处理高利息小本金项，架构迁移、重大风险或供应商退出时增加专项预算。实施时分小批验证，观察变更时间、事故和支持量是否真的下降。停止规则同样写入账本：连续投入后利息不降、目标架构变化、系统即将退役、依赖无法迁移或继续投入超过重建和退出成本，就暂停并重做候选比较。停止后保留最小安全护栏、风险接受、复审日和触发阈值，不因项目取消而把风险从账本抹掉。账本还要按月核对实际利息与原估算，记录误差原因；如果债务跨多个团队，就指定一个资产责任人收口，禁止把协调失败重复计算成多笔收益或让任何一方都不承担风险。 完成一笔债务后还要保留前后证据和误差复盘，核对预计利息是否真实下降；若收益来自流量下降或系统退役，不能错误归因于偿债项目并复制错误做法。
   • 追问一：重构是不是偿还技术债？
   • 直答一：只有它降低已登记利息或风险并通过验证才算，单纯改写代码不自动产生价值。
   • 追问二：固定偿债比例是否科学？
   • 直答二：它提供最低容量，但不能替代风险触发；硬风险出现时需要额外预算。
   • 追问三：即将退役的系统还债吗？
   • 直答三：通常做最小护栏和退出准备，除非安全、资金或恢复风险要求立即处理。
   • 详细章节：技术债治理

9. 问题（综合题 09）：请设计一套架构迁移的联合门禁和事故排障流程。

   • 口述答案：我把门禁分为不可抵消的五组。正确性检查权威事实、业务不变量、高价值样本和差异预算；成本检查单位请求、存储、双运行和长期人力；安全检查最小权限、租户隔离、敏感数据和审计；可观测性要求版本、业务键、路由、契约、数据位点、差异与积压可关联；恢复必须真实演练回切、回放、补偿、外部副作用处理和人工接管。每组都有阈值、所有者、证据时间和失败动作，硬门禁失败立即冻结扩面，不能用平均分放行。事故发生后先停止自动晋级和无关变更，保存开关、版本、日志与审计；再按受影响业务键确定订单、库存、支付或报警的权威事实，不以错误率恢复替代业务正确。随后沿入口路由、契约版本、新旧路径、CDC（变更数据捕获）位点、消息积压和平台控制面定位差异，识别是入口遗漏、兼容破坏、旧写者未栅栏还是观测盲区。止血动作按可逆性选择回切、限流、隔离或向前修复，并核对旧路径容量。恢复后对账、回放和补偿未知态，观察至少覆盖最长异步与业务周期。若发布和观测平台同时故障，进入保守模式，用原始审计、数据库、外部回执和人工抽样维持最低证据面。事故指挥人还要固定同步节奏，区分已证实事实、假设和未知；关闭前逐项验证门禁恢复、影响清单清零和人工任务有截止日，再把根因转成可自动执行的发布或迁移约束。 复盘行动项必须能改变下一次控制循环，例如增加契约测试、写栅栏或恢复演练；只写“加强监控”和“提高意识”没有阈值、所有者与验收，不能关闭治理缺口。
   • 追问一：总分很高但安全失败能放吗？
   • 直答一：不能；安全硬约束不可被性能或成本得分抵消。
   • 追问二：指标恢复为何不能关事故？
   • 直答二：故障窗口可能留下错误数据、积压和外部副作用，必须验证用户事实和差异清零。
   • 追问三：旧路径容量不足怎么办？
   • 直答三：冻结扩面、降流并向前修复，同时提高人工对账和风险批准等级，避免盲目全量回切。
   • 详细章节：迁移门禁与排障

10. 问题（综合题 10）：请完整讲述订单量增长时的架构演进，而不是直接回答“拆微服务”。

• 口述答案：我先确认增长发生在哪里：下单写入、库存热点、客服组合查询、报表扫描、履约外调的资源和变化曲线不同，不能用总订单量直接推导服务数。早期团队小、状态变化快，我会在模块化单体内保护交易、库存、支付、履约边界，用依赖规则和单写者守住未来可拆性。若第一瓶颈是客服和报表读取，就先建可重建的 CQRS（命令查询职责分离）读模型，声明差异年龄并保留权威回查，以最小成本隔离读负载。促销使库存写形成独立热点后，再把库存提升为独立边界，由它维护可用、预占、占用守恒；订单只持有预占结果，不直写库存表。通知、索引和可恢复履约准备可以消费订单事实事件，但库存扣减与支付确认仍由权威边界裁决。替换订单入口时采用 Strangler Fig Pattern（绞杀者模式），先影子和双运行，再按租户稳定灰度；数据库通过 CDC（变更数据捕获）投影，校验状态、金额与不变量。放量必须同时满足正确性、成本、安全、观测和恢复，并演练回切。主要热点已隔离后，若支付和履约没有独立容量或发布收益，就停止继续拆；若薄服务总是共同变更则合并。最终用单位订单成本、变更等待、故障半径、读模型新鲜度和对账结果复审，而不是用服务数量证明演进成功。每一阶段都保留基线和触发阈值，例如读模型超过陈旧预算就回查，库存差异非零就冻结，运行人时超预算就停止；这样能区分哪一步真正解决增长，而不是把全部改善归功于微服务。
• 追问一：订单创建能否完全异步？
• 直答一：可以返回“已受理”，但不能把尚未获得库存承诺的状态表达为已确认。
• 追问二：先拆库存的依据是什么？
• 直答二：独立写热点、清晰不变量和单一责任同时成立，而不是模块名称重要。
• 追问三：订单平台何时抽取？
• 直答三：多个业务线重复稳定共性且自助价值可证明时；单产品规则仍剧烈变化时不抽。
• 详细章节：订单增长演进线

11. 问题（综合题 11）：请完整讲述第三方物流从少量接入到接入平台的演进。

• 口述答案：我会先保护内部履约模型。只有一两家承运商时，在履约模块内建立 ACL（防腐层），把外部状态、认证、时区、错误码和回调转换为内部最小标准，同时保留原始报文、合作方版本和业务键；此时平台化会过早固化未知。承运商增加后，先提炼接入模板、契约测试、沙箱回放、凭证隔离和限额治理，但运价、承运商选择、时效承诺和赔付仍归履约业务。只有多个业务线反复解决签名、回调验真、轨迹归一、限流和故障切换，标准接口经过多家验证，才由平台团队经营自助注册、版本、观测和支持。迁移按合作方实施 Strangler Fig Pattern（绞杀者模式）：用历史报文影子解析，同一输入双运行比较标准事实，再接管低风险查询，最后灰度下单、取消等真实副作用；同一运单生命周期固定在同一路径。每个合作方有独立开关、预算、回滚和责任，不能用全局平均成功率掩盖单一高价值伙伴故障。高度定制且复用低的伙伴允许保留专用适配器，并单独核算商业价值。若平台新增一家仍需大量改码、用户只能提工单、共性接口持续膨胀或维护成本超过复用收益，就停止平台化并收缩为模板和工具。退役旧适配前要经过最长物流周期和回调重放窗口。运行中还要以运单终态、轨迹新鲜度、重复下单、取消结果和账单差异验证，而非只看接口成功率；外部未知态进入查单和人工队列，并给每家伙伴明确升级时限。 平台退出同样按合作方和业务线迁移，先保证专用适配可接管，再清理平台凭证、回调地址和历史任务；不能因停止投资就把在途运单和外部承诺变成无主状态。
• 追问一：统一物流状态越少越好吗？
• 直答一：不是；最小标准应支持共同业务决策，无法无损归一的语义保留扩展和原始证据。
• 追问二：为什么按合作方灰度？
• 直答二：版本、凭证、限额和失败语义以合作方为边界，便于稳定路由与独立回滚。
• 追问三：接入平台能决定承运商吗？
• 直答三：不能；它提供技术接入共性，商业选择和履约承诺属于业务边界。
• 详细章节：第三方物流演进线

12. 问题（综合题 12）：请完整讲述 IoT（物联网）报警风暴从止血到治理平台的演进。

• 口述答案：我先声明最高优先级不变量：高危报警不能被低危风暴挤占或吞没。第一阶段不急于拆服务，在现有应用内分离采集、规则和通知模块，原始事件先持久化，队列有上限，按租户和危险等级设配额；高危走独立容量和人工升级，低危重复可按设备、区域、规则版本和根因签名聚合抑制。第二阶段用到达率、规则计算耗时和队列年龄确认独立热点，只有模块隔离不足时才把规则计算提升为独立边界；它发布已经发生的报警事实，通知渠道幂等消费。第三阶段为运营查询建立 CQRS（命令查询职责分离）读模型，投影可聚合但不能替代原始事实和高危权威状态。更换规则引擎时，让新旧版本读取同一原始事件，影子回放并比较高危漏报、误报、延迟和资源；高危漏报门禁为零，低危差异按批准预算。通过后按租户或设备组稳定灰度，通知送达和人工升级结果回写证据链。多个产品团队反复需要规则版本、压测、配额、回放和审计时，才抽报警治理平台；危险等级和业务阈值仍归产品团队。平台强制统一导致语义失真、观测盲区、恢复超窗或维护成本超过复用时停止扩张。恢复以原始事件覆盖、积压清空、关键通知送达和人工核验为终点，不以告警数量下降为终点。容量评审还要计算风暴持续时长、净消费能力和原始事件保留窗口，演练通知渠道全部不可用后的补发；采集断开导致告警变少时必须识别为观测故障，不能误判为治理成功。 规则和容量变更都要关联同一版本，事故时才能区分设备真实恢复、抑制生效和采集断链；对高危样本定期人工抽检，防止自动校验与新引擎共享同一错误假设。
• 追问一：降噪率 99% 能证明成功吗？
• 直答一：不能；必须单独看高危召回、通知送达、采集覆盖和恢复窗口。
• 追问二：为什么保留原始事件？
• 直答二：它支持规则重放、漏报核验和读模型重建，是迁移与事故的证据基础。
• 追问三：何时拆规则计算服务？
• 直答三：形成独立资源热点、故障边界和负责人，且应用内隔离无法满足时再拆。
• 详细章节：IoT（物联网）报警演进线

13. 问题（综合题 13）：如何评审一份“把单体拆成二十个服务”的方案？

• 口述答案：我不会先评服务框图，而会把方案拉回问题和候选。先问当前损失是什么：构建慢、发布冲突、局部热点、故障扩散、合规隔离还是组织等待，各自需要量级、时间窗和业务影响；若只有“代码很多”和“行业都用”，证据不足。然后检查边界是否来自业务不变量和变化原因，每个服务能否独立说明权威数据、命令、事件、失败语义、所有者和恢复；按控制器、表或技术层拆分直接列为反例。第三步把维持模块化单体、只拆热点、只隔离读模型、全部拆分放在同一候选表中，先淘汰违反资金、安全、恢复和团队能力的项，再比较独立发布、扩容与故障收益能否覆盖网络、契约、跨域一致性、流水线、观测和值班成本。第四步攻击推荐项：画端到端同步链和变更拓扑，检查是否会形成共同发布、共享数据库、联合故障和分布式单体；确认团队是否有端到端责任与平台支撑。第五步要求渐进路径，先模块化，再拆最有证据的一块，影子、双运行、灰度和回滚均有联合门禁。最后写停止和合并条件，若共同变更率、单位成本和恢复时间恶化就冻结剩余拆分。只有二十个边界各自有可复算收益才批准；否则条件批准小试点或直接选择不拆。评审结论还要限定首次范围、观察周期、风险接受人和下一次复审日期；试点只证明被覆盖场景，不能外推到所有租户、峰值和灾备，证据不足的部分继续标为未知。 我还会要求方案给出合并回迁的实际步骤和预计时间；若作者只能描述如何拆、不能证明怎样退出，说明可逆性被高估，首次批准范围就必须进一步缩小。
• 追问一：服务越小越容易维护吗？
• 直答一：单个代码可能更小，但系统协调、契约和值班会增加，必须看总拥有成本。
• 追问二：共享数据库能否作为过渡？
• 直答二：可限时只读或受控过渡，但要先设单写者、权限、审计、截止日和迁移计划。
• 追问三：评审结论只有通过和不通过吗？
• 直答三：还应有条件批准、退回补证和缩小试点，条件逾期自动失效。
• 详细章节：架构评审与不拆权衡

14. 问题（综合题 14）：过度拆分和分布式单体已经出现，如何治理并决定是否合并？

• 口述答案：我先用证据确认问题，而不是凭感觉合并。收集三个月的变更拓扑、发布编排、调用链、数据库写入口、告警和事故，识别哪些服务总是共同改、共同发、同步互调、共享表并在故障时共同不可用；这些是分布式单体的强信号。止损阶段冻结新增服务和破坏性契约，把关键链路版本、业务键和依赖可视化，收紧共享库写权限，先恢复单写者和清晰不变量。随后按变化原因和故障命运重画模块：真正有独立热点、合规边界或团队责任的服务保留；只做数据转发、无法独立恢复且总共同发布的薄服务，比较“修成独立服务”和“合并部署”的未来成本。合并不是把代码重新揉成大泥球，而是把网络调用和跨资源事务收回本地，同时保留模块接口、依赖规则、契约测试和数据所有权；数据库可先同实例分模式，再按风险决定是否物理合并。迁移仍要小步：在抽象后增加本地实现，双运行比较，灰度切回，处理历史消息和外部调用。评估指标包括共同变更率、端到端延迟、联合故障、发布等待、值班对象和单位成本。若保留服务后这些指标持续改善，就停止合并；若合并后边界又频繁泄漏，则说明业务模型仍需重构，不能只改部署拓扑。组织上同步减少虚假所有者和重复值班，明确合并后的模块责任；退役服务还要清理流量、消息、数据权限、告警和成本，避免只关闭进程却留下长期运维残骸。 合并后的观察窗至少覆盖一次高峰、一次常规发布和一次故障演练，确认本地化没有扩大进程故障半径；若隔离收益丢失，就重新评估资源隔离而非机械继续合并。
• 追问一：合并服务是不是架构倒退？
• 直答一：不是；在独立收益不足时降低分布式成本是基于证据的演进。
• 追问二：合并后数据库也必须合并吗？
• 直答二：不必须；部署、数据和组织边界可分别决策，但要避免无意义的跨库事务。
• 追问三：最先合并哪类服务？
• 直答三：无独立数据语义、只转发、总共同发布且无法独立恢复的薄服务优先。
• 详细章节：分治停止与回迁

15. 问题（综合题 15）：共享数据库已经被多个服务直接写，如何逐步恢复数据所有权？

• 口述答案：第一步不是立刻分库，而是建立写入事实图。通过账号审计、代码搜索、日志和数据库活动记录列出每张关键表的服务、脚本、人工和批任务写入口，标 E1（源码与可复现证据）与 E0（待核对）；事故期间先禁止新增旁路。第二步按业务语义确定每类事实的所有者，明确由谁接受命令、维护不变量、解释字段和负责修复，不能按“谁建表”决定。第三步把非所有者直接写改成调用所有者命令或提交受控意图；短期兼容通过数据库权限、触发审计和防腐接口限制，批处理与人工脚本也必须迁移，避免只改在线服务。第四步为读取建立版本化查询或可重建投影，若暂时共库，至少做到账号分离、模式边界和禁止跨域写。第五步迁移数据时旧所有者保持唯一权威，利用 CDC（变更数据捕获）向新存储投影，回放和校验数量、金额、状态与不变量；切换时用写栅栏阻断旧入口。第六步转移备份、对账、修复、告警和值班，经过最长业务周期后撤销旧权限。若发现强不变量必须横跨候选边界，就暂停分库并重新划界，不能为了每服务一库强造分布式事务。治理成功的证据是权威写入口唯一、旁路拒绝可见、差异可恢复和责任人能独立收口，而不是数据库实例变多。迁移期间每日公布未知写者、拒绝次数和差异账龄，任何临时脚本都需限时权限和审计；否则一个被遗漏的月末任务就可能在切换后重新制造双权威。 最后要把所有权写进架构检查和入职材料，使新代码、新脚本和临时运维账号都走同一规则；否则一次人员变化就可能让已经治理的共享库重新失控。
• 追问一：数据库触发器能永久保护所有权吗？
• 直答一：适合审计和过渡护栏，不应替代业务命令、版本和责任边界。
• 追问二：只读共享可以吗？
• 直答二：可限时使用，但要有语义、负载和废弃边界；长期宜走查询契约或投影。
• 追问三：每服务必须独库吗？
• 直答三：不必须；单写者和权限是核心，同实例分模式也能表达所有权。
• 详细章节：数据所有权切换

16. 问题（综合题 16）：如何为 WMS（仓储管理系统）库存防超卖设计渐进演进方案？

• 口述答案：我先定义不变量：任一库存单元的可用、预占、占用与调整流水必须守恒，重复请求不重复扣减，未知态可查询和修复。早期在 WMS（仓储管理系统）模块化单体中让库存模块独占写入口，用数据库条件更新、版本和请求标识保护本地事务；订单只接收预占结果，不直接改库存表。增长后先确认热点是否真实：若只是报表拖慢，就隔离读模型；只有库存写曲线、发布节奏和故障影响独立，且有团队值班，才拆库存服务。迁移前用 Branch by Abstraction（抽象分支）收敛调用，将旧模块保持权威，新实现影子计算同一请求；双运行按库存单元、请求标识、前后数量和流水比较，高价值差异零容忍。数据由旧库通过 CDC（变更数据捕获）投影到新库，回放历史并校验聚合守恒，切换时给旧写者设栅栏。灰度按仓或租户稳定分组，不能让同一库存单元跨新旧权威；回滚先停新预占，再按权威流水处理已产生的订单和释放，不只退代码。门禁还包含单位扣减成本、租户权限、差异年龄、旧路径容量和对账恢复。若拆分后订单与库存总共同发布、同步链使可用性下降或团队无法值班，就停止继续拆并考虑合并部署。结果表达按事实等级，不用缓存命中率代替不超卖证明。上线观察覆盖促销峰值、重复提交、超时、释放和盘点调整，业务验收同时核对负库存、账实差异和未知态账龄；任一异常先保护库存权威和高价值订单，再分析性能。 切换后的盘点和对账必须覆盖冻结、释放、取消与补录等低频分支，不能只验证正常扣减；这些分支一旦遗漏，差异常在促销结束后才暴露。
• 追问一：Redis（远程字典服务）预扣能做唯一权威吗？
• 直答一：除非具备被业务批准的持久、恢复和审计能力，否则更适合热点闸门，权威仍需可对账事实源。
• 追问二：灰度为何按库存单元稳定路由？
• 直答二：同一库存事实不能同时由新旧路径裁决，否则会形成双权威。
• 追问三：回滚库存最难的是什么？
• 直答三：迁移期间已产生的预占、订单和释放副作用，需要按流水对账和补偿。
• 详细章节：订单与库存演进

17. 问题（综合题 17）：支付资金一致性场景如何做架构演进和回滚？

• 口述答案：支付演进先守资金事实，不以高可用或异步化掩盖未知态。我会明确支付单、请求唯一键、账务分录、渠道回执和对账差异各自权威，任何超时都返回处理中并查单，不能猜成功或失败。早期把支付模块保留在清晰本地边界，资金入账和审计同一提交；通知、报表和搜索可以消费已确认事实。若因合规、独立发布或故障隔离确需拆分，先用 Branch by Abstraction（抽象分支）收敛渠道调用和账务接口，新路径只能影子生成请求，不能触达真实扣款；通过沙箱、历史回放和纯计算比较后，再按低风险渠道、商户或金额分层灰度。契约迁移必须覆盖错误码、重试、签名、回调顺序和幂等，旧低频对账任务也要升级。数据迁移坚持单写者，CDC（变更数据捕获）投影只复制已提交支付事实，按支付单、金额、币种和账务平衡校验。回滚时先停新请求和自动重试，保全渠道回执，按支付单查单；已发生渠道扣款不能靠制品回退撤销，需要入账、退款或人工处理。门禁要求高价值差异为零、权限和密钥隔离、对账可恢复、旧路径容量足够。若拆分只增加同步链和共同发布，就保留模块化边界，不为形式服务化承担资金风险。观察窗至少覆盖渠道延迟回调、日终对账和退款周期，所有未知态都有负责人和截止时间；安全审计还要证明影子环境没有真实密钥和敏感数据越界。 风险接受必须按渠道、金额和商户分层，低风险试点不能证明大额路径安全；每次扩面前重新检查对账人力和退款能力，避免异常量超过人工兜底上限。
• 追问一：支付超时能否直接重试？
• 直答一：先用唯一键查原请求和渠道状态，未知时受控查单，不能盲目重复扣款。
• 追问二：支付影子流量能验证什么？
• 直答二：可验证签名、路由、请求构造和容量，不能验证真实扣款副作用。
• 追问三：回滚成功的标准是什么？
• 直答三：支付单、渠道事实、账务分录和对账结果一致，未知态全部有截止处理。
• 详细章节：迁移门禁与恢复

18. 问题（综合题 18）：异步任务和 Runner（执行器）调度如何从单应用演进为共享能力？

• 口述答案：我先区分任务业务语义和调度共性。早期只有少量导出、对账或补偿任务时，任务状态机、幂等键、检查点和副作用规则留在业务模块，Runner（执行器）只负责领取、续租、执行与回报；此时抽平台会让不稳定业务规则进入公共模型。随着任务数量和团队增加，先模块化调度协议：任务提交声明类型、优先级、资源预算和重试边界，执行用租约与栅栏防止过期 Runner（执行器）提交结果，长任务分片并持久化检查点；外部文件、通知和扣费都有幂等或补偿。若队列与执行资源形成独立热点，再拆调度控制面和执行数据面，按租户、任务类型和资源池隔离，事件化传播终态但权威状态仍由任务账本维护。多个团队反复需要配额、优先级、重试、检查点、审计和自助观测时，才平台化这些稳定共性；具体任务参数、业务校验和副作用仍由产品团队负责。迁移时复制历史任务做影子调度，不实际执行副作用；双运行比较选取、顺序和资源，灰度只接管可重放任务。回滚冻结新领取，让持租约任务完成或超时，再依据检查点恢复，避免双执行。若平台需人工理解每个任务、队列恢复不达标或低频用户被统一模型拖累，就停止平台扩张。容量门禁同时核算到达率、执行时间、净消费能力和下游限额，不能只增加 Runner（执行器）并发；恢复验收逐项核对任务终态、文件完整性、重复通知、扣费与积压年龄。 平台服务目标也要区分任务受理、开始、完成和恢复，不用单一成功率掩盖排队年龄；低优先级任务被持续饿死时，配额和公平性同样属于架构问题。
• 追问一：租约到期为何还要栅栏？
• 直答一：旧执行器可能仍在运行，栅栏能拒绝过期代次提交，防止双结果。
• 追问二：任务平台可以决定业务重试吗？
• 直答二：只能执行声明的策略，是否可重试和副作用如何补偿由业务所有者定义。
• 追问三：如何验证恢复能力？
• 直答三：注入执行器宕机、租约过期和队列积压，从检查点恢复并核对终态与副作用唯一性。
• 详细章节：平台边界与团队责任

19. 问题（综合题 19）：如何设计和迁移一个 CQRS（命令查询职责分离）读模型？

• 口述答案：我先确认问题确实在查询侧：组合检索、报表或客服视图迫使权威写模型增加大量索引和联表，已经影响写入与恢复；若只是偶发慢查询，先优化语句或只读副本，不急于引入第二模型。成立后明确写模型仍是唯一权威，读模型只保存可重建投影，声明用户可接受的差异年龄、关键操作的权威回查和投影不可用时的降级。数据流从已提交事实出发，事件包含稳定业务键、事实版本和必要快照；消费者按业务键幂等，拒绝版本倒退，保留死信、检查点和全量重建。首次迁移先对权威源做一致时间点基线，再接增量，避免全量与增量缝隙；同键比较状态、金额、数量和查询语义，而不只比文档数。上线先让新读模型影子承接查询，记录命中、延迟、差异和陈旧度，再按只读场景与租户灰度；涉及库存确认、支付状态或高价值操作时回查权威源。恢复演练要覆盖投影清空重建、事件重复、乱序、积压和模式升级，证明能在业务窗口内恢复。若读模型变成第二写入口、陈旧窗口无法接受、重建成本失控或团队无法承担双模型，就停止扩张，回到权威查询或更简单副本。平台化查询能力只有在多个团队共享稳定投影流程时才考虑，不能把所有业务查询塞进统一大模型。读模型发布也采用扩展与收缩，新旧字段并存到历史事件和消费者都完成迁移；任何重建都记录输入范围、版本、耗时和差异，让“可重建”成为真实演练结论而非设计口号。 运营侧需要看到投影更新时间和降级状态，避免把陈旧结果包装成即时事实；重大差异要自动冻结依赖该读模型的高风险动作，而不是只发告警等待人工发现。
• 追问一：读模型能否修正权威数据？
• 直答一：不能直接写回；发现差异应提交命令给权威边界或进入人工修复流程。
• 追问二：如何处理历史事件格式变化？
• 直答二：用版本化适配、保留原始事实或迁移快照，并在重建前验证全历史兼容。
• 追问三：新鲜度指标怎样定义？
• 直答三：用权威事实发生时间或版本与投影完成时间的差值，并按业务键和场景分层。
• 详细章节：演进连续谱

20. 问题（综合题 20）：内部平台已经成为工单中心和强制大一统，如何治理？

• 口述答案：我先承认这是产品与责任问题，不是再加一个门户就能解决。第一步按用户旅程盘点平台能力：哪些任务可以真正自助完成，哪些仍需平台人员代操作，工单等待、失败率、支持人时和用户绕行路径分别是多少；强制采用率降级为活动指标，不再当价值。第二步把平台边界从组件清单改为完整任务，例如“创建一个可观测、可回滚且合规的服务”，将镜像、配置、权限和告警通过一个推荐路径组合，但不吞并业务规则。第三步建立共享责任，平台团队对控制面、默认值、接口兼容和服务目标负责，产品团队对容量声明、业务配置和用户结果负责；取消平台替全部团队值班。第四步把高频工单分三类：可标准化的进入产品路线图，阶段性能力缺口交给铺路团队限时赋能，低频高度定制需求允许受控偏离。第五步为每项能力核算用户数、交付改善、维护和机会成本，采用低、工单高、接口频繁为单一团队改动的能力收缩为模板或退役。版本迁移用扩展与收缩，给用户真实退出和替代路径。治理中禁止一次性重写大平台，先挑最痛的一条旅程小范围验证。若自愿采用、首次交付和恢复时间仍无改善，就触发停止规则，冻结功能扩张并考虑拆成更薄的产品。平台价值来自减少认知和等待，不来自集中控制权。平台自身也进入服务目标、灾备和成本审计，控制面不可用时产品团队有受控手工路径；路线图评审由真实用户参与，防止平台只优化内部实现而继续恶化使用体验。
• 追问一：强制接入什么时候合理？
• 直答一：安全、合规等硬底线可强制，但仍要提供低摩擦路径、例外治理和效果验证。
• 追问二：工单都自动化就是自助吗？
• 直答二：不一定；用户若仍需理解底层细节、等待审批或无法恢复，只是自动化了部分流转。
• 追问三：平台能力退役如何做？
• 直答三：登记消费者，先提供替代和兼容窗口，观测迁移，清零后再删除数据、权限和支持责任。
• 详细章节：平台产品边界

21. 问题（综合题 21）：面对几十笔技术债，如何做组合治理而不是靠感觉排期？

• 口述答案：我先把债务统一成可比较的账本，每笔写业务资产、目标状态、借债收益、所有者、本金、周期利息、风险敞口、系统剩余寿命、依赖和停止规则，事实不足标 E0（待核对）。然后做第一层硬筛选：资金、安全、合规、不可恢复数据和会扩大爆炸半径的债务超过阈值，直接进入止损或专项治理，不能与普通维护项平均打分。第二层计算经济性，用剩余周期累计利息加风险期望损失减偿还本金，分别改变系统寿命、事故概率和人时成本做敏感性；结果接近时优先更可逆、能释放后续选择的债，例如先消除共享数据库旁路写，再拆库。第三层按依赖形成批次，避免同时迁移契约、数据库、组织和平台；每批都要交付可验证利息下降。预算由固定基础容量和事件预算组成，小本金高利息项持续清理，迁移窗口、供应商退场或硬风险触发额外投入。第四层平衡组合：既处理高风险集中项，也保留少量能提升交付效率的债，防止所有预算被一个长期重构吞没。实施后观察变更前置时间、事故、工单、恢复和单位成本；连续两个周期无改善就停止，比较重建、隔离、护栏和退出。即将退役系统通常不做完整美化，只做安全、备份、审计和迁出。每次产品排期公开偿债的业务收益和机会成本，避免技术团队单方宣称优先级。组合层还要限制同一故障域和同一关键人员上的债务集中度，预留应急容量；每季复核债务是否仍存在，避免目标系统变化后继续偿还已经失效的“本金”。
• 追问一：债务分数最高就一定先做吗？
• 直答一：不一定；还要看依赖、业务窗口、可逆性和敏感性，分数只帮助暴露假设。
• 追问二：怎样防止长期重构吞预算？
• 直答二：拆成能独立降低利息的批次，设阶段预算和停止阈值，未产生结果就重评。
• 追问三：无主债务由谁接？
• 直答三：先由资产责任人临时承接风险，补齐业务所有者；不能因历史责任不明而忽略。
• 详细章节：技术债治理

22. 问题（综合题 22）：契约升级导致灰度用户与非灰度用户同时异常，如何排查和恢复？

• 口述答案：我先判断灰度边界是否被共享状态穿透。立即冻结自动晋级和相关配置，保存网关路由、版本、契约模式、消息、数据库变更与调用样本；按业务键分别抽取灰度和非灰度用户，确认权威业务事实。然后沿四类共享面排查：第一是新版本是否写入旧版本无法理解的字段或状态，导致共享数据库污染；第二是消息生产者是否发出旧消费者不能处理的新语义；第三是缓存、配置或读模型是否被新旧版本共同使用；第四是链路标识是否在异步和下游丢失，使灰度请求进入旧路径又写回共享数据。恢复优先停止产生不兼容事实。若旧版本能读取当前数据且旧路径容量足够，切回入口并保留兼容适配；若数据已经不可逆升级，不能盲目退制品，应向前修复旧消费者或增加转换层。对已产生的非法状态按权威源和版本分类，回放兼容事件、修复投影、对账外部副作用，并观察最长缓存与消息窗口。根因复盘要把契约门禁从语法扩展到语义、时间和失败，强制 Expand and Contract（扩展与收缩），灰度测试覆盖共享数据库、消息和配置；稳定业务键和版本必须全链路透传。事故关闭以灰度与非灰度用户业务结果恢复、差异清零和积压消化为准，不以新版本错误率下降为准。沟通中每个时间点公布影响分母、新增异常、恢复动作和未知项，避免只报灰度比例；事后把真实污染样本加入兼容回归，并验证旧版本面对未来扩展仍能安全拒绝或降级。 恢复后还要扫描未进入抽样的消费者和离线任务，确认它们没有在下一业务周期重新读取污染数据；观察窗不足时事故只能降级为持续跟踪，不能提前关闭。
• 追问一：为什么非灰度用户也会受影响？
• 直答一：新旧版本可能共享数据库、消息、缓存和配置，灰度只隔离入口流量并不自动隔离状态。
• 追问二：第一时间回滚新版本对吗？
• 直答二：先确认旧版本能否读取新数据和契约；否则制品回退可能扩大故障。
• 追问三：怎样预防？
• 直答三：扩展先行、消费者迁移、共享状态兼容测试、全链路版本透传和真实回退演练。
• 详细章节：契约版本迁移

23. 问题（综合题 23）：为什么成本、安全、可观测性和恢复必须共同进入迁移门禁？

• 口述答案：迁移改变的不只是代码路径，还改变长期现金流、权限边界、证据链和失败后的生存能力，四者不能事后补。成本门禁要算新旧双运行、额外存储、网络、许可证、平台支持和值班人力，也要看单位业务量成本；如果影子验证本身把生产资源吃满，验证就会制造事故。安全门禁检查新账号最小权限、租户隔离、敏感数据复制、密钥轮换和审计完整性，任何越权风险属于不可抵消硬约束。可观测性门禁要求每个请求能关联业务键、租户、路由、制品版本、契约版本、数据位点和结果差异，并监控观测系统自身可用性；没有这些证据，自动灰度只能盲飞。恢复门禁要求旧路径容量与兼容真实可用，新路径可暂停，历史事实可回放，消息与投影可重建，外部副作用可查单、补偿或人工接管。评审顺序先做布尔硬准入，再比较性能和交付等可交换偏好，不能把安全 0 分用成本 20 分平均掉。每道门禁有所有者、证据时间、阈值和失败动作，扩大流量前重新检查，因为退出成本会随数据、消费者和组织扩张而变化。若发布控制面与观测面同时失效，必须冻结高风险变更，依靠权威数据、审计和外部回执进入保守模式。联合门禁的意义是让迁移在成功时可持续、失败时可证明地恢复。执行上把门禁自动化到流水线和控制面，同时保留人工否决与审计；任何临时豁免都限定范围、期限、补偿措施和批准人，逾期自动失效，不能变成永久旁路。 门禁本身也需版本化和定期演练，避免规则过期或观测口径漂移；若某项检查长期不改变决策，应删除或重设阈值，把评审精力留给真正会翻转结论的证据。
• 追问一：门禁越多会不会拖慢交付？
• 直答一：应按风险自动化和分级；低风险快速通过，高风险增加证据，避免事故造成更大等待。
• 追问二：成本超预算但正确性正常能扩面吗？
• 直答二：若成本是批准硬阈值就不能；先优化或缩小范围，避免形成不可持续稳态。
• 追问三：可观测性门禁最小字段是什么？
• 直答三：至少有业务键、范围、路由、制品与契约版本、权威结果、差异和时间。
• 详细章节：联合迁移门禁

24. 问题（综合题 24）：什么情况下明确不拆，什么情况下已经拆了也应停止？

• 口述答案：我会把“不拆”当正式候选而不是保守默认。业务边界仍频繁变化、小团队能在一个发布单元高效协作、关键不变量适合本地事务、没有长期独立热点或故障隔离收益、平台和值班能力不足时，优先模块化单体；用依赖规则、模块接口、数据权限和自动化测试控制复杂度。即使流量增长，也先判断能否通过分区、缓存、读模型、批处理、队列保护和整体扩容解决，容量问题不自动等于服务边界问题。拆分评审必须量化独立发布等待、资源冷热比、事故损失和合规要求，与契约、网络、一致性、流水线、观测和值班成本比较，净收益不稳定就不拆。已经拆分后，若一次需求长期同时修改多个服务，发布锁步，调用链同步且联合可用性下降，服务共享数据库或互相越权，单位成本和恢复时间恶化，团队又无法独立值班，就触发停止规则。先冻结新增服务，恢复单写者与契约，区分真正独立边界和薄转发服务；后者可合并部署或回迁本地调用，但保留模块和所有权规则。停止不等于立即全部合并，还可以只停在当前粒度、减少同步依赖和增强平台。决策要忽略沉没成本，用未来维护现金流比较；给“不拆”方案也设置复审阈值，当独立等待、热点或故障损失跨阈值时再重开，而不是永久拒绝演进。“不拆”仍要持续治理边界和技术债，防止退化成无约束单体；通过架构适应度检查循环依赖、旁路写和模块测试，确保未来触发条件出现时仍有可拆选择。 复审时必须与最初“不拆”基线使用同一业务范围和成本口径，避免团队扩大后把组织变化误算成架构收益；触发阈值未到就继续优化模块，而不是追逐流行方案。
• 追问一：预计未来会很大，能提前拆吗？
• 直答一：可提前设计模块和契约，但不应提前支付全部部署和值班成本，先保留可拆性。
• 追问二：停止拆分后还可优化性能吗？
• 直答二：可以，分区、缓存、读模型、资源隔离和整体扩容都不要求增加服务数量。
• 追问三：合并会失去团队自治吗？
• 直答三：可只合并部署，继续保留模块所有权、接口和测试，自治不必等同于进程数量。
• 详细章节：分治与停止条件

25. 问题（综合题 25）：请主持一次分治、平台化与技术债联合架构评审。

• 口述答案：会前我要求方案作者提交目标、非目标、业务不变量、量级、事实等级、当前损失、维持现状和至少一个替代项，并画权威数据、失败路径、组织责任和迁移状态机；缺回滚、联合门禁、技术债或停止规则直接退回补充。参会角色包括业务与决策所有者、数据和安全责任人、运行与成本代表、平台用户代表、实施负责人和独立质疑者，各自只在有权限的边界批准。会议先让业务重述不可接受损失，再核对 E1（源码与可复现证据）、E2（已有材料映射）、E3（演练证据）和 E0（待核对），防止演练数字冒充生产成果。随后用硬约束淘汰候选，特别检查资金、安全、合规、不可恢复数据和恢复上限；剩余方案才比较模块化、拆分、事件化、读模型和平台抽取的收益成本。独立质疑者专门攻击过度拆分、分布式单体、共享数据库、平台大一统、永久双写和兼容无截止日。迁移审查必须覆盖影子、双运行、稳定灰度、数据回放、契约迁移和业务回滚，门禁含正确性、成本、安全、观测和恢复。技术债写本金、利息、风险、预算和停止条件，组织同步迁移权限、值班和支持。结论只有批准、条件批准、拒绝或退回补证；条件批准写范围、负责人、截止日和逾期自动失效。会后运行证据触发复审，评审不是一次性盖章。记录人把异议、批准边界、实施版本和适应度指标互相链接；首次扩面前由非方案作者复算关键数据，运行结果一旦跨过翻转阈值，自动重开评审而不是沿用过期结论。
• 追问一：谁最终接受剩余风险？
• 直答一：由对相应业务、安全、运行或成本后果有授权的责任人签署，架构师不能代替。
• 追问二：评审会可以投票决定吗？
• 直答二：投票不能覆盖硬约束和明确异议；要记录证据、解除条件和责任主体。
• 追问三：时间紧如何缩短评审？
• 直答三：会前做准入和异步审阅，会议只讨论会翻转决策的证据与风险，不删除关键门禁。
• 详细章节：架构评审与项目话术

26. 问题（综合题 26）：请用三条项目线完整展示你的架构演进方法和设计权衡。

• 口述答案：我的统一方法是先问题和不变量，后边界与技术，再用迁移、门禁和停止规则闭环。订单增长线中，早期保持模块化单体，先隔离客服与报表读模型；库存成为独立写热点且有清晰守恒和团队责任后才拆，订单事实事件化用于通知和履约副作用，支付确认仍由权威边界裁决。第三方物流线中，少量伙伴先在履约内用 ACL（防腐层）保护内部模型，随着多业务线重复认证、回调验真和轨迹归一，先模板化再产品化接入平台；运价、承运商选择和履约承诺不进入平台，高度定制伙伴保留专用适配。IoT（物联网）报警线中，先在应用内用有界队列、优先级和高危独立通道止血，规则计算形成独立热点后再切边界，原始事件支持新旧引擎影子与双运行；多个团队重复规则发布、压测、配额和回放时才抽治理平台，高危漏报始终零容忍。三条线都使用稳定业务键、契约扩展与收缩、CDC（变更数据捕获）回放、灰度和业务对账，放量共同检查正确性、成本、安全、观测和恢复。组织上让流对齐团队拥有业务结果，铺路团队限时赋能，平台团队经营自助产品。若共同变更、联合故障、值班负担或单位成本反弹，就停止拆分、收缩平台或合并薄服务。成果按 E1（源码与可复现证据）至 E0（待核对）诚实表达，不用想象指标证明成功。我会把每条线的决策版本、用户影响、技术债和下一触发器放在同一演进账本中，定期比较原始瓶颈是否消失、新复杂度由谁承担；这让架构能力体现为持续判断和退出，而非一次画图。
• 追问一：三条线共同的第一步是什么？
• 直答一：明确不可接受损失、权威事实和当前证据，不先选择服务或平台。
• 追问二：共同的迁移底线是什么？
• 直答二：单写者、稳定业务键、可回放事实、兼容窗口、业务校验和真实恢复路径。
• 追问三：共同的停止条件是什么？
• 直答三：新增协调与运行成本持续超过隔离和复用收益，或任何硬门禁无法满足。
• 追问四：如何体现架构师而非组件专家？
• 直答四：讲清目标、证据、候选、取舍、责任、迁移、失败和退出，而不是罗列组件机制。
• 详细章节：三条完整演进线

3. 正式图、参考链接与复习清单

正式 PlantUML（统一建模语言）时序图见 architecture-evolution-platform-debt.puml，渲染结果见 architecture-evolution-platform-debt.png。该图仅使用 PlantUML（统一建模语言）时序语法，无需 Graphviz（图形可视化软件）。

用于核对模式原义和平台边界的真实资料如下；项目数字仍按本文 E1（源码与可复现证据）至 E0（待核对）规则陈述：

• Martin Fowler：Strangler Fig Application（绞杀者应用）
• Martin Fowler：Branch By Abstraction（抽象分支）
• Martin Fowler：CQRS（命令查询职责分离）
• AWS（亚马逊云服务）：事务发件箱模式
• Microsoft（微软）：命令查询职责分离模式
• Team Topologies（团队拓扑）：Key Concepts（核心概念）
• CNCF（云原生计算基金会）：Platform Engineering Maturity Model（平台工程成熟度模型）

复习时应能做到：

• 从问题规模和耦合判断分治边界，并说出何时不拆、停止拆或合并。
• 区分模块化单体、垂直切分、服务拆分、事件化、CQRS（命令查询职责分离）读模型和平台抽取。
• 说明 Strangler Fig Pattern（绞杀者模式）、Branch by Abstraction（抽象分支）、影子、双运行、灰度和业务回滚的验证边界。
• 画出数据库拆分、CDC（变更数据捕获）、回放、校验、写栅栏和权威切换状态机。
• 用语法、语义、时间、失败和生命周期解释契约兼容。
• 说明流对齐团队、平台团队、铺路团队和复杂子系统团队的责任与退出。
• 用用户旅程、采用、交付结果和停止规则评审内部平台，识别大一统陷阱。
• 计算技术债本金、利息、风险与偿还优先级，并能因系统退役改变结论。
• 用订单增长、第三方物流和 IoT（物联网）报警风暴三条线完整口述架构演进。
• 在 WMS（仓储管理系统）、支付、异步任务和 Runner（执行器）调度中区分权威事实、投影和外部副作用。
• 把正确性、成本、安全、可观测性和恢复作为联合迁移门禁。
• 按 E1（源码与可复现证据）、E2（已有材料映射）、E3（演练证据）、E0（待核对）诚实表达结果。