系统形态由约束触发：日请求量不能决定拆服务
"日均 500 万请求，是不是该拆微服务了？"——请求量本身既不能证明应拆，也不能证明不该拆。本页把"必须微服务"改成可证伪决策：先问独立扩容、发布节奏、故障隔离与业务边界中哪一项真的受阻。服务边界如何识别见把服务边界看成耦合与自治的交换；迁移的执行见迁移模式与双向恢复。
约束触发，不是规模神话
单体可以有清晰模块、依赖规则和独立构建；微服务可以互相同步调用、共同部署而成为分布式单体。部署单元数量不是架构质量指标。演进触发可能来自独立扩缩容、不同可用性目标、部署冲突、团队边界或合规隔离。需要先证明这些约束无法通过模块边界、库隔离或交付流程解决。
分布式拆分引入网络延迟、局部失败、协议版本、身份传递、遥测、部署协调和数据复制。收益应超过这些新增的技术与组织成本。
模块边界与团队边界
高内聚模块围绕稳定职责组织；模块间通过小而明确的契约交互。依赖方向、数据所有权和允许的调用路径应可审查，避免循环依赖和内部表泄漏。康威定律揭示沟通结构会影响系统结构，但不能机械理解为每个团队对应一个微服务。团队拆分还需考虑认知负载、值班能力、技能覆盖、发布责任和协调开销。
服务自治意味着团队能够独立开发、发布、观测和处理故障，并对其 API 和数据负责。若关键变更仍必须跨多个团队同步审批或共享写库，自治是表象。
把"必须微服务"改成可证伪决策
教学现状：20人团队、单体日均500万请求、峰值3000/秒，发布需要协调4个小组，数据库锁等待是主要尾延迟来源。先问哪项约束真的受阻。方案A模块化单体加强依赖规则与部署自动化，方案B按明确领域拆独立写域。A成本低且保留本地事务，但部署和进程故障仍共享；B可能自治，却增加网络、数据投影、版本兼容、值守和恢复。若主要瓶颈是同一热点行，拆进程不改变裁决点，反而增加RPC。
触发条件和测量
先记录变更等待时间、耦合提交比例、单模块资源、事故影响与恢复时间。给触发阈值，例如某模块持续需要独立容量、跨组协调占交付周期一半、边界可通过契约隔离；阈值是本组织决策，不是行业定律。拆分前先以代码边界和数据所有权实验，确认远程边界不会把每个请求变成十次跨服务调用。
架构形态演进应有退出路径：只拆最有价值边界，保留路由/兼容层并用业务结果验证。纯"服务数增加""接口覆盖率"不是价值指标。对比渐进替换原始说明理解渐进路线，不能把模式名当成功保证。
桌面算例与验收
每个请求新增3次网络调用，各平均5ms，串行至少多15ms工作路径，尾延迟还受相关故障影响。若拆出后只节约10ms数据库等待，正常链路也未必收益；但故障隔离和交付自治可能仍值得，需分别给证据。
提交现状基线、两个候选、硬约束、分阶段试点与反证条件。若试点后协调等待没有降、运维负担却增加，应收缩或修订边界，而不是继续拆以证明最初选择。
触发阈值表与反证登记：把"要不要演进"变成可复查的判断
本页前面把"必须微服务"改成了可证伪决策，评审还需要一张能填写的阈值表：每类约束选一个可测指标、一个阈值、一个观察窗口、一个反证条件。没有这张表，"再等等看"和"现在就拆"都只是立场。
四类约束各自的可测指标：发布协调（跨组协调占交付周期比例）、独立扩容（需要独立容量曲线的模块数）、故障隔离（一次事故波及的业务域数量）、合规（是否存在物理隔离等硬要求）。阈值是组织自定，本例取协调占比 ≥50%、独立扩容模块 ≥2、一次事故波及 ≥2 个域、存在硬合规要求；达到两项以上才进入拆分候选，一项只能记为观察。
反例算例：协调占比 10 天/20 天 = 50%、独立扩容模块 1 个、事故波及 1 个域、无合规要求。四项里只命中一项，正确判定是 KEEP_MODULAR——继续用模块化单体加依赖规则，而不是因为一项触发就全面拆分。若下季度独立扩容模块增到 2 个，判定反转为 SPLIT_CANDIDATE；这就是"什么输入跨过阈值会改变推荐"。
反证登记要写清三件事：阈值、观察窗口、推翻条件。例如"协调占比连续两个季度低于 30%、且没有扩容冲突，则复发'暂不拆分'判断"；"若拆分试点后协调等待未降、运维负担增加，则收缩边界"。反证条件不是免责声明，而是下一次复查时的检查表。
执行 python3 labs/evolution_models.py trigger_thresholds：预期输出 coordination_share=0.5、fired=["coordination"]、decision=KEEP_MODULAR、falsifier 含"连续两个季度低于 30%"。脚本只做阈值判定，不测算组织真实数据。
两个合理选择：A 单指标一票通过（任一约束满足即拆），激进、响应快但风险高；B 两项以上才进入候选，保守但需要维护四项测量。本例选 B，并规定任何拆分提案必须随附阈值表与反证登记，缺一项不进入评审。
架构师变化条件
把发布协调从 4 组降到 2 组（先合并团队）：协调等待减半而无需拆分——先试组织变化再试架构变化，二者成本不同。若合规要求某模块数据物理隔离，拆分由硬约束触发，成本比较变成可行性比较。数据库热点换成无索引扫描时，先修索引再谈拆分。每次变化重新填写触发条件表与试点反证条件。
闭卷验收
本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。