Google App Engine转向了Jetty

一开始Google App Engine将 Apache Tomcat 作为其Web Server/Servlet容器，但最后却转向了 Jetty 。一石激起千层浪，随之而来的是开发者社区无数的质疑之声：为何做此决定？Tomcat有什么问题么？鉴于此，InfoQ采访了 Webtide 团队（Jetty背后的公司）一探究竟。

InfoQ： Google App Engine为何选择Jetty而放弃了Tomcat，或是其他的服务器？

Google之所以选择Jetty，主要是看中了其大小和灵活性。在云中，服务器大小是非常重要的，因为你可能会在10秒内运行 几千个Jetty实例（就像Google那样），这样如果每个服务器能省下1MB，那么10秒内就会省下上GB的内存（省下的内存可供应用使用），这相当 可观。

Jetty还具有可插拔和可扩展的特质，这样Google就能最大限度地对其进行定制了。他们已经插入了自己的HTTP连接器、Google认证以及Session集群了。这些特性说明Jetty不仅适合于云环境，对嵌入式设备如电话和机顶盒等也同样适用。

InfoQ： Jetty是个高效的Java Servlet容器，其背后的秘诀是什么呢？

在开发Jetty之际，我们并未打算将其做成一个完全的应用服务器。我们将每个特性都设计成可插拔的，这样如果不需要某个特性， 那它就不会加载到内存中，同时也不会加载到请求处理的调用链中。如果不需要Session就可以移除Session处理器，这样我们连会话Cookie都 不用找了，大大节省了时间。在每秒处理几千个请求的情况下，任何微小的查找所产生的代价都是高昂的。

我 们并不认为仅仅通过设计就能得到优化的代码，每当有人说起现在的JVM在优化和垃圾收集方面有多么棒时，我们都对其持保留态度。也许他们说的对，但不管怎 样，我们依然可以对精心编写的代码进行优化，当然了，最好的手段就是避免创建对象。比如说，我们在Jetty中使用了并发技术，但却并没有使用常见的标准 并发数据结构，因为这会创建太多的对象。因此，相对于并发链表，我们采用了二重并发锁循环数组（dual concurrent lock circular arrays），这样无需创建对象就能享受到非阻塞并发带来的好处。

InfoQ： 现在很多开发者都在使用Jetty并觉得它很棒，你们是如何做到这一点的呢？

现在Jetty已经内建在很多框架中了，比如GWT、Scala/Lift、Grails、JRuby等等不一而足。这样如果你 使用了上面这些技术就能随时随地使用Jetty了。同时，jetty-maven插件对于广大开发者来说也是一个非常棒的工具，凭借该插件，Web应用无 需将组件打成War包就能运行了。我们可以直接编辑源代码和测试结果而无需构建War包。凭借Jetty的嵌入式特性，我们可以轻松编写一个main方 法，然后直接在IDE、调试器或是分析器中执行。

InfoQ： 在处理客户端——服务器请求时，Jetty有什么独到的方式？

现在Jetty已经成为第二代异步服务器了。这两年来我们一直在致力于异步请求的处理上，现在这已经成为我们的核心架构的一部分 了。有些容器增加了对异步Servlet的支持，但在我看来，事实并不像表面看起来的那么简单。我们的异步HTTP客户端重用了异步HTTP引擎，这样就 能以可伸缩的方式生成请求并处理响应了。

如前所述，我们通过一种可扩展、可插拔的处理器机制来处理请求，这样就可以分别对待（忽略、使用抑或是扩展）Web应用所提供的各种特性。

InfoQ： 能否介绍一下还有哪些地方使用了Jetty，应用规模如何？

Zimbra/Yahoo将Jetty作为Web Mail服务器为上百万用户提供服务，上百万开发者使用的Eclipse IDE嵌入了Jetty，hadoop map/reduce集群（运行在上千个节点集群上，同时还保持有排序1TB数据的记录）也使用了Jetty。我们还有J2ME的移植版以及本地的交叉编 译，这样就能运行在移动电话、家庭路由以及Java card上了！请查看 http://docs.codehaus.org/display/JETTY/Jetty+Powered 以了解其他使用Jetty的项目。

InfoQ： Jetty未来的路线图如何？

目前的当务之急就是发布Jetty 7.0.0以履行我们加入Eclipse基金会时的承诺。Jetty 7将支持Servlet 3.0的众多特性但却不会使用新的API，也不需要Java 1.6。在这之后，我们将发布Jetty 8，它将使用Servlet 3.0和Java 1.6，同时Jetty还将一如既往地紧跟Web 2.0领域的变化脚步并不断创新。现在我们提供了Firefox 3.5的跨域Ajax支持并应用在cometd中。不久的将来，我们还会提供WebSocket和BWTP支持。对Google Wave及相关协议的支持也已经提到了议事日程上，优先级还是非常高的。

InfoQ： Google/Jetty还有什么其他的计划么？

Google的计划并未公之于众，因此我们也不得而知。在JavaOne上，我们曾与App Engine的一些开发者聊过。对于他们所提出的关于如何改进Jetty的嵌入性与扩展性等相关问题，我们会以最快的速度给予回应。

在随后与Webtide团队的讨论中，InfoQ问到了关于SpringSource采用Tomcat而不是Jetty的缘由。

InfoQ： 能否向我们解释一下SpringSource为何将Tomcat而不是Jetty作为Grails的 默认容器 ？

原因在于Grails的主力开发者认为一旦遇到问题，他们能从内部的Tomcat开发者那里获得更好的“服务”。我怀疑这是 SpringSource的商业策略，他们将Grails用户赶到Tomcat上，这样就能向其兜售服务了。JBoss也一样，几年前JBoss雇佣了几 个Tomcat开发人员，同时他们与MortBay的合同也到期了，结果就用Tomcat替换掉了Jetty。商业因素的影响要比技术大的多，我对此感到 遗憾，但现在我们处于这样一个时代：基础项目正源源不断地融合到应用服务器中心了。

Grails还会继续支持Jetty和Tomcat的集成，但默认是处于Tomcat托管模式下。