通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

架构样式

体系结构样式是一系列共享某些特征的体系结构。 例如， N 层 是一种常见的体系结构样式。 最近， 微服务体系结构 已开始获得青睐。 体系结构样式不需要使用特定技术，但某些技术非常适合某些体系结构。 例如，容器自然适合微服务。

我们已确定在云应用程序中通常发现的一组体系结构样式。 有关每个样式的文章包括：

  • 样式的说明和逻辑关系图。
  • 有关何时选择此样式的建议。
  • 优点、挑战和最佳做法。
  • 使用相关 Azure 服务的建议部署。

样式概览

本部分简要介绍我们识别的体系结构样式，并给出一些重要注意事项以供使用。 请注意，该列表并不详尽。 阅读链接主题中的更多详细信息。

N 层

N 层体系结构样式的逻辑关系图。

N 层 是企业应用程序的传统体系结构。 通过将应用程序划分为执行逻辑函数 的层 （例如呈现、业务逻辑和数据访问）来管理依赖项。 层只能调用位于其下方的层。 但是，这种水平分层可能是一种隐患。 在不改动应用程序的其他部分的情况下，可能很难在应用程序的一个部分中引入更改。 这使得频繁更新成为挑战，限制了新功能的添加速度。

N 层很适合迁移已使用分层体系结构的现有应用程序。 因此，N 层最常出现在基础结构即服务（IaaS）解决方案或使用 IaaS 和托管服务的应用程序中。

Web-队列-辅助角色

Web-Queue-Worker 体系结构样式的逻辑关系图。

对于纯粹的 PaaS 解决方案，请考虑使用 Web-Queue-Worker 体系结构。 在此架构中，应用程序具有一个 Web 前端，用于处理 HTTP 请求，以及执行 CPU 密集型任务或长时间运行任务的后端工作进程。 前端通过异步消息队列与工作者通信。

Web-队列-辅助角色架构适合用于包含一些资源密集型任务的相对简单域。 与 N 层一样，体系结构易于理解。 托管服务的使用简化了部署和操作。 在复杂的领域中，管理依赖项可能会很困难。 前端和辅助角可能很容易变成难以维护和更新的大型单体组件。 与 N 层一样，这可以减少更新频率并限制创新。

微服务

微服务架构风格的逻辑图。

如果应用程序具有更复杂的域，请考虑迁移到 微服务 体系结构。 微服务应用程序由许多小型独立服务组成。 每个服务实现单个业务功能。 服务是松散耦合的，通过 API 协定进行通信。

每个服务都可以由一个小型集中的开发团队构建。 可以在团队之间部署单个服务，而无需进行大量协调，从而鼓励频繁更新。 与 N 层或 Web-队列-辅助角色相比，微服务体系结构的构建和管理更复杂。 它需要成熟的开发和 DevOps 文化。 如果做得好，这种风格可能会导致发布速度更快、创新更迅速，并且体系结构更加具有弹性。

事件驱动的架构

事件驱动架构样式图。

Event-Driven 体系结构 使用发布-订阅（pub-sub）模型，其中生成者发布事件，使用者订阅它们。 生产者独立于消费者，消费者彼此独立。

对于引入和处理大量数据且延迟非常低的应用程序，例如 IoT 解决方案，请考虑事件驱动的体系结构。 当不同的子系统必须对同一事件数据执行不同类型的处理时，该样式也很有用。

大数据、大计算

大数据体系结构样式的逻辑图。

大数据 和 大计算 是适合特定特征的工作负荷的专用体系结构样式。 大数据将非常大的数据集划分为区块，跨整个集执行并行处理，以便进行分析和报告。 大型计算也称为高性能计算（HPC），在大量核心（数千个）之间进行并行计算。 域包括模拟、建模和三维渲染。

架构风格作为约束

体系结构样式对设计设置了约束，包括可以显示的元素集以及这些元素之间的允许关系。 约束通过限制选择的宇宙来引导体系结构的“形状”。 当体系结构符合特定样式的约束时，会出现某些理想的属性。

例如，微服务中的约束包括：

  • 服务代表单一责任。
  • 每个服务都独立于其他服务。
  • 数据对拥有它的服务来说是私有的。 服务不共享数据。

通过遵循这些约束，出现的情况是一个系统，可以在其中独立部署服务、隔离故障、频繁更新，并且可以轻松地将新技术引入应用程序中。

每种架构风格都有各自的权衡。 因此，在选择任何体系结构样式之前，请确保了解该样式的基本原则和约束。 否则，您的设计可能只在表面上符合某种风格，但未能充分发挥该风格的潜力。 你需要更注意为什么选择某种体系结构风格而不是如何实现它。 务实也很重要。 有时最好放松约束，而不是坚持建筑纯洁。

择合适的体系结构样式，理想情况下应在充分知情的工作负载利益干系人达成共识的基础上进行。 工作负荷团队应首先确定他们试图解决的问题的性质。 然后，他们应确定业务驱动因素和相应的体系结构特征（也称为非功能要求），然后确定它们的优先级。 例如，如果需要更短的时间上市，他们可能会通过快速部署功能确定可维护性、可测试性和可靠的优先级。 或者，如果工作负荷团队的预算受到限制，他们可能会优先考虑可行性和简单性。 选择和维护体系结构样式不是一次性活动，而是持续方法：体系结构应随时间推移持续测量、验证和微调。 切换体系结构风格通常涉及大量成本，因此，在长期团队效率和风险缓解方面，可以更努力地进行前期工作。

下表总结了每种样式如何管理依赖项，以及最适合每个样式的域类型。

体系结构样式 依赖项管理 域类型
N 层 按子网划分的水平层 传统业务领域。 更新频率较低。
Web-队列-辅助角色 前端和后端作业，通过异步消息传递解耦。 具有一些资源密集型任务的相对简单的域。
微服务 通过 API 相互调用的垂直（功能）分解服务。 复杂域。 频繁更新。
事件驱动的体系结构 生产者/消费者。 为每个子系统提供独立视图。 IoT 和实时系统。
大数据 将大型数据集划分为小块。 本地数据集上的并行处理。 批处理和实时数据分析。 使用 ML 进行预测分析。
大型计算 将数据分配到数千个核心。 计算密集型域，例如模拟。

考虑挑战和优势

约束也会带来挑战，因此在采用这些样式时必须了解权衡。 对于此子域和边界上下文，采用这种体系结构风格的好处是否大于挑战。

下面是选择体系结构样式时要考虑的一些挑战类型：

  • 复杂性。 体系结构的复杂性是否适合你的域？ 反过来，该样式对于域而言是否过于简单？ 在这种情况下，你有可能最终得到一个“大泥球”，因为体系结构不会帮助你清晰管理依赖项。

  • 异步消息传送和最终一致性。 异步消息传送可用于分离服务，并提高可靠性（因为可以重试消息）和可伸缩性。 但是，这也在处理最终一致性以及可能出现重复消息方面产生挑战。

  • 服务间通信。 将应用程序分解为单独的服务时，服务之间的通信可能会导致不可接受的延迟或创建网络拥塞（例如，在微服务体系结构中）。

  • 可管理性。 管理应用程序、监视、部署更新等是多么困难？