Tomcat源代碼學習(二)----設計模式

Tomcat中的pipeline機制:(責任鏈模式)

      責任鏈模式是一種對象的行爲模式。在責任鏈模式裏,很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞,直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪一個對象最終處理這個請求,這使得系統可以在不影響客戶端的情況下動態地重新組織和分配責任。所以責任鏈模式將請求的發送者和請求的處理者解耦了。

      由圖1可知,tomcat先建立好連接再與容器Catalina進行交互。tomcat利用Coyote封裝了底層的網絡通訊,爲Catalina容器提供統一的接口,使得Catalina容器和具體的請求協議及I/O方式解耦。

在這裏插入圖片描述

圖1 Coyote內部結構

      通過上圖可以得知,connector與container的連接是通過內部的Adapter。具體的請求流和響應流在代碼實現中便是通過CoyoteAdapter進入Containter的。

在這裏插入圖片描述

圖2 入口的具體源碼

      在tomcat的pipeline機制中使用了責任鏈模式,其中,Container 扮演抽象處理者角色,具體處理者由 StandardEngine 等子容器扮演。與標準的責任鏈不同的是,這裏引入了 Pipeline 和 Valve 接口。

      Pipeline 和 Valve 是擴展了這個鏈的功能,使得在責任鏈在往下傳遞過程中,能夠接受外界的干預。在Catalina中,有4種容器(Engine、Host、Context、Wrapper),每個容器都有自己的Pipeline組件,每個Pipeline組件上至少會設定一個Valve(閥門),這個Valve我們稱之爲BaseValve(基礎閥)。基礎閥的作用是連接當前容器的下一個容器,可以說基礎閥是兩個容器之間的橋樑。

      請求request和響應response在Tomcat的容器中的傳遞,如下圖:

在這裏插入圖片描述

圖3 request和response在容器內的傳遞

      以四大組件中的Engine爲例,對tomcat中管道機制進行分析。

1)使用默認的基本閥創建一個新的標準引擎組件:
      StandardEngine的構造方法調用pipeline主鍵創建基礎閥。

在這裏插入圖片描述

圖4 創建基礎閥

2)普通閥與基礎閥
      基礎閥的作用是指引流進入下一條管道,普通的閥只是指向同一條管道的下一個閥門。

在這裏插入圖片描述

圖5 基礎閥(Host爲Engine的下一層組件)

在這裏插入圖片描述

圖6 普通閥

      大體的過程就是:Connector將流request和response傳入catalina中,首先接觸的到的Engine層,流進入pipeline中,流經pipeline的各閥門,閥門對流進行相應的處理,然後傳遞給同一管道中的下一個閥門,直到傳至基礎閥,基礎閥再將其傳遞給下一層的管道。

在這裏插入圖片描述

圖7 責任鏈類圖(以Engine拓展爲例)

在這裏插入圖片描述

圖8 pipeline上的閥門

Request的外觀模式:

      外觀模式爲整個子系統提供一種高層次的簡單藉口。

      這種設計模式主要用在一個大的系統中有多個子系統組成時,這多個子系統肯定要涉及到相互通信,但是每個子系統又不能將自己的內部數據過多的暴露給其它系統,不然就沒有必要劃分子系統了。每個子系統都會設計一個門面,把別的系統感興趣的數據封裝起來,通過這個門面來進行訪問。這就是門面設計模式存在的意義。

在這裏插入圖片描述

圖9 外觀模式

      RequestFacade內部包含 Request 對象,對於Request對象的訪問通過RequestFacade進行。tomcat中使用外觀模式主要是爲了保證主要類的安全,防止程序員使用核心類的暴露功能。

觀察者模式:

      觀察者模式常用的設計方法叫發佈-訂閱模式,也就是事件監聽機制,通常在某個事件發生的前後會觸發一些操作。定義對象間的一種一對多的依賴關係,當一個對象的狀態發生改變時,所有依賴於它的對象都得到通知並被自動更新。主要解決一個對象狀態改變給其他對象通知的問題,而且要考慮到易用和低耦合,保證高度的協作。

Tomcat中需要對很多組件進行生命週期管理,爲此Tomcat抽象了統一的生命週期管理骨架,通過這個骨架將所有需要進行生命週期管理的類都納入進來管理。其類圖如下:

在這裏插入圖片描述

圖10 觀察者模式類圖

在這裏插入圖片描述

圖11 具體的觀察者

在這裏插入圖片描述

圖12 時序圖

單例模式:(異常消息的管理)

      單例模式是對象的創建模式,確保一個類只有一個實例,而且自行實例化並向整個系統提供這個實例。

      tomcat中有一套完善的異常信息管理機制,在每個需要異常管理的工程包下都有相應的 properties 文件,文件中主要定義了各自pacakage下的類的各種異常信息,極大的方便了對異常信息的維護,而且利用java的ResourceBundle類,可以方便的實現國際化。然而,tomcat的核心包就有幾百個類,如果將這些類要用到的異常消息存入一個properties文件,在維護上會十分困難。

      Tomcat的做法是一個包共用一個properties文件。當包中的某個類需要用到異常消息時,可以先實例化StringManager,然後調用getString(String key)方法。如果每個類都實例化一個StringManager對象,而這些對象所包含的異常消息都是相同的,同樣也會帶來資源上的浪費。若每個包中的類,都共用一個StringManager對象,則會大大的提高效率。因此,to-mcat使用了單例模式對其進行管理。

在這裏插入圖片描述

圖13 以SingleSingnon調用StringManger爲例

在這裏插入圖片描述

圖14 StringManger類圖

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章