编辑

通过

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

N 层体系结构样式

Azure 存储
Azure 云服务
Azure 虚拟机

N 层体系结构将应用程序划分为 逻辑层，物理层。

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

层是分离职责和管理依赖项的一种方法。 每个层都有特定的责任。 较高层可以使用较低层中的服务，但不能在其他方面使用服务。

层在物理上是分开的，在单独的计算机上运行。 从合同上看，层可以严格或放松其通信模型。 在严格的模型中，请求必须逐个浏览相邻层，并且不能跳过任何层。 例如，从 Web 应用程序防火墙到 Web 层，再到中间层 1 等。 相比之下，在宽松的方法中，如果有必要，请求可能会跳过某些层。 严格的方法具有更多的延迟和开销，宽松的方法具有更多的耦合，随后更难以更改。 系统可以使用混合方法：根据需要同时放宽和严格层。

层可以直接调用另一层，或者通过消息队列 使用 异步消息传送模式。 尽管每个层可能托管在其自己的层中，但这不是必需的。 多个层可能托管在同一层上。 在物理上分离层可以提高可伸缩性和复原能力，但也增加了来自其他网络通信的延迟。

传统的三层应用程序具有呈现层、中间层和数据库层。 中间层是可选的。 更复杂的应用程序可以具有三个以上的层。 上图显示了一个具有两个中间层的应用程序，它封装了不同的功能区域。

N 层应用程序可以具有 封闭层体系结构 或 开放层体系结构：

  • 在封闭层体系结构中，层只能立即调用下一层。
  • 在开放层体系结构中，层可以调用其下方的任何层。

封闭层体系结构限制层之间的依赖关系。 但是，如果一个层只是将请求传递到下一层，则可能会创建不必要的网络流量。

何时使用此体系结构

N 层体系结构通常作为基础结构即服务（IaaS）应用程序实现，每个层都在一组单独的 VM 上运行。 但是，N 层应用程序不需要是纯 IaaS。 通常，最好对体系结构的某些部分使用托管服务，尤其是缓存、消息传递和数据存储。

请考虑以下 N 层体系结构：

  • 简单的 Web 应用程序。
  • 体系结构要求尚不明确时，一个很好的起点。
  • 将本地应用程序迁移到 Azure，只需进行最少的重构。
  • 统一开发本地和云应用程序。

N 层体系结构在传统的本地应用程序中非常常见，因此它很适合将现有工作负荷迁移到 Azure。

好处

  • 云与本地之间的可移植性，以及云平台之间的可移植性。
  • 大多数开发人员的学习曲线较少。
  • 通过不重新架构解决方案，成本相对较低
  • 传统应用程序模型的自然演变。
  • 打开异类环境（Windows/Linux）

挑战

  • 最终，中间层只需对数据库执行 CRUD 操作即可，无需执行任何有用的工作即可增加额外的延迟。
  • 整体设计可防止独立部署功能。
  • 管理 IaaS 应用程序比仅使用托管服务的应用程序更加工作。
  • 在大型系统中管理网络安全可能很困难。
  • 用户和数据流通常跨越多个层，从而增加了诸如测试和可观测性等问题的复杂性。

最佳做法

  • 使用自动缩放来处理负载更改。 请参阅自动缩放最佳做法。
  • 使用 异步消息传送 分离层。
  • 缓存半静态数据。 请参阅 缓存最佳做法。
  • 使用 SQL Server Always On 可用性组等解决方案配置数据库层以实现高可用性。
  • 在前端和 Internet 之间放置 Web 应用程序防火墙（WAF）。
  • 将每个层放置在其自己的子网中，并使用子网作为安全边界。
  • 仅允许来自中间层的请求来限制对数据层的访问。

虚拟机上的 N 层体系结构

本部分介绍在 VM 上运行的建议 N 层体系结构。

N 层体系结构的物理关系图

每个层由两个或多个 VM 组成，放置在可用性集或虚拟机规模集中。 如果一个 VM 发生故障，多个 VM 可提供复原能力。 负载均衡器用于在层中的 VM 之间分配请求。 可以通过向池中添加更多 VM 来水平缩放层。

每个层也放置在其自己的子网中，这意味着其内部 IP 地址位于同一地址范围内。 这样可以轻松将网络安全组规则和路由表应用到各个层。

Web 层和业务层是无状态的。 任何 VM 都可以处理该层的任何请求。 数据层应包含复制的数据库。 对于 Windows，我们建议使用 AlwaysOn 可用性组实现高可用性。 对于 Linux，请选择支持复制的数据库，例如 Apache Cassandra。

网络安全组限制对每个层的访问。 例如，数据库层仅允许从业务层进行访问。

注意

参考图中标有“业务层”的层是业务逻辑层的名字对象。 同样，我们还将呈现层称为“Web 层”。在本示例中，这是一个 Web 应用程序，不过多层体系结构可用于其他拓扑（如桌面应用）。 为层命名最适合你的团队以传达应用程序中该逻辑层和/或物理层的意图 - 甚至可以在选择表示该层的资源中表达命名（例如 vmss-appName-business-layer）。

其他注意事项

  • N 层体系结构不限于三个层。 对于更复杂的应用程序，通常有更多的层。 在这种情况下，请考虑使用第 7 层路由将请求路由到特定层。

  • 层是可伸缩性、可靠性和安全性的边界。 请考虑在这些方面具有不同要求的服务的单独层。

  • 使用虚拟机规模集 自动缩放。

  • 在体系结构中查找可以在不进行重大重构的情况下使用托管服务的位置。 具体而言，请查看缓存、消息传送、存储和数据库。

  • 为了提高安全性，请将网络外围网络置于应用程序前面。 DMZ 包括实现防火墙和数据包检查等安全功能的网络虚拟设备（NVA）。 有关详细信息，请参阅 网络外围网络参考体系结构。

  • 若要实现高可用性，请将两个或多个 NVA 放置在可用性集中，外部负载均衡器可在实例之间分发 Internet 请求。 有关详细信息，请参阅 部署高度可用的网络虚拟设备。

  • 不允许对运行应用程序代码的 VM 进行直接 RDP 或 SSH 访问。 相反，操作员应登录到 jumpbox，也称为堡垒主机。 这是网络上的 VM，管理员使用该 VM 连接到其他 VM。 jumpbox 有一个网络安全组，仅允许来自已批准的公共 IP 地址的 RDP 或 SSH。

  • 可以使用站点到站点虚拟专用网络（VPN）或 Azure ExpressRoute 将 Azure 虚拟网络扩展到本地网络。 有关详细信息，请参阅 混合网络参考体系结构。

  • 如果组织使用 Active Directory 管理标识，可能需要将 Active Directory 环境扩展到 Azure VNet。 有关详细信息，请参阅 标识管理参考体系结构。

  • 如果需要比 VM 的 Azure SLA 更高的可用性，请跨两个区域复制应用程序，并使用 Azure 流量管理器进行故障转移。 有关详细信息，请参阅 运行多个区域中的 Linux VM。