參考：http://www.ruanyifeng.com/blog/2016/09/software-architecture.htmlhtml
https://blog.csdn.net/bboyfeiyu/article/details/45136299程序員
https://www.cnblogs.com/zdxster/p/5305155.htmlweb
1. 什麼是分層架構sql
分層架構是一種很常見的架構模式，它也叫N層架構。這種架構是大多數Jave EE應用的實際標準，所以不少的架構師，設計師，還有程序員都知道它。許多傳統IT公司的組織架構和分層模式十分的類似。因此它很天然的成爲大多數應用的架構模式。數據庫
2. 模式分析設計模式
分層架構模式裏的組件被分紅幾個平行的層次，每一層都表明了應用的一個功能(展現邏輯或者業務邏輯)。儘管分層架構沒有規定自身要分紅幾層幾種，大多數的結構都分紅四個層次:展現層，業務層，持久層，和數據庫層。有時候，業務層和持久層會合併成單獨的一個業務層，尤爲是持久層的邏輯綁定在業務層的組件當中。所以，有一些小的應用可能只有3層，一些有着更復雜的業務的大應用可能有5層或者更多的分層。數組
分層架構中的每一層都有着特定的角色和職能。服務器
舉個例子，展現層負責處理全部的界面展現以及交互邏輯，業務層負責處理請求對應的業務。架構裏的層次是具體工做的高度抽象，它們都是爲了實現某種特定的業務請求。好比說展現層並不須要關心怎樣獲得用戶數據，它只需在屏幕上以特定的格式展現信息。業務層並不關心要展現在屏幕上的用戶數據格式，也不關心這些用戶數據從哪裏來。它只須要從持久層獲得數據，執行與數據有關的相應業務邏輯，而後把這些信息傳遞給展現層。架構
分層架構的一個突出特性是組件間關注點分離 (separation of concerns)。一個層中的組件只會處理本層的邏輯。好比說，展現層的組件只會處理展現邏輯，業務層中的組件只會去處理業務邏輯。多虧了組件分離，讓咱們更容易構造有效的角色和強力的模型。這樣應用變的更好開發，測試，管理和維護。jsp
3. 關鍵概念——層隔離
這是分層架構中很是重要的特色。這意味request必須一層一層的傳遞。舉個例子，從展現層傳遞來的請求首先會傳遞到業務層，而後傳遞到持久層，最後才傳遞到數據層。
那麼爲何不容許展現層直接訪問數據層呢。若是隻是得到以及讀取數據，展現層直接訪問數據層，比穿過一層一層來獲得數據來的快多了。這涉及到一個概念:層隔離。
層隔離就是說架構中的某一層的改變不會影響到其餘層:這些變化的影響範圍限於當前層次。若是展現層可以直接訪問持久層了，假如持久層中的SQL變化了，這對業務層和展現層都有必定的影響。這隻會讓應用變得緊耦合，組件之間互相依賴。這種架構會很是的難以維護。
從另一個方面來講，分層隔離使得層與層之間都是相互獨立的，架構中的每一層的互相瞭解都不多。爲了說明這個概念的厲害之處，想象一個超級重構，把展現層從JSP換成JSF。假設展現層和業務層的之間的聯繫保持一致，業務層不會受到重構的影響，它和展現層所使用的界面架構徹底獨立。
然而封閉的架構層次也有不便之處，有時候也應該開放某一層。若是想往包含了一些由業務層的組件調用的普通服務組件的架構中添加一個分享服務層。在這個例子裏，新建一個服務層一般是一個好主意，由於從架構上來講，它限制了分享服務訪問業務層(也不容許訪問展現層)。若是沒有隔離層，就沒有任何架構來限制展現層訪問普通服務，難以進行權限管理。
開放和封閉層的概念肯定了架構層和請求流之間的關係，而且給設計師和開發人員提供了必要的信息理解架構裏各類層之間的訪問限制。若是隨意的開放或者封閉架構裏的層，整個項目可能都是緊耦合，一團糟的。之後也難以測試，維護和部署。
4. 分層架構使用的特定環境
一個須要分解的比較大的系統。這種模式對大部分JAVAEE應用程序來講是標準模式，所以被大部分架構師、軟件設計師、開發者普遍知曉。因爲分層架構模式和公司裏傳統的IT溝通以及組織結構很是相似，使得它成爲大多數商務應用開發最天然的選擇。分層的開發方式實現了人類對復瑣事物的廣泛處理方式——分而治之。經過把複雜的系統分解成爲相對簡單的獨立系統，低耦合的分解既能夠實現開發人員的並行工做，又能夠實現開發人員的任務分工。並且經過分層，對組件拼裝和流水化做業提供了理論和事實的基礎。
5. 分層模式用來解決什麼問題？
分層模式的關鍵點在於肯定依賴：即經過分層，能夠限制子系統間的依賴關係，使系統以更鬆散的方式耦合，從而更易於維護。
典型的分層方式是應用程序專用功能位於上層，跨越應用程序領域的功能位於中層，而配置環境專用功能位於低層。層的數量與組成取決於問題領域和解決方案的複雜程度。一般而言只有一個應用程序專用層。應當把子系統組織成分層結構，架構的上層是應用程序專用子系統，架構的低層是硬件和操做專用子系統，中間件層是通用服務。
對系統進行分層有以下基本原則：
●可見度。各子系統只能與同一層及其下一層的子系統存在依賴關係。
●易變性。最上層放置隨用戶需求的改變而改變的元素。最底層放置隨實施平臺（硬件、語言、操做系統、數據庫等）的改變而改變的元素。中間的夾層放置普遍適用於各類系統和實施環境的元素。若是在這些大類中進一步劃分有助於對模型進行組織，則添加更多的層。
●通用性。通常將抽象的模型元素放置在模型的低層。若是它們不針對於具體的實施，則傾向於將其放置在中間層。
●層數。對於小型系統，三層就足夠了。對於複雜系統，一般須要5-7層。不管複雜程度如何，若是超過10層，就須要慎重考慮了。層數越多，越需慎重。
6. 分層模式的解決方案
分層架構是經常使用的架構模式，對於一個大系統能夠劃分爲幾個子系統，各子系統位於不一樣的抽象層次。各層間上層依賴下層服務，下層不能依賴上層。消息能夠從上向下，也能夠從下向上。自頂向下調用下層接口，稱爲請求。自低向上的通訊，稱爲通知，通常使用回調方法，從而實現單路徑耦合。
【分層的步驟】
一、定義抽象準則
二、根據準則定義抽象層數
三、給每一個層命名並指定任務
四、指定服務
五、細化分層，重複上述步驟，直到一個穩定的分層結構
六、爲每層指定接口
七、構建獨立層
八、指定層間通訊，分離臨接層
九、設計錯誤處理策略
【分層的優勢】
分層架構模式是個可靠的通用模式，對於大部分應用它是個很好的開始，尤爲當不知道哪一種結構適合使用時。
1、下降複雜度，上層不須要關注下層細節。
2、提升靈活性，能夠靈活替換某層的實現。
3、減少耦合度，將層次間的依賴減到最低。
4、有利於重用，同一層次能夠有多種用途。
5、有利於標準化。
它有以下幾點優點：重用性好、標準化支持、局部依賴、可替換性
【分層的缺點】
分層主要有如下的缺點：影響多層次的修改；下降了效率；多層傳遞，重複的工做；層的粒度難以把握。
1、不能封裝全部工做，可能會帶來及聯修改。
2、過多層次影響性能。
分層的難點主要有： 1、如何劃分層次。
2、定義層次職責。
分層的多層傳遞中有現象被稱爲污水池反模式（architecture sinkhole anti-pattern）。該反模式描述的是這樣的場景，請求流穿過架構的不少層，每一層只有少許的甚至沒有業務邏輯。例如，假設展現層響應用戶的請求獲取客戶信息，展現層將請求傳遞給業務層，業務層什麼也不作，僅僅將請求直接傳遞給持久層，持久層執行SQL語句獲取數據。數據在回傳過程當中沒有通過任何的處理。
每一個分層架構均可能會有一些場景落入污水池反模式。然而關鍵是分析這樣的請求佔了多少比例。一般80-20定律可用來分析是否落入了污水池反模式。當反模式的比例比較大時，你或許考慮將某些層開放，這時要注意缺少層隔離，會使得之後修改時比較困難。
分層架構會使應用變得龐大，即便把表示層和業務層分紅了單獨的部署單元。這對某些應用不須要考慮，可是也會帶來一些部署的隱患，如健壯性、可靠性、性能和可伸縮性。
【分層演化過程】
單層架構-->兩層架構-->三層架構-->N層架構
單層架構：早期批處理系統
兩層架構：C/S 客戶/服務器模式
特色：沒有複雜的領域邏輯
優勢：有很是好的工具支持，VB、Delphi、PowerBuilder
缺點：代碼冗餘，難於維護。
模式：1、領域邏輯寫在客戶端
2、領域邏輯寫在數據庫（存儲過程）
面向對象技術、WEB興起、Java出現共同推動了三層架構。
Layer與Tier的區別：1、Tier強調物理上的分離，Two Tier System。2、Layer強調邏輯上的分層。
三層架構：表現層-領域層-數據源層（持久層）
1、表現層：提供服務，顯示信息。
2、領域層：系統核心邏輯。
3、數據源層：與數據庫、消息系統以及其餘軟件包通訊
7.分層架構應用實例
爲了演示分層架構是如何工做的，想象一個場景，如圖，用戶發出了一個請求要得到客戶的信息。黑色的箭頭是從數據庫中得到用戶數據的請求流，紅色箭頭顯示用戶數據的返回流的方向。在這個例子中，用戶信息由客戶數據和訂單數組組成（客戶下的訂單）。
其中，Presentation 層表明了代碼中的jsp界面層；Business 層表明代碼中處理請求並返回結果的servlet層；Persistence持久層表明代碼中的dao層；Database數據層表明了代碼中的sql語句。
用戶界面只管接受請求以及顯示客戶信息。它無論怎麼獲得數據的，或者說獲得這些數據要用到哪些數據表。若是用戶界面接到了一個查詢客戶信息的請求，它就會轉發這個請求給用戶委託(Customer Delegate）模塊。這個模塊能找到業務層裏對應的模塊處理對應數據（約束關係）。業務層裏的customer object聚合了業務請求須要的全部信息（在這個例子裏獲取客戶信息）。這個模塊調用持久層中的custom dao來獲得客戶信息，調用order dao來獲得訂單信息。這些模塊會執行SQL語句，而後返回相應的數據給業務層當customer object收到數據之後，它就會聚合這些數據而後傳遞給customer delegate，而後傳遞這些數據到customer screen展現在用戶面前。
8. 分層架構與MVC之間的區別
我相信不少人都會對這兩個概念模糊，下面咱們來分析一下這二者之間的區別與聯繫。
三層架構是一個分層式的軟件體系架構設計，它可適用於任何一個項目。
MVC是一個設計模式，它是根據項目的具體需求來決定是否適用於該項目。
那麼架構跟設計模式有什麼區別呢？
咱們從接手一個項目開始，首先，咱們須要進行架構設計，通常咱們採用的就是分層式的架構設計，即咱們的三層架構。而後，在肯定了架構之後，咱們再根據項目的具體需求去考慮是否須要應用一些設計模式，好比是否應用咱們的MVC模式，抽象工廠模式等等。最後，肯定了模式之後，就是咱們的一些具體的實現了。
其次，它倆劃分的層次不一樣。
三層架構將整個項目劃分爲：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。
MVC 即Model（模型），View（視圖），Controller（控制）。
而咱們一般所見到的MVC通常也都是在應用三層架構的基礎上，即將Model層再進行分層。而若是Model再也不進行劃分的話，那麼使用MVC的意義也就不大了。
而後，它倆的目的着重點不一樣。
三層架構的目的着重點是「高內聚，低耦合」，即解耦。
MVC的目的則是實現Web系統的職能分工，即職責劃分。
其實職責劃分也是解耦，可是三層側重的是總體的一個解耦，而MVC側重的是web系統的解耦，即側重jsp和Servlet的一個解耦。
MVC和三層架構MVC與三層架構相似麼？
三層架構是典型的架構模式（Architecture Pattern），三層架構的分層模式是典型的上下關係，上層依賴於下層。但MVC做爲表現模式是不存在上下關係的，而是相互協做關係。即便將MVC看成架構模式，也不是分層模式。MVC和三層架構基本沒有可比性，是應用於不一樣領域的技術。
分層架構是經常使用的架構模式，對於一個大系統能夠劃分爲幾個子系統，各子系統位於不一樣的抽象層次。各層間上層依賴下層服務，下層不能依賴上層。消息能夠從上向下，也能夠從下向上。自頂向下調用下層接口，稱爲請求。自低向上的通訊，稱爲通知，通常使用回調方法，從而實現單路徑耦合。