5、容器組件

這一小節(jié)中我們將討論請求處理組件：引擎（engine）、虛擬主機(jī)、上下文（context）組件。

5.1、引擎（engine）

引擎表示可運(yùn)行的Catalina的servlet引擎實例并且包含了servlet容器的核心功能。在一個服務(wù)中只能有一個引擎。同時，作為一個真正的容器，Engine元素之下可以包含一個或多個虛擬主機(jī)。

作為請求處理的主要組件，它接收代表傳入請求的對象以及輸出相應(yīng)結(jié)果。它主要功能是將傳入請求委托給適當(dāng)?shù)奶摂M主機(jī)處理。如果根據(jù)名稱沒有找到可處理的虛擬主機(jī)，那么將根據(jù)默認(rèn)的Host來判斷該由哪個虛擬主機(jī)處理。

5.2、虛擬主機(jī)

虛擬主機(jī)在Tomcat中使用Host組件表示，是web應(yīng)用容器或者是Tomcat中所說的上下文。

在虛擬主機(jī)中有兩個概念非常重要--主機(jī)的域名和根目錄。

·域名：每個虛擬主機(jī)是由它注冊的域名來標(biāo)識的（例：www.host1.com）。域名是您預(yù)期的在客戶端瀏覽器地址欄輸入的值，對虛擬主機(jī)來說就是請求頭部。一臺虛擬主機(jī)的名稱在包含它的引擎內(nèi)必須是唯一的。

·根目錄：根目錄所在的文件夾包含將被部署到此主機(jī)的上下文。根目錄可以是一個絕對路徑，也可以是對CATALINA_BASE 來說的一個相對路徑。

?

CATALINA_HOME 是一個環(huán)境變量，它引用了tomcat 二進(jìn)制文件的位置。通過CATALINA_BASE 環(huán)境變量僅僅使用一個tomcat安裝信息的二進(jìn)制文件，就可以根據(jù)不同的配置運(yùn)行多個tomcat實例（這主要由conf文件夾的內(nèi)容決定）。

此外，使用一個CATALINA_BASE引用的位置（和CATALINA_HOME不同）保持標(biāo)準(zhǔn)的二進(jìn)制分配獨(dú)立于您的安裝。這是有好處的，使tomcat升級到一個新版本變得容易，而不必?fù)?dān)心影響已經(jīng)發(fā)布的web應(yīng)用程序和相關(guān)的配置文件 。

?

基本概念

當(dāng)涉及到主機(jī)名映射到互聯(lián)網(wǎng)協(xié)議地址時，最簡單的場景，一個給定的完全合格的主機(jī)名(FQHN)，例如www.swengsol.com 與映射到特定主機(jī)的IP地址相關(guān)聯(lián)。

這種方法的缺點是，主機(jī)連接到互聯(lián)網(wǎng)是相當(dāng)昂貴的。這是真實存在的，尤其是當(dāng)您考慮到帶寬成本、網(wǎng)絡(luò)基礎(chǔ)設(shè)施建設(shè) (例如：數(shù)據(jù)庫/郵件服務(wù)器、防火墻、不間斷電源ups、容錯等) 以及維護(hù) (包括人員配置、管理和備份) ，更不用說首先要獲得一個IP地址。

?

?

因此，許多小企業(yè)認(rèn)為最好的方法是從托管服務(wù)提供商那里租賃空間和基礎(chǔ)設(shè)施。托管服務(wù)可能是提供單個的物理服務(wù)器，它可以連接到互聯(lián)網(wǎng)并由特定的IP地址標(biāo)識。這臺物理服務(wù)器可以托管多個域名，每個域名代表一個提供商的客戶。

例如，我們假設(shè)Acme Widgets Inc. 和 Vertico LLC 擁有它們的域名，www.acme-widgets.com 和 www.vertico.com ，這些域名被托管在同一臺物理服務(wù)器上。應(yīng)用程序被部署到各自對應(yīng)的域，并且互不干擾。

在這種情況下，這些域被稱為虛擬主機(jī)，從這種意義上來講，每一個域看起來都是一個獨(dú)立的“物理主機(jī)”。然而，事實上，他們(域)僅僅是同一臺物理主機(jī)上不同的邏輯分區(qū)。

?

5.3、虛擬主機(jī)技術(shù)

有兩種常用的方法來設(shè)置虛擬主機(jī)：

·基于獨(dú)立IP地址的虛擬主機(jī)服務(wù)

·基于名稱的虛擬主機(jī)服務(wù)

5.3.1基于獨(dú)立IP地址的虛擬主機(jī)服務(wù)

使用這種技術(shù)，每個FQHN(完全合格的主機(jī)名)被解析為一個單獨(dú)的IP地址。然而，這些IP中的每一個被解析后都映射到同一臺物理機(jī)器上。

您可以使用以下的機(jī)制來實現(xiàn)此技術(shù)：

·多宿主服務(wù)器，也就是說它安裝了多個網(wǎng)卡(NICs),每一個網(wǎng)卡都分配了IP地址

·使用操作系統(tǒng)功能來設(shè)置虛擬網(wǎng)絡(luò)接口，為單個物理NIC（網(wǎng)卡）動態(tài)分配多個IP地址

?

無論在哪一種情況下，缺點是我們要獲得多個IP地址，而且這些地址(至少對于IPv4來說)是一種有限的資源。

Web服務(wù)器監(jiān)聽為這些IP地址分配的端口，當(dāng)Web服務(wù)器在一個特定的IP地址檢測到傳入的請求時，它會生成該IP地址的響應(yīng)信息。

例如，您有一個web服務(wù)器，它運(yùn)行在一個特定的在80端口監(jiān)聽 11.156.33.345 和 11.156.33.346 IP地址請求的物理主機(jī)上。此web服務(wù)器用以下方式響應(yīng)請求：當(dāng)收到來自主機(jī)域名www.host1.com的請求時，則映射到11.156.33.345 IP地址；反之當(dāng)收到來自主機(jī)域名www.host2.com的請求時則映射到后面的 IP地址 11.156.33.346 。

當(dāng)接收到一個來自11.156.33.346 IP地址的請求時，web服務(wù)器知道它應(yīng)當(dāng)為ww.host2.com對應(yīng)的域準(zhǔn)備響應(yīng)信息。對用戶來說，這是一個完全獨(dú)立的物理服務(wù)器在為他提供服務(wù)。

5.3.2基于名稱的虛擬主機(jī)服務(wù)

這是一種比較新的技術(shù)，它允許您把不同的域名映射到同一個IP地址。這些都是經(jīng)過注冊的正常的域名，多個DNS條目將這些域名映射到同一IP地址。

?

HTTP 1.1協(xié)議要求每個請求必須包含一個主機(jī)頭：帶有完全合格的主機(jī)域名，以及用戶希望連接的端口號(如果已指定)。主機(jī)上運(yùn)行的web服務(wù)器接收到此請求，解析此請求中的主機(jī)頭信息，以確定相應(yīng)的虛擬主機(jī)來響應(yīng)此請求。簡單、而且不使用不必要的IP地址，基于名稱的虛擬主機(jī)服務(wù)是我們的首選。

然而，當(dāng)您同時使用SSL(安全套接層)和虛擬主機(jī)時，您也許不得不使用基于IP地址的虛擬主機(jī)服務(wù)。原因是，在特定的虛擬主機(jī)響應(yīng)請求之前，協(xié)商協(xié)議要進(jìn)行證書認(rèn)證。這是因為：SSL協(xié)議層位于HTTP協(xié)議層的下方，而且在握手消息認(rèn)證完成之前，與客戶端請求進(jìn)行安全認(rèn)證的模塊無法讀取HTTP請求頭信息。

您也許可以同時使用SSL和基于名稱的虛擬主機(jī)服務(wù)，如果您的web服務(wù)器和客戶機(jī)支持RFC 3546(傳輸層安全性擴(kuò)展http://www.ietf.org/rfc/rfc3546.txt) 指定的服務(wù)器名稱標(biāo)識擴(kuò)展。使用此擴(kuò)展，在SSL協(xié)商期間，客戶端會傳輸主機(jī)名稱給它嘗試連接的對象，從而使web服務(wù)器能夠處理握手信息并為正確的主機(jī)名返回證書。

虛擬主機(jī)別名

當(dāng)web服務(wù)器解析別名信息時，例如它在主機(jī)頭里看到了域名的別名，那么web服務(wù)器會把此別名當(dāng)作虛擬主機(jī)的域名來處理。 例如，您把swengsol.com設(shè)置為虛擬主機(jī)域名www.swengsol.com的別名，那么在客戶端url里無論是輸入域名還是別名，您都會收到來自同一個虛擬主機(jī)的響應(yīng)信息。 這種方式效果不錯，當(dāng)一個物理主機(jī)有多個域名時，而且您不想弄亂配置文件在為每個別名創(chuàng)建一組條目時。

?

5.4、上下文（Context）

上下文或者web應(yīng)用是應(yīng)用自定義代碼（servlet、jsp）所存活的地方。它為web應(yīng)用組織資源提供了便利。

同時context容器為servlet提供了一個ServletContext實例。在許多方面,servlet規(guī)范主要是關(guān)心這個上下文組件。例如，它規(guī)定了部署上下文的格式以及部署內(nèi)容的描述符。

以下是上下文的一些重要屬性：

·根目錄（document base）：這個路徑是指war包或者未壓縮的項目文件所存放的目錄，可以是相對的，也可以是絕對的。

·上下文路徑（context path）：它是指在一個host下url中唯一標(biāo)識一個web應(yīng)用的部分。它幫助host容器來判斷該由哪一個已部署的上下文來處理傳入的請求。

也許你可能配置了默認(rèn)context，它可以在找不到匹配的context的情況下來處理傳入請求。該默認(rèn)context可以通過將其上下文路徑配置為空來標(biāo)記的，因此，可以通過只有主機(jī)名的路徑來訪問它（譯注：如http://localhost:8080/來訪問）。并且該context已被tomcat默認(rèn)定義為根目錄下的ROOT目錄。

·自動重加載（automic reload）：上下文中的資源會被tomcat監(jiān)控，一旦資源發(fā)生改變Tomcat就會自動重新加載資源文件。雖然該功能在開發(fā)過程中非常有用，但是在生產(chǎn)環(huán)境這個操作代價非常高，通常需要重啟產(chǎn)品應(yīng)用。

?

Context配置

Context是唯一的，這主要是因為它的配置包含多個選項。而我們之前已經(jīng)注意到的conf/server.xml是用來配置Tomcat實例中一些全局性的參數(shù)。雖然在這個文件中可以配置context相關(guān)的東西，但是不推薦這樣做。

相反，Tomcat推薦大家將context相關(guān)的配置從server.xml中提取出來，配置到上下文段文件中，該文件會被Tomcat監(jiān)控并且可以在運(yùn)行過程中重新加載。

請再次注意，server.xml只有在啟動時被加載一次。

同時需要確保在context中配置一個獨(dú)立明確的host和engine，因為Tomcat會在CATALINA_HOME/conf///目錄下查找context相關(guān)配置。而該目錄下為特定主機(jī)配置的上下文段文件則是以名稱.xml命名。

默認(rèn)情況下，會有一個引擎Catalina和一個名稱為localhost的主機(jī)，對應(yīng)的工作目錄為CATALINA_HOME/conf/Catalina/localhost。但是該目錄也可以是有效域名，如www.swengsol.com，那么對應(yīng)目錄就是CATALINA_HOME/conf/Catalina/www.swengsol.com。

另外，context片段也可以在war或部署目錄中被包含在META-INF目錄下。這種情況下，context文件名稱必須為context.xml。

此外，Context還可以被配置在web應(yīng)用描述符文件web.xml中。雖然這個片段文件是Tomcat專用的，但是由于該描述符是通過Servlet規(guī)范來描述的，因此它也適用與JavaEE下的其他輕量級servlet容器。

?

包裝器（Wrapper）

包裝器wrapper對象是context容器的子容器，表示一個單獨(dú)的servlet（或者由jsp文件轉(zhuǎn)換而來的servlet）。它之所以稱為包裝器是因為它包裝了java.servlet.Servlet實例。

這是容器層次結(jié)構(gòu)的最底層，添加任何子類都會導(dǎo)致異常。

同時包裝器還對它所包裝的servlet負(fù)責(zé)，包括加載、實例化servlet以及調(diào)用控制servlet生命周期相關(guān)的函數(shù)，如init()、service()和destroy()方法。

此外包裝器還通過它基本的Valve來調(diào)用和其包裝的servlet相關(guān)的過濾器。

在下篇文章中我們將討論嵌套組件相關(guān)東西。

Tomcat架構(gòu)(二)