21张图解析Tomcat运行原理与架构全貌-阿里云开发者社区

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持续关注喔~

有什么问题可以在评论区交流，如果觉得菜菜写的不错，可以点赞、关注、收藏支持一下~

关注菜菜，分享更多技术干货，公众号：菜菜的后端私房菜

21张图解析Tomcat运行原理与架构全貌