Tomcat系统架构与原理剖析

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

素履之往、、

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

阅读量509

点赞数

分类专栏：分布式文章标签： tomcat

本文链接：https://blog.csdn.net/king13127/article/details/118720366

版权

分布式专栏收录该内容

7 篇文章 0 订阅

订阅专栏

一、Tomcat架构

1.1 Tomcat 连接器组件 Coyote

1.2 Tomcat Servlet 容器 Catalina

一、Tomcat架构

我们都知道tomcat是一个HTTP 服务器，接收到请求之后把请求交给Servlet容器来处理，Servlet 容器通过Servlet接⼝调⽤业务类。Tomcat既按照Servlet规范的要求去实现了Servlet容器，同时它也具有HTTP服务器的功能。

上面这张就是经典的tomcat架构图，我们可以发现Tomcat中只有一个Server，一个Server可以有多个Service，一个Service可以有多个Connector和一个Container。总体我们发现Tomcat 设计了两个核⼼组件连接器（Connector）和容器（Container）来完成 Tomcat 的两⼤核⼼功能。

连接器，负责对外交流：处理Socket连接，负责⽹络字节流与Request和Response对象的转化；
容器，负责内部处理：加载和管理Servlet，以及具体处理Request请求；

1.1 Tomcat 连接器组件 Coyote

Coyote 是Tomcat 中连接器的组件名称 , 是对外的接⼝。客户端通过Coyote与服务器建⽴连接、发送请求并接受响应。coyote主要功能：

Coyote 封装了底层的⽹络通信（Socket 请求及响应处理）；
Coyote 使Catalina 容器（容器组件）与具体的请求协议及IO操作⽅式完全解耦；
Coyote 将Socket 输⼊转换封装为 Request 对象，进⼀步封装后交由Catalina 容器进⾏处理，处理请求完成后, Catalina 通过Coyote 提供的Response 对象将结果写⼊输出流；
Coyote 负责的是具体协议（应⽤层）和IO（传输层）相关内容

EndPoint，EndPoint 是 Coyote 通信端点，即通信监听的接⼝，是具体Socket接收和发送处理器，是对传输层的抽象，因此EndPoint⽤来实现TCP/IP协议的；
Processor，Processor 是Coyote 协议处理接⼝，如果说EndPoint是⽤来实现TCP/IP协议的，那么Processor⽤来实现HTTP协议，Processor接收来⾃EndPoint的Socket，读取字节流解析成Tomcat Request和Response对象，并通过Adapter将其提交到容器处理，Processor是对应⽤层协议的抽象；
ProtocolHandler，Coyote 协议接⼝，通过Endpoint 和 Processor ，实现针对具体协议的处理能⼒。Tomcat 按照协议和I/O 提供了6个实现类： AjpNioProtocol ，AjpAprProtocol， AjpNio2Protocol ， Http11NioProtocol ，Http11Nio2Protocol ，Http11AprProtocol；
Adapter，由于协议不同，客户端发过来的请求信息也不尽相同，Tomcat定义了⾃⼰的Request类来封装这些请求信息。ProtocolHandler接⼝负责解析请求并⽣成Tomcat Request类。但是这个Request对象不是标准的ServletRequest，不能⽤Tomcat Request作为参数来调⽤容器。Tomcat设计者的解决⽅案是引⼊CoyoteAdapter，这是适配器模式的经典运⽤，连接器调⽤CoyoteAdapter的Sevice⽅法，传⼊的是Tomcat Request对象，CoyoteAdapter负责将Tomcat Request转成ServletRequest，再调⽤容器。

1.2 Tomcat Servlet 容器 Catalina

Tomcat是⼀个由⼀系列可配置（conf/server.xml）的组件构成的Web容器，⽽Catalina是Tomcat的servlet容器。从另⼀个⻆度来说，Tomcat 本质上就是⼀款 Servlet 容器，因为 Catalina 才是 Tomcat 的核⼼，其他模块都是为Catalina 提供⽀撑的。⽐如：通过 Coyote 模块提供链接通信，Jasper 模块提供 JSP 引擎，Naming 提供JNDI 服务，Juli 提供⽇志服务。

其实，可以认为整个Tomcat就是⼀个Catalina实例，Tomcat 启动的时候会初始化这个实例，Catalina实例通过加载server.xml完成其他实例的创建，创建并管理⼀个Server，Server创建并管理多个服务，每个服务⼜可以有多个Connector和⼀个Container。

Catalina，负责解析Tomcat的配置⽂件（server.xml） , 以此来创建服务器Server组件并进⾏管理。
Server，服务器表示整个Catalina Servlet容器以及其它组件，负责组装并启动Servlaet引擎,Tomcat连接器。Server通过实现Lifecycle接⼝，提供了⼀种优雅的启动和关闭整个系统的方式，所以也是Catalina有一个Server。
Service服务是Server内部的组件，⼀个Server包含多个Service。它将若⼲个Connector组件绑定到⼀个Container。
Container，容器负责处理⽤户的servlet请求，并返回对象给web⽤户的模块。

Container又包含了四个内部模块：

Engine，表示整个Catalina的Servlet引擎，⽤来管理多个虚拟站点，⼀个Service最多只能有⼀个Engine，但是⼀个引擎可包含多个Host。
Host，代表⼀个虚拟主机，或者说⼀个站点，可以给Tomcat配置多个虚拟主机地址，⽽⼀个虚拟主机下可包含多个Context
Context，表示⼀个Web应⽤程序，⼀个Web应⽤可包含多个Wrapper
Wrapper，Servlet对应一个Wrapper封装，Wrapper 作为容器中的最底层，不能包含⼦容器

二、Tomcat的核心配置

上一节我们主要讲的Tomcat的架构和组件，其实其主要组件构成关系在核心配置文件server.xml中就有体现。

从上图就可以发现最外层是一个Server,Server有对全容器生效的基础支撑配置（listener,GlobalNamingResources...），同时Server中对应多个Service，Service中包含多个Connector（可配置线程池）和⼀个Engine，Engine中包含多个Host,每个Host又都可以对应webapps目录，可以读取下面多个web服务，实际就是架构中的context层，你也可以在配置中使用Context标签指定项目的位置的全路径：

三、Tomcat的核心流程

3.1 tomcat启动流程

3.2 tomcat的请求解析流程

3.3 tomcat的请求处理流程

四、Tomcat 类加载机制

Java类（.java）—> 字节码⽂件(.class) —> 字节码⽂件需要被加载到jvm内存当中（这个过程就是⼀个类加载的过程），类加载器（ClassLoader，说⽩了也是⼀个类，jvm启动的时候先把类加载器读取到内存当中去，其他的类（⽐如各种jar中的字节码⽂件，⾃⼰开发的代码编译之后的.class⽂件等等））。

要说 Tomcat 的类加载机制，⾸先需要来看看 Jvm 的类加载机制，因为 Tomcat 类加载机制是在 Jvm 类加载机制基础之上进⾏了⼀些变动。

4.1 jvm类加载机制

其中几大加载器：

BootstrapClassLoader，引导启动类加载器，c++编写，加载java核⼼库 java.*,⽐如rt.jar中的类，构造ExtClassLoader和AppClassLoade。
ExtClassLoader，扩展类加载器，java编写，加载扩展库 JAVA_HOME/lib/ext⽬录下的jar中的类，如classpath中的jre ，javax.*或者java.ext.dir指定位置中的类。
SystemClassLoader/AppClassLoader，系统类加载器，默认的类加载器，搜索环境变量 classpath 中指明的路径。
⾃定义类加载器，⽤户⾃定义的类加载器，可加载指定路径的 class ⽂件。

当某个类加载器需要加载某个.class⽂件时，它⾸先把这个任务委托给他的上级类加载器，递归这个操作，如果上级的类加载器没有加载，⾃⼰才会去加载这个类：

⽤户⾃⼰的类加载器，把加载请求传给⽗加载器，⽗加载器再传给其⽗加载器，⼀直到加载器树的顶层
最顶层的类加载器⾸先针对其特定的位置加载，如果加载不到就转交给⼦类。
如果⼀直到底层的类加载都没有加载到，那么就会抛出异常 ClassNotFoundException。

这个就是双亲委派机制，按照这个过程可以想到，如果同样在 classpath 指定的⽬录中和⾃⼰⼯作⽬录中存放相同的class，会优先加载 classpath ⽬录中的⽂件。

这样设计的作用主要是，防⽌重复加载同⼀个.class。通过委托去向上⾯问⼀问，加载过了，就不⽤再加载⼀遍。保证数据安全。保证核⼼.class不能被篡改。通过委托⽅式，不会去篡改核⼼.class，即使篡改也不会去加载，即使加载也不会是同⼀个.class对象了。不同的加载器加载同⼀个.class也不是同⼀个.class对象。这样保证了class执⾏安全（如果⼦类加载器先加载，那么我们可以写⼀些与java.lang包中基础类同名的类，然后再定义⼀个⼦类加载器，这样整个应⽤使⽤的基础类就都变成我们⾃⼰定义的类了。

4.2 tomcat的类加载机制

Tomcat 的类加载机制相对于 Jvm 的类加载机制做了⼀些改变。没有严格的遵从双亲委派机制，也可以说打破了双亲委派机制。这是因为如果加载了两个webapp下有两个相同的类，就会只执行优先加载的。所以tomcat设计了自己一套类加载机制。

在tomcat的类加载机制中：

引导类加载器和扩展类加载器的作⽤不变。
系统类加载器正常情况下加载的是 CLASSPATH 下的类，但是 Tomcat 的启动脚本并未使⽤该变量，⽽是让其加载tomcat启动的类，⽐如bootstrap.jar，通常在catalina.bat或者catalina.sh中指定。位于CATALINA_HOME/bin下。
Common 通⽤类加载器加载Tomcat使⽤以及应⽤通⽤的⼀些类，位于CATALINA_HOME/lib下，⽐如servlet-api.jar。
Catalina ClassLoader ⽤于加载服务器内部可⻅类，这些类应⽤程序不能访问。
Shared ClassLoader ⽤于加载应⽤程序共享类，这些类服务器不会依赖。
Webapp ClassLoader，每个应⽤程序都会有⼀个独⼀⽆⼆的Webapp ClassLoader，他⽤来加载本应⽤程序 /WEB-INF/classes 和 /WEB-INF/lib 下的类。

五、Tomcat 性能优化策略

系统性能的衡量指标，主要是响应时间和吞吐量。响应时间主要指执⾏某个操作的耗时，吞吐量：系统在给定时间内能够⽀持的事务数量，单位为TPS（Transactions PerSecond的缩写，也就是事务数/秒，⼀个事务是指⼀个客户机向服务器发送请求然后服务器做出反应的过程。

Tomcat优化从两个⽅⾯进⾏：

JVM虚拟机优化（优化内存模型）
Tomcat⾃身配置的优化（⽐如是否使⽤了共享线程池？IO模型？）

5.1 虚拟机运行优化

Java 虚拟机的运⾏优化主要是内存分配和垃圾回收策略的优化：

内存直接影响服务的运⾏效率和吞吐量
垃圾回收机制会不同程度地导致程序运⾏中断（垃圾回收策略不同，垃圾回收次数和回收效率都是不同的）

5.1.1 内存分配优化

JVM内存模型回顾：

Java 虚拟机内存相关参数：

参数调整示例：

JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -
XX:MaxMetaspaceSize=512m"

5.1.2 垃圾回收（GC）策略

垃圾回收性能指标：

吞吐量：⼯作时间（排除GC时间）占总时间的百分⽐，⼯作时间并不仅是程序运⾏的时间，还包含内存分配时间。
暂停时间：由垃圾回收导致的应⽤程序停⽌响应次数/时间。

垃圾收集器：

Serial Collector	串⾏收集器，单线程执⾏所有的垃圾回收⼯作，适⽤于单核CPU服务器，执行流程：⼯作进程-----\|（单线程）垃圾回收线程进⾏垃圾收集\|---⼯作进程继续
Parallel Collector	并⾏收集器，⼜称为吞吐量收集器（关注吞吐量），以并⾏的⽅式执⾏年轻代的垃圾回收，该⽅式可以显著降低垃圾回收的开销(指多条垃圾收集线程并⾏⼯作，但此时⽤户线程仍然处于等待状态)。适⽤于多处理器或多线程硬件上运⾏的数据量较⼤的应⽤。执行流程：⼯作进程-----\|（多线程）垃圾回收线程进⾏垃圾收集\|---⼯作进程继续
Concurrent Collector	并发收集器，以并发的⽅式执⾏⼤部分垃圾回收⼯作，以缩短垃圾回收的暂停时间。适⽤于那些响应时间优先于吞吐量的应⽤，因为该收集器虽然最⼩化了暂停时间(指⽤户线程与垃圾收集线程同时执⾏,但不⼀定是并⾏的，可能会交替进⾏)，但是会降低应⽤程序的性能。
Concurrent Mark Sweep Collector	CMS收集器，并发标记清除收集器，适⽤于那些更愿意缩短垃圾回收暂停时间并且负担的起与垃圾回收共享处理器资源的应⽤。
Garbage-First Garbage Collector	G1收集器，适⽤于⼤容量内存的多核服务器，可以在满⾜垃圾回收暂停时间⽬标的同时，以最⼤可能性实现⾼吞吐量(JDK1.7之后)。

垃圾回收器参数：

5.2 tomcat 配置调优

tomcat调优主要配置修改为：

5.2.1 使用和调整tomcat线程池

5.2.2 调整tomcat的连接器

修改Connector标签中的对应属性。springboot项目可以在配置文件修改。

server:
  tomcat:
    uri-encoding: UTF-8
    #最大工作线程数，默认200, 4核8g内存，线程数经验值800
    #操作系统做线程之间的切换调度是有系统开销的，所以不是越多越好。
    max-threads: 1000
    # 等待队列长度，默认100
   accept-count: 1000
    max-connections: 20000
    # 最小工作空闲线程数，默认10, 适当增大一些，以便应对突然增长的访问量
   min-spare-threads: 100