详解server.xml

作者: wencai | 来源:发表于2017-12-19 00:22 被阅读0次

转载：

https://www.cnblogs.com/kismetv/p/7228274.html#title1

http://blog.csdn.net/weinianjie1/article/details/7954425

一、前言

Tomcat是开源的轻量级Web应用服务器。server.xml中的每个元素都对应tomcat中的一个组件；通过对xml文件中元素的配置，可实现对tomcat中各个组件的控制。

二、元素分类和整体结构

1.server.xml整体结构

<Host>

</Host>

</Engine>

</Service>

</Server>

2.元素分类

server.xml中的元素可分为以下四类：

1）顶层元素：<Server>和<Service>

<Server>是整个配置文件的根元素，<Service>则代表一个Engine元素及一组与其关联的Connector元素。

2）连接器：<Connector>

代表了外部客户端发送请求到特定Service的接口；同时也是外部客户端从特定Service接受响应的接口。

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

容器的功能是处理Connector接受进来的请求，并产生相应的响应。这三者是父子关系。一个Engine可处理Service中的所有请求，一个Host可处理发向一个特定虚拟主机的所有请求，一个Context组件可处理一个特定Web应用的所有请求。

4）内嵌组件：可内嵌到容器中的组件。以上6个是tomcat最核心的组件，其他组件都归为内嵌组件。

三、核心组件

1.Server

代表整个tomcat容器。一个Server元素中可以有一个或多个Service元素。Server的主要任务，就是提供一个接口让客户端能访问到这个Service集合，同时维护它所包含的所有的Service的生命周期。

shutdown属性：关闭Server的指令；

port属性：Server接受shutdown指令的端口，设为-1可禁掉该端口

2.Service

作用是把Connector和Engine组装在一起，对外提供服务。一个Service可包含多个Connector，但只能包含一个Engine；Connector的作用是从客户端接受请求，Engine的作用是处理接受进来的请求。

3.Connector

主要作用是接受连接请求，创建Request和Response对象用于和请求端交换数据；然后分配线程让Engine来处理这个请求，并把产生的Request和Response对象传给Engine。

通过配置Connector，可控制请求Service的协议及端口号。

1）举例1：

客户端可以通过8080端口使用http协议访问tomcat，protocol属性规定了请求的协议，port规定了请求的端口号，redirectPort表示强制要求https而请求是http时，重定向至端口号为8443的Connector。

2）举例2：

客户端可以通过8009端口使用AJP协议访问Tomcat。AJP协议负责和其他的HTTP服务器(如Apache)建立连接；在把Tomcat与其他HTTP服务器集成时，就需要这个连接器。

4.Engine

Engine组件是Service组件中的请求处理组件。在Service组件中有且只有一个。Engine组件从一个或多个Connector中接受请求并处理，并将完成的响应返回给Connector，最终传递给客户端。

name：用于日志和错误信息，在整个Server中应该唯一。

defaultHost：指定了默认的host名称，当发往本机的请求指定的host名称不存在时，一律使用defaultHost指定的host进行处理；因此，defaultHost的值，必须与Engine中的一个Host组件的name属性值匹配。

5.Host

1）Engine与Host

Host是Engine的子容器。Engine组件中可以内嵌一个或多个Host组件，每个Host组件代表Engine中的一个虚拟主机。Host组件至少有一个，且其中一个的name必须与Engine组件的defaultHost属性相匹配。

2）Host的作用

Host虚拟主机的作用，是运行多个Web应用(一个Context代表一个Web应用 )，并负责安装、展开、启动和结束每个Web应用。

Host组件代表的虚拟主机，对应了服务器中一个网络名实体(如"www.test.com"或IP地址"116.25.25.25")，为了使用户可以通过网络名连接Tomcat服务器，这个名字应该在DNS服务器上注册。

客户端通常用主机名来标识他们希望连接的服务器；该主机名也会包含在HTTP请求头中。Tomcat从HTTP头中提取主机名，寻找名称匹配的主机。如果没有匹配，请求将转发至默认主机。因此默认主机不需要再DNS服务器中注册。

3）Host的配置

name：虚拟主机名。一个Engine中有且仅有一个Host组件的name属性与Engine组件的defaultHost属性相匹配；

unpackWARs：是否将代表Web应用的WAR文件解压；true：通过解压后的文件结构运行该Web应用；false：直接使用WAR文件运行web应用；

Host的autoDeploy和、APPBase、xmlBase、deployOnStartup属性，与Host内Web应用的自动部署有关。

6.Context

1）Context元素代表在特定虚拟主机上运行的一个Web应用。每个Web应用基于war文件或war文件解压后对应的目录。

Context是Host的子容器，每个Host可以定义任意多个Context元素。

2）Web应用自动部署

（1）Host的配置

要开启Web应用的自动部署，需要配置所在的虚拟主机；配置方式就是前面提到的Host元素的deployOnStartup和autoDeploy属性。如果这俩属性设为true，则tomcat启动自动部署。二者主要区别在于，deployOnStartup为true时，tomcat在启动时检查web应用；autoDeploy为true时，tomcat在运行时定期检查新的web应用或web应用的更新。

自动部署依赖于检查是否有新的或更改过的web应用，而Host元素的appBase和xmlBase设置了检查web应用更新的目录。

appBase：指定web应用所在的目录，默认值是webapps，这是一个相对路径。

xmlBase：指定web应用的XML配置文件所在的目录。默认值为conf/<engine_name>/<host_name>。

（2）检查web应用更新

一个web应用可能包含以下文件：XML配置文件，WAR包，以及一个应用目录(该目录包含Web应用的文件结构)；其中XML文件位于xmlBase指定的目录，WAR包和应用目录位于appBase指定的目录。tomcat会扫描这俩属性配置的目录来检查应用更新。

（3）<Context>元素的配置

docBase：指定web应用使用的war包路径，或应用目录。需注意的是：在自动部署场景下(配置文件位于xmlBase中)，docBase不在appBase目录中，才需要指定。

path：指定了访问该web应用的上下文路径，当请求到来时，tomcat根据web应用的path属性与URI的匹配程度来选择web应用处理相应请求。如果一个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应用重新加载。开发环境设为true方便调试；生产环境设为true会给服务器带来性能压力。

（4）自动部署举例

最典型的自动部署，就是当我们安装完tomcat后，在webapps目录下有如下文件夹：

当启动tomcat后，可用http://localhost:8080/来访问tomcat，其实访问的就是ROOT对应的web应用；也可通过http://localhost:8080/docs来访问docs应用，同理可访问examples/host-manager/这几个web应用。

http://localhost:8080/：ROOT是tomcat中的一个项目，最后的“/”表示http的根-ROOT。

3）server.xml中静态部署web应用

除了自动部署，我们也可以在server.xml中通过<context>元素静态部署Web应用。静态部署和自动部署是可以共存的。因为server.xml不可动态加载资源，服务器一旦启动，要修改这个文件就得重启服务器才能重新加载。而自动部署可以在tomcat运行时通过定期的扫描来实现，不需重启服务器。

docBase：静态部署时，docBase可以在appBase目录下，也可不在。

path：静态部署时，可显示指定path属性，但仍受到严格限制：只有当自动部署关闭(deployOnStartup和autoDeploy都为false)或docBase不在appBase中时，才可设置path。

reloadable：用法与自动部署时相同。

四、配置多个服务

通过在Server中配置多个Service服务，可以实现通过不同的端口号来访问同一台机器上部署的不同Web应用。

五、其他组件

1.Listener

监听器。可在特定事件发生时执行特定的操作；被监听事件通常是tomcat的启动和停止。

2.GlobalNamingResources与Realm

Realm，可以把它理解成“域”；Realm提供了一种用户密码与web应用的映射关系，从而达到角色安全管理的作用。

3.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目录下，可以看到如下所示的日志文件。

（5）pattern：指定记录日志的格式

pattern的配置中，有一个非常有用的选项是%D，含义是请求处理的时间(单位是毫秒)，对于统计分析请求的处理速度帮助很大。

开发人员可以充分利用访问日志，来分析问题、优化应用。例如，分析访问日志中各个接口被访问的比例，不仅可以为需求和运营人员提供数据支持，还可以使自己的优化有的放矢；分析访问日志中各个请求的响应状态码，可以知道服务器请求的成功率，并找出有问题的请求；分析访问日志中各个请求的响应时间，可以找出慢请求，并根据需要进行响应时间的优化。

六、关于用tomcat部署多个应用的3种方法:

1.配置文件中使用多个Context元素。这种配置好处是这些应用公用Connector，也就是说访问端口是一样的，这样就可以都部署在80下了。

这样有一个要求，就是应用程序在设计的时候就支持Context，一些链接前面都先加上动态的应用名，而不是使用“/”这样的绝对路径。Context元素的path一定不要以“/”结尾，可以是""或者"/WEB1"这样的。

2.配置文件中使用多个Service元素。这种配置可以解决应用程序不支持动态应用名的情况，使用不同端口访问不同页面。

不过这样有时候也不是很顺利，由于一个tomcat的jvm对一个jni类只允许load一次，你多个应用如果同时load了某个jni的类则会部署失败。这种情况可以把这个类从项目里拿出来放到tomcat安装目录的lib下作为公用的。不过还是有点麻烦哈~

3.部署多个tomcat。这个一般是做集群的时候用的，不过你也可以用来部署多应用，只要调整下端口不冲突就行。