5、容器組件

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

5.1、引擎（engine）

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

作為請求處理的主要組件，它接收代表傳入請求的對象以及輸出相應結果。它主要功能是將傳入請求委托給適當的虛擬主機處理。如果根據名稱沒有找到可處理的虛擬主機，那么將根據默認的Host來判斷該由哪個虛擬主機處理。

5.2、虛擬主機

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

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

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

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

?

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

此外，使用一個CATALINA_BASE引用的位置（和CATALINA_HOME不同）保持標準的二進制分配獨立于您的安裝。這是有好處的，使tomcat升級到一個新版本變得容易，而不必擔心影響已經發布的web應用程序和相關的配置文件 。

?

基本概念

當涉及到主機名映射到互聯網協議地址時，最簡單的場景，一個給定的完全合格的主機名(FQHN)，例如www.swengsol.com 與映射到特定主機的IP地址相關聯。

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

?

?

因此，許多小企業認為最好的方法是從托管服務提供商那里租賃空間和基礎設施。托管服務可能是提供單個的物理服務器，它可以連接到互聯網并由特定的IP地址標識。這臺物理服務器可以托管多個域名，每個域名代表一個提供商的客戶。

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

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

?

5.3、虛擬主機技術

有兩種常用的方法來設置虛擬主機：

·基于獨立IP地址的虛擬主機服務

·基于名稱的虛擬主機服務

5.3.1基于獨立IP地址的虛擬主機服務

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

您可以使用以下的機制來實現此技術：

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

·使用操作系統功能來設置虛擬網絡接口，為單個物理NIC（網卡）動態分配多個IP地址

?

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

Web服務器監聽為這些IP地址分配的端口，當Web服務器在一個特定的IP地址檢測到傳入的請求時，它會生成該IP地址的響應信息。

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

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

5.3.2基于名稱的虛擬主機服務

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

?

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

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

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

虛擬主機別名

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

?

5.4、上下文（Context）

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

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

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

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

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

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

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

?

Context配置

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

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

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

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

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

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

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

?

包裝器（Wrapper）

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

這是容器層次結構的最底層，添加任何子類都會導致異常。

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

此外包裝器還通過它基本的Valve來調用和其包裝的servlet相關的過濾器。

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

Tomcat架構(二)