精华内容
下载资源
问答
  • Tomcat架构

    千次阅读 2019-02-19 15:03:49
    现在的tomcat已经到9了,当tomcat下载安装完成后,其目录大致如下:   3.1、bin文件夹 bin文件夹下面放的是可执行性文件,其中:bat/exe文件是Windows下可执行的脚本文件。sh文件时Linux/Unix下可执行的脚本...

    tomcat目录结构

    tomcat的下载安装有很多教程,不再赘述。

    现在的tomcat已经到9了,当tomcat下载安装完成后,其目录大致如下:

    在这里插入图片描述

     

    3.1、bin文件夹

    bin文件夹下面放的是可执行性文件,其中:bat/exe文件是Windows下可执行的脚本文件。sh文件时Linux/Unix下可执行的脚本文件。

        bootstrap.jar:这个jar包是引导程序jar包,是tomcat的入口。
        catalina.bat:一个重要脚本,这个脚本完成了很多基本操作,如启动、关闭等,catalina.bat都参与其中,Windows中运行。
        catalina.sh:文件作用同catalina.bat,在Linux/Unix系统下运行。
        catalina-tasks.xml:配置文件,主要是引入各种jar包。
        configtest.bat:检测语法是否正确的脚本文件。
        configtest.sh:同上。
        service.bat:启动tomcat服务。和注册tomcat服务那块有关系。
        setclasspath.bat:设置classpath的脚本,在catalin.bat脚本中调用,可以设置java_home,jre_home等。
        shutdown.bat:主要是检查catalina.bat执行所需环境,并调用catalina.bat批处理文件关闭tomcat服务。
        startup.bat:主要是检查catalina.bat执行所需环境,并调用catalina.bat 批处理文件启动tomcat服务。
        tcnative-1.dll:加速器组件,可以提高性能。
        tomcat-native.tar.gz:里面放的是tomcat本地的library。
        tool-wrapper.bat:工具包装脚本。
        version.bat:一般是用来判断系统版本获取系统版本信息等。

    3.1、conf文件夹

    存放tomcat服务器的配置文件。

        catalina.policy:当Tomcat在安全模式下运行,此文件为默认的安全策略配置。
        catalina.properties:catalina环境变量配置。
        context.xml:用于定义所有Web应用均需要加载的Context配置,如果Web应用指定了自己的context.xml,那么该文件的配置会被覆盖。
        logging.properties:日志配置文件,可修改日志级别和日志路径等。
        server.xml:核心配置文件,用于配置链接器、监听端口、处理请求的虚拟主机等,可以说,tomcat根据该配置文件创建服务器实例。
        tomcat-users.xml:tomcat配置用户的文件,用于定义tomcat默认用户及角色映射信息,tomcat的manage模块使用该文件中定义的用户进行安全认证。
        web.xml:tomcat中所有应用默认的部署描述文件,主要定义了基础Servlet和MIME映射,如果应用中不包含web.xml,tomcat将使用此文件初始化部署描述,反之,tomcat会将默认部署描述与自定义配置进行合并。

    server.xml文件重点关注一下:

    里面详细配置可以参考这篇文章:
    server.xml配置详解
    3.3、lib文件夹

    tomcat依赖库目录,包含tomcat服务器运行环境依赖jar包。
    3.4、logs文件夹

    默认的日志存放文件夹。
    3.5、webapps文件夹

    默认的web应用部署目录。
    3.6、work文件夹

    web应用jsp代码生成和编译临时目录。清空work目录,然后重启tomcat,可以达到清除缓存的作用。sp文件在被翻译后,保存在当前这个目录下,session对象被序列化之后保存的位置。
     

     

    展开全文
  • 本文以 Tomcat 5 为基础,也...Tomcat 的基本设计思路和架构是具有一定连续性的。 Tomcat 总体结构 Tomcat 的结构很复杂,但是 Tomcat 也非常的模块化,找到了 Tomcat 最核心的模块,您就抓住了 Tomcat 的“七寸”。
  • Tomcat基本架构解析(Tomcat架构解析学习笔记)

    万次阅读 多人点赞 2018-12-06 10:42:56
    1.Tomcat组件架构设计    1)server  服务器可以描述为这样一个应用:接收客户端发来的请求数据并进行解析,完成相关业务处理,然后把处理结果作为相应返回给客户端。  通常我们可以使用serversocket监听...

    1.Tomcat组件架构设计

     

        1)server

            服务器可以描述为这样一个应用:接收客户端发来的请求数据并进行解析,完成相关业务处理,然后把处理结果作为相应返回给客户端。

            通常我们可以使用serversocket监听指定端口来实现该功能

     

        2)Connection和Container(Engine)

            当我们将请求监听和请求处理放在一起的时候扩展性就很差。比如当我们想适配多种网络协议,但是请求处理却相同的时候。

            处理方案就是:将网络协议和请求处理从概念上分开。Connection负责开启socket并监听客户端请求、返回响应数据;Container(Engine)负责具体的请求处理。

     

        3)Service

            上述方案的缺陷就是无法很好的判断Connection由哪个Container(Engine)来处理。

            采用service方案,一个server包含多个service(它们相互独立),一个service包含多个Connection和一个Container,这样,connection的请求只能由该container来处理

            由于Container表示一个更加通用的概念,为了与Tomcat组件命名一致,将Container重新命名为Engine,用于表示整个servlet引擎

     

        4)Context

            上述解决了网络协议和容器的解耦。下面我们需要在Engine中支持管理web应用。当接收到Connection请求时,能够找到一个合适的Web应用来处理。Context就代表一个Web应用

     

        5)Host

            为了提供对多个域名的服务,我们可以将每个域名视为一个虚拟的主机。在每个Host下包含多个Context

           

        6)Wrapper

            在一个Web应用中,可以包含多个servlet实例来处理不同链接的请求。因此,需要一个组件概念来表示Servlet定义,在Tomcat中servlet定义被称为Wrapper

     

        7)Container

            容器代表一类组件,这类组件的作用就是接收客户端请求并返回响应数据,具体操作委派到子组件完成。

            Engine、Host、Context、Wrapper均继承自Container

        8)LifeCycle

            所有的组件均存在启动、停止等生命周期方法,拥有生命周期管理的特性,我们将这个抽取出来作为接口LifeCycle,定义生命周期管理的核心方法。

        9)Executor

            tomcat的并发,提供了Executor接口来表示一个可以在组件间共享的线程池。该接口同样继承LifeCycle接口

            共享范围:Executor由Service维护,因此同一个Service中的组件可以共享一个线程池

            

        10)Bootstrap和Catalina

            Catalina提供一个shell程序,用于解析service.xml创建各个组件。同时负责启动、停止应用服务器

            Bootstrap作为应用服务器启动入口。Bootstrap负责创建Catalina,根据执行参数调用Catalina相关方方法完成对应用服务器的操作

     

        总结:

            * Server 表示整个servlet容器,因此Tomcat容器中只有一个Server实例

            * Service 表示一个或多个Connector的集合。这些Connector共享同一个Container来处理其他请求。在一个Server中可以包含多个Service,这些Service相互独立

            * Connector Tomcat连接器,用于监听并转换为Socket请求,将该请求交由Container处理,支持不同的协议及不同IO方式

            * Container 表示能够接收请求并返回响应的一类对象。在Tomcat中存在不同级别的容器:Engine、Host、Context、Wrapper

            * Engine 表示整个Servlet引擎,Engine为最高级别的容器。尽量Engine不是直接处理请求的容器却是获得目标容器的入口

            * Host 表示Engine中的虚拟机,与一个服务器的网络名有关,如域名等。客户端可以使用这个网络名连接服务器,这个名称必须要在DNS服务器上注册

            * Context 用于表示ServletContext,在Servlet规范中,一个ServletContext表示一个Web应用

            * Wrapper 表示Web应用中定义的Servlet

            * Executor 表示Tomcat组件间可以共享的线程池

     

     

    2.请求处理过程

     

        从本质上讲,应用服务器的处理开始于监听的Socket端口接收到数据,结束于将处理结果写入Socket输出流

        * 应用服务器将请求按照既定协议进行读取,并将其封装为与具体协议无关的请求体

        * 按照请求映射规则将请求定位到具体的处理单元(使用框架的话SpringMVC等则会将请求匹配到Servlet下的一个控制器)

        * 业务处理结束,将结果封装到一个与协议无关的响应对象

     

    3.Tomcat类加载方案

     

        应用服务器通常会创建类加载器以实现更灵活的控制。

        * 隔离性:Web应用类库互相隔离,避免依赖库或应用包相互影响。设想有两个应用,一个采取Spring2.X,一个采取Spring4.X,而应用服务器使用同一个类加载器,那么应用之间会因为jar包覆盖导致无法启动

        * 灵活性:Web应用之间的类加载器相互独立,我们就能只针对一个Web应用重新部署

        * 性能:每个Web应用都有一个类加载器,则Web应用在加载类时,不会搜索其他Web应用包含的jar包,性能自然高

        1)Common 位于Tomcat顶层的公共类加载器,默认指向Tomcat_home/lib下的包

        2)Catalina 用于加载Tomcat应用服务器的类加载器,路径为server.loader,默认为空

        3)Shared 所有web应用的父加载器,路径为shared.loader,默认为空

        4)Web 加载WEB-INF/classes下的未压缩的class、资源文件及WEB-INFO/lib下的jar包,该类加载器只对当前web应用可见

     

        在catalina.jar org.apache.catalina.loader包下可以看到关于ClassLoader的实现

     

     

    4.通过server.xml来查看Tomcat各组件之间的关系

        我们在Eclipse中创建一个web项目,springweb,并在Eclipse中关联Tomcat8.5,并在Tomcat中关联springweb,启动Tomcat,可以看到生成的server.xml如下所示:

    <?xml version="1.0" encoding="UTF-8"?>
    <Server port="8005" shutdown="SHUTDOWN">
      <Listener className="org.apache.catalina.startup.VersionLoggerListener"/>
      <!-- Security listener. Documentation at /docs/config/listeners.html
      <Listener className="org.apache.catalina.security.SecurityListener" />
      -->
      <!--APR library loader. Documentation at /docs/apr.html -->
      <Listener SSLEngine="on" className="org.apache.catalina.core.AprLifecycleListener"/>
      <!-- Prevent memory leaks due to use of particular java/javax APIs-->
      <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
      <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
      <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"/>
    
      
      <GlobalNamingResources>
       
        <Resource auth="Container" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" name="UserDatabase" pathname="conf/tomcat-users.xml" type="org.apache.catalina.UserDatabase"/>
      </GlobalNamingResources>
    
      <!-- A "Service" is a collection of one or more "Connectors" that share
           a single "Container" Note:  A "Service" is not itself a "Container",
           so you may not define subcomponents such as "Valves" at this level.
           Documentation at /docs/config/service.html
       -->
      <Service name="Catalina">
        <!-- A "Connector" represents an endpoint by which requests are received
             and responses are returned. Documentation at :
             Java HTTP Connector: /docs/config/http.html
             Java AJP  Connector: /docs/config/ajp.html
             APR (HTTP/AJP) Connector: /docs/apr.html
             Define a non-SSL/TLS HTTP/1.1 Connector on port 8080
        -->
        <Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"/>
        <!-- Define an AJP 1.3 Connector on port 8009 -->
        <Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/>
    
    
        <!-- An Engine represents the entry point (within Catalina) that processes
             every request.  The Engine implementation for Tomcat stand alone
             analyzes the HTTP headers included with the request, and passes them
             on to the appropriate Host (virtual host).
             Documentation at /docs/config/engine.html -->
    
        <!-- You should set jvmRoute to support load-balancing via AJP ie :
        <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
        -->
        <Engine defaultHost="localhost" name="Catalina">
          <!-- Use the LockOutRealm to prevent attempts to guess user passwords
               via a brute-force attack -->
          <Realm className="org.apache.catalina.realm.LockOutRealm">
            <!-- This Realm uses the UserDatabase configured in the global JNDI
                 resources under the key "UserDatabase".  Any edits
                 that are performed against this UserDatabase are immediately
                 available for use by the Realm.  -->
            <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
          </Realm>
    
          <Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true">
    
            <!-- SingleSignOn valve, share authentication between web applications
                 Documentation at: /docs/config/valve.html -->
            <!--
            <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
            -->
    
            <!-- Access log processes all example.
                 Documentation at: /docs/config/valve.html
                 Note: The pattern used is equivalent to using pattern="common" -->
            <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" pattern="%h %l %u %t &quot;%r&quot; %s %b" prefix="localhost_access_log" suffix=".txt"/>
    
          <Context docBase="springweb" path="/springweb" reloadable="true" source="org.eclipse.jst.jee.server:springweb"/></Host>
        </Engine>
      </Service>
    </Server>

        由上可知,Tomcat结构图可如下所示:

        * Tomcat只要一个Server,一个Server可以有多个Service,一个Service可以有多个Connection和Container

        * Server掌管整个Tomcat的生死大权

        * Service是对外提供服务的

        * Connector用于接收请求并将请求封装成Request和Response来具体处理

        * Container用于管理和封装Servlet,以及处理具体Request请求

     

    参考:Tomcat架构解析(刘光瑞)

     

    展开全文
  • tomcat 架构解析

    2018-12-13 12:09:37
    Tomcat架构解析 基于Tomcat 8.5.x全面介绍了Tomcat的架构、各组件的实现方案以及使用方式,主要包括Tomcat的基础组件架构以及工作原理,Tomcat各组件的实现方案、使用方式以及详细配置说明,Tomcat与Web服务器集成...
  • tomcat 架构解析和优化。pdf tomcat 架构解析和优化。pdftomcat 架构解析和优化。pdf
  • tomcat架构解析

    2019-10-19 19:47:30
    都是由于对web容器的认知不足,本书基于Tomcat 8.5.6全面介绍了Tomcat架构、各组件的实现方案以及使用方式,主要包括Tomcat的基础组件架构以及工作原理,Tomcat与Web服务器集成以及性能优化,Tomcat部分扩展特性...
  • Nginx+KeepAlived+Tomcat负载架构 这个可以实现tomcat集群,并且可以使服务器主备机进行切换。如果其中一台机器当机,会自动切换到另一台机器。客服端感受不到服务器当掉。非常实用。
  • tomcat总体架构

    2019-01-03 20:30:32
    tomcat总体架构UML图,对于tomcat清晰图解,谢谢!!!!
  • tomcat架构

    2018-03-21 16:06:39
    从源码级别解析tomcat架构,Java Web架构开发人员工具丛书
  • tomcat 架构 分析

    2014-11-13 09:15:26
    以类图,剪短的文字讲解了tomcat架构。真正做到会用tomcat和懂tomcat内部运行机制。
  • 基于Tomcat的全面解析应用服务器架构 涵盖Tomcat所有组件的详细配置
  • Tomcat系统架构.docx

    2021-10-19 15:28:41
    tomcat系统架构
  • 简介:这个分为两个部分的系列文章将研究ApacheTomcat的系统架构以及其运用的很多经典设计模式。本文是第1部分,将主要从Tomcat如何分发请求、如何处理多用户同时请求,还有它的多级容器是如何协调工作的角度来分析...
  • 其次,本书不局限于对Tomcat架构原理的讲解。对于像服务器这种技术方案相对复杂的应用程序,作为技术人员我们天生的就会好奇它是怎么高效的工作的。那么好奇之后呢?无外乎两点:1、借鉴它某些组件的原理,应用到...
  • Tomcat总体架构 1

    2021-08-31 07:08:22
    Tomcat总体架构_1
  • Tomcat总体架构 2

    2021-08-31 07:08:05
    Tomcat总体架构_2
  • Tomcat总体架构 3

    2021-08-31 07:07:49
    Tomcat总体架构_3
  • 这本书把tomcat的内部原理讲解的很清楚,对于想了解web容器和tomcat的各位是不可多得的好教材
  • tomcat整体目录结构 bin:可执行文件,.sh结尾的表示linux可执行文件,.bat结尾的表示linux可执行文件 conf:配置文件 lib:tomcat相关jar包 temp:临时文件 webapps:存放项目 work:工作目录 二 各文件夹...

    java中,常用的web服务器一般由tomcat,weblogic,jetty,undertwo等,但从用户使用广泛度来说,tomcat用户量相对比较大一些,当然这也基于它开源和免费的特点。

    从软件架构的发展角度来看,软件架构大致经历了如下几个阶段(当然,我们这篇文章不是主讲架构的,因此只是简单提一下架构发展,至于具体的架构,会在后面的文章中陆续与大家分享架构系列):

    那么从java web角度来说,架构大致经历了:

    Sevlet架构=》SSH架构=》SSM架构=》分布式垂直架构=》SOA架构=》微服务架构

    从当前企业使用的架构角度来说,企业使用SSM架构项目比较多,SSH基本别淘汰(大部分都是老项目维护),最近2年,也有一部分企业开始转向微服务架构了。

    基于java spring生态来说,如今,大部分中小型企业都基本使用springboot,springboot本身集成了tomcat,jetty和undertwo容器,那么我们为什么要花时间来研究tomcat呢?

    1.当前tomcat依然是主流java web容器,研究它,符合java 技术生态发展;

    2.在java web项目调优中,如ssm项目中,在优化项目时,jvm和tomcat同样重要,都需要优化;

    3.尽管springboot内置了tomcat容器,且配置了默认的tomcat参数,但当默认的tomcat参数满足不了项目优化要求时,就需要优化人员手动进行相关的参数优化,因此研究tomcat非常必要;

    4.熟悉tomcat架构,是后续进行项目优化的基础,也是必备条件

           基于如上原因但不限于如上原因,本篇文章将从tomcat架构角度分析tomca架构。本篇文件主要内容包括:简要分析tomcat架构和tomcat项目文件介绍,更深入的架构浅析,将在下篇文章中讲述。

    一 Tomcat架构

    通过tomcat官方发行,tomcat发展还是比较快的,目前已经更新到tomcat 10了 ,但当前大部分企业使用的tomcat为9或8版本。

    通过阅读tomcat源码,tomcat简要架构可归结为如下(关于更详细的架构图和架构细节,将在详解tomcat架构(下篇)中分享)。

    从上图中,可以得出:

    1.tomcat重要主件:

    Server主件:作为tomcat服务器主件

    service主件:作为tomcat服务主件,即向外提供服务,由一个或多个Host组成

    Connector主件:表示连接主件,外部访问tomcat时,通过该主键访问,其支持的比较重要的三个核心协议,http,https和ajp

    Engine主件:tomcat引擎主件

    Host主件:Tomcat主机主件

    Context:tomcat项目主件,一个Context代表也给tomcat项目

    2.tomcat支持的三大协议

    http协议,ajp协议,https协议。

        关于更复杂的架构细节,在下一篇文章中分享。

    二  tomcat目录结构

    bin:可执行文件,.sh结尾的表示linux可执行文件,.bat结尾的表示linux可执行文件

    conf:配置文件

    lib:tomcat相关jar包

    temp:临时文件

    webapps:存放项目

    work:工作目录

    三 Tomcat各目录结构详细介绍

    (一)bin

    bin目录存放可执行文件,简要结束常用命令:

    这里主要解释如下通用的命令,其他命令就不一一介绍

    startup.sh  程序项目命令文件

    version.sh  查看tomcat版本相关信息命令文件

    shutdown.sh  关闭程序命令

    (二) conf

    conf文件夹用来存放tomcat相关配置文件

    1.catalina.policy

    项目安全文件,用来防止欺骗代码或JSP执行带有像System.exit(0)这样的命令的可能影响容器的破坏性代码. 只有当Tomcat用-security命令行参数启动时这个文件才会被使用,即启动tomcat时,startup.sh  -security。

          上图中,tomcat容器下部署两个项目,项目1和项目2。由于项目1中有代码System.exit(0),当访问该代码时,该代码会导致整个tomcat停止,从而也导致项目2停止。

          为了解决因项目1存在欺骗代码或不安全代码导致损害Tomcat容器,从而影响其他项目正常运行的问题,启动tomcat容器时,加上-security参数就,即startup.sh  -security,如此即使项目1中有代码System.exit(0),也只会仅仅停止项目1,而不会影响Tomcat容器,然而起作用的配置文件就是catalina.policy文件。

    2.catalina.properties 

    配置tomcat启动相关信息文件

    3.context.xml 

    监视并加载资源文件,当监视的文件发生发生变化时,自动加载

    4.jaspic-providers.xml 和 jaspic-providers.xsd

    这两个文件不常用

    5.logging.properties

    该文件为tomcat日志文件,包括配置tomcat输出格式,日志级别等

    6.server.xml

    tomcat核心架构主件文件,在下一一篇文章中重点从架构角度分析。

    7.tomcat-users.xml和tomcat-users.xsd

    tomcat用户文件,如配置远程登陆账号,参考我的另外一篇博文

    https://blog.csdn.net/u010228798/article/details/104822043

    tomcat-users.xsd 为tomcat-users.xml描述和约束文件

    8.web.xml

    tomcat全局配置文件。

    (三) lib

    lib文件夹主要用来存放tomcat依赖jar包,如下为tomcat 10的lib文件夹下的相关jar包。

    每个jar包功能,这里就不讲解了,这里主要分析ecj-4.13.jar,这个jar包起到将.java编译成.class字节码作用。

    假设要编译MyTest.java,那么jdk会执行两步:

    第一步:将MyTest.java编译成MyTest.class

        javac  MyTest.java

    第二步:执行MyTest.class

        java MyTest.class

    那么,使用ecj-4.13.jar如执行MyTest.java呢?

     java -jar ecj-4.13.jar MyTest.java

    (四)logs

    该文件夹表示tomcat日志文件,大致包括如下六类文件:

    catalina.date.log,catalina.out,host-manager.date.log,localhost.date.log.localhost_access_log.date.txt和manager.date.log

    catalina.date.log(如catalina.2020-03-17.log):

    表示tomcat启动文件,需要注意的是,该文件只有在重启tomcat情况下,才会产生。

    manager.date.log(如manager.2020-03-17.log): 

    表示访问webapps下manager项目日志,如访问 ip:8080/manager/html

    host-manager.date.log(如host-manager.2020-03-17.log):   

    表示访问webapps下host-manager项目日志,如访问 ip:8080/host-manager/html

    localhost.date.log(如localhost.2020-03-17.log):

    (?)表示tomcat在启动时,自身访问服务,这个日志只记录tomcat访问日志,而非业务项目日志

    localhost_access_log.date.txt(如localhost_access_log.2020-03-17.txt)

    表示访问tomcat所有项目的日志记录,如下表示访问项目localhost,host-manager.html,manager.html和test/index.html四个项目日志记录

    catalina.out:

    表示catalina.date.log日志汇总,如2020.3.7和2020.3.8两天分别启动了tomcat,则会阐述如下两个日志:

    catalina.2020-03-17.log和catalina.2020-03-18.log

    那么,catalina.out内容就是catalina.2020-03-17.log加catalina.2020-03-17.log日志内容

    四  本系列文章

    1.基于linux和windows部署tomcat

    2.配置tomcat远程访问:https://blog.csdn.net/u010228798/article/details/104822043

    3.tomcat部署程序的四种方式

    4.详解tomcat架构(上篇)

    5.详解tomcat架构(下篇)

    6.详解JVM优化相关参数

    7.详解jvm优化工具:jconsole和jvisualvm

    8.使用idea解读tomcat源码

    9.解决idea下乱码问题:https://blog.csdn.net/u010228798/article/details/93355667

    10.优化tomcat

    五  版权区

    感谢您的阅读,若有不足之处,欢迎指教,共同学习、共同进步。

     从入门到架构群:820424。

     极少部分文章利用读书、参考、引用、抄袭、复制和粘贴等多种方式整合而成的,大部分为原创。

     如您喜欢,麻烦推荐一下;如您有新想法,欢迎提出,邮箱:2098469527@qq.com。

    demo访问地址:http://106.14.139.196/SaleManage/Index ,本套源码49元,需要购买请咨询:2098469527

     可以转载该博客,但必须著名博客来源

    展开全文
  • tomcat架构解析.pdf

    2019-07-23 09:36:31
    本书从功能组件、协议、规范,到详细配置等各个方面,系统性介绍了Tomcat架构的实现方案及使用方式,有助于读者详细了解应用服务器的架构及工作原理。主要内容包括: ★ Tomcat的基础组件架构及工作原理; ★ ...
  • 四张图带你了解Tomcat系统架构

    万次阅读 多人点赞 2018-01-09 09:59:21
    俗话说,站在巨人的肩膀上看世界,... Tomcat最核心的模块,问题才可以游刃而解,了解了Tomcat的整体架构对以后深入了解Tomcat来说至关重要! 一、Tomcat顶层架构 先上一张Tomcat的顶层结构图(图A),如下:

    俗话说,站在巨人的肩膀上看世界,一般学习的时候也是先总览一下整体,然后逐个部分个个击破,最后形成思路,了解具体细节,Tomcat的结构很复杂,但是 Tomcat 非常的模块化,找到了 Tomcat最核心的模块,问题才可以游刃而解,了解了Tomcat的整体架构对以后深入了解Tomcat来说至关重要!

    一、Tomcat顶层架构

    先上一张Tomcat的顶层结构图(图A),如下:


    Tomcat中最顶层的容器是Server,代表着整个服务器,从上图中可以看出,一个Server可以包含至少一个Service,用于具体提供服务。

    Service主要包含两个部分:Connector和Container。从上图中可以看出 Tomcat 的心脏就是这两个组件,他们的作用如下:

    1、Connector用于处理连接相关的事情,并提供Socket与Request和Response相关的转化; 2、Container用于封装和管理Servlet,以及具体处理Request请求;

    一个Tomcat中只有一个Server,一个Server可以包含多个Service,一个Service只有一个Container,但是可以有多个Connectors,这是因为一个服务可以有多个连接,如同时提供Http和Https链接,也可以提供向相同协议不同端口的连接,示意图如下(Engine、Host、Context下边会说到):


    多个 Connector 和一个 Container 就形成了一个 Service,有了 Service 就可以对外提供服务了,但是 Service 还要一个生存的环境,必须要有人能够给她生命、掌握其生死大权,那就非 Server 莫属了!所以整个 Tomcat 的生命周期由 Server 控制。

    另外,上述的包含关系或者说是父子关系,都可以在tomcat的conf目录下的server.xml配置文件中看出,下图是删除了注释内容之后的一个完整的server.xml配置文件(Tomcat版本为8.0)


    详细的配置文件文件内容可以到Tomcat官网查看:http://tomcat.apache.org/tomcat-8.0-doc/index.html

    上边的配置文件,还可以通过下边的一张结构图更清楚的理解:


    Server标签设置的端口号为8005,shutdown=”SHUTDOWN” ,表示在8005端口监听“SHUTDOWN”命令,如果接收到了就会关闭Tomcat。一个Server有一个Service,当然还可以进行配置,一个Service有多个,Service左边的内容都属于Container的,Service下边是Connector。

    二、Tomcat顶层架构小结:

    (1)Tomcat中只有一个Server,一个Server可以有多个Service,一个Service可以有多个Connector和一个Container; 
    (2) Server掌管着整个Tomcat的生死大权; 
    (4)Service 是对外提供服务的; 
    (5)Connector用于接受请求并将请求封装成Request和Response来具体处理; 
    (6)Container用于封装和管理Servlet,以及具体处理request请求;

    知道了整个Tomcat顶层的分层架构和各个组件之间的关系以及作用,对于绝大多数的开发人员来说Server和Service对我们来说确实很远,而我们开发中绝大部分进行配置的内容是属于Connector和Container的,所以接下来介绍一下Connector和Container。

    三、Connector和Container的微妙关系

    由上述内容我们大致可以知道一个请求发送到Tomcat之后,首先经过Service然后会交给我们的Connector,Connector用于接收请求并将接收的请求封装为Request和Response来具体处理,Request和Response封装完之后再交由Container进行处理,Container处理完请求之后再返回给Connector,最后在由Connector通过Socket将处理的结果返回给客户端,这样整个请求的就处理完了!

    Connector最底层使用的是Socket来进行连接的,Request和Response是按照HTTP协议来封装的,所以Connector同时需要实现TCP/IP协议和HTTP协议!

    Tomcat既然处理请求,那么肯定需要先接收到这个请求,接收请求这个东西我们首先就需要看一下Connector!

    四、Connector架构分析

    Connector用于接受请求并将请求封装成Request和Response,然后交给Container进行处理,Container处理完之后在交给Connector返回给客户端。

    因此,我们可以把Connector分为四个方面进行理解:

    (1)Connector如何接受请求的? (2)如何将请求封装成Request和Response的? (3)封装完之后的Request和Response如何交给Container进行处理的? (4)Container处理完之后如何交给Connector并返回给客户端的?

    首先看一下Connector的结构图(图B),如下所示:


    Connector就是使用ProtocolHandler来处理请求的,不同的ProtocolHandler代表不同的连接类型,比如:Http11Protocol使用的是普通Socket来连接的,Http11NioProtocol使用的是NioSocket来连接的。

    其中ProtocolHandler由包含了三个部件:Endpoint、Processor、Adapter。

    (1)Endpoint用来处理底层Socket的网络连接,Processor用于将Endpoint接收到的Socket封装成Request,Adapter用于将Request交给Container进行具体的处理。

    (2)Endpoint由于是处理底层的Socket网络连接,因此Endpoint是用来实现TCP/IP协议的,而Processor用来实现HTTP协议的,Adapter将请求适配到Servlet容器进行具体的处理。

    (3)Endpoint的抽象实现AbstractEndpoint里面定义的Acceptor和AsyncTimeout两个内部类和一个Handler接口。Acceptor用于监听请求,AsyncTimeout用于检查异步Request的超时,Handler用于处理接收到的Socket,在内部调用Processor进行处理。

    至此,我们应该很轻松的回答(1)(2)(3)的问题了,但是(4)还是不知道,那么我们就来看一下Container是如何进行处理的以及处理完之后是如何将处理完的结果返回给Connector的?

    五、Container架构分析

    Container用于封装和管理Servlet,以及具体处理Request请求,在Connector内部包含了4个子容器,结构图如下(图C):


    4个子容器的作用分别是:

    (1)Engine:引擎,用来管理多个站点,一个Service最多只能有一个Engine; (2)Host:代表一个站点,也可以叫虚拟主机,通过配置Host就可以添加站点; (3)Context:代表一个应用程序,对应着平时开发的一套程序,或者一个WEB-INF目录以及下面的web.xml文件; (4)Wrapper:每一Wrapper封装着一个Servlet;

    下面找一个Tomcat的文件目录对照一下,如下图所示:


    Context和Host的区别是Context表示一个应用,我们的Tomcat中默认的配置下webapps下的每一个文件夹目录都是一个Context,其中ROOT目录中存放着主应用,其他目录存放着子应用,而整个webapps就是一个Host站点。

    我们访问应用Context的时候,如果是ROOT下的则直接使用域名就可以访问,例如:www.ledouit.com,如果是Host(webapps)下的其他应用,则可以使用www.ledouit.com/docs进行访问,当然默认指定的根应用(ROOT)是可以进行设定的,只不过Host站点下默认的主营用是ROOT目录下的。

    看到这里我们知道Container是什么,但是还是不知道Container是如何进行处理的以及处理完之后是如何将处理完的结果返回给Connector的?别急!下边就开始探讨一下Container是如何进行处理的!

    六、Container如何处理请求的

    Container处理请求是使用Pipeline-Value管道来处理的!

    Pipeline-Value是责任链模式,责任链模式是指在一个请求处理的过程中有很多处理者依次对请求进行处理,每个处理者负责做自己相应的处理,处理完之后将处理后的请求返回,再让下一个处理着继续处理。


    但是!Pipeline-Value使用的责任链模式和普通的责任链模式有些不同!区别主要有以下两点:

    (1)每个Pipeline都有特定的Value,而且是在管道的最后一个执行,这个Value叫做BaseValue,BaseValue是不可删除的;(2)在上层容器的管道的BaseValue中会调用下层容器的管道。

    我们知道Container包含四个子容器,而这四个子容器对应的BaseValue分别在:StandardEngineValue、StandardHostValue、StandardContextValue、StandardWrapperValue。

    Pipeline的处理流程图如下(图D):


    (1)Connector在接收到请求后会首先调用最顶层容器的Pipeline来处理,这里的最顶层容器的Pipeline就是EnginePipeline(Engine的管道);

    (2)在Engine的管道中依次会执行EngineValue1、EngineValue2等等,最后会执行StandardEngineValue,在StandardEngineValue中会调用Host管道,然后再依次执行Host的HostValue1、HostValue2等,最后在执行StandardHostValue,然后再依次调用Context的管道和Wrapper的管道,最后执行到StandardWrapperValue。

    (3)当执行到StandardWrapperValue的时候,会在StandardWrapperValue中创建FilterChain,并调用其doFilter方法来处理请求,这个FilterChain包含着我们配置的与请求相匹配的Filter和Servlet,其doFilter方法会依次调用所有的Filter的doFilter方法和Servlet的service方法,这样请求就得到了处理!

    (4)当所有的Pipeline-Value都执行完之后,并且处理完了具体的请求,这个时候就可以将返回的结果交给Connector了,Connector在通过Socket的方式将结果返回给客户端。

    总结

    至此,我们已经对Tomcat的整体架构有了大致的了解,从图A、B、C、D可以看出来每一个组件的基本要素和作用。我们在脑海里应该有一个大概的轮廓了!如果你面试的时候,让你简单的聊一下Tomcat,上面的内容你能脱口而出吗?当你能够脱口而出的时候,这位面试官一定会对你刮目相看的!


    展开全文
  • Tomcat系统架构分析

    2014-10-18 16:05:42
    Tomcat系统架构分析 深入学习tomcat 了解tomcat架构
  • 介绍tomcat系统架构与设计模式的书籍,希望对大家有帮助
  • Tomcat整体架构

    2010-06-01 10:08:12
    整体架构图 Service接口 Server接口 生命周期接口Lifecycle

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 133,167
精华内容 53,266
关键字:

tomcat9架构