分層模式是最通用的架構,也被叫做N層架構模式(n-tier architecture pattern).這也是Java EE應用經常採用的標準模式.基本上都知道它.這種架構模式非常適合傳統的IT通信和組織結構,很自然地成爲大部分應用的第一架構選擇.
模式描述
在分層架構中的組件被劃分成幾個層,每個層代表應用的一個功能.分層架構本身沒有規定要分成多少層,大部分的應用會分成表現層,業務層,持久層和數據庫層.小的應用有時候會將業務層和持久層合在一起,更大規模的應用可能會劃分更多的層,比如調用外部服務的層.
每一層都有特定的角色和職能.各層實現的功能如下:
- 表現層(presentation):用戶界面,負責視覺和用戶互動
- 業務層(business):實現業務邏輯
- 持久層(persistence):提供數據,SQL 語句就放在這一層
- 數據庫(database):保存數據
分層架構的一個特性就是關注分離(separation of concerns).在層中的組件只負責本層的邏輯.組件的劃分很容易讓它們實現自己的角色和職責,也比較容易地開發,測試管理和維護.
關鍵概念
注意每一層都是封閉的.這意味着Request必須經過每一層才能到達最底下一層.
爲什麼不允許展示層直接訪問數據庫層呢,這樣不是更快嗎?這就是分層架構的另一個特徵:層隔離(layers of isolation).
層隔離的概念意味着你對任何一層的改變都不會影響其它層,這很好理解.層隔離也意味着一個層的組件並不會瞭解其它層的實現,或者知道很少. 比如業務層不需知道你持久層是由hibernate還是mybatis實現的.
分層架構也很容易增加新的層. 比如你想將一些通用的服務重構成一個服務層,比如通用圖片處理,遠程賬戶審計等,可以在業務層下增加一個服務層.它不會對展示層造成影響,也不會改變持久層的代碼.
上面的這個例子帶來一個問題,因爲每一層是封閉的,業務層不得不通過服務層訪問持久層. 所以有時候你會創建一個開放的層.這意味着上一層可以繞過這一層直接訪問下一層.
架構例子
架構考量
分層架構是一個可靠的通用的架構,對很多應用來說,如果你不確定哪種架構適合你的應用,可以用它作爲一個初始架構.第一個要注意的是污水池反模式(architecture sinkhole anti-pattern).這個反模式是這樣的,請求流簡單的穿過幾個層,每層裏面基本沒有做任何業務邏輯,或者做了很少的業務邏輯,比如一些JavaEE例子,業務邏輯層只是簡單的調用了持久層的接口,本身沒有什麼業務邏輯.每一層或多或少都有可能遇到這樣的場景.關鍵是分析這樣的請求的百分比是多少.80-20原則可以幫助你決定是否正在遇到污水池反模式,如果你的請求超過20%,你應該考慮讓一些層變成開放的.
另一個需要考慮的是分層架構可能會讓你的應用變得龐大,即使你的展示層和業務層可以獨立發佈（比如展示層使用單頁技術框架AngularJS, EmberJS）.它的確會帶來一些潛在的問題,比如分佈模式複雜,健壯性下降,可靠性,性能和規模等.
模式分析
- 總體靈活性: 低
- 發佈易用性:低
- 可測試性: 高
- 性能:低
- 規模擴展性: 低
- 開發容易度: 高
優點
- 結構簡單,容易理解和開發
- 不同技能的程序員可以分工,負責不同的層,天然適合大多數軟件公司的組織架構
- 每一層都可以獨立測試,其他層的接口通過模擬解決
- 一旦環境變化,需要代碼調整或增加功能時,通常比較麻煩和費時
- 部署比較麻煩,即使只修改一個小地方,往往需要整個軟件重新部署,不容易做持續發佈
- 軟件升級時,可能需要整個服務暫停
- 擴展性差.用戶請求大量增加時,必須依次擴展每一層,由於每一層內部是耦合的,擴展會很困難