一、Jetty目錄剖析
bin：可執(zhí)行腳本文件
demo- base：
etc：Jetty模塊定義的XML配置文件的目錄
lib：Jetty依賴的庫(kù)文件
logs：Jetty的日志目錄
modules：Jetty的模塊
resources：外部資源配置文件的目錄
webapps：項(xiàng)目WAR文件的目錄還需要關(guān)心根目錄下的一個(gè)文件：start.d（Wondows系統(tǒng)是start.ini文件），它定義了Jetty的活動(dòng)模塊。
二、基本配置
1、修改Jetty的端口
Jetty默認(rèn)使用8080端口，要讓它使用其他端口（如7070），那么編輯start.d（Wondows系統(tǒng)是start.ini文件），找到j(luò)etty.http.port行，修改為：
## Connector port to listen on
jetty.http.port=7070
保存并退出，再重啟Jetty。
2、修改webapps目錄
Jetty下的webapps是默認(rèn)的Web項(xiàng)目的部署目錄，如果想修改此目錄，可修改start.d配置文件（start.ini），移除以下行的注釋符號(hào)“#”
# jetty.deploy.monitoredDir=webapps
并把內(nèi)容修改到你指定的目錄。保存并退出，再重啟Jetty。
三、Jetty的模塊化架構(gòu)
Jetty運(yùn)行于模塊化的架構(gòu)之上，這意味著Jetty的功能是以模塊的方式運(yùn)行的，比如HTTP、HTTPS、SSL、日志logging、JMX、JNDI、WebSocket等模塊。常用的模塊如HTTP、JSP和WebSocket模塊都是默認(rèn)就激活的，而其他如HTTPS、JMX等模塊則需要手動(dòng)激活。
1、單個(gè)模塊的剖析
Jetty的modules子目錄列出了所有的模塊，這些模塊是擴(kuò)展名為.mod的文件，它聲明了要被激活的JAR文件（在Jetty的lib子目錄下）和XML配置文件（在Jetty的etc子目錄下），以及其他要作為模塊被激活的資源。比如，可以查看modules子目錄的logging.mod文件的內(nèi)容，可以看到，它聲明了配置文件是etc/jetty-logging.xml，所需的JAR包在lib/logging處，另外logs目錄是必須的。
[ xml]
etc/jetty-logging.xml
[files]
logs/
[lib]
lib/logging/**.jar
resources/
2、通過命令行激活模塊
激活Jetty的模塊有兩種方式。第一種方式是通過命令行激活：
java -jar start.jar --add-to-startd=logging
上面的命令會(huì)在Jetty目錄下創(chuàng)建logging.ini文件，相關(guān)的配置可以在此文件中查到。配置日志后，可以再次啟動(dòng)Jetty，并可以查看到日志模塊是激活了的。
3、通過配置文件start.ini激活模塊
第二種方式是通過配置文件start.ini激活模塊
--module=logging
這種方式和前一種相似，且更常用。
4、配置模塊
正如上面提到的，mod文件聲明了相關(guān)的XML配置文件，在Jetty的etc子目錄下，可以通過這些配置文件來(lái)配置模塊。比如日志模塊聲明了相關(guān)的配置文件是jetty-logging.xml，可以通過修改此配置文件來(lái)調(diào)整日志。
四、接受請(qǐng)求
Jetty 作為一個(gè)獨(dú)立的 Servlet 引擎可以獨(dú)立提供 Web 服務(wù)，但是它也可以與其他 Web 應(yīng)用服務(wù)器集成，所以它可以提供基于兩種協(xié)議工作，一個(gè)是 HTTP，一個(gè)是 AJP 協(xié)議。如果將 Jetty 集成到 Jboss 或者 Apache，那么就可以讓 Jetty 基于 AJP 模式工作。下面分別介紹 Jetty 如何基于這兩種協(xié)議工作，并且它們?nèi)绾谓⑦B接和接受請(qǐng)求的。
1、基于HTTP
如果前端沒有其它 web 服務(wù)器，那么 Jetty 應(yīng)該是基于 HTTP 協(xié)議工作。也就是當(dāng) Jetty 接收到一個(gè)請(qǐng)求時(shí)，必須要按照 HTTP 協(xié)議解析請(qǐng)求和封裝返回的數(shù)據(jù)。那么 Jetty 是如何接受一個(gè)連接又如何處理這個(gè)連接呢？
我們?cè)O(shè)置 Jetty 的 Connector 實(shí)現(xiàn)類為
org.eclipse.jetty.server.bi.SocketConnector 讓 Jetty 以 BIO 的方式工作，Jetty 在啟動(dòng)時(shí)將會(huì)創(chuàng)建 BIO 的工作環(huán)境，它會(huì)創(chuàng)建 HttpConnection 類用來(lái)解析和封裝 HTTP1.1 的協(xié)議，ConnectorEndPoint 類是以 BIO 的處理方式處理連接請(qǐng)求，ServerSocket 是建立 socket 連接接受和傳送數(shù)據(jù)，Executor 是處理連接的線程池，它負(fù)責(zé)處理每一個(gè)請(qǐng)求隊(duì)列中任務(wù)。acceptorThread 是監(jiān)聽連接請(qǐng)求，一有 socket 連接，它將進(jìn)入下面的處理流程。
當(dāng) socket 被真正執(zhí)行時(shí)，HttpConnection 將被調(diào)用，這里定義了如何將請(qǐng)求傳遞到 servlet 容器里，有如何將請(qǐng)求最終路由到目的 servlet，關(guān)于這個(gè)細(xì)節(jié)可以參考《 servlet 工作原理解析》一文。
下圖是 Jetty 啟動(dòng)創(chuàng)建建立連接的時(shí)序圖：
Jetty 創(chuàng)建接受連接環(huán)境需要三個(gè)步驟：
- 創(chuàng)建一個(gè)隊(duì)列線程池，用于處理每個(gè)建立連接產(chǎn)生的任務(wù)，這個(gè)線程池可以由用戶來(lái)指定，這個(gè)和 Tomcat 是類似的。
- 創(chuàng)建 ServerSocket，用于準(zhǔn)備接受客戶端的 socket 請(qǐng)求，以及客戶端用來(lái)包裝這個(gè) socket 的一些輔助類。
- 創(chuàng)建一個(gè)或多個(gè)監(jiān)聽線程，用來(lái)監(jiān)聽訪問端口是否有連接進(jìn)來(lái)。
相比 Tomcat 創(chuàng)建建立連接的環(huán)境，Jetty 的邏輯更加簡(jiǎn)單，牽涉到的類更少，執(zhí)行的代碼量也更少了。
當(dāng)建立連接的環(huán)境已經(jīng)準(zhǔn)備好了，就可以接受 HTTP 請(qǐng)求了，當(dāng) Acceptor 接受到 socket 連接后將轉(zhuǎn)入下圖所示流程執(zhí)行：
Accetptor 線程將會(huì)為這個(gè)請(qǐng)求創(chuàng)建 ConnectorEndPoint。HttpConnection 用來(lái)表示這個(gè)連接是一個(gè) HTTP 協(xié)議的連接，它會(huì)創(chuàng)建 HttpParse 類解析 HTTP 協(xié)議，并且會(huì)創(chuàng)建符合 HTTP 協(xié)議的 Request 和 Response 對(duì)象。接下去就是將這個(gè)線程交給隊(duì)列線程池去執(zhí)行了。
2、基于AJP
通常一個(gè) web 服務(wù)站點(diǎn)的后端服務(wù)器不是將 Java 的應(yīng)用服務(wù)器直接暴露給服務(wù)訪問者，而是在應(yīng)用服務(wù)器，如 Jboss 的前面在加一個(gè) web 服務(wù)器，如 Apache 或者 nginx，我想這個(gè)原因大家應(yīng)該很容易理解，如做日志分析、負(fù)載均衡、權(quán)限控制、防止惡意請(qǐng)求以及靜態(tài)資源預(yù)加載等等。
下圖是通常的 web 服務(wù)端的架構(gòu)圖：
這種架構(gòu)下 servlet 引擎就不需要解析和封裝返回的 HTTP 協(xié)議，因?yàn)?HTTP 協(xié)議的解析工作已經(jīng)在 Apache 或 Nginx 服務(wù)器上完成了，Jboss 只要基于更加簡(jiǎn)單的 AJP 協(xié)議工作就行了，這樣能加快請(qǐng)求的響應(yīng)速度。
對(duì)比 HTTP 協(xié)議的時(shí)序圖可以發(fā)現(xiàn)，它們的邏輯幾乎是相同的，不同的是替換了一個(gè)類 Ajp13Parserer 而不是 HttpParser，它定義了如何處理 AJP 協(xié)議以及需要哪些類來(lái)配合。
實(shí)際上在 AJP 處理請(qǐng)求相比較 HTTP 時(shí)唯一的不同就是在讀取到 socket 數(shù)據(jù)包時(shí)，如何來(lái)轉(zhuǎn)換這個(gè)數(shù)據(jù)包，是按照 HTTP 協(xié)議的包格式來(lái)解析就是 HttpParser，按照 AJP 協(xié)議來(lái)解析就是 Ajp13Parserer。封裝返回的數(shù)據(jù)也是如此。
讓 Jetty 工作在 AJP 協(xié)議下，需要配置 connector 的實(shí)現(xiàn)類為 Ajp13SocketConnector，這個(gè)類繼承了 SocketConnector 類，覆蓋了父類的 newConnection 方法，為的是創(chuàng)建 Ajp13Connection 對(duì)象而不是 HttpConnection。如下圖表示的是 Jetty 創(chuàng)建連接環(huán)境時(shí)序圖：
與 HTTP 方式唯一不同的地方的就是將 SocketConnector 類替換成了 Ajp13SocketConnector。改成 Ajp13SocketConnector 的目的就是可以創(chuàng)建 Ajp13Connection 類，表示當(dāng)前這個(gè)連接使用的是 AJP 協(xié)議，所以需要用 Ajp13Parser 類解析 AJP 協(xié)議，處理連接的邏輯都是一樣的。如下時(shí)序圖所示：
3、NIO處理方式
Jetty 建立客戶端連接到處理客戶端的連接也支持 NIO 的處理方式，其中 Jetty 的默認(rèn) 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)建一個(gè) Selector 相當(dāng)于一個(gè)觀察者，打開一個(gè) Server 端通道，把這個(gè) server 通道注冊(cè)到觀察者上并且指定監(jiān)聽的事件。然后遍歷這個(gè)觀察者觀察到事件，取出感興趣的事件再處理。這里有個(gè)最核心的地方就是，我們不需要為每個(gè)被觀察者創(chuàng)建一個(gè)線程來(lái)監(jiān)控它隨時(shí)發(fā)生的事件。而是把這些被觀察者都注冊(cè)一個(gè)地方統(tǒng)一管理，然后由它把觸發(fā)的事件統(tǒng)一發(fā)送給感興趣的程序模塊。這里的核心是能夠統(tǒng)一的管理每個(gè)被觀察者的事件，所以我們就可以把服務(wù)端上每個(gè)建立的連接傳送和接受數(shù)據(jù)作為一個(gè)事件統(tǒng)一管理，這樣就不必要每個(gè)連接需要一個(gè)線程來(lái)維護(hù)了。
這里需要注意的地方時(shí)，很多人認(rèn)為監(jiān)聽 SelectionKey.OP_ACCEPT 事件就已經(jīng)是非阻塞方式了，其實(shí) Jetty 仍然是用一個(gè)線程來(lái)監(jiān)聽客戶端的連接請(qǐng)求，當(dāng)接受到請(qǐng)求后，把這個(gè)請(qǐng)求再注冊(cè)到 Selector 上，然后才是非阻塞方式執(zhí)行。這個(gè)地方還有一個(gè)容易引起誤解的地方是：認(rèn)為 Jetty 以 NIO 方式工作只會(huì)有一個(gè)線程來(lái)處理所有的請(qǐng)求，甚至?xí)J(rèn)為不同用戶會(huì)在服務(wù)端共享一個(gè)線程從而會(huì)導(dǎo)致基于 ThreadLocal 的程序會(huì)出現(xiàn)問題，其實(shí)從 Jetty 的源碼中能夠發(fā)現(xiàn)，真正共享一個(gè)線程的處理只是在監(jiān)聽不同連接的數(shù)據(jù)傳送事件上，比如有多個(gè)連接已經(jīng)建立，傳統(tǒng)方式是當(dāng)沒有數(shù)據(jù)傳輸時(shí)，線程是阻塞的也就是一直在等待下一個(gè)數(shù)據(jù)的到來(lái)，而 NIO 的處理方式是只有一個(gè)線程在等待所有連接的數(shù)據(jù)的到來(lái)，而當(dāng)某個(gè)連接數(shù)據(jù)到來(lái)時(shí) Jetty 會(huì)把它分配給這個(gè)連接對(duì)應(yīng)的處理線程去處理，所以不同連接的處理線程仍然是獨(dú)立的。
Jetty 的 NIO 處理方式和 Tomcat 的幾乎一樣，唯一不同的地方是在如何把監(jiān)聽到事件分配給對(duì)應(yīng)的連接的處理方式。從測(cè)試效果來(lái)看 Jetty 的 NIO 處理方式更加高效。下面是 Jetty 的 NIO 處理時(shí)序圖：
五、與 Tomcat 的比較
Tomcat 和 Jetty 都是作為一個(gè) Servlet 引擎應(yīng)用的比較廣泛，可以將它們比作為中國(guó)與美國(guó)的關(guān)系，雖然 Jetty 正常成長(zhǎng)為一個(gè)優(yōu)秀的 Servlet 引擎，但是目前的 Tomcat 的地位仍然難以撼動(dòng)。相比較來(lái)看，它們都有各自的優(yōu)點(diǎn)與缺點(diǎn)。
Tomcat 經(jīng)過長(zhǎng)時(shí)間的發(fā)展，它已經(jīng)廣泛的被市場(chǎng)接受和認(rèn)可，相對(duì) Jetty 來(lái)說(shuō) Tomcat 還是比較穩(wěn)定和成熟，尤其在企業(yè)級(jí)應(yīng)用方面，Tomcat 仍然是第一選擇。但是隨著 Jetty 的發(fā)展，Jetty 的市場(chǎng)份額也在不斷提高，至于原因就要?dú)w功與 Jetty 的很多優(yōu)點(diǎn)了，而這些優(yōu)點(diǎn)也是因?yàn)?Jetty 在技術(shù)上的優(yōu)勢(shì)體現(xiàn)出來(lái)的。
架構(gòu)比較
從架構(gòu)上來(lái)說(shuō)，顯然 Jetty 比 Tomcat 更加簡(jiǎn)單，如果你對(duì) Tomcat 的架構(gòu)還不是很了解的話，建議你先看一下 《Tomcat系統(tǒng)架構(gòu)與設(shè)計(jì)模式》這篇文章。
Jetty 的架構(gòu)從前面的分析可知，它的所有組件都是基于 Handler 來(lái)實(shí)現(xiàn)，當(dāng)然它也支持 JMX。但是主要的功能擴(kuò)展都可以用 Handler 來(lái)實(shí)現(xiàn)。可以說(shuō) Jetty 是面向 Handler 的架構(gòu)，就像 Spring 是面向 Bean 的架構(gòu)，iBATIS 是面向 statement 一樣，而 Tomcat 是以多級(jí)容器構(gòu)建起來(lái)的，它們的架構(gòu)設(shè)計(jì)必然都有一個(gè)“元神”，所有以這個(gè)“元神“構(gòu)建的其它組件都是肉身。
從設(shè)計(jì)模板角度來(lái)看 Handler 的設(shè)計(jì)實(shí)際上就是一個(gè)責(zé)任鏈模式，接口類 HandlerCollection 可以幫助開發(fā)者構(gòu)建一個(gè)鏈，而另一個(gè)接口類 ScopeHandler 可以幫助你控制這個(gè)鏈的訪問順序。另外一個(gè)用到的設(shè)計(jì)模板就是觀察者模式，用這個(gè)設(shè)計(jì)模式控制了整個(gè) Jetty 的生命周期，只要繼承了 LifeCycle 接口，你的對(duì)象就可以交給 Jetty 來(lái)統(tǒng)一管理了。所以擴(kuò)展 Jetty 非常簡(jiǎn)單，也很容易讓人理解，整體架構(gòu)上的簡(jiǎn)單也帶來(lái)了無(wú)比的好處，Jetty 可以很容易被擴(kuò)展和裁剪。
相比之下，Tomcat 要臃腫很多，Tomcat 的整體設(shè)計(jì)上很復(fù)雜，前面說(shuō)了 Tomcat 的核心是它的容器的設(shè)計(jì)，從 Server 到 Service 再到 engine 等 container 容器。作為一個(gè)應(yīng)用服務(wù)器這樣設(shè)計(jì)無(wú)口厚非，容器的分層設(shè)計(jì)也是為了更好的擴(kuò)展，這是這種擴(kuò)展的方式是將應(yīng)用服務(wù)器的內(nèi)部結(jié)構(gòu)暴露給外部使用者，使得如果想擴(kuò)展 Tomcat，開發(fā)人員必須要首先了解 Tomcat 的整體設(shè)計(jì)結(jié)構(gòu)，然后才能知道如何按照它的規(guī)范來(lái)做擴(kuò)展。這樣無(wú)形就增加了對(duì) Tomcat 的學(xué)習(xí)成本。不僅僅是容器，實(shí)際上 Tomcat 也有基于責(zé)任鏈的設(shè)計(jì)方式，像串聯(lián) Pipeline 的 Vavle 設(shè)計(jì)也是與 Jetty 的 Handler 類似的方式。要自己實(shí)現(xiàn)一個(gè) Vavle 與寫一個(gè) Handler 的難度不相上下。表面上看，Tomcat 的功能要比 Jetty 強(qiáng)大，因?yàn)?Tomcat 已經(jīng)幫你做了很多工作了，而 Jetty 只告訴，你能怎么做，如何做，有你去實(shí)現(xiàn)。
打個(gè)比方，就像小孩子學(xué)數(shù)學(xué)，Tomcat 告訴你 1+1=2，1+2=3，2+2=4 這個(gè)結(jié)果，然后你可以根據(jù)這個(gè)方式得出 1+1+2=4，你要計(jì)算其它數(shù)必須根據(jù)它給你的公式才能計(jì)算，而 Jetty 是告訴你加減乘除的算法規(guī)則，然后你就可以根據(jù)這個(gè)規(guī)則自己做運(yùn)算了。所以你一旦掌握了 Jetty，Jetty 將變得異常強(qiáng)大。
性能比較
單純比較 Tomcat 與 Jetty 的性能意義不是很大，只能說(shuō)在某種使用場(chǎng)景下，它表現(xiàn)的各有差異。因?yàn)樗鼈兠嫦虻氖褂脠?chǎng)景不盡相同。從架構(gòu)上來(lái)看 Tomcat 在處理少數(shù)非常繁忙的連接上更有優(yōu)勢(shì)，也就是說(shuō)連接的生命周期如果短的話，Tomcat 的總體性能更高。
而 Jetty 剛好相反，Jetty 可以同時(shí)處理大量連接而且可以長(zhǎng)時(shí)間保持這些連接。例如像一些 web 聊天應(yīng)用非常適合用 Jetty 做服務(wù)器，像淘寶的 web 旺旺就是用 Jetty 作為 Servlet 引擎。
另外由于 Jetty 的架構(gòu)非常簡(jiǎn)單，作為服務(wù)器它可以按需加載組件，這樣不需要的組件可以去掉，這樣無(wú)形可以減少服務(wù)器本身的內(nèi)存開銷，處理一次請(qǐng)求也是可以減少產(chǎn)生的臨時(shí)對(duì)象，這樣性能也會(huì)提高。另外 Jetty 默認(rèn)使用的是 NIO 技術(shù)在處理 I/O 請(qǐng)求上更占優(yōu)勢(shì)，Tomcat 默認(rèn)使用的是 BIO，在處理靜態(tài)資源時(shí)，Tomcat 的性能不如 Jetty。
特性比較
作為一個(gè)標(biāo)準(zhǔn)的 Servlet 引擎，它們都支持標(biāo)準(zhǔn)的 Servlet 規(guī)范，還有 Java EE 的規(guī)范也都支持，由于 Tomcat 的使用的更加廣泛，它對(duì)這些支持的更加全面一些，有很多特性 Tomcat 都直接集成進(jìn)來(lái)了。但是 Jetty 的應(yīng)變更加快速，這一方面是因?yàn)?Jetty 的開發(fā)社區(qū)更加活躍，另一方面也是因?yàn)?Jetty 的修改更加簡(jiǎn)單，它只要把相應(yīng)的組件替換就好了，而 Tomcat 的整體結(jié)構(gòu)上要復(fù)雜很多，修改功能比較緩慢。所以 Tomcat 對(duì)最新的 Servlet 規(guī)范的支持總是要比人們預(yù)期的要晚。
參考資料
官方文檔
Jetty 的工作原理以及與 Tomcat 的比較
個(gè)人介紹：
高廣超 ：多年一線互聯(lián)網(wǎng)研發(fā)與架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)，擅長(zhǎng)設(shè)計(jì)與落地高可用、高性能互聯(lián)網(wǎng)架構(gòu)。
