一开始 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 托管模式下。
通过以上的讨论我们能看出这正是 SpringSource 与 Tomcat 之间的关系。
注册/登录 InfoQ 发表评论