21张图解析Tomcat运行原理与架构全貌通宵爆肝

最新推荐文章于 2024-08-06 08:55:22 发布

「已注销」

最新推荐文章于 2024-08-06 08:55:22 发布

阅读量1.1k

点赞数 18

文章标签： tomcat 架构 java

本文链接：https://blog.csdn.net/BASK2311/article/details/138857398

版权

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仓库查看)

tcl

复制代码

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请求的案例：

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()

java

复制代码

protected void initInternal() throws LifecycleException { // ...其他代码略 // Initialize our defined Services for (Service service : services) { service.init(); } }

在前面已经见到过太多组件有自己的抽象父类了，Lifecycle也不例外

这样设计能够将固定的和变动的进行分离，固定的流程放在抽象父类中模板实现，变动的使用子类实现去进行扩展

比如LifecycleBase中实现Lifecycle接口init的模板骨架

java

复制代码

@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在生命周期中使用观察者模式，定义状态，当状态改变时即为事件发生，触发组件的监听器

java

复制代码

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的启动/停止

java

复制代码

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中提供关闭钩子，当程序异常关闭时执行关闭钩子

java

复制代码

Runtime.getRuntime().addShutdownHook(shutdownHook);

当程序异常关闭时，会去用线程执行关闭钩子，停止服务器

java

复制代码

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的流程）