你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
体系结构样式是共享特定特征的体系结构系列。 例如， N 层 是一种常见的体系结构样式。 最近， 微服务体系结构 开始获得青睐。 体系结构样式不需要使用特定技术，但某些技术更适合某些体系结构。 例如，容器非常适合微服务。
我们已确定在云应用程序中通常发现的一组体系结构样式。 有关每个样式的文章包括：
- 样式的说明和逻辑关系图。
- 有关何时选择此样式的建议。
- 优点、挑战和最佳做法。
- 使用相关 Azure 服务的建议部署。
样式概览
本部分简要介绍我们识别的体系结构样式，并给出一些重要注意事项以供使用。 此列表并不详尽。 阅读链接主题中的更多详细信息。
N 层
N 层 是企业应用程序的传统体系结构。 通过将应用程序划分为执行逻辑函数 的层 （例如呈现、业务逻辑和数据访问）来管理依赖项。 层只能调用位于其下方的层。 但是，这种水平分层可能是一种隐患。 在不改动应用程序的其他部分的情况下，可能很难在应用程序的一个部分中引入更改。 这使得频繁更新成为挑战，限制了新功能的添加速度。
N 层非常适合用于迁移已使用分层体系结构的现有应用程序。 因此，N 层最常出现在基础结构即服务（IaaS）解决方案或应用程序（使用 IaaS 和托管服务的组合）中。
Web-队列-辅助角色
对于纯粹的 PaaS 解决方案，请考虑使用 Web-Queue-Worker 体系结构。 在此架构中，应用程序具有一个 Web 前端，用于处理 HTTP 请求，以及执行 CPU 密集型任务或长时间运行任务的后端工作进程。 前端通过异步消息队列与工作者通信。
Web -Queue-Worker 适用于具有一些资源密集型任务的相对简单的域。 与 N 层一样，体系结构易于理解。 托管服务简化部署和操作。 在复杂的领域中，管理依赖项可能会很困难。 前端和辅助角可能很容易变成难以维护和更新的大型单体组件。 与 N 层一样，Web-Queue-Worker 可以降低更新频率并限制创新。
微服务
如果应用程序具有更复杂的域，请考虑迁移到 微服务 体系结构。 微服务应用程序由许多小型独立服务组成。 每个服务实现单个业务功能。 服务是松散耦合的，通过 API 协定进行通信。
每个服务都可以由一个小型集中的团队开发。 可以通过最小化跨团队的协调来部署单个服务，从而支持频繁更新。 与 N 层或 WebQueue-Worker 体系结构相比，微服务体系结构对于生成和作更为复杂。 它需要成熟的开发和 DevOps 文化。 但是，使用正确的做法，此方法可能会导致更高的发布速度、更快的创新以及更具弹性的体系结构。
事件驱动的架构
Event-Driven 体系结构 使用发布-订阅（pub-sub）模型，其中生成者发布事件，使用者订阅它们。 生产者独立于消费者，消费者彼此独立。
对于引入和处理大量数据且延迟较低的应用程序，例如物联网（IoT）解决方案，请考虑事件驱动的体系结构。 当不同的子系统必须对同一事件数据执行不同类型的处理时，该样式也很有用。
大数据，大计算
大数据 和 大计算 是专为符合特定配置文件的工作负载打造的体系结构模式。 大数据将大型数据集拆分为区块，并在整个集中执行并行处理以进行分析和报告。 大型计算（也称为 高性能计算）跨数千个核心执行并行计算。 常见域包括模拟、建模和 3D 渲染。
架构风格作为约束
体系结构样式对设计设置了约束，包括可以显示的元素集以及这些元素之间的允许关系。 约束通过限制选择的宇宙来引导体系结构的“形状”。 当体系结构符合特定样式的约束时，会出现某些理想的属性。
例如，微服务中的约束包括：
- 服务代表单一责任。
- 每个服务都独立于其他服务。
- 数据对拥有它的服务来说是私有的。 服务不共享数据。
通过遵循这些约束，出现的情况是一个系统，可以在其中独立部署服务、隔离故障、频繁更新，并且可以轻松地将新技术引入应用程序中。
每种架构风格都有各自的权衡。 在选择体系结构样式之前，必须了解基本原则和约束。 如果缺乏这种理解，你可能会创建一个设计，该设计仅仅在表面上符合样式，而未能实现设计的全部优点。 更注重选择特定样式的原因，而不是如何实现它。 实事求是。 有时，放松约束比追求建筑纯洁更好。
理想情况下，应使用来自知情工作负荷利益干系人的输入来选择体系结构样式。 工作负荷团队应首先确定要解决的问题的性质。 然后，它们应定义关键业务驱动因素和相应的体系结构特征，也称为 非功能要求，并设置优先级。 例如，如果上市时间至关重要，团队可能会优先考虑可维护性、可测试性和可靠性，以实现快速部署。 如果团队的预算限制严格，可行性和简单性可能会优先。 选择和维护体系结构样式不是一次性任务。 它需要持续测量、验证和优化。 由于以后改变体系结构方向的成本可能很高，因此通常值得先投入更多精力来支持长期效率并减少风险。
下表总结了每种样式如何管理依赖项，以及最适合每个样式的域类型。
| 体系结构样式 | 依赖项管理 | 域类型 |
|---|---|---|
| N 层 | 按子网划分的水平层 | 传统业务领域。 更新频率较低。 |
| Web-队列-辅助角色 | 前端和后端工作，通过异步消息传递解耦。 | 具有一些资源密集型任务的相对简单的域。 |
| 微服务 | 通过 API 相互调用的垂直（功能）分解服务。 | 复杂域。 频繁更新。 |
| 事件驱动的体系结构 | 生产者或消费者。 每个子系统的独立视图。 | IoT 和实时系统。 |
| 大数据 | 将大型数据集划分为小块。 本地数据集上的并行处理。 | 批处理和实时数据分析。 使用 ML 进行预测分析。 |
| 大型计算 | 将数据分配到数千个核心。 | 计算密集型域，例如模拟。 |
考虑挑战和优势
约束也会带来挑战，因此在采用这些样式时必须了解权衡。 对于此子域和边界上下文，采用这种体系结构风格的好处是否大于挑战。
下面是选择体系结构样式时要考虑的一些挑战类型：
复杂。 体系结构的复杂性必须与域匹配。 如果它过于简单，就可能导致一团乱架构，其中依赖项管理不好，结构混乱。
异步消息传送和最终一致性。 异步消息传送用于分离服务并提高可靠性，因为可以重试消息。 它还增强了可伸缩性。 但是，异步消息传送也会在处理最终一致性和重复消息的可能性方面带来挑战。
服务间通信。 将应用程序分解为单独的服务可能会增加通信开销。 在微服务体系结构中，这种开销通常会导致延迟问题或网络拥塞。
可管理性。 管理应用程序包括监视、部署更新和维护作运行状况等任务。