理解软件风格/模式

架构模式，也叫架构风格，一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些呈现定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。一个架构模式常常可以分解成很多个设计模式的联合使用。MVC模式就属于架构模式。

原文链接：https://zhuanlan.zhihu.com/p/644132764

在软件开发中，架构在塑造软件系统的结构和行为方面起着至关重要的作用。它提供了系统设计的蓝图，详细说明了组件如何相互交互以提供特定的功能。然而，由于可用的架构风格和模式多种多样，可能需要时间来辨别哪种方法最适合特定的项目或系统。本文旨在阐明这些概念，帮助您在架构工作中做出明智的决策。

架构风格与架构模式（Architectural Styles vs. Architectural Patterns）

在我们深入研究细节之前，区分架构风格和模式非常重要，因为这些术语通常可以互换使用，但具有不同的含义。

架构风格是高级策略，为一系列系统提供抽象框架。架构风格通过经常性地解决重复出现的问题来改进结构划分和促进设计重用。您可以将其视为指导建筑物或住宅设计的主题或美学。比如分层、事件驱动和微服务。

另一方面，架构模式更加具体，并且特定于系统内的特定问题或模块。它们为架构问题提供了结构化的解决方案，详细说明了如何针对特定功能构建组件和交互。它们与软件设计模式类似，但工作在更高的抽象级别。比如包括模型-视图-控制器 (MVC)、发布-订阅和无服务器。

虽然架构风格提供了一个广泛的框架，并且可以被视为系统设计的一般哲学，但架构模式是该框架内特定设计问题的具体解决方案。换句话说，架构风格描述了系统的总体结构，而架构模式解决了该结构中可能出现的特定设计问题。

在下面的部分中，我们将探讨十种关键的架构风格，每种风格都有各自的模式、原则、优点、缺点和应用。这些风格包括分层、基于组件、面向服务、分布式系统、领域驱动、事件驱动、关注点分离、解释器、并发和以数据为中心。通过了解这些风格和模式，您可以更好地驾驭健壮、可扩展和可维护的架构景观和设计系统。让我们深入了解一下吧！

“在软件设计的宏伟画卷中，风格是画笔的粗略笔触，而模式则是使杰作栩栩如生的复杂细节。”

终极备忘录（The Ultimate Cheatsheet）

为了帮助您了解架构风格和模式的广阔前景，创建了一个备忘单，其中包含了本文中讨论的所有关键点。此备忘单是一个便捷的参考指南，您可以使用它快速回忆每种架构风格和模式的主要特征。

软件架构风格备忘单（下载高分辨率： https: //bit.ly/architect-cheatsheet）

1. 分层架构风格（Layered Architecture Style）

分层架构是最常见的架构模式之一。它通常用于传统 Web 应用程序和企业应用程序。

• 原则：这种架构风格将关注点分为不同的层。一个典型的例子是三层架构：表示层、业务逻辑层和数据存储层。
• 优点：易于理解、测试和维护；每一层都可以独立开发和更新。
• 缺点：这会导致性能开销；影响多个层的更改实施起来可能具有挑战性。
• 应用程序：Web 应用程序、企业应用程序。
• 反模式：循环依赖、跳层。

1.1 分层（n 层）模式（Layered (n-tier) pattern）

n 层架构将系统分为 n 层，每层都有特定的职责。最常见的划分是三层：表示层、业务逻辑层和数据存储层。

分层（n 层）架构模式

1.2 干净/洋葱图案（Clean / Onion Pattern）

清洁架构，也称为洋葱架构，是一种强调系统内关注点分离的软件设计哲学。它将软件组织成同心层，以领域模型为核心，周围是特定于应用程序的层。外层依赖于内层，但反之则不然，从而促进高度解耦和隔离。这使得基础设施、UI 或外部机构的更改对业务逻辑的影响最小。它非常适合需要高可维护性、可测试性以及独立于 UI、数据库或外部框架的系统。

干净/洋葱架构模式

2. 基于组件的架构风格（Component-Based Architecture Style）

这种风格强调对整个软件系统中可用的广泛功能的关注点分离。

• 原则：这种架构风格将系统组织为松散耦合、可重用的组件。
• 优点：高水平的可重用性、灵活性和可维护性。
• 缺点：管理组件及其交互的复杂性。
• 应用程序：Web 应用程序、桌面应用程序、分布式系统。
• 反模式：组件过大、组件冗余。

2.1 面向对象模式（Object-oriented Pattern）

该模式是基于“对象”的范例，“对象”可以包含数据和代码：字段形式的数据（通常称为属性）和过程形式的代码（通常称为方法）。它促进封装、继承和多态性，使复杂系统的设计、实现和维护变得更加容易。

2.2 微内核模式（Microkernel Pattern）

该模式将最小功能核心（微内核）与扩展功能和客户特定部分分开。微内核包含核心功能，而其他功能则作为微内核的插件实现。这使得系统可以在不修改核心的情况下轻松扩展。

微内核架构模式

2.3 插件模式（Plug-in Pattern）

此模式允许通过添加新模块或插件来向应用程序添加新功能。新模块通过标准接口集成到应用程序中，从而使应用程序能够扩展和定制。此模式通常用于 Web 浏览器、媒体播放器和内容管理系统。

3. 面向服务的架构风格（Service-Oriented Architecture Style）

这种风格将软件设计为相互通信的服务集合。每项服务都是独立的，代表具有确定结果的特定业务活动。

• 原则：SOA 将应用程序设计为通过网络进行通信的服务集合。
• 优点：灵活性、可扩展性、可重用性和松耦合。
• 缺点：复杂性增加、网络依赖性增加以及潜在的性能问题。
• 应用程序：企业系统、Web 服务、微服务。
• 反模式：忽略业务需求，在不需要的地方使用 SOA。

3.1 面向服务的架构模式（SOA）（Service-Oriented Architecture Pattern）

该模式将软件设计为多个系统中使用的离散服务的集合。SOA 模型中的每个服务都是为了执行特定的业务功能而构建的，例如检查客户的信用评分、计算付款或处理抵押贷款。这些服务通过网络相互通信以实现特定活动，例如处理抵押贷款申请。SOA 促进了可重用性，因为多个应用程序和灵活性可以使用服务，因为可以修改或替换服务而不影响其他服务。

面向服务的架构架构模式（SOA）

3.2 代理模式（Broker Pattern）

在代理架构模式中，系统的组件通过代理实体进行通信。代理协调通信，例如转发请求以及传输结果和异常。该模式使用通过远程服务调用进行交互的解耦组件来构建分布式软件系统。

3.3 微服务模式（Microservice Pattern）

该模式将软件应用程序设计为一套小型服务，每个服务都在其进程中运行，并与轻量级机制（通常是 HTTP）进行通信。这些服务是围绕业务功能构建的，并且可以通过完全自动化的部署机制独立部署。这种模式允许快速、频繁且可靠地交付复杂的应用程序。

微服务架构模式

3.4 无服务器（函数即服务或 FaaS）模式（Serverless (Function as a Service or FaaS) Pattern）

在此模式中，应用程序在云环境中构建和运行，而不考虑服务器。云提供商动态管理机器资源的分配，开发人员可以只关注应用程序代码中的各个功能。此模式非常适合可扩展、事件驱动的应用程序。

4. 分布式系统架构风格（Distributed System Architecture Style）

这种风格是指位于联网计算机上的组件通过传递消息进行通信并协调其操作的系统。这些组件相互交互以实现共同的目标。

• 原则：此架构涉及多个系统通过网络协同工作，以对最终用户显示为单个系统。
• 优点：可扩展性、容错性和资源共享。
• 缺点：复杂性增加、网络依赖性以及与数据一致性相关的问题。
• 应用：分布式数据库、云计算、电信网络。
• 反模式：不考虑网络故障，忽略数据一致性挑战。

4.1 天基模式（Space-Based Pattern）

这种模式也称为元组空间或云架构，旨在通过在多个服务器之间均匀分配服务和资源来避免任何单点故障或性能瓶颈。它非常适合需要 100% 正常运行时间和水平可扩展性的大容量、关键任务应用程序，例如金融交易系统或在线游戏平台。

天基架构模式

4.2 点对点 (P2P) 模式（Peer-to-Peer (P2P) Pattern）

在这种模式中，网络中的每个参与者（对等点）既充当客户端又充当服务器，网络节点直接通信而不需要中央服务器。该模式用于需要分布式计算或资源共享的应用程序，例如文件共享网络或区块链技术。

点对点 (P2P) 架构模式

5. 领域驱动架构风格（Domain-Driven Architecture Style）

这种风格侧重于核心领域和领域逻辑，基于业务领域模型进行设计。它强调技术和领域专家之间的协作，以迭代地完善准确有效的模型来解决业务问题。

• 原则：专注于核心领域和领域逻辑，并基于领域模型进行设计。
• 优势：提高对复杂业务领域的理解并促进技术和业务团队之间的沟通。
• 缺点：对于简单的领域来说可能有点过分，并且需要深入的理解。
• 应用：复杂的业务系统、企业软件。
• 反模式：忽略普遍存在的语言，不涉及领域专家。

5.1六边形（端口和适配器）架构风格（Hexagonal (Ports & Adapters) Pattern）

这种模式允许应用程序同样由用户、程序、自动化测试或批处理脚本驱动，并独立于其最终运行时设备和数据库进行开发和测试。它将软件的业务逻辑与外部关注点分开，由端口和适配器驱动。此模式非常适合需要与其软件环境解耦的应用程序，使它们能够适应新环境。

六边形（端口和适配器）架构模式

5.2 领域驱动设计模式（Domain-Driven Design Pattern）

该模式是一种通过将实现连接到不断发展的模型来满足复杂需求的软件开发方法。它涉及实现和当前模型之间的密切关系，两者都有恒定的迭代周期。DDD 非常适合具有丰富、复杂的业务规则的复杂系统或域不断变化的系统。

领域驱动设计架构模式

6. 事件驱动架构风格（Event-Driven Architecture Style）

事件驱动架构是一种用于应用程序设计的软件架构和模型。对于事件驱动系统，事件的捕获、通信、处理和持久化是解决方案的核心结构。

• 原则：这种架构风格由用户操作、传感器输出或来自其他程序的消息等事件驱动。
• 优点：高度可扩展，松散耦合，促进实时或近实时的信息流。
• 缺点：由于异步编程而增加了复杂性，可能难以维护和调试。
• 应用程序：GUI 应用程序、实时分析、复杂事件处理。
• 反模式：忽略事件顺序，缺乏事件持久性。

6.1 事件驱动模式（Event-Driven Pattern）

事件驱动架构是一种流行的分布式异步架构模式，用于生成高度可扩展的应用程序。它还具有很强的适应性，可用于小型应用程序和大型复杂系统。

事件驱动架构模式

6.2 发布-订阅模式（Pub-Sub Pattern）

这是一种消息传递模式，消息的发送者（称为发布者）不会将消息编程为直接发送到特定的接收者（称为订阅者）。相反，发布的消息被表征为主题，而不知道可能有哪些订阅者（如果有）。类似地，订阅者表达对一个或多个主题的兴趣，并且仅接收感兴趣的消息，而不知道有哪些发布者（如果有）。此模式广泛用于异步系统中，以将生成事件的进程与使用事件的进程解耦，从而实现更大的可扩展性和控制。

7. 关注点分离架构风格（Separation of Concern Architecture Style）

关注点分离是一种设计原则，用于将计算机程序划分为不同的部分，每个部分处理一个单独的关注点。

• 原则：不同的功能领域由系统的单独、独立的部分处理。
• 优点：提高可理解性，降低复杂性，促进模块化和并行开发。
• 缺点：由于接口管理，这会增加复杂性，并且需要模块之间进行更多通信。
• 应用：几乎所有类型的软件系统。
• 反模式：混合关注点、缺乏清晰的模块边界。

7.1 MVC模式（MVC Pattern）

这种模式有助于将图形用户界面开发与业务或后端逻辑开发分开。MVC 的视图控制器负责从模型中公开数据对象，以便轻松管理和呈现这些对象。这种模式广泛应用于桌面和移动应用程序等广泛的用户交互领域。

7.2 MVP模式（MVP Pattern）

这是模型-视图-控制器 (MVC) 架构模式的派生。它主要用于构建用户界面。在 MVP 中，演示者承担“中间人”的功能。模型和视图完全分离，仅通过演示者相互通信。MVP 是现代 Web 应用程序的优秀架构，因为它可以更轻松地进行自动化单元测试并为项目提供干净的结构。

模型-视图-呈现器架构模式

8. 解释器架构风格（Interpreter Architecture Style）

解释器模式是一种设计模式，指定如何评估语言中的句子。基本思想是用专门的计算机语言为每个符号（终结符或非终结符）建立一个类。

• 原理：程序指令直接执行，无需事先转换为机器语言。
• 优点：更容易调试和测试，更灵活。
• 缺点：比编译语言慢，需要更多资源。
• 应用程序：脚本语言，一些高级编程语言。
• 反模式：在性能至关重要的情况下使用解释器。

解释器架构模式

8.1 解释器模式（Interpreter Pattern）

该设计模式指定了如何评估语言中的句子。基本思想是用专门的计算机语言为每个符号（终结符或非终结符）建立一个类。语言中句子的语法树是复合模式的一个实例，用于为客户评估（解释）该句子。此模式用于编程语言的编译器和解释器、正则表达式引擎以及处理和分析结构化文本数据。

9. 并发架构风格（Concurrency Architecture Style）

并发性是同时执行多个独立任务的系统的属性。

• 原则：程序的不同部分独立执行，可能同时执行。
• 优点：可以显着提高性能，尤其是在多核系统上。
• 缺点：设计和调试具有竞争条件和死锁的问题可能很复杂。
• 应用：实时系统、高性能计算、网络服务器。
• 反模式：忽略潜在的并发问题并且不正确同步共享资源。

9.1 编排模式（Orchestration Pattern）

在此模式中，控制器（“协调器”）控制服务之间的交互。它规定了业务逻辑的控制流并确保一切按提示发生。此模式通常用于必须协调多个服务并需要集中控制的复杂业务流程。

编排架构模式

9.2 编排模式（Choreography Pattern）

该模式实现了一个服务系统，其中每个服务独立工作并通过事件与其他服务交互。没有中央协调器。相反，每个服务都知道下一步要做什么。当您想要创建一个分散的、高度解耦的系统以提供更大的灵活性和可扩展性时，可以使用此模式。

编排架构模式

9.3 主从模式（Primary-Secondary Pattern）

该模式由两种类型的组件组成：主组件和从组件。主组件将工作分配给相同的辅助从组件，并根据这些辅助机器返回的结果计算最终结果。这种模式用于并行计算，通过将巨大的计算任务分配给多个处理器来更快地执行计算。

9.4 管道/管道过滤器模式（Pipeline / Pipe-Filter Pattern）

该模式涉及一系列处理元素（进程、线程、协程等），这些元素的排列使得一个元素的输出是下一个元素的输入。这个想法是将执行复杂处理的任务分解为可以重用的单独元素。此模式在 Unix 和类 Unix 操作系统中用于管道命令。

10.以数据为中心的架构（Data-Centric Architecture）

这种风格侧重于数据的组织和转换方式。它通常用于处理大量数据、执行复杂计算或需要高度可扩展的系统。

• 原则：数据库是架构的中心，所有交互都通过数据库发生。
• 优点：可以提供数据的一致性、完整性和可靠性。
• 弱点：可能会造成数据瓶颈和潜在的可扩展性问题。
• 应用程序：许多企业应用程序、CRM 系统和 ERP 系统。
• 反模式：忽略潜在的数据瓶颈，不考虑数据可扩展性。

10.1 命令查询职责分离 (CQRS) 模式（Command Query Responsibility Segregation (CQRS) Pattern）

此模式将数据存储的读取和写入操作分开。它可以独立扩展读取和写入工作负载并分别对其进行优化。此模式非常适合读写负载差异较大的应用程序。

命令查询职责分离 (CQRS) 架构模式

10.2 事件溯源模式（Event-Sourcing Pattern）

这种编程技术将应用程序进行的状态更改建模为不可变的事件序列或“日志”。事件溯源涉及存储触发状态更改的事件，而不是就地修改应用程序的状态。此模式用于需要了解导致当前状态的事件的系统，例如审核系统或实时协作应用程序。

10.3 河童图案（Kappa Pattern）

这是一种软件架构模式。Kappa 架构系统中存储的规范数据是仅附加的不可变日志，而不是使用 SQL 之类的关系数据库或 Cassandra 之类的键值存储。该模式用于实时数据处理系统。

10.4 拉姆达模式（Lambda Pattern）

这种数据处理架构旨在利用批处理和流处理方法来处理大量数据。它提供了一个强大的、容错的系统，可以防止硬件故障和人为错误。该模式用于大数据处理任务。

结论

总之，理解架构风格和模式对于任何软件架构师或开发人员都至关重要。这些样式和模式提供了一种沟通、记录和探索设计替代方案的方法。它们还提供常见问题的解决方案，节省时间和精力，并带来更强大和可维护的系统。

本文探讨了各种架构风格和模式，每种风格和模式都有优点、缺点和理想的用例。然而，这只是冰山一角。还有更多的风格和模式，而且新的风格和模式还在不断涌现中。

原文：

The Architect’s Blueprint: Understanding Software Styles and Patterns with Cheatsheet​medium.com/bytebytego-system-design-alliance/the-architects-blueprint-understanding-software-styles-and-patterns-with-cheatsheet-5c1f5fd55bbd