架构风格是什么
架构风格是一组经过大量项目验证的结构组织方式，规定了组件如何划分、如何通信、依赖往哪个方向流动。它解决的是“这类问题的通用骨架”，而不是项目本身的业务决策。风格大体分两类：单体类适合部署简单、变更为主的场景，分布式类适合弹性与独立演进优先的场景。选风格之前先确定架构特征的优先级，否则容易按偏好而非需求做选择。
风格分类
| 类别 | 代表风格 | 典型取舍 |
|---|---|---|
| 单体类 | 分层、管道-过滤器、微内核、面向服务 | 部署与调试简单，弹性与独立演进受限 |
| 分布式类 | 服务化、事件驱动、空间型、微服务 | 弹性与解耦提升，分布式复杂度显著上升 |
| 数据类 | 读写分离、CQRS、事件溯源 | 查询与写入各自优化，一致性模型更复杂 |
| 局部风格 | 插件式、六边形、整洁架构 | 隔离核心与外部依赖，需额外抽象成本 |
基本信息
| 选择依据 | 先定架构特性优先级（性能、可用性、可维护性等）再选风格 |
|---|---|
| 组合方式 | 风格可叠加，如分层 + 事件驱动 + CQRS |
| 常见误区 | 把风格当目标追求，忽略团队规模与运维能力 |
| 验证方式 | 用质量属性场景把风格承诺转成可测指标 |
| 记录载体 | 架构决策记录（ADR）写明背景、选项与取舍理由 |
典型使用场景
- 项目启动选型：按架构特征优先级挑出两三个候选风格做对比
- 架构评审：检查所选风格是否真的支撑了宣称的质量属性
- 遗留系统改造：识别现有系统实际使用的风格，找出与预期的偏差
- 性能优化取舍：在分层与事件驱动之间权衡延迟与解耦程度
- 团队能力匹配：按现有运维与自动化水平选择可承载的风格
- 外包方案评估：用风格判断供应商方案是否与业务约束匹配
风格是手段而不是目标：同一个业务用不同风格都能实现，差别在于维护成本落在哪一段、由谁承担。
在没有明确质量属性优先级时直接选“更先进”的风格，通常得到的是复杂度上升、收益无法验证的系统。