一位ID是jackson1225的网友在javaeye询问了一个大型Web系统的架构和部署选型问题，希望能提高现有的基于Java的Web应用的服务能力。由于架构模式和部署调优一直是Java社区的热门话题，这个问题引发了很多热心网友的讨论，其中一些意见对其它大型Web项目也有很好的指导意义。在讨论之初jackson1225这样描述了当前的应用的架构和部署方案：

目前系统架构如下:

1. web层采用struts+tomcat实现，整个系统采用20多台web服务器，其负载均衡采用硬件F5来实现；
2. 中间层采用无状态会话Bean+DAO+helper类来实现，共3台weblogic服务器，部署有多个EJB，其负载均衡也采用F5来实现；
3. 数据库层的操作是自己写的通用类实现的，两台ORACLE数据库服务器，分别存放用户信息和业务数据；一台SQL SERVER数据库，是第三方的业务数据信息；

web层调用EJB远程接口来访问中间件层。web层首先通过一个XML配置文件中配置的EJB接口信息来调用相应的EJB远程接口；

该系统中一次操作涉及到两个ORACLE库以及一个SQL SERVER库的访问和操作，即有三个数据库连接，在一个事务中完成。

这样的架构其实很多公司都在使用，因为Struts和Tomcat分别是最流行的Java Web MVC框架和Servlet容器，而F5公司的负载均衡是横向扩展常见的解决方案（例如配置session sticky方案）。由于这个系统中有跨数据源的事务，所以使用Weblogic Server EJB容器和支持两阶段提交的数据库驱动就可以保证跨数据源的事物完整性（当然，容器管理的分布式事务并非是唯一和最优的解决方案）。

但是随着Rod Johnson重量级的著作《J2EE Development without EJB》和其中的Spring框架的流行，轻量级框架和轻量级容器的概念已经深入人心。所以对于jackson1225提出的这个场景，大多数网友都提出了置疑，认为这个系统滥用了技术，完全是在浪费钱。网友们大都认为SLSB（无状态会话Bean）完全没有必要出现在这个场景中，认为SLSB通过远程接口访问本地资源会有很大的性能开销，这种观点也是Rod johnson在without EJB中批判EJB 2.x中的一大反模式。

由于JavaEE是一个以模式见长的解决方案，模式和架构在JavaEE中占有很重要的地位，所以很多业内专家也都警惕“反模式（Anti-patterns）”的出现。对于上面所述的方案是否是反模式，jackson1225马上站出来申辩：

我们项目就是把EJB作为一个Facade，只是提供给WEB层调用的远程接口，而且只用了无状态会话Bean，所以性能上还可以的。

这个解释很快得到了一些网友的认可，但是大家很快意识到架构的好坏决定于是否能够满足用户的需求，davexin（可能是jackson1225的同事）描述了这个系统的用户和并发情况：

现在有用户4000万，马上要和另一个公司的会员系统合并，加起来一共有9000万用户。数据量单表中有一亿条以上的数据。这是基本的情况，其实我觉得现在的架构还是可以的，现在支持的并发大概5000并发用户左右，接下来会进行系统改造，目标支持1万个并发用户。

具体的并发量公布后又有网友置疑这个数据，认为这个系统的Servlet容器支持的并发数太小，怀疑是否配置不够优化。davexin又补充了该项目的服务器配置：

系统前端tomcat都是用的刀片，配置在2G内存，cpu大概在2.0G，每台机器也就支持250-400个并发，再多的话，就会相应时间非常的常，超过20秒，失去了意义 ，所以我们才得出这样的结论的。

一位ID是cauherk的网友提出了比较中肯的意见，他没有从Web容器单纯的并发支持能力上提出改进方案，而是提出了对于类似的应用的一些通用的改进提示，这里摘要一下：

1. 数据库压力问题

   可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。

2. 事务问题

   要在两个数据库中操作，那么必须考虑到分布式事务。你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整)，来避免分布式事务的问题，毕竟commit失败的几率很低。

3. web的优化

   将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存， google很多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力。

   对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。

4. 网络问题

   可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资，可以采用CDN(内容分发网)，减轻你的服务器压力。

cauherk的这个分析比较到位，其中ETags的方案是最近的一个热点，InfoQ的“使用ETags减少Web应用带宽和负载”里面对这种方案有很详细的介绍。一般以数据库为中心的Web应用的性能瓶颈都在数据库上，所以cauherk把数据库和事务问题放到了前两位来讨论。但是davexin解释在所讨论的这个项目中数据库并非瓶颈：

我们的压力不在数据库层，在web层和F5。 当高峰的时候 ，F5也被点死了，就是每秒点击超过30万，web动态部分根本承受不了。根据我们程序记录，20台web最多承受5000个并发，如果再多，tomcat就不响应了。就像死了一样。

这个回复让接下来的讨论都集中于Web容器的性能优化，但是JavaEye站长robbin发表了自己的意见，将话题引回了这个项目的架构本身：

performance tuning最重要的就是定位瓶颈在哪里，以及瓶颈是怎么产生的。

我的推测是瓶颈还是出在EJB远程方法调用上！

tomcat上面的java应用要通过EJB远程方法调用，来访问weblogic上面的无状态SessionBean，这样的远程方法调用一般都在100ms~500ms级别，或者更多。而如果没有远程方法调用，即使大量采用spring的动态反射，一次完整的web请求处理在本地JVM内部的完成时间一般也不过20ms而已。一次web请求需要过长的执行时间，就会导致servlet线程被占用更多的时间，从而无法及时响应更多的后续请求。

如果这个推测是成立的话，那么我的建议就是既然你没有用到分布式事务，那么就干脆去掉EJB。weblogic也可以全部撤掉，业务层使用spring取代EJB，不要搞分布式架构，在每个tomcat实例上面部署一个完整的分层结构。

另外在高并发情况下，apache处理静态资源也很耗内存和CPU，可以考虑用轻量级web server如lighttpd/litespeed/nginx取代之。

robbin的推断得到了网友们的支持，davexin也认同robbin的看法，但是他解释说公司认为放弃SLSB存在风险，所以公司倾向于通过将Tomcat替换为Weblogic Server 10来提升系统的用户支撑能力。robbin则马上批评了这种做法：

坦白说我还从来没有听说过大规模互联网应用使用EJB的先例。为什么大规模互联网应用不能用EJB，其实就是因为EJB性能太差，用了EJB几乎必然出现性能障碍。

web容器的性能说到底无非就是Servlet线程调度能力而已，Tomcat不像WebLogic那样附加n多管理功能，跑得快很正常。对比测试一下WebLogic的数据库连接池和C3P0连接池的性能也会发现类似的结论，C3P0可要比WebLogic的连接池快好几倍了。这不是说WebLogic性能不好，只不过weblogic要实现更多的功能，所以在单一的速度方面就会牺牲很多东西。

以我的经验来判断，使用tomcat5.5以上的版本，配置apr支持，进行必要的tuning，使用BEA JRockit JVM的话，在你们目前的刀片上面，支撑500个并发完全是可以做到的。结合你们目前20个刀片的硬件，那么达到1万并发是没问题的。当然这样做的前提是必须扔掉EJB，并置web层和业务层在同一个JVM内部。

接下来robbin还针对davexin对话题中的应用分别在tomcat和weblogic上的测试数据进行了分析：

引用：

2。1台weblogic10 Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户......
......
4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。

这说明瓶颈还不在EJB远程调用上，但是问题已经逐渐清楚了。为什么weblogic充当web容器发起远程EJB调用的时候可以支撑1000个并发，但是tomcat只能到350个？只有两个可能的原因：

1. 你的tomcat没有配置好，严重影响了性能表现
2. tomcat和weblogic之间的接口出了问题

 

接着springside项目发起者江南白衣也提出了一个总体的优化指导：

1.基础配置优化

tomcat 6？ tomcat参数调优?
JRockit JVM? JVM参数调优？
Apache+Squid 处理静态内容？

2.业务层优化

部分功能本地化，而不调remote session bean?
异步提交操作,JMS？
cache热点数据？

3.展示层优化

动态页面发布为静态页面？
Cache部分动态页面内容？

davexin在调整了Tomcat配置后应验了robbin对tomcat配置问题的质疑，davexin这样描述经过配置优化以后的测试结果：

经过测试，并发人数是可以达到像robbin所说的一样，能够在600人左右，如果压到并发700人，就有15%左右的失败，虽然在调整上面参数之后，并发人数上去了，但是在同样的时间内所完成的事务数量下降了10%左右，并且响应时间延迟了1秒左右，但从整体上来说，牺牲一点事务吞吐量和响应时间，并发人数能够提高500，觉得还是值得的。

至此这个话题有了一个比较好的结果。这个话题并非完全针对一个具体的项目才有意义，更重要的是在分析和讨论问题的过程中网友们解决问题的思路，尤其是cauherk、robbin、江南白衣等几位网友提出的意见可以让广大Java Web项目开发者了解到中、大型项目所需要考虑的架构和部署所需要考虑的关键问题，也消除了很多人对轻量Servlet容器与EJB容器性能的一些误解。

在讨论中还有一些小插曲，如davexin和江南白衣讨论了JRocket的实时（Realtime）版本是否可以提升Servlet容器的相应能力，答案是不可以。还有ID为mfc42d的网友从Servlet容器的并发支持能力引申到了Java的线程调度能力和NIO对Servelet容器的意义，他推荐了自己的两篇不错的blog“java的线程实现”和“java进程使用的最大内存的数值”，blog文章里面从JVM源码级别分析了Java的线程支持能力，面临JVM性能调优问题的网友可以认真阅读一下。

IBM developerWorks网站上最近发布了一则Cameron Laird的关于轻量级Web服务器的文章， 里面列举了很多的轻型的Web服务器实现和它们的特点，Cameron还从自己的经验出发总结了评价Web服务器的一些指标。这篇文章目的在于扩展我们在 Web应用部署时的思路，让我们重新思考Web应用的架构和部署方案。众多的轻量级Web服务器其实见证了动态脚本语言实现Web应用的火爆，给实现 Web应用提供了更多解决方案。

轻量Web服务器这个概念关注“轻巧性”，这意味着简单、易于安装、流线化、要求低和健壮。这种“轻巧”主要是相对于目前市场占有率占优的 Apache和IIS而言的，轻量Web服务器应该更小更简单，并且它们至少要有一些性能／特性超过这两个产品（这样它们才可能分得市场份额）。 Cameron这样对比了“轻量”相比“重量”的一些优势：

轻量级Web服务器可以适用于市场领头产品和其他“重量级”服务器无法胜任的情况。例如，整个服务器可以打包在一个文件中。这意 味着开发人员可以方便地携带生产环境所需的所有工具。即使在生产服务器上运行的是 Apache，也仍然可以在宾馆的房间里，借助只需数秒钟就可以安装完毕的轻量级Web服务器以尝试新想法。而且，由于轻量级Web服务器要求很低，因此 可以在那些无法负担IIS的主机上顺畅地运行。

我们关注一下目前的Web服务器占有率情况，Netcraft在它2007年7月的Web服务器调查中的服务器占有率数据如下：

其中Apache占有率最高，它是公认的稳定、性能优良、开发者活跃的开源软件产品。而Microsoft则受益于Windows平台内置的PWS 和IIS的优势及.NET平台的市场占优率，占有第二的位置。Sun则是由于历史问题，它的iPlanet、SunONE和一并计算的Netscape- Communications产品还能跻身前4。后面的lighttpd则是轻量型Web容器的代表，已经超过了老牌的商业Web服务器Zeus （ServerWatch给出了一个lighttpd市场占有率上升的分析），主要因为一些AJAX项目和Ruby on Rails（以下简称RoR）的流行对它的广泛部署起了推波助澜的作用。

轻量Web服务器除了lighttpd还有mongrel也经常被提及，主要因为它们是RoR项目的两种主要部署方案。JavaEye的创始人Robbin Fan曾经在它的blog中对比过RoR的这两种部署方案：

（RoR项目）用fcgi方式还是http方式，我个人觉得区别不大，关键还是看应用的场合，一般而言，推荐的搭配是lighttpd＋fcgi 或者nginx＋mongrel，而Apache因为性能差距，而不被推荐。

lighttpd+fcgi是大量使用脚本语言编写的网站的首选部署方案，Robbin Fan在同一篇文章中阐述了他选择lighttp部署JavaEye的理由：

JavaEye为什么用lighttpd＋fcgi呢？原因如下：

1) lighttpd发展了好几年了，市场占有率也相当高，是一个经过实践检验的server，它的文档也很全；

2) JavaEye的Ruby进程和Web Server在一台机器上面跑，通过unix socket使用fcgi协议通讯可以避免tcp的网络开销，其通讯速度比使用tcp socket使用http协议通讯要快一些。

Robbin选择lighttpd的主要原因是性能好于Apache。并且Apache目前的fastcgi模块有些bug，而对于像RoR这样的项目fastcgi是一种很好的部署方式，所以Apache就因此失去了这块份额。最近InfoQ报道过的RubyWorks提 供的RoR工作栈中选择了Haproxy+mongrel的方式，这也是前面引用的Robbin所说的另外一种部署方案。mongrel本身可以跑 Ruby进程，同时也是一个http服务器，它可以兼顾动态和静态Web服务，配合Haproxy做负载均衡就可以支持大并发量的Web应用，所以它越来 越流行了。

性能：对请求作出响应的速度有多快？

可伸缩性：当很多用户同时访问它时，服务器还能继续可靠地运行吗？

安全性：服务器是否只执行它应该执行的操作。它在认证用户和加密传输方面提供了怎样的支持？它的使用是否使附近的应用程序或主机变得更易受攻击？

可靠性：服务器的失效模式和故障发生率如何？

标准遵从性：服务器遵从相关的 RFC 吗？

灵活性：是否可以对服务器进行调优，以支持较重的请求负载、需要计算的动态页面或者代价不菲的认证等等？

平台需求：该服务器可用于哪些平台？它是否有特定的硬件需求？

易管理性：服务器是否易于设置和维护？它是否与日志记录、审计、成本计算等组织标准兼容？

YouTube依靠lighttpd快速交付归档的内容，例如视频；

cdServe运行 “German Woodworking Machinery and Tools” CD；

LiteSpeed宣扬它在 twitter、www.funnyoride.com、www.airliners.com、WordPress.com、 fanfiction.com、SlashGear、www.forumactif.com 和其他著名Web 站点上担任的角色；

OpenSUSE、RubyOnRails、MarkaBoo和其他一些著名站点依赖于Mongrel；

demon.net、bluelight.com、mtv.com、The Drudge Report、garfield.com等站点则使用thttpd；

上面的例子中有一些使用RoR的网站的例子，Cameron指出不仅是网站可以使用常规以外的其他编程语言。“不常见”语言还可以被用来实现轻量 Web服务器，例如Erlang、Java、Lisp、Lua、Perl、Python和Tcl。用这些语言实现的轻量级Web服务器不一定只是在性能／ 特性上超过Apache和IIS，它们可以提供例如容易嵌入、体积轻小这样的特性来吸引开发者的使用。Cameron给出了使用“不常见”语言编写轻量级 Web服务器的原因：

教学：使用轻量级Web服务器来制定一个重要、但是并不太大的目标。这是获得使用某种语言的经验的好方法。

虽然用C编写的轻量级Web服务器大小为10-50KB，更高级的语言有100KB到数MB的运行时，但整个 Web 服务器的源文件可能只占几千个字节。这种Web服务器占用的空间很小，因此比Apache更易于与技术伙伴共享。

更高级的语言可以使实验更吸引人 —— 例如，添加一个新的HTTP/1.1特性可能只需几行源代码。这些轻量级服务器是非常方便的实验材料。

将HTTP服务器添加到已有的、用高级语言编写的应用程序中只需增加几行源代码。

如前所述，不同的轻量级Web服务器有着不同的优点，它们或多或少独立于编程语言。所有轻量级Web服务器都比Apache更小、更易于配置。与 Apache相比，有些轻量级 Web 服务器更快，有些则快得多。有些则强调安全性、重负载下的从容性、可扩展性或者内存占有量。在任何情况下，都可以以一种不适用于 Apache 的方式彻底地理解这些服务器。

这些理由从另外一个方面说明了轻量级Web服务器的优势，Cameron还提供了一长串的轻量级Web服务器的列表和简介，感兴趣的读者可以认真阅读，从中寻找到您感兴趣的实现。轻量级Web服务器不只是Apache、IIS的竞争者，也是很好的合作者（例如我们经常可以见到关于mongrel与Apache配合使用的文章），现在我们还可以看到很多服务器协作部署的例子，各取所长应该是最佳的选择，所以我们更应该从现在就开始拓宽眼界，寻找我们所需要的。

最后，推荐对Web服务器感兴趣的读者可以使用Netcraft提供的Webserver Search的服务器查询功能来探索你感兴趣的网站的服务器，Webserver Search可以报告搜索的url对应的服务器的操作系统和Web服务器类型，是设计部署方案的一个很好参考。

JavaEye上活跃的开发者Complystill（歆渊）最近发布了自己的开源SecureJSH项目，提供了一个通过SSH交互进行Java应用开发或者管理的工具。

在项目的介绍中可以得知，SecureJSH与Ptyhon里面的ipython或者Ruby里面的irb非常相似。它们都允许交互式运行语言的代 码，以方便跟踪或者调试应用。但是，Java与Ruby、Python不同，后者是动态脚本语言，它们天生具有解释执行的特点（注意：当然Python支 持预编译，Ruby也将在YARV中开始支持，这里指它们的解释执行状态）。我们常见的Python和Ruby发行版本基本上都包括自己的解释器（这也是 它们的核心组件），但是Java是一种需要中间编译过程的语言，默认情况下它无法直接解释运行，也没有相应的解释器。

那么SecureJSH是如何实现的呢？读者首先会想到JSR-223，这个API可以自己扩展脚本语言支持，比如rhino是 Javascript解释引擎。但是使用它难以实现交互操作，因为它必须输入一个相对完整的脚本才可以运行，这样会丧失一部分交互性。SecureJSH 实际上是使用了JDK 6.0的新特性Java Compiler API（JSR-199），它提供了一组API来让程序可以动态地访问Java编译器的接口，这样就可以使用Java编译器动态检查代码语法或者动态根据 Java源码生成可以执行的字节码。这种方式与ASM的编程直接生成字节码不同，它能直接将Java源码转换为字节码，XRuby的主力开发者郑晔（网名 dreamhead）在他的Blog中这样对比了两种方案：

之前，刚刚在Blog中提到ASM， 里面的代码生成工作是通过直接写 字节码完成的。现在有了Compiler API，可以考虑生成代码以Java源码的形式完成，然后，通过调用Compiler API对源码进行动态编译，这样，可以达到同直接写字节码类似的作用。使用Compiler API，肯定不如直接生成字节码来得高效，但对于不了解JVM指令的人来说这也许是一种解决方案。

可见JSR-199不是最高效的字节码生成方案，但是更方便使用。Java Compiler API不是为了取代ASM这样的方案的，它的本意是以编程的方式实现实时编译及信息反馈。Java目前的主要架构师之一Peter von der Ahé曾经在他的Blog对谁需要使用Java Compiler API这个问题做了如下解释：

99%的Java开发者都不需要了解Java Compiler API。只有少数的开发者会直接应用这个API。但是IDE、Java EE应用程序服务器、Maven或者Ant还有测试框架的开发者却不一样，他们有一个共同点，就死需要调用编译器将Java源码转换为类文件（他们是这个 API的潜在用户）。

可见JSR-199的产生主要是面向热部署或者增量编译这样的场合，但是SecureJSH的产生扩展了Java Compiler API的应用场景，同时也增强了Java和JVM的交互性。Complystill这样介绍了SecureJSH的应用场景和需求：

SecureJSH允许Java编写的服务器端应用程序为管理员、客户、开发者和客户端服务提供一个安全shell，这里可以交互性地让Java语言逐句运行。SecureJSH需要JDK 6.0或者JRE 6.0加JAVAC（在classpath中）来运行。

• 安全：SecureJSH在服务器端实现了RFC-4251，SSH 2.0协议，支持公钥认证，这种方式方便安全（不需要每次输入密码）。
• 交互式执行：传 统的方式下，在运行Java源代码之前你必须将它们编译为字节码。但是使用SecureJSH，编译的过程是透明完成的，所以你只需要随意输入一些 Java表达式（就可以运行）。这意味着你可以使用你书写应用程序时完全相同的语法，与最新的Java语言规范同步。你可以在你的Java项目源码和 SecureJSH终端里面拷贝＆粘贴任何代码，都没有问题。
• 智能命令识别，UNIX Shell风格：不 像JSR-223（Java Scripting Engin，Java脚本引擎）对Java语言的脚本的支持，在（Java脚本引擎）里面你必须将Java类的全部代码输入后才可以执行， secureJSH更加智能和人性化，如果你输入了不完整的Java表达式，它会自动提示你进行多行的输入，然后将这些表达式包装到一个预先定义的类结构 中来执行。它是一个真正的Shell。
• 没有相互干扰，最小化资源消耗：SecureJSH没有需要储存在JVM范围的静态资源，每一个实例只消耗很少量的资源（基于NIO实现，所有的SSH通讯都由一个线程处理）。你可以按照你的想法在一个JVM里面运行任意多个shell服务，包括Java应用程序服务器的JVM。

作为一个开源项目，SecureJSH使用了ganymed的纯Java实现的SSH 2.0库，并使用Java NIO编写了网络服务，代码质量很高。据Comply Still介绍，SecureJSH最初是为内存数据库TOB设计的，为这个面向对象数据库提供交互访问的接口，但是后来作者发现它可以被应用在很多场 合，所以单独开源发布。作为Java开发者，您可以从这里下载源码从中学习SSH 2.0、NIO网络服务、Java Compiler API的使用方法，相信一定会有所收获。

从用户体验的角度来说，我们甚至还没有发挥出HTML的全部潜力。

本篇Blog引起了众多网友的评论，大部分人都认同DHH的观点。大部分开发者认为基于标准的Web开发还大有潜力可挖，通过加强设计者与开发者的联系，产品的用户体验可以得到很大的提升。目前大部分Web应用还不能令人满意，但是这个问题并不完全归咎于浏览器的非标准实现，更多的是因为设计和开发者本身对技术的掌握还不到位。DHH认为不能假设用新的（基于插件的）RIA技术开发出了非常令人惊奇的应用，就认为这些更“先进”和“富”的技术会取代我们正在使用的HTML、CSS和Javascript等。相反，DHH认为对这些技术的过度鼓吹都是废话。但回复的网友中也有一些人认为这是DHH对于RIA技术革命的不友好表现，例如Flexible Rails的作者Peter Armstrong就认为Flex结合Rails可以带来更好的用户体验。而后，DHH也很快出来澄清说他只是向那些无视HTML、CSS和Javascript的技术狂热者表示反对，而Rails是非常欢迎其它RIA技术作为补充的。

在国内技术社区，Ajax方面的专家（Ajaxcn网站站长）李锟针对DHH的这篇博客也发起了讨论。讨论中李锟认为基于标准的HTML、CSS和Javascript在RIA的未来发展中还将扮演主力的地位，引出许多针锋相对的观点讨论。最后大家基本上一致认为基于标准和模式进行基于HTML、CSS和Javascript的开发在目前还没有成为技术瓶颈，这些技术在未来还有很多潜力。李锟很好地总结了开发者目前面临的问题，现在看到了技术局限是因为对它的了解，而其它新兴RIA技术是否会成为主流还要等它们充分暴露问题以后再说。

Apple的iPhone也将Mobile Ajax作为他们首先支持的一种开发技术，这也不是偶然的。我觉得我们应该看到技术本身的局限，也应该看到技术未来发展的趋势。我们之所以对基于Web标准的技术局限看的这么清楚，也是因为对这些技术我们已经有了大量的实践。而其他的RIA技术目前尚未得到大量的实践，它们描绘的美好蓝图能否实现还未可知，它们存在哪些局限还没有充分暴露出来。

这里李锟引用发布于InfoQ中文站上的这条新闻，其实表明了基于标准的Ajax有可能被作为另外一种可行的技术手段，在以前被认为是插件型RIA天下的受限环境中被重新认可。这就是说现在的新兴RIA技术（如Apollo、Silverlight等）并不一定会以Ajax杀手的形式出现，而是作为Ajax的补充，所以RIA的未来似乎更加扑朔迷离。而作为Ajax开发者，这是一条好消息，证明现在正在使用的HTML、CSS和Javascript工具箱并没有过时，不需要在恐慌中去学习新的RIA技术，而应该坦然地喜爱你正在使用的技术，就像DHH和李锟这些Web开发者一样。

最后，关于最近在RIA界非常火的离线存储技术（如Google Gears、Dojo Offline等），DHH也写了一篇有趣的Blog，有兴趣的读者也可以一并阅读。

尝试测试分类（test categorization）

你需要的是一个让你的build转变到更敏捷状态的策略。你需要一种解决方案来允许你在一天内多次运行测试，让那些已经需要三个小时完成的测试回到原先的状态。
在你尝试使用这个策略让你的测试套件恢复原形之前，思考一下“单元测试”的基本概念可能会有所帮助。“我家有一只动物”和“我喜欢汽车”这样的陈述不是非常明确，所以，不幸的是，“我们编写单元测试”也不明确。现在，但愿测试泛指一切。
思考前面的两个关于动物和汽车的陈述：它们产生了很多疑问。例如，你家里有什么动物？是猫、蜥蜴还是熊？“我家有一只熊”与“我家有一只猫”完全不同。同样的，“我喜欢汽车”对于与汽车销售商交谈时没有帮助。你喜欢哪种车：运动车、卡车或者大货车？不同的答案会将你引入不同的路径。
同样，对于开发人员进行测试，根绝测试类型分类是有所帮助的。这样做更加精确，能够允许你的团队以不同的频度运行不同类型的测试。分类是避免恼人的运行所有“单元测试”的三小时build的关键方法。

形象的将你的测试套件整理为三层，每一层代表开发人员进行的不同类型的测试，它们是根据运行时间的长短划分的。如图1所示，每一层将花费更多的总build时间，无论是运行时间还是编写它们所需的时间。

图1 测试分类的三层

最下面一层测试运行时间最短，如你所想，他们也是最容易写的。他们也覆盖最少量的代码。顶层是有高层次的测试组成，它们检测应用程序的很大一部分。这些测试相对难写，同时也需要更多时间来执行。中间一层测试介于两个极端之间。
这三个分类如下：

• 单元测试
• 组件测试
• 系统测试

1、单元测试

单元测试隔离的确认一个或者多个对象。单元测试不处理数据库、文件系统或者任何可能带来测试不能保证长期可运行的因素；顺序上，测试可以从（项目）第一天就开始写。事实上，这就是JUnit的设计目标。单元测试的隔离概念是在很多mock对象库隔离特定对象的外在依赖的基础上的。进一步说，单元测试可以在实际代码编写前就开始写——也就是测试先行开发TDD的概念。
单元测试一般容易编写，因为他们不依靠于系统依赖，并且他们运行迅速。不好的方面是，单独的单元测试只能提供有限的代码覆盖度。单元测试的价值在于允许开发者在最低的依赖程度下保证对象的质量。
因为单元测试运行迅速容易编写，一个代码库应该有很多单元测试且尽量频繁的运行它们。你应该在每次build的时候运行它们，不管是在你的机器或者一个CI环境（以为这你应该在每次向SCM系统chech in之前运行它们）。

2、组件测试

组件测试保证多个对象的交互，但是它们突破了代码隔离的概念。因为组件测试处理多层架构，他们经常要处理数据库、文件系统、网络元素等。而且组件测试一般很难在（项目）前编写，所以将它们加入到一个实际的测试先行/测试驱动的场景中是个很大的挑战。
组件测试编写要花多一些时间，因为他们比单元测试要棘手。从另一个方面来看，他们能够提供比单元测试更高的代码覆盖率因为它们的宽工作范围。它们运行耗时更多，所以它们会极大地拖长你们的总测试耗时。
一个宿主框架可能减少测试庞大架构组建的挑战难度。DbUnit就是一个这种框架的完美例子。DbUnit是编写依赖于数据库的测试容易，它能够处理复杂的数据库状态准备工作。
当测试引起build时间延长，你基本上可以确定那就是大组的组件测试造成的。因为这些测试比单元测试运行时间更长，你可能发现你不能总是运行它们。因此，它让CI环境至少以小时为间隔执行它们。你一应该要求每个开发者在check in前在本机环境运行这些代码。

3、系统测试

系统测试从端到端保证软件应用。因此，他们提出了高度的架构复杂性：整个应用必须在进行系统测试时运行。如果是一个Web应用程序，你需要访问数据库，从Web服务器、（应用程序）容器、任何相关的配置都要配合系统测试的运行。系统测试总是在软件开发周期的最后阶段撰写的。
系统测试对于编写人员是个挑战，并且实际往往花费比较长的时间。另一方面，他们提供更好的催款理由，也就是说，他们提供了系统架构级的代码覆盖率。
系统测试与功能测试非常相近。区别在于它们不是一个假扮用户，用户是虚拟的。就像组件测试一样，很多框架都是来帮助这类测试的。例如，jWebUnit通过模拟一个浏览器提供了测试Web应用程序的基础设施。

什么是接受测试？
接受测试与功能测试类似，不同点在于，理想情况下，客户或者最终用户来编写接受测试。与功能测试类似，接受测试按照最终用户的行为测试。一个备受关注的接受测试框架是Selenium，它使用浏览器来测试Web应用程序。Selenium可以在build过程中自动运行，就像JUnit测试一样。但是Selenium是一个新的平台：他不一定使用JUnit，方式也不太一样。（Selenium RC就没有这个问题了）

我应该使用jWebUnit或者Selenium？
jWebUnit是一个JUnit扩展框架，设计用来进行系统测试；所以，它需要你自己写这些测试。Selenium是一个优秀的接受测试和功能测试工具，不同于jWebUnit，它允许非程序员编写测试。理想状态下，你的团队可以同时使用两种工具来确认应用程序的功能。

使用TestNG进行测试分类
使用TestNG实现测试分类非常容易。使用TestNG的group注释，逻辑上将测试分类就是进行合适的group注释，这非常简单。运行某一分类的测试只需要将group名称传给test runner就可以了，例如通过Ant。

实现测试分类

所以，你的单元测试套件实际上是单元测试、组件测试和系统测试的套件。甚至，在你检查所有的测试后发现build需要这么长时间是因为大部分测试都是组件测试。下一个问题是，如何通过JUnit实现测试分类？
你有很多选择，但是让我们先试验一下最简单的两个：

• 根据需要的分类创建不同的JUnit套件（suite）文件
• 对于不同类型的测试创建不同的目录

创建不同的套件

你可以使用JUnit的TestSuite类（它也是一种Test）定义一组同类测试的集合。你要创建一个TestSuite的实例并添加相关的测试类到test方法中。你可以在TestSuite实例中通过定义一个叫做suite()的public static方法告诉JUnit这个套件包括哪些测试。所有包括的测试将会一次全部执行。因此你可以通过创建TestSuite来实现测试分类，一个单元测试的TestSuite、一个组件测试的TestSuite，有一个系统测试的TestSuite。
例如清单1的类中的suite()方法创建了一个包含所有组建测试的TestSuite。注意这个类不是非常符合JUnit规范。他既没有继承TestCase，也没有任何测试的定义。但是JUnit会自动发现suite()方法并且运行它返回的所有测试类。

清单1 单元测试的TestSuite

package test.org.acme.widget;

import junit.framework.Test;
import junit.framework.TestSuite;
import test.org.acme.widget.*;

public class ComponentTestSuite {

 public static void main(String[] args) {
  junit.textui.TestRunner.run(ComponentTestSuite.suite());
 }

 public static Test suite(){
  TestSuite suite = new TestSuite();
  suite.addTestSuite(DefaultSpringWidgetDAOImplTest.class);
  suite.addTestSuite(WidgetDAOImplLoadTest.class);
  
  suite.addTestSuite(WidgetReportTest.class);
  return suite;
 }
}

清单2 运行组建测试的一个Ant任务

理想情况下，你还需要一个触发单元测试的任务和系统测试的任务。最后，还有希望运行所有测试的情况，你需要创建第四个任务来运行其它三个任务，就像清单3里面那样：

清单3 运行所有测试的任务

创建单独的TestSuite是一个迅速实现测试分类的解决方案。缺点是这个方法需要你创建新的测试，你必须编成式的将它们添加到合适的TestSuite里面，这可能有点痛苦。给每个测试类型创建单独的目录可能是一种更加有弹性的方法，它允许你添加新的测试分类但无需重新编译。

创建单独的目录

我发现最简单的通过JUnit实现测试分类的方法是逻辑上将不同类型的测试放到不同的目录中。使用这个方法，所有的单元测试都放在unit目录，所有的组建测试都放在component目录，等等。
例如，在test目录中保存着所有未分类的测试，你可以创建三个新的子目录，就像清单4中那样：

清单4 实现测试分类的目录结构

运行这些测试，你需要定义至少四个Ant任务：一个给单元测试，另外的给组建测试，还有系统测试。第四个任务是一个方便运行其它三个测试类型的任务（就像清单3种展示的那种方式）。
JUnit任务就像清单2中的形式。区别在哪里呢，只是在任务的batchtest这个地方。这次，fileset指向的是一个指定的目录，就像清单5种的样子，他指向了unit目录：

清单5 JUnit任务中的batchtest方面，用来运行所有单元测试

< batchtest  todir ="${testreportdir}" >
  < fileset  dir ="test/unit" >  
   < include  name ="**/**Test.java" />        
  </ fileset >
</ batchtest >

注意这个任务运行test/unit目录下的所有测试，当创建了新的单元测试（或者其它分类的其它测试），你只需要把它们放到这个目录里面就可以了！这比添加一行到TestSuite中并重新编译它要方便多了。

问题解决了！

回到最初的场景，我认为你和你的团队会决定使用单独的目录这种弹性的解决方案来解决你们的build时间过长的问题。这个任务最难的一个方面是检查和分清测试类型。你重构你的Ant build文件创建四个新的任务（三个单独的测试分类还有一个运行它们三个）。甚至，你修改CuiresControl只在check-in的时候运行单元测试，而组建测试按小时运行。更进一步的检查后，系统测试也可以几个小时运行一次，也许你会创建一个新的任务来同时运行组建测试和系统测试。

最后的结果是每天测试运行很多次，你的团队可以快速的发现集成错误——一般在几个小时内。

创建敏捷构建不是为了赶时髦，它实际上是保证代码质量的重要因素。测试运行的更加频繁，开发人员的测试的价值就能直接转化为钱。并且，希望你们的公司能够在2006取得广泛的成功！

资源
Learn

• " Automate acceptance tests with Selenium " (Christian Hellsten, developerWorks, December 2005): Architects, developers, and testers learn how to use the Selenium testing tools to automate acceptance tests.
• " Effective Unit Testing with DbUnit " (Andrew Glover, OnJava, January 2004): Introduces database-dependent testing with DbUnit.
• " An early look at JUnit 4 " (Elliotte Harold, developerWorks, September 2005): Obsessive code tester Elliotte Harold takes JUnit 4 out for a spin.
• " Repeatable system tests " (Andrew Glover, developerWorks, September 2006): Andrew Glover introduces Cargo, an open source framework that automates container management in a generic fashion.
• " Create test cases for Web applications " (Amit Tuli, developerWorks, May 2005): Software engineer Amit Tuli introduces jWebUnit.
• " In pursuit of code quality: JUnit 4 vs. TestNG " (Andrew Glover, developerWorks, April 2006): Has JUnit 4 rendered TestNG obsolete? Find out why not.
• In pursuit of code quality series (Andrew Glover, developerWorks): Learn more about code metrics, test frameworks, and writing quality-focused code.
• developerWorks : Hundreds of articles about every aspect of Java programming.

Get products and technologies

• Download JUnit : Find out what's new with JUnit 4.
• Download TestNG : Another powerful testing framework.

Discuss

• Participate in the discussion forum .
• Discussion forum: Improve your code quality : Andrew shares his expertise as a consultant focused on improving code quality.

public class SeleniumTestCase extends SeleneseTestCase4 {

    protected static final Log log = LogFactory.getLog(SeleniumTestCase.class);
    protected static Selenium selenium = null;

    /** *//**
     * 包含了登录的代码，保证在一个测试内部只执行一次开启浏览器并登录操作
     * @throws Exception
     */
    @BeforeClass
    public static void startSelenium() throws Exception {
        log.debug("Starting Selenium");
        selenium = SeleniumSession.getCurrentSession().getSelenium();
    }

    /** *//**
     * 在该类包含的所有测试结束之后关闭浏览器
     * @throws Exception
     */
    @AfterClass
    public static void stopSelenium() throws Exception {
        log.debug("Stoping Selenium");
        selenium.stop();
    }
}

public abstract class SomeTestCase extends TestCase {

  static {
    // perform the "global" set up logic
    //这里的代码会在类初始化时执行，所以相当于BeforeClass
    log.debug("Starting Selenium");
        selenium = SeleniumSession.getCurrentSession().getSelenium();

    // and now register the shutdown hook for tear down logic
    //将一个匿名方法写到这里，就相当于AfterClass
    Runtime.getRuntime().addShutdownHook(
       new Thread(){
           public void run() {
             log.debug("Stoping Selenium");
             selenium.stop();
           }
       }
     );
  }

}

这个好像是比较正统的方案，不好意思我并没有试验，但是看起来这的确可能是限定用JDK 1.4或JUnit 3.8.1的最佳解决方案。欢迎尝试。相关的连接参考这里：http://www.cs.wm.edu/~noonan/junit/doc/faq/faq.htm#organize_3 

1. 动机

springside项目的江南白衣、cac和徐昊、熊杰都多次推广非常Pragmatic的Selenium进行功能测试。而我们的项目中也开始引入Selenium测试，并结合持续集成搭建了一个测试环境，也尝试通过Selenium进行一些浏览器兼容性的测试。期间感觉到Selenium的强大，同时也发现这个项目还不是很成熟，还需要很多改进。但是，对于已经起步的程序员，我们觉得应该提供一个学习的场所，所以决定依靠javascud提供的服务，进行Selenium相关资源的中文化。
已经与Openqa的Wiki的负责人Patrick lightbody进行了沟通，他非常支持我们翻译Selenium文档，我们将一边翻译一边将翻译结果转移到OpenQA，这样就能够方便所有使用中文的Selenium用户了，希望大家共同努力！

2. 初步计划

我们准备从翻译 Selenium相关wiki 开始，翻译openqa下面的Selenium、Selenium RemoteControl、Selenium IDE下面的相关文章。顺序应该是偏重SeleniumRemoteControl和Selenium Core部分。
而openqa网站下面Selenium和RC的相关教程我们也会选择性的进行翻译。
Selenium On Rails如果哪位朋友感兴趣也可以负责（目前还是空的：）。
欢迎所有对Selenium感兴趣的（翻译的过程就是很好的学习）或者已经使用Selenium的同学积极参加，参加的方式可以是：直接参与翻译，编写原创学习文章并添加到相关资源列表，交流心得并将心得添加到相关资源列表，提供使用的视频片断，推荐好的Selenium文章进入翻译计划，提出你自己的意见。以上方式都非常欢迎，可以发信给我进行沟通（iamtin AT gmail.com）。
目前我们使用JavaScud的Wiki进行翻译工作，网址如下：
http://wiki.javascud.org/display/SEL/Home
需要帐号请自行注册，然后将注册后的帐号发给我带为申请或者直接向scud（飞云小侠）申请。

3. 工作线路图

按照官方网站的目录进行整理，首先翻译比较有意义/实用的部分。本页将作为文档的索引，同时也作为任务分配的页面。如果某一页的内容被翻译者认领，请将自己的名字和文档的翻译状态注在索引后面，方便统计。状态为（working, complete, reviewd），认领后为working状态，翻译好则complete，其它人看过并审过以后为reviewd。
我们首先翻译Selenium的几个About页面，然后开始翻译相应的Wiki部分，然后再补全Documentation、Reference部分，其余部分最后补齐。
现在wiki和about的原文文档已经粘贴过来了，请大家有工夫的时候开始翻译，这部分翻译完成后我们将把阶段成果链接到openqa的translation部分去。

• Selenium Core
  • 关于
  • News
  • Documentation
  • Usage
  • Reference
  • FAQ
  • Demos
  • Wiki
    • 我应该使用哪种Selenium工具？
    • Selenium Core FAQ
    • Getting Started with Selenium Core
    • Selenium Core Examples
    • Help With XPath
    • What People are Saying About Selenium
    • Publications and Presentations
    • Translated Documentnew!!
    • Selenium Core API Documentation Standard
    • Contributed User-Extensions
• Selenium IDE
  • 关于
  • News
  • Recording a test (video)
  • Documentation
  • Wiki
    • Recording a Test
    • FAQ
    • Contributed Extensions and Formats
    • Automating Selenium IDE tests
    • Writing extensions
    • Adding Custom Format
    • Building Selenium IDE
• Selenium RC
  • 关于
  • News
  • Documentation
  • Tutorial
  • Troubleshooting/FAQ
    • Java
    • .NET
    • Perl
    • Python
    • Ruby
    • Selenese
  • Server Command Line Options
  • Developer's Guide
  • Wiki
    • Possible Solution to HTTP AUTH Issues
    • Release Process
    • Selenium-RC and Continuous Integration
    • Specifications for Selenium Remote Control Client Driver Protocol
    • TODO for first Selenium Release
    • Windows Registry Support
• Selenium On Rails

4. 相关资源（部分）

徐昊(X)的：Selenium Better Pratice
江南白衣的：Selenium--透明反复推介的集成测试工具(Pragmatic系列)
cac翻译的：selenium参考手册
SpringSideTeam的Selenium指南
IBM的用 Selenium 自动化验收测试
Fit(table)+RC的方式使用Selenium
OpenQA的Selenium Remote Control Wiki
OpenQA的Selenium Core Wiki
OpenQA的Selenium IDE Wiki
OpenQA的Selenium Selenium on Rails Wiki
Nicholas的用Selenium进行功能测试
Tin的Selenium做功能测试的一点讨论