在系統從 0 到 1 的階段，爲了讓系統快速上線，我們通常是不考慮分層的。但是隨着業務越來越複雜，大量的代碼糾纏在一起，會出現邏輯不清晰、各模塊相互依賴、代碼擴展性差、改動一處就牽一髮而動全身等問題。
這時，對系統進行分層就會被提上日程，那麼我們要如何對架構進行分層？架構分層和高併發架構設計又有什麼關係呢？本節課，我將帶你尋找答案。
什麼是分層架構
軟件架構分層在軟件工程中是一種常見的設計方式，它是將整體系統拆分成 N 個層次，每個層次有獨立的職責，多個層次協同提供完整的功能。
我們在剛剛成爲程序員的時候，會被“教育”說系統的設計要是“MVC”（Model-View-Controller）架構。它將整體的系統分成了 Model（模型），View（視圖）和 Controller（控制器）三個層次，也就是將用戶視圖和業務處理隔離開，並且通過控制器連接起來，很好地實現了表現和邏輯的解耦，是一種標準的軟件分層架構。
另外一種常見的分層方式是將整體架構分爲表現層、邏輯層和數據訪問層：
表現層，顧名思義嘛，就是展示數據結果和接受用戶指令的，是最靠近用戶的一層；
邏輯層裏面有複雜業務的具體實現；
數據訪問層則是主要處理和存儲之間的交互。
這是在架構上最簡單的一種分層方式。其實，我們在不經意間已經按照三層架構來做系統分層設計了，比如在構建項目的時候，我們通常會建立三個目錄：Web、Service 和 Dao，它們分別對應了表現層、邏輯層還有數據訪問層。
除此之外，如果我們稍加留意，就可以發現很多的分層的例子。比如我們在大學中學到的 OSI 網絡模型，它把整個網絡分成了七層，自下而上分別是物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層。
工作中經常能用到 TCP/IP 協議，它把網絡簡化成了四層，即鏈路層、網絡層、傳輸層和應用層。每一層各司其職又互相幫助，網絡層負責端到端的尋址和建立連接，傳輸層負責端到端的數據傳輸等，同時相鄰兩層還會有數據的交互。這樣可以隔離關注點，讓不同的層專注做不同的事情。
Linux 文件系統也是分層設計的，從下圖你可以清晰地看出文件系統的層次。在文件系統的最上層是虛擬文件系統（VFS），用來屏蔽不同的文件系統之間的差異，提供統一的系統調用接口。虛擬文件系統的下層是 Ext3、Ext4 等各種文件系統，再向下是爲了屏蔽不同硬件設備的實現細節，我們抽象出來的單獨的一層——通用塊設備層，然後就是不同類型的磁盤了。
我們可以看到，某些層次負責的是對下層不同實現的抽象，從而對上層屏蔽實現細節。比方說 VFS 對上層（系統調用層）來說提供了統一的調用接口，同時對下層中不同的文件系統規約了實現模型，當新增一種文件系統實現的時候，只需要按照這種模型來設計，就可以無縫插入到 Linux 文件系統中。
'那麼，爲什麼這麼多系統一定要做分層的設計呢？答案是分層設計存在一定的優勢。
分層有什麼好處
分層的設計可以簡化系統設計，讓不同的人專注做某一層次的事情。想象一下，如果你要設計一款網絡程序卻沒有分層，該是一件多麼痛苦的事情。
因爲你必須是一個通曉網絡的全才，要知道各種網絡設備的接口是什麼樣的，以便可以將數據包發送給它。你還要關注數據傳輸的細節，並且需要處理類似網絡擁塞，數據超時重傳這樣的複雜問題。當然了，你更需要關注數據如何在網絡上安全傳輸，不會被別人窺探和篡改。
而有了分層的設計，你只需要專注設計應用層的程序就可以了，其他都可以交給下面幾層來完成。
再有，分層之後可以做到很高的複用。比如，我們在設計系統 A 的時候，發現某一層具有一定的通用性，那麼我們可以把它抽取獨立出來，在設計系統 B 的時候使用起來，這樣可以減少研發週期，提升研發的效率。
最後一點，分層架構可以讓我們更容易做橫向擴展。如果系統沒有分層，當流量增加時我們需要針對整體系統來做擴展。但是，如果我們按照上面提到的三層架構將系統分層後，就可以針對具體的問題來做細緻的擴展。
比如說，業務邏輯裏面包含有比較複雜的計算，導致 CPU 成爲性能的瓶頸，那這樣就可以把邏輯層單獨抽取出來獨立部署，然後只對邏輯層來做擴展，這相比於針對整體系統擴展所付出的代價就要小得多了。
這一點也可以解釋我們課程開始時提出的問題：架構分層究竟和高併發設計的關係是怎樣的？從“01 | 高併發系統：它的通用設計方法是什麼？”中我們瞭解到，橫向擴展是高併發系統設計的常用方法之一，既然分層的架構可以爲橫向擴展提供便捷， 那麼支撐高併發的系統一定是分層的系統。
如何來做系統分層
說了這麼多分層的優點，那麼當我們要做分層設計的時候，需要考慮哪些關鍵因素呢？
在我看來，最主要的一點就是你需要理清楚每個層次的邊界是什麼。你也許會問：“如果按照三層架構來分層的話，每一層的邊界不是很容易就界定嗎？”
沒錯，當業務邏輯簡單時，層次之間的邊界的確清晰，開發新的功能時也知道哪些代碼要往哪兒寫。但是當業務邏輯變得越來越複雜時，邊界就會變得越來越模糊，給你舉個例子。
任何一個系統中都有用戶系統，最基本的接口是返回用戶信息的接口，它調用邏輯層的 GetUser 方法，GetUser 方法又和 User DB 交互獲取數據，就像下圖左邊展示的樣子。
這時，產品提出一個需求，在 APP 中展示用戶信息的時候，如果用戶不存在，那麼要自動給用戶創建一個用戶。同時，要做一個 HTML5 的頁面，HTML5 頁面要保留之前的邏輯，也就是不需要創建用戶。這時邏輯層的邊界就變得不清晰，表現層也承擔了一部分的業務邏輯（將獲取用戶和創建用戶接口編排起來）。
那我們要如何做呢？參照阿里發佈的《阿里巴巴 Java 開發手冊 v1.4.0（詳盡版）》，我們可以將原先的三層架構細化成下面的樣子：
我來解釋一下這個分層架構中的每一層的作用
終端顯示層：各端模板渲染並執行顯示的層。當前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移動端展示等。
開放接口層：將 Service 層方法封裝成開放接口，同時進行網關安全控制和流量控制等。
Web 層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
Service 層：業務邏輯層。
Manager 層：通用業務處理層。這一層主要有兩個作用，其一，你可以將原先 Service 層的一些通用能力下沉到這一層，比如與緩存和存儲交互策略，中間件的接入；其二，你也可以在這一層封裝對第三方接口的調用，比如調用支付服務，調用審覈服務等。
DAO 層：數據訪問層，與底層 MySQL、Oracle、HBase 等進行數據交互。
外部接口或第三方平臺：包括其它部門 RPC 開放接口，基礎平臺，其它公司的 HTTP 接口。
'
在這個分層架構中主要增加了 Manager 層，它與 Service 層的關係是：Manager 層提供原子的服務接口，Service 層負責依據業務邏輯來編排原子接口。
以上面的例子來說，Manager 層提供創建用戶和獲取用戶信息的接口，而 Service 層負責將這兩個接口組裝起來。這樣就把原先散佈在表現層的業務邏輯都統一到了 Service 層，每一層的邊界就非常清晰了。
除此之外，分層架構需要考慮層次之間一定是相鄰層互相依賴，數據的流轉也只能在相鄰的兩層之間流轉。
我們還是以三層架構爲例，數據從表示層進入之後一定要流轉到邏輯層，做業務邏輯處理，然後流轉到數據訪問層來和數據庫交互。那麼你可能會問：“如果業務邏輯很簡單的話可不可以從表示層直接到數據訪問層，甚至直接讀數據庫呢？”
其實從功能上是可以的，但是從長遠的架構設計考慮，這樣會造成層級調用的混亂，比方說如果表示層或者業務層可以直接操作數據庫，那麼一旦數據庫地址發生變更，你就需要在多個層次做更改，這樣就失去了分層的意義，並且對於後面的維護或者重構都會是災難性的。
分層架構的不足
任何事物都不可能是盡善盡美的，分層架構雖有優勢也會有缺陷，它最主要的一個缺陷就是增加了代碼的複雜度。
[03 , running , editor]
這是顯而易見的嘛，明明可以在接收到請求後就可以直接查詢數據庫獲得結果，卻偏偏要在中間插入多個層次，並且有可能每個層次只是簡單地做數據的傳遞。有時增加一個小小的需求也需要更改所有層次上的代碼，看起來增加了開發的成本，並且從調試上來看也增加了複雜度，原本如果直接訪問數據庫我只需要調試一個方法，現在我卻要調試多個層次的多個方法。
另外一個可能的缺陷是，如果我們把每個層次獨立部署，層次間通過網絡來交互，那麼多層的架構在性能上會有損耗。這也是爲什麼服務化架構性能要比單體架構略差的原因，也就是所謂的“多一跳”問題。
那我們是否要選擇分層的架構呢？答案當然是肯定的。
你要知道，任何的方案架構都是有優勢有缺陷的，天地尚且不全何況我們的架構呢？分層架構固然會增加系統複雜度，也可能會有性能的損耗，但是相比於它能帶給我們的好處來說，這些都是可以接受的，或者可以通過其它的方案解決的。我們在做決策的時候切不可以偏概全，因噎廢食。