1. tomcat整体架构及其设计精髓分析-爱代码爱编程
MySQL性能调优
本文是按照自己的理解进行笔记总结，如有不正确的地方，还望大佬多多指点纠正，勿喷。
1.Servlet规范的设计理念分析
2.如何理解Tomcat=Http服务器+Servlet容器
3.结合server.xml理解Tomcat整体架构
4.连接器Connector的设计思路分析
5.适配器和模板方法模式在Tomcat中的应用
6.Tomcat多层容器(Container)的设计思路
7.请求定位servlet&请求调用过程分析
8.Tomcat生命周期设计思路剖析
9.组合和观察者模式在LifeCycle中的应用
1.Tomcat的整体架构
官方文档：https://tomcat.apache.org/tomcat-9.0-doc/index.html
1.1 Tomcat介绍
tomcat：应用服务器+servlet容器
server.xml
开源的Java Web 应用服务器，实现了 Java EE(Java Platform Enterprise Edition)的部 分技术规范，比如 Java Servlet、JavaServer Pages、Java Expression Language、Java WebSocket等。
Tomcat核心： Http服务器+Servlet容器
Servlet规范：Servlet接口+Servlet容器
1.1.1 Servlet基础回顾
https://note.youdao.com/ynoteshare/index.html?id=66522c749887b41f27af805a3ca200e8&type=note&_time=1641385214833
1.2 目录结构
Tomcat的解压之后的目录可以看到如下的目录结构
-
bin
- bin目录主要是用来存放tomcat的脚本，如
startup.sh , shutdown.sh
- bin目录主要是用来存放tomcat的脚本，如
-
conf
- catalina.policy: Tomcat安全策略文件,控制JVM相关权限,具体可以参考java. security.Permission
- catalina.properties : Tomcat Catalina行为控制配置文件,比如Common ClassLoader
- logging.properties : Tomcat日志配置文件, JDK Logging
server.xml : Tomcat Server配置文件- GlobalNamingResources :全局JNDI资源
- context.xml :全局Context配置文件
- tomcat-users.xml : Tomcat角色配置文件
- web.xml : Servlet标准的web.xml部署文件, Tomcat默认实现部分配置入内:
- org.apache.catalina.servlets.DefaultServlet
- org.apache.jasper.servlet.JspServlet
-
lib
公共类库 -
logs
tomcat在运行过程中产生的日志文件 -
webapps
用来存放应用程序，当tomcat启动时会去加载webapps目录下的应用程序 -
work
用来存放tomcat在运行时的编译后文件，例如JSP编译后的文件
1.3 web应用部署的方式
- 拷贝到webapps目录下
//指定appBase
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
其中autoDeploy意思是是否支持热部署，如果为true就是支持热部署，如果为false就是不支持热部署。
- server.xml 的Context标签下配置Context
<Context docBase="D:\mvc" path="/mvc" reloadable="true" />
这种方式有一个缺点就是它不支持热部署。
reloadable的意思是：编译之后不用再去加载了，因为是热加载。
path:指定访问该Web应用的URL入口（context-path）
docBase:指定Web应用的文件路径，可以给定绝对路径，也可以给定相对于的appBase属性的相对路径。
reloadable:如果这个属性设为true，tomcat服务器在运行状态下会监视在WEB-INF/classes和WEB-INF/lib目录下class文件的改动，如果监测到有class文件被更新的，服务器会自动重新加载Web应用。
- 在$CATALINA_BASE/conf/[enginename]/[hostname]/ 目录下（默认conf/Catalina/localhost）创建xml文件，文件名就是contextPath。
比如创建mvc.xml，path就是/mvc
访问：
<Context docBase="D:\mvc" reloadable="true" />
注意：想要根路径访问，文件名为ROOT.xml
1.4 结合Server.xml理解Tomcat架构
我们可以通过 Tomcat 的 server.xml 配置文件来加深对 Tomcat 架构的理解。Tomcat 采用了组件化的设计，它的构成组件都是可配置的，其中最外层的是 Server，其他组件按照一定的格式要求配置在这个顶层容器中。
<Server> //顶层组件，可以包括多个Service
<Service> //顶层组件，可包含一个Engine，多个连接器
<Connector/>//连接器组件，代表通信接口
<Engine>//容器组件，一个Engine组件处理Service中的所有请求，包含多个Host
<Host> //容器组件，处理特定的Host下客户请求，可包含多个Context
<Context/> //容器组件，为特定的Web应用处理所有的客户请求
</Host>
</Engine>
</Service>
</Server>
Tomcat启动期间会通过解析 server.xml，利用反射创建相应的组件，所以xml中的标签和源码一一对应。
1.5 架构图
简化之后的图
Tomcat 要实现 2 个核心功能：
- 处理 Socket 连接，负责网络字节流与 Request 和 Response 对象的转化。
- 加载和管理 Servlet，以及具体处理 Request 请求。
因此 Tomcat 设计了两个核心组件连接器（Connector）和容器（Container）来分别做这两件事情。连接器负责对外交流，容器负责内部处理。
2. Tomcat核心组件详解
2.1 Server 组件
指的就是整个 Tomcat 服务器，包含多组服务（Service），负责管理和启动各个Service，同时监听 8005 端口发过来的 shutdown 命令，用于关闭整个容器 。
2.2 Service组件
每个 Service 组件都包含了若干用于接收客户端消息的 Connector 组件和处理请求的 Engine 组件。 Service 组件还包含了若干 Executor 组件，每个 Executor 都是一个线程池，它可以为 Service 内所有组件提供线程池执行任务。
思考： 为什么要这么设计？
Tomcat 支持的多种 I/O 模型和应用层协议。Tomcat 支持的 I/O 模型有：
- BIO：阻塞式I/O，性能低下，8.5版本之后已经移除
- NIO：非阻塞 I/O，采用 Java NIO 类库实现，Tomcat内部实现了Reactor线程模型，性能较高
- AIO（NIO2）：异步 I/O，采用 JDK 7 最新的 NIO2 类库实现。
- APR：采用 Apache 可移植运行库实现，是 C/C++ 编写的本地库。是从操作系统级别来解决异步的IO问题，大幅度提高了性能
Tomcat 支持的应用层协议有：
- HTTP/1.1：这是大部分 Web 应用采用的访问协议。
- AJP：用于和 Web 服务器集成（如 Apache）。
- HTTP/2：HTTP 2.0 大幅度的提升了 Web 性能。
Tomcat 为了实现支持多种 I/O 模型和应用层协议，一个容器可能对接多个连接器，就好比一个房间有多个门，但是单独的连接器或者容器都不能对外提供服务，需要把它们组装起来才能工作，组装后这个整体叫作 Service 组件。Service 本身没有做什么重要的事情，只是在连接器和容器外面多包了一层，把它们组装在一起。Tomcat 内可能有多个 Service，这样的设计也是出于灵活性的考虑。通过在 Tomcat 中配置多个 Service，可以实现通过不同的端口号来访问同一台机器上部署的不同应用。
从上图可以看出，最顶层是 Server，这里的 Server 指的就是一个 Tomcat 实例。一个 Server 中有一个或者多个 Service，一个 Service 中有多个连接器和一个容器。连接器与容器之间通过标准的 ServletRequest 和 ServletResponse 通信。
2.3 连接器Connector组件
Tomcat 与外部世界的连接器，监听固定端口接收外部请求，传递给 Container，并将Container 处理的结果返回给外部。
连接器对 Servlet 容器屏蔽了不同的应用层协议及 I/O 模型，无论是 HTTP 还是 AJP，在容器中获取到的都是一个标准的 ServletRequest 对象。连接器需要实现的功能：
- 监听网络端口。
- 接受网络连接请求。
- 读取请求网络字节流。
- 根据具体应用层协议（HTTP/AJP）解析字节流，生成统一的 Tomcat Request 对象。
- 将 Tomcat Request 对象转成标准的 ServletRequest。
- 调用 Servlet 容器，得到 ServletResponse。
- 将 ServletResponse 转成 Tomcat Response 对象。
- 将 Tomcat Response 转成网络字节流。
- 将响应字节流写回给浏览器。
优秀的模块化设计应该考虑高内聚、低耦合：
高内聚是指相关度比较高的功能要尽可能集中，不要分散。
低耦合是指两个相关的模块要尽可能减少依赖的部分和降低依赖的程度，不要让两个模块产生强依赖。
分析连接器详细功能列表，我们会发现连接器需要完成 3 个高内聚的功能：
网络通信。应用层协议解析。Tomcat Request/Response 与 ServletRequest/ServletResponse 的转化。
因此 Tomcat 的设计者设计了 3 个组件来实现这 3 个功能，分别是 EndPoint、Processor 和 Adapter。
- EndPoint 负责提供字节流给 Processor；
- Processor 负责提供 Tomcat Request 对象给 Adapter；
- Adapter 负责提供 ServletRequest 对象给容器。
组件之间通过抽象接口交互。这样做的好处是封装变化。这是面向对象设计的精髓，将系统中经常变化的部分和稳定的部分隔离，有助于增加复用性，并降低系统耦合度。
由于 I/O 模型和应用层协议可以自由组合，比如 NIO + HTTP 或者 NIO2 + AJP。Tomcat 的设计者将网络通信和应用层协议解析放在一起考虑，设计了一个叫 ProtocolHandler 的接口来封装这两种变化点。各种协议和通信模型的组合有相应的具体实现类。比如：Http11NioProtocol 和 AjpNioProtocol。
除了这些变化点，系统也存在一些相对稳定的部分，因此 Tomcat 设计了一系列抽象基类来封装这些稳定的部分，抽象基类 AbstractProtocol 实现了 ProtocolHandler 接口。每一种应用层协议有自己的抽象基类，比如 AbstractAjpProtocol 和 AbstractHttp11Protocol，具体协议的实现类扩展了协议层抽象基类。
2.3.1 ProtocolHandler 组件
连接器用 ProtocolHandler 来处理网络连接和应用层协议，包含了 2 个重要部件：EndPoint 和 Processor。
连接器用 ProtocolHandler 接口来封装通信协议和 I/O 模型的差异，ProtocolHandler 内部又分为 EndPoint 和 Processor 模块，EndPoint 负责底层 Socket 通信，Proccesor 负责应用层协议解析。连接器通过适配器 Adapter 调用容器。
2.3.1.1 EndPoint
EndPoint 是通信端点，即通信监听的接口，是具体的 Socket 接收和发送处理器，是对传输层的抽象，因此 EndPoint 是用来实现 TCP/IP 协议的。
EndPoint 是一个接口，对应的抽象实现类是 AbstractEndpoint，而 AbstractEndpoint 的具体子类，比如在 NioEndpoint 和 Nio2Endpoint 中，有两个重要的子组件：Acceptor 和 SocketProcessor。其中 Acceptor 用于监听 Socket 连接请求。SocketProcessor 用于处理接收到的 Socket 请求，它实现 Runnable 接口，在 Run 方法里调用协议处理组件 Processor 进行处理。为了提高处理能力，SocketProcessor 被提交到线程池来执行，而这个线程池叫作执行器（Executor)。
2.3.1.2 Processor
Processor 用来实现 HTTP/AJP 协议，Processor 接收来自 EndPoint 的 Socket，读取字节流解析成 Tomcat Request 和 Response 对象，并通过 Adapter 将其提交到容器处理，Processor 是对应用层协议的抽象。
Processor 是一个接口，定义了请求的处理等方法。它的抽象实现类 AbstractProcessor 对一些协议共有的属性进行封装，没有对方法进行实现。具体的实现有 AJPProcessor、HTTP11Processor 等，这些具体实现类实现了特定协议的解析方法和请求处理方式。
EndPoint 接收到 Socket 连接后，生成一个 SocketProcessor 任务提交到线程池去处理，SocketProcessor 的 Run 方法会调用 Processor 组件去解析应用层协议，Processor 通过解析生成 Request 对象后，会调用 Adapter 的 Service 方法。
2.3.2 Adapter 组件
由于协议不同，客户端发过来的请求信息也不尽相同，Tomcat 定义了自己的 Request 类来“存放”这些请求信息。ProtocolHandler 接口负责解析请求并生成 Tomcat Request 类。但是这个 Request 对象不是标准的 ServletRequest，也就意味着，不能用 Tomcat Request 作为参数来调用容器。Tomcat 设计者的解决方案是引入 CoyoteAdapter，这是适配器模式的经典运用，连接器调用 CoyoteAdapter 的 Sevice 方法，传入的是 Tomcat Request 对象，CoyoteAdapter 负责将 Tomcat Request 转成 ServletRequest，再调用容器的 Service 方法。
设计复杂系统的基本思路：
首先要分析需求，根据高内聚低耦合的原则确定子模块，然后找出子模块中的变化点和不变点，用接口和抽象基类去封装不变点，在抽象基类中定义模板方法，让子类自行实现抽象方法，也就是具体子类去实现变化点。
2.4 容器Container组件
容器，顾名思义就是用来装载东西的器具，在 Tomcat 里，容器就是用来装载 Servlet 的。
Tomcat 通过一种分层的架构，使得 Servlet 容器具有很好的灵活性。Tomcat 设计了 4 种容器，分别是 Engine、Host、Context 和 Wrapper。这 4 种容器不是平行关系，而是父子关系。
- Engine：引擎，Servlet 的顶层容器，用来管理多个虚拟站点，一个 Service 最多只能有一个 Engine；
- Host：虚拟主机，负责 web 应用的部署和 Context 的创建。可以给 Tomcat 配置多个虚拟主机地址，而一个虚拟主机下可以部署多个 Web 应用程序；
- Context：Web 应用上下文，包含多个 Wrapper，负责 web 配置的解析、管理所有的 Web 资源。
一个Context对应一个 Web 应用程序。 - Wrapper：表示一个 Servlet，最底层的容器，
是对 Servlet 的封装，负责 Servlet 实例的创建、执行和销毁。
思考：Tomcat 是怎么管理这些容器的？
Tomcat 采用组合模式来管理这些容器。
具体实现方法是，所有容器组件都实现了 Container 接口，因此组合模式可以使得用户对单容器对象和组合容器对象的使用具有一致性。
Container 接口定义如下：
public interface Container extends Lifecycle {
public void setName(String name);
public Container getParent();
public void setParent(Container container);
public void addChild(Container child);
public void removeChild(Container child);
public Container findChild(String name);
}