架构模式是具有某些共同特征的⼀系列可以被重复应⽤的架构实践总结归纳结果。⽐如，N 层就是⼀个常见的体系结构模式。最近以来，流⾏的微服务架构也是⼀种模式。体系结构风格不依据使⽤特定的技术，但某些技术⾮常适合某些特定的体系结构。例如，容器原⽣就能适应微服务。后续的⽂章我将介绍应⽤程序中常⽤的体系结构模式。有关每个模式的⽂章包括： 该模式的说明和逻辑关系图。
有关何时选择该样式的建议。烘手机
优点、挑战和最佳做法。
模式导览
本节提供我们常⽤的体系架构设计时使⽤模式的导览，以及有关其⽤法的概要性注意事项。其详情可以查阅《云原⽣架构设计快速⼊门》相关的架构主题来深⼊学习。
N层
N层是适⽤于企业应⽤程序的传统体系架构设计模式，这种应⽤⼀般表现单体形式。可通过将应⽤程序划分成执⾏逻辑函数的层（例如经典三层：呈现层、业务逻辑层和数据访问层）来管理依赖关系。第N层只能调⽤位于其下⾯的第N-1层。但是，这种⽔平分层⽅式可能带来⿇烦。在不改动应⽤程序的其他部分的情况下，可能很难在应⽤程序的⼀个部分中引⼊更改。这使得频繁的更新成为⼀项难题，限制添加新功能的速度。
⽽基于各种云计算基础设置的N层原⽣就很适合⽤于迁移已使⽤此分层架构的现有应⽤程序。因此，N 层往往出现在基础结构即服务 (IaaS)解决⽅案中，或混合使⽤ IaaS 和托管服务的应⽤程序中。
WEB应⽤-队列-辅助⾓⾊
对于单纯的 PaaS 解决⽅案，可以考虑WEB应⽤-队列-辅助⾓⾊架构。在此类架构设计风格中，应⽤程序有⼀个处理 HTTP 请求的 Web 前端，以及⼀个执⾏ CPU 密集型任务或长时间运⾏的操作的后端辅助⾓⾊。前端通过异步消息队列来与辅助⾓⾊通信。
Web-队列-辅助⾓⾊架构适合⽤于包含⼀些资源密集型任务的相对简单域。与N层⼀样，该架构也很⽐较易于理解。云计算带来托管服务的使⽤简化了部署和操作。但对于复杂的域，可能很难管理依赖项。前端和辅助⾓可能很容易变成难以维护和更新的⼤型单体组件。与 N 层⼀样，这可能会降低更新频率并限制创新。
微服务
如果应⽤程序包括相当复杂的业务域，请考虑转移到微服务体系结构设计模式。微服务应⽤程序体系架构设计的风格是由许多⼩型独⽴服务构成。每个独⽴的服务实现相对单⼀的业务功能。服务松散耦合，通过 API 协定通信。其每个服务可由⼩规模的专业开发团队构建。⽆需在团队之间进⾏过多的协调⼯作即可部署单个服务，此模式有利于需求演进相对较快的架构场景。但与 N 层架构或 Web-队列-辅助⾓⾊等架构模式相⽐，微服务体系结构的构建和管理显得更复杂。它需要成熟的开发和 DevOps 团队⽀持。但如果实施得当，此架构模式可以显著加快发布速度，加速创新，提⾼体系结构的复原能⼒。
事件驱动的架构
事件驱动的架构设计模式使⽤经典的发布-订阅 (pub-sub) 模型，其中⽣产者发布事件，消费者订阅事件。⽣产者独⽴于消费者，双⽅互相独⽴。
可考虑对那些能容忍极低延迟并且有着极⼤量数据处理需求的应⽤程序导⼊（例如 IoT 解决⽅案）事件驱动的架构。当不同的⼦系统必须对相同的事件数据执⾏不同类型的处理时，该架构设计模式相当有⽤。
⼤数据
⼤数据架构设计⽤来处理对传统数据库系统⽽⾔太⼤或太复杂的数据的引⼊、处理和分析。
⼤数据解决⽅案通常涉及⼀个或多个以下类型的⼯作负荷：
静态⼤数据源的批处理。
移动中的⼤数据的实时处理。lc低通滤波器
⼤数据的交互式浏览。
预测分析和机器学习。
⼤计算
⼤计算是专业化的架构设计模式，适⽤于符合某些特定要求的⼯作负荷。⼤数据将庞⼤的数据集划分为区块，针对要分析和报告的整个数据集执⾏并⾏处理。⼤计算也称为⾼性能计算 (HPC)，它使⽤⼤量（数千个）核⼼执⾏并⾏计算。应⽤领域包含仿⽅案包括图像渲染、流体动⼒学、⾦融风险建模、⽯油勘探、药物设计和⼯程应⼒分析等等。。
以下是⼤计算应⽤程序的⼀些典型特征：
⼯作可拆分为离散的任务，这些任务可以跨多个核⼼同时运⾏。
顾婷婷是什么梗各任务都是有限的。接收⼀些输⼊，执⾏某些处理操作，然后⽣成输出。整个应⽤程序的运⾏时间（从数分钟到数天）有限。常见模式是突然预配⼤量核⼼，在应⽤程序完成后，核⼼数量减少到零。
应⽤程序不需要全天候运⾏。但是，系统必须处理节点故障或应⽤程序故障。
天线制作对于某些应⽤程序，任务是独⽴的且可并⾏运⾏。在其他情况下，任务紧密耦合，这意味着它们必须交互或交换中间结果。在该情况下，请考虑使⽤ InfiniBand 和远程直接内存访问 (RDMA) 等⾼速联⽹技术。
架构设计原则即约束
体系结构模式各类原则是对设计施加约束，包括可显⽰的元素集，以及这些元素之间允许的关系。约束通过限制所选的范围来引导架构
的“形状”。当某个体系结构符合特定模式的约束时，就会显现某些所需属性。
例如，微服务中的约束包括：
服务代表单⼀责任。
每项服务都独⽴于其他服务。
数据专⽤于拥有此数据的服务。服务不共享数据。
如果遵守这些约束，则会显现⼀个可在其中独⽴部署服务、隔离故障、频繁更新且很容易将新技术引⼊此系统架构中。
在选择某个系统架构设计模式之前，请确保了解该模式的基本原则和约束。否则，最终可能会得到⼀个表⾯上符合该模式，但不能完全发挥该模式的最佳潜⼒的设计，所以有时说架构上的务实设计是⾮常重要。有时，最好是放宽约束，⽽不是坚持体系结构的纯度。
下表总结了每个架构设计风格如何管理依赖项，以及最适合每个模式的域类型。
表 1
架构样式依赖项管理域类型
ddtsfN 层按⼦⽹划分的⽔平层传统的业务域。更新频率较低。
Web-队列-辅助⾓⾊通过异步消息传送分离的前端和后端作业。包含⼀些资源密集型任务的相对简单域。
微服务通过 API 相互调⽤的垂直（功能）分解服务。复杂域。频繁更新。
事件驱动的架构。⽣成者/使⽤者。为每个⼦系统提供独⽴视图。IoT 和实时系统
⼤数据将巨型数据集划分为⼩区块。针对本地数据集执⾏并⾏处理。批处理和实时数据分析。使⽤机器学习进⾏预测分析。⼤计算将数据分配到数千个核⼼。仿真等计算密集型域。
考虑难题和优势
约束也会带来挑战，因此，在采⽤其中的任何架构模式时，必须了解各⾃的利弊。此架构模式在该⼦域和界定的上下⽂中是否利⼤于弊？下⾯是在选择体系架构设计模式时要考虑的⼀些挑战类型：
复杂性。该架构模式的复杂性对于域⽽⾔是否合理？反过来，该模式对于域⽽⾔是否过于简单？在这种情况下，风险是最终只设计出⼀个⼤杂烩，因为该体系结构⽆助于利落地管理依赖项。
球头挂环异步消息传送和最终⼀致性。异步消息传送可⽤于分离服务，并提⾼可靠性（因为消息可以重试）和可伸缩性。但是，这也会在处理最终⼀致性⽅⾯带来挑战，并可能会导致出现重复消息。
服务间通信。将应⽤程序分解为独⽴的服务时，风险是服务之间的通信会导致不可接受的延迟，或造成⽹络拥塞（例如，在微服务这个架构设计风格中经常会出现）。
可管理性。管理应⽤程序、监视、部署更新以及其他操作的难度有多⼤？
单体
