Jetty 的基本架構(gòu)

Jetty 目前的是一個比較被看好的 Servlet 引擎，它的架構(gòu)比較簡單，也是一個可擴展性和非常靈活的應(yīng)用服務(wù)器，它有一個基本數(shù)據(jù)模型，這個數(shù)據(jù)模型就是 Handler，所有可以被擴展的組件都可以作為一個 Handler，添加到 Server 中，Jetty 就是幫你管理這些 Handler。

Jetty 的基本架構(gòu)

下圖是 Jetty 的基本架構(gòu)圖，整個 Jetty 的核心組件由 Server 和 Connector 兩個組件構(gòu)成，整個 Server 組件是基于 Handler 容器工作的，它類似與 Tomcat 的 Container 容器，Jetty 與 Tomcat 的比較在后面詳細介紹。Jetty 中另外一個比不可少的組件是 Connector，它負責(zé)接受客戶端的連接請求，并將請求分配給一個處理隊列去執(zhí)行。

Jetty 中還有一些可有可無的組件，我們可以在它上做擴展。如 JMX，我們可以定義一些 Mbean 把它加到 Server 中，當(dāng) Server 啟動的時候，這些 Bean 就會一起工作。

從上圖可以看出整個 Jetty 的核心是圍繞著 Server 類來構(gòu)建，Server 類繼承了 Handler，關(guān)聯(lián)了 Connector 和 Container。Container 是管理 Mbean 的容器。Jetty 的 Server 的擴展主要是實現(xiàn)一個個 Handler 并將 Handler 加到 Server 中，Server 中提供了調(diào)用這些 Handler 的訪問規(guī)則。

整個 Jetty 的所有組件的生命周期管理是基于觀察者模板設(shè)計，它和 Tomcat 的管理是類似的。下面是 LifeCycle 的類關(guān)系圖

每個組件都會持有一個觀察者（在這里是 Listener 類，這個類通常對應(yīng)到觀察者模式中常用的 Observer 角色，關(guān)于觀察者模式可以參考 《Tomcat系統(tǒng)架構(gòu)與設(shè)計模式，第2部分:設(shè)計模式分析》一文中關(guān)于觀察者模式的講解）集合，當(dāng) start、fail 或 stop 等事件觸發(fā)時，這些 Listener 將會被調(diào)用，這是最簡單的一種設(shè)計方式，相比 Tomcat 的 LifeCycle 要簡單的多。

Handler 的體系結(jié)構(gòu)

前面所述 Jetty 主要是基于 Handler 來設(shè)計的，Handler 的體系結(jié)構(gòu)影響著整個 Jetty 的方方面面。下面總結(jié)了一下 Handler 的種類及作用：

Jetty 主要提供了兩種 Handler 類型，一種是 HandlerWrapper，它可以將一個 Handler 委托給另外一個類去執(zhí)行，如我們要將一個 Handler 加到 Jetty 中，那么就必須將這個 Handler 委托給 Server 去調(diào)用。配合 ScopeHandler 類我們可以攔截 Handler 的執(zhí)行，在調(diào)用 Handler 之前或之后，可以做一些另外的事情，類似于 Tomcat 中的 Valve；另外一個 Handler 類型是 HandlerCollection，這個 Handler 類可以將多個 Handler 組裝在一起，構(gòu)成一個 Handler 鏈，方便我們做擴展。

回頁首

Jetty 的啟動過程

Jetty 的入口是 Server 類，Server 類啟動完成了，就代表 Jetty 能為你提供服務(wù)了。它到底能提供哪些服務(wù)，就要看 Server 類啟動時都調(diào)用了其它組件的 start 方法。從 Jetty 的配置文件我們可以發(fā)現(xiàn)，配置 Jetty 的過程就是將那些類配置到 Server 的過程。下面是 Jetty 的啟動時序圖：

因為 Jetty 中所有的組件都會繼承 LifeCycle，所以 Server 的 start 方法調(diào)用就會調(diào)用所有已經(jīng)注冊到 Server 的組件，Server 啟動其它組件的順序是：首先啟動設(shè)置到 Server 的 Handler，通常這個 Handler 會有很多子 Handler，這些 Handler 將組成一個 Handler 鏈。Server 會依次啟動這個鏈上的所有 Handler。接著會啟動注冊在 Server 上 JMX 的 Mbean，讓 Mbean 也一起工作起來，最后會啟動 Connector，打開端口，接受客戶端請求，啟動邏輯非常簡單。

回頁首

接受請求

Jetty 作為一個獨立的 Servlet 引擎可以獨立提供 Web 服務(wù)，但是它也可以與其他 Web 應(yīng)用服務(wù)器集成，所以它可以提供基于兩種協(xié)議工作，一個是 HTTP，一個是 AJP 協(xié)議。如果將 Jetty 集成到 Jboss 或者 Apache，那么就可以讓 Jetty 基于 AJP 模式工作。下面分別介紹 Jetty 如何基于這兩種協(xié)議工作，并且它們?nèi)绾谓⑦B接和接受請求的。

基于 HTTP 協(xié)議工作

如果前端沒有其它 web 服務(wù)器，那么 Jetty 應(yīng)該是基于 HTTP 協(xié)議工作。也就是當(dāng) Jetty 接收到一個請求時，必須要按照 HTTP 協(xié)議解析請求和封裝返回的數(shù)據(jù)。那么 Jetty 是如何接受一個連接又如何處理這個連接呢？

我們設(shè)置 Jetty 的 Connector 實現(xiàn)類為 org.eclipse.jetty.server.bi.SocketConnector 讓 Jetty 以 BIO 的方式工作，Jetty 在啟動時將會創(chuàng)建 BIO 的工作環(huán)境，它會創(chuàng)建 HttpConnection 類用來解析和封裝 HTTP1.1 的協(xié)議，ConnectorEndPoint 類是以 BIO 的處理方式處理連接請求，ServerSocket 是建立 socket 連接接受和傳送數(shù)據(jù)，Executor 是處理連接的線程池，它負責(zé)處理每一個請求隊列中任務(wù)。acceptorThread 是監(jiān)聽連接請求，一有 socket 連接，它將進入下面的處理流程。

當(dāng) socket 被真正執(zhí)行時，HttpConnection 將被調(diào)用，這里定義了如何將請求傳遞到 servlet 容器里，有如何將請求最終路由到目的 servlet，關(guān)于這個細節(jié)可以參考《 servlet 工作原理解析》一文。

下圖是 Jetty 啟動創(chuàng)建建立連接的時序圖：

Jetty 創(chuàng)建接受連接環(huán)境需要三個步驟：

1. 創(chuàng)建一個隊列線程池，用于處理每個建立連接產(chǎn)生的任務(wù)，這個線程池可以由用戶來指定，這個和 Tomcat 是類似的。
2. 創(chuàng)建 ServerSocket，用于準備接受客戶端的 socket 請求，以及客戶端用來包裝這個 socket 的一些輔助類。
3. 創(chuàng)建一個或多個監(jiān)聽線程，用來監(jiān)聽訪問端口是否有連接進來。

相比 Tomcat 創(chuàng)建建立連接的環(huán)境，Jetty 的邏輯更加簡單，牽涉到的類更少，執(zhí)行的代碼量也更少了。

當(dāng)建立連接的環(huán)境已經(jīng)準備好了，就可以接受 HTTP 請求了，當(dāng) Acceptor 接受到 socket 連接后將轉(zhuǎn)入下圖所示流程執(zhí)行：

Accetptor 線程將會為這個請求創(chuàng)建 ConnectorEndPoint。HttpConnection 用來表示這個連接是一個 HTTP 協(xié)議的連接，它會創(chuàng)建 HttpParse 類解析 HTTP 協(xié)議，并且會創(chuàng)建符合 HTTP 協(xié)議的 Request 和 Response 對象。接下去就是將這個線程交給隊列線程池去執(zhí)行了。

基于 AJP 工作

通常一個 web 服務(wù)站點的后端服務(wù)器不是將 Java 的應(yīng)用服務(wù)器直接暴露給服務(wù)訪問者，而是在應(yīng)用服務(wù)器，如 Jboss 的前面在加一個 web 服務(wù)器，如 Apache 或者 nginx，我想這個原因大家應(yīng)該很容易理解，如做日志分析、負載均衡、權(quán)限控制、防止惡意請求以及靜態(tài)資源預(yù)加載等等。

下圖是通常的 web 服務(wù)端的架構(gòu)圖：

這種架構(gòu)下 servlet 引擎就不需要解析和封裝返回的 HTTP 協(xié)議，因為 HTTP 協(xié)議的解析工作已經(jīng)在 Apache 或 Nginx 服務(wù)器上完成了，Jboss 只要基于更加簡單的 AJP 協(xié)議工作就行了，這樣能加快請求的響應(yīng)速度。

對比 HTTP 協(xié)議的時序圖可以發(fā)現(xiàn)，它們的邏輯幾乎是相同的，不同的是替換了一個類 Ajp13Parserer 而不是 HttpParser，它定義了如何處理 AJP 協(xié)議以及需要哪些類來配合。

實際上在 AJP 處理請求相比較 HTTP 時唯一的不同就是在讀取到 socket 數(shù)據(jù)包時，如何來轉(zhuǎn)換這個數(shù)據(jù)包，是按照 HTTP 協(xié)議的包格式來解析就是 HttpParser，按照 AJP 協(xié)議來解析就是 Ajp13Parserer。封裝返回的數(shù)據(jù)也是如此。

讓 Jetty 工作在 AJP 協(xié)議下，需要配置 connector 的實現(xiàn)類為 Ajp13SocketConnector，這個類繼承了 SocketConnector 類，覆蓋了父類的 newConnection 方法，為的是創(chuàng)建 Ajp13Connection 對象而不是 HttpConnection。如下圖表示的是 Jetty 創(chuàng)建連接環(huán)境時序圖：

與 HTTP 方式唯一不同的地方的就是將 SocketConnector 類替換成了 Ajp13SocketConnector。改成 Ajp13SocketConnector 的目的就是可以創(chuàng)建 Ajp13Connection 類，表示當(dāng)前這個連接使用的是 AJP 協(xié)議，所以需要用 Ajp13Parser 類解析 AJP 協(xié)議，處理連接的邏輯都是一樣的。如下時序圖所示：

基于 NIO 方式工作

前面所描述的 Jetty 建立客戶端連接到處理客戶端的連接都是基于 BIO 的方式，它也支持另外一種 NIO 的處理方式，其中 Jetty 的默認 connector 就是 NIO 方式。

關(guān)于 NIO 的工作原理可以參考 developerworks 上關(guān)于 NIO 的文章，通常 NIO 的工作原型如下：

 Selector selector = Selector.open(); 
 ServerSocketChannel ssc = ServerSocketChannel.open(); 
 ssc.configureBlocking( false ); 
 SelectionKey key = ssc.register( selector, SelectionKey.OP_ACCEPT ); 
 ServerSocketChannel ss = (ServerSocketChannel)key.channel(); 
 SocketChannel sc = ss.accept(); 
 sc.configureBlocking( false ); 
 SelectionKey newKey = sc.register( selector, SelectionKey.OP_READ ); 
 Set selectedKeys = selector.selectedKeys(); 

創(chuàng)建一個 Selector 相當(dāng)于一個觀察者，打開一個 Server 端通道，把這個 server 通道注冊到觀察者上并且指定監(jiān)聽的事件。然后遍歷這個觀察者觀察到事件，取出感興趣的事件再處理。這里有個最核心的地方就是，我們不需要為每個被觀察者創(chuàng) 建一個線程來監(jiān)控它隨時發(fā)生的事件。而是把這些被觀察者都注冊一個地方統(tǒng)一管理，然后由它把觸發(fā)的事件統(tǒng)一發(fā)送給感興趣的程序模塊。這里的核心是能夠統(tǒng)一 的管理每個被觀察者的事件，所以我們就可以把服務(wù)端上每個建立的連接傳送和接受數(shù)據(jù)作為一個事件統(tǒng)一管理，這樣就不必要每個連接需要一個線程來維護了。

這里需要注意的地方時，很多人認為監(jiān)聽 SelectionKey.OP_ACCEPT 事件就已經(jīng)是非阻塞方式了，其實 Jetty 仍然是用一個線程來監(jiān)聽客戶端的連接請求，當(dāng)接受到請求后，把這個請求再注冊到 Selector 上，然后才是非阻塞方式執(zhí)行。這個地方還有一個容易引起誤解的地方是：認為 Jetty 以 NIO 方式工作只會有一個線程來處理所有的請求，甚至?xí)J為不同用戶會在服務(wù)端共享一個線程從而會導(dǎo)致基于 ThreadLocal 的程序會出現(xiàn)問題，其實從 Jetty 的源碼中能夠發(fā)現(xiàn)，真正共享一個線程的處理只是在監(jiān)聽不同連接的數(shù)據(jù)傳送事件上，比如有多個連接已經(jīng)建立，傳統(tǒng)方式是當(dāng)沒有數(shù)據(jù)傳輸時，線程是阻塞的也就 是一直在等待下一個數(shù)據(jù)的到來，而 NIO 的處理方式是只有一個線程在等待所有連接的數(shù)據(jù)的到來，而當(dāng)某個連接數(shù)據(jù)到來時 Jetty 會把它分配給這個連接對應(yīng)的處理線程去處理，所以不同連接的處理線程仍然是獨立的。

Jetty 的 NIO 處理方式和 Tomcat 的幾乎一樣，唯一不同的地方是在如何把監(jiān)聽到事件分配給對應(yīng)的連接的處理方式。從測試效果來看 Jetty 的 NIO 處理方式更加高效。下面是 Jetty 的 NIO 處理時序圖：

回頁首

處理請求

下面看一下 Jetty 是如何處理一個 HTTP 請求的。

實際上 Jetty 的工作方式非常簡單，當(dāng) Jetty 接受到一個請求時，Jetty 就把這個請求交給在 Server 中注冊的代理 Handler 去執(zhí)行，如何執(zhí)行你注冊的 Handler，同樣由你去規(guī)定，Jetty 要做的就是調(diào)用你注冊的第一個 Handler 的 handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) 方法，接下去要怎么做，完全由你決定。

要能接受一個 web 請求訪問，首先要創(chuàng)建一個 ContextHandler，如下代碼所示：

 Server server = new Server(8080); 
 ContextHandler context = new ContextHandler(); 
 context.setContextPath("/"); 
 context.setResourceBase("."); 
 context.setClassLoader(Thread.currentThread().getContextClassLoader()); 
 server.setHandler(context); 
 context.setHandler(new HelloHandler()); 
 server.start(); 
 server.join(); 

當(dāng)我們在瀏覽器里敲入 http://localhost:8080 時的請求將會代理到 Server 類的 handle 方法，Server 的 handle 的方法將請求代理給 ContextHandler 的 handle 方法，ContextHandler 又調(diào)用 HelloHandler 的 handle 方法。這個調(diào)用方式是不是和 Servlet 的工作方式類似，在啟動之前初始化，然后創(chuàng)建對象后調(diào)用 Servlet 的 service 方法。在 Servlet 的 API 中我通常也只實現(xiàn)它的一個包裝好的類，在 Jetty 中也是如此，雖然 ContextHandler 也只是一個 Handler，但是這個 Handler 通常是由 Jetty 幫你實現(xiàn)了，我們一般只要實現(xiàn)一些我們具體要做的業(yè)務(wù)邏輯有關(guān)的 Handler 就好了，而一些流程性的或某些規(guī)范的 Handler，我們直接用就好了，如下面的關(guān)于 Jetty 支持 Servlet 的規(guī)范的 Handler 就有多種實現(xiàn)，下面是一個簡單的 HTTP 請求的流程。

訪問一個 Servlet 的代碼：

 Server server = new Server(); 
 Connector connector = new SelectChannelConnector(); 
 connector.setPort(8080); 
 server.setConnectors(new Connector[]{ connector }); 
 ServletContextHandler root = new 
 ServletContextHandler(null,"/",ServletContextHandler.SESSIONS); 
 server.setHandler(root); 
 root.addServlet(new ServletHolder(new 
 org.eclipse.jetty.embedded.HelloServlet("Hello")),"/"); 
 server.start(); 
 server.join(); 

創(chuàng)建一個 ServletContextHandler 并給這個 Handler 添加一個 Servlet，這里的 ServletHolder 是 Servlet 的一個裝飾類，它十分類似于 Tomcat 中的 StandardWrapper。下面是請求這個 Servlet 的時序圖：

上圖可以看出 Jetty 處理請求的過程就是 Handler 鏈上 handle 方法的執(zhí)行過程，在這里需要解釋的一點是 ScopeHandler 的處理規(guī)則，ServletContextHandler、SessionHandler 和 ServletHandler 都繼承了 ScopeHandler，那么這三個類組成一個 Handler 鏈，它們的執(zhí)行規(guī)則是：ServletContextHandler.handle?ServletContextHandler.doScope ?SessionHandler. doScope?ServletHandler. doScope?ServletContextHandler. doHandle?SessionHandler. doHandle?ServletHandler. doHandle，它這種機制使得我們可以在 doScope 做一些額外工作。

回頁首

與 Jboss 集成

前面介紹了 Jetty 可以基于 AJP 協(xié)議工作，在正常的企業(yè)級應(yīng)用中，Jetty 作為一個 Servlet 引擎都是基于 AJP 協(xié)議工作的，所以它前面必然有一個服務(wù)器，通常情況下與 Jboss 集成的可能性非常大，這里介紹一下如何與 Jboss 集成。

Jboss 是基于 JMX 的架構(gòu)，那么只要符合 JMX 規(guī)范的系統(tǒng)或框架都可以作為一個組件加到 Jboss 中，擴展 Jboss 的功能。Jetty 作為主要的 Servlet 引擎當(dāng)然支持與 Jboss 集成。具體集成方式如下：

Jetty 作為一個獨立的 Servlet 引擎集成到 Jboss 需要繼承 Jboss 的 AbstractWebContainer 類，這個類實現(xiàn)的是模板模式，其中有一個抽象方法需要子類去實現(xiàn)，它是 getDeployer，可以指定創(chuàng)建 web 服務(wù)的 Deployer。Jetty 工程中有個 jetty-jboss 模塊，編譯這個模塊就會產(chǎn)生一個 SAR 包，或者可以直接從官網(wǎng)下載一個 SAR 包。解壓后如下圖：

在 jboss-jetty-6.1.9 目錄下有一個 webdefault.xml 配置文件，這個文件是 Jetty 的默認 web.xml 配置，在 META-INF 目錄發(fā)下發(fā)現(xiàn) jboss-service.xml 文件，這個文件配置了 MBean，如下：

 <mbean code="org.jboss.jetty.JettyService" 
         name="jboss.web:service=WebServer" xmbean-dd="META-INF/webserver-xmbean.xml"> 

同樣這個 org.jboss.jetty.JettyService 類也是繼成 org.jboss.web.AbstractWebContainer 類，覆蓋了父類的 startService 方法，這個方法直接調(diào)用 jetty.start 啟動 Jetty。

回頁首

與 Tomcat 的比較

Tomcat 和 Jetty 都是作為一個 Servlet 引擎應(yīng)用的比較廣泛，可以將它們比作為中國與美國的關(guān)系，雖然 Jetty 正常成長為一個優(yōu)秀的 Servlet 引擎，但是目前的 Tomcat 的地位仍然難以撼動。相比較來看，它們都有各自的優(yōu)點與缺點。

Tomcat 經(jīng)過長時間的發(fā)展，它已經(jīng)廣泛的被市場接受和認可，相對 Jetty 來說 Tomcat 還是比較穩(wěn)定和成熟，尤其在企業(yè)級應(yīng)用方面，Tomcat 仍然是第一選擇。但是隨著 Jetty 的發(fā)展，Jetty 的市場份額也在不斷提高，至于原因就要歸功與 Jetty 的很多優(yōu)點了，而這些優(yōu)點也是因為 Jetty 在技術(shù)上的優(yōu)勢體現(xiàn)出來的。

架構(gòu)比較

從架構(gòu)上來說，顯然 Jetty 比 Tomcat 更加簡單，如果你對 Tomcat 的架構(gòu)還不是很了解的話，建議你先看一下 《Tomcat系統(tǒng)架構(gòu)與設(shè)計模式》這篇文章。

Jetty 的架構(gòu)從前面的分析可知，它的所有組件都是基于 Handler 來實現(xiàn)，當(dāng)然它也支持 JMX。但是主要的功能擴展都可以用 Handler 來實現(xiàn)?？梢哉f Jetty 是面向 Handler 的架構(gòu)，就像 Spring 是面向 Bean 的架構(gòu)，iBATIS 是面向 statement 一樣，而 Tomcat 是以多級容器構(gòu)建起來的，它們的架構(gòu)設(shè)計必然都有一個“元神”，所有以這個“元神“構(gòu)建的其它組件都是肉身。

從設(shè)計模板角度來看 Handler 的設(shè)計實際上就是一個責(zé)任鏈模式，接口類 HandlerCollection 可以幫助開發(fā)者構(gòu)建一個鏈，而另一個接口類 ScopeHandler 可以幫助你控制這個鏈的訪問順序。另外一個用到的設(shè)計模板就是觀察者模式，用這個設(shè)計模式控制了整個 Jetty 的生命周期，只要繼承了 LifeCycle 接口，你的對象就可以交給 Jetty 來統(tǒng)一管理了。所以擴展 Jetty 非常簡單，也很容易讓人理解，整體架構(gòu)上的簡單也帶來了無比的好處，Jetty 可以很容易被擴展和裁剪。

相比之下，Tomcat 要臃腫很多，Tomcat 的整體設(shè)計上很復(fù)雜，前面說了 Tomcat 的核心是它的容器的設(shè)計，從 Server 到 Service 再到 engine 等 container 容器。作為一個應(yīng)用服務(wù)器這樣設(shè)計無口厚非，容器的分層設(shè)計也是為了更好的擴展，這是這種擴展的方式是將應(yīng)用服務(wù)器的內(nèi)部結(jié)構(gòu)暴露給外部使用者，使得如果 想擴展 Tomcat，開發(fā)人員必須要首先了解 Tomcat 的整體設(shè)計結(jié)構(gòu)，然后才能知道如何按照它的規(guī)范來做擴展。這樣無形就增加了對 Tomcat 的學(xué)習(xí)成本。不僅僅是容器，實際上 Tomcat 也有基于責(zé)任鏈的設(shè)計方式，像串聯(lián) Pipeline 的 Vavle 設(shè)計也是與 Jetty 的 Handler 類似的方式。要自己實現(xiàn)一個 Vavle 與寫一個 Handler 的難度不相上下。表面上看，Tomcat 的功能要比 Jetty 強大，因為 Tomcat 已經(jīng)幫你做了很多工作了，而 Jetty 只告訴，你能怎么做，如何做，有你去實現(xiàn)。

打個比方，就像小孩子學(xué)數(shù)學(xué)，Tomcat 告訴你 1+1=2，1+2=3，2+2=4 這個結(jié)果，然后你可以根據(jù)這個方式得出 1+1+2=4，你要計算其它數(shù)必須根據(jù)它給你的公式才能計算，而 Jetty 是告訴你加減乘除的算法規(guī)則，然后你就可以根據(jù)這個規(guī)則自己做運算了。所以你一旦掌握了 Jetty，Jetty 將變得異常強大。

性能比較

單純比較 Tomcat 與 Jetty 的性能意義不是很大，只能說在某種使用場景下，它表現(xiàn)的各有差異。因為它們面向的使用場景不盡相同。從架構(gòu)上來看 Tomcat 在處理少數(shù)非常繁忙的連接上更有優(yōu)勢，也就是說連接的生命周期如果短的話，Tomcat 的總體性能更高。

而 Jetty 剛好相反，Jetty 可以同時處理大量連接而且可以長時間保持這些連接。例如像一些 web 聊天應(yīng)用非常適合用 Jetty 做服務(wù)器，像淘寶的 web 旺旺就是用 Jetty 作為 Servlet 引擎。

另外由于 Jetty 的架構(gòu)非常簡單，作為服務(wù)器它可以按需加載組件，這樣不需要的組件可以去掉，這樣無形可以減少服務(wù)器本身的內(nèi)存開銷，處理一次請求也是可以減少產(chǎn)生的臨時 對象，這樣性能也會提高。另外 Jetty 默認使用的是 NIO 技術(shù)在處理 I/O 請求上更占優(yōu)勢，Tomcat 默認使用的是 BIO，在處理靜態(tài)資源時，Tomcat 的性能不如 Jetty。

特性比較

作為一個標準的 Servlet 引擎，它們都支持標準的 Servlet 規(guī)范，還有 Java EE 的規(guī)范也都支持，由于 Tomcat 的使用的更加廣泛，它對這些支持的更加全面一些，有很多特性 Tomcat 都直接集成進來了。但是 Jetty 的應(yīng)變更加快速，這一方面是因為 Jetty 的開發(fā)社區(qū)更加活躍，另一方面也是因為 Jetty 的修改更加簡單，它只要把相應(yīng)的組件替換就好了，而 Tomcat 的整體結(jié)構(gòu)上要復(fù)雜很多，修改功能比較緩慢。所以 Tomcat 對最新的 Servlet 規(guī)范的支持總是要比人們預(yù)期的要晚。

回頁首

總結(jié)

本文介紹了目前 Java 服務(wù)端中一個比較流行應(yīng)用服務(wù)器 Jetty，介紹了它的基本架構(gòu)和工作原理以及如何和 Jboss 工作，最后與 Tomcat 做了比較。在看這篇文章的時候最好是結(jié)合我前面寫的兩篇文章《 Tomcat 系統(tǒng)架構(gòu)與設(shè)計模式》和《 Servlet 工作原理解析》以及這些系統(tǒng)的源代碼，耐心的都看一下會讓你對 Java 服務(wù)端有個總體的了解。

參考資料

學(xué)習(xí)

• 查看文章 《 Tomcat 系統(tǒng)架構(gòu)與設(shè)計模式》（developerWorks，2010 年 5 月）：了解 Tomcat 中容器的體系結(jié)構(gòu)，基本的工作原理，以及 Tomcat 中使用的經(jīng)典的設(shè)計模式介紹。
  
  
• Servlet工作原理解析， （developerWorks，2011 年 2 月）：以 Tomcat 為例了解 Servlet 容器是如何工作的？一個 Web 工程在 Servlet 容器中是如何啟動的？ Servlet 容器如何解析你在 web.xml 中定義的 Servlet ？用戶的請求是如何被分配給指定的 Servlet 的？ Servlet 容器如何管理 Servlet 生命周期？你還將了解到最新的 Servlet 的 API 的類層次結(jié)構(gòu)，以及 Servlet 中一些難點問題的分析。
  
  
• Tomcat vs Jetty，對 Tomcat 與 Jetty 的做了比較。
  
  
• HTTP 協(xié)議，W3C 關(guān)于 HTTP 協(xié)議的詳細描述。
  
  
• developerWorks Java 技術(shù)專區(qū)：這里有數(shù)百篇關(guān)于 Java 編程各個方面的文章。
  
  

討論

• 加入 developerWorks 中文社區(qū)。查看開發(fā)人員推動的博客、論壇、組和維基，并與其他 developerWorks 用戶交流。
  
  

關(guān)于作者