vlambda博客
学习文章列表

阅读源码，首先要理解源码的整体架构设计，网上有好多文章谈及模块组成、源码解读，但就我个人而言并不是很好理解，本篇文章尝试用最浅显的逻辑，一步一步阐述它的的设计原理。

好了，如果你已经学习了基础的Java多线程 、Java网络编程，让你设计一个Http服务器你会怎么做？

1、初始化一个serversocket

2、监听客户端连接，并通过accept创建客户端socket

3、解析socket流，并构造响应数据

于是你的结构图是这样的:

这是最简单的模型，在这个模型里所有的Socket创建、连接、流操作都在一个模块里，但是Tomcat实际上为了多协议（不仅仅是Http，还包括AJP等），所以为了使特定协议与Server解耦合，Tomcat的设计者把连接和流操作分离开来，并让Server分别持有连接、流操作，于是结构图变成了这样：

其中一个启动中的Server就是一个Tomcat应用程序实例，一个Server可以有多个Connector以管理多个连接协议，所以也可以持有不同的对应的Engine来进行流处理。但是这里有个问题就是，N个Connector是如何对应到M个Engine处理器 以实现特定的连接交给特定的流处理器来执行任务呢？

为了解决这个问题，Tomcat设计了Service模块，并变成了下面的结构图模型：

其中一个Service模块维护多个Connector形成Connector集合并对应一个Engine，而一个Server可以有多个Service！至此，一个Tomcat基础模型就构建完成了，后续所有的功能模块、线程设计均基于这个模型构建！

我们首先要看的是Engine模块，在流处理中依然有很多问题要解决！

第一个问题，如果我这台主机提供多个域名服务，这时我们访问不同的域名其实就得交由不同的应用逻辑来处理，但是如果Engine只有一个（我们当然可以创建多个Service进而实现多个Engine，最简单的方法就是再启动一个Tomcat），那么就必须在请求到达Engine后执行分配逻辑，来处理不同的域名下的服务，Tomcat设计了虚拟主机的模块来执行这个功能，关于虚拟主机是这样的一个概念：

在一台Tomcat服务器中可以同时管理多个站点，即可以将多个站点配置在同一台Tomcat服务器上，而对于用户（浏览器）而言，是不知道具体哪些网站是布置在同一台Tomcat（服务器）之上的，对于用户（浏览器）而言，每个站点都像是运行在各自独立的服务器上。此时每个网站就是运行在同一台这是服务器中各自对应的虚拟主机上。此时，简单的理解，每个网站就可以认为是一个虚拟主机。

添加了虚拟主机的模块，Tomcat于是就变成了下面的结构模型：

当请求过来的时候，会通过解析当前请求的域名来处理不同Hosts的数据流 ，所以一个Engine可以管理多个Hosts！

第二个问题，我们一直强调“流处理”，其实流处理就是根据当前上下文的所有变量来实现Web应用的功能逻辑罢了，如socket、session、cookie等等，这些都是在一个流程处理中的所有有用变量或者对象，而且这些对象会在不同类之间相互调用，那么如何保证这些变量或者对象可以灵活的获取和构造并保证一致性，Tomcat于是设计了context组件，于是，就有了下面的模型：

这里的context其实就是ServletContext，实际上一个ServletContex就是代表了一个Web应用！所以一个Host下显然可以有不同的Web应用，即一个Host可以拥有多个context！

因为这里我们谈及了Servlet，上文也说过Tomcat其实就是Servlet的规范实现，所以一个Web应用自然可以包含多个Servlet，Tomcat中定义为Wrapper，于是就有了下面的模型图：

Servlet的加载时通过反射的形式加载的，因为当我们创建Http服务器的时候，我们所有的Servlet都是继承HttpServlet,这样当读取web.xml文件的时候就可以按照类似下面的代码构建我们创建的Servlet：

HttpServlet httpServlet = (HttpServlet) Class.forName(“自定义Servlet的包路径”).newInstance();

至此，关于Engine部分的内容基本构造完成。

但是Tomcat设计时为了统一管理右侧的这些组件，实际把他们抽象成了一个被称为container的组件，使得四个组件都继承这个container，也就是我们说的容器概念，然后统一管理各个组件的声明周期！于是的Tomcat模型可以扩充成这样：

这里变成虚线，是为了体现各个组件实际上是由父类Container容器实现的“弱依赖”关系，把原先的实现改为了虚线！至此我们看到一个较为完整的组件关系图，于是你们见到最多的关于Tomcat的结构图就是下面一幅：

这个架构图展示了上述Tomcat的核心组件，并表示出了各个组件间的组合关系：一个Server包含多个Service，一个Service包含多个Connector形成的一个集合，并对应一个Container组件！

接下来，我们该探讨Connector组件的实现细节！

我们提到Connector组件可以支持不同的协议，默认是Http和AJP，实际上Connector还支持不同的I/O模型：如BIO、NIO、APR等等，所以如何针对不同类型的连接方式来建立客户端的通信，Tomcat设计了被称为协议处理器 的上层组件：ProtocolHandler

ProtocolHandler包含又包含两个组件，一个是抽象的AbstractEndpoint，用于实现不同的协议、I/O模型。NioEndpoint指代非阻塞式SocketIO，另外还包含Processer组件用于实际的对应容器的逻辑处理；于是就出现了类似Http11NioProtocol这样的实现来处理支持Http1.1和NIO的连接方式，这样我们的模型图就变成了这样：

这里面我们忽略一个上述文章中重要的一个组件功能：Service。这个组件如文章所述是建立Connector和Container（我们前文说的是Engine，但是注意自从建立了Container组件，实际上Engine等四个组件被统称为Container组件的子组件）的重要桥梁，所以实际上谈论Connector就必须谈论的就是Service是如何实现两者的映射关系的！

当Processor读取请求信息后需要按照请求的信息映射到相应的容器来处理，这里的映射信息是由Service的Maper和MaperListener来实现的，这里使用了观察者模式来监听客户端的连接并注册到Maper中，后续只需要根据Maper维护的映射信息即可找到对应的容器。实际上为了实现Connector和Service的解耦运用了适配器模式，所以Processor的一个默认适配器实现被称为CoyoteAdapter；我们的模型图变成了下面的结构：

但是Tomcat整合的考虑更多：既然可以由Container来统一表示这4个组件，那么图中所有的组件其实都包含启动、停止等各个生命周期，为了高效的管理个组件的运行，我们有必要把所有的组件在抽象成一个更通用的组件来进行统一的管理，这里Tomcat设计了Lifecycle组件，于是实际的Tomcat变成了下面的模型结构图：

至此，一个基本的Tomcat模型就创造出来了！