架构师蓝图: 理解软件风格与模式

本文介绍了 10 种软件架构风格及其对应设计模式，梳理了各个风格的优缺点和适用场景，帮助读者在架构选项过程中能有的放矢，做出更适合业务场景的架构设计。原文: The Architect’s Blueprint: Understanding Software Styles and Patterns with Cheatsheet

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

架构风格(Architectural Styles) vs 架构模式(Architectural Patterns)

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

架构风格是为一系列系统提供抽象框架的高级策略。架构风格通过经常解决重复出现的问题来改进模块划分并促进设计重用。可以把它想象成指导建筑或住宅设计的主题或美学，具体实例包括分层(Layered)、事件驱动(Event-Driven)和微服务(Microservices)等。

另一方面，架构模式要更加具体，并且特定于系统中的特定问题或模块，为体系架构问题提供了结构化解决方案，详细说明了应该如何为特定功能构建组件和交互。架构模式类似于软件设计模式，但是工作在更高的抽象层次上。具体实例包括模型-视图-控制器(MVC，Model-View-Controller)、发布-订阅(Publish-Subscribe)和无服务器(Serverless)等。

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

下面我们将探讨十种关键的架构风格，每种风格都有其各自的模式、原则、优缺点和应用范围。这些风格包括分层(Layered)、基于组件(Component-Based)、面向服务(Service-Oriented)、分布式系统(Distributed System)、领域驱动(Domain-Driven)、事件驱动(Event-Driven)、关注点分离(Separation of Concern)、解释器(Interpreter)、并发(Concurrency)和以数据为中心(Data-Centric)。通过理解这些风格和模式，可以更好驾驭全局性体系架构，并设计出健壮、可伸缩和可维护的系统。让我们开始吧!

"在软件设计的宏伟图景中，风格是粗线条的轮廓，而模式是将杰作带入生活的复杂细节。"

终极备忘录

为了帮助读者浏览架构风格和模式的广阔景观，我创建了一个备忘录，包含了本文讨论的所有关键点。这个备忘录可以作为方便的参考指南，帮助读者快速回忆每种体系架构风格和模式的主要特征。

软件架构风格备忘录

1. 分层架构风格(Layered Architecture Style)

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

• 原则: 这种体系架构风格将关注点划分为不同的层。典型的例子是三层架构: 表示层、业务逻辑层和数据存储层。

• 优点: 易于理解、测试和维护，每一层都可以独立开发和更新。

• 缺点: 有额外的性能开销，影响多个层的更改可能很难实现。

• 应用: Web 应用、企业应用。

• 反模式: 循环依赖，跨层依赖。

分层(n 层)模式

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

分层(n 层)体系架构模式

整洁/洋葱模式

整洁体系架构，也被称为洋葱体系架构，是一种强调系统内关注点分离的软件设计哲学。它将软件组织成同心的层，以领域模型为核心，周围是特定于应用程序的层。外层只依赖内层，促进高度的解耦和隔离。这使得基础设施、UI 或外部代理的更改对业务逻辑的影响最小。对于需要高度可维护性、可测试性和独立于 UI、数据库或外部框架的系统来说，是理想的选择。

整洁/洋葱架构模式

2. 基于组件的体系架构风格

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

• 原则: 这种体系架构风格将系统组织为松耦合、可重用的组件。

• 优点: 高可重用性、灵活性和可维护性。

• 缺点: 管理组件及其交互的复杂性。

• 应用: Web 应用、桌面应用、分布式系统。

• 反模式: 过于庞大的组件，冗余的组件。

面向对象模式

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

微内核模式

此模式将最小功能核心(微内核)与扩展功能及特定于客户的部分分离开来。微内核包含核心功能，而其他特性则作为微内核的插件实现。这使得系统可以很容易扩展，而无需修改核心。

微内核架构模式

插件模式

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

3. 面向服务的体系架构风格

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

• 原则: SOA 将应用程序设计为通过网络进行通信的服务集合。

• 优点: 灵活性、可伸缩性、可重用性和松耦合。

• 缺点: 增加了复杂性、网络依赖性和潜在的性能问题。

• 应用: 企业系统、web 服务、微服务。

• 反模式: 忽略业务需求，在不需要 SOA 的地方使用 SOA。

面向服务的体系架构模式

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

面向服务的体系架构模式

代理(Broker)模式

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

微服务模式

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

微服务架构模式

无服务器(功能即服务或 FaaS)模式

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

4. 分布式系统架构风格

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

• 原则: 该架构涉及多个系统在网络上一起工作，对最终用户显示为单个系统。

• 优点: 可伸缩性、容错性和资源共享。

• 缺点: 增加了复杂性、网络依赖性以及与数据一致性相关的问题。

• 应用: 分布式数据库、云计算、电信网络。

• 反模式: 不考虑网络故障，忽略数据一致性挑战。

云架构模式

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

云架构模式

点对点(P2P)模式

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

点对点(P2P)架构模式

5. 领域驱动架构风格

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

• 原则: 关注核心领域和领域逻辑，并基于领域模型进行设计。

• 优点: 提高对复杂业务领域的理解，促进技术和业务团队之间的沟通。

• 缺点: 对于简单的领域，可能过度复杂，需要深入理解。

• 应用: 复杂业务系统、企业软件。

• 反模式: 忽略通用语言，不涉及领域专家。

六边形(端口和适配器)模式

这种模式允许应用程序能同时由用户、程序、自动化测试或批处理脚本驱动，并且可以在与最终运行时的设备和数据库隔离的情况下进行开发和测试。它将软件的业务逻辑与由端口和适配器驱动的外部关注点分离开来。对于需要与软件环境解耦的应用程序，此模式非常理想，有助于系统适应新的环境。

六边形(端口和适配器)架构模式

领域驱动设计模式

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

领域驱动体系架构模式

6. 事件驱动架构风格

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

• 原则: 这种架构风格由用户操作、传感器输出或来自其他程序的消息等事件驱动。

• 优点: 高度可伸缩、松耦合、适合处理实时或近实时信息流。

• 缺点: 由于异步编程而增加的复杂性可能难以维护和调试。

• 应用: GUI 应用程序，实时分析，复杂事件处理。

• 反模式: 忽略事件顺序，缺乏事件持久性。

事件驱动模式

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

事件驱动架构模式

发布-订阅模式

这是一种消息传递模式，其中消息的发送者(称为发布者)不将消息直接发送给特定的接收者(称为订阅者)。相反，发布的消息被划分为主题，发布者并不知道可能有哪些订阅者(如果有的话)。类似的，订阅者对一个或多个主题感兴趣，并且只接收感兴趣的消息，而不知道有哪些发布者(如果有的话)。此模式在异步系统中广泛使用，用于将产生事件的流程与消费事件的流程分离，从而实现更大的可伸缩性和控制。

7. 关注点分离架构风格

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

• 原则: 不同功能领域由系统中独立的部分处理。

• 优点: 提高可理解性，降低复杂性，促进模块化和并行开发。

• 缺点 :由于接口管理，这会增加复杂性，并且需要在模块之间进行更多通信。

• 应用: 几乎所有类型的软件系统。

• 反模式: 混合关注点，缺乏清晰的模块边界。

MVVC 模式

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

MVP 模式

这种模式派生于模型-视图-控制器(MVC)模式，主要用于构建用户界面。在 MVP 中，呈现者承担了"中间人"的功能，模型和视图是完全分离的，并且仅通过呈现者相互通信。MVP 是现代 web 应用的优秀架构，更容易实现自动化单元测试，并为项目提供了清晰的结构。

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

8. 解释器架构风格

解释器模式是一种设计模式，指定如何对语言中的句子求值。基本思想是在一种专门的计算机语言中为每个符号(终端或非终端)提供一个类。

• 原理: 程序指令直接执行，无需事先转换成机器语言。

• 优点: 更容易调试和测试，更灵活。

• 缺点: 比编译语言慢，需要更多资源。

• 应用: 脚本语言，一些高级编程语言。

• 反模式: 在性能至关重要的地方使用解释器。

解释器体系架构模式

解释器模式

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

9. 并发架构风格

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

• 原则: 程序的不同部分独立执行，也可能同时执行。

• 优点: 可以显著提高性能，特别是在多核系统上。

• 缺点: 设计和调试带有竞争条件和死锁的问题可能很复杂。

• 应用: 实时系统、高性能计算、web 服务器。

• 反模式: 忽略潜在的并发问题，未正确同步共享资源。

Orchestration 模式

在此模式中，控制器("调度器")控制服务之间的交互，指示业务逻辑的控制流，并确保一切都按调度进行。此模式通常用于必须协调多个服务并希望集中控制的复杂业务流程。

Orchestration 模式

Choreography 模式

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

Choreography 模式

主从模式

此模式由两种类型组件组成: Primary 和 Secondary。主(Primary)部件将工作分配给相同的附属(Secondary)部件，并根据从附属部件返回的结果计算出最终结果。这种模式用于并行计算，通过将巨大的计算任务分配给几个处理器来更快执行计算。

流水线(Pipeline)/管道过滤(Pipe-Filter)模式

这种模式涉及一系列处理组件(进程、线程、协程等)，以便一个组件的输出成为下一个组件的输入。其思想是将执行复杂处理的任务分解为可重用的独立组件。此模式用于 Unix 和类 Unix 操作系统中的管道命令。

10. 以数据为中心的体系架构

这种风格关注的是如何组织和转换数据，通常用于处理大量数据、执行复杂计算或需要高度可扩展的系统。

• 原则: 数据库是体系架构的中心，所有交互都通过数据库进行。

• 优点: 可以提供数据一致性、完整性和可靠性。

• 缺点: 可能造成数据瓶颈和潜在的可伸缩性问题。

• 应用: 企业应用、CRM 系统和 ERP 系统。

• 反模式: 忽略潜在的数据瓶颈，不考虑数据可伸缩性。

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

此模式将数据存储的读写操作分离，支持读写工作负载的独立伸缩，并分别对其进行优化。这种模式非常适合读写负载差异很大的应用程序。

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

事件源模式

这种技术将应用状态建模为不可变序列或事件"日志"。事件源不是就地修改应用状态，而是存储触发状态变更的事件。此模式用于需要知道导致当前状态的事件的系统中，例如审计系统或实时协作应用程序。

Kappa 模式

Kappa 架构系统中存储的规范化数据是只能追加的不可变日志，而不是 SQL 之类的关系数据库或 Cassandra 之类的键值存储。这种模式用于实时数据处理系统。

Lambda 模式

这种数据处理架构旨在利用批处理和流处理方法来处理大量数据，为硬件故障和人为错误提供了健壮、容错的系统。此模式用于大数据处理任务。

结论

总之，理解架构风格和模式对任何软件架构师或开发人员来说都至关重要。这些风格和模式提供了沟通、记录和探索设计可选方案的方法，为常见问题提供了解决方案，节省了时间和精力，帮助我们构建更健壮和可维护的系统。

本文探讨了各种体系架构风格和模式，每种风格和模式都有优缺点和理想用例。然而这只是冰山一角，还有更多更新的风格和模式在不断被开发出来。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！