tomcat 架构解析01-总体架构、启动和请求处理流程

总体架构

tomcat服务器设计图如下：

以下逐个说明每个类和接口的意义
server表示整个Servelet容器，每启动一个tomcat进程只有一个Server实例
Connector tomcat连接器，用于监听并转化用户端Socket请求，将读取到的请求交给Container处理，可以支持不同的协议及IO实现
Container 处理用户端请求并返回响应对象的一类对象，tomcat中包含不同级别的容器：Engine（整个tomcat容器对象）、Host（虚拟主机）、Context(一个web应用) 、Wrapper（一个Servelet）
Engine 表示整个Servlet引擎，是最高级的容器对象，是获取目标容器的入口，它不直接处理用户请求。
Host 表示虚拟主机，与一个服务器的域名有关。处理针对域名请求的容器
Context 表示一个应用，可能包含一组servlet结合
Wrapper 表示应用中定义的某一个Servlet示例。
当用户发起一个请求访问www.baidu.com时，那么首先根据域名询问总引擎Engine找到对应的虚拟主机，再找到处理该域名请求的应用，最后根据url找到处理请求的具体servlet，最终处理用户请求并返回结果。
Service： Service包含一个或多个Connetcor 和 一个Container，用来接受用户请求并返回处理结果，server 中可以包含一个或多个service
Executor 表示tomcat组件间可以共享的线程池。

以下概要分析上述各组件的设计由来

server

从最基本的功能来讲，tomcat作为web容器，就是要实现接收用户请求并返回响应结果的基本功能。从程序开发角度来讲直接通过Socket监听一个端口就能实现该功能。通过Start()来启动服务器监听端口，stop停止服务释放资源。设计方案如下：

connector 和 Container/Engine

上述方案中将通过单线程监听和处理用户请求，并发效率低，且不支持不同协议及IO方式的扩展。因此拓展出Connector用来监听、接收用户请求并回写响应数据，用Container来专门负责请求处理计算，如下：

这个时候tomcat可能包含多个Connector 和 多个Container/Engine ，那么某个Connector接收的请求交给那个Container/Engine 来处理呢，所以引入Service概念，某个Service中Connector接收的请求，交给本Service的Container/Engine来处理

container/engine 代表请求处理引擎即servlet引擎。我们知道web服务器是可以部署管理多个应用的，这个engine就要具备多应用管理的能力，并能够根据用户请求信息找到对应的应用来进行请求处理。因此 Engine下抽象出引用Context模型。Engine(总引擎)中可能包含多个应用（Context）

我们考虑web服务器往往根据请求域名来确定处理请求的应用即虚拟主机功能。每个域名对应一个虚拟主机。每个虚拟主机下可能包含多个应用。因此加入虚拟主机后方案优化如下

（实际在tomcat中engine中既可以包含虚拟主机Host也可以直接包含应用Context，只不过Tomcat中提供的默认实现StandardEngine只能包含Host）

在上述基础上我们知道一个web应用中可以包含多个Servlet,Tomcat中Servlet对应Wrapper,完善后设计如下：

实际上 Engine host context wrapper 都输归类为Container 容器。抽象出Container父类，如下：

除了上述内容外服务器还有一些后台处理功能，如每30秒扫描一次web应用文件的变更情况。针对这种情况 Tomcat为容器定义了 backgroundProcess 方法。

Lifecycle

上述组件中都有start和stop方法用于启动申请资源和停止释放资源，都具有生命周期的特征。因此可以抽象出生命周期通用接口，这样就可以采用一致的机制来初始化、启动、停止、销毁各个组件。

如此每个组件就都有了生命周期状态和生命周期事件

Pipeline和 Vaue

上述设计基本完成了核心组件的设计，但是为了增强组件的扩展新个伸缩性，tomcat引入了责任链模式，Tomcat采用责任链模式来处理用户请求。tomcat定义了Pipeline和Value来构造责任链

Pipeline中维护了一个基础的Value,位于Pipeline的末端（最后执行），封装了具体的请求处理和响应过程，在此基础上我们可以添加自定义的Value实现额外功能。Tomcat每个层级的容器都有Pipeline和基础Value实现

Connector

我们知道Tomcat支持多协议，默认支持http和AJP,同时还支持多种IO方式，包括BIO、NIO、APR、NIO2,需要针对不同的协议提供不同的实现，Connector设计增加协议处理组件，拓展如下:

ProctocolHandler代表协议处理器，每个实例代表一种协议/IO方式的实现（http11NioProtocol表示基于nio的http1.1协议实现）。每个协议处理器包含一个Endpoint来启动socket监听，该接口根据IO方式来实现数据读取。还包含一个Processor用来根据协议进行请求内容解析。
tomcat 并没有Endpoint接口只有AbstractEndpoint抽象类。
请求映射及容器的注册和销毁
当Processor 根据协议解析出请求内容后,需要根据请求内容映射到具体的容器进行处理，这就是请求映射。Tomcat组件采用通用的生命周期管理，且可以通过工具进行状态变更，因此还需要考虑容器组件的注册与销毁。
tomcat 通过Mapper和MapperListener两个类实现上述功能，Mapper 用来维护容器映射信息，通过请求信息可以找到对应的Mapper,完成请求映射，MapperListener实现了ContainerListener 和LifecycleListener,在容器组件状态发生变更时，注册或取消对应的容器信息。
MapperListener实现了Lifecycle接口，当启动时会自动作为监听器注册到各个容器组件上。
tomcat7之前Mapper由Connector维护 8 之后改由Service维护
Tomcat通过适配器模式实现了Connector 和Mapper 和Container 的解耦，tomcat 默认的Connector 实现，对应的是配置时CoyoteAdapter。
拓展后设计方案如下：

Executor

作为web服务器不能让用户请求穿行执行，也不能为每个用户请求开启一个线程（量大崩溃），因此需要引入线程池。
Tomcat提供了Executor接口表示一个可以在组件间共享的线程池，改接口集成了lifecycle,可以按照通用组件进行管理。
线程池共享范围：tomcat中的线程池由service维护，因此同一个service中的组件可以共享线程池。如果没有定义任何线程池，相关组件也会自动创建线程池，此时线程池不共享。
tomcat中，Endpoint会启动一组线程来监听端口，当接受到请求后悔创建请求对象，并交给线程池处理，由此并发处理客户端请求。

Bootstrap和 Catalina

上述内容完成了核心组件的设计，除此之外还需要考虑可配置性，因此还需要一套配置组件及启动组件
tomcat通过类Catalina提供了一个Shell程序，用于解析server.xml中定义的各个组件，同时负责启动、停止服务器。
tomcat提供了Bootstrap作为应用服务器的启动入口。Bootstrap负责创建Catalina实例，根据执行参数调用Catalina相关方法完成启动、停止操作。Bootstrap 和 Catalina 松耦合（采用反射调用Catalina ）
如上文所述，Server及其子组件代表了tomcat服务器，因此我们可以不通过bootstrap和Catalina 启动服务器
事实上Tomcat还提供了，org.apache.catalina.startup.Tomcat,使得我们可以将Tomcat嵌入到我们的应用系统中进行启动。当然也可以自定义配置方式和启动类实现自定义启动。最后得出tomcat架构设计图如下：

启动流程

Tomcat启动过程非常的标准化，统一按照生命周期管理接口Lifecycle定义的方法进行启动。先init 再start。每级组件除了启动自身外还要启动子组件。启动时序图如下：

请求处理流程

请求处理开始于监听端口接收数据，结束于服务器写出响应数据，流程如下：