Tomat6架构探讨

ss1

浏览: 77656 次
性别:
来自: 上海

最近访客更多访客>>

行_天下

mointor

zw532781787

goahead2010

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

Tomcat 源码研究

Tomcat 应用服务器 Apache 网络应用 Servlet

下面，我们重点针对 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() 方法，并且没有加 synchronized 或 synchronized(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 接口，而且还实现了 Lifecycle 和 MBeanRegistration 接口， 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 有可能包含一个到多个连接器。但所有这些连接器都属于一个引擎 (Engine 或 Container) 。在 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.com 和 abc.com 指向同一台 Tomcat 应用服务器。

(5) 连接器 (Connector)
在 Tomcat 中，连接器负责和客户端进行请求响应的交流。 Tomcat 中有两种连接器 (Coyote 和 JK 连接器 ) ， Coyote 连接器实现了 Http1.1 协议，我们可以将它理解为 Tomcat 的 Web 服务器部分。 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 协议。连接器将 Service 和 Container 连接起来，首先它需要注册到一个 Service ，它的作用就是把来自客户端的请求转发到 Container( 容器 ) ，这就是它为什么称作连接器的原因。

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

分享到：

Tomat6的整体架构 | Tomcat启动遇到的常见问题

2009-11-06 14:27
浏览 1653
评论(0)
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论