放棄喜歡的人有多難過，(轉)Google 選擇 Jetty, 放棄 Tomcat

Google 選擇 Jetty, 放棄 Tomcat

10 小時前 by 見習記者 鄉村里的一條土狗
評論(4) 有830人瀏覽 收藏
聲明：JavaEye新聞文章的版權屬于JavaEye網站所有，嚴禁任何網站轉載本文，否則必將追究法律責任！
Google 應用系統引擎最初是以 Apache Tomcat 作為其 webserver/servlet 容器的，但最終將切換到 Jetty 上。 這個決定讓許多開發人員都詫異的想問：為什么要做這樣的改變？Tomcat 有什么問題嗎？ 我們獲得的一次訪問 Webtide ——Jetty 背后的公司——里的這個團隊的機會，得到了關于這個決定背后更詳細的信息。放棄喜歡的人有多難過。

記者： 為什么Google選擇Jetty作為其應用系統的引擎，而不是 Tomcat 或其他的？

Google選擇Jetty的關鍵原因是它的體積和靈活性。 在云計算里，體積的因素是很重要，如果你運行幾萬個Jetty的實例（Google就是這樣干的），每個server省1兆，那就會省10幾個G的內存（或能夠給其他應用提供更多的內存）。選擇比努力更重要。
Jetty 被設計成了可插拔和可擴展的特性，這樣Google就可以高度的自定義它。 他們在其中替換了他們自己的HTTP connector，Google認證，以及他們自己的session集群。也真是奇怪，這個特性對于云計算來說是非常出色的，但同時也讓Jetty非常適合嵌入小的設備中，例如手機和機頂盒。

記者： 是什么促使Jetty成為Java里出色的servlet容器？

我們在開發Jetty時，并沒有想著要把它開發成一個全功能的應用server（盡管它是的）。每一項功能都考慮了可插拔性，所以，如果你不需要他，你就可以不把它加載到內存里，把它從request 處理調用鏈中去掉。如果你不需要sessons，你可以把session處理器拿掉，這樣你就不要浪費資源去來回尋找session cookie了。當你每秒鐘都有出來上千個請求時，這些微小的查找動作的開銷是非常的大的。

我們也并沒有想當然的企圖通過設計就可以得到最優化的代碼，我們是如同收集沙粒般，每次得到一些人告訴我們如何才能有好的JVMs優化和垃圾回收辦法。這是真的，已經很小心的代碼仍然能被優化，最后的效果就是避免創建新的對象。例如，我們在Jetty里使用并行處理技術，但我們并沒有使用很多標準的并行處理數據結構，因為這需要創建太多的對象。所以，只是作為個例子，我們使用了雙并行鎖循環 arrays，而不是采用并行鏈式 lists，這樣我們就能夠在不創建對象的情況下，獲得了非阻塞并行效果。

記者： 是什么使Jetty成為開發人員的一個有用的server平臺的（例如：testing）？

Jetty 已經在一些流行框架中內置了，例如GWT，scala/lift，grails，Jruby等等，還有很多。如果你使用了這些技術，你就直接可以用Jetty了。 Jetty-maven 插件是另外一個非常優秀的開發工具，它能讓web應用在不打包成war文件的情況下運行。源文件可以直接編輯，在不需要把它重新放進war文件的情況下獲得測試結果。 Jetty嵌入式的特征讓我們不再需要寫通過寫那些main方法、通過你的IDE，調試器或 profiler 來運行之類的無聊的事情。

記者： Jetty在處理 client-server 請求時有什么獨特的地方嗎？

Jetty 現在是一個第二代的異步處理server。 過去的兩年里，我們讓Jetty實現了處理異步請求的功能，這成了它核心架構的一部分。就像其他的支持異步serlets容器一樣，我想，他們會發現這個東西并不是看起來的那么簡單和容易。 我們的異步HTTP引擎被我們復用在了HTTP client 上，所以我們可以大量的降低request 和 responses 消耗。
同時，就像我之前提到過的，我們的請求處理器是可擴展和可插拔的，這讓web application可以被單獨省略掉，或者是單獨使用，或者是進一步擴展的application。

記者： 有沒有其他Jetty使用的案例，大的或小的？

使用Jetty的公司有像Zimbra/Yahoo，這意味著Jetty正作為web mail 服務器，為百萬級的用戶提供服務。 Eclipse IDE把它內置了進去，這意味著有成百萬的開發者在桌面運行Jetty。 Jetty被 hadoop map/reduce cluster使用，在其上有幾千個點的集群，處理著世界最大的TB級別的數據分類排序工作。 我們也有 J2ME 的接口，有本地編譯器，所以我們可以在手機上，家用路由器和 Java cards 上運行。 更多的Jetty使用的例子可以參考 http://docs.codehaus.org/display/JETTY/Jetty+Powered

記者： Jetty的將來或藍圖是怎樣的？

Jetty 最近的計劃是發布 7.0.0 版本，這將會完全的遷移到eclipse foundation 下。 Jetty 7 將會支持很多 servlet 3.0 的特征，但是并不會使用新的API 和 不會依賴Java 1.6 。 Jetty 7后，很快我們會發布Jetty 8，這將會完全支持 servlet 3.0 和 Java 1.6，Jetty 會繼續的創新 和跟蹤各種web 2.0 里的其他的新成果。 我們現在已經能支持 Firefox 3.5 里的跨域Ajax功能，我們可以在cometd版本里使用這個。 我們很快就會增加對 WebSocket 和 BWTP 的支持。 對 Google wave 以及相關協議的支持的問題已經優先排到了我們的議事日程上了。

記者： Google/Jetty 還有其他的計劃嗎？

Google有他們自己下棋的棋局，我們并不清楚。 我們在JavaOne大會上曾經和App Engine開發者們有個簡單的對話，我們愿意聽他們任何的反饋和意見，用來改進Jetty的可嵌入性和可擴展性。
下面的跟Webtide團隊的討論中，我們詢問了SpringSource 從Jetty轉換到Tomcat的事情。

記者： 你們如何看待 SpringSource 把 Grails 從本來作為缺省容器的Jetty換成了Tomcat的事情？

原因是grails開發的領導感覺使用Tomcat能從內部的Tomcat開發人員哪里獲得更好的”服務“。我猜測，他們把Grails的用戶驅趕到某一個平臺，以讓SpringSource能更好的銷售他們的技術支持服務。幾年前我們看到了相同的事情，JBoss 雇傭了一下tomcat開發人員后把Jetty提出成了Tomcat，并最終和Mort Bay達成了商業合同。 很遺憾，這些商業協議對技術選擇有如此大的影響，當相同的是，一些基礎結構的工程也正聚集到也application server 為中心的隊伍里來。
rails將會繼續同時支持對Jetty和Tomcat的集成，但會改成Tomcat為缺省服務。

這看起來是 SpringSource使用/攀附 Tomcat 的一個特別合適的論斷