三層架構簡介
三層架構是互聯網上最常見的交互架構。當兩層服務器部分被分為邏輯層和數據層兩部分時，它就出現了。
它看起來像這樣：
客戶端層是負責用戶交互的“分佈式應用程序”的一部分。該層不應包含業務邏輯，也不應存儲關鍵數據。此外，它不應直接與數據庫層交互，而只能通過業務邏輯層進行交互。
但是，這裡仍然有一些邏輯。首先，這是通過界面與用戶交互，驗證他輸入的數據，使用本地文件。這還包括使用服務器時與用戶授權和數據加密相關的所有內容。
其次，是簡單的業務邏輯。例如，如果一個在線商店發送了一個產品列表，我們可以在客戶端對它們進行排序和過濾。原始數據存儲也在這裡：緩存、登錄用戶 cookie 等。
業務邏輯層位於第二層，大部分業務邏輯都集中在上面。在它之外，只保留導出到客戶端的片段，以及沉浸在數據庫中的邏輯元素（存儲過程和触發器）。
非常部分的業務邏輯服務器不僅包含相同的邏輯，還解決了伸縮性問題：將代碼分成幾部分分佈到不同的服務器上。一些需求量很大的服務可以在幾十台服務器上運行。它們之間的負載由負載均衡器管理。
服務器應用程序通常設計為可以輕鬆啟動服務器的另一個副本，並開始與服務器的其他副本協同工作。也就是說，即使在編寫服務器代碼的過程中，您也永遠無法保證您的靜態類是在單個實例中啟動的。
數據層提供數據存儲並放置在單獨的級別上，通常通過數據庫管理系統 (DBMS) 實現，僅從應用程序服務器級別提供與此組件的連接。
分離數據層的原因
將數據層分離為成熟的第三層的原因有很多，但主要的原因是服務器負載增加。
首先，數據庫開始需要大量內存和處理器時間來處理數據。因此，它們開始被放置在單獨的服務器上。
隨著負載的增加，後端可以很容易地複制，一台服務器可以增加十個副本，但是複制數據庫是不可能的——數據庫仍然是系統的一個不可分割的組件。
其次，數據庫變得智能——它們有自己的業務邏輯。他們開始支持存儲過程，觸發器，他們自己的語言比如PLSQL。甚至出現了開始編寫在 DBMS 內部運行的代碼的程序員。
所有與數據無關的邏輯都被取出到後端並在數十台服務器上並行啟動。與數據密切相關的所有內容都保留在 DBMS 中，並且已經存在負載增加的問題，必須使用我們自己的方法來解決：
- 數據庫集群是一組存儲相同數據並使用特定協議同步數據的數據庫服務器。
- 分片——數據被分割成邏輯塊並分佈在不同的數據庫服務器上。使用這種方法很難維護數據庫更改。
- NoSQL 方法是將數據存儲在為存儲大量數據而構建的數據庫中。這些通常甚至不是數據庫，而是特定的文件存儲。與關係數據庫相比，功能非常差。
- 數據緩存。出現了整個緩存 DBMS，而不是數據庫級別的簡單緩存，它只將結果存儲在內存中。
很明顯，需要單獨的人員和/或整個團隊來管理這個服務器技術動物園，這導致將數據層移除到一個單獨的層中。
重要的！當舊方法不再應對新挑戰時，所有先進技術都誕生於大型 IT 公司的深處。把數據庫做成一個單獨的層，並不是哪個程序員發明的，而是甲骨文或IBM深處某處的一群工程師發明的。
有趣的！當扎克伯格開始編寫 Facebook 時，他只是在 PHP + MySQL 上工作。當有數百萬用戶時，他們編寫了一個專門的翻譯器，將所有 PHP 代碼翻譯成 C++，並將其編譯成本機機器代碼。
此外，MySQL 無法存儲數十億用戶的數據，因此 Facebook 提出了 NoSQL 數據庫的概念，並編寫了功能強大的服務器端 NoSQL DBMS——Cassandra。順便說一下，它完全是用 Java 編寫的。
應用邏輯位置不明確
儘管三層架構幾乎明確地在其各部分之間分配了角色，但並不總是能夠準確地確定係統中需要添加業務邏輯的新部分（新代碼）的確切位置。
下圖顯示了這種歧義的一個例子：
服務器部分用灰色背景填充，客戶端部分用白色填充。後一種方法（最右邊）的一個很好的例子是現代移動應用程序。客戶端（在手機上）包含視圖（顯示）、邏輯和數據。而且只是有時這些數據會與服務器同步。
最左邊選項的一個示例是典型的 PHP 服務器，它具有服務器上的所有邏輯，並且它為客戶端提供了已經靜態的 HTML。您的項目將位於這兩個極端之間的某個位置。
剛開始工作時，在熟悉項目後，你需要諮詢從事該項目的程序員，了解哪些地方更適合你實現下一個任務的邏輯。
隨意這樣做。首先，他們不會憑章程爬進別人的修道院。其次，每個人（你也一樣）會更容易在你希望找到的地方找到你需要的代碼。