建站
咨詢
售后
建站咨詢
新聞中心
[[406066]]
前言
只要從事軟件開發(fā)的工作，系統(tǒng)架構(gòu)是必備知識。有朋友說可能會說，我只是一個搬磚的，怎么會接觸到架構(gòu)知識呢?其實，除了架構(gòu)的設計者(也就是架構(gòu)師)，作為普通的開發(fā)者也是在時刻踐行著系統(tǒng)架構(gòu)的理論。畢竟，再好的架構(gòu)，都需要碼農(nóng)去實施。只不過當你沒有系統(tǒng)了解軟件架構(gòu)時，可能感知不到而已。
池州網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)公司！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、響應式網(wǎng)站開發(fā)等網(wǎng)站項目制作，到程序開發(fā)，運營維護。成都創(chuàng)新互聯(lián)公司成立于2013年到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選成都創(chuàng)新互聯(lián)公司。
本篇文章就帶大家系統(tǒng)的了解一下軟件架構(gòu)的分層，學習完畢，你就會明白，為什么系統(tǒng)要分層。同時，也能準確的看清楚目前自己系統(tǒng)中采用的是什么樣的分層架構(gòu)。
不采用架構(gòu)分層，行不行?
首先我們來思考一個問題，如果一個系統(tǒng)不采用分層架構(gòu)可不可以?這個問題就好像在問，代碼中不使用設計模式行不行?答案當然是可以的。但不采用架構(gòu)分層，會帶來極大的未知風險，或者說代碼極具熵增的特性。
作為一個初創(chuàng)軟件，可能沒有什么業(yè)務邏輯，沒有什么用戶量，而軟件最主要的目標就是快速上線，實踐商業(yè)模式。此時，可以不考慮分層。但隨著業(yè)務邏輯的復雜，業(yè)務板塊的增多，彼此之間就會出現(xiàn)錯綜復雜的依賴關系，隨之就會產(chǎn)生的邏輯不清晰、可讀性差，維護困難，改動一處動全身等問題。
什么是架構(gòu)分層?
分層架構(gòu)是將軟件模塊按照水平切分的方式分成多個層，一個系統(tǒng)由多層組成，每層由多個模塊組成。同時，每層有自己獨立的職責，多個層次協(xié)同提供完整的功能。比如，我們經(jīng)常提到的MVC架構(gòu)，就是一種非常典型非?；A的分層方式。
分層設計的本質(zhì)其實就是將復雜問題簡單化，基于單一職責原則讓每層代碼各司其職，基于“高內(nèi)聚，低耦合”的設計思想實現(xiàn)相關層對象之間的交互。從而，提升代碼的可維護性和可擴展性。
系統(tǒng)架構(gòu)分層之后，往往需要達到以下目標：
- 高內(nèi)聚：分層設計可以簡化系統(tǒng)設計，讓不同層專注做某一模塊的事;
- 低耦合：層與層之間通過接口或API來交互，依賴方不用知道被依賴方的細節(jié);
- 復用：分層之后可以做到代碼或功能的復用;
- 擴展性：分層架構(gòu)可以讓代碼更容易橫向擴展
通訊領域的OSI參考模型
在計算機領域現(xiàn)有最典型的分層架構(gòu)設計就是OSI參考模型和TCP/IP參考模型了。關于這個模型，我們在《一篇文章，只用看三遍，終生不忘網(wǎng)絡分層! 》一文中已經(jīng)詳細介紹了。下面直接看一下相關的模型圖：
對于上述的三種分層模式，試想一下，如果沒有分層，當一個業(yè)務或協(xié)議需要改變時，我們只能針對整個系統(tǒng)做修改或擴展。而分層之后，便可以很方便的把不同功能的模塊抽離出來，修改對應的模塊即可。而且不同層還可以被復用，只要確保按照這個層的協(xié)議來處理就可以了。
軟件系統(tǒng)整體分層
以Java軟件應用為例，整個軟件系統(tǒng)也可進行分層，比如分為部署的硬件環(huán)境、操作系統(tǒng)、所需的中間件、承載業(yè)務的應用程序以及軟件接入層?？赏ㄟ^下圖進行整體了解：
對于上述分層也產(chǎn)生了對應在職位，比如運維工程師、中間件工程師、產(chǎn)品經(jīng)理、開發(fā)工程師、測試工程師等工種。而我們在實踐過程中，接觸最多，使用最多的分層要屬應用軟件層了，其次是中間件層。
下面我們就來看看針對應用軟件層通常有哪些分層方式。
經(jīng)典三層架構(gòu)
三層架構(gòu)(3-tier application) ，通常就是將整個業(yè)務應用劃分為：表現(xiàn)層(UI)、業(yè)務邏輯層(BLL)、數(shù)據(jù)訪問層(DAL)。
表現(xiàn)層(UI)，通俗講就是展現(xiàn)給用戶的界面，對應項目中的Web層包含Servlet和Controller等。
業(yè)務邏輯層(BLL)：也稱作領域?qū)樱撠熛到y(tǒng)業(yè)務邏輯的處理，對應項目中Service和ServiceImpl等。
數(shù)據(jù)訪問層(DAL)：該層所做事務直接操作數(shù)據(jù)庫，針對數(shù)據(jù)的增添、刪除、修改、更新、查找等，對應項目中的Dao。
在提出該分層架構(gòu)的時代，多數(shù)系統(tǒng)往往較為簡單，本質(zhì)上都是一個單體架構(gòu)(Monolithic Architecture)的數(shù)據(jù)庫管理系統(tǒng)。這種分層架構(gòu)已經(jīng)是Client-Server架構(gòu)的進化了，它有效地隔離了業(yè)務邏輯與數(shù)據(jù)訪問邏輯，使得這兩個不同關注點能夠相對自由和獨立地演化。
在開源技術框架中，表現(xiàn)層實現(xiàn)的代表作品是Struts1/2、Spring MVC，業(yè)務層實現(xiàn)的代表作品是Spring，持久層實現(xiàn)的代表作品是Hibernate和Mybatis。
MVC
MVC全名是Model View Controller，是模型(model)-視圖(view)-控制器(controller)的縮寫，一種軟件設計典范，用一種業(yè)務邏輯、數(shù)據(jù)、界面顯示分離的方法組織代碼，將業(yè)務邏輯聚集到一個部件里面，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業(yè)務邏輯。MVC被獨特的發(fā)展起來用于映射傳統(tǒng)的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結(jié)構(gòu)中。
標準的MVC交互模型如下圖：
View：視圖，為用戶提供使用界面，與用戶直接進行交互。
Model：模型，承載數(shù)據(jù)，對用戶提交請求進行計算的模塊。分為兩類，一類稱為數(shù)據(jù)承載Bean，一類稱為業(yè)務處理Bean。數(shù)據(jù)承載Bean是指實體類，專門承載業(yè)務數(shù)據(jù)的，如Student、User等。而業(yè)務處理Bean則是指Service或Dao對象，專門用于處理用戶提交請求的。
Controller：控制器，用于將用戶請求轉(zhuǎn)發(fā)給相應的Model進行處理，并處理Model的計算結(jié)果向用戶提供響應。
從圖中可以看到，標準的MVC中模型能主動推數(shù)據(jù)給視圖進行更新(觀察者設計模式，在模型上注冊視圖，當模型更新時自動更新視圖)，但在Web開發(fā)中模型是無法主動推給視圖(無法主動更新用戶界面)，因為在Web開發(fā)是請求-響應模型。
Web MVC標準架構(gòu)，如下圖所示：
在Web MVC模式下，模型無法主動推數(shù)據(jù)給視圖，如果用戶想要視圖更新，需要再發(fā)送一次請求(即請求-響應模型)。MVC用于將web(UI)層進行職責解耦。
三層架構(gòu)和MVC的區(qū)別與聯(lián)系
MVC嚴格說是三層架構(gòu)中的UI層，也就是說，MVC把三層架構(gòu)中的UI層再度進行了分化，分成了控制器、視圖、實體三個部分，控制器完成頁面邏輯，通過實體來與界面層完成通話，而C層直接與三層中的BLL進行對話。
三層架構(gòu)和MVC可以共存。三層架構(gòu)是基于業(yè)務邏輯來分的，而MVC是基于頁面來分的。MVC是表現(xiàn)模式(Presentation Pattern)，三層架構(gòu)是典型的架構(gòu)模式(Architecture Pattern)。
三層架構(gòu)的分層模式是典型的上下關系，上層依賴于下層。但MVC作為表現(xiàn)模式是不存在上下關系的，而是相互協(xié)作關系。即使將MVC當作架構(gòu)模式，也不是分層模式。MVC和三層架構(gòu)基本沒有可比性，是應用于不同領域的技術。
阿里四層架構(gòu)
三層架構(gòu)實現(xiàn)比較簡單，很多朋友可能覺得項目分層就應該如此，結(jié)果就是往往會出現(xiàn)一大堆的業(yè)務邏輯都堆砌在Service層中。而在《阿里巴巴 Java 開發(fā)手冊 》中將原來的三層架構(gòu)進一步細化，添加了Manager通用業(yè)務處理層。
Manager層可以將原Service層的一些通用能力進行下沉，比如與緩存和存儲交互策略，中間件的接入;還可以封裝對第三方接口的調(diào)用，比如調(diào)用支付服務，調(diào)用審核服務等RPC接口。
通用業(yè)務處理層，它有如下特征：
- 對第三方平臺封裝的層，預處理返回結(jié)果及轉(zhuǎn)化異常信息。
- 對Service層通用能力的下沉，如緩存方案、中間件通用處理。
- 與DAO層交互，對多個DAO的組合復用。
其各層的作用如下：
- 終端顯示層：各端模板渲染并執(zhí)行顯示的層。當前主要是Velocity渲染，JS渲染， JSP渲染，移動端展示等。
- 開放接口層：將Service層方法封裝成開放接口，同時進行網(wǎng)關安全控制和流量控制等。
- Web層：主要是對訪問控制進行轉(zhuǎn)發(fā)，各類基本參數(shù)校驗，或者不復用的業(yè)務簡單處理等。
- Service層：業(yè)務邏輯層。
- Manager層：通用業(yè)務處理層。
- DAO層：數(shù)據(jù)訪問層，與底層 MySQL、Oracle、HBase 等進行數(shù)據(jù)交互。
- 外部接口或第三方平臺：包括其它部門RPC開放接口，基礎平臺，其它公司的HTTP接口。
系統(tǒng)工程結(jié)構(gòu)
在學習了以上分層架構(gòu)之后，下面來看一下針對分層在軟件系統(tǒng)中的對照關系表：
以上分層定義僅供參考。在上表中還多出了對外接口層和接入層。
對外接口層：所有對外的接口放在這層，不能包含任何業(yè)務邏輯，只數(shù)據(jù)對象的轉(zhuǎn)換和異常的封裝。
接入層：所有外部系統(tǒng)的依賴放在這層，好處是一旦外部系統(tǒng)接口修改，只需要在一處修改即可。
DDD分層架構(gòu)
DDD是一種處理高度復雜領域的設計思想，試圖分離技術實現(xiàn)的復雜性，同時圍繞業(yè)務概念構(gòu)建領域模型，提出的一種軟件架構(gòu)設計的方法論。
DDD分層架構(gòu)將數(shù)據(jù)、緩存等都視為基礎層， 可以被所有層調(diào)用;抽離了領域?qū)?，負責核心業(yè)務邏輯處理，領域?qū)诱{(diào)用外部依賴全部通過接口，以保證領域?qū)拥?00%單測覆蓋率;應用層聚合多個領域?qū)拥哪芰?，只做功能的組合、轉(zhuǎn)發(fā)，不負責具體業(yè)務邏輯。
我們這里只做DDD分層架構(gòu)的簡單介紹，關于DDD概念不做過多拓展，相關架構(gòu)模式可專門進行學習一下。看一下DDD分層的架構(gòu)圖：
其中對應層的功能介紹如下：
接口層(Interfaces)：該層包含與其他系統(tǒng)交互的所有內(nèi)容，如Web服務器、RESTful接口。接口層處理傳入數(shù)據(jù)的解釋、校驗、編解碼、序列化操作，同時可以考慮引入專門的DTO(數(shù)據(jù)轉(zhuǎn)換對象)來協(xié)助數(shù)據(jù)轉(zhuǎn)換;
應用層(Application)：該層負責驅(qū)動應用程序完成工作流程。很薄一層，協(xié)調(diào)多個領域?qū)ο?實體、聚合根、領域服務)實現(xiàn)服務編排和組合完成工作流，該層通常不應該包含具體業(yè)務邏輯。該層涉及：其他微服務RPC調(diào)用、微服務編排和組合、分布式事務實現(xiàn)、消息驅(qū)動事件的驅(qū)動、日志記錄等。
領域?qū)?Domain)：該層是軟件的核心，包含業(yè)務邏輯具體實現(xiàn)，包含實體、值對象、聚合、領域服務、倉儲接口等領域?qū)ο髢?nèi)容，通常該層應該配備圖示告知軟件是如何工作的;
基礎層(Infrastructure)：包含網(wǎng)關、緩存、數(shù)據(jù)庫存儲、消息中間件、監(jiān)控、應用程序服務等通用的技術和基礎服務?；A層以不同方式支持到其他三層，促進各層間通信。配置文件、數(shù)據(jù)庫Schema模式定義以及倉儲接口實現(xiàn)都是基礎結(jié)構(gòu)的一部分;
DDD分層架構(gòu)傳統(tǒng)三層架構(gòu)的比較
DDD四層架構(gòu)也基于傳統(tǒng)三層架構(gòu)的，看一下它們之間的對照關系：
DDD四層架構(gòu)和傳統(tǒng)三層架構(gòu)有以下區(qū)別：
- 關注點不一樣：三層架構(gòu)關注請求調(diào)用順序;DDD架構(gòu)關注領域服務。
- 橫向劃分方式不一樣：三層架構(gòu)主要關注縱向劃分，對橫向劃分沒有約定;DDD架構(gòu)更關注縱向，即：多個領域?qū)又g劃分及交互方式。
- 對資源的定位不一樣：三層架構(gòu)把所有依賴的數(shù)據(jù)都放到數(shù)據(jù)訪問層;DDD架構(gòu)只將領域強關聯(lián)的數(shù)據(jù)放到Repository中，其他比如API層緩存、文件等都當成基礎服務來處理。
關于DDD架構(gòu)分層還有整潔架構(gòu)和六邊形架構(gòu)兩種形式，這里就不再拓展，感興趣的朋友可自行查找相關資料進行學習。
小結(jié)
本篇文章為大家講解了市面上常見的架構(gòu)分層。分層架構(gòu)的目的是通過關注點分離來降低系統(tǒng)的復雜度，同時滿足單一職責、高內(nèi)聚、低耦合、提高可復用性和降低維護成本。但分層架構(gòu)同樣也有一定的缺點，比如開發(fā)成本高、性能略低、可擴展性低等問題。實踐中，可根據(jù)需要選擇合適的分層架構(gòu)。
標題名稱：軟件架構(gòu)分層，你的項目處于什么階段?
文章出自：http://fisionsoft.com.cn/article/cdpoecc.html
