在软件开发中，架构在塑造软件系统的结构和行为方面起着至关重要的作用。
它提供了系统设计的蓝图，详细说明了组件如何相互交互以提供特定的功能。
然而，由于可用的架构风格和模式多种多样，可能需要时间来辨别哪种方法最适合特定的项目或系统。
本文旨在阐明这些概念，帮助你在架构工作中做出明智的决策。
架构风格 vs 架构模式在我们深入研究细节之前，区分架构风格和模式非常重要，因为这些术语通常可以互换使用，但具有不同的含义。
架构风格（Architectural Styles）是高级别的策略，为一系列系统提供抽象框架。
架构风格通过为经常出现的问题提供解决方案来改进组成部分并促进设计重用。
你可以将其视为指导建筑物或住宅设计的主题或美学。
例子包括分层、事件驱动和微服务等。
而架构模式（Architectural Patterns）则更加具体，并且特定于系统内的特定问题或模块。
它们为架构问题提供了结构化的解决方案，详细说明了如何针对特定功能构建组件和交互。
它们与软件设计模式类似，但工作在更高的抽象级别。
例子包括模型-视图-控制器 (MVC)、发布-订阅（Publish-Subscribe）和无服务器（Serverless）等。
虽然架构风格提供了一个广泛的框架，并且可以被视为系统设计的一般哲学，但架构模式是该框架内特定设计问题的具体解决方案。
换句话说，架构风格描述了系统的总体结构，而架构模式解决了该结构中可能出现的特定设计问题。
在下面的部分中，我们将探讨十种关键的架构风格，每种风格都有各自的模式、原则、优点、缺点和应用。
这些风格包括分层、基于组件、面向服务、分布式系统、领域驱动、事件驱动、关注点分离、解释器、并发和以数据为中心。
通过了解这些风格和模式，你可以更好地驾驭架构领域，并设计出具有强大、可扩展和易维护性的系统。
我们一起来深入了解一下。

在软件设计的宏伟画卷中，风格是画笔的粗线条，而模式则是使杰作栩栩如生的复杂细节。
终极备忘录为了帮助你快速浏览架构风格和模式的广阔领域，下面为你提供了一个软件架构备忘录，其中包含了本文中讨论的所有关键点。
这个备忘录是一个极其方便的参考指南，你可以使用它快速回忆每种体系结构风格和模式的主要特征。
软件架构风格备忘录1、分层架构风格分层架构是最常见的架构模式之一。
它通常用于传统Web应用程序和企业级应用程序。
原则：这种架构风格将关注点分为不同的层。
一个典型的例子是三层架构：展现层、业务逻辑层和数据存储层。
分层（n层）模式n层架构将系统分为n层，每层都有特定的职责。
最常见的划分是三层：展现层、业务逻辑层和数据存储层。
分层（n层）架构模式整洁/洋葱模式整洁架构，也称为洋葱架构，是一种强调系统内部关注点分离的软件设计哲学。
它将软件组织成同心层，以领域模型为核心，周围是特定于应用程序的层。
外层依赖于内层，但内层不依赖于外层，这样促进了高度解耦和隔离。
这使得基础设施、UI或外部代理的更改对业务逻辑的影响最小。
它非常适合需要高可维护性、可测试性以及独立于UI、数据库或外部框架的系统。
整洁/洋葱架构模式2、基于组件的架构风格这种风格强调在整个软件系统中广泛可用功能进行关注点分离。
原则：这种架构风格将系统组织为松散耦合、可重用的组件。
面向对象模式该模式是基于“对象”的范例，“对象”可以包含数据和代码：字段形式的数据（通常称为属性）和过程形式的代码（通常称为方法）。
它促进封装、继承和多态性，使复杂系统的设计、实现和维护变得更加容易。
微内核模式该模式将最小功能核心（微内核）与扩展功能和客户特定部分分开。
微内核包含核心功能，而其他功能则作为微内核的插件实现。
这使得系统可以在不修改核心的情况下轻松扩展。
微内核模式插件模式此模式允许通过添加新模块或插件来向应用程序添加新功能。
新模块通过标准接口集成到应用程序中，从而使应用程序能够扩展和定制。
此模式通常用于Web浏览器、媒体播放器和内容管理系统。
3、面向服务架构风格这种风格将软件设计为相互通信的服务集合。
每项服务都是独立的，代表具有确定结果的特定业务活动。
原则：SOA将应用程序设计为通过网络进行通信的服务集合。
面向服务的架构模式（SOA）该模式将软件设计为多个系统中使用的离散服务的集合。
SOA模型中的每个服务都是为了执行特定的业务功能而构建的，例如检查客户的信用评分、计算付款或处理抵押贷款。
这些服务通过网络相互通信以实现特定活动，例如处理抵押贷款申请。
SOA促进了可重用性，因为多个应用程序可以灵活的使用服务，还可以修改或替换服务而不影响其他服务。
面向服务架构模式（SOA）代理模式（Broker Pattern）在代理架构模式中，系统的组件通过代理实体进行通信。
代理协调通信，例如转发请求以及传输结果和异常。
该模式使用通过远程服务调用进行交互的解耦组件来构建分布式软件系统。
微服务模式该模式将软件应用程序设计为一套小型服务，每个服务都在其独自的进程中运行并用轻量级机制（通常是HTTP）进行通信。
这些服务是围绕业务功能构建的，并且可以通过完全自动化的部署机制独立部署。
这种模式允许快速、频繁且可靠地交付复杂的应用程序。
微服务架构模式无服务器（函数即服务 或 FaaS）模式在此模式中，应用程序在云环境中构建和运行，而不需要考虑服务器。
云提供商动态管理机器资源的分配，开发人员可以只关注应用程序代码中的各个功能。
此模式非常适合可扩展、事件驱动的应用程序。
4、分布式系统架构风格这种风格是指位于网络上服务器中的组件系统通过消息来进行通信和协调。
这些组件相互交互以实现共同的目标。
原则：这种架构涉及多个系统通过网络协同工作，对最终用户而言表现为单个系统。
基于空间的模式这种模式也称为元组空间或云架构，旨在通过在多个服务器之间均匀分配服务和资源来避免任何单点故障或性能瓶颈。
它非常适合需要100%正常运行时间和水平可扩展性的大容量、关键任务应用程序，例如金融交易系统或在线游戏平台。
Space-Based Architecture Pattern点对点（P2P）模式在这种模式中，网络中的每个参与者（peer）既充当客户端又充当服务器，网络节点直接通信而不需要中央服务器。
该模式用于需要分布式计算或资源共享的应用程序，例如文件共享网络或区块链技术。
点对点(P2P)架构模式5、领域驱动架构风格这种风格侧重于核心领域和领域逻辑，基于业务领域模型进行设计。
它强调技术和领域专家之间的协作，以迭代的方式完善准确有效的模型来解决业务问题。
原则：专注于核心领域和领域逻辑，并将设计基于领域模型。
六边形（端口和适配器）模式这种模式允许应用程序平等地由用户、程序、自动化测试或批处理脚本驱动，并独立于其最终运行时的设备和数据库进行开发和测试。
它将软件的业务逻辑与外部关注点分开，由端口和适配器驱动。
此模式非常适合需要与其软件环境解耦的应用程序，使它们能够适应新环境。
六边形（端口和适配器）架构模式领域驱动设计模式该模式是一种通过将“实现”连接到不断发展的“模型”来满足复杂需求的软件开发方法。
它涉及“实现”和当前“模型”之间的密切关系，两者都有恒定的迭代周期。
DDD非常适合具有丰富、复杂业务规则的复杂系统或领域不断变化的系统。
领域驱动设计架构模式6、事件驱动架构风格事件驱动架构是一种用于应用程序设计的软件架构和模型。
对于事件驱动系统，事件的捕获、通信、处理和持久化是解决方案的核心结构。
原则：这种架构风格由用户操作、传感器输出或来自其他程序的消息等事件驱动的。
事件驱动模式事件驱动架构是一种流行的分布式异步架构模式，用于生成高度可扩展的应用程序。
它的适应性也很强，可用于小型应用程序和大型复杂系统。
事件驱动架构模式发布-订阅模式这是一种消息传递模式，消息的发送者（称为发布者）不会将消息直接发送到特定的接收者（称为订阅者）。
相反，发布的消息被归类到“主题”中，它并不知道可能有哪些订阅者（可能没有）。
类似地，订阅者可以对一个或多个主题感兴趣，并且仅接收感兴趣的消息，它并不知道有哪些发布者（如果有）。
此模式广泛用于异步系统中，将生成事件的进程与使用事件的进程解耦，从而实现更大的可扩展性和控制。
7、关注点隔离架构风格关注点分离是一种设计原则，用于将计算机程序划分为不同的部分，每个部分处理一个单独的关注点。
原则：不同的功能区域由系统的单独、独立的部分处理。
MVVC模式这种模式有助于将图形用户界面开发与业务或后端逻辑开发分开。
MVVC的视图控制器负责从模型中公开数据对象，以便轻松管理和呈现这些对象。
这种模式广泛应用于桌面和移动应用程序等大量的用户交互领域。
MVP模式它是模型-视图-控制器 (MVC) 架构模式的派生，主要用于构建用户界面。
在MVP中，展现者承担“中间人”的功能。
模型和视图完全分离，仅通过展现者相互通信。
MVP是现代Web 应用程序的优秀架构，因为它可以更轻松地进行自动化单元测试并为项目提供整洁的结构。
Model-View-Presenter Architecture Pattern8、解释器架构风格解释器模式是一种设计模式，用于定义如何解析和执行一个语言中的句子。
其基本思想是为语言中的每个符号（无论是终结符还是非终结符）创建一个对应的类，以实现对该符号的解释和执行操作。
原则：程序指令直接执行，无需事先转换为机器语言。
解释器架构模式解释器模式该设计模式指定了如何解析语言中的句子。
基本思想是用专门的计算机语言为每个符号（终结符或非终结符）建立一个类。
语言中的句子的语法树是组合模式的一个实例，并且被用来为客户端解释（评估）该句子。
这种模式通常在编程语言的编译器和解释器、正则表达式引擎以及处理和分析结构化文本数据时被使用。
9、并发架构风格并发性是同时执行多个独立任务的系统的属性。
原则：程序的不同部分独立执行，可能同时执行。
指挥模式在此模式中，控制器（指挥器）控制服务之间的交互。
它规定了业务逻辑的控制流并确保一切按提示发生。
此模式通常用在必须协调多个服务并需要集中控制流程的复杂业务。
指挥架构模式协作模式该模式实现了一个服务系统，其中每个服务都独立工作，并通过事件与其他服务进行交互。
没有中央指挥器，和指挥模式不一样的是，每个服务都知道接下来该做什么。
该模式用于创建分散化、高度解耦的系统，以实现更大的灵活性和可伸缩性。
协作架构模式主-备模式该模式由两种类型的组件组成：主要组件和备用组件。
主要组件将工作分配给相同的备用组件，并通过这些备用机器返回的结果计算出最终结果。
该模式在并行计算中使用，通过将庞大的计算任务分配给多个处理器，以加快计算速度。
管道/管道过滤器模式"。
该模式涉及一系列处理元素（进程、线程、协程等），这些元素的输出成为下一个元素的输入。
其思想是将执行复杂处理的任务拆分为可以重用的单独元素。
该模式在Unix和类Unix操作系统中用于命令的管道化处理。
10、以数据为中心架构该架构风格专注于数据的组织和转换。
它通常在处理大量数据、执行复杂计算或需要高度可伸缩性的系统中使用。
原则：数据库处于架构的中心，所有的交互都通过数据库进行。
命令查询职责分离（CQRS）模式该模式将数据存储的读操作和写操作分离开来。
它使读和写工作负载能够独立扩展，并对它们进行单独优化。
该模式适用于读和写负载之间存在较大差异的应用程序。
Command Query Responsibility Segregation (CQRS) Architecture Pattern事件溯源模式这种编程技术将应用程序的状态变化建模为一个不可变的事件序列或“日志”。
与直接在应用程序中修改状态不同，事件源模式涉及存储触发状态变化的事件。
这种模式适用于需要了解导致当前状态的事件的系统，例如审计系统或实时协作应用程序。
简单来说，事件源模式将应用程序的状态变化记录为一个事件的序列，而不是直接修改状态，这使得我们可以追踪并了解到达当前状态的所有事件。
Kappa模式这是一种软件架构模式。
Kappa架构系统中，它不像使用SQL等关系型数据库或像Cassandra这样的键值存储，它存储的典型数据是一个只追加不可变的日志。
该模式在实时数据处理系统中使用。
Lambda模式这种数据处理架构旨在通过利用批处理和流式处理方法来处理大量的数据。
它提供了一个健壮的、容错的系统，能够应对硬件故障和人为错误。
该模式在大数据处理任务中使用。
结语总之，对于任何软件架构师或开发人员来说，理解架构风格和模式是至关重要的。
这些风格和模式提供了一种交流、记录和探索设计方案的方式。
它们还提供了解决常见问题的解决方案，节省时间和精力，并带来更强大和可维护的系统。
在本文章中，我们探讨了各种架构风格和模式，每种都具有自身的优势、劣势和理想的使用案例。
然而，这些只是冰山一角。
还有许多其他风格和模式存在，并且新的风格和模式也在不断涌现。
参考文章：https://medium.com/bytebytego-system-design-alliance/the-architects-blueprint-understanding-software-styles-and-patterns-with-cheatsheet-5c1f5fd55bbd

（图片来源网络，侵删）