你当前正在访问 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,我们推荐 SQL Server,使用 Always On 可用性组实现高可用性。 对于 Linux,请选择支持复制的数据库,例如 Apache Cassandra。

网络安全组限制对每个层的访问。 例如,数据库层仅允许来自业务层的访问。

注意

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

其他注意事项

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

  • 层是可伸缩性、可靠性和安全性的边界。 请考虑为这些区域中有不同需求的服务提供单独的层。

  • 使用虚拟机规模集进行自动扩缩

  • 在体系结构中寻找可以使用托管服务而无需进行大量重构的位置。 具体来说,就是缓存、消息传递、存储和数据库。

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

  • 为实现高可用性,请在可用性集中放置两个或多个 NVA,并使用外部负载均衡器在实例间分布 Internet 请求。 有关详细信息,请参阅部署高可用性网络虚拟设备

  • 不允许将 RDP 或 SSH 访问定向到正在运行应用程序代码的 VM。 相反,运算符应登录到 jumpbox,也称为壁垒主机。 这是管理员在网络上用来连接其他 VM 的 VM。 jumpbox 中有一个网络安全组,它仅支持来自已批准的公共 IP 地址的 RDP 或 SSH。

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

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

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