【博学谷学习记录】超强总结，用心分享 | 架构师 Tomcat源码学习总结

Tomcat

Tomcat功能需求分析

浏览器发给服务端的是一个 HTTP 格式的请求，HTTP 服务器收到这个请求后，需要调用服务端程序来处理，所谓的服务端程序就是你写的 Java 类，一般来说不同的请求需要由不同的 Java 类来处理。那么问题来了，HTTP 服务器怎么知道要调用哪个 Java 类的哪个方法呢？

• HTTP 服务器直接调用具体业务类，它们是紧耦合的。

解决：HTTP 服务器不直接调用业务类，而是把请求交给容器来处理，容器通过 Servlet 接口调用业务
类。因此 Servlet 接口和 Servlet 容器的出现，达到了 HTTP 服务器与业务类解耦的目的。

Tomcat两个非常重要的功能（身份）

• Http服务器功能：Socket通信（TCP/IP）、解析Http报文
• Servlet容器功能：有很多Servlet（自带系统级Servlet+自定义Servlet），Servlet处理具体的业务逻辑

Tomcat的架构（设计实现）

Tomcat的需求是要实现 2 个核心功能：

• 处理 Socket 连接，负责网络字节流与 Request 和 Response 对象的转化。
• 加载和管理 Servlet，以及具体处理 Request 请求。

基于Tomcat需求，所以 Tomcat 设计了两个核心组件连接器（Connector）和容器（Container）来分别做这两件事情。

连接器负责对外交流，容器负责内部处理。

​ Tomcat中一个容器可能对接多个连接器，每一个连接器都对应某种协议某种IO模型,Tomcat将多个连接器和单个容器组成一个service组件，一个tomcat中可能存在多个Service组件

• Connector：将不同协议不同IO模型的请求转换为标准的标准的 ServletRequest 对象交给容器处理。
• Container：Container本质上是一个Servlet容器,负责servelt的加载和管理，处理请求ServletRequest，并返回标准的 ServletResponse 对象给连接器。

连接器的设计

铺垫：Tomcat 是支持多种 I/O 模型和应用层协议的

Tomcat 支持的 I/O 模型有：

• NIO：非阻塞 I/O，采用 Java NIO 类库实现
• NIO.2：异步 I/O，采用 JDK 7 最新的 NIO.2 类库实现
• APR：采用 Apache 可移植运行库实现，是 C/C++ 编写的本地库

Tomcat 支持的应用层协议有：

• TP/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 通信。

核心功能

连接器对 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。

由于 I/O 模型和应用层协议可以自由组合，比如 NIO + HTTP 或者 NIO.2 + AJP。Tomcat 的设计者将网络通信和应用层协议解析放在一起考虑，设计了一个叫 ProtocolHandler 的接口来封装这两种变化点

通过图清晰地看到它们的继承和层次关系，这样设计的目的是尽量将稳定的部分放到抽象基类，同时每一种 I/O 模型和协议的组合都有相应的具体实现类，我们在使用时可以自由选择。

ProtocolHandler 组件

1.EndPoint组件

Endpoint 翻译过来是"通信端点",主要负责网络通信,这其中就包括,监听客户端连接创建与客户端连接的Socket,并负责连接Socket 接收和发送处理器。因此Endpoint是对传输层的抽象，是用来实现 TCP/IP 协议的

EndPoint类结构图

EndPoint用基类用抽象类AbstractEndpoint来表示，对于不同的Linux IO模型通过使用不同子类来实现。

Endpoint 是一个接口，对应的抽象实现类是 AbstractEndpoint，而 AbstractEndpoint 的具体子类，比如在 NioEndpoint 和 Nio2Endpoint 中，有两个重要的子组件：Acceptor 和 SocketProcessor

其中 Acceptor 用于监听 Socket 连接请求。SocketProcessor 用于处理接收到的 Socket 请求，它实现Runnable 接口，在 run 方法里调用协议处理组件 Processor 进行处理。为了提高处理能力，SocketProcessor 被提交到线程池来执行。而这个线程池叫作执行器（Executor)

Acceptor接收连接包装Socket 给Poller

Poller：做IO事件检测，有IO事件绑定到一个SocketProcessorBase提交到线程中执行

线程池中：调用Processor完成协议解析，解析完后将请求交给Adapter

2.Processor组件

Processor：翻译过来是"处理器"，主要负责根据具体应用层协议（HTTP/AJP）读取字节流解析成Tomcat Request 和 Response，因此Processor是对应用层的抽象，是用来实现 HTTP/AJP 协议的。

Processor类结构图

Processor 是一个接口，定义了请求的处理等方法。它的抽象实现类 AbstractProcessor 对一些协议共有的属性进行封装，没有对方法进行实现。具体的实现有 AjpProcessor、Http11Processor 等，这些具体实现类实现了特定协议的解析方法和请求处理方式

3.Adapter组件

由于协议不同，客户端发过来的请求信息也不尽相同，Tomcat 定义了自己的 Request 类来“存放”这些请求信息。ProtocolHandler 接口负责解析请求并生成 Tomcat Request/Response类。但是这个Request/Response 对象不是标准的 ServletRequest/ServletResponse，也就意味着，不能用TomcatRequest/Response 作为参数来调用容器。
Tomcat 设计者的解决方案是引入 CoyoteAdapter，这是适配器模式的经典运用，负责将Tomcat
Request/Response 与 ServletRequest/ServletResponse 的相互转化，实现连接器（Connector）和容器（Container）的解耦。

4.ProtocolHandler组件

ProtocolHandler组件EndPoint组件，Processor组件合并在一起表示协议处理器。用来处理tomcat支持多种IO模型和多种协议的组件。

ProtocolHandler类图

Connector处理流程

Endpoint内部Acceptor组件用于监听Socket 连接请求，当发送客户端连接到服务端Acceptor组件负责与客户端建立连接创建Socket,每当连接客户端发起请求，Endpoint会创建一个
SocketProcessor对象SocketProcessor 用于处理接收到的 Socket 请求，它实现 Runnable 接口，在 run 方法里调用协议处理组件 Processor 进行处理。为了提高处理能力，SocketProcessor 被提交到线程池来执行。而这个线程池叫作执行器（Executor)
Processor 接收来自 Endpoint 的 Socket，读取字节流解析成 Tomcat Request 和 Response 对象，接着会调用 Adapter 的 Service 方法。并通过 Adapter 将其提交到容器处理
连接器调用 CoyoteAdapter 的 sevice 方法，传入的是 Tomcat Request 对象，CoyoteAdapter 负责将 Tomcat Request 转成 ServletRequest，再调用容器的 service 方法。

容器

容器的本质

Tomcat 有两个核心组件：连接器和容器

Container本质上是一个Servlet容器,负责servelt的加载和管理，处理请求ServletRequest，并返回标准的ServletResponse 对象给连接器。

容器工作流程

当客户请求某个资源时，HTTP 服务器会用一个 ServletRequest 对象把客户的请求信息封装起来，然后调用Servlet 容器的 service 方法，Servlet 容器拿到请求后，根据请求的 URL 和 Servlet 的映射关系，找到相应的Servlet，如果 Servlet 还没有被加载，就用反射机制创建这个 Servlet，并调用 Servlet 的init 方法来完成初始化，接着调用 Servlet 的 service 方法来处理请求，把 ServletResponse 对象返回给HTTP 服务器，HTTP 服务器会把响应发送给客户端

容器层次结构

Tomcat 设计了 4 种容器组件，分别是 Engine、Host、Context 和 Wrapper。这 4 种容器不是平行关系，而是父子关系。

• Wrapper:表示一个 Servlet
• Context:表示一个 Web 应用程序，一个 Web 应用程序中可能会有多个 Servlet
• Host:表示的是一个虚拟主机，或者说一个站点，可以给 Tomcat 配置多个虚拟主机地址，而一个虚拟主机下可以部署多个 Web 应用程序
• Engine:表示引擎，用来管理多个虚拟站点，一个 Service 最多只能有一个 Engine。

可以再通过 Tomcat 的server.xml配置文件来加深对 Tomcat 容器的理解。Tomcat 采用了组件化的设计，它的构成组件都是可配置的，其中最外层的是 Server，其他组件按照一定的格式要求配置在这个顶层容器中。

组件类图

Container容器中定义了Container 接口用来描述Container容器中所有的组件，不同的子组件分别定义了不同子接口做描述。容器组件之间具有父子关系。

从接口看到了 getParent、setParent、addChild 和 removeChild 等方法。可能还注意到 Container 接口扩展了 Lifecycle 接口，Lifecycle 接口用来统一管理各组件的生命周期

套娃式架构设计的好处

• 一层套一层的方式，其实组件关系还是很清晰的，也便于后期组件生命周期管理
• tomcat这种架构设计正好和xml配置文件中标签的包含方式对应上，那么后续在解读xml以及封装对象的过程中就容易对应
• 便于子容器继承父容器的一些配置