现在的位置: 首页 > 综合 > 正文

Tomat6架构探讨(二续)

2012年09月01日 ⁄ 综合 ⁄ 共 4628字 ⁄ 字号 评论关闭

Tomat6架构探讨(续)

原文地址:http://carllgc.blog.ccidnet.com/blog-htm-do-showone-uid-4092-type-blog-itemid-283322.html 

Tomat源码学习(二) 

下面,我们重点针对Catalina子模块,熟悉Tomcat的几个关键组件。
 

(1)   服务器
(Server)   
Tomcat中,服务器代表整个J2EE容器,所有的服务及服务上下文均包含在服务器内。我们打开Tomcat源代码,可以看到org.apache.catalina.Server这个接口,其中比较重要的方法有initialize(负责Tomcat启动前的初始化工作),还有一些服务(Services)管理方法,比如removeService()addService()findService()之类的方法。
 

Tomcat运行时,我们永远只有一个Server实例,这不由让我们联想到单例模式(Singleton Pattern)。不错,在Tomcat中,Server的实例化工作正是由一个叫ServerFactory工厂类完成的,这个工厂类实现了单例设计模式。
 

比较有意思的是,这个工厂类的产品创建方法名为getServer()而不是标准的createServer()方法,并且没有加synchronizedsynchronized(this)保护,这是为什么呢?我们知道,在应用单例模式时,需要注意的一个关键点就是多线程的调用问题,如果我们的工厂类在创建单例对象时,这个工厂类有可能被多个线程并发调用的话,那么最好给这个工厂方法加上synchronized以避免产生两个不同的产品类实例。如果您想避免synchronized的锁机制造成的性能损失,请使用双重检查机制(double-checked locking)。所以,如果考虑多线程,这个工厂类的getServer()方法应该写成:(红色代码是作者另加上的,源代码中没有)。
 

/** 

* Return the singleton <code>Server</code> instance for this JVM. 

*/ 

public static Server getServer() { 

if( server==null ){ 
synchronized (ServerFactory.class) { 
if(server==null){ 
  server=new StandardServer(); 



return (server); 
} 

为什么Tomcat在实现时没有加上面的红色代码呢?这是因为,Tomcat启动时创建Server对象,不可能出现多线程情况,所以就免掉了双重检查。如果我们确信没有多线程调用我们的单例工厂类,我们也可以这样做。 

另外,如果您对ServerFactory进行调试,您会发现一个非常有趣的现象,这个工厂先执行的不是create方法(此处为getServer方法),而是setServer方法。这意味着这个工厂方法其实并不生产实际产品,实际产品是从别处产生,然后通过setServer方法注册到这个Factory。当下次有客户请求产品时,这个工厂方法只是简单的把现成的单例产品传给客户。所以这个类其实只需一个单例类足矣,根本没有必要使用工厂模式,所以Tomcat的开发者也觉得不好意思使用标准的工厂方法createProduct,杀鸡焉用宰牛刀,对吗?
 

Tomcat6.0中,服务器(Server)接口的实现类只有一个,那就是org.apache.catalina.core. StandardServer类。这是一个标准的服务器实现类,这个类不但实现了Server接口,而且还实现了LifecycleMBeanRegistration接口,Lifecycle主要提供了服务器的生命周期管理功能,比如说启动、停止等方法,而MBeanRegistration接口是为了将server注册到MBean服务器,以便在Tomat运行时,我们能通过JMX来管理服务器。
 

Tomcat5.0开始,Tomcat的开发人员在JMX管理上着实下了一番功夫,争取做到让Tomcat具有JBoss那样非常强大的管理功能。
 

(2)   服务
(Service) 
在上述的标准服务器(StanderServer.java)实现代码中,我们可以看到其中有一个services的数组,这个数组就是用来存储服务(Service)的。所以,我们可以这样理解,一个服务器可能有一至多个服务组成。所谓服务,就是包含一至多个连接器的组件,能够对用户请求作出响应的组件。打开org.apache.catalina.Service.java的源代码,我们可以看到其中含有一个连接器数组(Connector[]),这表明一个Service有可能包含一个到多个连接器。但所有这些连接器都属于一个引擎(EngineContainer)。在Tomcat6中,org.apache.catalina.Service接口由org.apache.catalina.core. StandardService类来实现的。
 

(3)   引擎
(Engine) 
对一个具体的服务(service)来说,引擎是一个用户请求的处理管道,这个管道很特别,因为它只处理Servlet请求,在Tomcat中,引擎其实就是指Servlet引擎。引擎从这些连接器那里接收到Servlet请求,然后处理它们,并将响应的结果传回到适当的连接器,从而将响应发送到客户端。简单地说,引擎的功能就是如何处理用户的Servlet请求。
 

org.apache.catalina.Engine这个接口继承自org.apache.catalina.Container,说明引擎是一种特殊的Container,是一种专门用来处理servlet请求的容器。
 

(4)   主机
(Host) 
Tomcat服务器来说,主机是Tomcats所在机器的网络名(域名)。一个引擎可能包含多个主机,主机支持网络别名。例如,用户通过配置config.xml里面的主机(Host)元素,让
www.abc.comabc.com 指向同一台Tomcat应用服务器。 

(5)   连接器
(Connector) 
Tomcat中,连接器负责和客户端进行请求响应的交流。Tomcat中有两种连接器(CoyoteJK连接器)Coyote连接器实现了Http1.1协议,我们可以将它理解为TomcatWeb服务器部分。JK连接器负责处理来自第三方Web服务器的请求,并将请求结果发送给第三方Web服务器。针对Apache Httpd Web服务器,JK连接器实现了AJP协议。
 

Tomcat6.0中,实现Coyote连接器的类是org.apache.catalina.connector.Connector 

(6)   上下文
(Context) 
上下文代表某一具体的Web应用,一个主机可包含多个Web应用,所以可有多个Web应用上下文,不同的上下文可用不同路径来表示。上下文里含有一些关于该Web应用的一些具体信息,比如欢迎页面的文件名,web.xml文件的位置等等信息。
 

上下文在Tomcat的源码中对应org.apache.catalina.Context接口,其具体实现为org.apache.catalina.core.StandardContext
 

至此为止,我们熟悉了Tomcat架构中一些重要组件。下面我们用UML类图(Class Diagram)来总结一下。 

在上面的类图中,我们先撇开Tomcat组件不谈,首先给我们印象最深刻的一点是:针对接口编程,而非针对具体实现编程(Program to interface, not implementation)。人家老外这点确实值得我们学习。上面的类图中,共有7个类,其余均为接口,这些类无一例外地调用了接口,而非具体的实现类。ServerFactory调用了Server接口,而非StandServer的实现类;Connector类调用了Service接口和Container接口,而没有调用它们的实现类;StandardService类调用了Container接口和Server接口,也同样没有调用它们的实现类。所以我们在编程时,也要贯彻这条原则。 

<<Head First Design Patterns>>一书里,作者举了个非常生动的例子,请看下面三段代码:
 

a)   代码片段一
 
Dog d=new Dog(); 
d.bark(); 

b)   代码片段二
 
Animal animal=new Dog(); 
animal.makeSound(); 

c)   代码片段三 
Animal animal = getAnimal(); 
animal.makeSound(); 

作者详细解释了上面第三段代码为什么是最好的,而第二段又为什么比第一段好的道理。东扯西拉这么多,现在我们切入正题。
 

从上面的类图中,我们可以非常清晰地理解Tomcat的总体架构:
 

a)   Server(服务器)Tomcat构成的顶级构成元素,所有一切均包含在Server中,Server的实现类StandardServer可以包含一个到多个Services
 

b)   次顶级元素Service的实现类为StandardService调用了容器(Container)接口,其实是调用了Servlet Engine(引擎),而且StandardService类中也指明了该Service归属的Server
 

c)   接下来次级的构成元素就是容器(Container),主机(Host)、上下文(Context)和引擎(Engine)均继承自Container接口,所以它们都是容器。但是,它们是有父子关系的,在主机(Host)、上下文(Context)和引擎(Engine)这三类容器中,引擎是顶级容器,直接包含是主机容器,而主机容器又包含上下文容器,所以引擎、主机和上下文从大小上来说又构成父子关系,虽然它们都继承自Container接口。
 

d)   连接器(Connector)没有接口(这可是违反了面向接口编程的原则哟!),它直接实现了Http1.1协议。连接器将ServiceContainer连接起来,首先它需要注册到一个Service,它的作用就是把来自客户端的请求转发到Container(容器),这就是它为什么称作连接器的原因。
 

下面我们来小结一下,Tomcat的架构从功能的角度,可以分成5个子模块,它们分别是Connector子模块,Jsper子模块,Servlet子模块,Catalina子模块和Resource子模块,每个子模块负责一定的功能;从组件的角度,我们可以看到Tomcat中至少有7个关键组件,它们Server组件、Service组件、Container组件、Connector组件及继承自Container组件的Host组件、Engine组件和Container组件,从UML Class Diagram中,我们可以非常明确地理解它们的包容关系。到此为止,希望我们能对Tomcat的架构有一个比较清晰的认识。
 

抱歉!评论已关闭.