Tomcat - 理解Tomcat架构设计
准备知识
Tomcat和Catalina是什么关系?
Tomcat的前身为Catalina,Catalina又是一个轻量级的Servlet容器。在美国,catalina是一个很美的小岛。所以Tomcat作者的寓意可能是想把Tomcat设计成一个优雅美丽且轻量级的web服务器。Tomcat从4.x版本开始除了作为支持Servlet的容器外,额外加入了很多的功能,比如:jsp、el、naming等等,所以说Tomcat不仅仅是Catalina。
什么是Servlet?
在互联网兴起之初,当时的Sun公司(后面被Oracle收购)已然看到了这次机遇,于是设计出了Applet来对Web应用的支持。不过事实却并不是预期那么得好,Sun悲催地发现Applet并没有给业界带来多大的影响。经过反思,Sun就想既然机遇出现了,市场前景也非常不错,总不能白白放弃了呀,怎么办呢?于是又投入精力去搞一套规范出来,这时Servlet诞生了!
一个Servlet主要做下面三件事情:
- 创建并填充Request对象,包括:URI、参数、method、请求头信息、请求体信息等
- 创建Response对象
- 执行业务逻辑,将结果通过Response的输出流输出到客户端
Servlet没有main方法,所以,如果要执行,则需要在一个容器里面才能执行,这个容器就是为了支持Servlet的功能而存在,Tomcat其实就是一个Servlet容器的实现。
Tomcat 总结架构
下图应该是网上能找的最好的关于Tomcat的架构图了, 我们来看下它的构成:
从组件的角度看
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 -- 认证授权组件
从web.xml配置和模块对应角度
从一个完整请求的角度来看
假设来自客户的请求为: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
从源码的设计角度看
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编译运行所必需的。
从后续深入理解的角度
- 基于组件的架构
我们知道组成Tomcat的是各种各样的组件,每个组件各司其职,组件与组件之间有明确的职责划分,同时组件与组件之间又通过一定的联系相互通信。Tomcat整体就是一个个组件的堆砌!
- 基于JMX
我们在后续阅读Tomcat源码的时候,会发现代码里充斥着大量的类似于下面的代码。
Registry.getRegistry(null, null).invoke(mbeans, "init", false);
Registry.getRegistry(null, null).invoke(mbeans, "start", false);
而这实际上就是通过JMX来管理相应对象的代码。这儿我们不会详细讲述什么是JMX,我们只是简单地说明一下JMX的概念,参考JMX百度百科。
- 基于生命周期
如果我们查阅各个组件的源代码,会发现绝大多数组件实现了Lifecycle接口,这也就是我们所说的基于生命周期。生命周期的各个阶段的触发又是基于事件的方式。
更多文章
相关文章
- Tomcat - 如何设计一个简单的web容器
- 在学习Tomcat前,很多人先入为主的对它的认知是巨复杂的;所以第一步,在学习它之前,要打破这种观念,我们通过学习如何设计一个最基本的web容器来看它需要考虑什么;进而在真正学习Tomcat时,多把重点放在它的顶层设计上,而不是某一块代码上, 思路永远比具体实现重要的多。
- Tomcat - 理解Tomcat架构设计
- 前文我们已经介绍了一个简单的Servlet容器是如何设计出来,我们就可以开始正式学习Tomcat了,在学习开始,我们有必要站在高点去看看Tomcat的架构设计。
- Tomcat - 源码分析准备和分析入口
- 上文我们介绍了Tomcat的架构设计,接下来我们便可以下载源码以及寻找源码入口了。
- Tomcat - 启动过程:初始化和启动流程
- 在有了Tomcat架构设计和源码入口以后,我们便可以开始真正读源码了。
- Tomcat - 启动过程:类加载机制详解
- 上文我们讲了Tomcat在初始化时会初始化classLoader。本文将具体分析Tomcat的类加载机制,特别是区别于传统的
双亲委派模型
的加载机制。
- 上文我们讲了Tomcat在初始化时会初始化classLoader。本文将具体分析Tomcat的类加载机制,特别是区别于传统的
- Tomcat - 启动过程:Catalina的加载
- 通过前两篇文章,我们知道了Tomcat的类加载机制和整体的组件加载流程;我们也知道通过Bootstrap初始化的catalinaClassLoader加载了Catalina,那么进而引入了一个问题就是Catalina是如何加载的呢?加载了什么呢?本文将带你进一步分析。
- Tomcat - 组件生命周期管理:LifeCycle
- 上文中,我们已经知道Catalina初始化了Server(它调用了 Server 类的 init 和 start 方法来启动 Tomcat);你会发现Server是Tomcat的配置文件server.xml的顶层元素,那这个阶段其实我们已经进入到Tomcat内部组件的详解;这时候有一个问题,这么多组件是如何管理它的生命周期的呢?
- Tomcat - 组件拓展管理:JMX和MBean
- 我们在前文中讲Lifecycle以及组件,怎么会突然讲JMX和MBean呢?本文通过承接上文Lifecycle讲Tomcat基于JMX的实现。
- Tomcat - 事件的监听机制:观察者模式
- 本文承接上文中Lifecycle中实现,引出Tomcat的监听机制。
- Tomcat - Server的设计和实现: StandardServer
- 基于前面的几篇文章,我们终于可以总体上梳理Server的具体实现了,这里体现在StandardServer具体的功能实现上。
- Tomcat - Service的设计和实现: StandardService
- 上文讲了Server的具体实现了,本文主要讲Service的设计和实现;我们从上文其实已经知道Server中包含多个service了。
- Tomcat - 线程池的设计与实现:StandardThreadExecutor
- 上文中我们研究了下Service的设计和实现,StandardService中包含Executor的调用;这个比较好理解,Tomcat需要并发处理用户的请求,自然而言就想到线程池,那么Tomcat中线程池(Executor)具体是如何实现的?本文带你继续深度解析。
- Tomcat - Request请求处理: Container设计
- 在理解了Server,Service和Executor后,我们可以进入Request处理环节了。我们知道客户端是可以发起多个请求的,Tomcat也是可以支持多个webapp的,有多个上下文,且一个webapp中可以有多个Servlet...等等,那么Tomcat是如何设计组件来支撑请求处理的呢?本节文将介绍Tomcat的Container设计。
- Tomcat - Container容器之Engine:StandardEngine
- 上文已经知道Container的整体结构和设计,其中Engine其实就是Servlet Engine,负责处理request的顶层容器。
- Tomcat - Container的管道机制:责任链模式
- 上文中介绍了Engine的设计,其中有Pipline相关内容没有介绍,本文将向你阐述Tomcat的管道机制以及它要解决的问题。
- Tomcat - Request请求处理过程:Connector
- 本文主要介绍request请求的处理过程。