架构样式
架构样式是具有某些共同特征的一系列样式。 例如，N 层就是一个常见的体系结构样式。 最近以来，微服务架构开始受到青睐。 体系结构风格不需要使用特定的技术，但某些技术非常适合某些特定的体系结构。 例如，容器原生就能适应微服务。
样式概览
本节提供我们已识别的体系结构样式的概览，以及有关其用法的概要性注意事项。 请在链接的主题中阅读更多详细信息。
N 层
N 层 是适用于企业应用程序的传统体系结构。 可通过将应用程序划分成执行逻辑函数的层（例如呈现、业务逻辑和数据访问）来管理依赖关系。 一个层只能调用位于其下面的层。 但是，这种水平分层方式可能带来麻烦。 在不改动应用程序的其他部分的情况下，可能很难在应用程序的一个部分中引入更改。 这使得频繁的更新成为一项难题，限制添加新功能的速度。
N 层原生就很适合用于迁移已使用分层架构的现有应用程序。 因此，N 层往往出现在基础结构即服务 (IaaS) 解决方案中，或混合使用 IaaS 和托管服务的应用程序中。
Web-队列-辅助角色
对于单纯的 PaaS 解决方案，可以考虑 Web-队列-辅助角色 架构。 在此风格中，应用程序有一个处理 HTTP 请求的 Web 前端，以及一个执行 CPU 密集型任务或长时间运行的操作的后端辅助角色。 前端通过异步消息队列来与辅助角色通信。
Web-队列-辅助角色架构适合用于包含一些资源密集型任务的相对简单域。 与 N 层一样，该架构也很易于理解。 托管服务的使用简化了部署和操作。 但对于复杂的域，可能很难管理依赖项。 前端和辅助角可能很容易变成难以维护和更新的大型单体组件。 与 N 层一样，这可能会降低更新频率并限制创新。
微服务
如果应用程序包含更复杂的域，请考虑转移到 微服务 体系结构。 微服务应用程序由许多小型独立服务构成。 每个服务实现单个业务功能。 服务松散耦合，通过 API 协定通信。
每个服务可由小规模的专业开发团队构建。 无需在团队之间进行过多的协调即可部署单个服务，因此有利于频繁更新。 与 N 层或 Web-队列-辅助角色相比，微服务体系结构的构建和管理更复杂。 它需要成熟的开发和 DevOps 文化。 但如果实施得当，此样式可以加快发布速度，加速创新，提高体系结构的复原能力。
事件驱动的架构
事件驱动的架构 使用发布-订阅 (pub-sub) 模型，其中，生成者发布事件，使用者订阅事件。 生成者独立于使用者，使用者互相独立。
可考虑对以极低延迟引入和处理大量数据的应用程序（例如 IoT 解决方案）使用事件驱动的架构。 当不同的子系统必须对相同的事件数据执行不同类型的处理时，该样式也很有用。
大数据、大计算
大数据 和 大计算 是专业化的架构样式，适用于符合某些特定要求的工作负荷。 大数据将庞大的数据集划分为区块，针对要分析和报告的整个数据集执行并行处理。 大计算也称为高性能计算 (HPC)，它使用大量（数千个）核心执行并行计算。 应用领域包含仿真、建模和 3D 渲染。
架构样式即约束
体系结构样式对设计施加约束，包括可显示的元素集，以及这些元素之间允许的关系。 约束通过限制所选的范围来引导架构的“形状”。 当某个体系结构符合特定样式的约束时，就会显现某些所需属性。
例如，微服务中的约束包括：
- 服务代表单一责任。
- 每项服务都独立于其他服务。
- 数据专用于拥有此数据的服务。 服务不共享数据。
如果遵守这些约束，则会显现一个可在其中独立部署服务、隔离故障、频繁更新且很容易将新技术引入应用程序的系统。
在选择某个体系结构样式之前，请确保了解该样式的基本原则和约束。 否则，最终可能会得到一个表面上符合该样式，但不能完全发挥该样式的潜力的设计。 务实也很重要。 有时，最好是放宽约束，而不是坚持体系结构的纯度。
下表总结了每个样式如何管理依赖项，以及最适合每个样式的域类型。
| 架构样式 | 依赖项管理 | 域类型 |
|---|---|---|
| N 层 | 按子网划分的水平层 | 传统的业务域。 更新频率较低。 |
| Web-队列-辅助角色 | 通过异步消息传送分离的前端和后端作业。 | 包含一些资源密集型任务的相对简单域。 |
| 微服务 | 通过 API 相互调用的垂直（功能）分解服务。 | 复杂域。 频繁更新。 |
| 事件驱动的架构。 | 生成者/使用者。 为每个子系统提供独立视图。 | IoT 和实时系统 |
| 大数据 | 将巨型数据集划分为小区块。 针对本地数据集执行并行处理。 | 批处理和实时数据分析。 使用机器学习进行预测分析。 |
| 大计算 | 将数据分配到数千个核心。 | 仿真等计算密集型域。 |
考虑难题和优势
约束也会带来挑战，因此，在采用其中的任何样式时，必须了解各自的利弊。 该体系结构样式在该子域和界定的上下文中是否利大于弊？
下面是在选择体系结构样式时要考虑的一些挑战类型：
-
复杂性。 该体系结构的复杂性对于域而言是否合理？ 反过来，该样式对于域而言是否过于简单？ 在这种情况下，风险是最终只设计出一个大泥球，因为该体系结构无助于利落地管理依赖项。
-
异步消息传送和最终一致性。 异步消息传送可用于分离服务，并提高可靠性（因为消息可以重试）和可伸缩性。 但是，这也会在处理最终一致性方面带来挑战，并可能会导致出现重复消息。
-
服务间通信。 将应用程序分解为独立的服务时，风险是服务之间的通信会导致不可接受的延迟，或造成网络拥塞（例如，在微服务体系结构中）。
-
可管理性。 管理应用程序、监视、部署更新以及其他操作的难度有多大？
