Tomcat源码解析(一)： Tomcat整体架构

2024-06-04 9497阅读

Tomcat源码系列文章

一、Tomcat整体架构
- 1、Tomcat两个核心组件功能
- 2、Tomcat支持的多种I/O模型和应用层协议
- 二、Connector连接器
- - 1、连接器功能汇总
  - 2、ProtocolHandler组件
  - - 2.1、Endpoint
    - 2.2、Processor
    - 3、Adapter组件
    - 三、Container容器
    - - 1、容器的基本组成
      - 2、server.xml配置文件
      - 3、请求定位Servlet的过程
      - 3.1、Mapper组件
        3.2、定位Servlet流程
        3.3、实现原理
        一、Tomcat整体架构
        
        1、Tomcat两个核心组件功能
        
        连接器（Connector）：处理Socket连接，负责网络字节流与Request和Response对象的转化
        容器（Container）：加载和管理Servlet，以及具体处理Request请求
        
        
        一个Server类的实例就代表了一个Tomcat的容器，一个Tomcat进程只会有一个Server实例
        一个Server实例可以包含多个Service对象(一个容器和多个连接器组合)
        2、Tomcat支持的多种I/O模型和应用层协议
        
        Tomcat支持的I/O模型
        
        NIO：非阻塞I/O，采用Java NIO类库实现
        NIO.2：异步I/O，采用JDK 7最新的NIO.2类库实现
        APR：采用Apache可移植运行库实现，是C/C++编写的本地库
        Tomcat支持的应用层协议
        
        HTTP/1.1：这是大部分Web应用采用的访问协议
        AJP：用于和Web服务器集成（如Apache）
        HTTP/2：HTTP 2.0大幅度的提升了Web性能
        
        
        Tomcat为了实现支持多种I/O模型和应用层协议，一个容器可能对接多个连接器
        单独的连接器或者容器都不能对外提供服务，需要把它们组装起来才能工作，组装后这个整体叫作Service组件
        通过在Tomcat中配置多个Service，可以实现通过不同的端口号来访问同一台机器上部署的不同应用
        二、Connector连接器
        
        1、连接器功能汇总
        
        连接器对Servlet容器屏蔽了协议及I/O模型等的区别，无论是HTTP还是AJP，在容器中获取到的都是一个标准的ServletRequest对象
        
        连接器细化功能
        
        监听网络端口
        接受网络连接请求
        读取网络请求字节流
        根据具体应用层协议（HTTP/AJP）解析字节流，生成统一的Tomcat Request对象
        将Tomcat Request对象转成标准的ServletRequest
        调用Servlet容器，得到ServletResponse
        将ServletResponse转成Tomcat Response对象
        将Tomcat Response转成网络字节流
        将响应字节流写回给浏览器
        连接器汇总功能
        
        网络通信
        应用层协议解析
        Tomcat Request/Response与ServletRequest/ServletResponse的转化
        Tomcat的设计者设计了3个组件来实现这3个功能，分别是Endpoint、Processor和Adapter
        
        Endpoint负责提供字节流给Processor
        Processor负责提供Tomcat Request对象给Adapter
        Adapter负责提供ServletRequest对象给容器
        2、ProtocolHandler组件
        
        由于I/O模型和应用层协议可以自由组合，比如NIO + HTTP或者NIO.2 + AJP
        Tomcat的设计者将网络通信和应用层协议解析放在一起考虑
        设计了一个叫ProtocolHandler的接口来封装这两种变化点
        各种协议和通信模型的组合有相应的具体实现类。比如：Http11NioProtocol和AjpNio2Protocol
        网络和协议相同点封装到抽象基类AbstractProtocol，每一种应用层协议有自己的抽象基类
        这样设计每一种I/O模型和协议的组合都有相应的具体实现类，我们在使用时可以自由选择
        特别说明：当前只有一个实现类Http2Protocol用于处理HTTP/2.0，不在以下体系内
        
        
        小结一下，连接器模块用三个核心组件：Endpoint、Processor和Adapter来分别做三件事情
        其中Endpoint和Processor放在一起抽象成了ProtocolHandler组件，它们的关系如下图所示
        
        
        2.1、Endpoint
        
        Endpoint是通信端点，即通信监听的接口，是具体的Socket接收和发送处理器，是对传输层的抽象，因此Endpoint是用来实现TCP/IP协议的
        Endpoint是一个接口，对应的抽象实现类是AbstractEndpoint，而AbstractEndpoint的具体子类，比如在NioEndpoint和Nio2Endpoint中，有两个重要的子组件：Acceptor和SocketProcessor
        Acceptor用于监听Socket连接请求
        SocketProcessor用于处理接收到的Socket请求，它实现Runnable接口，在run方法里调用协议处理组件Processor进行处理。为了提高处理能力，SocketProcessor被提交到线程池来执行。而这个线程池叫作执行器（Executor)
        2.2、Processor
        
        如果说Endpoint是用来实现TCP/IP协议的，那么Processor用来实现HTTP协议
        Processor接收来自Endpoint的Socket，读取字节流解析成Tomcat Request和Response对象，并通过Adapter将其提交到容器处理，Processor是对应用层协议的抽象
        Processor是一个接口，定义了请求的处理等方法
        它的抽象实现类AbstractProcessor对一些协议共有的属性进行封装，没有对方法进行实现
        具体的实现有AjpProcessor、Http11Processor等，这些具体实现类实现了特定协议的解析方法和请求处理方式
        3、Adapter组件
        
        由于协议不同，客户端发过来的请求信息也不尽相同，Tomcat定义了自己的Request类来“存放”这些请求信息
        ProtocolHandler接口负责解析请求并生成Tomcat Request类
        但是这个Request对象不是标准的ServletRequest，也就意味着，不能用Tomcat Request作为参数来调用容器
        Tomcat设计者的解决方案是引入CoyoteAdapter，这是适配器模式的经典运用
        连接器调用CoyoteAdapter的sevice方法，传入的是Tomcat Request对象
        CoyoteAdapter负责将Tomcat Request转成ServletRequest
        再调用容器的service方法
        三、Container容器
        
        1、容器的基本组成
        
        Tomcat设计了4种容器，分别是Engine、Host、Context和Wrapper
        这4种容器不是平行关系，而是父子关系
        
        
        Wrapper：表示一个Servlet，它负责管理Servlet的生命周期
        Wrapper作为容器中的最底层，不能包含子容器
        Context：表示一个Web应用程序，是Servlet、Filter的父容器
        一个Web应用可包含多个Wrapper
        Host：表示一个虚拟主机，包含主机名称和IP地址，默认是localhost
        Tomcat可以配置多个虚拟主机地址
        一个虚拟主机下可包含多个Context
        Engine：表示顶级容器，接受连接器的所有请求，并将响应返回给连接器
        一个Service最多只能有一个Engine，但是一个Engine可包含多个Host
        2、server.xml配置文件
        
        容器的父子包含关系，在在tomcat的conf目录下的server.xml配置文件中也有体现
        Server标签设置的端口号为8005，shutdown=”SHUTDOWN” ，表示在8005端口监听“SHUTDOWN”命令，如果接收到了就会关闭Tomcat
        
        根据上边的配置文件，查看源码目录
        
        
        Tomcat中默认的配置下webapps下的每一个文件夹目录都是一个Context
        其中ROOT目录中存放着主应用，其他目录存放着子应用，而整个webapps就是一个Host站点
        我们访问应用Context的时候，如果是ROOT下的则直接使用域名就可以访问，例如：www.ledouit.com
        如果是Host（webapps）下的其他应用，则可以使用www.ledouit.com/springmvc进行访问
        3、请求定位Servlet的过程
        
        3.1、Mapper组件
        
        Tomcat是用Mapper组件来确定请求是由哪个Wrapper容器里的Servlet来处理
        
        Mapper组件的功能就是将用户请求的URL定位到一个Servlet
        它的工作原理是：Mapper组件里保存了Web应用的配置信息
        其实就是容器组件与访问路径的映射关系
        比如Host容器里配置的域名、Context容器里的Web应用路径，以及Wrapper容器里Servlet映射的路径
        可以想象这些配置信息就是一个多层次的Map
        当一个请求到来时，Mapper组件通过解析请求URL里的域名和路径，再到自己保存的Map里去查找，就能定位到一个Servlet
        一个请求URL最后只会定位到一个Wrapper容器，也就是一个Servlet
        3.2、定位Servlet流程
        
        举例：一个网购系统
        
        有面向网站管理人员的后台管理系统，还有面向终端客户的在线购物系统
        这两个系统跑在同一个Tomcat上，为了隔离它们的访问域名，配置了两个虚拟域名： manage.shopping.com 和 user.shopping.com
        网站管理通过manage.shopping.com域名去管理用户和商品，而用户管理和商品管理是两个单独的Web应用
        终端客户通过user.shopping.com域名去搜索商品和下订单，搜索功能和订单管理也是两个独立的Web应用
        针对这样的部署，Tomcat会创建一个Service组件和一个Engine容器组件
        在Engine容器下创建两个Host子容器，在每个Host容器下创建两个Context子容器
        由于一个Web应用通常有多个Servlet，Tomcat还会在每个Context容器里创建多个Wrapper子容器
        每个容器都有对应的访问路径，可以通过下面这张图来帮助理解
        
        
        假如有用户访问一个URL，比如图中的http://user.shopping.com:8080/order/buy，Tomcat如何将这个URL定位到一个Servlet呢？
        
        根据协议和端口号选定Service和Engine
        Tomcat的每个连接器都监听不同的端口，比如Tomcat默认的HTTP连接器监听8080端口、默认的AJP连接器监听8009端口
        上面例子中的URL访问的是8080端口，因此这个请求会被HTTP连接器接收
        由Tomcat整体架构可知，连接器是属于某个Service组件的
        一个Service组件里除了有多个连接器，还有一个容器组件，也就能获取唯一Engine容器
        根据域名选定Host
        Service和Engine确定后，Mapper组件通过URL中的域名去查找相应的Host容器
        比如例子中的URL访问的域名是 user.shopping.com，因此Mapper会找到Host2这个容器
        根据URL路径找到Context组件
        Host确定以后，Mapper根据URL的路径来匹配相应的Web应用的路径
        比如例子中访问的是 /order，因此找到了Context4这个Context容器
        根据URL路径找到Wrapper（Servlet）
        Context确定后，Mapper再根据web.xml中配置的Servlet映射路径来找到具体的Wrapper和Servlet
        3.3、实现原理
        
        需要注意的是，并不是说只有Servlet才会去处理请求，实际上这个查找路径上的父子容器都会对请求做一些处理
        连接器中的Adapter会调用容器的Service方法来执行Servlet
        最先拿到请求的是Engine容器，Engine容器对请求做一些处理后，会把请求传给自己子容器Host继续处理，依次类推
        最后这个请求会传给Wrapper容器，Wrapper会调用最终的Servlet来处理
        具体实现是使用Pipeline-Valve管道
        Pipeline-Valve是责任链模式
        
        责任链模式是指在一个请求处理的过程中有很多处理者依次对请求进行处理
        每个处理者负责做自己相应的处理
        处理完之后将再调用下一个处理者继续处理
        Valve接口
        
        Valve是一个处理点，因此invoke方法就是来处理请求的
        Valve中有getNext和setNext方法，可以猜到有一个链表将Valve链起来了
        public interface Valve { // 获取下一个阀门 public Valve getNext(); // 设置下一个阀门 public void setNext(Valve valve); // 执行业务逻辑 public void invoke(Request request, Response response); }
        
        Pipeline接口
        
        Pipeline中维护了Valve链表，Valve可以插入到Pipeline中，对请求做某些处理
        Pipeline中没有invoke方法，因为整个调用链的触发是Valve来完成的
        Valve完成自己的处理后，调用 getNext.invoke 来触发下一个Valve调用
        public interface Pipeline { // 获取基本阀门 public Valve getBasic(); // 设置基本阀门 public void setBasic(Valve valve); // 添加阀门 public void addValve(Valve valve); // 获取阀门数组 public Valve[] getValves(); // 删除阀门 public void removeValve(Valve valve); // 获取首个阀门 public Valve getFirst(); }
        
        四种容器的执行流程
        
        每一个容器都有一个Pipeline对象，只要触发这个Pipeline的第一个Valve，这个容器里Pipeline中的Valve就都会被调用到
        但是，不同容器的Pipeline是怎么链式触发的呢，比如Engine中Pipeline需要调用下层容器Host中的Pipeline
        Pipeline中还有个getBasic方法
        这个BasicValve处于Valve链表的末端，它是Pipeline中必不可少的一个Valve
        负责调用下层容器的Pipeline里的第一个Valve
        
        整个调用过程由连接器中的Adapter触发的，它会调用Engine的第一个Valve
        // Calling the container connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);