高并發系統設計二（架構分層）

在系統從 0 到 1 的階段，為了讓系統快速上線，我們通常是不考慮分層的，但是隨著業務越來越復雜，大量的代碼糾纏在一起，會出現邏輯不清晰、各模塊相互依賴、代碼擴展性差、改動一處就牽一發而動全身等問題，

這時，對系統進行分層就會被提上日程，那么我們要如何對架構進行分層？架構分層和高并發架構設計又有什么關系呢？本節課，我將帶你尋找答案，

什么是分層架構
軟體架構分層在軟體工程中是一種常見的設計方式，它是將整體系統拆分成 N 個層次，每個層次有獨立的職責，多個層次協同提供完整的功能，

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

另外一種常見的分層方式是將整體架構分為表現層、邏輯層和資料訪問層：
1、表現層，顧名思義嘛，就是展示資料結果和接受用戶指令的，是最靠近用戶的一層；
2、邏輯層里面有復雜業務的具體實作；
3、資料訪問層則是主要處理和存盤之間的互動，

這是在架構上最簡單的一種分層方式，其實，我們在不經意間已經按照三層架構來做系統分層設計了，比如在構建專案的時候，我們通常會建立三個目錄：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（詳盡版）》，我們可以將原先的三層架構細化成下面的樣子：

我來解釋一下這個分層架構中的每一層的作用，
1、終端顯示層：各端模板渲染并執行顯示的層，當前主要是 Velocity 渲染，JS 渲染， JSP渲染，移動端展示等，
2、開放介面層：將 Service 層方法封裝成開放介面，同時進行網關安全控制和流量控制等，
3、Web 層：主要是對訪問控制進行轉發，各類基本引數校驗，或者不復用的業務簡單處理等，
4、Service 層：業務邏輯層，
5、Manager 層：通用業務處理層，這一層主要有兩個作用，其一，你可以將原先 Service層的一些通用能力下沉到這一層，比如與快取和存盤互動策略，中間件的接入；其二，你也可以在這一層封裝對第三方介面的呼叫，比如呼叫支付服務，呼叫審核服務等，
6、DAO 層：資料訪問層，與底層 MySQL、Oracle、Hbase 等進行資料互動，
外部介面或第三方平臺：包括其它部門 RPC 開放介面，基礎平臺，其它公司的 HTTP 介面，

在這個分層架構中主要增加了 Manager 層，它與 Service 層的關系是：Manager 層提供原子的服務介面，Service 層負責依據業務邏輯來編排原子介面，

以上面的例子來說，Manager 層提供創建用戶和獲取用戶資訊的介面，而 Service 層負責將這兩個介面組裝起來，這樣就把原先散布在表現層的業務邏輯都統一到了 Service 層，每一層的邊界就非常清晰了，

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

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

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

分層架構的不足
任何事物都不可能是盡善盡美的，分層架構雖有優勢也會有缺陷，它最主要的一個缺陷就是增加了代碼的復雜度，

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

另外一個可能的缺陷是，如果我們把每個層次獨立部署，層次間通過網路來互動，那么多層的架構在性能上會有損耗，這也是為什么服務化架構性能要比單體架構略差的原因，也就是所謂的“多一跳”問題，

那我們是否要選擇分層的架構呢？答案當然是肯定的，

你要知道，任何的方案架構都是有優勢有缺陷的，天地尚且不全何況我們的架構呢？分層架構固然會增加系統復雜度，也可能會有性能的損耗，但是相比于它能帶給我們的好處來說，這些都是可以接受的，或者可以通過其它的方案解決的，我們在做決策的時候切不可以偏概全，因噎廢食，

摘自億級高并發系統設計