三层架构简介
三层架构是互联网上最常见的交互架构。当两层服务器部分被分为逻辑层和数据层两部分时，它就出现了。
它看起来像这样：
客户端层是负责用户交互的“分布式应用程序”的一部分。该层不应包含业务逻辑，也不应存储关键数据。此外，它不应直接与数据库层交互，而只能通过业务逻辑层进行交互。
但是，这里仍然有一些逻辑。首先，这是通过界面与用户交互，验证他输入的数据，使用本地文件。这还包括使用服务器时与用户授权和数据加密相关的所有内容。
其次，是简单的业务逻辑。例如，如果一个在线商店发送了一个产品列表，我们可以在客户端对它们进行排序和过滤。原始数据存储也在这里：缓存、登录用户 cookie 等。
业务逻辑层位于第二层，大部分业务逻辑都集中在上面。在它之外，只保留导出到客户端的片段，以及沉浸在数据库中的逻辑元素（存储过程和触发器）。
非常部分的业务逻辑服务器不仅包含相同的逻辑，还解决了伸缩性问题：将代码分成几部分分布到不同的服务器上。一些需求量很大的服务可以在几十台服务器上运行。它们之间的负载由负载均衡器管理。
服务器应用程序通常设计为可以轻松启动服务器的另一个副本，并开始与服务器的其他副本协同工作。也就是说，即使在编写服务器代码的过程中，您也永远无法保证您的静态类是在单个实例中启动的。
数据层提供数据存储并放置在单独的级别上，通常通过数据库管理系统 (DBMS) 实现，仅从应用程序服务器级别提供与此组件的连接。
分离数据层的原因
将数据层分离为成熟的第三层的原因有很多，但主要的原因是服务器负载增加。
首先，数据库开始需要大量内存和处理器时间来处理数据。因此，它们开始被放置在单独的服务器上。
随着负载的增加，后端可以很容易地复制，一台服务器可以增加十个副本，但是复制数据库是不可能的——数据库仍然是系统的一个不可分割的组件。
其次，数据库变得智能——它们有自己的业务逻辑。他们开始支持存储过程，触发器，他们自己的语言比如PLSQL。甚至出现了开始编写在 DBMS 内部运行的代码的程序员。
所有与数据无关的逻辑都被取出到后端并在数十台服务器上并行启动。与数据密切相关的所有内容都保留在 DBMS 中，并且已经存在负载增加的问题，必须使用我们自己的方法来解决：
- 数据库集群是一组存储相同数据并使用特定协议同步数据的数据库服务器。
- 分片——数据被分割成逻辑块并分布在不同的数据库服务器上。使用这种方法很难维护数据库更改。
- NoSQL 方法是将数据存储在为存储大量数据而构建的数据库中。这些通常甚至不是数据库，而是特定的文件存储。与关系数据库相比，功能非常差。
- 数据缓存。出现了整个缓存 DBMS，而不是数据库级别的简单缓存，它只将结果存储在内存中。
很明显，需要单独的人员和/或整个团队来管理这个服务器技术动物园，这导致将数据层移除到一个单独的层中。
重要的！当旧方法不再应对新挑战时，所有先进技术都诞生于大型 IT 公司的深处。把数据库做成一个单独的层，并不是哪个程序员发明的，而是甲骨文或IBM深处某处的一群工程师发明的。
有趣的！当扎克伯格开始编写 Facebook 时，他只是在 PHP + MySQL 上工作。当有数百万用户时，他们编写了一个专门的翻译器，将所有 PHP 代码翻译成 C++，并将其编译成本机机器代码。
此外，MySQL 无法存储数十亿用户的数据，因此 Facebook 提出了 NoSQL 数据库的概念，并编写了功能强大的服务器端 NoSQL DBMS——Cassandra。顺便说一下，它完全是用 Java 编写的。
应用逻辑位置不明确
尽管三层架构几乎明确地在其各部分之间分配了角色，但并不总是能够准确地确定系统中需要添加业务逻辑的新部分（新代码）的确切位置。
下图显示了这种歧义的一个例子：
服务器部分用灰色背景填充，客户端部分用白色填充。后一种方法（最右边）的一个很好的例子是现代移动应用程序。客户端（在手机上）包含视图（显示）、逻辑和数据。而且只是有时这些数据会与服务器同步。
最左边选项的一个示例是典型的 PHP 服务器，它具有服务器上的所有逻辑，并且它为客户端提供了已经静态的 HTML。您的项目将位于这两个极端之间的某个位置。
刚开始工作时，在熟悉项目后，你需要咨询从事该项目的程序员，了解哪些地方更适合你实现下一个任务的逻辑。
随意这样做。首先，他们不会凭章程爬进别人的修道院。其次，每个人（你也一样）会更容易在你希望找到的地方找到你需要的代码。