架构模式

为什么要架构模式

架构模式的第一性分类轴

架构模式是对系统复杂性来源的不同应对方式。所有架构模式，均可投影到以下稳定维度上。

控制流主导权

数据与状态位置

构件耦合方式

演进与扩展方式

风格与模式的关系

核心区分

层次定义粒度典型示例
架构风格系统的高层次组织方式系统级分层、微服务、事件驱动
架构模式针对系统级反复出现问题的可复用解决方案跨组件CQRS、Saga、API Gateway

关系本质

架构模式 = 上下文（Context）+ 问题（Problem）+ 解决方案（Solution）架构风格 ≈ 解决方案的抽象结构

架构风格

架构风格关注的是：系统整体组织方式，决定了系统的依赖拓扑与约束条件集，它限定了变更的影响范围、扩展的可能性边界、以及团队组织的协作模式

数据流风格

根本问题驱动

驱动问题：如何在高吞吐量场景下保持处理步骤的解耦？

历史脉络：早期批处理系统面临的问题——强耦合导致任何步骤变化都影响整体；Unix 管道哲学的启示——ls | grep | wc 的组合智慧；核心洞察——数据流动天然适合并行化，且步骤之间无需共享状态

根本矛盾：高吞吐量需求 vs. 处理步骤间的耦合成本

本质

解决的根本问题

根本问题本质数据流风格的解法
提高吞吐量需要并行化但不想引入复杂同步数据流天然支持流水线并行
降低节点间的耦合需要修改一个步骤不影响其他步骤只通过数据交互，接口标准化

核心特征

节点间解耦：

子模式

批处理
管道-过滤器

代价

数据流风格的本质约束：数据必须流经整个管道                              ↓              带来了两个不可避免的代价：              1. 因果链断裂 → 调试困难              2. 管道延迟累加 → 实时性差

调用-返回风格

根本问题驱动

驱动问题：如何控制复杂系统的认知负担？

历史脉络：单体系统规模扩大后，缺乏结构化组织导致逻辑纠缠——所有逻辑纠缠在一起，无法理解、维护、修改；分而治之的思想起源——将大问题分解为可理解的小问题；核心洞察——层次化调用链使系统可被"逐层理解"

根本矛盾：系统的整体性 vs. 人类逐层理解的分段能力

本质

解决的根本问题

典型形态

代价

整洁架构

根本问题驱动

驱动问题：如何防止业务逻辑被技术细节绑架？

历史脉络：分层架构的困境——层间依赖方向混乱，业务逻辑依赖数据库/UI；核心洞察——依赖方向必须指向稳定，业务不应依赖易变的技术实现

根本矛盾：业务稳定性需求 vs. 技术实现的多变性

本质

同心圆结构，依赖方向指向内层。

+────────────────────────────────────────────────────────────────────+|                        Frameworks & Drivers                          ||   +------------------------------------------------------------+   ||   |                   Interface Adapters                        |   ||   |   +----------------------------------------------------+   |   ||   |   |                  Use Cases                          |   |   ||   |   |   +----------------------------------------+       |   |   ||   |   |   |                                        |       |   |   ||   |   |   |              Entities                  |       |   |   ||   |   |   |           (Business Rules)            |       |   |   ||   |   |   |                                        |       |   |   ||   |   |   +----------------------------------------+       |   |   ||   |   +----------------------------------------------------+   |   ||   +------------------------------------------------------------+   |+────────────────────────────────────────────────────────────────────+    依赖方向: 外层 ──────→ 内层                      ↓              依赖指向稳定

核心原则

稳定内核，易变边缘：

价值

与分层架构的关系

整洁架构是分层架构的更严格形式——通过同心圆结构明确了依赖方向必须指向内层，避免逆向依赖。

微内核架构

根本问题驱动

驱动问题：如何让系统核心保持稳定，同时支持功能的差异化扩展？

历史脉络：操作系统内核设计的经验——最小化内核 + 插件扩展；核心诉求——产品线需求（同一核心 + 不同特性）；核心洞察——变化的应被隔离，不变的应被固化

根本矛盾：核心稳定性需求 vs. 功能差异化扩展需求

本质

解决的根本问题

核心设计点

谦卑对象模式

将难测试部分隔离为简单的实现，让测试不依赖易变部分。是微内核架构实现可测试性的重要手段。

代价

仓库风格

根本问题驱动

驱动问题：如何在多个构件需要共享数据时避免直接耦合？

历史脉络：直接调用的问题——构件间形成网状耦合；共享数据的启示——围绕数据组织而非调用链组织；核心洞察——中央数据存储作为协调点，构件通过数据间接通信

根本矛盾：数据共享需求 vs. 构件直接耦合的风险

本质

典型形式

代价

架构模式

架构模式是在某一风格下，对特定问题的可复用解决方案。

事件驱动架构

根本问题驱动

驱动问题：如何在构件之间实现真正的时间解耦？

历史脉络：同步调用的困境——调用方必须等待被调用方完成；GUI 编程的启示——用户操作是事件，响应是事件处理器；核心洞察——状态变化是比调用更原语的事件

根本矛盾：时间解耦 vs 复杂性

本质

解决的根本问题

核心特征

两种组织方式

Mediator

有中心协调者

Broker

无中心协调者

代价

领域逻辑组织模式

决定了业务规则的结构化程度，直接影响系统对复杂度的抵抗能力和长期维护成本

关注：业务规则以什么形式存在。

事务脚本

事务脚本的隐含假设是：业务 = 操作序列

根本问题驱动

驱动问题：如何组织简单的业务逻辑？

历史脉络：简单业务场景——逻辑不复杂，不需要复杂的领域抽象；过程化编程的自然映射——一个请求 = 一个过程；核心洞察——复杂度不高时，最简单的结构就是最好的

适用条件：业务简单、生命周期短、逻辑无复用需求

本质

业务简单时，业务认知本身就是线性操作步骤，无需额外抽象

适用场景

演进风险

领域模型

根本问题驱动

驱动问题：如何用代码表达业务概念而非技术实现？

历史脉络：贫血模型的问题——业务逻辑散落在服务层，对象只是数据容器；面向对象应该同时包含数据和行为；核心洞察——领域模型是业务概念的软件映射

根本矛盾：业务表达清晰性需求 vs. 技术实现便捷性偏好

本质

领域模型是业务概念结构的同构映射——代码结构与业务结构一致。

核心价值

通过业务结构的同构映射，使业务复杂性可被结构化地分解和组织

代价

表模块

表模块的隐含假设是：业务 = 数据的增删改查。与事务脚本模式一样，都属于过程式思维

本质

特点

服务层

本质

引入动机

架构演进路径与阶段矛盾

架构模式并非静态选择，而是随业务规模、技术环境、团队能力动态演进的产物。

各阶段核心矛盾与对应模式

架构演进背后是每阶段核心矛盾的转移：

阶段核心矛盾驱动的架构变化
单体 → 分层认知负担 vs 业务复杂度分层解耦
分层 → 模块化单体部署效率 vs 扩展性需求模块化边界
单体/分层 → 服务化业务复用 vs 耦合成本SOA / ESB
单体 → 微服务迭代速度 vs 团队规模按领域拆分
同步 → 事件驱动响应实时性 vs 系统耦合异步解耦
微服务 → 服务网格治理复杂度 vs 业务聚焦Sidecar 代理

典型演进路径

路径一：单体到微服务（互联网路径）

单体架构 → 模块化单体 → 垂直拆分 → 核心域微服务化 → 完整微服务 → 服务网格

触发条件：

核心原则：渐进式演进，避免全量重构

路径二：分层到整洁架构（企业路径）

分层架构 → 依赖倒置 → 领域分层 → 整洁架构 → 插件化扩展

触发条件：

核心原则：依赖方向指向稳定，业务不依赖技术

路径三：事务到事件驱动（数据路径）

事务脚本 → 领域模型 → 事件溯源 → CQRS → 事件驱动

触发条件：

演进决策的判断标准

决策点单体/分层微服务事件驱动
团队规模小中大型任意规模
部署频率月级周/天级持续
扩展需求垂直扩展优先水平扩展优先弹性扩展
业务复杂度中低中高高
一致性要求强一致弱一致最终一致
团队能力要求低高中高

演进决策框架

业务复杂度低 + 团队小 + 扩展需求低└──→ 分层架构（默认起点）业务复杂度高 + 需技术灵活性└──→ 整洁架构 / 六边形架构团队规模扩大 + 部署频繁└──→ 模块化单体（过渡态）扩展压力大 + 需独立部署└──→ 微服务架构高并发 + 需实时响应└──→ 事件驱动 / 空间架构核心稳定 + 需差异化扩展└──→ 微内核架构

常见演进错误

错误表现后果
跳过中间态直接从单体到微服务分布式复杂度爆发
过度演进小团队强上微服务治理成本超过收益
进化不彻底模块化单体但边界模糊仍是单体困境
技术驱动演进为技术趋势而改造业务价值缺失

核心原则

  1. **渐进式演进优于革命性重构**：每次只跨一步
  2. **模式复杂度匹配问题复杂度**：不要超前设计
  3. **团队能力是演进上限**：选择团队能驾驭的下一个阶段
  4. **架构服务于业务价值**：演进目标而非技术纯粹性

架构设计不是选模式，而是管理复杂性来源。模式演进是对复杂性来源变化的回应。

反模式与常见误区

架构级反模式

大泥球

特征：系统缺乏可识别结构，模块边界模糊，相互缠绕。

后果：维护成本指数增长，系统脆弱，任何改动都可能引发意外故障。

根源：缺乏正式架构设计，开发者各自为政。

分布式单体

特征：将单体机械拆分为多个服务，但服务间高度耦合。

典型表现：所有服务使用同一套技术栈；服务间调用链过长；部署需要协调多个服务同时发布。

后果：继承分布式的复杂度，未获得分布式的收益。

过度分层

特征：层次过多，一个请求经过 5+ 层处理。

后果：延迟累加，追踪困难，增加不必要复杂度。

API 过度细分

特征：服务边界划出过细，一次业务操作需要客户端发起数十次调用。

后果：用户体验差，网络成为瓶颈。

决策级误区

误区特征后果
金锤思维对所有问题套用同一种架构忽视业务场景与团队能力匹配
过早优化为想象中的扩展需求设计复杂架构初期效率极低，团队被复杂度拖累
技术惯性新建服务默认复用已有技术栈失去技术多样性带来的灵活性
手段目标化把"使用某种架构"本身当作目标架构服务于技术趋势而非业务价值

反模式识别信号

信号可能对应的反模式
无法回答"系统如何扩展"大泥球
改动一个服务影响多个服务分布式单体
简单请求需要多次网络调用API 过度细分
无论场景都用同一种架构金锤思维
小项目但架构很复杂过早优化

关联内容（自动生成）