Tomcat是如何运行的?整体架构又是怎样的?

在许多的高端开发的岗位中都会或多或少有要求面试人员要研究过一些常用中间件源码。这是因为一切的秘密都是藏在源码中,阅读源码能够让我们对框架或者中间件的理解更加深刻,而我们也能够在源码的研究中获得其中一些优秀的设计方式。而我们的中间件和源码那么多,我们该从何入手呢?其实大部分的中间件或者框架都有一些共性的部分,例如网络编程、多线程、反射和类加载等技术。所以深入研究透了一两个中间件的话,那么再回过头来看其它的中间件,那么就会很容易理解它里面所用的技术以及原理。而作为一个老牌的WEB端框架Tomcat,无论是其整体的架构设计,还是其内在的一些技术灵活应用,都值得我们一看。

在学习框架的时候,我一般都是对这个框架有一个整体的认识。知道它整体是如何运行的,然后再深入其中某部分进行研究,这样会事半功倍。

整体架构

我们想要了解一个框架,首先要了解它是干什么的,Tomcat我们都知道,是用于处理连接过来的Socket请求的。那么Tomcat就会有两个功能:

  • 对外处理连接,将收到的字节流转化为自己想要的Request和Response对象
  • 对内处理Servlet,将对应的Request请求分发到相应的Servlet中

那么我们整体的骨架就出来了,Tomcat其实就分为两大部分,一部分是连接器(Connnector)处理对外连接和容器(Container)管理对内的Servelet。大体的关系图如下

最外层的大框就是代表一个Tomcat服务,一个Tomcat服务可以对应多个Service。每个Service都有连接器和容器。这些对应的关系我们也可以打开在Tomcat目录配置文件中server.xml中看出来。

<Server port="8006" shutdown="SHUTDOWN">
  <Service name="Catalina">

    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
    <Connector port="8010" protocol="AJP/1.3" redirectPort="8443" />

    <Engine name="Catalina" defaultHost="localhost">

      <Realm className="org.apache.catalina.realm.LockOutRealm">

        <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
               resourceName="UserDatabase"/>
      </Realm>

      <Host name="localhost"  appBase="webapps"

      </Host>
    </Engine>
  </Service>
</Server>

这里我将其中配置文件中删除了一些内容精简了一下,这里我们可以看到连接器其实就是Connector,一个Service中可以有多个连接器,容器其实对应的就是Engine

Tomcat的整体架构简单来说就是这样的对应关系。接下来我们简单的介绍连接器的整体架构和容器的整体架构。

连接器

我们可以看到上图中连接器传给容器的是ServletRequest对象,而容器传给连接器的是ServletResponse对象,这些在网络传输过程中是肯定不行的,因为网络传输中传送的字节流。所以连接器的功能需求我们大概能总结出来以下几点。

  • Socket连接
  • 读取请求网络中的字节流
  • 根据相应的协议(Http/AJP)解析字节流,生成统一的Tomcat Requestt对象
  • Tomcat Reques传给容器
  • 容器返回Tomcat Response对象
  • Tomcat Response对象转换为字节流
  • 将字节流返回给客户端

其实上面的细分都能总结为以下的三点

  • 网络通信
  • 应用层协议的解析
  • Tomcat的Request/ResponseServletRequest/ServletResponse对象的转化

而在Tomcat中它也用了三个类来实现上面的三个功能,分别对应如下

  • EndPoint
  • Processor
  • Adapter

用图表示他们的关系的话就是这样

容器

容器,顾名思义就是装东西的器具,那么这个Tomcat容器是装什么的呢?其实主要的就是装了Servlet的。那么容器是如何设计的呢?Tomcat的容器设计其实是用了组合设计模式。其实从Server.xml中我们也能看到其关系了。

  <Engine name="Catalina" defaultHost="localhost">
      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true">

      </Host>
    </Engine>

在这里面我们只能看到容器中的两个模块,一个是顶层模块Engine,另一个是Host,其实还有两个模块,一个是Context对应的是我们webapp里面的每个应用文件夹,每个文件夹就是对应一个Context,还有一个模块Wrapper对应的是我们Context中的所有servlet,Wrapper管理了访问关系与具体的Servlet的对应。图表示就是下面这样。

Tomcat中容器所有模块都实现了Container接口,而组合模式的意义就是使得用户对于单个对象和组合对象的使用具有一致性,即无论添加多少个Context其使用就是为了找到其下面的Servlet,而无论添加多少个Host也是为了找个下面的Servlet。而在容器中设计了这么多的模块,一个请求过来Tomcat如何找到对应的Servlet进行处理呢?

请求如何定位

我们就举个最简单的例子,我们本机应用上启动了一个Tomcat,webapp下有我们部署的一个应用buxuewushu。我们在浏览器上输入http://localhost:8080/buxuewushu/add.do是如何找到对应Servlet进行处理呢?

在我们启动Tomcat的时候,连接器就会进行初始化监听所配置的端口号,这里我们配置的是8080端口对应的协议是HTTP。

  • 请求发送到本机的8080端口,被在那里监听的HTTP/1.1的连接器Connector获得
  • 连接器Connector将字节流转换为容器所需要的ServletRequest对象给同级Service下的容器模块Engine进行处理
  • Engine获得地址http://localhost:8080/buxuewushu/add。匹配他下面的Host主机
  • 匹配到名为localhost的Host(就算此时请求为具体的ip,没有配置相应的Host,也会交给名为localhost的Host进行处理,因为他是默认的主机)
  • Host匹配到路径为/buxuewushu的Context,即在webapp下面找到相应的文件夹
  • Context匹配到URL规则为*.do的servlet,对应为某个Servlet类
  • 调用其doGet或者doPost方法
  • Servlet执行完以后将对象返回给Context
  • Context返回给Host
  • Host返回给Engine
  • Engine返回给连接器Connector
  • 连接器Connector将对象解析为字节流发送给客户端

原文地址:https://blog.51cto.com/14230003/2476437

时间: 2024-08-30 04:07:34

Tomcat是如何运行的?整体架构又是怎样的?的相关文章

tomcat原理解析(二):整体架构

一 整体结构 前面tomcat实现原理(一)里面描述了整个tomcat接受一个http请求的简单处理,这里面我们讲下整个tomcat的架构,以便对整体结构有宏观的了解.tomat里面由很多个容器结合在一起,主要有server,service,context,host,engine,wrapper,connector这7个容器来组装.当然了tomcat里面还有其它容器这里就不一一列举,因为我只看重点的.这7个容器存着父子关系,即可以通过当前容器找自己的父容器和自己的子容器.说到这我画了一个简单的结

Tomcat系列(一)- 整体架构

整体架构 我们想要了解一个框架,首先要了解它是干什么的,Tomcat我们都知道,是用于处理连接过来的Socket请求的.那么Tomcat就会有两个功能: 对外处理连接,将收到的字节流转化为自己想要的Request和Response对象 对内处理Servlet,将对应的Request请求分发到相应的Servlet中 那么我们整体的骨架就出来了,Tomcat其实就分为两大部分,一部分是连接器(Connnector)处理对外连接和容器(Container)管理对内的Servelet. 大体的关系图如下

Tomcat源码分析二:先看看Tomcat的整体架构

Tomcat源码分析二:先看看Tomcat的整体架构 Tomcat架构图 我们先来看一张比较经典的Tomcat架构图: 从这张图中,我们可以看出Tomcat中含有Server.Service.Connector.Container等组件,接下来我们一起去大致的看看这些组件的作用和他们之间的相互联系.在这之前,我们先补充一个知识点,也就是Tomcat它实现的功能点是什么呢?通过查找一些资料,这里参考下极客时间<深入拆解Tomcat_Jetty>中的总结,即Tomcat 要实现 2 个核心功能:

【深入浅出jQuery】源码浅析--整体架构(转)

最近一直在研读 jQuery 源码,初看源码一头雾水毫无头绪,真正静下心来细看写的真是精妙,让你感叹代码之美. 其结构明晰,高内聚.低耦合,兼具优秀的性能与便利的扩展性,在浏览器的兼容性(功能缺陷.渐进增强)优雅的处理能力以及 Ajax 等方面周到而强大的定制功能无不令人惊叹. 另外,阅读源码让我接触到了大量底层的知识.对原生JS .框架设计.代码优化有了全新的认识,接下来将会写一系列关于 jQuery 解析的文章. 我在 github 上关于 jQuery 源码的全文注解,感兴趣的可以围观一下

【深入浅出jQuery】源码浅析--整体架构

最近一直在研读 jQuery 源码,初看源码一头雾水毫无头绪,真正静下心来细看写的真是精妙,让你感叹代码之美. 其结构明晰,高内聚.低耦合,兼具优秀的性能与便利的扩展性,在浏览器的兼容性(功能缺陷.渐进增强)优雅的处理能力以及 Ajax 等方面周到而强大的定制功能无不令人惊叹. 另外,阅读源码让我接触到了大量底层的知识.对原生JS .框架设计.代码优化有了全新的认识,接下来将会写一系列关于 jQuery 解析的文章. 我在 github 上关于 jQuery 源码的全文注解,感兴趣的可以围观一下

jQuery整体架构源码解析

最近一直在研读 jQuery 源码,初看源码一头雾水毫无头绪,真正静下心来细看写的真是精妙,让你感叹代码之美. 其结构明晰,高内聚.低耦合,兼具优秀的性能与便利的扩展性,在浏览器的兼容性(功能缺陷.渐进增强)优雅的处理能力以及 Ajax 等方面周到而强大的定制功能无不令人惊叹. 另外,阅读源码让我接触到了大量底层的知识.对原生JS .框架设计.代码优化有了全新的认识,接下来将会写一系列关于 jQuery 解析的文章. 我在 github 上关于 jQuery 源码的全文注解,感兴趣的可以围观一下

Spring技术内幕:设计理念和整体架构概述

程序员都很崇拜技术大神,很大一部分是因为他们发现和解决问题的能力,特别是线上出现紧急问题时,总是能够快速定位和解决. 一方面,他们有深厚的技术基础,对应用的技术知其所以然,另一方面,在采坑的过程中不断总结,积累了很多经验. 相信大家都使用过Spring,有些人了解它的核心:IOC和AOP,但只是了解它们的基本概念.使用了反射和动态代理,关于如何管理对象.代理的具体实现了解的比较浅. 有些人使用Spring MVC,使用Spring集成数据库.事务.消息队列以简化操作,但对集成的具体设计思路和实现

LevelDB 整体架构

[LevelDB 整体架构]     从图中可以看出,构成LevelDb静态结构的包括六个主要部分:内存中的MemTable和Immutable MemTable以及磁盘上的几种主要文件:Current文件,Manifest文件,log文件以及SSTable文件.当然,LevelDb除了这六个主要部分还有一些辅助的文件,但是以上六个文件和数据结构是LevelDb的主体构成元素. LevelDb的Log文件和Memtable与Bigtable论文中介绍的是一致的,当应用写入一条Key:Value记

淘宝整体架构

一应用无状态(淘宝session框架) 假如在session中保存了大量与客户端的状态信息,保存状态信息的server宕机时 通常通过集群解决,不仅有负载均衡,更重要的是要有失效恢复failover tomcat用集群节点广播复制,jboss用配对复制等session状态复制策略,但严重影响系统的伸缩性,不能通过增加更多的机器达到良好的水平伸缩 因为集群节点间session通信随着节点的增多而开销增大,因此要想做到应用本身的伸缩性,要保证应用无状态,这样集群中的各个节点来说都是相同的,使系统更好