软件架构模式
相关源文件
目的与范围
本文档提供了软件架构模式的全面概述，这些模式是针对常见系统设计问题的可重用解决方案。它涵盖了基础架构风格、设计模式和方法论，这些有助于开发人员创建可维护、可扩展且健壮的软件系统。有关真实系统中特定实现的更多信息，请参阅真实案例研究。有关云特定架构的详细信息，请参阅云和分布式系统。
来源：README.md225-249
基础架构模式
软件架构模式代表了系统的最高层结构，并定义了组件如何交互。以下是现代软件开发中最常用的六种架构模式。
图示：核心架构模式之间的关系
来源：README.md242
单体架构
在单体架构中，应用程序的所有组件相互连接，并作为一个单元运行。所有功能都由一个平台上的一个应用程序进行管理和提供。
特性
- 单一部署单元
- 共享数据库
- 紧密耦合的组件
- 更简单的开发工作流程
- 随着复杂性增长，可伸缩性和维护性方面面临挑战
用例
- 复杂性有限的小型应用程序
- MVP 和原型
- 需求简单、定义明确的应用程序
- 事务一致性至关重要的系统
来源：README.md242 README.md230-231
微服务架构
微服务架构将应用程序组织成松散耦合、独立部署的服务集合。每项服务都实现特定的业务功能，并通过定义良好的 API 进行通信。
图示：典型的微服务架构组件
特性
- 独立部署
- 服务特定数据库
- 松散耦合
- 技术异构性
- 弹性和故障隔离
- 复杂的编排和监控
最佳实践
- 每个服务职责单一
- 独立数据存储
- 基于 API 的通信
- 自动化部署（CI/CD）
- 分散式治理
- 为故障而设计
- 监控和可观测性
- 定义良好的服务边界
- 智能端点，哑管道
来源：README.md230-232 README.md238-239 README.md248
面向服务架构（SOA）
SOA 将应用程序组织成离散的、可重用的服务，这些服务通过网络上的标准协议进行通信。它强调不同系统之间的互操作性和服务可重用性。
特性
- 业务对齐服务
- 标准化服务契约
- 服务抽象
- 服务可重用性
- 通过企业服务总线 (ESB) 进行通信
- 与微服务相比，服务更大、粒度更粗
来源：README.md242
事件驱动架构
事件驱动架构基于事件的生成、检测和消费。组件通过事件异步通信，从而实现松散耦合和可扩展性。
图示：基本事件驱动架构流程
特性
- 解耦的生产者和消费者
- 异步通信
- 可扩展性
- 实时处理
- 事件溯源和 CQRS 兼容性
常见模式
- 事件通知
- 事件驱动状态传输
- 事件溯源
- CQRS（命令查询责任分离）
来源：README.md132-133 README.md306-307 README.md248
分层架构
分层架构将组件组织成水平层，每一层执行特定的角色。上层使用下层的服务，实现了关注点分离。
图示：标准分层架构
常见层
- 表现层（UI）
- 应用层（服务/进程）
- 领域层（业务逻辑）
- 基础设施层（数据访问/持久化）
来源：README.md242
无服务器架构
无服务器架构允许开发人员在不管理服务器基础设施的情况下构建应用程序。云提供商动态管理服务器的分配和预配。
特性
- 无需服务器管理
- 函数即服务 (FaaS)
- 事件驱动执行
- 微服务兼容性
- 自动伸缩
- 按执行付费定价模型
来源：README.md242 README.md301-302 README.md312
设计模式
设计模式是针对常见软件设计问题的标准化解决方案。它们分为三种主要类型：创建型、结构型和行为型模式。
图示：设计模式类别
创建型模式
创建型模式关注对象创建机制，力求以适合情况的方式创建对象。
常见创建型模式
- 单例：确保类只有一个实例，并提供对该实例的全局访问点
- 工厂方法：在不指定要创建的对象的确切类的情况下创建对象
- 抽象工厂：提供一个接口，用于创建相关对象的族
- 建造者：将复杂对象的构建与其表示分离
- 原型：通过复制现有对象来创建新对象
结构型模式
结构型模式处理对象组合以及对象之间的关系，以形成更大的结构。
常见结构型模式
- 适配器模式：允许不兼容的接口协同工作
- 桥接：将抽象与其实现分离
- 组合：将对象组合成树形结构，以表示部分-整体层次结构
- 装饰器：动态地为对象添加职责
- 外观：为复杂子系统提供简化的接口
- 代理：为另一个对象提供代理，以控制对它的访问
行为型模式
行为型模式侧重于对象之间的通信，以及它们如何交互和分发职责。
常见行为型模式
- 观察者模式：定义对象之间的一对多依赖关系
- 策略：定义一系列算法并使它们可互换
- 命令模式：将请求封装为对象
- 迭代器：提供一种顺序访问集合元素的方法
- 状态：允许对象在其内部状态发生变化时改变其行为
- 责任链：沿着处理程序链传递请求
- 中介者：定义一个对象，该对象封装了一组对象如何交互
来源：README.md233-234 README.md236
领域驱动设计 (DDD)
领域驱动设计是一种软件开发方法，侧重于通过领域专家和软件开发人员之间的协作来演进领域（问题空间）的模型。
图示：领域驱动设计的关键组件
DDD 中的关键概念
- 通用语言：开发人员和领域专家之间的通用语言
- 限界上下文：特定模型适用的边界
- 实体：具有贯穿时间的明确身份的对象
- 值对象：没有身份的不可变对象
- 聚合：具有明确边界的实体和值对象的集群
- 仓储：存储和检索领域对象的机制
- 领域服务：自然不属于实体或值对象的运算
- 领域事件：领域专家关心的事件
来源：README.md234-235 README.md240
UI架构模式
这些模式专门用于组织用户界面组件及其相关逻辑。
图示：UI 架构模式之间的关系
模型-视图-控制器 (MVC)
将应用程序分为三个主要逻辑组件
- 模型：数据和业务逻辑
- 视图：用户界面
- 控制器：处理和响应事件，在模型和视图之间进行协调
模型-视图-呈现器 (MVP)
MVC 的演进，其中
- 模型：数据和业务逻辑
- 视图：用户界面（被动）
- 呈现器：从模型中检索数据并对其进行格式化以供视图使用
模型-视图-视图模型 (MVVM)
旨在将 UI 开发与业务逻辑分离
- 模型：数据和业务逻辑
- 视图：用户界面元素
- 视图模型：视图和模型之间的中介，处理视图逻辑
VIPER（iOS 架构）
为 iOS 应用提供更精细的分离
- 视图：UI 元素
- 业务逻辑：业务逻辑
- 呈现器：UI 逻辑，准备来自业务逻辑的数据供视图使用
- 实体：基本模型对象
- 路由器：导航逻辑
来源：README.md246
权衡与选择标准
选择架构模式时，请考虑以下权衡
图示：架构选择中的复杂性权衡
模式选择的关键考虑因素
- 可伸缩性要求：系统需要增长多少？
- 复杂性管理：领域有多复杂？
- 团队结构：组织结构影响架构选择
- 开发速度：某些模式可以实现更快的开发周期
- 部署约束：基础设施和部署考虑因素
- 运营开销：维护和监控的复杂性
- 性能要求：响应时间和吞吐量需求
- 容错性：所需的弹性级别
- 技术栈：现有技术和约束
- 预算和资源：可用时间、金钱和专业知识
来源：README.md237 README.md308-309
实施挑战与最佳实践
成功实施架构模式需要了解常见挑战并遵守最佳实践。
常见挑战
- 分布式系统复杂性：管理网络延迟、容错
- 数据一致性：维护跨组件的数据完整性
- 服务边界：定义适当的服务边界
- 通信开销：高效处理服务间通信
- 监控和调试：跨分布式组件跟踪问题
- 安全顾虑：保护组件间的通信安全
- 性能优化：平衡灵活性与性能
- 迁移挑战：从单体架构迁移到分布式架构
最佳实践
- 从业务领域开始：将架构与业务需求对齐
- 演进式设计：迭代地演进架构
- 自动化：实施 CI/CD 实践
- 可观测性：构建监控、日志记录和跟踪
- 测试策略：制定全面的测试方法
- 文档：维护最新的文档
- 标准化：建立一致性指南
- 设计即安全：从一开始就融入安全性
来源：README.md232 README.md239 README.md241
总结
软件架构模式提供了标准化的方法来构建系统，以解决特定的设计问题。通过了解每种模式的优势、劣势和适用环境，架构师可以做出明智的决策，平衡技术要求与业务目标。
架构的选择应基于
- 特定的问题领域
- 预期的规模和性能要求
- 团队结构和能力
- 长期可维护性目标
- 业务约束和优先级
没有一种通用的架构模式是绝对最优的；最佳选择取决于正在开发的系统的具体上下文和需求。
来源：README.md225-249