通过

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

架构样式

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

我们发现了一组通常在云应用程序中发现的体系结构样式。 每个样式的文章包含以下组件：

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

样式概览

本部分简要介绍我们识别的架构风格，以及其使用时的一些高级注意事项。 此列表并不详尽。 阅读链接文章中的更多详细信息。

N 层

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

N 层 是企业应用程序的传统体系结构，可将应用程序划分为逻辑层和物理层。 每个层都有一个特定的责任，层仅通过调用它们下面的层来管理依赖项。 典型层包括表示、业务逻辑和数据访问。

N 层体系结构非常适合用于迁移已使用分层体系结构的现有应用程序。 在迁移到 Azure 时，此方法需要极少量的更改，并支持使用本地和云组件的混合环境。 但是水平分层可能会使引入更改变得困难，而不会影响应用程序的多个部分，这会限制频繁更新的敏捷性。

Web-队列-辅助角色

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

Web 队列辅助角色 是一种体系结构，由 Web 前端、消息队列和后端辅助角色组成。 Web 前端处理 HTTP 请求和用户交互，而工作进程执行资源密集型任务、长时间运行的工作流或批处理操作。 前端和工作线程之间的通信通过异步消息队列进行。

此体系结构非常适合具有相对简单的域的应用程序，这些域具有一些资源密集型处理要求。 使用托管的 Azure 服务（如应用服务和 Azure Functions）可以轻松理解和部署。 可以独立扩展前端和工作节点，以提供资源分配的灵活性。 但是，如果不仔细设计，这两个组件都可以变得庞大和单一。

微服务

微服务体系结构样式的逻辑关系图。

微服务体系结构将应用程序分解为小型自治服务的集合。 每个服务在有限上下文中实现单个业务功能，并自包含其自己的数据存储。 服务通过定义完善的 API 进行通信，可以独立开发、部署和缩放。

微服务使团队能够自主工作，并支持具有更高发布速度的频繁更新。 此体系结构非常适合需要频繁更改和创新的复杂域。 但它在服务发现、数据一致性和分布式系统管理等领域带来了显著的复杂性。 成功需要成熟的开发和 DevOps 实践，这使得它更适合具有高级技术功能的组织。

事件驱动的架构

事件驱动架构风格示意图。

事件驱动的体系结构 使用发布-订阅模型，其中事件生成者生成事件流，事件使用者几乎实时响应这些事件。 生产者和消费者彼此独立，通信通过事件通道或代理进行。 此体系结构支持简单的事件处理和复杂的事件模式分析。

事件驱动的体系结构在需要以最小延迟进行实时处理的情况下表现得非常出色。 一些示例包括 IoT 解决方案、金融交易系统或需要处理大量流数据的应用程序。 事件驱动的体系结构提供出色的可伸缩性和故障隔离性，但针对分布式组件的保证交付、事件排序和最终一致性带来了挑战。

大数据

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

大数据 体系结构处理对传统数据库系统太大或过于复杂的数据的引入、处理和分析。 这些体系结构通常包括数据存储（如数据湖）的组件、用于历史分析的批处理、用于实时见解的流处理以及用于报告和可视化的分析数据存储。

大数据体系结构对于需要从大型数据集中提取见解、使用机器学习支持预测分析或处理 IoT 设备的实时流数据的组织至关重要。 新式实现通常使用 Microsoft Fabric 等托管服务来简化构建和维护大数据解决方案的复杂性。

大规模计算

说明大型计算体系结构样式的关系图。

大型计算 体系结构支持需要数百或数千个核心进行计算密集型作的大型工作负荷。 工作可以拆分为同时跨多个核心运行的离散任务，每个任务都采用输入、处理和生成输出。 任务可以是独立的（尴尬并行），也可以是需要高速通信的紧密耦合。

大型计算对于模拟、财务风险建模、科学计算、工程压力分析和三维渲染至关重要。 Azure 提供用于托管大型计算工作负荷的 Azure Batch 选项，或者为更传统的群集管理提供 HPC Pack 等选项。 这些架构可以按需突发计算容量，并在需要时扩展到数千个处理核心。

架构风格作为约束

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

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

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

遵守这些约束时，你将获得一个系统，使你能够执行以下作：

  • 独立部署服务。
  • 隔离故障。
  • 推送更频繁的更新。
  • 更轻松地将新技术引入应用程序。

每种架构风格都有各自的权衡。 在选择体系结构样式之前，必须了解基本原则和约束。 如果缺乏这种理解，你可能会创建一个设计，该设计仅仅在表面上符合样式，而未能实现设计的全部优点。 更注重选择特定样式的原因，而不是如何实现它。 实事求是。 有时，放松约束比追求建筑纯洁更好。

理想情况下，应使用来自知情工作负荷利益干系人的输入来选择体系结构样式。 工作负荷团队应首先确定要解决的问题的性质。 然后，它们应定义关键业务驱动因素和相应的体系结构特征，也称为 非功能要求，并设置优先级。 例如，如果上市时间至关重要，团队可能会优先考虑可维护性、可测试性和可靠性，以实现快速部署。 如果团队的预算限制严格，可行性和简单性可能会优先。 选择和维护体系结构样式不是一次性任务。 它需要持续测量、验证和优化。 由于以后改变体系结构方向的成本可能很高，因此通常值得先投入更多精力来支持长期效率并减少风险。

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

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

考虑挑战和优势

约束也会带来挑战，因此，当你采用上述任何样式时，了解权衡非常重要。 确定体系结构样式的优点是否超过了 此子域和边界上下文的挑战。

选择体系结构样式时，请考虑以下类型的挑战：

  • 复杂性： 体系结构的复杂性必须与域匹配。 如果它过于简单，就可能导致一团乱架构，其中依赖项管理不好，结构混乱。

  • 异步消息传送和最终一致性： 异步消息传送用于分离服务并提高可靠性，因为可以重试消息。 它还增强了可伸缩性。 但是，异步消息传送也会在处理最终一致性和重复消息的可能性方面带来挑战。

  • 服务间通信： 将应用程序分解为单独的服务可能会增加通信开销。 在微服务体系结构中，这种开销通常会导致延迟问题或网络拥塞。

  • 可管理性： 管理应用程序包括监视、部署更新和维护作运行状况等任务。

后续步骤