关于后端:架构师蓝图-理解软件风格与模式

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

在软件开发过程中，架构在塑造软件系统的构造和行为方面起着至关重要的作用。架构为零碎设计提供蓝图，具体阐明组件如何互相交互以交付特定性能。然而，因为有大量可用的体系架构格调和模式，分别哪种办法最适宜特定的我的项目或零碎可能须要付出大量工夫。本文旨在说明相干概念，帮忙读者在架构工作中做出理智决策。

在深入研究细节之前，很重要的一点是要辨别架构格调和模式，这些术语通常能够调换应用，但具备不同的含意。

架构格调 是为一系列零碎提供形象框架的高级策略。架构格调通过常常解决反复呈现的问题来改良模块划分并促成设计重用。能够把它设想成领导修建或住宅设计的主题或美学，具体实例包含分层 (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)。通过了解这些格调和模式，能够更好驾驭全局性体系架构，并设计出强壮、可伸缩和可保护的零碎。让咱们开始吧!

“ 在软件设计的雄伟图景中，格调是粗线条的轮廓，而模式是将杰作带入生存的简单细节。”

为了帮忙读者浏览架构格调和模式的广大景观，我创立了一个备忘录，蕴含了本文探讨的所有关键点。这个备忘录能够作为不便的参考指南，帮忙读者疾速回顾每种体系架构格调和模式的次要特色。

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

准则: 这种体系架构格调将关注点划分为不同的层。典型的例子是三层架构: 表示层、业务逻辑层和数据存储层。
长处: 易于了解、测试和保护，每一层都能够独立开发和更新。
毛病: 有额定的性能开销，影响多个层的更改可能很难实现。
利用: Web 利用、企业应用。
反模式: 循环依赖，跨层依赖。

分层 (n 层) 模式

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

整洁 / 洋葱模式

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

这种格调强调对整个软件系统中可用的宽泛性能的关注拆散。

准则: 这种体系架构格调将零碎组织为松耦合、可重用的组件。
长处: 高可重用性、灵活性和可维护性。
毛病: 治理组件及其交互的复杂性。
利用: Web 利用、桌面利用、分布式系统。
反模式: 过于宏大的组件，冗余的组件。

面向对象模式

这种模式是基于 ” 对象 ” 的范式，对象能够蕴含数据和代码: 字段模式的数据 (通常称为属性) 和过程模式的代码(通常称为办法)。该模式促成了封装、继承和多态，使设计、实现、保护简单零碎变得更加容易。

微内核模式

此模式将最小性能外围 (微内核) 与扩大性能及特定于客户的局部拆散开来。微内核蕴含外围性能，而其余个性则作为微内核的插件实现。这使得零碎能够很容易扩大，而无需批改外围。

插件模式

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

这种格调将软件设计为互相通信的服务汇合。每个服务都是自蕴含的，代表具备确定后果的特定业务流动。

准则: SOA 将利用程序设计为通过网络进行通信的服务汇合。
长处: 灵活性、可伸缩性、可重用性和松耦合。
毛病: 减少了复杂性、网络依赖性和潜在的性能问题。
利用: 企业零碎、web 服务、微服务。
反模式: 疏忽业务需要，在不须要 SOA 的中央应用 SOA。

面向服务的体系架构模式

这种模式将软件设计为多个零碎可复用的离散服务的汇合。SOA 模型中的每个服务都是为执行特定业务性能而构建的，例如查看客户的信用评分、计算付款或解决抵押贷款。这些服务通过网络互相通信，以实现特定流动，例如解决抵押贷款申请。SOA 促成了可重用性，多个利用能够灵便应用服务，特定服务能够在不影响其余服务的状况下被批改或替换。

代理 (Broker) 模式

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

微服务模式

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

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

在此模式中，应用程序在云环境中构建和运行，不须要思考服务器。云服务商动静治理机器资源的调配，开发人员能够只关注利用代码中的单个性能。此模式非常适合可伸缩的事件驱动应用程序。

这种格调指的是由一组组件交互实现独特指标的零碎，这些组件位于联网的计算机上，通过传递音讯进行通信以及协调相互的动作。

准则: 该架构波及多个零碎在网络上一起工作，对最终用户显示为单个零碎。
长处: 可伸缩性、容错性和资源共享。
毛病: 减少了复杂性、网络依赖性以及与数据一致性相干的问题。
利用: 分布式数据库、云计算、电信网络。
反模式: 不思考网络故障，疏忽数据一致性挑战。

云架构模式

这种模式旨在通过在多个服务器均匀分布服务和资源来防止任何单点故障或性能瓶颈，非常适合须要 100% 失常运行工夫和程度可扩展性的大容量、要害工作型应用程序，例如金融交易零碎或在线游戏平台。

点对点 (P2P) 模式

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

这种格调侧重于外围畛域和畛域逻辑，基于业务畛域模型进行设计，强调技术和领域专家之间的合作，迭代的改良模型，使其精确而无效的解决业务问题。

准则: 关注外围畛域和畛域逻辑，并基于畛域模型进行设计。
长处: 进步对简单业务畛域的了解，促成技术和业务团队之间的沟通。
毛病: 对于简略的畛域，可能适度简单，须要深刻了解。
利用: 简单业务零碎、企业软件。
反模式: 疏忽通用语言，不波及领域专家。

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

这种模式容许应用程序能同时由用户、程序、自动化测试或批处理脚本驱动，并且能够在与最终运行时的设施和数据库隔离的状况下进行开发和测试。它将软件的业务逻辑与由端口和适配器驱动的内部关注点拆散开来。对于须要与软件环境解耦的应用程序，此模式十分现实，有助于零碎适应新的环境。

畛域驱动设计模式

此模式是通过将实现连贯到一直倒退的模型来实现简单需要的软件开发办法，波及实现和模型之间的密切关系，在两者之间有恒定的迭代周期。DDD 非常适合具备丰盛、简单业务规定的简单零碎，或者畛域处于一直变动中的零碎。

事件驱动体系架构是用于利用程序设计的软件体系架构和模型。对于事件驱动零碎，事件的捕捉、通信、解决和长久化是解决方案的外围架构。

准则: 这种架构格调由用户操作、传感器输入或来自其余程序的音讯等事件驱动。
长处: 高度可伸缩、松耦合、适宜解决实时或近实时信息流。
毛病: 因为异步编程而减少的复杂性可能难以保护和调试。
利用: GUI 应用程序，实时剖析，简单事件处理。
反模式: 疏忽事件程序，不足事件持久性。

事件驱动模式

事件驱动架构是一种风行的分布式异步架构模式，用于生成高度可伸缩的应用程序，具备很高的适应性，可用于小型应用程序和大型简单零碎。

公布 - 订阅模式

这是一种消息传递模式，其中音讯的发送者 (称为发布者) 不将音讯间接发送给特定的接收者(称为订阅者)。相同，公布的音讯被划分为主题，发布者并不知道可能有哪些订阅者(如果有的话)。相似的，订阅者对一个或多个主题感兴趣，并且只接管感兴趣的音讯，而不晓得有哪些发布者(如果有的话)。此模式在异步零碎中宽泛应用，用于将产生事件的流程与生产事件的流程拆散，从而实现更大的可伸缩性和管制。

关注点拆散是一种设计准则，外围是将计算机程序划分为不同局部，每个局部解决一个独自的关注点。

准则: 不同性能畛域由零碎中独立的局部解决。
长处: 进步可了解性，升高复杂性，促成模块化和并行开发。
毛病 : 因为接口治理，这会减少复杂性，并且须要在模块之间进行更多通信。
利用: 简直所有类型的软件系统。
反模式: 混合关注点，不足清晰的模块边界。

MVVC 模式

此模式有助于将图形用户界面开发与业务或后端逻辑开发拆散开来。MVVC 的视图控制器负责从模型中公开数据对象，以便这些对象易于治理和出现。此模式宽泛用于桌面和挪动利用等宽泛的用户交互畛域。

MVP 模式

这种模式派生于模型 - 视图 - 控制器 (MVC) 模式，次要用于构建用户界面。在 MVP 中，出现者承当了 ” 中间人 ” 的性能，模型和视图是齐全拆散的，并且仅通过出现者互相通信。MVP 是古代 web 利用的优良架构，更容易实现自动化单元测试，并为我的项目提供了清晰的构造。

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

原理: 程序指令间接执行，无需当时转换成机器语言。
长处: 更容易调试和测试，更灵便。
毛病: 比编译语言慢，须要更多资源。
利用: 脚本语言，一些高级编程语言。
反模式: 在性能至关重要的中央应用解释器。

解释器模式

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

并发是同时执行多个独立工作的零碎的一种属性。

准则: 程序的不同局部独立执行，也可能同时执行。
长处: 能够显著进步性能，特地是在多核零碎上。
毛病: 设计和调试带有竞争条件和死锁的问题可能很简单。
利用: 实时零碎、高性能计算、web 服务器。
反模式: 疏忽潜在的并发问题，未正确同步共享资源。

Orchestration 模式

在此模式中，控制器 (“ 调度器 ”) 管制服务之间的交互，批示业务逻辑的控制流，并确保所有都按调度进行。此模式通常用于必须协调多个服务并心愿集中控制的简单业务流程。

Choreography 模式

此模式实现一个服务零碎，每个服务独立工作，通过事件与其余服务交互，没有地方调度者。相同，每个服务都晓得下一步该做什么。当咱们想要创立扩散的、高度解耦的零碎，以实现更多的灵活性和可伸缩性时，能够应用此模式。

主从模式

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

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

这种模式波及一系列解决组件(过程、线程、协程等)，以便一个组件的输入成为下一个组件的输出。其思维是将执行简单解决的工作合成为可重用的独立组件。此模式用于 Unix 和类 Unix 操作系统中的管道命令。

这种格调关注的是如何组织和转换数据，通常用于解决大量数据、执行简单计算或须要高度可扩大的零碎。

准则: 数据库是体系架构的核心，所有交互都通过数据库进行。
长处: 能够提供数据一致性、完整性和可靠性。
毛病: 可能造成数据瓶颈和潜在的可伸缩性问题。
利用: 企业应用、CRM 零碎和 ERP 零碎。
反模式: 疏忽潜在的数据瓶颈，不思考数据可伸缩性。

命令查问职责拆散 (CQRS) 模式

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

事件源模式

这种技术将利用状态建模为不可变序列或事件 ” 日志 ”。事件源不是就地批改利用状态，而是存储触发状态变更的事件。此模式用于须要晓得导致以后状态的事件的零碎中，例如审计零碎或实时合作应用程序。

Kappa 模式

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

Lambda 模式

这种数据处理架构旨在利用批处理和流解决办法来解决大量数据，为硬件故障和人为谬误提供了强壮、容错的零碎。此模式用于大数据处理工作。

总之，了解架构格调和模式对任何软件架构师或开发人员来说都至关重要。这些格调和模式提供了沟通、记录和摸索设计可选计划的办法，为常见问题提供了解决方案，节俭了工夫和精力，帮忙咱们构建更强壮和可保护的零碎。

本文探讨了各种体系架构格调和模式，每种格调和模式都有优缺点和现实用例。然而这只是冰山一角，还有更多更新的格调和模式在一直被开发进去。

你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。为了不便大家当前能第一工夫看到文章，请敌人们关注公众号 ”DeepNoMind”，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的反对和能源，激励我继续写下去，和大家独特成长提高！

本文由 mdnice 多平台公布

关于后端:架构师蓝图-理解软件风格与模式

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

终极备忘录

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