[[406066]]

前言

只要從事軟件開發的工作，系統架構是必備知識。有朋友說可能會說，我只是一個搬磚的，怎么會接觸到架構知識呢?其實，除了架構的設計者(也就是架構師)，作為普通的開發者也是在時刻踐行著系統架構的理論。畢竟，再好的架構，都需要碼農去實施。只不過當你沒有系統了解軟件架構時，可能感知不到而已。

本篇文章就帶大家系統的了解一下軟件架構的分層，學習完畢，你就會明白，為什么系統要分層。同時，也能準確的看清楚目前自己系統中采用的是什么樣的分層架構。

不采用架構分層，行不行?

首先我們來思考一個問題，如果一個系統不采用分層架構可不可以?這個問題就好像在問，代碼中不使用設計模式行不行?答案當然是可以的。但不采用架構分層，會帶來極大的未知風險，或者說代碼極具熵增的特性。

作為一個初創軟件，可能沒有什么業務邏輯，沒有什么用戶量，而軟件最主要的目標就是快速上線，實踐商業模式。此時，可以不考慮分層。但隨著業務邏輯的復雜，業務板塊的增多，彼此之間就會出現錯綜復雜的依賴關系，隨之就會產生的邏輯不清晰、可讀性差，維護困難，改動一處動全身等問題。

什么是架構分層?

分層架構是將軟件模塊按照水平切分的方式分成多個層，一個系統由多層組成，每層由多個模塊組成。同時，每層有自己獨立的職責，多個層次協同提供完整的功能。比如，我們經常提到的MVC架構，就是一種非常典型非常基礎的分層方式。

分層設計的本質其實就是將復雜問題簡單化，基于單一職責原則讓每層代碼各司其職，基于“高內聚，低耦合”的設計思想實現相關層對象之間的交互。從而，提升代碼的可維護性和可擴展性。

系統架構分層之后，往往需要達到以下目標：

• 高內聚：分層設計可以簡化系統設計，讓不同層專注做某一模塊的事;
• 低耦合：層與層之間通過接口或API來交互，依賴方不用知道被依賴方的細節;
• 復用：分層之后可以做到代碼或功能的復用;
• 擴展性：分層架構可以讓代碼更容易橫向擴展

通訊領域的OSI參考模型

在計算機領域現有最典型的分層架構設計就是OSI參考模型和TCP/IP參考模型了。關于這個模型，我們在《一篇文章，只用看三遍，終生不忘網絡分層! 》一文中已經詳細介紹了。下面直接看一下相關的模型圖：

對于上述的三種分層模式，試想一下，如果沒有分層，當一個業務或協議需要改變時，我們只能針對整個系統做修改或擴展。而分層之后，便可以很方便的把不同功能的模塊抽離出來，修改對應的模塊即可。而且不同層還可以被復用，只要確保按照這個層的協議來處理就可以了。

軟件系統整體分層

以Java軟件應用為例，整個軟件系統也可進行分層，比如分為部署的硬件環境、操作系統、所需的中間件、承載業務的應用程序以及軟件接入層。可通過下圖進行整體了解：

對于上述分層也產生了對應在職位，比如運維工程師、中間件工程師、產品經理、開發工程師、測試工程師等工種。而我們在實踐過程中，接觸最多，使用最多的分層要屬應用軟件層了，其次是中間件層。

下面我們就來看看針對應用軟件層通常有哪些分層方式。

經典三層架構

三層架構(3-tier application) ，通常就是將整個業務應用劃分為：表現層(UI)、業務邏輯層(BLL)、數據訪問層(DAL)。

表現層(UI)，通俗講就是展現給用戶的界面，對應項目中的Web層包含Servlet和Controller等。

業務邏輯層(BLL)：也稱作領域層，負責系統業務邏輯的處理，對應項目中Service和ServiceImpl等。

數據訪問層(DAL)：該層所做事務直接操作數據庫，針對數據的增添、刪除、修改、更新、查找等，對應項目中的Dao。

在提出該分層架構的時代，多數系統往往較為簡單，本質上都是一個單體架構(Monolithic Architecture)的數據庫管理系統。這種分層架構已經是Client-Server架構的進化了，它有效地隔離了業務邏輯與數據訪問邏輯，使得這兩個不同關注點能夠相對自由和獨立地演化。

在開源技術框架中，表現層實現的代表作品是Struts1/2、Spring MVC，業務層實現的代表作品是Spring，持久層實現的代表作品是Hibernate和Mybatis。

MVC

MVC全名是Model View Controller，是模型(model)-視圖(view)-控制器(controller)的縮寫，一種軟件設計典范，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件里面，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。MVC被獨特的發展起來用于映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。

標準的MVC交互模型如下圖：

View：視圖，為用戶提供使用界面，與用戶直接進行交互。

Model：模型，承載數據，對用戶提交請求進行計算的模塊。分為兩類，一類稱為數據承載Bean，一類稱為業務處理Bean。數據承載Bean是指實體類，專門承載業務數據的，如Student、User等。而業務處理Bean則是指Service或Dao對象，專門用于處理用戶提交請求的。

Controller：控制器，用于將用戶請求轉發給相應的Model進行處理，并處理Model的計算結果向用戶提供響應。

從圖中可以看到，標準的MVC中模型能主動推數據給視圖進行更新(觀察者設計模式，在模型上注冊視圖，當模型更新時自動更新視圖)，但在Web開發中模型是無法主動推給視圖(無法主動更新用戶界面)，因為在Web開發是請求-響應模型。

Web MVC標準架構，如下圖所示：

在Web MVC模式下，模型無法主動推數據給視圖，如果用戶想要視圖更新，需要再發送一次請求(即請求-響應模型)。MVC用于將web(UI)層進行職責解耦。

三層架構和MVC的區別與聯系

MVC嚴格說是三層架構中的UI層，也就是說，MVC把三層架構中的UI層再度進行了分化，分成了控制器、視圖、實體三個部分，控制器完成頁面邏輯，通過實體來與界面層完成通話，而C層直接與三層中的BLL進行對話。

三層架構和MVC可以共存。三層架構是基于業務邏輯來分的，而MVC是基于頁面來分的。MVC是表現模式(Presentation Pattern)，三層架構是典型的架構模式(Architecture Pattern)。

三層架構的分層模式是典型的上下關系，上層依賴于下層。但MVC作為表現模式是不存在上下關系的，而是相互協作關系。即使將MVC當作架構模式，也不是分層模式。MVC和三層架構基本沒有可比性，是應用于不同領域的技術。

阿里四層架構

三層架構實現比較簡單，很多朋友可能覺得項目分層就應該如此，結果就是往往會出現一大堆的業務邏輯都堆砌在Service層中。而在《阿里巴巴 Java 開發手冊 》中將原來的三層架構進一步細化，添加了Manager通用業務處理層。

Manager層可以將原Service層的一些通用能力進行下沉，比如與緩存和存儲交互策略，中間件的接入;還可以封裝對第三方接口的調用，比如調用支付服務，調用審核服務等RPC接口。

通用業務處理層，它有如下特征：

• 對第三方平臺封裝的層，預處理返回結果及轉化異常信息。
• 對Service層通用能力的下沉，如緩存方案、中間件通用處理。
• 與DAO層交互，對多個DAO的組合復用。

其各層的作用如下：

• 終端顯示層：各端模板渲染并執行顯示的層。當前主要是Velocity渲染，JS渲染， JSP渲染，移動端展示等。
• 開放接口層：將Service層方法封裝成開放接口，同時進行網關安全控制和流量控制等。
• Web層：主要是對訪問控制進行轉發，各類基本參數校驗，或者不復用的業務簡單處理等。
• Service層：業務邏輯層。
• Manager層：通用業務處理層。
• DAO層：數據訪問層，與底層 MySQL、Oracle、HBase 等進行數據交互。
• 外部接口或第三方平臺：包括其它部門RPC開放接口，基礎平臺，其它公司的HTTP接口。

系統工程結構

在學習了以上分層架構之后，下面來看一下針對分層在軟件系統中的對照關系表：

以上分層定義僅供參考。在上表中還多出了對外接口層和接入層。

對外接口層：所有對外的接口放在這層，不能包含任何業務邏輯，只數據對象的轉換和異常的封裝。

接入層：所有外部系統的依賴放在這層，好處是一旦外部系統接口修改，只需要在一處修改即可。

DDD分層架構

DDD是一種處理高度復雜領域的設計思想，試圖分離技術實現的復雜性，同時圍繞業務概念構建領域模型，提出的一種軟件架構設計的方法論。

DDD分層架構將數據、緩存等都視為基礎層， 可以被所有層調用;抽離了領域層，負責核心業務邏輯處理，領域層調用外部依賴全部通過接口，以保證領域層的100%單測覆蓋率;應用層聚合多個領域層的能力，只做功能的組合、轉發，不負責具體業務邏輯。

我們這里只做DDD分層架構的簡單介紹，關于DDD概念不做過多拓展，相關架構模式可專門進行學習一下。看一下DDD分層的架構圖：

其中對應層的功能介紹如下：

接口層(Interfaces)：該層包含與其他系統交互的所有內容，如Web服務器、RESTful接口。接口層處理傳入數據的解釋、校驗、編解碼、序列化操作，同時可以考慮引入專門的DTO(數據轉換對象)來協助數據轉換;

應用層(Application)：該層負責驅動應用程序完成工作流程。很薄一層，協調多個領域對象(實體、聚合根、領域服務)實現服務編排和組合完成工作流，該層通常不應該包含具體業務邏輯。該層涉及：其他微服務RPC調用、微服務編排和組合、分布式事務實現、消息驅動事件的驅動、日志記錄等。

領域層(Domain)：該層是軟件的核心，包含業務邏輯具體實現，包含實體、值對象、聚合、領域服務、倉儲接口等領域對象內容，通常該層應該配備圖示告知軟件是如何工作的;

基礎層(Infrastructure)：包含網關、緩存、數據庫存儲、消息中間件、監控、應用程序服務等通用的技術和基礎服務。基礎層以不同方式支持到其他三層，促進各層間通信。配置文件、數據庫Schema模式定義以及倉儲接口實現都是基礎結構的一部分;

DDD分層架構傳統三層架構的比較

DDD四層架構也基于傳統三層架構的，看一下它們之間的對照關系：

DDD四層架構和傳統三層架構有以下區別：

• 關注點不一樣：三層架構關注請求調用順序;DDD架構關注領域服務。
• 橫向劃分方式不一樣：三層架構主要關注縱向劃分，對橫向劃分沒有約定;DDD架構更關注縱向，即：多個領域層之間劃分及交互方式。
• 對資源的定位不一樣：三層架構把所有依賴的數據都放到數據訪問層;DDD架構只將領域強關聯的數據放到Repository中，其他比如API層緩存、文件等都當成基礎服務來處理。

關于DDD架構分層還有整潔架構和六邊形架構兩種形式，這里就不再拓展，感興趣的朋友可自行查找相關資料進行學習。

小結

本篇文章為大家講解了市面上常見的架構分層。分層架構的目的是通過關注點分離來降低系統的復雜度，同時滿足單一職責、高內聚、低耦合、提高可復用性和降低維護成本。但分層架構同樣也有一定的缺點，比如開發成本高、性能略低、可擴展性低等問題。實踐中，可根據需要選擇合適的分層架構。