浅谈Tomcat多层容器的设计_tomcat

容器的层次结构

tomcat设计了4种容器：engine、host、context和wrapper

tomcat通过这种分层，使得servlet容器具有很好的灵活性。

context表示一个web应用程序
wrapper表示一个servlet，一个web应用程序中可能会有多个servlet
host代表一个虚拟主机，或一个站点，可以给tomcat配置多个虚拟主机地址，而一个虚拟主机下可以部署多个web应用程序
engine表示引擎，用来管理多个虚拟站点，一个service最多只能有一个engine

观察tomcat的server.xml配置文件。tomcat采用了组件化设计，最外层即是server

这些容器具有父子关系，形成一个树形结构，tomcat用组合模式来管理这些容器。

所有容器组件都实现container接口，因此组合模式可以使得用户对

单容器对象
最底层的wrapper

组合容器对象
上面的context、host或者engine
的使用具有一致性。

container接口定义：

public interface container extends lifecycle {
    public void setname(string name);
    public container getparent();
    public void setparent(container container);
    public void addchild(container child);
    public void removechild(container child);
    public container findchild(string name);
}

请求定位servlet的过程

搞这么多层次的容器，tomcat是怎么确定请求是由哪个wrapper容器里的servlet来处理的呢？
tomcat用mapper组件完成这个任务。

mapper就是将用户请求的url定位到一个servlet

工作原理

mapper组件保存了web应用的配置信息：容器组件与访问路径的映射关系，比如

host容器里配置的域名
context容器里的web应用路径
wrapper容器里servlet映射的路径

这些配置信息就是一个多层次的map。

当一个请求到来时，mapper组件通过解析请求url里的域名和路径，再到自己保存的map里去查找，就能定位到一个servlet。
一个请求url最后只会定位到一个wrapper容器，即一个servlet。

假如有一网购系统，有

面向b端管理人员的后台管理系统
面向c端用户的在线购物系统

这俩系统跑在同一tomcat，为隔离它们的访问域名，配置两个虚拟域名：

manage.shopping.com
管理人员通过该域名访问tomcat去管理用户和商品，而用户管理和商品管理是两个单独的web应用

user.shopping.com
c端用户通过该域名去搜索商品和下订单，搜索功能和订单管理也是两个独立web应用

这样部署，tomcat会创建一个service组件和一个engine容器组件，在engine容器下创建两个host子容器，在每个host容器下创建两个context子容器。由于一个web应用通常有多个servlet，tomcat还会在每个context容器里创建多个wrapper子容器。每个容器都有对应访问路径

tomcat如何将url定位到一个servlet呢？

首先，根据协议和端口号选定service和engine
tomcat的每个连接器都监听不同的端口，比如tomcat默认的http连接器监听8080端口、默认的ajp连接器监听8009端口。该url访问8080端口，因此会被http连接器接收，而一个连接器是属于一个service组件的，这样service组件就确定了。一个service组件里除了有多个连接器，还有一个engine容器，因此service确定了，engine也确定了。

根据域名选定host。
mapper组件通过url中的域名去查找相应的host容器，比如user.shopping.com，因此mapper找到host2容器。

根据url路径找到context组件
host确定以后，mapper根据url的路径来匹配相应的web应用的路径，比如例子中访问的是/order，因此找到了context4这个context容器。

最后，根据url路径找到wrapper（servlet）
context确定后，mapper再根据web.xml中配置的servlet映射路径来找到具体wrapper和servlet。

并非只有servlet才会去处理请求，查找路径上的父子容器都会对请求做一些处理：

连接器中的adapter会调用容器的service方法执行servlet
最先拿到请求的是engine容器，engine容器对请求做一些处理后，会把请求传给自己子容器host继续处理，依次类推
最后这个请求会传给wrapper容器，wrapper会调用最终的servlet来处理

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

valve表示一个处理点，比如权限认证和记录日志。

public interface valve {
  public valve getnext();
  public void setnext(valve valve);
  public void invoke(request request, response response)
}

由于valve是一个处理点，因此invoke方法就是来处理请求的。
pipeline接口：

public interface pipeline extends contained {
  public void addvalve(valve valve);
  public valve getbasic();
  public void setbasic(valve valve);
  public valve getfirst();
}

所以pipeline中维护了valve链表，valve可插入到pipeline。
pipeline中没有invoke方法，因为整个调用链的触发是valve完成自己的处理后，调用getnext.invoke调用下一个valve。

每个容器都有一个pipeline对象，只要触发这个pipeline的第一个valve，这个容器里pipeline中的valve就都会被调用到。但不同容器的pipeline如何链式触发？
比如engine中pipeline需要调用下层容器host中的pipeline。
pipeline有个getbasic方法。这个basicvalve处于valve链尾，负责调用下层容器的pipeline里的第一个valve。

整个调用过程由连接器中的adapter触发的，它会调用engine的第一个valve：

wrapper

容器的最后一个valve会创建一个filter链，并调用dofilter方法，最终会调到servlet的service方法。

valve和filter有什么区别呢？

valve是tomcat的私有机制，与tomcat紧耦合。servlet api是公有标准，所有web容器包括jetty都支持filter
valve工作在web容器级别，拦截所有应用的请求。servlet filter工作在应用级别，只拦截某个web应用的所有请求。若想做整个web容器的拦截器，必须使用valve。

到此这篇关于浅谈tomcat多层容器的设计的文章就介绍到这了,更多相关tomcat 多层容器内容请搜索移动技术网以前的文章或继续浏览下面的相关文章希望大家以后多多支持移动技术网！