作为我们最常用的Java服务器软件之一,tomcat
已经经过了十多年的迭代,成为我们服务器上非常重要的一部分。那么tomcat
是如何启动的呢?
想要了解tomcat
是如何启动,那么就需要先明白tomcat
的设计。
理解tomcat的设计
如果要理解tomcat
的设计,我觉得就需要从server.xml
说起了,在tomcat
中,最常见的配置就是server.xml
了,以下是一份简化过的server.xml
:
……
在以上配置中可以看出有以下这个结构的标签:
.
└── server
├── listener
└── service
├── connector
├── engine
│ ├── host
│ │ └── value
│ └── realm
└── executor
实际上,这里面的每一个标签代表了tomcat架构中的一个接口类(interface),他们的对应关系:
server --> org.apache.catalina.Server
service --> org.apache.catalina.Service
connector --> org.apache.catalina.connector.Connector
engine --> org.apache.catalina.Engine
host --> org.apache.catalina.Host
realm --> org.apache.catalina.Realm
executor --> org.apache.catalina.Executor
Server
首先我们来分析下server
,这个类代表了一个tomcat
服务器(servlet容器)。他可以包含多个service
服务。
Service
而service
则包含了一个或多个Connector
和一个Container
。
在tomcat的容器设计中,将网络请求跟具体具体请求处理分别由Connector
和Container
来处理:
-
Connector
:负责Socket
网络连接的处理。 -
Container
:负责处理具体的servlet
请求。
Container
实际上Container
包含了一类接口,包括:
标签 | 描述 |
---|---|
Engine | 表示Servlet引擎,作为最高级的容器,Engine是获取目标容器的入口 |
Host | Servlet引擎中的虚拟机,多域名也是基于host实现的 |
Context | 在Servlet规范中,一个Context,表示一个独立的Web 应用 |
Wrapper | 表示web应用中定义的Servlet |
也就是engine
和它包含的所有的标签代表的类,Container
可以添加或者包含子容器,所以service
类中仅持有了engine
。
每一个Container
对象都会有一个对应的StandardValve
, Pipeline
接口会维护一条Value
的职责链,将请求依次传递到每一级的容器中处理。
Connector
之前的文字中已经提到,Connector
是负责处理Socket
端口信息的组件。
作为一个网络服务器,tomcat支持了多种协议(HTTP,AJP,WEBSOCKET等),多种通信方式(BIO,NIO,APR等)。在Connector
中这些部分的处理,都被封装到了ProtocolHandler
这个类的属性里面,它表示一个协议处理器,针对不同的协议和I/O方式,会有不同的实现。
Coyote
是tomcat
默认的连接器(Connector
)实现框架,作为独立的模块它只负责具体协议的处理和I/O处理,与servlet没有直接的联系,所以理论上,我们是可以更换成我们自己所希望的实现方式的。
Executor
每一个service
都会维护一个共享的线程池,tomcat监听socket端口,当接收到客户端请求后,会创建请求处理对象,并交由线程池处理,由此并发处理客户端请求。
Listener
在server
标签下,还有一个标签listener
,它的表示监听器,它会捕获存在节点的事件(比如在上面的配置中就配置在server标签,则表示这个listener存在server节点上),并根据具体实现执行相对应的操作。
了解了每个标签的意义之后,我们就大概了解tomcat启动之后,各个部分是如何运作的了。
tomcat的启动过程
我们使用tomcat
的时候,一般在Linux
服务器上都是使用catalina.sh
脚本来启动服务器的。一般启动的命令:
./catalina.sh start
这句脚本在执行什么呢?打开脚本,定位到start子命令的位置,最关键的启动命令如下:
shift
touch "$CATALINA_OUT"
if [ "$1" = "-security" ] ; then
if [ $have_tty -eq 1 ]; then
echo "Using Security Manager"
fi
shift
eval $_NOHUP "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
-Djava.endorsed.dirs="\"$JAVA_ENDORSED_DIRS\"" -classpath "\"$CLASSPATH\"" \
-Djava.security.manager \
-Djava.security.policy=="\"$CATALINA_BASE/conf/catalina.policy\"" \
-Dcatalina.base="\"$CATALINA_BASE\"" \
-Dcatalina.home="\"$CATALINA_HOME\"" \
-Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
org.apache.catalina.startup.Bootstrap "$@" start \
>> "$CATALINA_OUT" 2>&1 "&"
else
eval $_NOHUP "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
-Djava.endorsed.dirs="\"$JAVA_ENDORSED_DIRS\"" -classpath "\"$CLASSPATH\"" \
-Dcatalina.base="\"$CATALINA_BASE\"" \
-Dcatalina.home="\"$CATALINA_HOME\"" \
-Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
org.apache.catalina.startup.Bootstrap "$@" start \
>> "$CATALINA_OUT" 2>&1 "&"
fi
if [ ! -z "$CATALINA_PID" ]; then
echo $! > "$CATALINA_PID"
fi
echo "Tomcat started."
从中可以看出catalina.sh
启动tomcat是执行了org.apache.catalina.startup.Bootstrap
的start()
方法,start()
方法启动了Catalina
类的线程。
/**
* Start the Catalina daemon.
* @throws Exception Fatal start error
*/
public void start()
throws Exception {
if( catalinaDaemon==null ) init();
Method method = catalinaDaemon.getClass().getMethod("start", (Class [] )null);
method.invoke(catalinaDaemon, (Object [])null);
}
tomcat
提供了Bootstrap
类作为服务器的命令处理器,由它创建Catalina
实例并根据外部传递的命令控制Catalina
的启动和关闭。Bootstrap
本身是一个单独的JAR
包被放到$CATALINA_HOME/bin
目录下面。而从上面的源码中会看到,Bootstrap
总是通过Java的反射操作Catalina
,因为启动服务器这个过程对运行时没有多大的影响,这种方式实现了程序启动和服务核心代码的解耦。
而这种解耦带来的另外一个优势是tomcat在这一步,可以灵活地定制自己的类加载器,根据servlet规范
每一个Web应用都有独立的类加载器实例。
再回到Catalina
,它通过Digester
框架(XML解析框架)定义转换规则,将server.xml
中的配置标签都转换成对应的类实例,一个tomcat
程序这样就启动完毕了。
总结
tomcat
的开发严格遵守了面向接口开发的设计规范,其软件的架构设计,启动的方式,配置文件的读取方式都非常值得我们借鉴到我们自己的系统平台中,我觉得能把握好微观的设计,才能做出更好的平台系统,正像 @左耳朵耗子 陈皓老师在博客中说的: "如果你要做好架构,首先你得把计算机体系结构以及很多老古董的基础技术吃透了。"