云应用程序架构样式详解：从N层到微服务

云应用程序架构样式详解：从N层到微服务

在云计算和软件架构设计领域，选择合适的架构样式对于构建高效、可扩展和易于维护的应用程序至关重要。本文将为您详细介绍几种常见的云应用程序架构样式，包括它们的定义、适用场景、优缺点以及实施建议。

架构样式概述

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

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

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

样式概览

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

N 层

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

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

Web-队列-辅助角色

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

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

微服务

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

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

事件驱动的架构

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

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

大数据、大计算

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

架构样式即约束

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

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

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

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

每个体系结构样式都有自己的优缺点。因此，在选择任何体系结构样式之前，请确保了解该样式的基本原则和约束。否则，最终可能会得到一个表面上符合该样式，但不能完全发挥该样式的潜力的设计。需要更多地关注为什么要选择某种体系结构样式，而不是如何去实现它。务实也很重要。有时，最好是放宽约束，而不是坚持体系结构的纯度。

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

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

考虑难题和优势

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

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

• 复杂性。该体系结构的复杂性对于域而言是否合理？反过来，该样式对于域而言是否过于简单？在这种情况下，风险是最终只设计出一个大泥球，因为该体系结构无助于利落地管理依赖项。
• 异步消息传送和最终一致性。异步消息传送可用于分离服务，并提高可靠性（因为消息可以重试）和可伸缩性。但是，这也会在处理最终一致性方面带来挑战，并可能会导致出现重复消息。
• 服务间通信。将应用程序分解为独立的服务时，风险是服务之间的通信会导致不可接受的延迟，或造成网络拥塞（例如，在微服务体系结构中）。
• 可管理性。管理应用程序、监视、部署更新以及其他操作的难度有多大？