常见的体系架构模式

之前查了一些设计模式，突然发现了架构设计模式，所以本文介绍下几种常见的架构模式及其简要介绍、用法和优缺点：

1. 分层模式（Layered Architecture）

   • 用法：将系统划分为多个逻辑层次，每一层提供服务给上一层，并使用下一层的服务。典型的例子包括表示层、业务逻辑层和数据访问层。
   • 优点：
     • 易于分工协作，降低耦合度。
     • 每一层可独立开发、测试和维护。
     • 提供清晰的责任分离和模块化结构。
   • 缺点：
     • 层与层之间的通信可能导致性能开销。
     • 可能产生过多的抽象层级，导致复杂性增加。
     • 不适用于需要高度灵活性或快速迭代响应的场景。

2. 客户端-服务器模式（Client-Server Pattern）

   • 用法：在分布式系统中，客户端发起请求，服务器处理请求并返回结果。例如Web应用、数据库查询等。
   • 优点：
     • 客户端和服务器职责明确，易于扩展和升级。
     • 支持多用户同时访问。
   • 缺点：
     • 单点故障问题（服务器端），需要高可用解决方案。
     • 网络延迟可能影响性能。
     • 难以实现复杂的交互逻辑和状态共享。

3. 主从设备模式（Master-Slave Pattern）

   • 用法：用于数据库复制、分布式计算等场景，一个主节点负责管理整个系统，多个从节点执行任务或者存储数据的副本。
   • 优点：
     • 能够实现负载均衡和容错。
     • 通过读写分离提高性能。
   • 缺点：
     • 主节点失效可能导致整个系统的中断。
     • 数据同步可能存在延时问题。
     • 从节点数量增加会加大管理和协调复杂度。

4. 管道-过滤器模式（Pipeline-Filter Pattern）

   • 用法：数据流经一系列处理单元（过滤器），每个过滤器对数据进行特定的处理后再传递给下一个。在多媒体处理、日志处理等领域广泛应用。
   • 优点：
     • 易于添加、移除或修改单个处理步骤。
     • 并行处理能力较强，支持流水线并发执行。
   • 缺点：
     • 如果过滤器之间有紧密依赖，可能会限制其重用性。
     • 处理过程中错误的传播和控制较为复杂。

5. 代理模式（Proxy Pattern）

   • 用法：为其他对象提供一种代理以控制对该对象的访问，比如远程代理、虚拟代理、保护代理等。
   • 优点：
     • 通过间接访问隐藏真实对象的复杂性。
     • 增强安全性，可以添加额外的权限验证和监控功能。
     • 支持延迟加载和优化资源消耗。
   • 缺点：
     • 添加了额外的间接访问开销。
     • 设计不当可能增加整体设计的复杂性。

6. 点对点模式（Peer-to-Peer Pattern）

   • 用法：网络中的所有节点地位平等，可以直接与其他节点通信和交换信息，如文件共享网络、区块链技术等。
   • 优点：
     • 高度分散化，无中心节点故容错能力强。
     • 扩展性好，随着节点增多，整体性能可能提升。
   • 缺点：
     • 控制和管理困难，容易出现一致性问题。
     • 对网络安全和隐私要求较高。

7. 事件总线模式（Event Bus Pattern）

   • 用法：作为一种消息传递机制，允许系统各组件发布和订阅事件，从而解耦组件间的直接联系。
   • 优点：
     • 提高系统的松耦合程度。
     • 支持异步处理和分布式系统集成。
   • 缺点：
     • 系统行为难以跟踪和调试。
     • 如果不正确地管理事件，可能导致内存泄漏或消息积压。

8. 模型-视图-控制器模式（Model-View-Controller Pattern, MVC）

   • 用法：在软件工程中用于构建用户界面，将数据模型、用户界面展示以及处理用户输入的逻辑分离成三个相互协作的部分。
   • 优点：
     • 提高代码可复用性和可维护性。
     • 易于进行前后端分离开发。
   • 缺点：
     • 当项目变得庞大时，MVC边界可能模糊不清。
     • 过于严格的分离可能导致额外的通信开销。

9. 黑板模式（Blackboard Pattern）

   • 用法：主要用于解决复杂、不确定性问题，多个知识源观察并更新全局黑板上的数据，寻找解决问题的最佳方案。
   • 优点：
     • 非确定性问题求解的有效方式。
     • 各个组件相对独立，易于扩展和重构。
   • 缺点：
     • 控制和协调各个组件较复杂。
     • 适用场景有限，非通用架构模式。

10. 解释器模式（Interpreter Pattern）

    • 注意：解释器模式通常属于软件设计模式而非体系架构模式，它主要用于设计语言解释器或表达式解析器。
    • 用法：定义语法或表达式的文法，并创建一个解释器来解释这些语法结构。
    • 优点：
      • 便于扩展新的语法规则。
      • 把复杂的问题转换为简单的解释规则集合。
    • 缺点：
      • 仅在特定情况下有效，如解析简单语言或表达式时。
      • 对于复杂的文法，维护和执行效率较低。
        其他的待再详细了解：

• 分层模式
• 客户端-服务器模式
• 主从模式
• 管道-过滤器模式
• 代理模式
• 对等模式
• 事件总线模式
• 模型-视图-控制器模式
• 黑板模式
• 解释器模式
• 事件驱动架构
• 微内核架构
• 微服务架构
• 基于空间的架构
• 面向对象风格
• 仓库风格
• 基于规则的系统风格
• 黑板系统风格
• C2风格
• 正交架构风格
• 异构风格
• 管道过滤器风格
  在《软件架构理论与实践》这本书中对上述架构模式有更详细的描述，大家有空可以再看下。