在传统上，开发应用程序是分层的，MVC这种是常常被用到的。这里的N层体系结构更关注的服务之间的层次结构，而不是单应用内部的。和微服务不同的是，微服务之间的关系是平等的，而N层体系结构中的层与层之间有前后关系。这种体系结构，在实践中非常广泛，在微服务的设计中，某些微服务就具有这样的特性，只能在某个层提供服务。

微软把这种体系结构拿出来，我认为是可取的，让我们对程序之间的调用模式，有了更丰富的理论体系支撑。

欢迎关注我。

N 层体系结构将应用程序分成逻辑层和物理层。

层是分离职责和管理依赖关系的方式。 每个层都有特定的责任。 较高层可使用较低层中的服务，反之则不行。

层在物理上是分隔开的，在不同的计算机上运行。 一个层可直接调用另一个层，或使用异步消息传递（消息队列）。 虽然每个层可能托管在自己的层中，但这并不是必需的。 多个层可能托管在同一层上。 在物理上分隔层可以提高可伸缩性和复原能力，但因额外的网络通信也增加了延迟。

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

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

• 在封闭的层体系结构中，层只能调用紧邻的下一层。
• 在开放的层体系结构中，层可以调用它下面的任何层。

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

何时使用此架构

N 层体系结构通常作为服务架构 (IaaS) 应用程序实现，每个层都在独立的 VM 集中运行。 然而，N 层应用程序不需要只是 IaaS。 通常，对体系结构的某些部分使用托管服务是有利的，特别是缓存、消息传递和数据存储。

请考虑将 N 层体系结构用于：

• 简单的 Web 应用程序。
• 将本地应用程序迁移到 Azure 并进行最小的重构。
• 统一开发本地和云应用程序。

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

优点

• 云与本地之间，云平台之间具有可移植性。
• 对于大多数开发者来说，学习曲线较少。
• 从传统应用程序模型自然演变。
• 对异构环境 (windows/linux) 开放

挑战

• 很容易最终得到一个只在数据库上执行CRUD操作的中间层，在不做任何有用工作的情况下增加额外的延迟。
• 单一式设计阻止了独立部署各项功能。
• 管理 IaaS 应用程序的工作量要大于管理只使用托管服务的应用程序。
• 管理大型系统中的网络安全比较困难。

最佳做法

• 使用自动缩放处理负载中的更改。
• 使用异步消息传递来分离层。
• 缓存 semistatic 数据。
• 配置高可用性，如使用的解决方案的数据库层SQL Server Always On 可用性组。
• 在前端和 Internet 之间放置 Web 应用程序防火墙 (WAF)。
• 将每个层放置在自己的子网中，并将子网用作安全边界。
• 通过仅允许来自中间层的请求，限制对数据层的访问。

转自：https://docs.microsoft.com/zh-cn/azure/architecture/guide/architecture-styles/n-tier