一次请求的来龙去脉 - Tomcat架构解析(二)

　> 容器，简单理解就是用来装东西的工具。在Tomcat里面，容器被设计用来装载Servlet， 也就是我们平常写的普通的Servlet ，就会存放在容器里面。这也就是咱们平常念叨的Servlet容器，其实从广义上理解，Servlet容器是指Tomcat，从狭义上理解，Servlet容器，只是Tomcat里面的一个组件而已。
 

      1.容器概述
 

　　Tomcat采用分层结构设计了4种容器，这4种容器分别是： Engine 、Host 、Context 、Wrap 。它们钧继承 Container 容器接口。这样设计使得Tomcat在处理请求时，分工更加明确，也使得容器具有很好的灵活性。

　　

　　其中从左到右： Engine 表示引擎，用来管理多个虚拟站点，一个Service最多只能有一个Engine。 Host代表虚拟主机，或者表示站点。其实就是我们配置出来的虚拟映射地址。Context表示一个Web应用，Wrap 名为包装，它其实就是内部包装着我们写的Servlet。
 

　　为了方便大家理解，我们可以从Tomcat里面的server.xml中看出来一些端倪。

　　这四个容器呈现的是一个父子包含关系：

　　2. 定位Servlet
 

　　> 在Tomcat里面使用Mapper 映射器来实现Servlet的定位工作。在最初启动项目的时候，Tomcat就开始解析了项目的配置信息，然后使用Mapper来保存了具体的映射地址和Host、Context、Wrap的对应关系。当请求到来的时候，就会到Mapper里面去查找匹配的Wrap(Servlet)，然后调用。当我们为了方便理解，我们可以浅显的认为Mapper其实就是一个类似Map键值对的容器。
 

　　2.1 全局概览
 

　　比如： 下面的图示，我们可以把瑞吉点餐项目的面向管理员后台项目和面向用户前端项目部署在同一个Tomcat上，为了隔离它们，我们通过配置虚拟域名，也就是两个Host。而用户系统，订单系统，产品系统，购物车系统又都是可以独立运行的应用，所以我们可以配备4个Context来对应它们。最后一排的Wrap，其实就是各自系统中的Servlet了。

　　2.2 请求到来
 

　　> 此时用户使用 http://user.reggie.com:8080/cart/delete 来访问。
 

　　2.2.1 定位Service和Engine
 

　　由于来访的时候，使用的是8080端口，正好被Http连接器捕捉到。在Tomcat里面，Service里面包含着： 连接器和容器。找到了连接器，也就意味着找到了容器，这也就意味着Engine就确定了。
 

　　2.2.2 定位Host
 

　　Service和Engine确定了之后，就在Mapper中，通过路径地址，找到响应的Host容器。由于使用的是user.reggie.com 访问，所以这就确定了是Host2这个容器。
 

　　2.2.3 定位Context
 

　　Host确定了之后，继续在Mapper中查找。由于使用的/cart访问，所以这就定位到了Context4这个应用。
 

　　2.2.4 定位Wrap
 

　　Context确定了之后，后续也就能根据地址 /delete，轻而易举的找到 Wrap6 这个容器。最后也就定位到了Servlet。
 

　　2.3 请求传递
 

　　> Tomcat 里面是如何把请求从最外层的容器Engine，一直往里传递到Wrap，然后执行Servlet的调用的呢?

　　>

　　> 答案是使用 Pipeline-Valve 管道。

　　>

　　> Pipeline-Valve 是责任链模式，责任链模式是指在一个请求处理的过程中有很多处理者依次对请求进行处理，每个处理者负责做自己相应的处理，处理完之后将再调用下一个处理者继续处理。
 

　　下面通过一个张简单的草图来描述：
 

　　每一个容器都有一个Pipeline对象，中间的每一个圆圈，其实表示的是一个Valve，它表示处理点。在Pipeline里面维护这Valve的链表。只要执行了第一个Pipeline的Valve，这个容器中的Pipeline就会被调用，直到最后末端的Basic的Valve，它负责去连接下一个子容器的第一个Valve处理点。这样不断的串联起来，最终就到达了Servlet。

　　值得注意的是： 在Wrap的最后一个Basic的Valve的处理点里面，它会创建一个Filter过滤器链，然后在doFilter方法中最终调用Servlet的service方法。
 

　　3. 总结
 

　　本文主要给大家描述了Tomcat了里面的容器结构，以及请求到来的时候，是如何识别到底执行了哪个Servlet。请求的链式调用是基于 Pipeline-Valve 责任链来完成的，这样的设计使得系统具有良好的可扩展性，如果需要扩展容器本身的功能，只需要增加相应的 Valve 即可。