web服務器專題：tomcat（二）模塊組件與server.xml 配置文件

一個Server.xml的實例

<?xml version='1.0' encoding='utf-8'?>
<Server port="8005" shutdown="SHUTDOWN">
  <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <Listener className="org.apache.catalina.core.JasperListener" />
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
  <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />


  <GlobalNamingResources>
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml" />
  </GlobalNamingResources>
  <Service name="Catalina">
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
    <Engine name="Catalina" defaultHost="localhost">
      <Realm className="org.apache.catalina.realm.LockOutRealm">
        <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
               resourceName="UserDatabase"/>
      </Realm>
      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true">
        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log." suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %b" />
      </Host>
    </Engine>
  </Service>
</Server>

以上，即一個tomcat7的默認的server.xml配置文件，整個配置文件，我們先整體梳理一下以上的核心標簽結構：

<Server>
  <Service>
    <Connector />
    <Connector />
    <Engine>
      <Host>
         <Context />
      </Host>
    </Engine>
  <Service>
</Server>

元素分類

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

（1）頂層元素：<Server>和<Service>

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

（2）連接器：<Connector>

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

（3）容器：<Engine><Host><Context>

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

（4）內嵌組件：可以內嵌到容器中的組件。

實際上，Server、Service、Connector、Engine、Host和Context是最重要的最核心的Tomcat組件，其他組件都可以歸為內嵌組件。

組件及其元素詳解

1、Server

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

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

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：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000"   redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

（1）通過配置第1個Connector，客戶端可以通過8080端口號使用http協議訪問Tomcat。其中，protocol屬性規定了請求的協議，port規定了請求的端口號，redirectPort表示當強制要求https而請求是http時，重定向至端口號為8443的Connector，connectionTimeout表示連接的超時時間。

在這個例子中，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等集成的原理如下圖。

4、Engine

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

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

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

 <Engine name="Catalina" defaultHost="localhost">

其中，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的配置如下：

<Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true">

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

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_name>/<host_name>，例如第一部分的例子中，主機localhost的xmlBase的默認值是$TOMCAT_HOME/conf/Catalina/localhost。

檢查Web應用更新

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

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

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

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

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

<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。

（3）server.xml中靜態部署Web應用

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

server.xml中使用Context元素配置Web應用，Context元素應該位于Host元素中。

例：

docBase：靜態部署時，docBase可以在appBase目錄下，也可以不在；本例中，docBase不在appBase目錄下。

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

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

7、其他組件

　　1、Listener

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

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

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

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組件：

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

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

核心組件間的關聯及工作流程

整體關系

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

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

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

請求的處理

當請求被發送到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應用

Tomcat根據應用的 path屬性與URI的匹配程度來選擇Web應用處理相應請求，詳細見上文<Context>元素的配置

例如：

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

配置多個服務

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

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

（1）復制<Service>元素，放在當前<Service>后面。

（2）修改端口號：根據需要監聽的端口號修改<Connector>元素的port屬性；必須確保該端口沒有被其他進程占用，否則Tomcat啟動時會報錯，而無法通過該端口訪問Web應用。

例子：

下一篇：web服務器專題：tomcat（三）tomcat-users.xml 配置文件

posted @ 2020-12-10 14:16 糖拌西紅柿閱讀(314) 評論(0) 收藏舉報

刷新頁面返回頂部

糖拌西紅柿

web服務器專題：tomcat（二）模塊組件與server.xml 配置文件

web服務器專題：tomcat（二）模塊組件與server.xml 配置文件

一個Server.xml的實例

元素分類

組件及其元素詳解

1、Server

2、Service

3、Connector

4、Engine

5、Host

（1）Engine與Host

（2）Host的作用

（3）Host的配置

6、Context

（1）Context的作用

（2）Web應用自動部署

（3）server.xml中靜態部署Web應用

7、其他組件

1、Listener

2、GlobalNamingResources與Realm

核心組件間的關聯及工作流程

整體關系

請求的處理

（1）根據協議和端口號選定Service和Engine

（2）根據域名或IP地址選定Host

（3）根據URI選定Context/Web應用

例如：

配置多個服務

公告

　　1、Listener