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

简介: 【10月更文挑战第2天】本文通过21张图详细解析了Tomcat的运行原理与架构。Tomcat作为Java Web开发中最流行的Web服务器之一,其架构设计精妙。文章首先介绍了Tomcat的基本组件:Connector(连接器)负责网络通信,Container(容器)处理业务逻辑。连接器内部包括EndPoint、Processor和Adapter等组件,分别处理通信、协议解析和请求封装。容器采用多级结构(Engine、Host、Context、Wrapper),并通过Mapper组件进行请求路由。文章还探讨了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那不为人知的高效奥秘

image.png

先来一张经过本文探索得到的流程图(熟悉Tomcat的同学可以复习复习,不熟悉的同学看完本篇文章就能理解~)

作为Web服务器,那必须要先处理网络请求,处理完网络通信,再进行业务处理

在这个过程中,秉承着高内聚、低耦合的设计思想,可以划分为两个组件处理这些事情

  1. Connector(连接器):负责处理网络通信
  2. Container(容器):负责处理业务 比如servlet容器

    image.png

连接器

连接器处理网络通信又可以分为多个步骤:处理通信(获取socket)、解析协议、封装请求/响应

在Tomcat中这三个工作分别交给三个组件进行处理:

  1. EndPoint:处理通信、获取socket
  2. Processor:解析本次网络请求的协议
  3. Adapter:封装解析的请求/响应交给容器

image.png

AbstractEndPoint

EndPoint从名称上看就知道是做点到点的通信,传输层与应用层间使用Socket处理网络通信

Tomcat 9中实际没有EndPoint的接口,只有抽象类,具体实现只有两种:

  1. NioEndPoint:基于多路复用模型的NIO
  2. Nio2EndPoint:基于AIO的NIO2

    image.png

EndPoint能够使用不同的IO模型来实现网络通信获取Socket

不太理解IO模型的同学可以看看这篇文章喔~

EndPoint实际上还有一种APR的实现(AprEndpoint):在早期JDK NIO性能并不理想,使用编写的本地库来提升性能,后来在Tomcat 10被舍弃

Processor

Processor组件的接口是Processor 用于解析协议

image.png

从AbstractProcessor的实现类中可以看到,它可以解析HTTP、AJP协议(AJP协议更高效,比如Nginx反向代理使用AJP会更快)

UpgradeProcessorBase则是用于协议升级,比如实现WebSocket

Processor能够解析协议,将流解析为Tomcat中封装的请求与响应

ProtocolHandler

Tomcat在设计上将动态变化的EndPoint、Processor组合成ProtocolHandler:负责网络通信获取Socket并将流解析为请求/响应

image.png

EndPoint可以使用NIO、NIO2的方式进行网络通信,而Processor能够解析HTTP、AJP协议

在ProtocolHandler中设计上却又使用了继承的方式,当动态变化的值太多时,会导致继承类爆炸(好在这里只有 2*2=4)

ProtocolHandler只是将两个能够动态改变的子组件进行组合

image.png

Adapter

Adapter 从名称就知道它是适配器模式

Processor解析流封装的请求/响应是Tomcat中定义的,Adapter将请求/响应转化为Servlet的请求/响应,方便后续容器进行处理

image.png

Adapter适配器转换请求/响应是固定的,不会随着IO模型、协议改变,只有一个实现类

线程池

在多路复用IO模型中,当线程监听到某个通道上数据就绪(发生事件),就可以进行处理

由于可能多个通道同时发生事件,此时肯定不能让监听的线程同步进行处理的,否则会阻塞后续的流程

因此会使用线程池对工作线程进行管理,监听到通道上数据就绪后,就交给工作线程执行后续任务

image.png

实际上EndPoint不仅存在线程池还涉及其他组件

这里的线程池是Tomcat自己实现的,并不是JUC下实现的线程池

思考:为什么Tomcat总是自己实现组件呢?为什么不使用已有的轮子呢?网络通信也是自己实现,为啥不用Netty呢?

(这一系列问题以及其他组件,后续单独专注于组件的文章再进行讨论)

多连接器

连接器中不变的是Adapter适配器,变动的是IO模型、协议、端口等

那么Tomcat是否支持多个不同的连接器由一个容器处理呢?

答案是支持的,Tomcat为了方便扩展设计成支持多个不同的连接器绑定同一个容器(Spring Boot中用默认HTTP、NIO、8080的连接器)

image.png

默认连接器使用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

  1. Wrapper代表Servlet,为最底层的容器,真正处理业务,不能再有子容器
  2. Context代表Web应用,能够包含多个Wrapper,即一个Web应用可以包含多个Servlet
  3. Host代表域名,即虚拟站点,每个Host允许有多个Context
  4. Engine代表引擎,最顶层容器,有且只有一个,允许有多个Host

    image.png

这些容器接口都实现Container容器接口,其中都有对应的标准实现StandardXX,标准实现一般都继承抽象父类ContainerBase

一般只在标准实现上进行扩展,比如Spring Boot内嵌Tomcat:TomcatEmbeddedContext继承StrandardContext

为了方便理解,举个HTTP请求的案例:

http://cart.caicaijava.com:8080/caicai/add

image.png

首先请求会经过连接器进行处理,连接器处理完将请求交给顶级容器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请求为例:

在容器路由时已经解析好路由的信息:

image.png

一般现在微服务架构下的部署都是单节点单应用,因此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结束

image.png

每个容器的Valve标准实现都是用作Basic基础节点的,它们最终会去调用下一层容器职责链(StandardEngine/Host/Context/WrapperValve)

image.png

FilterChain

作为最底层容器Wrapper的Valve标准实现,会将Servlet的过滤器和Servlet组装成过滤器链FilterChain,其中Servlet末尾执行

image.png

其他组件

在容器运行时还包含其他组件,如提供类加载的加载器Loader、管理session的管理器Manager...

Loader

Tomcat还提供Loader加载器,每个Context容器会关联一个Loader,用其对子组件进行类加载

同时后台会启动定时任务,判断Class文件是否改变,如果Class文件发生改变,则对其重新进行类加载,以此来实现热加载

(后续文章再对其进行说明)

Manager

由于HTTP协议是无状态的,因此可以使用cookie、session的方式在Web服务器维护状态

Tomcat提供Manager管理器与Context容器进行关联,对session进行管理(标准实现),在调用流程中维护session

image.png

Service、Server

前面说到一个或多个连接器共享同一个容器来对请求进行处理

Tomcat将连接器与容器组合成Service,以此来对外提供服务(相当于多包装一层)

Tomcat为了灵活设计,允许多个Service提供服务,使用Server管理Service(又多包装一层)

image.png

实际上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);
    }
}

image.png

组合优于继承、固定流程抽象模板骨架实现 像这种组件的设计都是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类进行启动/停止的

image.png

在Spring容器初始化Bean的流程中,会通过工厂来创建Web服务器,如果使用的是Tomcat则会通过org.apache.catalina.startup.Tomcat进行启动

请求流程源码分析

为了方便理解,通过源码梳理一条大致的主流程

启动和连接器EndPoint处理网络通信的源码留到后续文章分析,这里从监听到事件交给线程池处理开始(processor前)

  1. EndPoint 交给ProtocolHandler处理 getHandler().process(socketWrapper, event)
  2. ProtocolHandler调用Processor进行解析 processor.process(wrapper, status)
  3. Processor解析完请求,调用适配器Adapter进行封装 getAdapter().service(request, response)
  4. 适配器Adapter封装完请求/响应(会使用加载器解析请求映射),最后从Engine的职责链First开始调用connector.getService().getContainer().getPipeline().getFirst().invoke(request, response)
  5. Engine职责链调用完(当前为Basic,最后一个),从映射中获取Host继续职责链调用 host.getPipeline().getFirst().invoke(request, response)
  6. Host职责链调用完,从映射中获取Context继续职责链调用 context.getPipeline().getFirst().invoke(request, response)
  7. Context职责链调用完,从映射中获取Wrapper继续职责链调用 wrapper.getPipeline().getFirst().invoke(request, response)
  8. Wrapper职责链调用完,加载servlet并封装FilterChain继续调用过滤器链 filterChain.doFilter(request.getRequest(),response.getResponse())
  9. 调用完过滤器链,调用servlet的service servlet.service(request, response)(后续则是MVC的流程)

    image.png

总结

本篇文章以自顶向下的形式描述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-CaiCaiJavaGithub-CaiCaiJava,除此之外还有更多Java进阶相关知识,感兴趣的同学可以starred持续关注喔~

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

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

相关文章
|
5天前
|
运维 负载均衡 微服务
|
2月前
|
前端开发 JavaScript Java
智能客服系统的技术栈解析-唯一客服系统技术架构优势
“唯一客服系统”采用 Vue.js 2.x + ElementUI 构建前端,实现响应式界面,支持多端适配;后端基于 Golang + Gin + GORM,具备高性能与高并发处理能力。系统支持私有化部署,提供灵活定制、AI 扩展能力,技术栈简洁易维护,兼顾开发者友好与企业级应用需求。
162 1
|
1月前
|
人工智能 JavaScript 前端开发
LangGraph架构解析
本文深入解析了传统Agent开发的三大痛点:状态管理碎片化、流程控制复杂及扩展性差,提出使用LangGraph通过有向图模型重构工作流,将LLM调用与工具执行抽象为节点,实现动态流程跳转。文中详述LangGraph四大核心组件——状态机引擎、节点设计、条件边与工具层集成,并结合生产环境最佳实践,如可视化调试、状态持久化与人工干预机制,最终对比LangGraph与传统方案的性能差异,给出选型建议。
232 0
|
12天前
|
机器学习/深度学习 负载均衡 网络架构
Mixture of Experts架构的简要解析
Mixture of Experts(MoE)架构起源于1991年,其核心思想是通过多个专门化的“专家”网络处理输入的不同部分,并由门控网络动态组合输出。这种架构实现了稀疏激活,仅激活部分专家,从而在模型规模与计算成本之间取得平衡。MoE的关键在于门控机制的设计,如线性门控、噪声Top-K门控等,确保模型能根据输入特征自适应选择专家。
78 8
|
12天前
|
机器学习/深度学习 存储 资源调度
Transformer架构的简要解析
Transformer架构自2017年提出以来,彻底革新了人工智能领域,广泛应用于自然语言处理、语音识别等任务。其核心创新在于自注意力机制,通过计算序列中任意两个位置的相关性,打破了传统循环神经网络的序列依赖限制,实现了高效并行化与长距离依赖建模。该架构由编码器和解码器组成,结合多头注意力、位置编码、前馈网络等模块,大幅提升了模型表达能力与训练效率。从BERT到GPT系列,几乎所有现代大语言模型均基于Transformer构建,成为深度学习时代的关键技术突破之一。
185 7
|
25天前
|
消息中间件 缓存 Java
医院信息系统(HIS)的开发架构解析,代码示例
医院信息系统(HIS)是现代医院的核心,其架构设计直接影响系统稳定性、扩展性与用户体验。本文解析HIS架构演进历程,从单机、C/S、B/S到微服务与云原生架构,结合代码示例,深入讲解现代HIS系统的分层架构、核心模块与关键技术实践。
296 1
|
5天前
|
Java 数据库 数据安全/隐私保护
Spring Boot四层架构深度解析
本文详解Spring Boot四层架构(Controller-Service-DAO-Database)的核心思想与实战应用,涵盖职责划分、代码结构、依赖注入、事务管理及常见问题解决方案,助力构建高内聚、低耦合的企业级应用。
80 0
|
边缘计算 Kubernetes 物联网
Kubernetes 赋能边缘计算:架构解析、挑战突破与实践方案
在物联网和工业互联网快速发展的背景下,边缘计算凭借就近处理数据的优势,成为解决云计算延迟高、带宽成本高的关键技术。而 Kubernetes 凭借统一管理、容器化适配和强大生态扩展性,正逐步成为边缘计算的核心编排平台。本文系统解析 Kubernetes 适配边缘环境的架构分层、核心挑战与新兴解决方案,为企业落地边缘项目提供实践参考。
39 0
|
17天前
|
Kubernetes Java 微服务
Spring Cloud 微服务架构技术解析与实践指南
本文档全面介绍 Spring Cloud 微服务架构的核心组件、设计理念和实现方案。作为构建分布式系统的综合工具箱,Spring Cloud 为微服务架构提供了服务发现、配置管理、负载均衡、熔断器等关键功能的标准化实现。本文将深入探讨其核心组件的工作原理、集成方式以及在实际项目中的最佳实践,帮助开发者构建高可用、可扩展的分布式系统。
173 0

热门文章

最新文章

推荐镜像

更多
  • DNS