「系統設計」為什么要做架構分層？

參考&鳴謝

3.設計模式之分層思維：為什么要做代碼分層架構？

從零開始學架構（八）分層架構和設計模式

架構模式之分層架構總結

文章目錄

「系統設計」為什么要做架構分層？
- 一、什么是分層架構
- - MVC
  - OSI
  - TCP/IP
  - 文件系統
- 二、分層有什么好處
- - 模塊化
  - 復用性
  - 拓展性
- 三、如何來做系統分層
- - 確定層次
  - 定義接口
  - 遵循設計原則
- 四、分層架構的不足
- - 復雜性問題
  - 性能問題
  - 靈活性問題
- 五、回顧&小結

引言

在軟件系統設計中，分層架構是一種常見而強大的設計模式。通過將系統劃分為不同的層次，每個層次專注于特定功能，分層架構有助于提高系統的可維護性、可擴展性和模塊化。本文將深入探討分層架構的底層原理，闡述其優勢以及一些可能的缺陷。

一、什么是分層架構

分層架構是一種將系統劃分為多個層次的設計模式，每個層次專注于特定的功能。這樣的設計使得系統的不同部分能夠更好地組織和管理，從而提高了系統的可維護性、可擴展性和可理解性。

MVC

我們在剛剛成為程序員的時候，會被“教育”說系統的設計要是“MVC”（Model-View-Controller）架構。它將整體的系統分成了 Model（模型），View（視圖）和 Controller（控制器）三個層次，也就是將用戶視圖和業務處理隔離開，并且通過控制器連接起來，很好地實現了表現和邏輯的解耦，是一種標準的軟件分層架構。

另外一種常見的分層方式是將整體架構分為表現層、邏輯層和數據訪問層：

表現層，顧名思義嘛，就是展示數據結果和接受用戶指令的，是最靠近用戶的一層；
邏輯層里面有復雜業務的具體實現；
數據訪問層則是主要處理和存儲之間的交互。

這是在架構上最簡單的一種分層方式。其實，我們在不經意間已經按照三層架構來做系統分層設計了，比如在構建項目的時候，我們通常會建立三個目錄：Web、Service 和 Dao，它們分別對應了表現層、邏輯層還有數據訪問層。

OSI

除此之外，如果我們稍加留意，就可以發現很多的分層的例子。比如我們在大學中學到的 OSI 網絡模型，它把整個網絡分了七層，自下而上分別是物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層。

TCP/IP

工作中經常能用到 TCP/IP 協議，它把網絡簡化成了四層，即鏈路層、網絡層、傳輸層和應用層。每一層各司其職又互相幫助，網絡層負責端到端的尋址和建立連接，傳輸層負責端到端的數據傳輸等，同時呢相鄰兩層還會有數據的交互。這樣可以隔離關注點，讓不同的層專注做不同的事情。

文件系統

Linux 文件系統也是分層設計的，從下圖你可以清晰地看出文件系統的層次。在文件系統的最上層是虛擬文件系統（VFS），用來屏蔽不同的文件系統之間的差異，提供統一的系統調用接口。虛擬文件系統的下層是 Ext3、Ext4 等各種文件系統，再向下是為了屏蔽不同硬件設備的實現細節，我們抽象出來的單獨的一層——通用塊設備層，然后就是不同類型的磁盤了。

我們可以看到，某些層次負責的是對下層不同實現的抽象，從而對上層屏蔽實現細節。比方說 VFS 對上層（系統調用層）來說提供了統一的調用接口，同時對下層中不同的文件系統規約了實現模型，當新增一種文件系統實現的時候，只需要按照這種模型來設計，就可以無縫插入到 Linux 文件系統中。

那么，為什么這么多系統一定要做分層的設計呢？答案是分層設計存在一定的優勢。

二、分層有什么好處

模塊化

**分層的設計可以簡化系統設計，讓不同的人專注做某一層次的事情。**想象一下，如果你要設計一款網絡程序卻沒有分層，該是一件多么痛苦的事情。

因為你必須是一個通曉網絡的全才，要知道各種網絡設備的接口是什么樣的，以便可以將數據包發送給它。你還要關注數據傳輸的細節，并且需要處理類似網絡擁塞，數據超時重傳這樣的復雜問題。當然了，你更需要關注數據如何在網絡上安全傳輸，不會被別人窺探和篡改。

而有了分層的設計，你只需要專注設計應用層的程序就可以了，其他的，都可以交給下面幾層來完成。

復用性

**再有，分層之后可以做到很高的復用。**比如，我們在設計系統 A 的時候，發現某一層具有一定的通用性，那么我們可以把它抽取獨立出來，在設計系統 B 的時候使用起來，這樣可以減少研發周期，提升研發的效率。

拓展性

**最后一點，分層架構可以讓我們更容易做橫向擴展。**如果系統沒有分層，當流量增加時我們需要針對整體系統來做擴展。但是，如果我們按照上面提到的三層架構將系統分層后，那么我們就可以針對具體的問題來做細致的擴展。

比如說，業務邏輯里面包含有比較復雜的計算，導致 CPU 成為性能的瓶頸，那這樣就可以把邏輯層單獨抽取出來獨立部署，然后只對邏輯層來做擴展，這相比于針對整體系統擴展所付出的代價就要小的多了。

橫向擴展是高并發系統設計的常用方法之一，既然分層的架構可以為橫向擴展提供便捷，那么支撐高并發的系統一定是分層的系統。

三、如何來做系統分層

說了這么多分層的優點，那么當我們要做分層設計的時候，需要考慮哪些關鍵因素呢？

確定層次

在我看來，最主要的一點就是你需要理清楚每個層次的邊界是什么。你也許會問：“如果按照三層架構來分層的話，每一層的邊界不是很容易就界定嗎？”

沒錯，當業務邏輯簡單時，層次之間的邊界的確清晰，開發新的功能時也知道哪些代碼要往哪兒寫。但是當業務邏輯變得越來越復雜時，邊界就會變得越來越模糊。

定義接口

任何一個系統中都有用戶系統，最基本的接口是返回用戶信息的接口，它調用邏輯層的 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 層，每一層的邊界就非常清晰了。

除此之外，分層架構需要考慮的另一個因素，是層次之間一定是相鄰層互相依賴，數據的流轉也只能在相鄰的兩層之間流轉。

我們還是以三層架構為例，數據從表示層進入之后一定要流轉到邏輯層，做業務邏輯處理，然后流轉到數據訪問層來和數據庫交互。那么你可能會問：“如果業務邏輯很簡單的話可不可以從表示層直接到數據訪問層，甚至直接讀數據庫呢？”

其實從功能上是可以的，但是從長遠的架構設計考慮，這樣會造成層級調用的混亂，比方說如果表示層或者業務層可以直接操作數據庫，那么一旦數據庫地址發生變更，你就需要在多個層次做更改，這樣就失去了分層的意義，并且對于后面的維護或者重構都會是災難性的。

四、分層架構的不足

任何事物都不可能是盡善盡美的，分層架構雖有優勢也會有缺陷。

復雜性問題

它最主要的一個缺陷就是增加了代碼的復雜度。這是顯而易見的嘛，明明可以在接收到請求后就可以直接查詢數據庫獲得結果，卻偏偏要在中間插入多個層次，并且有可能每個層次只是簡單地做數據的傳遞。有時增加一個小小的需求也需要更改所有層次上的代碼，看起來增加了開發的成本，并且從調試上來看也增加了復雜度，原本如果直接訪問數據庫我只需要調試一個方法，現在我卻要調試多個層次的多個方法。