最近我的一个朋友问我有关 N 层架构的问题，我能够通过示例向他解释 1、2 和 3 层架构。但是当我想给出超过 3 层的示例时，我被卡住了。我用谷歌搜索并寻求帮助，但找不到任何像样的例子。
它被命名为 N 层的事实让我认为“N”可以是从 1 开始的任何数字。但我找不到 4 层或 5 层的任何示例。
有人可以分享一些涉及超过 3 层的 N 层架构示例吗？
【问题讨论】：
标签： service architecture n-tier-architecture
被称为 N 层的转变反映了向越来越多的组件化架构的转变，从旧的客户端-服务器到第一个 3 层，然后是 4 层。层的定义特征是具有明确定义的关注点分离的接口。
【讨论】：
四层架构包括以下内容
一个。客户端层——node.js angularJs 等基本上独立于服务器端，UI 团队独立处理客户端工件
b.聚合层 --- 内容交付网络 (akamai)
c。 api tier -- 所有服务器端调用的网关，可以有自己的缓存
d。服务层——包括内部或外部服务...
【讨论】：
五分钟前我读到了这篇文章 https://www.nginx.com/blog/time-to-move-to-a-four-tier-application-architecture
客户端是您阅读它的地方 Api 或您的应用程序后端是您组装它的地方.. 数据聚合..要么通过外包事物的 jsons/xmls，要么通过数据库查询，最后服务层是您实际对数据库进行查询或在大数据上运行函数或从谷歌读取 GPS 位置和地图的地方......这就是我在这种情况下的看法。它只是将数据层从三层中划分出来。
但是这个 N 层模型是完全抽象的，因此您可以撕毁您的基础架构，直到您只拥有一些逻辑上的原子部分。还是在划分之前的结构。
【讨论】：
我倾向于用不那么抽象和更实际的解释来回答这个问题：“我要如何以及为什么要将我的系统分成多个层，我应该将它们放在服务器上的什么位置？”
基本上，当您创建一个使用数据库的简单网站时，您已经“开箱即用”了 3 层：
数据层 - 数据库。但是，如果您使用的是短期内存缓存或文件系统，那么我们可能会争论是否可以将其视为“层”。
应用层 - 在您的服务器上执行的代码。
呈现（或客户端）层 - 在客户端机器上执行并将结果呈现给客户端的代码
现在，我们如何获得第四层？
很可能不需要拆分客户端层。它在客户的设备上，我们希望尽可能保持简单和高效。
我们可以拆分数据层吗？我已经看到一些系统使用围绕数据库、Azure Blob、文件系统等的 API 来创建一些可以被视为层的子系统。但这仍然是相同的数据层（a.k.a 基础服务层）还是我们可以将其视为一个单独的实体？如果我们把它分开，它会和我们的数据库在同一个物理（或虚拟）服务器上，这样我们就可以保护数据不被直接访问？
但是，在大多数情况下，拆分的是应用程序层。
其中一部分仍被命名为应用层。它成为一个内部 API Web 应用程序，并位于可以访问数据库的安全区域中。没有人可以直接访问数据库，只能通过这个应用层。
另一部分通过某种连接（HTTP 客户端等）成为应用层 API 的消费者。消费者可能被称为表示层（令人困惑 - 它与客户端层不一样吗？），即使它本身只有 JSON API 并且没有任何用户友好的格式。
但随之而来的问题是：在哪些情况下，作为开发人员，我们可能希望将我们的生活复杂化并将我们的 Web 应用程序拆分为表示层和应用程序层，而不是将它们作为层保持在同一个 Web 应用程序中？
在严重的工作负载中，单独的应用程序层可能有利于可扩展性，或者拒绝数据库连接到向用户公开的 Web 服务器（甚至是 Intranet 的服务器）可能是安全要求。
我看到一些雄心勃勃的项目从一开始就追求 4 层，然后诅咒自己过度设计的东西。您必须跟踪那些内部连接、安全性、身份验证令牌，控制套接字（不是在每个请求上打开新的 HTTP 连接），避免通过粗心创建的全局 HTTP 客户端实例意外共享多个并行请求的数据等。
【讨论】：
4 层架构的一个简单示例是 RMI JDBC Servlet。这涉及 客户层 servlet 的应用服务器 用于服务器程序的 Rmi 服务器 用于数据库的 Jdbc 服务器
【讨论】：