什么是 N 层体系结构？
N 层体系结构将应用程序分成逻辑层和物理层级。 N 表示将应用程序分成的物理层级数，通常与层数相关。 我们可以有一个双层体系结构（客户端-服务器），甚至是五层体系结构，虽然这很常见，但一般情况下，最好将层级数保持在四层或四层以内。
我们来谈谈层和层级的构成。
什么是层？
层在逻辑上分离构成应用程序的应用程序代码。 每个层都有特定的职责，例如处理来自用户的请求、运行业务逻辑或处理数据存储。
通过将应用程序分离成这些逻辑层，我们可以独立处理每个层。 这种分隔使得应用程序的组件模块化，让我们能够更轻松地维护应用。 我们可以针对每项职责优化应用程序。 处理 Web 请求的层专注于其主要任务：处理 Web 请求。 它不关心数据的存储或运行业务逻辑。 相反，数据访问层专注于优化与数据存储的通信，而忽略有关如何向用户呈现数据的详细信息。 这种将重点放在特定功能上的概念称为关注点分离。
下图展示了一个常见 N 层体系结构中的各个层。 每个层处理应用程序的一个方面。 业务层管理用户界面层和数据访问层之间的通信。
什么是层级？
层级表示应用程序各部分在不同计算资源上的物理分离。 通常，每个物理层级运行应用程序的一个逻辑层。
将体系结构分离成多个物理层级有以下几个好处：
- 通过向每个层级添加资源，可以单独缩放各个应用程序组件。
- 通过添加负载均衡来检测故障资源并将请求重定向到正常的系统，可以增强应用程序的复原能力。
- 通过限制层级之间的网络通信并且仅允许必要的访问，可以让应用程序更安全。
该体系结构规定层级之间的通信应该是自上而下的。 每个层级可与其下一层级通信，但通常不允许跳过层级。 此设计可限制层级的暴露面，从而提高安全性。
三层体系结构
在所有 N 层体系结构中，三层体系结构是最常见的。 每个层和层级的职责和名称因应用程序和业务而异，但典型的三层应用程序具有：呈现层、应用层或中间层以及数据层。 此体系结构是最常见的 N 层样式。 在本模块的余下部分中，我们将引用一个三层模型（每个层级运行应用程序的单个层），并将它们同义地称为层级。
呈现层
呈现层通常为用户请求提供便利。 这些请求可能是指用户访问网页，或通过公开的 API 公开访问应用程序。 此层级专注于用户体验。 提供直观的界面等内容，并确保最终用户与应用程序之间的安全通信。
在此层级，你不关心数据本身，而只关心如何将它呈现给用户。 通常不会在此层级发生数据处理或数据访问。 这是较低层级的职责。
应用层
应用层（通常也称为中间层）通常专注于处理应用程序的业务逻辑。 这里可能是指处理客户订单、跟踪货件或根据收到的材料更新库存。 此层级还负责处理针对数据层的创建、读取、更新、删除 (CRUD) 活动。 此层级也是调用依赖服务（例如外部 API）的好位置。
此层级既不关心如何将信息呈现给用户，也不关心如何存储和检索数据。 它专注于履行应用程序收到的请求所需的业务逻辑。
数据层
在此层级，重点是数据存储。 此层级负责将数据存储在表、文件或其他媒体中。 它提供一个数据访问接口（例如 T-SQL）。 在三层体系结构中，数据层提供对应用层的数据访问。
此层级既不关心如何将数据呈现给用户，也不关心有关数据的任何逻辑。 存储过程的使用可能位于此层级，但有关数据本身的大部分逻辑应在更高层级进行处理。
何时使用 N 层体系结构
我们已经讨论了 N 层体系结构是什么，现在让我们讨论何时使用这种样式的体系结构。 请考虑将 N 层体系结构用于：
- 中小型 Web 应用程序。
- 将本地应用程序迁移到 Azure 并进行最小的重构。
- 使用本地开发人员的技能、功能和经验。
Web 应用程序是这种体系结构样式的一个很好的用例。 由于这种体系结构样式的复杂性较低，并且 Web 应用程序中的各项职责之间通常自然分离，因此可能适合使用 N 层体系结构。 这些应用程序可能是指面向公众的应用程序，也可能是指组织内部使用的业务线应用程序。 对于较小或不太复杂的应用程序，使用呈现层与应用层合并而不是分离的双层（客户端/服务器）体系结构可能就足够了。
N 层体系结构在传统的本地应用程序中很常见，因此它很适合将现有工作负载迁移到 Azure。 此样式的应用程序在迁移到 Azure 时通常只需进行最低限度的重构或修改，从而简化了初始迁移。 迁移到 Azure 之后，你可以利用平台即服务 (PaaS) 服务来进一步改进应用程序。
由于这是一种常见的体系结构样式，工程师通常对其较为熟悉，也拥有较丰富的经验。 通过选择此体系结构，可以使用现有技能集来部署应用程序，而无需掌握新的体系结构模式。