系統的架構設計是每個系統構建過程及其關鍵的一部分，決定了系統是否能夠被正確、有效地構建。

系統架構設計描述了在應用系統的內部，如何根據業務、技術、組織、靈活性、可擴充套件性以及可維護性等多重因素，將應用系統劃分成不同的部分，並使這些部分相互分工，相互協作，從而為使用者提供某種特定價值的方式。

隨著面向物件分析、設計模式、企業架構模式等方法論的深入人心，從功能實現、程式碼組織的角度考慮，系統中不同職責的部分逐漸被劃分到了如下三個部分：

• 表示層：聚焦資料顯示和使用者互動
• 業務邏輯層：聚焦業務邏輯處理
• 資料訪問層：聚焦資料的儲存與訪問

每層負責的部分更趨向於具體化、細緻化，這就是最初的軟體三層架構，該架構解決了系統間呼叫複雜、職責不清的問題，更有效地降低了層與層之間的依賴關係。這是將系統在邏輯上進行劃分，而不是物理上劃分，即不同層的程式碼在進行編譯、打包、部署後依然執行在同一個程序中。

對於這種功能集中、程式碼中心化、一個釋出包、部署後執行在同一程序的應用程式，通常稱之為單塊架構應用。典型的單塊架構應用，莫過於傳統的J2EE專案所構建的產品或專案。

隨著業務的擴大，需求的增加，單塊架構很難滿足業務快速變化的需求：一方面程式碼的可維護性、擴充套件性、靈活性在降低；另一方面系統的修改成本、構建以及維護成本在顯著增加。

單塊架構及其面臨的挑戰

三層應用架構

三層應用架構的發展

層能幫助我們劃分出構成某整體事務的、上下互相支撐的不同部分。層的概念：

• 層能被單獨構造；
• 每層具有區別於其它層的顯著特點；
• 層與層之間能夠互相連線，互相支撐，互相作用，相互協作，從而構成一個整體；
• 層的內部可以被替換成其他可工作的部分，但對整體的影響不大。

Web程式開發早期受到到面向過程思維以及設計方式的影響，所有的邏輯程式碼呼叫相互交錯，錯綜複雜，如早期的PHP、JSP以及ASP便是將所有的頁面邏輯、業務邏輯以及資料庫訪問邏輯放在一起，即一層架構。

隨著Java、.NET的發展，資料訪問部分的程式碼逐漸有了清晰的結構，但表示邏輯和業務邏輯依然交織在一起，即二層架構。

隨著面向物件分析、面向物件設計、面向物件原則、設計模式、企業架構模式等理念以及方法論的不斷髮展，從而為使用者提供以及有效組織軟體結構的考慮，Web根據職責的不同逐漸被定義在不同的層次，每一層負責的部分更趨向於具體化、細緻化，即三層架構。

什麼是三層架構

三層架構通常包括表示層、業務邏輯層以及資料訪問層、

• 表示層

表示層指的是使用者使用應用程式時與其互動操作的部分，通過該部分進行互動並獲取期望的結果。目前使用者介面大部分為Web形式，也可以是桌面軟體形式。

• 業務邏輯層

業務邏輯層是根據使用者輸入的資訊，進行邏輯計算或業務處理的部分。業務邏輯層主要聚焦應用程式對業務問題的邏輯處理，以及業務流程的操作，它是大部分軟體系統區別於其他系統的核心。

• 資料訪問層

在使用者同應用程式互動的過程中就會產生資料，這類資料需要通過某種機制被有效地儲存，以便將來使用。這種機制或方法就是資料訪問層最關注的部分。它關注的是對原始資料的操作，而不是對資料儲存介質，即資料庫的操作。

三層架構的優勢

三層架構一方面解決了應用程式中程式碼間呼叫複雜、程式碼職責不清的問題。其通過在各層間定義介面，並將介面與實現分離，可以很容易地利用不同的實現來替換原有層次的實現，從而降低層與層之間的依賴。這種方式不僅有利於幫助團隊理解整個應用架構，降低後期維護成本，同時也有利於制定整個應用程式架構的標準。

另一方面，三層架構的出現從某種程度上解決了企業內部如何有效根據技能調配人員，提高生產效率的問題。

單塊架構

什麼是單塊架構

三層架構將應用從邏輯上分為三層，但最終經歷編譯、打包、部署後，不考慮負載均衡以及水平擴充套件的情況，最終還是執行在同一臺機器的同一個程序中。對於這種功能集中、程式碼和資料中心化、一個釋出包、部署後執行在同一程序的應用程式，我們稱之為單塊架構應用。

單塊架構的優勢

• 易於開發

• 易於測試

  由於所有功能都執行在一個程序中，啟動開發環境或將釋出包部署到某一環境，一旦啟動該程序，就能立即開始策測試。

• 易於部署

所有功能最終都會被打成一個包，因此只需複製該軟體包到伺服器相應的位置即可。最簡單的方式是使用scp遠端複製到指定目錄下。

• 易於水平伸縮

單塊架構面臨的挑戰

• 維護成本增加

隨著應用程式功能越來越多，團隊越來越大，相應的成本必然增加。此外當出現缺陷時，由於引起缺陷的原因組合會比較多，這將導致修復缺陷的成本增加，週期增長。

另外隨著程式碼量增加，在開發人員對全域性功能缺乏深度理解下，修復一個缺陷，可能引入其他缺陷。

• 持續交付週期長

隨著應用程式的功能越來越多，程式碼越來越複雜，構建和部署的時間也會響應增加。

• 新人培養週期長

隨著應用程式的功能越來越多，對於新加入的團隊成員而言，瞭解行業背景、熟悉應用程式業務、配置本地開發環境這些任務將消耗其大量的時間。

• 技術選型成本高

傳統的單塊架構系統傾向於採用統一的技術平臺或方案解決所有問題。因此對於單塊架構的應用而言，初始的技術選型嚴重限制了將來採用不同語言或框架的能力。

• 可擴充套件性差

（1）垂直擴充套件：所有程式碼都執行在同一臺伺服器上，將會導致應用程式擴充套件非常困難。相對而言垂直擴充套件是最容易的，但成本會越來越高；

（2）水平擴充套件：水平擴充套件的通常方法是建立一個叢集，通過在叢集中不斷新增新節點，然後藉助前端的負載均衡器，將使用者請求根據某種演算法合理地分配到不同的節點上。

對於單塊架構而言，所有程式程式碼都執行在伺服器同一個程序中，則會導致應用程式的水平擴充套件成本高。比如某部分功能是記憶體密集型，另一個部分是CPU密集型，當擴充套件時就需要新節點必須有足夠的記憶體和強勁的CPU。

• 構建全功能團隊難

單塊架構的開發模式在分工時以進呢個為單位，這樣的分工會導致任何功能的改變都需要跨團隊溝通和協調。