21张图解析Tomcat运行原理与架构全貌💥通宵爆肝
前言
早年间,精通CRUD的小菜同学在Tomcat上通过继承HttpServlet进行CRUD
后来,有了Spring MVC框架的DispatcherServlet,让小菜更容易的进行CRUD
到现在,Spring Boot框架内嵌Web服务器,让小菜更轻松、更便捷的专注CRUD
小菜保持专一的原则,一心只关注CRUD,从未对服务器、框架有过”非分之想“
突然有一天,小菜不知道改动了哪里,程序跑不起来了
小菜心想:程序跑不了,那我岂不是得跑了?不行,不行,大环境这么恶劣,我可不能跑啊
于是,小菜开始查看各种中间件的运行原理,抽丝剥茧一层一层解析各种各样的中间件…
架构
Tomcat作为Java实现的Web服务器,是Java Web开发最流行的Web服务器之一
本文作为解析Tomcat专栏的第一篇文章,将带你深入Tomcat的运行流程,一步步揭开Tomcat精妙设计的核心组件,探索Tomcat那不为人知的高效奥秘
先来一张经过本文探索得到的流程图(熟悉Tomcat的同学可以复习复习,不熟悉的同学看完本篇文章就能理解~)
作为Web服务器,那必须要先处理网络请求,处理完网络通信,再进行业务处理
在这个过程中,秉承着高内聚、低耦合的设计思想,可以划分为两个组件处理这些事情
- Connector(连接器):负责处理网络通信
- Container(容器):负责处理业务 比如servlet容器
连接器
连接器处理网络通信又可以分为多个步骤:处理通信(获取socket)、解析协议、封装请求/响应
在Tomcat中这三个工作分别交给三个组件进行处理:
- EndPoint:处理通信、获取socket
- Processor:解析本次网络请求的协议
- Adapter:封装解析的请求/响应交给容器
AbstractEndPoint
EndPoint从名称上看就知道是做点到点的通信,传输层与应用层间使用Socket处理网络通信
Tomcat 9中实际没有EndPoint的接口,只有抽象类,具体实现只有两种:
- NioEndPoint:基于多路复用模型的NIO
- Nio2EndPoint:基于AIO的NIO2
EndPoint能够使用不同的IO模型来实现网络通信获取Socket
不太理解IO模型的同学可以看看这篇文章喔~
EndPoint实际上还有一种APR的实现(AprEndpoint):在早期JDK NIO性能并不理想,使用编写的本地库来提升性能,后来在Tomcat 10被舍弃
Processor
Processor组件的接口是Processor 用于解析协议
从AbstractProcessor的实现类中可以看到,它可以解析HTTP、AJP协议(AJP协议更高效,比如Nginx反向代理使用AJP会更快)
UpgradeProcessorBase则是用于协议升级,比如实现WebSocket
Processor能够解析协议,将流解析为Tomcat中封装的请求与响应
ProtocolHandler
Tomcat在设计上将动态变化的EndPoint、Processor组合成ProtocolHandler:负责网络通信获取Socket并将流解析为请求/响应
EndPoint可以使用NIO、NIO2的方式进行网络通信,而Processor能够解析HTTP、AJP协议
在ProtocolHandler中设计上却又使用了继承的方式,当动态变化的值太多时,会导致继承类爆炸(好在这里只有 2*2=4)
ProtocolHandler只是将两个能够动态改变的子组件进行组合
Adapter
Adapter 从名称就知道它是适配器模式
Processor解析流封装的请求/响应是Tomcat中定义的,Adapter将请求/响应转化为Servlet的请求/响应,方便后续容器进行处理
Adapter适配器转换请求/响应是固定的,不会随着IO模型、协议改变,只有一个实现类
线程池
在多路复用IO模型中,当线程监听到某个通道上数据就绪(发生事件),就可以进行处理
由于可能多个通道同时发生事件,此时肯定不能让监听的线程同步进行处理的,否则会阻塞后续的流程
因此会使用线程池对工作线程进行管理,监听到通道上数据就绪后,就交给工作线程执行后续任务
实际上EndPoint不仅存在线程池还涉及其他组件
这里的线程池是Tomcat自己实现的,并不是JUC下实现的线程池
思考:为什么Tomcat总是自己实现组件呢?为什么不使用已有的轮子呢?网络通信也是自己实现,为啥不用Netty呢?
(这一系列问题以及其他组件,后续单独专注于组件的文章再进行讨论)
多连接器
连接器中不变的是Adapter适配器,变动的是IO模型、协议、端口等
那么Tomcat是否支持多个不同的连接器由一个容器处理呢?
答案是支持的,Tomcat为了方便扩展设计成支持多个不同的连接器绑定同一个容器(Spring Boot中用默认HTTP、NIO、8080的连接器)
默认连接器使用Http11NioProtocol监听8080端口(HTTP、NIO、8080)
在默认的基础上增加一个连接器,使用AjpNio2Protocol监听6666(AJP、NIO2、6666)
运行时会根据端口、协议找到连接器进行处理
(文章就不贴Spring Boot扩展的代码了😁感兴趣的同学可以直接去末尾Git仓库查看)
2024-04-24 17:22:32.474 INFO 25672 --- [main]
o.s.b.w.embedded.tomcat.TomcatWebServer :
Tomcat initialized with port(s): 8080 (http) 6666 (ajp)
从日志上可以看到Tomcat监听端口变多了
容器
如果让我们来设计容器,很多人的第一反映肯定就是设计一个Servlet容器
当连接器处理完通信,封装好请求,直接交给这个Servlet容器进行处理
但是Tomcat并没有只单独设计一个Servlet容器
为了能够灵活扩展,Tomcat设计多层父子容器:Engine、Host、Context、Wrapper
- Wrapper代表Servlet,为最底层的容器,真正处理业务,不能再有子容器
- Context代表Web应用,能够包含多个Wrapper,即一个Web应用可以包含多个Servlet
- Host代表域名,即虚拟站点,每个Host允许有多个Context
- Engine代表引擎,最顶层容器,有且只有一个,允许有多个Host
这些容器接口都实现Container容器接口,其中都有对应的标准实现StandardXX,标准实现一般都继承抽象父类ContainerBase
一般只在标准实现上进行扩展,比如Spring Boot内嵌Tomcat:TomcatEmbeddedContext继承StrandardContext
为了方便理解,举个HTTP请求的案例:
http://cart.caicaijava.com:8080/caicai/add
首先请求会经过连接器进行处理,连接器处理完将请求交给顶级容器Engine
假设配置两个Host:order.caicaijava.com、cart.caicaijava.com,由于我们请求的是cart.caicaijava.com则会被路由到对应Host
假设配置多个Context,会根据请求的前缀/caicai找到对应Context,wrapper同理
Mapper
在多级容器中根据请求路由到下级容器时,实际上是根据Mapper组件进行路由的
Mapper映射器会将请求进行解析,将HTTP请求映射到对应的servlet容器上
Mapper通过map方法解析映射并将结果封装起来,后续在多级容器中路由就能快速找到下一级容器
实际上Spring Boot中内嵌的Tomcat默认下每层容器都只有一个,以http://127.0.0.1:8080/caicai/test/add请求为例:
在容器路由时已经解析好路由的信息:
一般现在微服务架构下的部署都是单节点单应用,因此Host一般都是localhost
而Context则是配置的contextPath:/caicai,其实现类是Spring Boot继承StandardContext的TomcatEmbeddedContext
而Wrapper则是MVC框架中实现的DispatchServlet,最后根据解析出的路径/test/add,再去DispatchServlet中寻找(Spring MVC的流程本篇文章不提)
PipeLine-Valve
为了方便扩展,在多级容器的调用链路中每个容器都使用职责链模式
Pipeline接口为职责链中的管道,Valve接口为管道中负责处理的节点
Pipeline管道分为First首节点和Basic基础节点,基础节点用于调用下一层容器,处于当前容器职责链的末尾,最后执行
也就是每层容器中职责链的调用顺序从First开始Basic结束
每个容器的Valve标准实现都是用作Basic基础节点的,它们最终会去调用下一层容器职责链(StandardEngine/Host/Context/WrapperValve)
FilterChain
作为最底层容器Wrapper的Valve标准实现,会将Servlet的过滤器和Servlet组装成过滤器链FilterChain,其中Servlet末尾执行
其他组件
在容器运行时还包含其他组件,如提供类加载的加载器Loader、管理session的管理器Manager…
Loader
Tomcat还提供Loader加载器,每个Context容器会关联一个Loader,用其对子组件进行类加载
同时后台会启动定时任务,判断Class文件是否改变,如果Class文件发生改变,则对其重新进行类加载,以此来实现热加载
(后续文章再对其进行说明)
Manager
由于HTTP协议是无状态的,因此可以使用cookie、session的方式在Web服务器维护状态
Tomcat提供Manager管理器与Context容器进行关联,对session进行管理(标准实现),在调用流程中维护session
Service、Server
前面说到一个或多个连接器共享同一个容器来对请求进行处理
Tomcat将连接器与容器组合成Service,以此来对外提供服务(相当于多包装一层)
Tomcat为了灵活设计,允许多个Service提供服务,使用Server管理Service(又多包装一层)
实际上Spring Boot中默认内嵌的Tomcat这些组件都只有一个
Lifecycle
Tomcat中这么多组件,如何设计才能方便管理呢?
一般组件是要有生命周期的,比如在初始化(启动前)、启动时、结束前都需要做一些工作
做这些工作时(比如初始化),有的组件需要依赖别的组件,比如service肯定要依赖connector、container
而实现初始化最简单的办法就是从内到外依次进行初始化,但如果这样实现,后续组件多并且要扩展会导致逻辑乱,万一漏了个组件但又成功启动会导致错误难以排查
Tomcat使用Lifecycle接口来统一的管理组件的生命周期,提供init、start、stop、destroy等方法管理组件的初始化、启动、停止、卸载等生命周期
Server、Service的包装设计也是为了方便管理内部组件
在组件中再使用组合模式,启动父组件时,由父组件来启动子组件
比如调用父组件Server的init、start内部会去调用子组件Service的相同生命周期方法
StandardServer.initInternal()
protected void initInternal() throws LifecycleException {
// ...其他代码略
// Initialize our defined Services
for (Service service : services) {
service.init();
}
}
在前面已经见到过太多组件有自己的抽象父类了,Lifecycle也不例外
这样设计能够将固定的和变动的进行分离,固定的流程放在抽象父类中模板实现,变动的使用子类实现去进行扩展
比如LifecycleBase中实现Lifecycle接口init的模板骨架
@Override
public final synchronized void init() throws LifecycleException {
//如果当前不是NEW状态抛出异常
if (!state.equals(LifecycleState.NEW)) {
invalidTransition(Lifecycle.BEFORE_INIT_EVENT);
}
try {
//设置状态为INITIALIZING 初始化中
setStateInternal(LifecycleState.INITIALIZING, null, false);
//开始初始化
initInternal();
//设置状态为INITIALIZED 初始化结束
setStateInternal(LifecycleState.INITIALIZED, null, false);
} catch (Throwable t) {
handleSubClassException(t, "lifecycleBase.initFail", toString());
}
}
为了方便扩展(想在组件初始化前后做一些事情)Tomcat在生命周期中使用观察者模式,定义状态,当状态改变时即为事件发生,触发组件的监听器
protected void fireLifecycleEvent(String type, Object data) {
//构建事件
LifecycleEvent event = new LifecycleEvent(this, type, data);
//遍历监听器处理事件
for (LifecycleListener listener : lifecycleListeners) {
listener.lifecycleEvent(event);
}
}
组合优于继承、固定流程抽象模板骨架实现 像这种组件的设计都是Effective Java中说到过的原则
启动与停止
Tomcat服务器将启动/停止的功能单独抽离成新的组件
在原生Tomcat中使用Bootstrap引导类启动/停止Tomcat服务器
它会通过反射调用Catalina中的启动/停止方法,最终去调用Server的启动/停止
public void start() throws Exception {
if (catalinaDaemon == null) {
init();
}
//catalinaDaemon 就是Catalina对象
Method method = catalinaDaemon.getClass().getMethod("start", (Class [])null);
method.invoke(catalinaDaemon, (Object [])null);
}
public void stop() throws Exception {
Method method = catalinaDaemon.getClass().getMethod("stop", (Class []) null);
method.invoke(catalinaDaemon, (Object []) null);
}
Catalina中提供关闭钩子,当程序异常关闭时执行关闭钩子
Runtime.getRuntime().addShutdownHook(shutdownHook);
当程序异常关闭时,会去用线程执行关闭钩子,停止服务器
protected class CatalinaShutdownHook extends Thread {
@Override
public void run() {
try {
if (getServer() != null) {
Catalina.this.stop();
}
} catch (Throwable ex) {
ExceptionUtils.handleThrowable(ex);
log.error(sm.getString("catalina.shutdownHookFail"), ex);
} finally {
// If JULI is used, shut JULI down *after* the server shuts down
// so log messages aren't lost
LogManager logManager = LogManager.getLogManager();
if (logManager instanceof ClassLoaderLogManager) {
((ClassLoaderLogManager) logManager).shutdown();
}
}
}
}
而在Spring Boot中内嵌的Tomcat是通过Tomcat类进行启动/停止的
在Spring容器初始化Bean的流程中,会通过工厂来创建Web服务器,如果使用的是Tomcat则会通过org.apache.catalina.startup.Tomcat进行启动
请求流程源码分析
为了方便理解,通过源码梳理一条大致的主流程
启动和连接器EndPoint处理网络通信的源码留到后续文章分析,这里从监听到事件交给线程池处理开始(processor前)
- EndPoint 交给ProtocolHandler处理
getHandler().process(socketWrapper, event)
- ProtocolHandler调用Processor进行解析
processor.process(wrapper, status)
- Processor解析完请求,调用适配器Adapter进行封装
getAdapter().service(request, response)
- 适配器Adapter封装完请求/响应(会使用加载器解析请求映射),最后从Engine的职责链First开始调用
connector.getService().getContainer().getPipeline().getFirst().invoke(request, response)
- Engine职责链调用完(当前为Basic,最后一个),从映射中获取Host继续职责链调用
host.getPipeline().getFirst().invoke(request, response)
- Host职责链调用完,从映射中获取Context继续职责链调用
context.getPipeline().getFirst().invoke(request, response)
- Context职责链调用完,从映射中获取Wrapper继续职责链调用
wrapper.getPipeline().getFirst().invoke(request, response)
- Wrapper职责链调用完,加载servlet并封装FilterChain继续调用过滤器链
filterChain.doFilter(request.getRequest(),response.getResponse())
- 调用完过滤器链,调用servlet的service
servlet.service(request, response)
(后续则是MVC的流程)
总结
本篇文章以自顶向下的形式描述Tomcat中部分核心组件以及运行流程,后续的文章将逐步从源码解析各核心组件,彻底剖析Tomcat~
连接器用于处理网络通信,其将IO模型、协议等动态改变的部分交给ProtocolHandler组件进行处理,固定不变的交给Adapter处理
ProtocolHandler中EndPoint负责监听通道,当通道数据就绪发生事件时,将事件封装好交给线程池处理
线程池中的线程开始处理,会使用ProtocolHandler中的Processor进行请求解析,将网络流解析为Tomcat封装的请求,然后再使用Adapter将Tomcat的请求/响应进行封装,能够得到Servlet中定义的请求/响应,接着调用容器进行处理
容器分为Engine、Host、Context、Wrapper的多级父子容器,其每层关系为一对多,调用链路使用职责链模式,Pipeline中使用Valve进行处理,每层职责链从First开始到Basic结束,Basic通常是每层的标准容器实现,用于调用下层容器
调用完Wrapper容器后,其标准实现会将servlet与过滤器组合为过滤器链进行调用,先调用过滤器最后再调用servlet
在容器中还有很多其他组件,如负责类加载器的加载器Loader、负责管理session的管理器Manager,负责多级容器间路由的映射器Mapper…
为了方便管理与扩展,允许多个连接器绑定同个容器,并将连接器与容器组合为Service提供服务,整个Tomcat为一个Server服务器,允许存在多个Service提供服务
组件间使用组合模式进行管理,实现生命周期接口,在初始化/启动/停止/卸载时,通过调用父组件的生命周期接口去触发子组件的生命周期方法
同时为了方便扩展还提供生命周期的监听器,当生命周期状态发生改变时可以进行扩展(观察者模式)
在原生的Tomcat中使用Bootstrap作为启动类,调用Catalina进行启动/停止,而在Spring Boot中内嵌服务器会使用封装的Tomcat进行启动/停止
在Tomcat的设计中,为了方便扩展使用职责链、观察者、模板等设计模式,多层容器、Service等冗余架构
现在微服务架构基本都是单应用部署,其中允许多实例的组件Service、Host、Context、Wrapper等一般都只有一个
🌠最后(不要白嫖,一键三连求求拉~)
本篇文章被收入专栏 Tomcat全解析:架构设计与核心组件实现,感兴趣的同学可以持续关注喔
本篇文章笔记以及案例被收入 Gitee-CaiCaiJava、 Github-CaiCaiJava,除此之外还有更多Java进阶相关知识,感兴趣的同学可以starred持续关注喔~
有什么问题可以在评论区交流,如果觉得菜菜写的不错,可以点赞、关注、收藏支持一下~
关注菜菜,分享更多技术干货,公众号:菜菜的后端私房菜