tomcat原理简析和对比jetty

推荐书籍《深入剖析tomcat》

简介：

Tomcat是Servlet运行环境（容器），每个servlet执行init(),service(),destory()

以下是servlet的作用

1. Tomcat Server的结构

Tomcat各个组件是在$CATLINA_HOME/conf/server.xml文件中配置的

<Server> 顶层类元素，可包含多个service
<Service> 顶层类元素，可包含一个Engine和多个Connector
<Connector/> 链接类容器，代表通信接口
<Engine> 容器元素，为Service处理客户请求,含多个Host
<Host> 容器元素，为Host处理客户请求，含多个Context
<Context/> 容器元素，为Web应用处理客户请求
Host>
Engine>
Service>
Server>

Server：单例，代表整个Catalina servlet container；

Service：由一个或者多个Connector组成，以及一个Engine，负责处理所有Connector所获得的客户请求

Connector：一个Connector将在某个指定端口上侦听客户请求，并将获得的请求交给Engine来处理，从Engine处获得回应并返回客户
TOMCAT有两个典型的Connector，一个直接侦听来自browser的http请求，一个侦听来自其它WebServer的请求
Coyote Http/1.1 Connector 在端口8080处侦听来自客户browser的http请求
Coyote JK2 Connector 在端口8009处侦听来自其它WebServer(Apache)的servlet/jsp代理请求

Engine：Engine下可以配置多个虚拟主机Virtual Host，每个虚拟主机都有一个域名
当Engine获得一个请求时，它把该请求匹配到某个Host上，然后把该请求交给该Host来处理
Engine有一个默认虚拟主机，当请求无法匹配到任何一个Host上的时候，将交给该默认Host来处理

Host：代表一个Virtual Host，虚拟主机，每个虚拟主机和某个网络域名Domain Name相匹配
每个虚拟主机下都可以部署(deploy)一个或者多个Web App，每个Web App对应于一个Context，有一个Context path
当Host获得一个请求时，将把该请求匹配到某个Context上，然后把该请求交给该Context来处理
匹配的方法是“最长匹配”，所以一个path==""的Context将成为该Host的默认Context
所有无法和其它Context的路径名匹配的请求都将最终和该默认Context匹配

Context：一个Context对应于一个Web Application，一个Web Application由一个或者多个Servlet组成
Context在创建的时候将根据配置文件载入Servlet类：

$CATALINA_HOME/conf/web.xml

$WEBAPP_HOME/WEB-INF/web.xml
当Context获得请求时，将在自己的映射表(mapping table)中寻找相匹配的Servlet类
如果找到，则执行该类，获得请求的回应，并返回

Tomcat Server处理一个http请求的过程

假设来自客户的请求为：
http://localhost:8080/wsota/wsota_index.jsp

1) 请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得
2) Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应
3) Engine获得请求localhost/wsota/wsota_index.jsp，匹配它所拥有的所有虚拟主机Host
4) Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机）
5) localhost Host获得请求/wsota/wsota_index.jsp，匹配它所拥有的所有Context
6) Host匹配到路径为/wsota的Context（如果匹配不到就把该请求交给路径名为""的Context去处理）
7) path="/wsota"的Context获得请求/wsota_index.jsp，在它的mapping table中寻找对应的servlet
8) Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类
9) 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法
10)Context把执行完了之后的HttpServletResponse对象返回给Host
11)Host把HttpServletResponse对象返回给Engine
12)Engine把HttpServletResponse对象返回给Connector
13)Connector把HttpServletResponse对象返回给客户browser

2. Tomcat目录

tomcat
|---bin Tomcat：存放启动和关闭tomcat脚本；

|---conf Tomcat：存放不同的配置文件（server.xml和web.xml）；
|---doc：存放Tomcat文档；
|---lib/japser/common：存放Tomcat运行需要的库文件（JARS）；
|---logs：存放Tomcat执行时的LOG文件；
|---src：存放Tomcat的源代码；
|---webapps：Tomcat的主要Web发布目录（包括应用程序示例）；
|---work：存放jsp编译后产生的class文件；

3. Tomcat类加载

  Bootstrap($JAVA_HOME/jre/lib/ext/*.jar) 
System($CLASSPATH/*.class和指定的jar) 
Common($CATALINA_HOME/common 下的classes,lib,endores三个子目录) 
Catalina ($CATALINA_HOME/server/下的classes和lib目录仅对Tomcat可见)
&Shared($CATALINA_HOME/shared/下的classes和lib目录以及$CATALINA_HOME/lib目录)仅对Web应用程序可见,对Tomcat不可见

WebApp($WEBAPP/Web-INF/*仅对该WEB应用可见classes/*.class lib/*.jar)

4.  server.xml 描述了如何启动Tomcat Server

 server:          1、port 指定一个端口，这个端口负责监听关闭tomcat的请求 
          2、shutdown 指定向端口发送的命令字符串 
    service:           1、name 指定service的名字 
    Connector (表示客户端和service之间的连接)：
          1、port 指定服务器端要创建的端口号，并在这个断口监听来自客户端的请求 
          2、minProcessors 服务器启动时创建的处理请求的线程数 
          3、maxProcessors 最大可以创建的处理请求的线程数 
          4、enableLookups 如果为true，则可以通过调用request.getRemoteHost()进行DNS查
询来得到远程客户端的实际主机名，若为false则不进行DNS查询，而是返回其ip地址 
          5、redirectPort 指定服务器正在处理http请求时收到了一个SSL传输请求后重定向的端口号 
          6、acceptCount 指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理
队列中的请求数，超过这个数的请求将不予处理 
          7、connectionTimeout 指定超时的时间数(以毫秒为单位) 
    Engine (表示指定service中的请求处理机，接收和处理来自Connector的请求)：
          1、defaultHost 指定缺省的处理请求的主机名，它至少与其中的一个host元素的name属性值是一样的 
    Context (表示一个web应用程序)：
          1、docBase 应用程序的路径或者是WAR文件存放的路径 
          2、path 表示此web应用程序的url的前缀，这样请求的url为http://localhost:8080/path/**** 
          3、reloadable 这个属性非常重要，如果为true，则tomcat会自动检测应用程序的/WEB-INF/lib 和/WEB-INF/classes目录的变化，自动装载新的应用程序，我们可以在不重起tomcat的情况下改变应用程序 
    host (表示一个虚拟主机)：
          1、name 指定主机名 
          2、appBase 应用程序基本目录，即存放应用程序的目录 
          3、unpackWARs 如果为true，则tomcat会自动将WAR文件解压，否则不解压，直接
从WAR文件中运行应用程序 
    Logger (表示日志，调试和错误信息)：
          1、className 指定logger使用的类名，此类必须实现org.apache.catalina.Logger 接口 
          2、prefix 指定log文件的前缀 
          3、suffix 指定log文件的后缀 
          4、timestamp 如果为true，则log文件名中要加入时间，如下例:localhost_log.2001-10-04.txt 
   Realm (表示存放用户名，密码及role的数据库)：
          1、className 指定Realm使用的类名，此类必须实现org.apache.catalina.Realm接口 
   Valve (功能与Logger差不多，其prefix和suffix属性解释和Logger 中的一样)：
          1、className 指定Valve使用的类名，如用org.apache.catalina.valves.AccessLogValve类可以记录应用程序的访问信息 
    directory（指定log文件存放的位置）：
    1、pattern 有两个值，common方式记录远程主机名或ip地址，用户名，日期，第一行请求的字符串，HTTP响应代码，发送的字节数。combined方式比common方式记录的值更多

5. Context的部署配置文件web.xml

注释：一个java web应用在Tomcat中与一个Context对应，是一一对应关系。

一个Context对应于一个Web App，每个Web App是由一个或者多个servlet组成的
当一个Web App被初始化的时候，它将用自己的ClassLoader对象载入“部署配置文件web.xml”中定义的每个servlet类
它首先载入在$CATALINA_HOME/conf/web.xml中部署的servlet类
然后载入在自己的Web App根目录下的WEB-INF/web.xml中部署的servlet类
web.xml文件有两部分：servlet类定义和servlet映射定义
每个被载入的servlet类都有一个名字，且被填入该Context的映射表(mapping table)中，和某种URL PATTERN对应
当该Context获得请求时，将查询mapping table，找到被请求的servlet，并执行以获得请求回应

分析一下所有的Context共享的web.xml文件，在其中定义的servlet被所有的Web App载入

  
  
  
    
  
  
  
    
    
    
  
    
  
    
  
      
        default  
          
          org.apache.catalina.servlets.DefaultServlet  
          
          
            debug  
            0  
          
          
            listings  
            true  
          
        1  
      
  
  
    
  
      
        invoker  
          
          org.apache.catalina.servlets.InvokerServlet  
          
          
            debug  
            0  
          
        2  
      
  
  
    
  
      
        jsp  
        org.apache.jasper.servlet.JspServlet  
          
            logVerbosityLevel  
            WARNING  
          
        3  
      
  
  
  
    
    
    
  
      
      
        default  
        /  
      
  
      
        invoker  
        /servlet/*  
      
  
      
        jsp  
        *.jsp  
      
  
  
    
    
    
  
    ... ... ... ...  
  
  
  
  

参考：

http://blog.csdn.net/jiandanfeng2/article/details/7342667

http://871421448.iteye.com/blog/1557985

6. 用户配置

 在进行具体Tomcat管理之前，先给tomcat添加一个用户，使这个用户有权限来进行管理。 
      打开conf目录下的tomcat-users.xml文件，在相应的位置添加下面一行： 
     
    然后重起tomcat，在浏览器中输入http://localhost:8080/manager/，会弹出对话框，输入上面的用户

名和密码即可

7. 两个 Servlet 引擎：Tomcat 和 Jetty 的优缺点

参考：

http://blog.csdn.net/qing_2012/article/details/8276789

http://www.open-open.com/lib/view/open1322622094390.html

Tomcat 和 Jetty 都是作为一个 Servlet 引擎应用的比较广泛，可以将它们比作为中国与美国的关系，虽然 Jetty 正常成长为一个优秀的 Servlet 引擎，但是目前的 Tomcat 的地位仍然难以撼动。

相同点：

Tomcat和Jetty都是一种Servlet引擎，他们都支持标准的servlet规范和JavaEE的规范（目前全球范围内最著名的两款开源webserver/servlet容器）

方面	tomcat	jetty
稳定和成熟	相对 Jetty 来说 Tomcat 还是比较稳定和成熟，尤其在企业级应用方面，Tomcat 仍然是第一选择
架构	Tomcat 的核心是它的容器的设计，从 Server 到 Service 再到 engine 等 container 容器。作为一个应用服务器这样设计无口厚非，容器的分层设计也是为了更好的扩展，这是这种扩展的方式是将应用服务器的内部结构暴露给外部使用者，使得如果想扩展 Tomcat，开发人员必须要首先了解 Tomcat 的整体设计结构，然后才能知道如何按照它的规范来做扩展。这样无形就增加了对 Tomcat 的学习成本。	显然 Jetty 比 Tomcat 更加简单 它的所有组件都是基于 Handler 来实现，当然它也支持 JMX。但是主要的功能扩展都可以用 Handler 来实现。可以说 Jetty 是面向 Handler 的架构，就像 Spring 是面向 Bean 的架构  Handler 的设计实际上就是一个责任链模式，接口类 HandlerCollection 可以帮助开发者构建一个链，而另一个接口类 ScopeHandler 可以帮助你控制这个链的访问顺序。另外一个用到的设计模板就是观察者模式，用这个设计模式控制了整个 Jetty 的生命周期，只要继承了 LifeCycle 接口，你的对象就可以交给 Jetty 来统一管理了。所以扩展 Jetty 非常简单 表面上看，Tomcat 的功能要比 Jetty 强大，因为 Tomcat 已经帮你做了很多工作了，而 Jetty 只告诉，你能怎么做，如何做，有你去实现。 打个比方，就像小孩子学数学，Tomcat 告诉你 1+1=2，1+2=3，2+2=4 这个结果，然后你可以根据这个方式得出 1+1+2=4，你要计算其它数必须根据它给你的公式才能计算，而 Jetty 是告诉你加减乘除的算法规则，然后你就可以根据这个规则自己做运算了。所以你一旦掌握了 Jetty，Jetty 将变得异常强大。
性能	Tomcat 在处理少数非常繁忙的连接上更有优势，也就是说连接的生命周期如果短的话，Tomcat 的总体性能更高	而 Jetty 刚好相反，Jetty 可以同时处理大量连接而且可以长时间保持这些连接。例如像一些 web 聊天应用非常适合用 Jetty 做服务器，像淘宝的 web 旺旺就是用 Jetty 作为 Servlet 引擎。 另外由于 Jetty 的架构非常简单，作为服务器它可以按需加载组件，这样不需要的组件可以去掉，这样无形可以减少服务器本身的内存开销，处理一次请求也是可以减少产生的临时对象，这样性能也会提高。另外 Jetty 默认使用的是 NIO 技术在处理 I/O 请求上更占优势，Tomcat 默认使用的是 BIO，在处理静态资源时，Tomcat 的性能不如 Jetty。
特性	作为一个标准的 Servlet 引擎，它们都支持标准的 Servlet 规范，还有 Java EE 的规范也都支持，由于 Tomcat 的使用的更加广泛，它对这些支持的更加全面一些，有很多特性 Tomcat 都直接集成进来了	Jetty 的应变更加快速，这一方面是因为 Jetty 的开发社区更加活跃，另一方面也是因为 Jetty 的修改更加简单，它只要把相应的组件替换就好了

总结： Jetty更满足公有云的分布式环境的需求，而Tomcat更符合企业级环境

Tomcat为满足更多的企业级需求，增加了JEE特性，在服务企业级应用时，它的支持优于Jetty。然而，即使Tomcat性能略优于Jetty，但对于大多非企业级应用而言，配置复杂体积庞大的Tomcat显得过于重量级。

 

    正因为这个，实验室的云平台实现便是把云平台本身的门户网站放在Tomcat内，而云台托管的Java Web应该是部署在Jetty内的。