Tomcat 源码详解第二课 -- 理解Tomcat架构设计

原创于 2024-12-04 07:30:00 发布 · 1.1k 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#tomcat #java #Servlet #tomcat架构

中间件专栏收录该内容

13 篇文章

订阅专栏

2.2. 从 web.xml 配置和模块对应角度

2.3. 从一个完整请求的角度来看

2.4. 从源码的设计角度看

2.5. 从后续深入理解的角度

一. 前言

Tomcat 的前身为 Catalina，Catalina 又是一个轻量级的 Servlet 容器。在美国，Catalina 是一个很美的小岛。所以 Tomcat 作者的寓意可能是想把 Tomcat 设计成一个优雅美丽且轻量级的 Web 服务器。Tomcat 从 4.x 版本开始除了作为支持 Servlet 的容器外，额外加入了很多的功能，比如：jsp、el、naming 等等，所以说 Tomcat 不仅仅是 Catalina。

1.1. 什么是 Servlet？

所谓 Servlet，其实就是 Sun 为了让 Java 能实现动态可交互的网页，从而进入 Web 编程领域而制定的一套标准！

在互联网兴起之初，当时的 Sun 公司（后面被 Oracle 收购）已然看到了这次机遇，于是设计出了Applet 来对 Web 应用的支持。不过事实却并不是预期那么得好，Sun 悲催地发现 Applet 并没有给业界带来多大的影响。经过反思，Sun 就想既然机遇出现了，市场前景也非常不错，总不能白白放弃了呀，怎么办呢？于是又投入精力去搞一套规范出来，这时 Servlet 诞生了！

一个 Servlet 主要做下面三件事情：

创建并填充 Request 对象，包括：URI、参数、method、请求头信息、请求体信息等
创建 Response 对象
执行业务逻辑，将结果通过 Response 的输出流输出到客户端

Servlet 没有 main 方法，所以，如果要执行，则需要在一个容器里面才能执行，这个容器就是为了支持 Servlet 的功能而存在，Tomcat 其实就是一个 Servlet 容器的实现。

二. Tomcat 总结架构

下图应该是网上能找的最好的关于 Tomcat 的架构图了，我们来看下它的构成：

2.1. 从组件的角度看

Server：表示服务器，它提供了一种优雅的方式来启动和停止整个系统，不必单独启停连接器和容器；它是 Tomcat 构成的顶级构成元素，所有一切均包含在 Server 中；
Service：表示服务，Server 可以运行多个服务。比如一个 Tomcat 里面可运行订单服务、支付服务、用户服务等等；Server 的实现类 StandardServer 可以包含一个到多个 Services, Service 的实现类为 StandardService 调用了容器(Container)接口，其实是调用了 Servlet Engine(引擎)，而且 StandardService 类中也指明了该 Service 归属的 Server;
Container：表示容器，可以看做Servlet容器；引擎(Engine)、主机(Host)、上下文(Context)和 Wraper 均继承自 Container 接口，所以它们都是容器。
- Engine -- 引擎
- Host -- 主机
- Context -- 上下文
- Wrapper -- 包装器
Connector：表示连接器, 它将 Service 和 Container 连接起来，首先它需要注册到一个Service，它的作用就是把来自客户端的请求转发到 Container (容器)，这就是它为什么称作连接器, 它支持的协议如下：
- 支持 AJP 协议
- 支持 Http 协议
- 支持 Https 协议
Service 内部还有各种支撑组件，下面简单罗列一下这些组件
- Manager -- 管理器，用于管理会话 Session
- Logger -- 日志器，用于管理日志
- Loader -- 加载器，和类加载有关，只会开放给 Context 所使用
- Pipeline -- 管道组件，配合 Valve 实现过滤器功能
- Valve -- 阀门组件，配合 Pipeline 实现过滤器功能
- Realm -- 认证授权组件

2.2. 从 web.xml 配置和模块对应角度

上述模块的理解不是孤立的，它直接映射为 Tomcat 的 web.xml 配置，让我们联系起来看

2.3. 从一个完整请求的角度来看

通过一个完整的 HTTP 请求，我们还需要把它贯穿起来

假设来自客户的请求为：http://localhost:8080/test/index.jsp 请求被发送到本机端口 8080，被在那里侦听的 Coyote HTTP/1.1 Connector，然后

Connector 把该请求交给它所在的 Service 的 Engine 来处理，并等待 Engine 的回应
Engine 获得请求 localhost:8080/test/index.jsp，匹配它所有虚拟主机 Host
Engine 匹配到名为 localhost 的 Host (即使匹配不到也把请求交给该 Host 处理，因为该 Host被定义为该 Engine 的默认主机)
localhost Host 获得请求 /test/index.jsp，匹配它所拥有的所有 Context
Host 匹配到路径为 /test 的 Context(如果匹配不到就把该请求交给路径名为""的 Context 去处理)
path="/test" 的 Context 获得请求 /index.jsp，在它的 mapping table 中寻找对应的 servlet
Context 匹配到 URL PATTERN 为 *.jsp 的 servlet，对应于JspServlet 类，构造HttpServletRequest 对象和 HttpServletResponse 对象，作为参数调用 JspServlet 的 doGet 或 doPost 方法
Context 把执行完了之后的 HttpServletResponse 对象返回给 Host
Host 把 HttpServletResponse 对象返回给 Engine
Engine 把HttpServletResponse 对象返回给 Connector
Connector 把HttpServletResponse 对象返回给客户 browser

2.4. 从源码的设计角度看

从功能的角度将 Tomcat 源代码分成5个子模块，分别是：

Jsper 模：这个子模块负责 jsp 页面的解析、jsp 属性的验证，同时也负责将 jsp 页面动态转换为 java 代码并编译成 class 文件。在 Tomcat 源代码中，凡是属于 org.apache.jasper 包及其子包中的源代码都属于这个子模块;
Servlet 和 Jsp 模块：这个子模块的源代码属于 javax.servlet 包及其子包，如我们非常熟悉的javax.servlet.Servlet 接口、javax.servet.http.HttpServlet 类及 javax.servlet.jsp.HttpJspPage就位于这个子模块中;
Catalina 模块：这个子模块包含了所有以 org.apache.catalina 开头的 java 源代码。该子模块的任务是规范了 Tomcat 的总体架构，定义了 Server、Service、Host、Connector、Context、Session 及 Cluster 等关键组件及这些组件的实现，这个子模块大量运用了Composite 设计模式。同时也规范了 Catalina 的启动及停止等事件的执行流程。从代码阅读的角度看，这个子模块应该是我们阅读和学习的重点。
Connector 模块：如果说上面三个子模块实现了 Tomcat 应用服务器的话，那么这个子模块就是Web服务器的实现。所谓连接器(Connector)就是一个连接客户和应用服务器的桥梁，它接收用户的请求，并把用户请求包装成标准的 Http 请求(包含协议名称，请求头 Head，请求方法是 Get 还是 Post 等等)。同时，这个子模块还按照标准的 Http 协议，负责给客户端发送响应页面，比如在请求页面未发现时，connector 就会给客户端浏览器发送标准的 Http 404 错误响应页面。
Resource 模块：这个子模块包含一些资源文件，如 Server.xml 及 Web.xml 配置文件。严格说来，这个子模块不包含 java 源代码，但是它还是 Tomcat 编译运行所必需的。

2.5. 从后续深入理解的角度

我们看完上述组件结构后，后续应该重点从哪些角度深入理解 Tomcat 呢？

基于组件的架构

我们知道组成 Tomcat 的是各种各样的组件，每个组件各司其职，组件与组件之间有明确的职责划分，同时组件与组件之间又通过一定的联系相互通信。Tomcat 整体就是一个个组件的堆砌！

基于JMX

我们在后续阅读 Tomcat 源码的时候，会发现代码里充斥着大量的类似于下面的代码。

Registry.getRegistry(null, null).invoke(mbeans, "init", false);
Registry.getRegistry(null, null).invoke(mbeans, "start", false);

而这实际上就是通过 JMX 来管理相应对象的代码。这儿我们不会详细讲述什么是 JMX，我们只是简单地说明一下 JMX 的概念，参考 JMX 百度百科。

JMX（Java Management Extensions，即 Java 管理扩展）是一个为应用程序、设备、系统等植入管理功能的框架。JMX 可以跨越一系列异构操作系统平台、系统体系结构和网络传输协议，灵活的开发无缝集成的系统、网络和服务管理应用。

基于生命周期

如果我们查阅各个组件的源代码，会发现绝大多数组件实现了 Lifecycle 接口，这也就是我们所说的基于生命周期。生命周期的各个阶段的触发又是基于事件的方式。