Google App Servlet容器转型了，最初是Apache Tomcat ，但最终将切换到 Jetty 上。很多人想问：为什么要做?Tomcat 有什么问题吗? 我们获得的一次访问 Webtide(Jetty 开发个团队)的机会，一下是一些详细的信息：
提问: 为什么Google选择Jetty作为web服务器和Servlet容器，而不是 Tomcat 或其他的?
Google选择Jetty的关键原因是它的性能和灵活性。 在云计算里，性能的因素很重要，如果你运行几万个Jetty的实例(Google就是这样干的)，每个server省1M内存空间，那就会省10几个G的内存(或者在相同的内存下运行更多的Jetty实例)。
Jetty 由于其设计的精巧因此拥有可插拔和可扩展的特性，这样Google就可以高度的自定义它。 Google替换了他们自己的HTTP connector，Google认证，以及Google自己的session集群。这些特性对于云计算来说是非常出色的，同时特性也让Jetty非常适合嵌入小型设备中，例如手机和机顶盒等。
提问： 是什么促使Jetty成为Java里出色的servlet容器?
我们在开发Jetty时，并没有想着要把Jetty开发成一个全功能的应用程序服务器（但实际上Jetty确实是一个全功能）。每一项功能都考虑了可插拔性，如果你不需要某些功能，就可以不把它加载到内存里，然后可以把该功能从request过滤器中去掉。比如：不需要sessons，你可以把session处理器去掉，这样你就不要浪费资源去处理session了。当每秒处理上万个请求的时候，每项微小的开销都将累计到一起形成巨大的性能开销。
我们也并没有想当然的企图通过设计就可以得到最优化的代码，我们是如同收集沙粒般，每次得到一些人告诉我们如何才能有好的JVMs优化和垃圾回收办法。这是真的，已经很小心的代码仍然能被优化，最后的效果就是避免创建新的对象。例如，我们在Jetty里使用并行处理技术，但我们并没有使用很多标准的并行处理数据结构，因为这需要创建太多的对象。所以，只是作为个例子，我们使用了双并行锁循环 arrays，而不是采用并行链式 lists，这样我们就能够在不创建对象的情况下，获得了非阻塞并行效果。
提问： 是什么使Jetty成为开发人员首选的应用程序服务器(例如：方便调试)?
Jetty 已经在被嵌入到很多流行框架中，例如GWT，Scala/lift，Grails，JRuby等等。如果你使用了这些技术，你就直接可以用 Jetty了。 maven jetty plugin是另外一个非常优秀的开发工具，它能让web应用在不打包成war文件的情况下直接运行。现在越来越多的项目开始使用maven进行管理，因此maven jetty plugin的使用范围非常的广，通过使用maven jetty plugin,您可以直接获得与打包成war文件相同的测试结果。 Jetty嵌入式的特性让我们不再需要写通过写那些main方法、通过你的IDE，调试器或 profiler 来执行应用。
提问： Jetty在处理 客户端/服务器 请求(request)时有什么独特的地方吗?
Jetty 现在是一个第二代的异步处理 应用程序服务器。过去的两年里，我们让Jetty实现了处理异步请求的功能，这成了Jetty核心架构的一部分。就像其他的支持异步Servlet容器一样，我想，他们会发现这个东西并不是看起来的那么简单和容易。 我们的异步HTTP引擎被我们复用在了HTTP client 上，所以我们可以大量的降低request 和 responses 开销。同时，就像我之前提到过的，我们的请求处理器是可扩展和可插拔的，这让web应用程序 可以被单独省略掉，或者是单独使用，或者是进一步扩展的应用程序。
提问： 能否列举一些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达成了商业合同。很遗憾，这些商业协议对技术选择有如此大的影响，当相同的是，一些基础结构的工程也正聚集到以 应用程序服务器 为中心的队伍里来。
Grails将会继续同时支持对Jetty和Tomcat的集成，但会改成Tomcat为缺省服务。
这看起来是 SpringSource使用 Tomcat 的一个特别合适的论断。
[ad#468-60]