Tomcat源码分析之整体架构
来源于url:http://sh.qihoo.com/96b0a3290a643d75e?refer_scene=&scene=2&sign=360_79aabe15&uid=411dec71cbf4bf456fa5595ee74bc942
本章结构如下：

前言

Tomcat顶层结构
Server
Service
Connector
Container
Tomncat启动流程

一、前言

一般而言，对于一个复杂的系统，直接扎进去看源码会是很难受的，会浪费大量的时间和脑细胞，却得不到理想的效果。

这个时候，策略很重要，应该明白，越是复杂的东西，越会有良好的逻辑和层次，否则开发者自己估计过段时间怕也搞不清了。

tomcat是一个很大的系统，有复杂的结构，想要了解它，就应该顺着开发者设计之初的思路来，先了解整体的结构，对整体有了一定的掌控后，再逐个分析，了解感兴趣的细节。

二、Tomcat顶层结构

先上一张图：

这里写图片描述
上图大概展示了tomcat的结构，下面先简单介绍各个模块：

Server：服务器的意思，代表整个tomcat服务器，一个tomcat只有一个Server；
Service：Server中的一个逻辑功能层，一个Server可以包含多个Service；
Connector：称作连接器，是Service的核心组件之一，一个Service可以有多个Connector，主要是连接客户端请求；
Container：Service的另一个核心组件，按照层级有Engine，Host，Context，Wrapper四种，一个Service只有一个Engine，其主要作用是执行业务逻辑；
Jasper：JSP引擎；
Session：会话管理；
…
上面简单列了tomcat的模块结构，下面结合配置文件更加具体一点来分析，当然更多是集中在Connector和Container两个组件上，毕竟这是两个核心组件，后续的内容也会更多集中在这两个组件上面。

先将conf/server.xml配置文件内容贴出供参考（注释部分没有贴出）：

这里写图片描述

StandardServer实现Server很好理解，tomcat为所有的组件都提供了生命周期管理，继承LifecycleMBeanBase则跟tomcat中的生命周期机制有关，后续文章会有介绍。

扫描二维码关注公众号，回复： 2183465 查看本文章

三、Service

可以想象，一个Server服务器，它最基本的功能肯定是：

接收客户端的请求，然后解析请求，完成相应的业务逻辑，然后把处理后的结果返回给客户端，一般会提供两个节本方法，一个start打开服务Socket连接，监听服务端口，一个stop停止服务释放网络资源。

这时的服务器就是一个Server类：

这里写图片描述
如何实现这个简单的服务器，看过《深入剖析tomcat》的应都知道，这部分代码之前也敲过，在github上（https://github.com/w1992wishes/tomcat-work），其实就是在一个端口上监听Socket请求，然后解析请求，返回处理结果。

但如果将请求监听和请求处理放在一起，扩展性会变差，毕竟网络协议不止HTTP一种，如果想适配多种网络协议，请求处理又相同，这时就无能为力了，tomcat的设计大师不会采取这种做法，而是将请求监听和请求处理分开为两个模块，分别是Connector和Container，Connector负责处理请求监听，Container负责处理请求处理。

但显然tomcat可以有多个Connector，同时Container也可以有多个。那这就存在一个问题，哪个Connector对应哪个Container，提供复杂的映射吗？相信看过server.xml文件的人已经知道了tomcat是怎么处理的了。

没错，Service就是这样来的。在conf/server.xml文件中，可以看到Service组件包含了Connector组件和Engine组件（前面有提过，Engine就是一种容器），即Service相当于Connector和Engine组件的包装器，将一个或者多个Connector和一个Engine建立关联关系。在默认的配置文件中，定义了一个叫Catalina 的服务，它将HTTP/1.1和AJP/1.3这两个Connector与一个名为Catalina 的Engine关联起来。

一个Server可以包含多个Service（它们相互独立，只是公用一个JVM及类库），一个Service负责维护多个Connector和一个Container。

其标准实现是StandardService，UML类图如下：
这里写图片描述

这时tomcat就是这样了：
这里写图片描述

四、Connector

前面介绍过Connector是连接器，用于接受请求并将请求封装成Request和Response，然后交给Container进行处理，Container处理完之后在交给Connector返回给客户端。

一个Connector会监听一个独立的端口来处理来自客户端的请求。server.xml默认配置了两个Connector：
这里写图片描述

这里先简单介绍Connector，后续会详细分析。

Connector使用ProtocolHandler来处理请求的，不同的ProtocolHandler代表不同的连接类型，比如：Http11Protocol使用的是普通Socket来连接的（tomcat9已经删除了这个类，不再采用BIO的方式），Http11NioProtocol使用的是NioSocket来连接的。

其中ProtocolHandler由包含了三个部件：Endpoint、Processor、Adapter。

Endpoint用来处理底层Socket的网络连接，Processor用于将Endpoint接收到的Socket封装成Request（这个Request和ServletRequest无关），Adapter充当适配器，用于将Request转换为ServletRequest交给Container进行具体的处理。
Endpoint由于是处理底层的Socket网络连接，因此Endpoint是用来实现TCP/IP协议的，而Processor用来实现HTTP协议的，Adapter将请求适配到Servlet容器进行具体的处理。
Endpoint的抽象实现AbstractEndpoint里面定义的Acceptor和AsyncTimeout两个内部类和一个Handler接口。Acceptor用于监听请求，AsyncTimeout用于检查异步Request的超时，Handler用于处理接收到的Socket，在内部调用Processor进行处理。

先不用太纠结，了解Connector是做什么的就可以，后续再深入。

五、Container

tomcat的container层次如下：
这里写图片描述

5.1、Engine

一个Service中有多个Connector和一个Engine，Engine表示整个Servlet引擎，一个Engine下面可以包含一个或者多个Host，即一个Tomcat实例可以配置多个虚拟主机，默认的情况下 conf/server.xml 配置文件中定义了一个名为Catalina的Engine。

Engine的UML类图如下：
这里写图片描述

ContainerBase和LifecycleBase都是抽象出来的公共层。

5.2、Host

Host，代表一个站点，也可以叫虚拟主机，一个Host可以配置多个Context，在server.xml文件中的默认配置为, 其中appBase=webapps，也就是\webapps目录，unpackingWARS=true 属性指定在appBase指定的目录中的war包都自动的解压，autoDeploy=true 属性指定对加入到appBase目录的war包进行自动的部署。

一个Engine包含多个Host的设计，使得一个服务器实例可以承担多个域名的服务，是很灵活的设计。

其标准实现继承图如下：
这里写图片描述

5.3、Context

Context，代表一个应用程序，就是日常开发中的web程序，或者一个WEB-INF目录以及下面的web.xml文件，换句话说每一个运行的webapp最终都是以Context的形式存在，每个Context都有一个根路径和请求路径；与Host的区别是Context代表一个应用，如，默认配置下webapps下的每个目录都是一个应用，其中ROOT目录中存放主应用，其他目录存放别的子应用，而整个webapps是一个站点。

在Tomcat中通常采用如下方式创建一个Context：

在\webapps 目录中创建一个目录dirname，此时将自动创建一个context，默认context的访问url为http://host:port/dirname，也可以通过在ContextRoot\META-INF 中创建一个context.xml文件，其中包含如下内容来指定应用的访问路径：
在server.xml文件中增加context 元素，如下：

其标准实现类图如下：