Jetty 的架構從前面的分析可知，它的所有組件都是基於 Handler 來實現，當然它也支持 JMX。但是主要的功能擴展都可以用 Handler 來實現。可以說 Jetty 是面向 Handler 的架構，就像 Spring 是面向 Bean 的架構，iBATIS 是面向 statement 一樣，而 Tomcat 是以多級容器構建起來的，它們的架構設計必然都有一個“元神”，所有以這個“元神“構建的其它組件都是肉身。

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

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

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

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

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

Jetty與Tomcat的區別