漫谈Web开发技术流派

本文从笔者多年在互联网公司从事Web开发的经验出发，谈谈对Java、.NET、LAMP这几种主流平台一些粗浅的认识和感受，希望能抛砖引玉，引发大家透过这些技术流派，进行一些对本质的独立思考。

 

大难不死的J2EE

之所以把Java排在前面，是因为以Sun强大的技术支持和广泛的开发者阵营作为后盾，J2EE已经毋庸置疑的成为目前互联网和企业应用开发中，最为广泛采用的平台。

Java语言天生就是为了互联网而存在，自诞生之日，可爱的杜克公爵就深得人心。说到Java的诞生，还有一些戏剧性。

Java的前身是Sun的一个开发小组为了开发一个能够在手机、交互电视等消费类电子产品的平台上运行的系统而研发的语言，小组希望产品能像橡树一样生根发芽、茁壮成长，所以取名Oak。我们今天所熟知Java的一些特性，比如面向对象、平台无关、垃圾回收、多线程、异常处理、安全性，早在Oak时代就已经具备。但在注册Oak商标的时候，发现已经被注册过，组员们喝着爪哇岛特产咖啡商量新名字，突然有人突发奇想，于是Oak成了大名鼎鼎的Java。

遗憾的是项目在市场上并不成功，Sun几乎已经决定取消这个小组的计划，Java面临夭折。就在此时，Web和浏览器诞生了，Java以它的平台无关特性，在互联网上展示出无可比拟的优势，重新焕发了生机。

初期Java的优势体现在客户端Applet展现的功能，在2000年以前，一些动态效果和网络应用，大都用Applet完成，以弥补HTML的先天不足，国内比较早的应用当属Chinaren在99年推出的图形聊天室和休闲游戏平台，在当时可谓独领风骚。

HotSpot出现后Java的性能得到大幅提升，Servlet和JSP相继出现，优秀的Container层出不穷，我们进入了J2EE的新时代。同时，随着服务端架构的发展、Web端Flash日渐强大、Ajax广泛应用，Applet由于自身的一些局限逐渐淡出，目前基本只能在一些实时要求较高的网络管理系统和企业应用上见到。

从最初Servlet/JSP标准，到 “Model 2”MVC三层架构，为了从页面分离代码、实现更清晰的层次，出现了很多技术框架，比如MVC框架JSF、Webwork、Struts等，组件管理框架Avalon、Turbine、Spring等，持久层Torque、IBATIS、Hibernate等。

逐渐SSH（Struts+Spring+Hibernate）成为了最广为接受的组合，利用Struts的MVC，Spring的IoC组件管理、AOP和事务，Hibernate的ORM和Cache，这样的优秀组合，满足了大多数项目的需求。

但是是否这一定就是最优方案？未必。Struts在应对流程变更时表现并不灵活，标签库不可能完全覆盖HTML的特性；Spring的配置繁琐，初始化耗时；Hibernate也不可能取代关系数据库，相反如果使用不当，有可能造成性能低下，比如1+N次查询问题。因此，只有在前期需求分析非常完备、性能压力不是很大的项目中，SSH组合才能发挥威力，清晰得划分层次，便于团队分工协作，完全实现模型驱动开发，提高效率和质量。

 

技术垄断的产物——ASP.NET

微软推出.NET平台是为了在Web Service时代占据先机，虽然Web Service存在多年没有真正有大作为，但C#和ASP.NET的确是发展壮大起来，微软提供强大开发工具和完善的类库支持，使ASP.NET开发非常系统、简单，比如用开发Web Service就像写普通程序，根本不用关心细节，ASP和Java的程序员转向.NET都会比较平滑。

针对Ajax盛行的现状，微软提供了Atlas框架用于实现Ajax应用。其最大特点是和.NET平台无缝整合，和微软的一贯做法一样，在Atlas的帮助下，开发Ajax应用变得非常简单。但是如果从一开始就依赖Atlas框架，结果可能是对页面DOM模型、Javascript和Ajax这些实际技术缺少深入了解，实际代码都是框架生成的。这就像写客户端过度依赖IDE，从而不了解界面布局、消息传递等机制一个道理。这是微软技术平台的特点，也是软肋，因为在对一个框架不能深入了解内核机制的情况下，我们是不敢投入太多信任的。

ASP.NET运行在Windows平台，虽然自身做了很多优化，但是仍然受到系统的制约。文件句柄数极限是一个门槛；系统本身不够透明，也导致在高负载下定位和解决问题的成本增加。这使得ASP.NET更适合开发企业ERP等中小型系统，如果向互联网用户提供公众服务，后期风险是比较高的。

 

草根技术的代表——LAMP组合

PHP生来就具有很强的草根性，语法简单、脚本式、部署简单，在PHP的开源发展过程中，并没有得到强有力的商业支持，但同样生机蓬勃，充满自由气息，也许正是由于这种特质，LAMP组合仍然被很多人认为是目前最适合进行Web2.0开发的技术。

PHP3之前由于脚本引擎性能局限，执行效率不高。PHP4编译代码为四元组，内部对四元组解释执行，类似Java虚拟机机制，效率得到很大提升。加上Apache和现在日趋完善的Lighttpd高性能Web Server支持、ZendOptimizer、eAccelerator这些优化解决方案，PHP自身性能基本没有问题。

PHP有很多模版引擎，比如PHPLIB Template、PEAR、Smarty等。Smarty的工作机制与JSP类似，把模板文件预编译成PHP脚本，第一次运行较慢，之后效率很高。

PHP的主要问题仍然在于面向对象特性不足，在大型项目中如果没有良好的面向对象分析和设计模式，有可能导致代码的膨胀和混乱化，后期的修改维护工作将比较繁琐。不过随着面向对象特性逐步增强，增加命名空间、异常处理等，加上Smarty等优秀引擎，相信PHP会越来越适于大中型项目开发，虽然与简单灵巧的特质有些背道而驰，但胜任商业应用毕竟是发展的趋势。

 

Web技术新秀——Ruby on Rails

Ruby语法简单，面向对象，功能强大。Rails出现后，Ruby on Rails立即成为Web开发阵营中的新秀，众多程序员追捧的热点。Rails提供一个典型的框架，用Action Pack实现MVC，视图层是模板，控制层是脚本，省去了Struts带来的XML配置工作，持久层是Active Record。Rails可以基于数据库结构迅速创建Web应用，适于快速开发。

但Rails还太年轻，目前还在发展中阶段，纯脚本解释执行带来的效率问题还没有足够优化，类库还不够完备。因此如果你打算用Rails给自己写个Blog或者典型的小型Web2.0应用很合适，比如37signals开发的Basecamp.com和Robot Co-op开发的43Things.com采用Rails，这些Web2.0小应用每天页面访问几十万，数据库记录数不到百万，负载是比较轻的。如果要实现逻辑复杂的应用或者高负载的公众服务，似乎还不是时候，RoR体系还需要时间继续进化。

 

当然，除了以上几种平台，还有用C、Perl、Python、Lua等语言开发CGI的选择，但由于本身不是专为Web设计，也没有足够的类库和开发者社群的支持，因此除非针对特殊需要，这些语言已经越来越少的用于Web开发。让C这种编译语言完成底层工作，脚本语言去完成粘合剂的工作，才是他们真正的使命。

 

技术流派简析对比

也许对其他类型应用并不是这样的优先级，但是对于提供互联网公众服务的产品，设计容量和性能是首要考虑的问题，其次考虑语言类库支持的完整性，最后才是选择具体实现的框架。

关于文中提到的各种平台和框架的性能对比，可以找到一些评测报告，但这些评测要么停留在比较低的层面，比如代码执行效率；要么不够客观，比如J2EE和.NET的PetStore评测，.NET采用更紧凑的结构和Cache，而J2EE完整展现了MVC、事务、远程调用等各种特性，并没有可比性。

所以对于评测结果，我们姑妄一听，在真实工作环境中，多数Web项目在页面和控制层并没有特别复杂的运算，性能压力来自进程调度、磁盘和网络IO、数据库各个方面。尤其对于大负载的Web项目，采用什么语言、什么框架、什么模型其实都不那么重要，良好的架构设计、各个层面上的优化，才是最重要的。数据库建模时正确的设计字段、关联、适当建立索引，根据数据量决定是否分布和散列机制，适当采用存储过程，优化数据库参数，利用Query Cache等，是在数据库层面的优化；合理使用内存或者Cache Server实现缓存降低数据库负载；在逻辑层采用正确的算法处理问题，降低CPU的消耗；服务器用动态负载均衡（LVS、BigIP）或者DNS轮询实现分布；利用Proxy Server实现静态页面缓存和高性能的IO。从前到后，性能优化是一个系统的、永无止境的问题，绝对不是语言和框架本身的差别。

考虑语言类库的完整性，Java、.NET、PHP都是已经十分完善的了，常用的字符串、IO、数据库、数学和安全相关、多媒体等功能，都可以很容易的实现。RoR由于流行时间的原因，资源还不够充足。

 

Web系统开发时的选型准则

在我们新项目开发的技术选型中，有几个前提是必须遵循的：

1、  采用团队成员熟悉和喜欢的技术。一般程序员可以懂几种语言，但是谈得上熟悉或者精通，每个人还是术业有专攻。如果团队成员都对Java非常熟悉也非常钟爱，要让他们学习PHP开发新系统，天知道会遇到什么问题。

2、  对架构深入了解。对任何架构，必须有足够深入的了解才可以信任，尤其是开源框架，必须做到成竹在胸，出现问题快速定位代码，必要时可以修改。在很多小型项目上，我们也会用自己开发的轻量级MVC框架。

3、  部署方案成熟。项目部署一直都不是一个很简单的事，从硬件到操作系统，到配合搭建的服务器、组件，都必须足够成熟，有成功案例支持才能采用。

针对互联网这个领域，大多数产品逻辑和流程并不复杂，每个产品的开发人员并不多，但是需要随运营反馈不断调整，需求变更比较频繁。因此，在我们中大型项目中用Struts的MVC，Spring的IoC和AOP, 持久层常用Torque、IBATIS这些轻量级ORM，容量和并发要求高的项目，采用Memcached，或者用ACE、ICE自己搭建特定中间层TCP Server，处理后台的逻辑和运算；小型项目如论坛等用LAMP和Cache Server，或者自己的简化MVC框架，就能达到比较理想的效果。

任何一种技术，只要能适应功能和性能的需求，为用户提供高质量的服务，就是先进的技术。技术选型要遵循“简单即是美”的原则，根据规模、特点和需求，选择合适的技术架构，过于执着追求复杂的框架、或者当下流行的技术，通常并不是明智的选择。