候选架构怎么生成：架构风格选型

第 1 课把驱动因素排好了序——现在用这份排序去"购物"：每种架构风格都是一个预先打包好的权衡组合，选型就是拿排序去匹配货架。

知识点一：风格是"预置权衡包"，不是身份认同

分层、微服务、事件驱动……这些架构风格不是时髦程度的排行榜，而是前人验证过的权衡组合：每种风格在某几个质量属性上强、在另几个上弱，且强弱是结构性的，换语言换框架都改不了。所以选风格的唯一正当依据，就是你第 1 课产出的驱动属性排序。

正式挑风格前，先回答两个先决问题（Richards & Ford 称之为架构的顶层决策）：

1. 必须分布式吗？系统需要几个能独立部署、独立伸缩的单元（架构量子）？答案是 1 → 单体族；>1 → 分布式族。
2. 数据必须拆吗？所有模块共用一个库，还是不同部分必须各管各的数据？数据拆分往往比服务拆分更难回头。

知识点二：六种主力风格速览

下表基于 Fundamentals of Software Architecture 各风格章节的星级评分整理（定性近似，完整星级表见文末资源）：

风格	简单/成本	伸缩/弹性	容错	可演进	典型场景
分层单体	⬤⬤⬤（最优）	低	低	低	小系统、原型、生命周期短
模块化单体	⬤⬤⬤	低-中	低	中-高	新系统默认起点；按领域分模块，留拆分余地
微内核	⬤⬤	低	低	高（插件维度）	产品型软件：核心稳定 + 定制插件（IDE、规则引擎）
服务化 (service-based)	⬤⬤	中	高	中-高	要部分分布式收益又不想付全额微服务税；常保留共享库
事件驱动	⬤	高	高	中	高吞吐异步流、广播扇出、削峰；调试与追踪难
微服务	⬤（最贵）	最高	高	最高	多团队并行、按域独立伸缩演进；强一致跨服务最难

注意每行的规律：伸缩/容错越强的风格，简单性/成本分越低——没有全五星的风格，这正是"权衡包"的含义。

知识点三：选型三步法

1. 用前三驱动属性定"族"。排序里有"独立伸缩、隔离故障、多团队独立交付"→ 分布式族；没有 → 单体族。约束一票否决：团队 3 个人，微服务直接出局，无论属性多匹配。
2. 族内按次要属性挑具体风格，对照上表逐项打分，落差最小者胜出。
3. 存疑时，默认单体优先。Martin Fowler 的观察：几乎所有成功的微服务系统都是从单体拆出来的，而从零直接建微服务的多数陷入困境（MonolithFirst）。分布式要付"微服务税"：运维、调试、数据一致性成本全面上涨——没有被驱动属性明确要求时，不要预付这笔税。

随堂测验

实战练习：拍卖系统 Kata（续）

沿用第 1 课的题目与你自己的驱动属性排序（一致性 > 可用性 > 伸缩/低延迟）。

你的任务（10 分钟）：

1. 先答两个先决问题：这个系统需要几个架构量子？数据要不要拆？
2. 按三步法选出你的风格（允许混合），写出 3 句理由——每句必须引用一个驱动属性。
3. 额外一问：如果团队只有 4 个人，你的方案变不变？

写完再看：参考答案

先决问题：至少 2 个量子——"出价/裁定"与"围观推送"的伸缩模式和一致性要求完全不同（前者强一致、写密集；后者高扇出、可容忍毫秒级延迟）。数据不必全拆：竞价核心单库保强一致，推送侧只消费事件流。

一种合理方案：服务化（service-based）主体 + 事件驱动推送通道。

1. 一致性第一 → 出价裁定收进单一服务、单一数据库，用单写入点/串行化保证唯一成交——这正是服务化保留共享库的优势，纯微服务的分库反而与第一驱动属性为敌。
2. 可用性第二 → 服务化的粗粒度服务各自独立部署、独立故障转移，满足"故障 5s 切换"且成本远低于微服务。
3. 伸缩/延迟第三 → 围观推送单独成量子，走事件驱动广播（出价事件 → 消息总线 → 推送集群横向扩），数万人扇出不回压竞价核心。

4 人团队？方案降级为：模块化单体（竞价+商品+账户为模块）+ 独立推送服务，共 2 个部署单元。驱动属性没变，但团队规模是约束，一票否决细粒度拆分——这就是约束与属性的区别。

你选了别的风格不代表错——检验标准只有一条：三句理由是否都能追溯到你的驱动属性排序，以及是否算过对应的代价。

课后延伸

主推资料源：Fundamentals of Software Architecture 第二部分——每种风格一章，附完整星级评分表；配套的风格星级速查表与驱动特性工作表（Developer to Architect，免费下载）值得打印贴墙。反方视角必读：Fowler 的 MonolithFirst 与 Microservice Premium，两篇都很短。

💬 对某个风格想深入、或想让我点评你的 Kata 选型——回到对话里直接提问。