Tomcat 的 Server 文件配置詳解!

Tomcat 的 Server 文件配置詳解!



前言

Tomcat隸屬於Apache基金會,是開源的輕量級Web應用服務器,使用非常廣泛。server.xml是Tomcat中最重要的配置文件,server.xml的每一個元素都對應了Tomcat中的一個組件;通過對xml文件中元素的配置,可以實現對Tomcat中各個組件的控制。因此,學習server.xml文件的配置,對於瞭解和使用Tomcat至關重要。

本文將通過實例,介紹server.xml中各個組件的配置,並詳細說明Tomcat各個核心組件的作用以及各個組件之間的相互關係。

說明:由於server.xml文件中元素與Tomcat中組件的對應關係,後文中為了描述方便,“元素”和“組件”的使用不嚴格區分。

一、一個server.xml配置實例

server.xml位於$TOMCAT_HOME/conf目錄下;下面是一個server.xml實例。後文中將結合該實例講解server.xml中,各個元素的含義和作用;在閱讀後續章節過程中,可以對照該xml文檔便於理解。

Tomcat 的 Server 文件配置詳解!


二、server.xml文檔的元素分類和整體結構

1、整體結構

server.xml的整體結構如下:

Tomcat 的 Server 文件配置詳解!


該結構中只給出了Tomcat的核心組件,除了核心組件外,Tomcat還有一些其他組件,下面介紹一下組件的分類。

2、元素分類

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

(1)頂層元素:<server>和<service>/<server>

<server>元素是整個配置文件的根元素,<service>元素則代表一個Engine元素以及一組與之相連的Connector元素。/<service>/<server>

(2)連接器:<connector>

<connector>代表了外部客戶端發送請求到特定Service的接口;同時也是外部客戶端從特定Service接收響應的接口。/<connector>

(3)容器:<engine><host><context>/<host>/<engine>

容器的功能是處理Connector接收進來的請求,併產生相應的響應。Engine、Host和Context都是容器,但它們不是平行的關係,而是父子關係:Engine包含Host,Host包含Context。一個Engine組件可以處理Service中的所有請求,一個Host組件可以處理發向一個特定虛擬主機的所有請求,一個Context組件可以處理一個特定Web應用的所有請求。

(4)內嵌組件:可以內嵌到容器中的組件。實際上,Server、Service、Connector、Engine、Host和Context是最重要的最核心的Tomcat組件,其他組件都可以歸為內嵌組件。

下面將詳細介紹Tomcat中各個核心組件的作用,以及相互之間的關係。點此查看一分鐘配置tomcat的https教程。

三、核心組件

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

1、Server

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

在第一部分的例子中,在最外層有一個<server>元素,shutdown屬性表示關閉Server的指令;port屬性表示Server接收shutdown指令的端口號,設為-1可以禁掉該端口。/<server>

Server的主要任務,就是提供一個接口讓客戶端能夠訪問到這個Service集合,同時維護它所包含的所有的Service的聲明週期,包括如何初始化、如何結束服務、如何找到客戶端要訪問的Service。

2、Service

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

在第一部分的例子中,Server中包含一個名稱為“Catalina”的Service。實際上,Tomcat可以提供多個Service,不同的Service監聽不同的端口,後文會有介紹。

3、Connector

Connector的主要功能,是接收連接請求,創建Request和Response對象用於和請求端交換數據;然後分配線程讓Engine來處理這個請求,並把產生的Request和Response對象傳給Engine。

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

Tomcat 的 Server 文件配置詳解!


(1)通過配置第1個Connector,客戶端可以通過8080端口號使用http協議訪問Tomcat。其中,protocol屬性規定了請求的協議,port規定了請求的端口號,redirectPort表示當強制要求https而請求是http時,重定向至端口號為8443的Connector,connectionTimeout表示連接的超時時間。點此查看一分鐘配置tomcat的https教程。

在這個例子中,Tomcat監聽HTTP請求,使用的是8080端口,而不是正式的80端口;實際上,在正式的生產環境中,Tomcat也常常監聽8080端口,而不是80端口。這是因為在生產環境中,很少將Tomcat直接對外開放接收請求,而是在Tomcat和客戶端之間加一層代理服務器(如nginx),用於請求的轉發、負載均衡、處理靜態文件等;通過代理服務器訪問Tomcat時,是在局域網中,因此一般仍使用8080端口。

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

Tomcat 的 Server 文件配置詳解!


關於Connector的更多內容,可以參考我的另一篇文章:詳解tomcat的連接數與線程池

4、Engine

Engine組件在Service組件中有且只有一個;Engine是Service組件中的請求處理組件。Engine組件從一個或多個Connector中接收請求並處理,並將完成的響應返回給Connector,最終傳遞給客戶端。

前面已經提到過,Engine、Host和Context都是容器,但它們不是平行的關係,而是父子關係:Engine包含Host,Host包含Context。

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

Tomcat 的 Server 文件配置詳解!


其中,name屬性用於日誌和錯誤信息,在整個Server中應該唯一。defaultHost屬性指定了默認的host名稱,當發往本機的請求指定的host名稱不存在時,一律使用defaultHost指定的host進行處理;因此,defaultHost的值,必須與Engine中的一個Host組件的name屬性值匹配。

5、Host

(1)Engine與Host

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

(2)Host的作用

Host虛擬主機的作用,是運行多個Web應用(一個Context代表一個Web應用),並負責安裝、展開、啟動和結束每個Web應用。

Host組件代表的虛擬主機,對應了服務器中一個網絡名實體(如”www.javastack.cn”,或IP地址”116.25.25.25”);為了使用戶可以通過網絡名連接Tomcat服務器,這個名字應該在DNS服務器上註冊。

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

(3)Host的配置

在第一部分的例子中,Host的配置如下:

Tomcat 的 Server 文件配置詳解!


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

name屬性指定虛擬主機的主機名,一個Engine中有且僅有一個Host組件的name屬性與Engine組件的defaultHost屬性相匹配;一般情況下,主機名需要是在DNS服務器中註冊的網絡名,但是Engine指定的defaultHost不需要,原因在前面已經說明。

unpackWARs指定了是否將代表Web應用的WAR文件解壓;如果為true,通過解壓後的文件結構運行該Web應用,如果為false,直接使用WAR文件運行Web應用。

Host的autoDeploy和appBase屬性,與Host內Web應用的自動部署有關;此外,本例中沒有出現的xmlBase和deployOnStartup屬性,也與Web應用的自動部署有關;將在下一節(Context)中介紹。

6、Context

(1)Context的作用

Context元素代表在特定虛擬主機上運行的一個Web應用。在後文中,提到Context、應用或Web應用,它們指代的都是Web應用。每個Web應用基於WAR文件,或WAR文件解壓後對應的目錄(這裡稱為應用目錄)。

Context是Host的子容器,每個Host中可以定義任意多的Context元素。

在第一部分的例子中,可以看到server.xml配置文件中並沒有出現Context元素的配置。這是因為,Tomcat開啟了自動部署,Web應用沒有在server.xml中配置靜態部署,而是由Tomcat通過特定的規則自動部署。下面介紹一下Tomcat自動部署Web應用的機制。

(2)Web應用自動部署

Host的配置

要開啟Web應用的自動部署,需要配置所在的虛擬主機;配置的方式就是前面提到的Host元素的deployOnStartup和autoDeploy屬性。如果deployOnStartup和autoDeploy設置為true,則tomcat啟動自動部署:當檢測到新的Web應用或Web應用的更新時,會觸發應用的部署(或重新部署)。二者的主要區別在於,deployOnStartup為true時,Tomcat在啟動時檢查Web應用,且檢測到的所有Web應用視作新應用;autoDeploy為true時,Tomcat在運行時定期檢查新的Web應用或Web應用的更新。除此之外,二者的處理相似。

通過配置deployOnStartup和autoDeploy可以開啟虛擬主機自動部署Web應用;實際上,自動部署依賴於檢查是否有新的或更改過的Web應用,而Host元素的appBase和xmlBase設置了檢查Web應用更新的目錄。

其中,appBase屬性指定Web應用所在的目錄,默認值是webapps,這是一個相對路徑,代表Tomcat根目錄下webapps文件夾。

xmlBase屬性指定Web應用的XML配置文件所在的目錄,默認值為conf/<engine>/<host>,例如第一部分的例子中,主機localhost的xmlBase的默認值是$TOMCAT_HOME/conf/Catalina/localhost。/<host>/<engine>

檢查Web應用更新

一個Web應用可能包括以下文件:XML配置文件,WAR包,以及一個應用目錄(該目錄包含Web應用的文件結構);其中XML配置文件位於xmlBase指定的目錄,WAR包和應用目錄位於appBase指定的目錄。

Tomcat按照如下的順序進行掃描,來檢查應用更新:

A、掃描虛擬主機指定的xmlBase下的XML配置文件

B、掃描虛擬主機指定的appBase下的WAR文件

C、掃描虛擬主機指定的appBase下的應用目錄

<context>元素的配置/<context>

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

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

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

但是,需要注意的是,在自動部署場景下(配置文件位於xmlBase中),不能指定path屬性,path屬性由配置文件的文件名、WAR文件的文件名或應用目錄的名稱自動推導出來。如掃描Web應用時,發現了xmlBase目錄下的app1.xml,或appBase目錄下的app1.WAR或app1應用目錄,則該Web應用的path屬性是”app1”。如果名稱不是app1而是ROOT,則該Web應用是虛擬主機默認的Web應用,此時path屬性推導為””。

reloadable屬性指示tomcat是否在運行時監控在WEB-INF/classes和WEB-INF/lib目錄下class文件的改動。如果值為true,那麼當class文件改動時,會觸發Web應用的重新加載。在開發環境下,reloadable設置為true便於調試;但是在生產環境中設置為true會給服務器帶來性能壓力,因此reloadable參數的默認值為false。

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

Tomcat 的 Server 文件配置詳解!


在該例子中,docBase位於Host的appBase目錄之外;path屬性沒有指定,而是根據app1.xml自動推導為”app1”;由於是在開發環境下,因此reloadable設置為true,便於開發調試。

自動部署舉例

最典型的自動部署,就是當我們安裝完Tomcat後,$TOMCAT_HOME/webapps目錄下有如下文件夾:

Tomcat 的 Server 文件配置詳解!


當我們啟動Tomcat後,可以使用http://localhost:8080/來訪問Tomcat,其實訪問的就是ROOT對應的Web應用;我們也可以通過http://localhost:8080/docs來訪問docs應用,同理我們可以訪問examples/host-manager/manager這幾個Web應用。

(3)server.xml中靜態部署Web應用

除了自動部署,我們也可以在server.xml中通過<context>元素靜態部署Web應用。靜態部署與自動部署是可以共存的。在實際應用中,並不推薦使用靜態部署,因為server.xml 是不可動態重加載的資源,服務器一旦啟動了以後,要修改這個文件,就得重啟服務器才能重新加載。而自動部署可以在Tomcat運行時通過定期的掃描來實現,不需要重啟服務器。/<context>

server.xml中使用Context元素配置Web應用,Context元素應該位於Host元素中。舉例如下:

Tomcat 的 Server 文件配置詳解!


docBase:靜態部署時,docBase可以在appBase目錄下,也可以不在;本例中,docBase不在appBase目錄下。

path:靜態部署時,可以顯式指定path屬性,但是仍然受到了嚴格的限制:只有當自動部署完全關閉(deployOnStartup和autoDeploy都為false)或docBase不在appBase中時,才可以設置path屬性。在本例中,docBase不在appBase中,因此path屬性可以設置。

reloadable屬性的用法與自動部署時相同。

四、核心組件的關聯

1、整體關係

核心組件之間的整體關係,在上一部分有所介紹,這裡總結一下:

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

Service在Connector和Engine外面包了一層,把它們組裝在一起,對外提供服務。一個Service可以包含多個Connector,但是隻能包含一個Engine;Connector接收請求,Engine處理請求。

Engine、Host和Context都是容器,且 Engine包含Host,Host包含Context。每個Host組件代表Engine中的一個虛擬主機;每個Context組件代表在特定Host上運行的一個Web應用。

2、如何確定請求由誰處理?

當請求被髮送到Tomcat所在的主機時,如何確定最終哪個Web應用來處理該請求呢?

(1)根據協議和端口號選定Service和Engine

Service中的Connector組件可以接收特定端口的請求,因此,當Tomcat啟動時,Service組件就會監聽特定的端口。在第一部分的例子中,Catalina這個Service監聽了8080端口(基於HTTP協議)和8009端口(基於AJP協議)。當請求進來時,Tomcat便可以根據協議和端口號選定處理請求的Service;Service一旦選定,Engine也就確定。

通過在Server中配置多個Service,可以實現通過不同的端口號來訪問同一臺機器上部署的不同應用。

(2)根據域名或IP地址選定Host

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

(3)根據URI選定Context/Web應用

這一點在Context一節有詳細的說明:Tomcat根據應用的 path屬性與URI的匹配程度來選擇Web應用處理相應請求,這裡不再贅述。

(4)舉例

以請求http://localhost:8080/app1/index.html為例,首先通過協議和端口號(http和8080)選定Service;然後通過主機名(localhost)選定Host;然後通過uri(/app1/index.html)選定Web應用。

3、如何配置多個服務

通過在Server中配置多個Service服務,可以實現通過不同的端口號來訪問同一臺機器上部署的不同Web應用。

在server.xml中配置多服務的方法非常簡單,分為以下幾步:

(1)複製<service>元素,放在當前<service>後面。/<service>/<service>

(2)修改端口號:根據需要監聽的端口號修改<connector>元素的port屬性;必須確保該端口沒有被其他進程佔用,否則Tomcat啟動時會報錯,而無法通過該端口訪問Web應用。/<connector>

以Win7為例,可以用如下方法找出某個端口是否被其他進程佔用:netstat -aon|findstr "8081"發現8081端口被PID為2064的進程佔用,tasklist |findstr "2064"發現該進程為FrameworkService.exe(這是McAfee殺毒軟件的進程)。

Tomcat 的 Server 文件配置詳解!


(3)修改Service和Engine的name屬性

(4)修改Host的appBase屬性(如webapps2)

(5)Web應用仍然使用自動部署

(6)將要部署的Web應用(WAR包或應用目錄)拷貝到新的appBase下。

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

Tomcat 的 Server 文件配置詳解!


再將原webapps下的docs目錄拷貝到webapps2中,則通過如下兩個接口都可以訪問docs應用:

http://localhost:8080/docs/

http://localhost:8084/docs/

五、其他組件

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

1、Listener

Tomcat 的 Server 文件配置詳解!

Listener(即監聽器)定義的組件,可以在特定事件發生時執行特定的操作;被監聽的事件通常是Tomcat的啟動和停止。

監聽器可以在Server、Engine、Host或Context中,本例中的監聽器都是在Server中。實際上,本例中定義的6個監聽器,都只能存在於Server組件中。監聽器不允許內嵌其他組件。

監聽器需要配置的最重要的屬性是className,該屬性規定了監聽器的具體實現類,該類必須實現了org.apache.catalina.LifecycleListener接口。

點此查看一分鐘配置tomcat的https教程。

下面依次介紹例子中配置的監聽器:

  • VersionLoggerListener:當Tomcat啟動時,該監聽器記錄Tomcat、Java和操作系統的信息。該監聽器必須是配置的第一個監聽器。
  • AprLifecycleListener:Tomcat啟動時,檢查APR庫,如果存在則加載。APR,即Apache Portable Runtime,是Apache可移植運行庫,可以實現高可擴展性、高性能,以及與本地服務器技術更好的集成。
  • JasperListener:在Web應用啟動之前初始化Jasper,Jasper是JSP引擎,把JVM不認識的JSP文件解析成java文件,然後編譯成class文件供JVM使用。
  • JreMemoryLeakPreventionListener:與類加載器導致的內存洩露有關。
  • GlobalResourcesLifecycleListener:通過該監聽器,初始化< GlobalNamingResources>標籤中定義的全局JNDI資源;如果沒有該監聽器,任何全局資源都不能使用。< GlobalNamingResources>將在後文介紹。
  • ThreadLocalLeakPreventionListener:當Web應用因thread-local導致的內存洩露而要停止時,該監聽器會觸發線程池中線程的更新。當線程執行完任務被收回線程池時,活躍線程會一個一個的更新。只有當Web應用(即Context元素)的renewThreadsWhenStoppingContext屬性設置為true時,該監聽器才有效。

2、GlobalNamingResources與Realm

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

Tomcat 的 Server 文件配置詳解!


Realm,可以把它理解成“域”;Realm提供了一種用戶密碼與web應用的映射關係,從而達到角色安全管理的作用。在本例中,Realm的配置使用name為UserDatabase的資源實現。而該資源在Server元素中使用GlobalNamingResources配置:

Tomcat 的 Server 文件配置詳解!


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

關於Tomcat域管理的更多內容,可以參考:Realm域管理

3、Valve

在第一部分的例子中,Host元素內定義了Valve組件:

Tomcat 的 Server 文件配置詳解!


單詞Valve的意思是“閥門”,在Tomcat中代表了請求處理流水線上的一個組件;Valve可以與Tomcat的容器(Engine、Host或Context)關聯。

不同的Valve有不同的特性,下面介紹一下本例中出現的AccessLogValve。

AccessLogValve的作用是通過日誌記錄其所在的容器中處理的所有請求,在本例中,Valve放在Host下,便可以記錄該Host處理的所有請求。AccessLogValve記錄的日誌就是訪問日誌,每天的請求會寫到一個日誌文件裡。AccessLogValve可以與Engine、Host或Context關聯;在本例中,只有一個Engine,Engine下只有一個Host,Host下只有一個Context,因此AccessLogValve放在三個容器下的作用其實是類似的。

本例的AccessLogValve屬性的配置,使用的是默認的配置;下面介紹AccessLogValve中各個屬性的作用:

(1)className:規定了Valve的類型,是最重要的屬性;本例中,通過該屬性規定了這是一個AccessLogValve。

(2)directory:指定日誌存儲的位置,本例中,日誌存儲在$TOMCAT_HOME/logs目錄下。

(3)prefix:指定了日誌文件的前綴。

(4)suffix:指定了日誌文件的後綴。通過directory、prefix和suffix的配置,在$TOMCAT_HOME/logs目錄下,可以看到如下所示的日誌文件。

Tomcat 的 Server 文件配置詳解!


(5)pattern:指定記錄日誌的格式,本例中各項的含義如下:

  • %h:遠程主機名或IP地址;如果有nginx等反向代理服務器進行請求分發,該主機名/IP地址代表的是nginx,否則代表的是客戶端。後面遠程的含義與之類似,不再解釋。
  • %l:遠程邏輯用戶名,一律是”-”,可以忽略。
  • %u:授權的遠程用戶名,如果沒有,則是”-”。
  • %t:訪問的時間。
  • %r:請求的第一行,即請求方法(get/post等)、uri、及協議。
  • %s:響應狀態,200,404等等。
  • %b:響應的數據量,不包括請求頭,如果為0,則是””-。

例如,下面是訪問日誌中的一條記錄:

Tomcat 的 Server 文件配置詳解!


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

開發人員可以充分利用訪問日誌,來分析問題、優化應用。例如,分析訪問日誌中各個接口被訪問的比例,不僅可以為需求和運營人員提供數據支持,還可以使自己的優化有的放矢;分析訪問日誌中各個請求的響應狀態碼,可以知道服務器請求的成功率,並找出有問題的請求;分析訪問日誌中各個請求的響應時間,可以找出慢請求,並根據需要進行響應時間的優化。


分享到:


相關文章: