正文

創(chuàng)新互聯(lián)建站專注于莘縣網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供莘縣營銷型網(wǎng)站建設(shè)，莘縣網(wǎng)站制作、莘縣網(wǎng)頁設(shè)計、莘縣網(wǎng)站官網(wǎng)定制、成都小程序開發(fā)服務(wù)，打造莘縣網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供莘縣網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

1 前言

Tomcat 隸屬于 Apache 基金會，是開源的輕量級 Web 應(yīng)用服務(wù)器，使用非常廣泛。server.xml是 Tomcat 中最重要的配置文件，server.xml的每一個元素都對應(yīng)了 Tomcat 中的一個組件；通過對 XML 文件中元素的配置，可以實現(xiàn)對 Tomcat 中各個組件的控制。因此，學(xué)習(xí)server.xml文件的配置，對于了解和使用 Tomcat 至關(guān)重要。

本文將通過實例，介紹server.xml中各個組件的配置，并詳細說明 Tomcat 各個核心組件的作用以及各個組件之間的相互關(guān)系。

說明：由于server.xml文件中元素與 Tomcat 中組件的對應(yīng)關(guān)系，后文中為了描述方便，“元素”和“組件”的使用不嚴(yán)格區(qū)分。

2 server.xml配置實例

server.xml位于$TOMCAT_HOME/conf目錄下，下面是一個server.xml實例。后文中將結(jié)合該實例講解server.xml中，各個元素的含義和作用；在閱讀后續(xù)章節(jié)過程中，可以對照該 XML 文檔進行理解。

3 server.xml文檔的整體結(jié)構(gòu)和元素分類

3.1 整體結(jié)構(gòu)

server.xml的整體結(jié)構(gòu)如下：

該結(jié)構(gòu)中只給出了 Tomcat 的核心組件，除了核心組件外，Tomcat 還有一些其他組件，下面介紹一下組件的分類。

3.2 元素分類

server.xml文件中的元素可以分為以下 4 類：

第 1 類：頂層元素，和

元素是整個配置文件的根元素，元素則代表一個Engine元素以及一組與之相連的Connector元素。

第 2 類：連接器，

代表了外部客戶端發(fā)送請求到特定 Service 的接口；同時也是外部客戶端從特定 Service 接收響應(yīng)的接口。

第 3 類：容器，、和

容器的功能是處理 Connector 接收進來的請求，并產(chǎn)生相應(yīng)的響應(yīng)。Engine、Host 和 Context 都是容器，但它們不是平行的關(guān)系，而是父子關(guān)系：Engine 包含 Host，Host 包含 Context。一個 Engine 組件可以處理 Service 中的所有請求，一個 Host 組件可以處理發(fā)向一個特定虛擬主機的所有請求，一個 Context 組件可以處理一個特定 Web 應(yīng)用的所有請求。

第 4 類：內(nèi)嵌組件，可以內(nèi)嵌到容器中的組件

實際上，Server、Service、Connector、Engine、Host 和 Context 是最重要的最核心的 Tomcat 組件，其他組件都可以歸為內(nèi)嵌組件。下面將詳細介紹 Tomcat 中各個核心組件的作用，以及相互之間的關(guān)系。

4 核心組件

本部分將分別介紹各個核心組件的作用、特點以及配置方式等。

4.1 Server

Server 元素在最頂層，代表整個 Tomcat 容器，因此它必須是server.xml中唯一一個最外層的元素。一個 Server 元素中可以有一個或多個 Service 元素。

在第一部分的例子中，在最外層有一個元素，shutdown屬性表示關(guān)閉 Server 的指令；port屬性表示 Server 接收shutdown指令的端口號，設(shè)為-1可以禁掉該端口。

Server 的主要任務(wù)，就是提供一個接口讓客戶端能夠訪問到這個 Service 集合，同時維護它所包含的所有的 Service 的生命周期，包括如何初始化、如何結(jié)束服務(wù)、如何找到客戶端要訪問的 Service 等。

4.2 Service

Service 的作用，是在 Connector 和 Engine 外面包了一層，把它們組裝在一起，對外提供服務(wù)。一個 Service 可以包含多個 Connector，但是只能包含一個 Engine；其中 Connector 的作用是從客戶端接收請求，Engine 的作用是處理接收進來的請求。

在第一部分的例子中，Server 中包含一個名稱為Catalina的 Service。實際上，Tomcat 可以提供多個 Service，不同的 Service 監(jiān)聽不同的端口，后文會有介紹。

4.3 Connector

Connector 的主要功能，是接收連接請求，創(chuàng)建 Request 和 Response 對象用于和請求端交換數(shù)據(jù)；然后分配線程讓 Engine 來處理這個請求，并把產(chǎn)生的 Request 和 Response 對象傳給 Engine。

通過配置 Connector，可以控制請求 Service 的協(xié)議及端口號。在第一部分的例子中，Service 包含兩個 Connector：

通過配置第 1 個 Connector，客戶端可以通過 8080 端口號使用http協(xié)議訪問 Tomcat。其中，protocol屬性規(guī)定了請求的協(xié)議，port規(guī)定了請求的端口號，redirectPort表示當(dāng)強制要求https而請求是http時，重定向至端口號為 8443 的 Connector，connectionTimeout表示連接的超時時間。在這個例子中，Tomcat 監(jiān)聽 HTTP 請求，使用的是 8080 端口，而不是正式的 80 端口；實際上，在正式的生產(chǎn)環(huán)境中，Tomcat 也常常監(jiān)聽 8080 端口，而不是 80 端口。這是因為在生產(chǎn)環(huán)境中，很少將 Tomcat 直接對外開放接收請求，而是在 Tomcat 和客戶端之間加一層代理服務(wù)器（如 nginx），用于請求的轉(zhuǎn)發(fā)、負載均衡、處理靜態(tài)文件等；通過代理服務(wù)器訪問 Tomcat 時，是在局域網(wǎng)中，因此一般仍使用 8080 端口。

通過配置第 2 個 Connector，客戶端可以通過 8009 端口號使用AJP協(xié)議訪問 Tomcat。AJP協(xié)議負責(zé)和其他的 HTTP 服務(wù)器（如 Apache）建立連接；在把 Tomcat 與其他 HTTP 服務(wù)器集成時，就需要用到這個連接器。之所以使用 Tomcat 和其他服務(wù)器集成，是因為 Tomcat 可以用作 Servlet/JSP 容器，但是對靜態(tài)資源的處理速度較慢，不如 Apache 和 IIS 等 HTTP 服務(wù)器；因此常常將 Tomcat 與 Apache 等集成，前者作 Servlet 容器，后者處理靜態(tài)資源，而 AJP 協(xié)議便負責(zé) Tomcat 和 Apache 的連接。Tomcat 與 Apache 等集成的原理如下圖所示：

4.4 Engine

Engine 組件在 Service 組件中有且只有一個；Engine 是 Service 組件中的請求處理組件。Engine 組件從一個或多個 Connector 中接收請求并處理，并將完成的響應(yīng)返回給 Connector，最終傳遞給客戶端。

前面已經(jīng)提到過，Engine、Host 和 Context 都是容器，但它們不是平行的關(guān)系，而是父子關(guān)系：Engine 包含 Host，Host 包含 Context。

在第一部分的例子中，Engine 的配置語句如下：

其中，name屬性用于日志和錯誤信息，在整個 Server 中應(yīng)該唯一。defaultHost屬性指定了默認的 host 名稱，當(dāng)發(fā)往本機的請求指定的 host 名稱不存在時，一律使用 defaultHost 指定的 host 進行處理；因此，defaultHost的值，必須與 Engine 中的一個 Host 組件的name屬性值匹配。

4.5 Host

4.5.1 Engine 與 Host

Host 是 Engine 的子容器。Engine 組件中可以內(nèi)嵌 1 個或多個 Host 組件，每個 Host 組件代表 Engine 中的一個虛擬主機。Host 組件至少有一個，且其中一個的name必須與 Engine 組件的defaultHost屬性相匹配。

4.5.2 Host 的作用

Host 虛擬主機的作用，是運行多個 Web 應(yīng)用（一個 Context 代表一個 Web 應(yīng)用），并負責(zé)安裝、展開、啟動和結(jié)束每個 Web 應(yīng)用。

Host 組件代表的虛擬主機，對應(yīng)了服務(wù)器中一個網(wǎng)絡(luò)名實體（如www.test.com，或 IP 地址116.25.25.25），為了使用戶可以通過網(wǎng)絡(luò)名連接 Tomcat 服務(wù)器，這個名字應(yīng)該在 DNS 服務(wù)器上注冊。

客戶端通常使用主機名來標(biāo)識它們希望連接的服務(wù)器；該主機名也會包含在 HTTP 請求頭中。Tomcat 從 HTTP 頭中提取出主機名，尋找名稱匹配的主機。如果沒有匹配，請求將發(fā)送至默認主機。因此默認主機不需要是在 DNS 服務(wù)器中注冊的網(wǎng)絡(luò)名，因為任何與所有 Host 名稱不匹配的請求，都會路由至默認主機。

4.5.3 Host 的配置

在第一部分的例子中，Host 的配置如下：

下面對其中配置的屬性進行說明：

name屬性指定虛擬主機的主機名，一個 Engine 中有且僅有一個 Host 組件的name屬性與 Engine 組件的defaultHost屬性相匹配；一般情況下，主機名需要是在 DNS 服務(wù)器中注冊的網(wǎng)絡(luò)名，但是 Engine 指定的defaultHost不需要，原因在前面已經(jīng)說明。

unpackWARs指定了是否將代表 Web 應(yīng)用的 WAR 文件解壓；如果為true，通過解壓后的文件結(jié)構(gòu)運行該 Web 應(yīng)用，如果為false，直接使用 WAR 文件運行 Web 應(yīng)用。

Host 的autoDeploy和appBase屬性，與 Host 內(nèi) Web 應(yīng)用的自動部署有關(guān)；此外，本例中沒有出現(xiàn)的xmlBase和deployOnStartup屬性，也與 Web 應(yīng)用的自動部署有關(guān)；將在下一節(jié)（Context）中介紹。

4.6 Context

4.6.1 Context 的作用

Context 元素代表在特定虛擬主機上運行的一個 Web 應(yīng)用。在后文中，提到 Context、應(yīng)用或 Web 應(yīng)用，它們指代的都是 Web 應(yīng)用。每個 Web 應(yīng)用基于 WAR 文件，或 WAR 文件解壓后對應(yīng)的目錄（這里稱為應(yīng)用目錄）。Context 是 Host 的子容器，每個 Host 中可以定義任意多的 Context 元素。

在第一部分的例子中，可以看到server.xml配置文件中并沒有出現(xiàn) Context 元素的配置。這是因為，Tomcat 開啟了自動部署，Web 應(yīng)用沒有在server.xml中配置靜態(tài)部署，而是由 Tomcat 通過特定的規(guī)則自動部署。下面介紹一下 Tomcat 自動部署 Web 應(yīng)用的機制。

4.6.2 Web 應(yīng)用自動部署

第 1 點：Host 的配置

要開啟 Web 應(yīng)用的自動部署，需要配置所在的虛擬主機；配置的方式就是前面提到的 Host 元素的deployOnStartup和autoDeploy屬性。如果deployOnStartup和autoDeploy設(shè)置為true，則 tomcat 啟動自動部署：當(dāng)檢測到新的 Web 應(yīng)用或 Web 應(yīng)用的更新時，會觸發(fā)應(yīng)用的部署（或重新部署）。二者的主要區(qū)別在于，deployOnStartup為true時，Tomcat 在啟動時檢查 Web 應(yīng)用，且檢測到的所有 Web 應(yīng)用視作新應(yīng)用；autoDeploy為true時，Tomcat 在運行時定期檢查新的 Web 應(yīng)用或 Web 應(yīng)用的更新。除此之外，二者的處理相似。

通過配置deployOnStartup和autoDeploy可以開啟虛擬主機自動部署 Web 應(yīng)用；實際上，自動部署依賴于檢查是否有新的或更改過的 Web 應(yīng)用，而 Host 元素的appBase和xmlBase設(shè)置了檢查 Web 應(yīng)用更新的目錄。

其中，appBase屬性指定 Web 應(yīng)用所在的目錄，默認值是webapps，這是一個相對路徑，代表 Tomcat 根目錄下webapps文件夾。xmlBase屬性指定 Web 應(yīng)用的 XML 配置文件所在的目錄，默認值為conf//，例如第一部分的例子中，主機localhost的xmlBase的默認值是$TOMCAT_HOME/conf/Catalina/localhost。

第 2 點：檢查 Web 應(yīng)用更新

一個 Web 應(yīng)用可能包括以下文件：XML 配置文件，WAR 包，以及一個應(yīng)用目錄（該目錄包含 Web 應(yīng)用的文件結(jié)構(gòu)）；其中 XML 配置文件位于xmlBase指定的目錄，WAR 包和應(yīng)用目錄位于appBase指定的目錄。Tomcat 按照如下的順序進行掃描，來檢查應(yīng)用更新：

掃描虛擬主機指定的xmlBase下的 XML 配置文件；
掃描虛擬主機指定的appBase下的 WAR 文件；
掃描虛擬主機指定的appBase下的應(yīng)用目錄。

第 3 點：元素的配置

Context 元素最重要的屬性是docBase和path，此外reloadable屬性也比較常用。

docBase指定了該 Web 應(yīng)用使用的 WAR 包路徑，或應(yīng)用目錄。需要注意的是，在自動部署場景下（配置文件位于xmlBase中），docBase不在appBase目錄中，才需要指定；如果docBase指定的 WAR 包或應(yīng)用目錄就在docBase中，則不需要指定，因為 Tomcat 會自動掃描appBase中的 WAR 包和應(yīng)用目錄，指定了反而會造成問題。

path指定了訪問該 Web 應(yīng)用的上下文路徑，當(dāng)請求到來時，Tomcat 根據(jù) Web 應(yīng)用的path屬性與 URI 的匹配程度來選擇 Web 應(yīng)用處理相應(yīng)請求。例如，Web 應(yīng)用app1的path屬性是/app1，Web 應(yīng)用app2的path屬性是/app2，那么請求/app1/index.html會交由app1來處理；而請求/app2/index.html會交由app2來處理。如果一個 Context 元素的path屬性為""，那么這個 Context 是虛擬主機的默認 Web 應(yīng)用；當(dāng)請求的 URI 與所有的path都不匹配時，使用該默認Web應(yīng)用來處理。

但是，需要注意的是，在自動部署場景下（配置文件位于xmlBase中），不能指定path屬性，path屬性由配置文件的文件名、WAR 文件的文件名或應(yīng)用目錄的名稱自動推導(dǎo)出來。如掃描 Web 應(yīng)用時，發(fā)現(xiàn)了xmlBase目錄下的app1.xml，或appBase目錄下的app1.WAR或app1應(yīng)用目錄，則該 Web 應(yīng)用的path屬性是app1。如果名稱不是app1而是ROOT，則該 Web 應(yīng)用是虛擬主機默認的 Web 應(yīng)用，此時path屬性推導(dǎo)為""。

reloadable屬性指示 Tomcat 是否在運行時監(jiān)控在WEB-INF/classes和WEB-INF/lib目錄下class文件的改動。如果值為true，那么當(dāng)class文件改動時，會觸發(fā) Web 應(yīng)用的重新加載。在開發(fā)環(huán)境下，reloadable設(shè)置為true便于調(diào)試；但是在生產(chǎn)環(huán)境中設(shè)置為true會給服務(wù)器帶來性能壓力，因此reloadable參數(shù)的默認值為false。

下面來看自動部署時，xmlBase下的 XML 配置文件app1.xml的例子：

在該例子中，docBase位于 Host 的appBase目錄之外；path屬性沒有指定，而是根據(jù)app1.xml自動推導(dǎo)為app1；由于是在開發(fā)環(huán)境下，因此reloadable設(shè)置為true，便于開發(fā)調(diào)試。

第 4 點：自動部署舉例

最典型的自動部署，就是當(dāng)我們安裝完 Tomcat 后，$TOMCAT_HOME/webapps目錄下有如下文件夾：

當(dāng)我們啟動 Tomcat 后，可以使用http://localhost:8080/來訪問 Tomcat，其實訪問的就是 ROOT 對應(yīng)的 Web 應(yīng)用；我們也可以通過http://localhost:8080/docs來訪問docs應(yīng)用，同理我們可以訪問examples/host-manager/manager這幾個 Web 應(yīng)用。

4.6.3 server.xml中靜態(tài)部署 Web 應(yīng)用

除了自動部署，我們也可以在server.xml中通過元素靜態(tài)部署 Web 應(yīng)用。靜態(tài)部署與自動部署是可以共存的。在實際應(yīng)用中，并不推薦使用靜態(tài)部署，因為server.xml是不可動態(tài)重加載的資源，服務(wù)器一旦啟動了以后，要修改這個文件，就得重啟服務(wù)器才能重新加載。而自動部署可以在 Tomcat 運行時通過定期的掃描來實現(xiàn)，不需要重啟服務(wù)器。server.xml中使用 Context 元素配置 Web 應(yīng)用，Context 元素應(yīng)該位于 Host 元素中。舉例如下：

docBase：靜態(tài)部署時，docBase可以在appBase目錄下，也可以不在；本例中，docBase不在appBase目錄下；
path：靜態(tài)部署時，可以顯式指定path屬性，但是仍然受到了嚴(yán)格的限制：只有當(dāng)自動部署完全關(guān)閉（deployOnStartup和autoDeploy都為false）或docBase不在appBase中時，才可以設(shè)置path屬性。在本例中，docBase不在appBase中，因此path屬性可以設(shè)置；
reloadable屬性的用法與自動部署時相同。

5 核心組件的關(guān)聯(lián)

5.1 整體關(guān)系

核心組件之間的整體關(guān)系，在上一部分有所介紹，這里總結(jié)一下：

Server 元素在最頂層，代表整個 Tomcat 容器；一個 Server 元素中可以有一個或多個 Service 元素。

Service 在 Connector 和 Engine 外面包了一層，把它們組裝在一起，對外提供服務(wù)。一個 Service 可以包含多個 Connector，但是只能包含一個 Engine；Connector 接收請求，Engine 處理請求。

Engine、Host 和 Context 都是容器，且 Engine 包含 Host，Host 包含 Context。每個 Host 組件代表 Engine 中的一個虛擬主機；每個 Context 組件代表在特定 Host 上運行的一個 Web 應(yīng)用。

5.2 如何確定請求由誰處理？

當(dāng)請求被發(fā)送到 Tomcat 所在的主機時，如何確定最終哪個 Web 應(yīng)用來處理該請求呢？

5.2.1 根據(jù)協(xié)議和端口號選定 Service 和 Engine

Service 中的 Connector 組件可以接收特定端口的請求，因此，當(dāng) Tomcat 啟動時，Service 組件就會監(jiān)聽特定的端口。在第一部分的例子中，catalina這個 Service 監(jiān)聽了 8080 端口（基于 HTTP 協(xié)議）和 8009 端口（基于 AJP 協(xié)議）。當(dāng)請求進來時，Tomcat 便可以根據(jù)協(xié)議和端口號選定處理請求的 Service；Service 一旦選定，Engine 也就確定。

通過在 Server 中配置多個 Service，可以實現(xiàn)通過不同的端口號來訪問同一臺機器上部署的不同應(yīng)用。

5.2.2 根據(jù)域名或 IP 地址選定 Host

Service 確定后，Tomcat 在 Service 中尋找名稱與域名/IP 地址匹配的 Host 處理該請求。如果沒有找到，則使用 Engine 中指定的defaultHost來處理該請求。在第一部分的例子中，由于只有一個 Host（name屬性為localhost），因此該 Service/Engine 的所有請求都交給該 Host 處理。

5.2.3 根據(jù) URI 選定 Context/Web 應(yīng)用

這一點在 Context 一節(jié)有詳細的說明：Tomcat 根據(jù)應(yīng)用的path屬性與 URI 的匹配程度來選擇 Web 應(yīng)用處理相應(yīng)請求，這里不再贅述。

5.2.4 舉例

以請求http://localhost:8080/app1/index.html為例，首先通過協(xié)議和端口號（http和8080）選定 Service；然后通過主機名（localhost）選定 Host；然后通過 URI（/app1/index.html）選定 Web 應(yīng)用。

5.3 如何配置多個服務(wù)

通過在 Server 中配置多個 Service 服務(wù)，可以實現(xiàn)通過不同的端口號來訪問同一臺機器上部署的不同 Web 應(yīng)用。在server.xml中配置多服務(wù)的方法非常簡單，分為以下幾步：

復(fù)制元素，放在當(dāng)前后面；

修改端口號：根據(jù)需要監(jiān)聽的端口號修改元素的port屬性；必須確保該端口沒有被其他進程占用，否則 Tomcat 啟動時會報錯，而無法通過該端口訪問 Web 應(yīng)用。
以 Win7 為例，可以用如下方法找出某個端口是否被其他進程占用：netstat -aon|findstr "8081"發(fā)現(xiàn) 8081 端口被 PID 為 2064 的進程占用，tasklist |findstr "2064"發(fā)現(xiàn)該進程為FrameworkService.exe（這是 McAfee 殺毒軟件的進程）。

修改 Service 和 Engine 的name屬性；

修改 Host 的appBase屬性（如webapps2）

Web 應(yīng)用仍然使用自動部署；

將要部署的 Web 應(yīng)用（WAR 包或應(yīng)用目錄）拷貝到新的appBase下。

以第一部分的server.xml為例，多個 Service 的配置如下：

<?xml version='1.0' encoding='utf-8'?>

 
 
 
 
 
 
 
 
 
 
 
 
 
  
  
  
  
  
  
 
 
 
 
 
 
  
  
  
  
  
  
 
 

再將原webapps下的docs目錄拷貝到webapps2中，則通過如下兩個接口都可以訪問docs應(yīng)用：

http://localhost:8080/docs/
http://localhost:8084/docs/

6 其他組件

除核心組件外，server.xml中還可以配置很多其他組件。下面只介紹第一部分例子中出現(xiàn)的組件，如果要了解更多內(nèi)容，可以查看 Tomcat 官方文檔。

6.1 Listener

Listener（即監(jiān)聽器）定義的組件，可以在特定事件發(fā)生時執(zhí)行特定的操作；被監(jiān)聽的事件通常是 Tomcat 的啟動和停止。監(jiān)聽器可以在 Server、Engine、Host 或 Context 中，本例中的監(jiān)聽器都是在 Server 中。實際上，本例中定義的 6 個監(jiān)聽器，都只能存在于 Server 組件中。監(jiān)聽器不允許內(nèi)嵌其他組件。

監(jiān)聽器需要配置的最重要的屬性是className，該屬性規(guī)定了監(jiān)聽器的具體實現(xiàn)類，該類必須實現(xiàn)了org.apache.catalina.LifecycleListener接口。下面依次介紹例子中配置的監(jiān)聽器：

VersionLoggerListener：當(dāng) Tomcat 啟動時，該監(jiān)聽器記錄 Tomcat、Java 和操作系統(tǒng)的信息。該監(jiān)聽器必須是配置的第一個監(jiān)聽器。

AprLifecycleListener：Tomcat 啟動時，檢查 APR 庫，如果存在則加載。APR，即 Apache Portable Runtime，是 Apache 可移植運行庫，可以實現(xiàn)高可擴展性、高性能，以及與本地服務(wù)器技術(shù)更好的集成。

JasperListener：在 Web 應(yīng)用啟動之前初始化 Jasper，Jasper 是 JSP 引擎，把 JVM 不認識的 JSP 文件解析成 Java 文件，然后編譯成class文件供 JVM 使用。

JreMemoryLeakPreventionListener：與類加載器導(dǎo)致的內(nèi)存泄露有關(guān)。

GlobalResourcesLifecycleListener：通過該監(jiān)聽器，初始化標(biāo)簽中定義的全局 JNDI 資源；如果沒有該監(jiān)聽器，任何全局資源都不能使用。將在后文介紹。

ThreadLocalLeakPreventionListener：當(dāng) Web 應(yīng)用因thread-local導(dǎo)致的內(nèi)存泄露而要停止時，該監(jiān)聽器會觸發(fā)線程池中線程的更新。當(dāng)線程執(zhí)行完任務(wù)被收回線程池時，活躍線程會一個一個的更新。只有當(dāng) Web 應(yīng)用（即 Context 元素）的renewThreadsWhenStoppingContext屬性設(shè)置為true時，該監(jiān)聽器才有效。

6.2 GlobalNamingResources 與 Realm

第一部分的例子中，Engine 組件下定義了 Realm 組件：

Realm，可以把它理解成“域”；Realm 提供了一種用戶密碼與 Web 應(yīng)用的映射關(guān)系，從而達到角色安全管理的作用。在本例中，Realm 的配置使用name為 UserDatabase 的資源實現(xiàn)。而該資源在 Server 元素中使用 GlobalNamingResources 配置：

GlobalNamingResources 元素定義了全局資源，通過配置可以看出，該配置是通過讀取$TOMCAT_HOME/conf/tomcat-users.xml實現(xiàn)的。

6.3 Valve

在第一部分的例子中，Host 元素內(nèi)定義了 Valve 組件：

單詞 Valve 的意思是“閥門”，在 Tomcat 中代表了請求處理流水線上的一個組件；Valve 可以與 Tomcat 的容器（Engine、Host 或 Context）關(guān)聯(lián)。不同的 Valve 有不同的特性，下面介紹一下本例中出現(xiàn)的 AccessLogValve。

AccessLogValve 的作用是通過日志記錄其所在的容器中處理的所有請求，在本例中，Valve 放在 Host 下，便可以記錄該 Host 處理的所有請求。AccessLogValve 記錄的日志就是訪問日志，每天的請求會寫到一個日志文件里。AccessLogValve 可以與 Engine、Host 或 Context 關(guān)聯(lián)；在本例中，只有一個 Engine，Engine 下只有一個 Host，Host 下只有一個 Context，因此 AccessLogValve 放在三個容器下的作用其實是類似的。本例的 AccessLogValve 屬性的配置，使用的是默認的配置；下面介紹 AccessLogValve 中各個屬性的作用：

className：規(guī)定了 Valve 的類型，是最重要的屬性；本例中，通過該屬性規(guī)定了這是一個 AccessLogValve。

directory：指定日志存儲的位置，本例中，日志存儲在$TOMCAT_HOME/logs目錄下。

prefix：指定了日志文件的前綴。

suffix：指定了日志文件的后綴。通過directory、prefix和suffix的配置，在$TOMCAT_HOME/logs目錄下，可以看到如下所示的日志文件。

pattern：指定記錄日志的格式，本例中各項的含義如下：

%h：遠程主機名或 IP 地址；如果有 Nginx 等反向代理服務(wù)器進行請求分發(fā)，該主機名/IP 地址代表的是 Nginx，否則代表的是客戶端。后面遠程的含義與之類似，不再解釋。

%l：遠程邏輯用戶名，一律是-，可以忽略。

%u：授權(quán)的遠程用戶名，如果沒有，則是-。

%t：訪問的時間。

%r：請求的第一行，即請求方法（Get/Post 等）、URI 及協(xié)議。

%s：響應(yīng)狀態(tài)，200、404等等。

%b：響應(yīng)的數(shù)據(jù)量，不包括請求頭，如果為0，則是-。

例如，下面是訪問日志中的一條記錄

pattern的配置中，除了上述各項，還有一個非常常用的選項是%D，含義是請求處理的時間（單位是毫秒），對于統(tǒng)計分析請求的處理速度幫助很大。

開發(fā)人員可以充分利用訪問日志，來分析問題、優(yōu)化應(yīng)用。例如，分析訪問日志中各個接口被訪問的比例，不僅可以為需求和運營人員提供數(shù)據(jù)支持，還可以使自己的優(yōu)化有的放矢；分析訪問日志中各個請求的響應(yīng)狀態(tài)碼，可以知道服務(wù)器請求的成功率，并找出有問題的請求；分析訪問日志中各個請求的響應(yīng)時間，可以找出慢請求，并根據(jù)需要進行響應(yīng)時間的優(yōu)化。