架构模式是具有某些共同特征的一系列可以被重复应用的架构实践总结归纳结果。 比如，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 解决方案）事件驱动的架构。 当不同的子系统必须对相同的事件数据执行不同类型的处理时，该架构设计模式相当有用。
大数据
大数据架构设计用来处理对传统数据库系统而言太大或太复杂的数据的引入、处理和分析。
大数据解决方案通常涉及一个或多个以下类型的工作负荷：
- 静态大数据源的批处理。
- 移动中的大数据的实时处理。
- 大数据的交互式浏览。
- 预测分析和机器学习。
大计算
大计算 是专业化的架构设计模式，适用于符合某些特定要求的工作负荷。 大数据将庞大的数据集划分为区块，针对要分析和报告的整个数据集执行并行处理。 大计算也称为高性能计算 (HPC)，它使用大量（数千个）核心执行并行计算。 应用领域包含仿方案包括图像渲染、流体动力学、金融风险建模、石油勘探、药物设计和工程应力分析等等。。
以下是大计算应用程序的一些典型特征：
- 工作可拆分为离散的任务，这些任务可以跨多个核心同时运行。
- 各任务都是有限的。 接收一些输入，执行某些处理操作，然后生成输出。 整个应用程序的运行时间（从数分钟到数天）有限。 常见模式是突然预配大量核心，在应用程序完成后，核心数量减少到零。
- 应用程序不需要全天候运行。 但是，系统必须处理节点故障或应用程序故障。
- 对于某些应用程序，任务是独立的且可并行运行。 在其他情况下，任务紧密耦合，这意味着它们必须交互或交换中间结果。 在该情况下，请考虑使用 InfiniBand 和远程直接内存访问 (RDMA) 等高速联网技术。
架构设计原则即约束
体系结构模式各类原则是对设计施加约束，包括可显示的元素集，以及这些元素之间允许的关系。 约束通过限制所选的范围来引导架构的“形状”。 当某个体系结构符合特定模式的约束时，就会显现某些所需属性。
例如，微服务中的约束包括：
- 服务代表单一责任。
- 每项服务都独立于其他服务。
- 数据专用于拥有此数据的服务。 服务不共享数据。
如果遵守这些约束，则会显现一个可在其中独立部署服务、隔离故障、频繁更新且很容易将新技术引入此系统架构中。
在选择某个系统架构设计模式之前，请确保了解该模式的基本原则和约束。 否则，最终可能会得到一个表面上符合该模式，但不能完全发挥该模式的最佳潜力的设计，所以有时说架构上的务实设计是非常重要。 有时，最好是放宽约束，而不是坚持体系结构的纯度。
下表总结了每个架构设计风格如何管理依赖项，以及最适合每个模式的域类型。
| 架构样式 | 依赖项管理 | 域类型 |
|---|---|---|
| N 层 | 按子网划分的水平层 | 传统的业务域。 更新频率较低。 |
| Web-队列-辅助角色 | 通过异步消息传送分离的前端和后端作业。 | 包含一些资源密集型任务的相对简单域。 |
| 微服务 | 通过 API 相互调用的垂直（功能）分解服务。 | 复杂域。 频繁更新。 |
| 事件驱动的架构。 | 生成者/使用者。 为每个子系统提供独立视图。 | IoT 和实时系统 |
| 大数据 | 将巨型数据集划分为小区块。 针对本地数据集执行并行处理。 | 批处理和实时数据分析。 使用机器学习进行预测分析。 |
| 大计算 | 将数据分配到数千个核心。 | 仿真等计算密集型域。 |
考虑难题和优势
约束也会带来挑战，因此，在采用其中的任何架构模式时，必须了解各自的利弊。 此架构模式在该子域和界定的上下文中是否利大于弊？
下面是在选择体系架构设计模式时要考虑的一些挑战类型：
-
复杂性。 该架构模式的复杂性对于域而言是否合理？ 反过来，该模式对于域而言是否过于简单？ 在这种情况下，风险是最终只设计出一个大杂烩，因为该体系结构无助于利落地管理依赖项。
-
异步消息传送和最终一致性。 异步消息传送可用于分离服务，并提高可靠性（因为消息可以重试）和可伸缩性。 但是，这也会在处理最终一致性方面带来挑战，并可能会导致出现重复消息。
-
服务间通信。 将应用程序分解为独立的服务时，风险是服务之间的通信会导致不可接受的延迟，或造成网络拥塞（例如，在微服务这个架构设计风格中经常会出现）。
-
可管理性。 管理应用程序、监视、部署更新以及其他操作的难度有多大？
单体
![[置顶]
软件架构学习小结](http://www.uml.org.cn/zjjs/images/2013090311.jpg)
