HTTP服務(wù)的七層架構(gòu)技術(shù)解析及運用

時間：2022-05-24 23:48:01 | 來源：網(wǎng)絡(luò)營銷

時間：2022-05-24 23:48:01 來源：網(wǎng)絡(luò)營銷

一般來說，計算機領(lǐng)域的體系結(jié)構(gòu)普遍采用了分層的方式，從整體結(jié)構(gòu)來看：

從最底層的硬件往高層依次有：

操作系統(tǒng) -> 驅(qū)動程序 -> 運行庫 -> 系統(tǒng)程序 -> 應(yīng)用程序等等。

從網(wǎng)絡(luò)分層模型OSI來講，由上至下為：

應(yīng)用層 -> 表示層 -> 會話層 -> 傳輸層 -> 網(wǎng)絡(luò)層 -> 數(shù)據(jù)鏈路層 -> 物理層

當然實際應(yīng)用的TCP/IP協(xié)議的分層就沒OSI標準這么復(fù)雜。

從C語言文件編寫到生成可執(zhí)行文件的過程來看：

預(yù)處理(展開后的C語言代碼) -> 編譯成匯編語言(特定CPU體系結(jié)構(gòu)的匯編語言源文件) -> 匯編器生成目標文件(CPU可執(zhí)行的二進制指令機器碼) -> 鏈接器連接目標文件生成可執(zhí)行文件(操作系統(tǒng)可以加載執(zhí)行的二進制文件)

雖說這不算是軟件的分層結(jié)構(gòu)，但是可以理解為一種通過分層來簡化復(fù)雜問題的思想，那么，PHP語言可以認為是建立在C語言之上的層——其解釋器Zend引擎是用C語言實現(xiàn)，畢竟用PHP這樣的腳本語言編寫動態(tài)網(wǎng)頁要比用C語言方便得多。

當然還有我們最熟悉的MVC分層技術(shù)了，對于分層的好處，想必大家都已經(jīng)比較熟悉了，這是一種“分而治之 大而化小”的思想。

說到分層就不得不提模塊了，其實分層和模塊是從兩種維度來進行“分而治之”的方式，模塊是從橫向維度來將一個整體分割成若干個獨立的部分，每個部分行使獨立自己的職責，當然它們之間也可能有依賴關(guān)系，這通過其對外提供的服務(wù)來實現(xiàn)。

如果將整個系統(tǒng)比做中國版圖的話，那么模塊方式將中國分為省，自治區(qū)等。分層則是從縱向緯度將一個整體從高至低劃分為若干個獨立的層，一個完整的服務(wù)由底層至上層，層層傳遞最終產(chǎn)出。

分層和模塊可以同時運用，例如中國用模塊方式分為省之后，然后每個省的行政機構(gòu)利用分層方式來行使職責，從低到高有戶，村，鄉(xiāng)，區(qū)，市，省等等，每一層都向上一層匯報。

分層和模塊會提高系統(tǒng)復(fù)雜度并影響效率（戶不能直接向省匯報，而需要一級一級向上匯報），但是這樣有利系統(tǒng)的擴展和維護，每一層只需要關(guān)注自己提供的服務(wù)接口以及它下一層所提供的服務(wù)接口，試想一下如果省需要接受來自市，區(qū)，鄉(xiāng)，村等所有下級層的匯報，那些省干部會很頭疼的。

一、HTTP服務(wù)傳統(tǒng)的三層架構(gòu)MVC

HTTP服務(wù)中最經(jīng)典的分層架構(gòu)非MVC莫屬了，幾乎任何一個PHP開發(fā)框架都是支持MVC分層模式，此模式歷史也比較悠久，是在上個世紀八十年代為編程語言Smalltalk設(shè)計的軟件模式，至今已經(jīng)被廣泛引用，如下圖所示：

本文主要講的是HTTP服務(wù)七層架構(gòu)技術(shù)，比MVC多出了四層，這樣復(fù)雜的分層是否有必要呢？

關(guān)于這個問題仁者見仁智者見智，億企邦認為MVC分層粒度不夠精細，當然你也可以繼續(xù)堅持傳統(tǒng)的三層，那么后文你也沒必要看下去了。

那么為什么MVC分層不夠精細呢，在我曾經(jīng)使用開源框架的MVC模式的經(jīng)驗中發(fā)現(xiàn)，V和C層功能職責一般都很清晰穩(wěn)定，但是M層卻常常顯得臃腫笨拙。

C層主要是負責整體流程控制，一般規(guī)范的架構(gòu)中，流程都可以用一張或幾張流程圖畫出，那么表明流程一般都是固定的。

V層主要是負責頁面呈現(xiàn)，可能使用smarty模板引擎，也可能是自帶的模板引擎，顯示的頁面可能是HTML，XML或則JSON，這些種類再多也都是可以度量的，所以M層也可以說是固定的。

而M層卻關(guān)系到系統(tǒng)的業(yè)務(wù)邏輯，隨著系統(tǒng)不斷迭代更新，M層中的內(nèi)容也會不斷演變，而這一層中也有很多復(fù)雜的處理，如文件讀取，數(shù)據(jù)庫查詢，緩存策略，邏輯運算，數(shù)據(jù)加工，數(shù)據(jù)打包等等。

所以MVC三層模型中，M層是還能再做細分的，當M層有一個更精細合理的分層方式之后，我們的業(yè)務(wù)邏輯演變過程會更加的得心應(yīng)手。

二、HTTP服務(wù)七層架構(gòu)

由上面的介紹，那么我們對MVC中的M層再進行分層規(guī)劃，億企邦這里給出的是一種對M層分五層的方式，讀者如果覺得五層太多或則太少那么可以參考這個再進行規(guī)劃。

原來的M層被分為：

A層：Application 應(yīng)用層

B層：Business 業(yè)務(wù)層

C層：Component 組件層

D層：Datadriver 數(shù)據(jù)驅(qū)動層

S層：Systemdriver 系統(tǒng)驅(qū)動層

那么整個七層架構(gòu)則為：

1、Controller

2、View

3、Application

4、Business

5、Component

6、Datadriver

7、Systemdriver

結(jié)構(gòu)圖還是參考經(jīng)典MVC，將其中M層換成新的五層即可。

下面億企邦就依次給大家介紹一下這幾個新的層：

1、Application

應(yīng)用層在最上面，其針對實際中的單個頁面或則單個接口，Controller通過HTTP請求地址中的參數(shù)找到對應(yīng)的Application，然后執(zhí)行中指定的公共方法，比如main()，然后應(yīng)用就開始啟動。

應(yīng)用層的職責包括接受HTTP參數(shù)（一般是間接接受，比如從request對象中獲?。{(diào)用Business層的特定業(yè)務(wù)，保存業(yè)務(wù)執(zhí)行結(jié)果，這些結(jié)果最終會由View顯示出來，當然是通過Controller協(xié)調(diào)。應(yīng)用層是M層分解成五層之后最高的層，Controller會與此層直接通信。

2、Business

業(yè)務(wù)層在應(yīng)用層之下，通常一個應(yīng)用實例對應(yīng)一個業(yè)務(wù)實例，而一個業(yè)務(wù)有可能為多個應(yīng)用服務(wù)，業(yè)務(wù)是一個執(zhí)行流，它通過執(zhí)行一系列的操作來完成應(yīng)用的需求。

這些操作來自下層的組件層Component,可能一個業(yè)務(wù)需要一個或則多個組件來完成一個完整的需求。因為一個業(yè)務(wù)實例通常只對應(yīng)一個功能，所以只有一個固定的方法會被上層的應(yīng)用調(diào)用，比如flow()。業(yè)務(wù)層的職責是幫應(yīng)用層執(zhí)行業(yè)務(wù)流并且有必要的時候返回數(shù)據(jù)給應(yīng)用層，它會調(diào)用下層Component的方法。

3、Component

從組件層開始和上面兩層有一個本質(zhì)的區(qū)別，組件層開始有了類庫的概念。前面兩層的實例通常只暴露一個特殊約定的公共的方法讓上層調(diào)用，從這一層開始一個實例會提供多個方法給上層。

組件層通常和系統(tǒng)中一個角色對應(yīng)，例如在博客系統(tǒng)中，博文是一個角色，用戶是一個角色，那么就會有博文組件BlogComponent，用戶組件UserComponent，每個角色都有對應(yīng)的操作，例如博文和用戶都可以添加刪除修改。

需要注意組件層中不應(yīng)該有任何數(shù)據(jù)讀取的操作，數(shù)據(jù)讀取是下層數(shù)據(jù)驅(qū)動層來做的。如果組件層從下層獲取了數(shù)據(jù)，那么它的一個職責就是對數(shù)據(jù)進行加工。

例如BlogComponent有一個方法是獲取一個博文getBlog($id)，那么getBlog()方法中，從數(shù)據(jù)驅(qū)動層中取得了對應(yīng)id的博文數(shù)據(jù)之后，需要對博文數(shù)據(jù)進行一定的處理，比如將博文中的HTML特殊標簽過濾等等。

組件層不關(guān)心數(shù)據(jù)的讀取方式，但是會關(guān)心數(shù)據(jù)的結(jié)果，比如數(shù)據(jù)不存在或則數(shù)據(jù)已經(jīng)過期。

4、Datadriver

數(shù)據(jù)驅(qū)動層的職責是為組件層提供源數(shù)據(jù)，此層關(guān)心數(shù)據(jù)的存取介質(zhì)，存取方式等等，數(shù)據(jù)可能被存儲在DB，MC，F(xiàn)ilesystem或則遠程的HTTP服務(wù)器上。

數(shù)據(jù)驅(qū)動層不關(guān)心數(shù)據(jù)的內(nèi)容，只關(guān)心數(shù)據(jù)讀取的操作結(jié)果，例如假設(shè)數(shù)據(jù)存在DB中，但是數(shù)據(jù)驅(qū)動層在執(zhí)行數(shù)據(jù)庫查詢的時候出錯了，那么需要在此層處理。

假設(shè)數(shù)據(jù)存儲在遠程的HTTP服務(wù)器上，那么數(shù)據(jù)驅(qū)動層需要關(guān)心HTTP返回碼是否為正確的200系列或則錯誤的400，500系列，哪怕HTTP請求返回了錯誤的數(shù)據(jù)實體，但是返回碼為200，那么數(shù)據(jù)驅(qū)動層也不關(guān)心，這種情況需要上層組件層來處理。

5、Systemdriver

系統(tǒng)驅(qū)動層是系統(tǒng)環(huán)境提供的數(shù)據(jù)訪問實例，例如數(shù)據(jù)庫服務(wù)的Systemdriver可能是一個db handler，HTTP服務(wù)的Systemdriver可能是一個http handler，文件存儲系統(tǒng)驅(qū)動層可能是一個file handler, 系統(tǒng)驅(qū)動層相對簡單，這層可以和數(shù)據(jù)驅(qū)動層進行合并，其職責也較少。僅僅只是執(zhí)行數(shù)據(jù)驅(qū)動層的數(shù)據(jù)訪問指令。

通常情況下這五個層中，上層的實例數(shù)量比下層的實例數(shù)量要多，整體類似一個倒置的梯形，如下圖所示：

在上圖中一共有6個Application，5個Business，4個Component，3個Datadriver，2個Systemdriver。

每個Application都由一個Business為其服務(wù)。

每個Business都服務(wù)一個或則多個Application（B5同時服務(wù)A5 A6），都有一個或則多個Componet為其服務(wù)。

每個Component為一個或則多個Business服務(wù)，都有一個或則多個Datadriver為其服務(wù)。

每個Datadriver為一個或則多個Component服務(wù)，都有一個或則多個Systemdriver為其服務(wù)。

每個Systemdriver為一個或則多個Datadriver服務(wù)。

三、HTTP服務(wù)的七層架構(gòu)運用

現(xiàn)在運用這樣的架構(gòu)來設(shè)計一個簡單的博客系統(tǒng)，服務(wù)端用PHP語言實現(xiàn)，當然，架構(gòu)是思想，不區(qū)分語言。

整個系統(tǒng)包含以下功能：

1、發(fā)布博文

2、修改博文

3、刪除博文

4、評論博文

5、修改用戶信息

要求每個功能都記錄操作日志。

設(shè)計的數(shù)據(jù)存儲包括：

1、博文數(shù)據(jù)表

2、用戶數(shù)據(jù)表

3、評論數(shù)據(jù)表

4、日志（存文件系統(tǒng)）

在表結(jié)構(gòu)設(shè)計的時候我們加入了一些冗余字段信息，例如在博文表中有評論數(shù)量字段comment_nums, 博文每被評論一次其值加1，每刪除一個評論其值減1。

用戶數(shù)據(jù)表中我們添加了用戶發(fā)布的博文數(shù)量字段blog_nums，用戶每發(fā)布一篇博文其值加1，每刪除一篇博文其值減1。

下面設(shè)計分層：

應(yīng)用層，一共有5個應(yīng)用：

1、PostBlogApplication 發(fā)布博文

2、UpdateBlogApplication 修改博文

3、DeleteBlogApplication 刪除博文

4、CommentBlogApplication 評論博文

5、UpdateUserApplication 修改用戶信息

業(yè)務(wù)層，這5個應(yīng)用分別有5個業(yè)務(wù)對其服務(wù)：

1、PostBlogBusiness 博文發(fā)布業(yè)務(wù)

2、UpdateBlogBusiness 博文修改業(yè)務(wù)

3、DeleteBlogBusiness 博文刪除業(yè)務(wù)

4、CommentBlogBusiness 博文評論業(yè)務(wù)

5、UpdateUserBusiness 用戶修改業(yè)務(wù)

組件層，系統(tǒng)一共有4個角色對應(yīng)4個組件：

1、BlogComponent 博文組件

提供方法包括：

（1）、postBlog() 發(fā)布博文

（2）、deleteBlog()刪除博文

（3）、updateBlog()修改博文

（4）、getBlog()獲取博文內(nèi)容

2、CommentComponent 評論組件

提供方法包括：

（1）、postComment() 發(fā)布評論

（2）、deleteComment() 刪除評論

3、UserComponent 用戶組件

提供方法包括：

updateUser() 修改用戶信息

4、LogComponent 日志組件

提供方法包括：

logMsg() 記錄日志信息

數(shù)據(jù)驅(qū)動層和4個組件對應(yīng)

1、BlogDatadriver DB類型 提供blog的select insert delete update

2、CommentDatadriver DB類型 提供comment的select insert delete update

3、UserDatadriver DB類型 提供user的select insert delete update

4、LogDatadriver FS類型 提供file的read write

系統(tǒng)驅(qū)動層: DB類型和FS類型

1、MySqlSystemdriver DB的handler

2、FileSystemdriver FS的handler

現(xiàn)在以發(fā)布博文操作來介紹流程，假設(shè)接口地址為: http://www.mahaixiang.cn/postBlog：

1、Controller通過重寫規(guī)則發(fā)現(xiàn)其對應(yīng)的Application為PostBlogApplication，于是PostBlogApplication被實例化，并且其中的特殊方法main()會被自動調(diào)用。

2、postBlogApplication需要PostBlogBusiness業(yè)務(wù)來完成博文發(fā)布操作，PostBlogBusiness被實例化，并且其中的特殊方法flow()會被調(diào)用。

3、根據(jù)需求，發(fā)布博文的時候需要在博文表中插入一條博文，然后修改用戶信息中的博文數(shù)量字段。

那么postBlogBusiness業(yè)務(wù)流就包括兩個操作，這兩個操作分別由BlogComponent中的postBlog()方法和UserComponent中的updateUser()方法來實現(xiàn)，其中前者往博文表中插入博文信息，后者將用戶信息中的博文數(shù)量字段加1。

由于系統(tǒng)要求任何操作都需要記錄日志，因此還有第三個操作就是記錄日志，通過BlogComponent的logMsg()方法實現(xiàn)，那么PostBlogBusiness業(yè)務(wù)流一共包括了三個操作，分別由三個組件來完成。

4、下面就需要分別考慮上面三個組件的下層調(diào)用了

其中BlogComponet的postBlog()調(diào)用BlogDatadriver的insert相關(guān)方法來插入博文數(shù)據(jù)，BlogDatadriver是DB類型，因此通過MySqlSystemdriver 來實現(xiàn)。

UserComponent的updateUser()調(diào)用UserDatadriver的update相關(guān)方法來實現(xiàn)博文數(shù)量更新，UserDatadriver也是DB類型，因此也通過MySqlSystemdriver 來實現(xiàn)。

LogComponent的logMsg()調(diào)用LogDatadriver的write相關(guān)方法，LogDatadriver是FS類型，因此通過FileSystemdriver 來實現(xiàn)。

5、三個組件的操作都執(zhí)行成功后，PostBlogBusiness告訴postBlogApplication博文發(fā)布成功，然后postBlogApplication通過Controller來調(diào)用View相關(guān)的方法顯示執(zhí)行結(jié)果。

對于其他幾個操作流程，大家可以舉一反三，這里億企邦就不再多介紹了。

分層帶來的益處：

現(xiàn)在我們通過幾個系統(tǒng)功能的演變用例來看看這個分層帶來的益處：

用例1：為了方便對日志的管理，現(xiàn)在希望能夠?qū)⑷罩敬鎯υ贒B中而不是FS中。

解決方法：這是對數(shù)據(jù)存儲的改造，我們知道應(yīng)該從數(shù)據(jù)驅(qū)動層入手。日志功能是由日志組件LogComponent實現(xiàn)的，其中LogComponet的了logMsg()方法調(diào)用LogDatadriver來存日志。我們將LogDatadriver由FS類型改造成DB類型，接口方法保持不變，這樣很快就完成了改造。

用例2：新增需求-用戶A可以將一篇博文轉(zhuǎn)移給另外一個用戶B。

解決方法：

步驟1：首先這個新需求對應(yīng)了一個新的應(yīng)用，于是我們新增了一個SendBlogApplication。

步驟2：需要有一個業(yè)務(wù)完成操作，新增業(yè)務(wù)為SendBlogBusiness。

步驟3：考慮轉(zhuǎn)移一篇博文涉及到的操作：①、將博文表中對應(yīng)的用戶ID字段由A的ID切換到B的ID；②、A用戶的博文數(shù)量減1；③、B用戶的博文數(shù)量加1。

這三個操作需要兩個組件來完成，這兩個組件我們系統(tǒng)中已經(jīng)有了，BlogComponent的updateBlog ()完成操作1，UserComponent的updateUser()完成操作2，3。

從用例2可以看出，當新增了這么一個需求的時候，我們在應(yīng)用層和業(yè)務(wù)層添加了實例，組件層以下都不變，這是因為現(xiàn)在的組件層已經(jīng)能夠滿足新的業(yè)務(wù)的需求，當我們現(xiàn)有組件無法滿足新的一業(yè)務(wù)需求的時候，我們則需要對組件層做修改。

通過這兩個簡單的用例我們發(fā)現(xiàn)我們對系統(tǒng)的修改要么可以很明確的確定在哪些層，要么就是從上層組件往下層進行，操作起來很方便。

億企邦點評：

這種縱向的分層和橫向的模塊結(jié)合起來，能讓整個系統(tǒng)的結(jié)構(gòu)清晰流暢，在本人設(shè)計的一款框架里面，原生的支持這樣的分層架構(gòu)和模塊，使用者只需要按照同一個模式簡單的操作，層之間的接口和協(xié)議已經(jīng)由框架本身約定好，框架還不夠完善，自己內(nèi)部用用可以，暫時不發(fā)布了。