Tomcat源码解析(一)： Tomcat整体架构

Tomcat源码系列文章

Tomcat源码解析(一)： Tomcat整体架构

---

一、Tomcat整体架构

1、Tomcat两个核心组件功能

• 连接器（Connector）：处理Socket连接，负责网络字节流与Request和Response对象的转化
• 容器（Container）：加载和管理Servlet，以及具体处理Request请求

• 从图上可以看到，最顶层是Server，这里的Server指的就是一个Tomcat 实例
• 一个Server中有一个或者多个Service
• 一个Service只有一个容器，但是可以有多个连接器

2、Tomcat支持的多种I/O模型和应用层协议

Tomcat支持的I/O模型

• NIO：非阻塞I/O，采用Java NIO类库实现
• NIO.2：异步I/O，采用JDK 7最新的NIO.2类库实现
• APR：采用Apache可移植运行库实现，是C/C++编写的本地库

Tomcat支持的应用层协议

• HTTP/1.1：这是大部分Web应用采用的访问协议
• AJP：用于和Web服务器集成（如Apache）
• HTTP/2：HTTP 2.0大幅度的提升了Web性能

• Tomcat为了实现支持多种I/O模型和应用层协议，一个容器可能对接多个连接器
• 单独的连接器或者容器都不能对外提供服务，需要把它们组装起来才能工作，组装后这个整体叫作Service组件
• 通过在Tomcat中配置多个Service，可以实现通过不同的端口号来访问同一台机器上部署的不同应用

二、Connector连接器

1、连接器功能汇总

连接器对Servlet容器屏蔽了协议及I/O模型等的区别，无论是HTTP还是AJP，在容器中获取到的都是一个标准的ServletRequest对象

连接器细化功能

1. 监听网络端口
2. 接受网络连接请求
3. 读取网络请求字节流
4. 根据具体应用层协议（HTTP/AJP）解析字节流，生成统一的Tomcat Request对象
5. 将Tomcat Request对象转成标准的ServletRequest
6. 调用Servlet容器，得到ServletResponse
7. 将ServletResponse转成Tomcat Response对象
8. 将Tomcat Response转成网络字节流
9. 将响应字节流写回给浏览器

连接器汇总功能

• 网络通信
• 应用层协议解析
• Tomcat Request/Response与ServletRequest/ServletResponse的转化

Tomcat的设计者设计了3个组件来实现这3个功能，分别是Endpoint、Processor和Adapter

• Endpoint负责提供字节流给Processor
• Processor负责提供Tomcat Request对象给Adapter
• Adapter负责提供ServletRequest对象给容器

2、ProtocolHandler组件

• 由于I/O模型和应用层协议可以自由组合，比如NIO + HTTP或者NIO.2 + AJP
  • Tomcat的设计者将网络通信和应用层协议解析放在一起考虑
  • 设计了一个叫ProtocolHandler的接口来封装这两种变化点
  • 各种协议和通信模型的组合有相应的具体实现类。比如：Http11NioProtocol和AjpNio2Protocol
• 网络和协议相同点封装到抽象基类AbstractProtocol，每一种应用层协议有自己的抽象基类
• 这样设计每一种I/O模型和协议的组合都有相应的具体实现类，我们在使用时可以自由选择
• 特别说明：当前只有一个实现类Http2Protocol用于处理HTTP/2.0，不在以下体系内

• 小结一下，连接器模块用三个核心组件：Endpoint、Processor和Adapter来分别做三件事情
• 其中Endpoint和Processor放在一起抽象成了ProtocolHandler组件，它们的关系如下图所示

2.1、Endpoint

• Endpoint是通信端点，即通信监听的接口，是具体的Socket接收和发送处理器，是对传输层的抽象，因此Endpoint是用来实现TCP/IP协议的
• Endpoint是一个接口，对应的抽象实现类是AbstractEndpoint，而AbstractEndpoint的具体子类，比如在NioEndpoint和Nio2Endpoint中，有两个重要的子组件：Acceptor和SocketProcessor
  • Acceptor用于监听Socket连接请求
  • SocketProcessor用于处理接收到的Socket请求，它实现Runnable接口，在run方法里调用协议处理组件Processor进行处理。为了提高处理能力，SocketProcessor被提交到线程池来执行。而这个线程池叫作执行器（Executor)

2.2、Processor

• 如果说Endpoint是用来实现TCP/IP协议的，那么Processor用来实现HTTP协议
• Processor接收来自Endpoint的Socket，读取字节流解析成Tomcat Request和Response对象，并通过Adapter将其提交到容器处理，Processor是对应用层协议的抽象
• Processor是一个接口，定义了请求的处理等方法
  • 它的抽象实现类AbstractProcessor对一些协议共有的属性进行封装，没有对方法进行实现
  • 具体的实现有AjpProcessor、Http11Processor等，这些具体实现类实现了特定协议的解析方法和请求处理方式

3、Adapter组件

• 由于协议不同，客户端发过来的请求信息也不尽相同，Tomcat定义了自己的Request类来“存放”这些请求信息
• ProtocolHandler接口负责解析请求并生成Tomcat Request类
  • 但是这个Request对象不是标准的ServletRequest，也就意味着，不能用Tomcat Request作为参数来调用容器
  • Tomcat设计者的解决方案是引入CoyoteAdapter，这是适配器模式的经典运用
    • 连接器调用CoyoteAdapter的sevice方法，传入的是Tomcat Request对象
    • CoyoteAdapter负责将Tomcat Request转成ServletRequest
    • 再调用容器的service方法

再来看看连接器的组件图：

三、Container容器

1、容器的基本组成

• Tomcat设计了4种容器，分别是Engine、Host、Context和Wrapper
• 这4种容器不是平行关系，而是父子关系

• Wrapper：表示一个Servlet，Wrapper 作为容器中的最底层，不能包含子容器
• Context：表示一个Web应用程序， 一个Web应用可包含多个Wrapper
• Host：代表一个虚拟主机，或者说一个站点，可以给Tomcat配置多个虚拟主机地址，而一个虚拟主机下可包含多个Context
• Engine：表示引擎，用来管理多个虚拟站点，一个Service最多只能有一个Engine，但是一个引擎可包含多个Host

2、server.xml配置文件

• 容器的父子包含关系，在在tomcat的conf目录下的server.xml配置文件中也有体现
• Server标签设置的端口号为8005，shutdown=”SHUTDOWN” ，表示在8005端口监听“SHUTDOWN”命令，如果接收到了就会关闭Tomcat

• 根据上边的配置文件，查看源码目录

• Tomcat中默认的配置下webapps下的每一个文件夹目录都是一个Context
• 其中ROOT目录中存放着主应用，其他目录存放着子应用，而整个webapps就是一个Host站点
• 我们访问应用Context的时候，如果是ROOT下的则直接使用域名就可以访问，例如：www.ledouit.com
• 如果是Host（webapps）下的其他应用，则可以使用www.ledouit.com/springmvc进行访问

3、请求定位Servlet的过程

3.1、Mapper组件

Tomcat是用Mapper组件来确定请求是由哪个Wrapper容器里的Servlet来处理

• Mapper组件的功能就是将用户请求的URL定位到一个Servlet
  • 它的工作原理是：Mapper组件里保存了Web应用的配置信息
  • 其实就是容器组件与访问路径的映射关系
  • 比如Host容器里配置的域名、Context容器里的Web应用路径，以及Wrapper容器里Servlet映射的路径
  • 可以想象这些配置信息就是一个多层次的Map
• 当一个请求到来时，Mapper组件通过解析请求URL里的域名和路径，再到自己保存的Map里去查找，就能定位到一个Servlet
• 一个请求URL最后只会定位到一个Wrapper容器，也就是一个Servlet

3.2、定位Servlet流程

举例：一个网购系统

• 有面向网站管理人员的后台管理系统，还有面向终端客户的在线购物系统
• 这两个系统跑在同一个Tomcat上，为了隔离它们的访问域名，配置了两个虚拟域名： manage.shopping.com 和 user.shopping.com
  • 网站管理通过manage.shopping.com域名去管理用户和商品，而用户管理和商品管理是两个单独的Web应用
  • 终端客户通过user.shopping.com域名去搜索商品和下订单，搜索功能和订单管理也是两个独立的Web应用

---

• 针对这样的部署，Tomcat会创建一个Service组件和一个Engine容器组件
• 在Engine容器下创建两个Host子容器，在每个Host容器下创建两个Context子容器
• 由于一个Web应用通常有多个Servlet，Tomcat还会在每个Context容器里创建多个Wrapper子容器
• 每个容器都有对应的访问路径，可以通过下面这张图来帮助理解

假如有用户访问一个URL，比如图中的http://user.shopping.com:8080/order/buy，Tomcat如何将这个URL定位到一个Servlet呢？

1. 根据协议和端口号选定Service和Engine
   • Tomcat的每个连接器都监听不同的端口，比如Tomcat默认的HTTP连接器监听8080端口、默认的AJP连接器监听8009端口
   • 上面例子中的URL访问的是8080端口，因此这个请求会被HTTP连接器接收
   • 由Tomcat整体架构可知，连接器是属于某个Service组件的
   • 一个Service组件里除了有多个连接器，还有一个容器组件，也就能获取唯一Engine容器
2. 根据域名选定Host
   • Service和Engine确定后，Mapper组件通过URL中的域名去查找相应的Host容器
   • 比如例子中的URL访问的域名是 user.shopping.com，因此Mapper会找到Host2这个容器
3. 根据URL路径找到Context组件
   • Host确定以后，Mapper根据URL的路径来匹配相应的Web应用的路径
   • 比如例子中访问的是 /order，因此找到了Context4这个Context容器
4. 根据URL路径找到Wrapper（Servlet）
   • Context确定后，Mapper再根据web.xml中配置的Servlet映射路径来找到具体的Wrapper和Servlet

3.3、实现原理

• 需要注意的是，并不是说只有Servlet才会去处理请求，实际上这个查找路径上的父子容器都会对请求做一些处理
  • 连接器中的Adapter会调用容器的Service方法来执行Servlet
  • 最先拿到请求的是Engine容器，Engine容器对请求做一些处理后，会把请求传给自己子容器Host继续处理，依次类推
  • 最后这个请求会传给Wrapper容器，Wrapper会调用最终的Servlet来处理
• 具体实现是使用Pipeline-Valve管道

Pipeline-Valve是责任链模式

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

Valve接口

• Valve是一个处理点，因此invoke方法就是来处理请求的
• Valve中有getNext和setNext方法，可以猜到有一个链表将Valve链起来了

public interface Valve {
  public Valve getNext();
  public void setNext(Valve valve);
  public void invoke(Request request, Response response)
}

Pipeline接口

• Pipeline中维护了Valve链表，Valve可以插入到Pipeline中，对请求做某些处理
• Pipeline中没有invoke方法，因为整个调用链的触发是Valve来完成的
• Valve完成自己的处理后，调用 getNext.invoke 来触发下一个Valve调用

public interface Pipeline extends Contained {
  public void addValve(Valve valve);
  public Valve getBasic();
  public void setBasic(Valve valve);
  public Valve getFirst();
}

四种容器的执行流程

• 每一个容器都有一个Pipeline对象，只要触发这个Pipeline的第一个Valve，这个容器里Pipeline中的Valve就都会被调用到
• 但是，不同容器的Pipeline是怎么链式触发的呢，比如Engine中Pipeline需要调用下层容器Host中的Pipeline
  • Pipeline中还有个getBasic方法
  • 这个BasicValve处于Valve链表的末端，它是Pipeline中必不可少的一个Valve
  • 负责调用下层容器的Pipeline里的第一个Valve

• 整个调用过程由连接器中的Adapter触发的，它会调用Engine的第一个Valve

// Calling the container
connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);