Tomcat架构解析之1 架构简介

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
简介: Tomcat除了能够支撑通常的web app外,其本身高度模块化的架构体系,也能带来最大限度的可扩展性。目前tomcat版本已经衍生到tomcat9,但是主流的版本还是tomcat6。

Tomcat除了能够支撑通常的web app外,其本身高度模块化的架构体系,也能带来最大限度的可扩展性。
目前tomcat版本已经衍生到tomcat9,但是主流的版本还是tomcat6。此系列架构体系介绍还是以tomcat6为蓝本。
Tomcat是有一系列逻辑模块组织而成,这些模块主要包括:

  • 核心架构模块,例如Server,Service,engine,host和context及wrapper等
  • 网络接口模块connector
  • log模块
  • session管理模块
  • jasper模块
  • naming模块
  • JMX模块
  • 权限控制模块
  • ……

这些模块会在相关的文档里逐一描述,本篇文档以介绍核心架构模块为主。

1 核心架构模块说明

核心架构模块之间是层层包含关系。
例如可以说Service是Server的子组件,Server是Service的父组件。
在server.xml已经非常清晰的定义了这些组件之间的关系及配置。
需要强调的是Service中配置了实际工作的Engine,同时配置了用来处理时间业务的线程组Executor(如果没有配置则用系统默认的WorkThread模式的线程组),以及处理网络socket的相关组件connector。详细情况如图所示。


img_e7b4a57bc50393906d01077cbcaca80f.jpe
1:n代表一对多的关系;1:1代表一对一的关系

StandEngine, StandHost, StandContext及StandWrapper是容器,他们之间有互相的包含关系。例如,StandEngine是StandHost的父容器,StandHost是StandEngine的子容器。在StandService内还包含一个Executor及Connector。

  • Executor是线程池,它的具体实现是executor,这个不是必须的,如果没有配置,则使用自写的worker thread线程池
  • Connector是网络socket相关接口模块,它包含两个对象,ProtocolHandler及Adapter
    • ProtocolHandler是接收socket请求,并将其解析成HTTP请求对象,可以配置成nio模式或者传统io模式
    • Adapter是处理HTTP请求对象,它就是从StandEngine的valve一直调用到StandWrapper的valve

2 分层建模

一个服务器无非是接受HTTP request,然后处理,产生HTTP response通过原有连接返回给客户端。
那为什么会整出这么多的模块进行处理,这些模块是不是有些多余呢?
其实这些模块各司其职,我们从底层wrapper开始,一直到顶层的server
通过这些描述,会发现这正是tomcat架构的高度模块化的体现。这些细分的模块,使得tomcat非常健壮,通过一些配置和模块定制化,可以很大限度的扩展tomcat。
首先,我们以一个典型的页面访问为例,假设访问的URL是
http://www.mydomain.com/app/index.html

img_38586bfab8b58731ac96a3e2e910732c.jpe
详细情况

  • Wrapper封装了具体的访问资源 index.html
  • Context 封装了各个wrapper资源的集合 app
  • Host 封装了各个context资源的集合 www.mydomain.com

按照领域模型,这个典型的URL访问,可以解析出三层领域对象,他们之间互有隶属关系。这是最基本的建模。
从上面的分析可以看出,从wrapperhost层层递进,层层组合。
那么host 资源的集合是什么呢,就是上面所说的engine
如果说以上的三个容器可以看成是物理模型的封装,那么engine可以看成是一种逻辑的封装。

有这套engine的支持,我们已经可以完成从enginehostcontext再到某个特定wrapper的定位,然后进行业务逻辑的处理

先说线程池,这是典型的线程池的应用。首先从线程池中取出一个可用线程,来处理请求,这个组件就是connector
它就像酒店的前台服务员登记客人信息办理入住一样,主要完成了HTTP消息的解析,根据tomcat内部的mapping规则,完成从enginehostcontext再到某个特定wrapper的定位,进行业务处理,然后将返回结果返回。之后,此次处理结束,线程重新回到线程池中,为下一次请求提供服务。

如果线程池中没有空闲线程,则请求被阻塞,直到有空闲线程进行处理,最多至阻塞超时。
线程池的实现有executorworker thread(默认)

至此,可以说一个酒店有了前台接待,有了房间等硬件设施,就可以开始正式运营了。

那么把engine,处理线程池,connector封装在一起,形成了一个完整独立的处理单元,这就是service,就好比某个独立的酒店。

通常,我们经常看见某某集团旗下酒店。也就是说,每个品牌有多个酒店同时运营。就好比tomcat中有多个service独自运行。那么这多个service的集合就是server,就好比是酒店所属的集团。

3 作用域

为什么要按层次分别封装一个对象呢?这主要是为了方便统一管理。
类似命名空间的概念,在不同层次的配置,其作用域不一样。
以tomcat自带的打印request与response消息的RequestDumperValve为例。这个valve的类路径
org.apache.catalina.valves.RequestDumperValve
valve机制是tomcat非常重要的处理逻辑的机制,会在相关文档里专门描述。 如果这个valve配置在server.xml的节点下,则其只打印出访问这个app(my)的request与response消息。

<Host name="localhost" appBase="webapps"  
          unpackWARs="true" autoDeploy="true"  
          xmlValidation="false" xmlNamespaceAware="false">  
             <Context path="/my" docBase=" /usr/local/tomcat/backup/my" >  
                   <Valve className="org.apache.catalina.valves.RequestDumperValve"/>  
             </Context>  
             <Context path="/my2" docBase=" /usr/local/tomcat/backup/my" >  
             </Context>  
  </Host> 

若这个valve配置在server.xml节点下,则可以打印出访问这个host下两个apprequestresponse信息

<Host name="localhost" appBase="webapps"  
                unpackWARs="true" autoDeploy="true"  
                xmlValidation="false" xmlNamespaceAware="false">  
                    <Valve className="org.apache.catalina.valves.RequestDumperValve"/>  
                    <Context path="/my" docBase=" /usr/local/tomcat/backup/my" >  
                    </Context>  
                    <Context path="/my2" docBase=" /usr/local/tomcat/backup/my" >   
                    </Context>  
  </Host> 

在这里贴一个默认的server.xml的配置,通过这些配置可以加深对tomcat核心架构分层模块的理解

<Server port="8005" shutdown="SHUTDOWN">  
         <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />  
         <Listener className="org.apache.catalina.core.JasperListener" />   
         <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />  
         <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />  
         <GlobalNamingResources>  
              <Resource name="UserDatabase" auth="Container"  
                      type="org.apache.catalina.UserDatabase"  
                     description="User database that can be updated and saved"  
                     factory="org.apache.catalina.users.MemoryUserDatabaseFactory"  
                     pathname="conf/tomcat-users.xml" />   
          </GlobalNamingResources>  
          <Service name="Catalina">  
               <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"   
                     maxThreads="150" minSpareThreads="4"/>  
               <Connector port="80" protocol="HTTP/1.1"   
                     connectionTimeout="20000"   
                     redirectPort="7443" />  
               <Connector port="7009" protocol="AJP/1.3" redirectPort="7443" />  
               <Engine name="Catalina" defaultHost="localhost">  
                    <Realm className="org.apache.catalina.realm.UserDatabaseRealm"  
                           resourceName="UserDatabase"/>  
                    <Host name="localhost" appBase="webapps"  
                           unpackWARs="true" autoDeploy="true"  
                           xmlValidation="false" xmlNamespaceAware="false">  
                           <Context path="/my" docBase="/usr/local/tomcat/backup/my" >  
                           </Context>   
                    </Host>   
                </Engine>  
            </Service>  
  </Server>  

至此,头脑中应该有tomcat整体架构的概念

目录
相关文章
|
2月前
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
73 1
|
29天前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
176 36
微服务架构解析:跨越传统架构的技术革命
|
1月前
|
存储 Linux API
深入探索Android系统架构:从内核到应用层的全面解析
本文旨在为读者提供一份详尽的Android系统架构分析,从底层的Linux内核到顶层的应用程序框架。我们将探讨Android系统的模块化设计、各层之间的交互机制以及它们如何共同协作以支持丰富多样的应用生态。通过本篇文章,开发者和爱好者可以更深入理解Android平台的工作原理,从而优化开发流程和提升应用性能。
|
2月前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
2月前
|
SQL 数据可视化 数据库
多维度解析低代码:从技术架构到插件生态
本文深入解析低代码平台,涵盖技术架构、插件生态及应用价值。通过图形化界面和模块化设计,低代码平台降低开发门槛,提升效率,支持企业快速响应市场变化。重点分析开源低代码平台的优势,如透明架构、兼容性与扩展性、可定制化开发等,探讨其在数据处理、功能模块、插件生态等方面的技术特点,以及未来发展趋势。
|
2月前
|
SQL 数据可视化 数据库
多维度解析低代码:从技术架构到插件生态
本文深入解析低代码平台,从技术架构到插件生态,探讨其在企业数字化转型中的作用。低代码平台通过图形化界面和模块化设计降低开发门槛,加速应用开发与部署,提高市场响应速度。文章重点分析开源低代码平台的优势,如透明架构、兼容性与扩展性、可定制化开发等,并详细介绍了核心技术架构、数据处理与功能模块、插件生态及数据可视化等方面,展示了低代码平台如何支持企业在数字化转型中实现更高灵活性和创新。
53 1
|
2月前
|
SQL 数据可视化 数据库
多维度解析低代码:从技术架构到插件生态
本文深入解析低代码平台,涵盖技术架构、插件生态及应用价值。重点介绍开源低代码平台的优势,如透明架构、兼容性与扩展性、可定制化开发,以及其在数据处理、功能模块、插件生态等方面的技术特点。文章还探讨了低代码平台的安全性、权限管理及未来技术趋势,强调其在企业数字化转型中的重要作用。
|
2月前
|
存储 边缘计算 安全
深入解析边缘计算:架构、优势与挑战
深入解析边缘计算:架构、优势与挑战
56 0
|
2月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
87 2
|
11天前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析

热门文章

最新文章

推荐镜像

更多