适用读者：要抄行业方案的人；要判断"我们能不能照这套搭"的人。
前置：S18-A05（风格与质量属性）、A06（中间件）、S17（分布式）、S11-A04（分库分表）。
覆盖旧文：3123（电商）、3124（营销）、3125（社交媒体）、3126（外卖）、3127（约车）、3128（金融支付）、3129（互联网金融信贷）、3130（物流配送）→ 8 篇 / 约 4.8 万字符。
扩展点：E-S18-037（八套架构的共同五段骨架）、E-S18-038（四个不可照抄的行业内核）、E-S18-039（案例到自研的迁移检查表）。
下一篇：S18-X03 · 行业清单与职场随笔登记。
1. 一句话结论
行业架构的差异不在技术栈，在"业务不变量"：电商的不变量是库存不超卖，支付是账不平不允许，出行是时空匹配的实时性，物流是多段交接的状态一致。技术组件大同小异，把不变量落到哪个环节，才是这套架构真正的骨架。
出处：
A-3123（电商）、A-3128（支付）、A-3127（约车）、A-3130（物流）。
2. 共同五段骨架（E-S18-037）
① 接入层：网关（鉴权、限流、灰度、协议转换）
② 领域服务层：按限界上下文切分（订单/商品/库存/支付/履约）
③ 异步链路：MQ / 事件总线（解耦、削峰、最终一致）
④ 存储层：OLTP（分库分表）+ 缓存（热点）+ 检索（ES）+ 分析（数仓）
⑤ 支撑面：配置/注册/追踪/告警/对账/补偿（真正决定能不能上生产）
| 层 | 通用判据 | 常见错配 |
|---|---|---|
| 接入 | 全链路统一鉴权与限流 | 每个服务各写一套鉴权 |
| 领域 | 一个上下文一个服务，边界稳定 | 按表/按层拆 |
| 异步 | 只有"可容忍延迟"的环节才异步 | 把强一致读改成异步 |
| 存储 | 按访问模式选存储 | 一个 MySQL 扛所有查询形态 |
| 支撑 | 对账、补偿、可观测先行 | 上线后再补，故障时无从下手 |
3. 四个不可照抄的行业内核（E-S18-038）
3.1 电商：库存不超卖
方案 A 数据库行锁：UPDATE stock SET n = n - 1 WHERE sku = ? AND n >= 1
→ 强一致、简单；热点 SKU 上 QPS 受限（行锁排队）
方案 B Redis 预扣（Lua 原子）：先扣缓存，再异步落库
→ 高并发；需处理"扣了但下单失败"的回补与对账
方案 C 库存分桶（把 1000 件拆 10 桶各 100）
→ 提升并发；桶间不均衡需再平衡
判据：秒杀级热点用 B/C + 对账；日常商品用 A。
反例：只改缓存不改库 → 超卖；只用分布式锁 → 性能打回单机。
3.2 支付：账务与对账
三条硬约束：① 借贷必平（复式记账）② 幂等（同一笔不重复入账）③ 可追溯（每笔有流水）
核心结构：支付单（外部请求）→ 交易单（内部记账）→ 账务分录（借/贷两条）
对账：T+1 与渠道文件逐笔比对 → 差异分类（我方有他方无/金额不符/状态不符）→ 人工/自动处理
判据："支付系统里没有 UPDATE，只有 INSERT"——账务是只追加的事件流，余额是派生结果。任何"直接改余额"的设计都会在对账时暴露。
3.3 出行：时空索引与撮合
司机位置高频上报 → 地理索引（GeoHash / S2 / H3 网格）→ 附近司机查询
撮合：距离 + 评分 + 空闲时长 → 派单（抢单 or 指派）→ 超时重派
难点：位置数据量（百万司机 × 秒级）、撮合的公平性与体验、跨城调度
判据：不是"用了 Redis GEO 就做出约车"——难点在撮合策略与重派逻辑，索引只是入口。
3.4 物流：多段交接的状态一致
订单 → 仓内作业（拣货/打包）→ 干线运输 → 末端配送 → 签收
每段由不同主体操作系统 → 状态靠"事件上报 + 状态机"统一
核心不变量：状态只能前进不能回退（除逆向单）；每次交接有责任人与时间戳
判据：物流架构的本质是"跨组织状态机 + 对账"，不是"调度算法"。
4. 另外四套的要点速览
| 行业（旧文） | 核心不变量 | 关键设计 | 易错点 |
|---|---|---|---|
| 营销（3124） | 优惠不叠加超限、预算不透支 | 规则引擎 + 预算扣减 + 幂等发券 | 规则硬编码在业务代码；券重复发放 |
| 社交（3125） | 时间线可见性与扇出 | 推模式（写扩散）/ 拉模式（读聚合）混合 | 大 V 扇出打爆；拉黑/可见性遗漏 |
| 外卖（3126） | 履约时效与运力调度 | 商户/骑手/订单三边撮合 + 预计送达时间 | 高峰期运力不足；超时赔付规则 |
| 信贷（3129） | 风控决策可解释、还款计划准确 | 规则+模型决策流、账单试算、逾期状态机 | 计息口径（日利率/年化/复利）不一致 |
时间线扇出判据：
写扩散（推）：发帖时写入所有粉丝收件箱 → 读快，写放大（大 V 灾难）
读扩散（拉）：读时聚合关注列表 → 写轻，读慢、聚合成本高
混合：普通用户推、大 V 拉（阈值如粉丝 >10 万）
5. 从案例到自研：迁移检查表（E-S18-039）
□ 我的不变量是什么？（一句话，能写进代码断言）
□ 这套案例里，哪部分是"为它的规模而存在"？（我是否需要）
□ 哪些环节依赖了它特有的资源？（运力/牌照/渠道/供应链）
□ 我能否先做"单段"再扩"多段"？（避免一步到位）
□ 出故障时，我能否在 5 分钟内定位到是哪个环节？（可观测性）
□ 数据不一致时，我有没有对账与补偿？（不是"应该不会"）
□ 回滚方案？（开关、双写、灰度比例）
判据："抄骨架、不抄规模"——五段骨架可以照搬；为百万级并发做的分片/异步/多活，在你 1/100 的量级上是纯负担。
6. 反例：五种"抄完更难维护"
| 做法 | 后果 |
|---|---|
| 直接上分库分表（未到触发线） | 跨片查询、报表崩、运维成本翻倍 |
| 全链路异步化 | 用户看不到结果，客服无法解释 |
| 引入服务网格（团队 5 人） | 排障链路变长，收益为零 |
| 照抄"多活" | 一致性复杂度爆炸，实际只有单地域流量 |
| 抄大厂"中台" | 领域未稳定就抽象，改一次动全身 |
7. 自测
- 五段骨架？支撑面为什么决定"能不能上生产"？
- 库存不超卖的三种方案与判据？
- 支付三条硬约束？为什么"没有 UPDATE 只有 INSERT"？
- 时间线推/拉/混合的判据？
- 迁移检查表里最关键的三问？
答案
- 接入/领域/异步/存储/支撑；对账与可观测缺失时故障不可定位、不一致不可修复。
- 行锁/Redis 预扣/库存分桶；热点用 B/C 加对账，日常用 A。
- 借贷必平、幂等、可追溯；余额是事件流派生，改余额无法对账。
- 写扩散读快写放大大 V 灾难；读扩散写轻读慢；按粉丝阈值混合。
- 我的不变量是什么、哪些是为它的规模存在、不一致时有无对账补偿。
8. 下一篇
S18-X03 · 行业清单与职场随笔登记 —— 18 篇应用分类目录、9 篇职场随笔与 4 篇技术随笔（DDD 落地案例、字节码插桩、代码评审、笔记发布流程）的处置与去向。
本篇属于系列《S18 · 架构方法与领域建模》。旧文来源：A-3123–3130（八行业案例）；扩展点 E-S18-037/038/039。