Tomcat 容器的设计和实现

Tomcat 容器是对 Servlet 规范的实现,也称为 Servlet 引擎。在分析 Tomcat 容器的设计和实现之前,首先简单了解一下 Servlet 规范,弄清楚 Tomcat 究竟要实现什么?

1. Servlet 规范简述

Servlet 是什么?javadoc 中已经明确说明:

Servlet 是在 Web 服务器中运行的 Java 程序,通常用于接收并响应来自 Web 客户端的 HTTP 请求。

Servlet 提供了更高级的抽象,让研发专注于如何处理请求和响应,而不必关心底层网络的处理。像连接处理、解析 HTTP 等都由容器实现,那又是谁决定了容器应该做什么?

答案是 Servlet 规范,简单来说它主要指导解决以下问题:

  • 容器如何管理 Servlet 的生命周期
  • 容器怎么表示请求和响应,怎么映射请求到 Servlet,怎么执行 Servlet
  • 一个 Web 应用的目录组织方式以及容器如何部署一个 Web 应用
  • 其他组件的行为,如过滤器-Filter,监听器-Listener,会话-Session
  • 容器安全性问题,如授权、认证以及类隔离

javax.servlet 包中的类和接口,描述并定义了 Servlet 类与容器提供的运行时环境之间的契约。容器和应用对相关类和接口的实现情况如下:

Java Servlet API

容器实现的类或接口的作用如下:

  • ServletContext: 表示一个 Web 应用程序,是 Servlet 运行的上下文,定义了一组与容器通信的方法
  • ServletRequest: 封装客户端请求,容器会创建一个它的实例,并传给 serlvet 的 service 方法
  • ServletResponse: 封装服务端响应,容器会创建一个它的实例,并传给 serlvet 的 service 方法
  • FilterChain: 过滤器调用链视图,控制过滤器的调用
  • RequestDispatcher: 转发请求,将请求转发给 JSP 或另一个 Servlet
  • HttpSession: 用户会话,一个与 cookie 关联

2. Tomcat 引擎设计

Tomcat 在内部抽象出了容器组件的概念,基本结构如下:

servlet-engine

容器可以执行接收的请求,并返回响应。容器之间是一种一对多的包含关系,在运行时,它们通过内部的 pipeline(管道) 串联起来。容器主要有以下几种:

  • Engine - 顶级容器,不能被其他容器包含,它接受处理连接器的所有请求,并将响应返回相应的连接器,子容器通常是 Host 或 Context
  • Host - 类似 Apache 虚拟主机的概念,包含主机名称和IP地址,这里默认是localhost,父容器是 Engine,子容器是 Context
  • Context - 表示一个 Web 应用程序,是 Servlet、Filter 的父容器
  • Wrapper - 表示一个 Servlet,它负责管理 Servlet 的生命周期,并提供了方便的机制使用拦截器,没有子容器

容器可以和多个组件关联,组件主要提供通用或定制的功能:

  • Loader - 类加载器,用于在运行时加载类到容器
  • Manager - 管理 Session 池
  • Realm - 安全域的只读接口,用于验证用户身份及其相应角色
  • Vavle - 与特定容器关联的请求处理组件,由容器的 Pipeline 管理,取义于阀门在现实世界的管道中用来控制或修改流量
  • Listener - 这里只是一个统称,主要想强调容器内部设计了很多事件,比如组件的生命周期事件,容器属性变动的事件等

Servlet 引擎就是由容器和组件组合嵌套而成,实现时设计的类图及类的核心方法如下(Tomcat 版本 6.0.53):

Tomcat 容器类图

3. 容器生命周期的设计

容器的大部分实现依赖于 Lifecycle(如启动、配置),Lifecycle 是观察者模式的应用,Tomcat 使用 LifecycleSupport 类用于周期事件的添加、删除和触发。运用 Lifecycle 在实现时大量使用接口而不是具体的类,更加灵活。

Tomcat 设计了 init、start、stop、destroy和periodic 五类事件,其中 periodic 是一个定时触发事件,由每个容器所属的后台线程触发。容器在初始化时会默认添加一个用于配置的 Listener,如上图所示,类的作用如下:

  • EngineConfig: 无具体功能
  • HostConfig: 主要负责创建 Context 实例;检查已部署应用资源是否变化并重新部署
  • ContextConfig: 主要负责解析 web.xml 初始化 Servlet、Filter、Listener,添加资源监控目录,供 Loader 热加载

4. Pipeline 管道的设计 - 执行 Servlet

Pipeline 是一个很常用的处理模型,和 FilterChain 大同小异,都是责任链模式的实现,Pipeline 内部有多个 Valve,这些 Valve 因栈的特性都有机会处理请求和响应。

Tomcat 的实现类是 StandardPipeline,内部的 Valve 是一个有固定尾节点的单链表,插入时采用头插法逆序插入,读取时使用头结点顺序读取。

这里主要对每个容器的固定 valve 的功能进行分析,容器也是通过最后一个 valve 串联起来:

  • StandardEngineValve: 根据请求的服务器名称,选择适当的 Host 来处理此请求
  • StandardHostValve: 主要功能如下:
    • 匹配 Context,绑定当前 Web 应用的类加载器到当前线程,进入 Context 管道处理请求
    • 响应返回时,如果有异常,生成错误页面,并还原线程的类加载器
  • StandardContextValve: 主要功能如下:
    • 禁止直接访问 WEB-INF 和 META-INF目录
    • 若进行了热加载,重新关联类加载器
    • 获取匹配的 Wrapper 和配置的 ServletRequestListener,进入 Wrapper 管道处理请求
    • 响应返回时,销毁之前初始化的 ServletRequestListener
  • StandardWrapperValve: 主要功能如下:
    • 反射加载一个 Servlet 实例,并创建一个过滤器链
    • 调用配置的过滤器,然后调用 servlet 的 service() 方法
    • 最后释放过滤器链和 serlvet 实例
    • 如果 servlet 被标记不可用,调用它的 destroy() 方法

6. Web 应用程序的部署

部署的过程其实就是解析 xml 实例化对象,并触发和处理容器及组件对应生命周期事件的过程。

在 Tomcat 中,一个 Context 实例就代表一个 Web 应用程序,所以部署的第一步就是创建一个 StandardContext 对象。在创建时 HostConfig 首先会查找 Context 描述符,它可能在两个位置:

  • $CATALINA_BASE/conf/<engine>/<host>/[webappname].xml
  • $CATALINA_BASE/webapps/webappname/META_INF/context.xml

如果两个位置都不存在此文件,则使用 conf/context.xml 默认配置。

Context 实例化后会触发 init 和 start 生命周期事件:

  • init - 会创建用于解析 context.xml 和 web.xml 的工具 Digester 的实例,并解析context.xml
  • start - 则会根据 web.xml 部署描述符实例化 Servlet、Filter、Listener 等 Web 组件

6.1 热部署和热加载

热部署和热加载的操作都是由容器的后台线程调用自身、子容器或组件的 backgroundProcess() 方法或 periodic 生命周期事件触发。

如果 Host 的 autoDeploy 属性为 true,那么在运行时将 Web 应用程序放到 webapps 目录下,会自动部署;此外它还监视 .war、context.xml 和 web.xml 以及docBase 目录下的静态资源文件,如果 lastModified 有变动会重新部署。

如果 Context 的 reloadable 属性为 true,那么 Loader 组件的 backgroundProcess() 方法会检测 class和jar 的变化并自动加载。

7. 小结

本文主要对容器的设计进行了分析,其中核心就是 Lifecycle 和 Pipeline 的设计。接下来会对各个组件的实现进行分析。

posted @ 2019-04-30 17:43  小创  阅读(1870)  评论(0编辑  收藏  举报