Tomcat 系統架構與設計模式之系統架構
Tomcat 總體結構
Tomcat 的結構很複雜，但是 Tomcat 也非常的模組化，找到了 Tomcat 最核心的模組，您就抓住了 Tomcat 的“七寸”。下面是 Tomcat 的總體結構圖：
圖 1.Tomcat 的總體結構
從上圖中可以看出 Tomcat 的心臟是兩個元件：Connector 和 Container，關於這兩個元件將在後面詳細介紹。Connector 元件是可以被替換，這樣可以提供給伺服器設計者更多的選擇，因為這個元件是如此重要，不僅跟伺服器的設計的本身，而且和不同的應用場景也十分相關，所以一個 Container 可以選擇對應多個 Connector。多個 Connector 和一個 Container 就形成了一個 Service，Service 的概念大家都很熟悉了，有了 Service 就可以對外提供服務了，但是 Service 還要一個生存的環境，必須要有人能夠給她生命、掌握其生死大權，那就非 Server 莫屬了。所以整個 Tomcat 的生命週期由 Server 控制。
以 Service 作為“婚姻”
我們將 Tomcat 中 Connector、Container 作為一個整體比作一對情侶的話，Connector 主要負責對外交流，可以比作為 Boy，Container 主要處理 Connector 接受的請求，主要是處理內部事務，可以比作為 Girl。那麼這個 Service 就是連線這對男女的結婚證了。是 Service 將它們連線在一起，共同組成一個家庭。當然要組成一個家庭還要很多其它的元素。
說白了，Service 只是在 Connector 和 Container 外面多包一層，把它們組裝在一起，向外面提供服務，一個 Service 可以設定多個 Connector，但是隻能有一個 Container 容器。這個 Service 介面的方法列表如下：
圖 2. Service 介面
從 Service 介面中定義的方法中可以看出，它主要是為了關聯 Connector 和 Container，同時會初始化它下面的其它元件，注意介面中它並沒有規定一定要控制它下面的元件的生命週期。所有元件的生命週期在一個 Lifecycle 的介面中控制，這裡用到了一個重要的設計模式，關於這個介面將在後面介紹。
Tomcat 中 Service 介面的標準實現類是 StandardService 它不僅實現了 Service 藉口同時還實現了 Lifecycle 介面，這樣它就可以控制它下面的元件的生命週期了。StandardService 類結構圖如下：
圖 3. StandardService 的類結構圖
從上圖中可以看出除了 Service 介面的方法的實現以及控制組件生命週期的 Lifecycle 介面的實現，還有幾個方法是用於在事件監聽的方法的實現，不僅是這個 Service 元件，Tomcat 中其它元件也同樣有這幾個方法，這也是一個典型的設計模式，將在後面介紹。
下面看一下 StandardService 中主要的幾個方法實現的程式碼，下面是 setContainer 和 addConnector 方法的原始碼：
清單 1. StandardService. SetContainer
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
public
void setContainer(Container container) {
Container
oldContainer = this.container;
if
((oldContainer != null) && (oldContainer instanceof Engine))
((Engine)
oldContainer).setService(null);
this.container
= container;
if
((this.container != null) && (this.container instanceof Engine))
((Engine)
this.container).setService(this);
if
(started && (this.container != null) && (this.container instanceof Lifecycle)) {
try
{
((Lifecycle)
this.container).start();
}
catch (LifecycleException e) {
;
}
}
synchronized
(connectors) {
for
(int i = 0; i < connectors.length; i++)
connectors[i].setContainer(this.container);
}
if
(started && (oldContainer != null) && (oldContainer instanceof Lifecycle)) {
try
{
((Lifecycle)
oldContainer).stop();
}
catch (LifecycleException e) {
;
}
}
support.firePropertyChange("container",
oldContainer, this.container);
}
|
這段程式碼很簡單，其實就是先判斷當前的這個 Service 有沒有已經關聯了 Container，如果已經關聯了，那麼去掉這個關聯關係—— oldContainer.setService(null)。如果這個 oldContainer 已經被啟動了，結束它的生命週期。然後再替換新的關聯、再初始化並開始這個新的 Container 的生命週期。最後將這個過程通知感興趣的事件監聽程式。這裡值得注意的地方就是，修改 Container 時要將新的 Container 關聯到每個 Connector，還好 Container 和 Connector 沒有雙向關聯，不然這個關聯關係將會很難維護。
清單 2. StandardService. addConnector
1
2
3
4
5
6
7
相關推薦Tomcat 系統架構與設計模式之系統架構Tomcat 總體結構 Tomcat 的結構很複雜，但是 Tomcat 也非常的模組化，找到了 Tomcat 最核心的模組，您就抓住了 Tomcat 的“七寸”。下面是 Tomcat 的總體結構圖： 圖 1.Tomcat 的總體結構 從上圖中 《深入分析JavaWeb技術內幕》之 11-Tomcat系統架構與設計模式1、 分發請求 2 、同時請求 3、 多級容器 4、 設計模式 Tomcat的組織結構 https://www.cnblogs.com/zhouyuqin/p/5143121.html Tomcat Server處理一個HTTP請求的 第11章 Tomcat的系統架構與設計模式必須 ket 聲明 命令模式 基本 ner 虛擬主機 fec 啟動 11.1 Tomcat總體設計 11.1.1 Tomcat總體架構 Tomcat和核心有連個組件：Connector和Container,Connector是可以被替換的。一個container可以 Tomcat 系統架構與設計模式，第 1 部分: 工作原理本文以 Tomcat 5 為基礎，也兼顧最新的 Tomcat 6 和 Tomcat 4。Tomcat 的基本設計思路和架構是具有一定連續性的。 Tomcat 的結構很複雜，但是 Tomcat 也非常的模組化，找到了 Tomcat 最核心的模組，您就抓住了 Tomcat 的“七寸”。下面是 Tomcat 的 Tomcat 系統架構與設計模式，第 2 部分: 設計模式分析門面設計模式在 Tomcat 中有多處使用，在 Request 和 Response 物件封裝中、Standard Wrapper 到 ServletConfig 封裝中、ApplicationContext 到 ServletContext 封裝中等都用到了這種設計模式 Tomcat 系統架構與設計模式，第 1 部分: 工作原理圖 1.Tomcat 的總體結構public synchronized void start() throwsLifecycleException { ……… if( !initialized ) { try { init(); } catch( Exception ex ) 《深入分析JavaWeb技術內幕》之 12-Spring架構與設計模式core context bean（bean工廠，bean定義，bean解析） bean（bean工廠，bean定義，bean解析） 學習C++設計新思維(泛型程式設計與設計模式之應用).pdf之繼承關係檢查ok！主題是：檢查型別A與B是不是有繼承關係，在本書的P38，下面直接上程式碼。 #pragma once template<class T, class U> class Conversion { typedef char Small; class B 連載03：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)如果 oss 為我 AS img 概念 失望 架構 eof 統一化 打破了這種集合關系，那麽我們需要重新整理一下我們的思路，這些特征到底是什麽關系呢？感覺有點亂。 不過沒有關系，我們先跳出面向對象的原有的思維方式，我們先從計算機的最基本的處理來看，在計算機裏面我們使用 (值 連載01：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)識字 架構 margin 簡化 ××× 實例 如果 基本 系統架構 軟件設計公理化 現在是一個知識過剩的時代，培養獨立思考的能力遠比盲目看書更重要。 連載00：推薦：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)（袁曉河著）連載 由於 並且 時代 進取 瓶頸 轉載 所有 是我 我正在推出本人的心得體會《軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計（袁曉河著）》，由於我從未進行過相關的推廣，所以經驗欠缺，希望各位給出寶貴意見，謝謝！軟件設計正在邁入一個瓶頸時代，軟件設計正在越來越衰 連載02：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)根據 str 多態 讓我 text tro 得到 然而 ext 公理化之路 1 2 傳統方式的疑惑 首先讓我們來理解一下來自百科中傳統的對面向對象的定義和說明：抽象與分類：忽略事物的非本質特征，只註意那些與當前目標有關的本質特征，從而找出事物的共性，叫做抽象，把具有共同性質 連載04：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)在一起 class rgb 反向 變換 模式 tom prot RM 置換的公理化過程前面所涉及到的地址和值的“置換”關系以外，賦值、抽象、實現、繼承等也都是一種“置換”的關系，而這種“置換”關系是否只是邏輯上我們的一個創造呢？還是客觀現實中存在呢？這裏我暫時先給出結論：“ 連載06：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)pad box 表現 -a 標準 orm ack ace ria 可置換性可置換繼續向上融入了分層、虛擬化、微內核等架構設計中，所以正確性、穩定性和可測試性等等特性以外還需要新增一個新的非功能屬性，這就是可置換性，可置換性是一個比較隱式的特性，其外在表現不太為人所知，雖然在 連載31：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)nbsp 定性 之前 發生 修改 TE 主體 .com 方差 貝葉斯網絡模型 貝葉斯定理：貝葉斯定理是概率論中的一個結論，它跟隨機變量的條件概率以及邊緣概率分布有關。在有些關於概率的解說中，貝葉斯定理能夠告知我們如何利用新證據修改已有的看法。通常，事件A在事件B（發生）的條 連載29：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)新的 tro 因此 大量 blob 個數 通過 集合 事件 概率抽象 隨機變量：一個隨機試驗可能結果（稱為基本事件）的全體組成一個基本空間Ω。隨機變量X是定義在基本空間Ω上的取值為實數的函數，即基本空間Ω中每一個點，也就是每個基本事件都有實軸上的點與之對應。離散隨機變量：有 連載24：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)ext 美的 目前 簡單 mage 大量 系統架構 自己 另一個 對偶 對偶原理：有兩個定理（或命題），如果一個定理中的所有元素和運算替換為對應的對偶元素的就成為另一個定理時，這兩個定理是相互對偶的。兩個相互對偶的定理，如果其中一個定理真實，則另一個必然真實。數學上可以證明 連載38：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)數據業務 完全 等等 組裝 規劃 訪問 復雜 平臺 進一步 從另一個角度看設計 真理可能在少數人一邊。---柏拉圖最初偏離真理毫厘，到頭來就會謬之千裏。---亞裏士多德 前面的章節中我們從一些正規的角度來闡述軟件設計的基本思想原理，然而，如果我們被桎梏於這些所謂的規範化之中 連載39：軟件體系設計新方向：數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)算法 部分 運行 電信 最優 圖片 中國 而在 描述 1. 簡單性 由於對簡單的理解會很多，具有最少構成要素的結構，符合簡單性觀念。在眾多可能中選擇一個最方便的方式，也符合簡單性觀念。根據奧康的剃刀原則“如無必要，勿增實體”即簡單有效的原則。然而簡單性是一個相對的概念，是在 系統架構設計——設計模式之代理模式（一）在紛繁複雜的程式設計世界裡，我們總是需要儘可能的考慮到各種情況。而有這麼一種機制，我們可以將我們指責中的一部分隔離開來，讓一個所謂的代理來幫我們解決一部分和主體業務關係不大的業務，從而讓我們能更專 |