摘要：分層架構簡單而高效，業界已經有很多成熟的應用，對那些項目剛剛起步，架構師們還沒想好要采用哪種架構模式的系統而言，這是非常適合的。
前言
軟件剛出現的時候，還是大型計算機的年代，一個軟件系統一般都只會運行在一台機器上。隨着軟硬件技術的革新，計算機體積和成本逐漸變小，此時工程師們發現一個軟件系統只運行在單台機器上會存在各種瓶頸。如果將系統按照功能划分成前端和后端，分別部署在兩台服務器上，問題得到了緩解，於是便有了Client/Server架構的出現。
隨后，個人電腦的興起帶動了眾多富桌面應用（rich desktop application）的出現，它們基於操作系統上的user interface開發，數據則是存儲在單獨部署的database server上，通過標准的網絡協議進行數據通信。這種Desktop + Database Server的架構和C/S架構一樣，同屬兩層架構（two-tier architecture）。
隨着90年代互聯網的迅速崛起，Browser + Web Server + Database Server的組合也漸漸風靡。Browser為表現層，提供用戶交互界面；Web Server為業務層，處理具體的業務邏輯；Database Server為數據層，存儲系統數據。三個層次各司其職，這也是大家最熟悉的三層架構（three-tier architecture）。
上述的幾種架構模式都屬於分層架構（layered architecture）的范疇，分層架構並沒有限定一定得有多少個層次，層次的數量可以根據應用場景靈活控制，因此也被稱為n-tier architecture。它結構簡單，基於此架構進行系統開發成本也很低（很多公司在組織結構上划分為前端工程師、后端工程師、DBA，根據康威定律，這天然就具備了分層架構開發的良好條件），因此它在業界備受歡迎。如果你的團隊還不確定選擇什么樣的架構，又或者為了踐行敏捷宣言中的“just starts coding“，那么分層架構會是一個不錯的選擇。
架構視圖
在分層架構中，組件根據功能被划分在不同的層次上，雖然層次的數量和類型並沒有被限制，但大多數的分層架構都由以下4層組成：表現層（presentation）、業務層（business）、持久層（persistence）和數據層（database），如下圖所示。在一些簡單的系統中，持久層的邏輯（如SQL）被嵌入到業務層中，形成了經典的三層架構；而在一些復雜的系統中，也會根據具體的業務划分為五層甚至更多的層次。
分層架構的標准邏輯分層
前文所述的表現層等4個層次都是邏輯的划分方法，在實際部署時，一般會有下圖所示的幾種部署形態。形態1中，表現層、業務層和持久層為一個部署單元，而數據層則單獨部署，具體表現為一個獨立部署的數據庫或文件系統；形態2中，表現層被分離出單獨部署，業務層和持久層組成一個部署單元，數據層依舊是單獨部署的數據庫或文件系統；形態3中，包括數據層在內的4層全都在同一個部署單元內，常見於業務簡單的系統，它們往往使用的是嵌入式數據庫或內存數據庫。
分層架構的部署形態
分層架構中的每一層都扮演着各自的角色，比如表現層負責處理所有的用戶請求和瀏覽器交互，而業務層則負責執行每次請求下的特定業務邏輯；表現層無需擔心從哪里獲取用戶數據，它只需要將數據以特定的格式在瀏覽器上顯示即可。同樣地，業務層也無需關心用戶數據從何而來以及如何呈現，它只需從持久層中取出數據，執行特定的業務邏輯（比如聚合數據），然后將結果返回給表現層。
每一層都是特定行為的抽象，這樣的職責划分，使得組織能夠快速高效地創建出責任模型，圍繞各層打造開發團隊。
層間隔離
分層架構中的每一層可以是封閉的或者開放的，封閉意味着當一個請求自頂向下在層間傳遞時，它不能跳過任意的一層。比如，當表現層接收到請求之后，它必須先后經過業務層和持久層才能到達數據層，如下圖所示。
封閉的分層架構
對於簡單的數據獲取類請求，如果讓表現層能夠直接訪問數據層獲取數據，無疑是最簡單高效的。也即是讓業務層和持久層變成開放狀態，允許請求在層間傳遞時跳過此層。那么，究竟是封閉好，還是開放好呢？要解答這個問題，就要回到層間隔離的出發點上。
所謂的層間隔離，旨在降低一個層次上的變化對其他層次的組件的影響，簡單來說，就是每個層次對其他層次的功能知道的越少越好。為了達到層間隔離的目的，就需要將每個層次置為封閉的狀態。假設表現層能夠直接訪問持久層，那么持久層的變化將會直接影響到業務層和表現層，這加劇了層間的耦合，導致系統變化的代價高昂。
層間隔離可以降低層次變化對系統的影響，凡事沒有絕對，在某些的場景，將特定的層次置為開放的狀態也不失為一件好事。考慮以下例子，業務層中存在着一些共享組件承載着業務層公共的功能（比如日志類、審計類、日期和字符串工具類等）。現在有一項架構決策要求表現層不能直接訪問這些共享組件，但矛盾的是，原則上表現層是可以直接訪問業務層的，這種需要違反原則的決策將會很難落地。
業務層中的共享組件
一種解決方法是，新增一個服務層，該層包含了業務層的這些共享組件。因為業務層是關閉的狀態，故表現層也就不能訪問到這些共享組件了。然而，新增的服務層必須置為開放狀態，否則業務層將無法直接訪問持久層。新增一個服務層並置為開放狀態，這樣既落地了架構決策，也不會影響到原有的功能，一舉兩得。
在分層架構中新增一個層次
一些注意事項
在使用分層架構時，需要注意以下兩點：
1、做好模塊的划分
為分層架構做好模塊划分主要是為后續的架構演進做好准備，比如在業務復雜到一定程度后演進為微服務架構時，各個模塊可以很自然地演進為微服務。為此，應該避免出現類的繼承層次過深的現象，這會導致代碼嚴重的耦合，不利於后續的架構演進。
2、避免掉進sinkhole反模式的陷阱
所謂sinkhole反模式指的是請求只是簡單地路過各個層次，並沒有做一些業務處理。
比如，表現層接收到一個獲取基本用戶數據（姓名、地址等）的請求后將它傳遞到業務層；然而，業務層並沒有做任何的業務處理，直接將請求傳遞到持久層；持久層也僅僅是構造了一個簡單的SQL語句，向數據層查詢用戶數據；最后，數據按照原路返回到表現層，中途沒有經過任何的數據匯聚、轉換等操作。
sinkhole反模式會導致很多不必要的對象實例化開銷，從而增大了系統的內存消耗，並且影響了性能。
然而，一個系統多多少少都會存在一些sinkhole反模式場景，要判斷一個系統是否已經徹底掉進sinkhole反模式的陷阱，主要還是看這類業務請求所占的百分比。根據20-80法則，當系統中有超過80%的業務請求是sinkhole類請求時，表示系統已經掉進sinkhole反模式的陷阱，這從側面也說明該系統已經不再適合分層架構，是時候考慮架構演進了。
綜合得分
分層架構的綜合得分
從綜合得分上看，分層架構的Overall cost和Simplicity得分很高，這很大程度上得益於分層架構本身是單體架構，少了很多分布式系統才有的復雜性。但這樣導致Deployability得分很低，因為3行代碼的改動就足以造成整個系統的重新部署。Testability得分不高也是這個原因，整系統的重新上線通常都需要將測試用例全部執行一遍，多了不少額外的工作量。
Elasticity、Fault tolerance、Scalability這些都是單體架構天然的劣勢，自然地，分層架構在這些方面得分都很低。另外，sinkhole反模式的存在也拉低了分層架構在Performance上的得分。
總結
分層架構簡單而高效，業界已經有很多成熟的應用，對那些項目剛剛起步，架構師們還沒想好要采用哪種架構模式的系統而言，這是非常適合的。在實現分層架構時，我們需要合理地設置各個層次的封閉或開放狀態，做好層間隔離，同時也要避免掉進sinkhole反模式陷阱。隨着業務的不斷擴張，分層架構在可維護性、可測試性、可擴展性等上的短板也會逐步被放大，此時就需要考慮往其他架構模式演進了。