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

架构样式

  • 项目

架构样式是具有某些共同特征的一系列样式。 例如，N 层就是一个常见的体系结构样式。 最近以来，微服务架构开始受到青睐。 体系结构风格不需要使用特定的技术，但某些技术非常适合某些特定的体系结构。 例如，容器原生就能适应微服务。

我们已经识别了云应用程序中常用的一组体系结构样式。 有关每个样式的文章包括：

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

样式概览

本节提供我们已识别的体系结构样式的概览，以及有关其用法的概要性注意事项。 请在链接的主题中阅读更多详细信息。

N 层

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

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

N 层原生就很适合用于迁移已使用分层架构的现有应用程序。 因此，N 层往往出现在基础结构即服务 (IaaS) 解决方案中，或混合使用 IaaS 和托管服务的应用程序中。

Web-队列-辅助角色

Web 队列辅助角色体系结构样式的逻辑图。

对于单纯的 PaaS 解决方案，可以考虑 Web-队列-辅助角色 架构。 在此风格中，应用程序有一个处理 HTTP 请求的 Web 前端，以及一个执行 CPU 密集型任务或长时间运行的操作的后端辅助角色。 前端通过异步消息队列来与辅助角色通信。

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

微服务

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

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

每个服务可由小规模的专业开发团队构建。 无需在团队之间进行过多的协调即可部署单个服务，因此有利于频繁更新。 与 N 层或 Web-队列-辅助角色相比，微服务体系结构的构建和管理更复杂。 它需要成熟的开发和 DevOps 文化。 但如果实施得当，此样式可以加快发布速度，加速创新，提高体系结构的复原能力。

事件驱动的架构

事件驱动体系结构样式图。

事件驱动的架构 使用发布-订阅 (pub-sub) 模型，其中，生成者发布事件，使用者订阅事件。 生成者独立于使用者，使用者互相独立。

可考虑对以极低延迟引入和处理大量数据的应用程序（例如 IoT 解决方案）使用事件驱动的架构。 当不同的子系统必须对相同的事件数据执行不同类型的处理时，该样式也很有用。

大数据、大计算

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

大数据 和 大计算 是专业化的架构样式，适用于符合某些特定要求的工作负荷。 大数据将庞大的数据集划分为区块，针对要分析和报告的整个数据集执行并行处理。 大计算也称为高性能计算 (HPC)，它使用大量（数千个）核心执行并行计算。 应用领域包含仿真、建模和 3D 渲染。

架构样式即约束

体系结构样式对设计施加约束，包括可显示的元素集，以及这些元素之间允许的关系。 约束通过限制所选的范围来引导架构的“形状”。 当某个体系结构符合特定样式的约束时，就会显现某些所需属性。

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

  • 服务代表单一责任。
  • 每项服务都独立于其他服务。
  • 数据专用于拥有此数据的服务。 服务不共享数据。

如果遵守这些约束，则会显现一个可在其中独立部署服务、隔离故障、频繁更新且很容易将新技术引入应用程序的系统。

在选择某个体系结构样式之前，请确保了解该样式的基本原则和约束。 否则，最终可能会得到一个表面上符合该样式，但不能完全发挥该样式的潜力的设计。 务实也很重要。 有时，最好是放宽约束，而不是坚持体系结构的纯度。

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

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

考虑难题和优势

约束也会带来挑战，因此，在采用其中的任何样式时，必须了解各自的利弊。 该体系结构样式在该子域和界定的上下文中是否利大于弊？

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

  • 复杂性。 该体系结构的复杂性对于域而言是否合理？ 反过来，该样式对于域而言是否过于简单？ 在这种情况下，风险是最终只设计出一个大泥球，因为该体系结构无助于利落地管理依赖项。

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

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

  • 可管理性。 管理应用程序、监视、部署更新以及其他操作的难度有多大？