社区

Java

主题

网格计算,

集群与缓存

类似Google构架的开源项目Hadoop 已经存在一年多了，现在正受到来自开发社区的广泛关注。下面是来自Hadoop官网 的消息：

Hadoop是一个软件平台，可以让你很容易地开发和运行处理海量数据的应用……Hadoop是MapReduce 的实现，它使用了Hadoop分布式文件系统（HDFS）。MapReduce将应用切分为许多小任务块去执行。出于保证可靠性的考虑，HDFS会为数据块创建多个副本，并放置在群的计算节点中，MapReduce就在数据副本存放的地方进行处理……

Hadoop是由Java编写的，该项目已到得Yahoo的全面支持，项目的领袖Doug Cutting从2006年一月开始已经被Yahoo全职雇用于此项目中。华盛顿大学也从那时开始了一个以Hadoop为基础的分布式计算的课程，课程相关的材料也已发布 在Google Code了，以满足那些对这项技术感兴趣的开发者们。
最近，Yahoo的Jeremy Zawodny提供了 一个Hadoop的状态更新：

在过去的几年里，每家参与建立大规模Web系统的公司都面临着一些相同的基础性挑战……底层架构从来都是一个挑战。你不得不去购 买、并大量安装和管理众多的服务器，即使你使用的是其他人提供的商业硬件平台，你也不得不开发软件对这些任务进行分治处理，并让其保持运行……要建立一个 必要的软件基础结构，我们可以放弃开发自己的技术，这可以认为是一项竞争优势，先赚到钱再说。但我们已经选择了一条稍有不同的路，当认识到有越来越多的公 司和组织的需求都很相似的时候，我们发现了Doug Cutting（开源项目Nutch和Lucene的开创者）的工作，于是我们邀请他加入Yahoo，在新的开源项目Hadoop上继续工作。

Zawodny去年一直工作于提供数据排序的基准评测，在测试中，每一个节点都对相同总和的输入数量进行排序。 假如有20个节点，每个节点有100条记录，那么就有2000个记录需要排序；当有100个节点时，每个节点有100条记录，那就总共有10000条记 录。下面是最近的评测结果：

日期		节点数	耗时（小时）
四月	2006	188	47.9
五月	2006	500	42.0
十一月	2006	20	1.8
十一月	2006	100	3.3
十一月	2006	500	5.2
十一月	2006	900	7.8
七月	2007	20	1.2
七月	2007	100	1.3
七月	2007	500	2.0
七月	2007	900	2.5

Tim O'Reilly找出了 Zawodny所发的帖子，并从中发现了来自于Yahoo的高层支持：

……Yahoo! 已经在一月聘用了Hadoop的创始人Doug Cutting，但Doug在开源大会上的谈论 ，更像是Hadoop的发布会，Yahoo! 也想以此表明Hadoop项目对他们来讲有多么重要。实际上，我还接到David Filo打来的电话，他想确认我是否知道这种支持来自于高层……
…… 为什么Yahoo! 的参与这么重要？首先，这预示一个搜索界第二大的公司认识到开源是在Web 2.0上与一个占统治地位的对手进行竞争的强大武器……支持Hadoop和其它Apache项目不仅仅只是让Yahoo深入到他们可以使用的开源软件项目 中，更会帮助他们恢复在极客（geek）心中的形象……其次，或是同样重要的是，Yahoo! 给了Hadoop一个机会进行规模方面的测试……

John Munsh用一句话总结了 Yahoo的参与：“Hadoop和‘非我发明症（Not-Invented-Here Syndrome）’之反例”。（译者注：John Munsh在这里用“非我发明症”来指Microsoft那种不愿意接受任何协议，标准，或是其他公司开发的软件的态度。它认为不是自己创造的东西就是不 值得信任的。而Yahoo! 却基于竞争对手Google的MapReduce来构造自己的应用，所以这里说是“非我发明症”之反例。）

微软的Sriram Krishnan则从那些 转到类似Hadoop和Amazon EC2这种针对大规模应用并在不断发展的解决方案的创业者和开发人员所面对的问题的角度，对Hadoop提出了反对意见：

Web 2.0的主要价值来自于由众多用户生成的数据，如del.ico.us、Digg、Facebook……它已经超越了任何个人运行大规模的服务器软件的商 业意义，如Gmail、Google Search、Live、Y! Search……放荡不羁的极客们根本就不会去碰那些大规模blob存储（S3，Google文件系统），大规模结构化存储(Google的 Bigtable），还有在这种微架构之上运行代码的工具（MapReduct，Dryad）等等……我也不知道Doug Cutting的这种类似的开源产物在这条路上已经走了多远——也许这就是答案吧……

社区

Architecture

主题

RIA,

性能和扩展性

今天，当我们选择负载均衡时，大部分Web应用集群选择基于软件或硬件的服务器端方案，而《Digital Web Magazine》最近发表的一篇文章讨论了一家公司如何在EC2支持的应用中实现客户端负载均衡。

文章从负载均衡方案的需求谈起：

需要在应用服务器集群中分担负载；

温和地应对单个服务器的宕机；

确保在最终用户端可以把这组服务器视为一个单独的服务器。

作者朱磊（音译 Lei Zhu）分析了我们常用的服务端负载均衡手段——循环DNS（Round Robin DNS），文中提到：

很不幸，循环DNS的主要弱点是不能满足上面提到的第二个需求，当两台服务器中的一台宕机时，DNS服务器仍然会继续把请求发给它，这导致一半用户无法获得响应。

他还指出集群前端软、硬件专用方案的不足：负载均衡器（Load Balancer）自己总有一个响应数量上限，尽管可以通过循环DNS配合专用负载均衡器解决这一问题，但维护一个专用负载均衡器需要额外投入数万美元， 而且通常后备负载均衡器只有在主设备出现故障后才会发挥作用。

在客户端负载均衡概念的介绍中，作者请读者考虑关于桌面应用如何负载均衡的问题：

桌面程序随机选择一台服务器，然后尝试获取数据，如果服务器不可用或没有在预设的时间内响应，那么就选择另一台服务器，直到可以 提取数据。桌面应用与Web应用不同的是，前者是独立于服务器，可以在客户端通过对服务器访问的负载均衡实现应用的可扩展性，而后者把客户端代码 （JavaScript或Flash WSF）保存在提供数据和资源的服务器上。

为了把概念延伸到Web应用，作者剖析了典型AJAX应用的关键组成：

客户端代码：JavaScript/Flash客户端的SWF；

资源：图片、级联样式表、音频和视频文件、HTML文档；

服务端代码：用于反馈客户端所需数据的后台逻辑。

其中1、2两类内容相对静止，一般不像第3类那样有负载均衡的需要。关注于第3类组成，作者建议采用可靠的服务器或者像亚马逊S3那样的服务，它描绘的策略如下：

就像桌面应用一样，我们可以把一个应用服务器列表嵌到客户端代码里，Web客户端包括一个称为Servers.XML的文件，它保存了可用服务器的列表。客户端通过AJAX或者Flash访问列表中的每一个服务器，直到找到一台可响应的。

尽管浏览器可以禁止客户端代码向它所来源的那些服务器之外的服务器发起服务端调用，但作者还是建议采用Flash或JavaScript的方案解决这个问题。采用客户端负载均衡有两个好处：

不需要额外的服务器设备，“不需要专用负载均衡设备，无需配置负载均衡硬件或确认备份功能和主负载均衡器是否正常工作”；

服务器可以被物理隔离，“由于是客户端选择服务器而不是由一个固定的负载均衡器重定向调用，所以服务器的位置不受限制”。

文章结尾，作者介绍了上述技术如何在亚马逊的EC2和S3基础上构造一个叫VoxLite的具有高可用性和可扩展性的视频资讯应用，不过作者并没有架构出一个没有单点故障的负载均衡方案。

很多Web应用会面向特定区域，通过一个动态DNS支持的EC2实例实现调用的负载均衡。如果提供负载均衡的这个实例出现故障，在动态DNS映像到另一个EC2实例前，整个系统就不可用了。

为了克服这个问题，VoxLite通过向S3发起HTTP GET调用获得可用的服务器列表，该列表由EC2实例的一系列任务维护：

1. 加载并解析http://s3.amazonaws.com/voxlite/?prefix=servers。
2. 如果当前运行实例没有被列出来，就向一批EC2实例的关键服务器各发送一个空文件；
3. 通过测试到亚马逊内部Web服务IP地址的连接情况，可以验证该批其他服务器的是否运行正常，如果无法建立连接就把该服务器从这批服务器的列表中删掉。

根据你的需求，客户端负载均衡在统一负载均衡的架构下，提供了一个有趣且具创新性的选择。作者总结道：

通过在客户端负载均衡中采用S3和EC2，可以简化搭建一个具有弹性、扩展性、健壮性Web应用的工作。

查看英文原文：Client side load balancing of Ajax applications

社区

Architecture

主题

性能和扩展性

“可伸缩性（Scalability）”是软件厂商常常在新闻稿中用到的一个词（也是人们站在饮水机旁谈论的一个词），但这个词在很多情况下都被误解了。例如，很多人说起可伸缩性的时候其实指的是性能和高可用性。Royans K Tharakan试图回答“什么是可伸缩性”这个问题，他说：

可伸缩性，简单来说，是以更大的规模来做你现在所做的事。伸展一个Web应用的规模在于让更多的人使用你的程序。如果你没法找出 方法在伸展规模的同时提高性能，没关系。而且只要你可以伸展规模来处理更大数量的用户，那么有几个单点故障（single point of failure）也没关系。

Royans解释说如今我们在面对规模伸展的时候有两个选择：

• 纵向的可伸缩性——在同一个逻辑单元内增加资源来提高处理能力。这样的例子包括在现有服务器上增加CPU，或者在现有的RAID/SAN存储中增加硬盘来提高存储量。
• 横向的可伸缩性——增加更多逻辑单元的资源，并令它们像是一个单元一样工作。大多数集群方案、分布式文件系统、负载平衡都是在帮助你提高横向的可伸缩性。

架构师们都在为达到线性的可伸缩性而挣扎，目的是让系统产出的增长与系统中投入资源的增长保持稳定的比率。然而，增加资源会导致一般耗费 （overhead）的额外增长，因此难以达到线性的可伸缩性。Royans将之称为“伸缩性因子”，并用它来区分各种类型的伸缩能力：

• 如果在你扩大规模的时候伸缩性因子保持为常数，这种叫做线性伸缩性。
• 但很可能有些组件并不像其他组件那么适应规模的增长。小于1.0的伸缩性因子叫做次线性伸缩性。
• 话说回来，也可能因为增加更多组件而获得更佳的性能（在RAID系统中跨多个磁盘的I/O，当磁盘越多，性能越好）。这种叫做超线性伸缩性 。
• 如果应用程序没有专门为可伸缩性而设计，有可能当规模扩大的时候情况会变糟。这种称为负伸缩性。

跟软件开发中的许多事物一样，这里也没有适合一切情形的银弹可以解决你的伸缩性问题。Royans建议说，“如果你急切需要可伸缩性，向纵向发展可能是最容易的”，但注意“不幸的是纵向伸展会随着你的规模增长而越来越昂贵”，而且“无穷的横向线性伸缩性只是难以达到，而无穷的纵向伸缩性绝不可能”。他继续说：

从另一方面来说，横向可伸缩性并不要求你购买越来越昂贵的服务器。它的本意是用普通的存储和服务器方案来实现规模伸展。不过横向可伸缩性也不便宜。应用必须从建造的最底层就加以考虑才能在多台服务器上运行得像一台服务器一样。

Royans最后建议应该考虑所有的层次才能解决可伸缩性问题：

对于一个成功的Web应用，所有的层次都要同样能够应付规模的增长。包括存储层（集群文件系统、S3等）、数据库层（分区、联 合）、应用层（memcached、scaleout、terracota、tomcat clustering等等）、Web层、负载平衡、防火墙等等。比如，如果你没办法实现多个负载平衡控制器来处理未来的网络流量，不管你在Web层的横向 伸缩性上扔下多少钱，都不会有什么效果。你的流量始终被限制在一个负载平衡控制器能够承受的程度。

查看英文原文：Think you know what scalability is?

12月 22nd, 2006 by 奇遇

1.       基本组成：

a)         运行入口CodeEngineRunner的main（）；里面注册所有的Generator；主要有：IbatisGenerator，ControllerGenerator，JSPGenerator三个；任意一个可以单独运行多次；

b)        代码结构：*Generator,用于生成domain，manager和sqlmap，controller等文件，在生成之后为了保持系统的完整性，通常会调用一些Modifier去修改配置文件；由于每个Generator会单独再次访问配置文件，所以可以单独和重复生成；

c)        主要的配置文件有2个，位于code_engine目录下，分别为：code-engine-config.xml，code-engine-gears.xml，但在实际使用中，我们经常要配置的是code-engine-gears.xml，前者一般在项目开始的时候设定，后者用来生成和修改domain，manager和sqlmap, controller，jsp和相关的一些配置文件；

d)        模板文件位于template文件夹下面；可以任意添加和调用；语法为freemarker，但是，通常只需参照其他模板文件，一般都可以写出新模板；

e)         每次运行codeengine都会在backup目录下面生成备份文件，以备再次生成和修改；

f)         生成日志在logs目录下；

g)        Framework目录是框架目录，可重用部分，在生成新项目时候拷贝用；

h)        Reference目录是一些开发组件，主要是写js组件；

2. code-engine-config.xml 配置简介：

       <?xml version="1.0" encoding="UTF-8"?>

<codeEngineConfiguration>

    <context>

        <distDir path="D:"wiczone"trunk"wiczone" java="src" web="war"/>

        <!--<distDir path="D:"test"trunk"project" java="src" web="war"/>-->

        <!--<distDir path="build" java="src" web="war"/>-->

        <templateDir path="template"/>

        <i18nSupport>true</i18nSupport>

        <database classPath="lib"mysql-connector-java-3.1.7-bin.jar">

            <driverClass>org.gjt.mm.mysql.Driver</driverClass>

            <url>jdbc:mysql://localhost:3306/wiczone</url>

            <username>root</username>

            <password>root</password>

        </database>

        <package base="biz.wic" app="application">

        <!--<package base="biz.web" app="framework">-->

            <domain>domain</domain>

            <controller>web</controller>

            <manager>manager</manager>

            <service>service</service>

        </package>

        <web layoutComponent="tiles">

            <manager>WEB-INF"applicationContext-manager.xml</manager>

            <lucene>WEB-INF"applicationContext-lucene.xml</lucene>

            <servlet>WEB-INF"action-servlet.xml</servlet>

            <security>WEB-INF"applicationContext-acegi.xml</security>

            <sqlMapConfig>WEB-INF"sql-map-config.xml</sqlMapConfig>

            <messages>WEB-INF"classes"messages.properties</messages>

            <tiles>WEB-INF"defs</tiles>

            <jdbc>WEB-INF"jdbc.properties</jdbc>

        </web>

    </context>

    <!--

    IMPORTANT NOTES:

    1.in most cases, we no necessary to modify the <context/> part, since we have already set done;

    2.each of controller/jsp can be re-created alternatively.

    3.please becareful that metadata's character case.

    4.the basis rule is:

        if not existed we will created;

        if already existed we may overwrited;

    -->

</codeEngineConfiguration>

1） 如上所示，< database > 用于配置数据库的连接，注意要保证driver能访问到；

2） <Package>负责生成各种代码使用，

3） <web>用于指定一些配置文件；

4） 以上文件通常在项目开始的时候设定；

<context>详解

a）<distDir path="build" java="src" web="war"/>

        <!--<distDir path="D:"dist_project" java="src" web="war"/>-->

        <templateDir path="template"/>

        <i18nSupport>true</i18nSupport>

distDir@path指目标项目的路径，‘build’是相对路径； @java指java source code的根目录；

@web指web application的根目录；

templateDir@path指freemarker template所在的目录，这里设定的是$Code_Engin$"template; 此目录下放置用于生成controller和jsp的模板文件（以ftl为文件后缀）；

template /lib/下面放置的一个common.ftl为通用的functions，已经用auto imports引入，要调用common.ftl的function，通常类似：<@ce.dosth param=paramObj />, ce是namespace，用于限定引用；具体代码见（BaseGenerator.java）

5） i18nSupport是指定jsp是否支持多语言；一般设定为支持的；

<package base="biz.wic" app="application">

            <domain>domain</domain>

            <controller>web</controller>

            <manager>manager</manager>

            <service>service</service>

        </package>

用于设定java code的package；

       <web layoutComponent="tiles">

            <manager>WEB-INF"applicationContext-manager.xml</manager>

            <servlet>WEB-INF"jbcc-servlet.xml</servlet>

            <security>WEB-INF"applicationContext-acegi.xml</security>

            <sqlMapConfig>WEB-INF"sql-map-config.xml</sqlMapConfig>

            <messages>WEB-INF"classes"messages.properties</messages>

            <tiles>WEB-INF"defs</tiles>

6）         </web>

3.code-engine-gears.xml配置详解：

<?xml version="1.0" encoding="UTF-8"?>

<gears>

    <!--

    Generate model, related sqlmap manager file via abator, in most case we don't need modify the abator-config.xml;

    just add the following model node will work;

    and this model node can create more than one; model name should be unique;

    default extends is : biz.web.framework.domain.BaseEntity

    -->

    <model name="city_model" table="city" domain="City" usingLucene="false"

           extends="biz.web.framework.domain.BaseEntity" keyProperty="id"/>

    <!--

    Create *Controller and *MgrController, modify layout component like Tiles of Sitemesh;

    modify action-servlet.xml, applicationContext-*.xml

    defaultMethods@keyProperty default to "id"

    -->

    <controller name="City" springBeanDef="true" template="controller.ftl">

        <managers>CityMgr</managers>

        <!--<services support="MailService"></services>-->

        <defaultMethods refModel="city_model">

            <method name="index" style="form" view="list_city"/>

            <method name="listAll" style="ajax" />

            <method name="list" style="ajax" />

            <method name="get" style="ajax"/>

        </defaultMethods>

    </controller>

    <!-- using the option [extends] to generated Mgr controller,

        overwrite default to true;

        method view default to

        -->

    <controller name="CityMgr" springBeanDef="true" template="controller_mgr.ftl"

                extends="City" overwrite="true">

        <!--<services support="CompassService"></services>-->

        <defaultMethods refModel="city_model">

            <method name="manager" style="form" view="list_mgr_city"/>

            <method name="update" style="form" view="edit_city"/>

            <method name="create" style="form" view="edit_city"/>

            <method name="save" style="form" view="edit_city"/>

            <method name="edit" style="form" view="edit_city"/>

            <method name="delete" style="ajax"/>

        </defaultMethods>

    </controller>

    <!-- overwrite default to true;

        jsp name attribute used for jsp file name, and also used for tiles definition

    -->

    <jsp name="list_mgr_city" refController="CityMgr" template="list_mgr_jsp.ftl" overwrite="false">

        <tiles>main_layout_4</tiles>

    </jsp>

    <jsp name="edit_city" refController="CityMgr" template="edit_jsp.ftl" overwrite="false">

        <!--<tinyMCE>content</tinyMCE>-->

        <!--<tiles>main_layout_4</tiles>-->

    </jsp>

    <!--<jsp name="detail_recommend" refController="City" template="detail_jsp.ftl" overwrite="false">-->

        <!--<tinyMCE>content</tinyMCE>-->

        <!--<tiles>main_layout_1</tiles>-->

    <!--</jsp>-->

    <!--overwrite default to true;-->

    <!--<jsp name="list_city" refController="City" template="list_jsp.ftl" overwrite="false">-->

        <!--<tiles>main_layout_2</tiles>-->

    <!--</jsp>-->

</gears>

1）<model> <controller><jsp> 等节点用于生成domain，manager，controller和jsp，可配置0-n个；次序随意; 且每个节点都有可选属性 overwrite （true、false）；

overwrite指定当目标controller文件存在时，是否要覆写该文件，否则就生成.generated为后缀的文件；overwrite属性是可选的，默认为true；

2）<controller name="CityMgr" springBeanDef="true" template="controller_mgr.ftl"

                extends="City" overwrite="true">

<managers>CityMgr</managers>

        <!--<services support="CompassService"></services>-->

        <defaultMethods refModel="city_model">

            <method name="manager" style="form" view="list_mgr_city"/>

            <method name="update" style="form" view="edit_city"/>

            <method name="create" style="form" view="edit_city"/>

            <method name="save" style="form" view="edit_city"/>

            <method name="edit" style="form" view="edit_city"/>

            <method name="delete" style="ajax"/>

        </defaultMethods>

    </controller>

这个配置看上去有些复杂，是为了提供更好的灵活性；name用于在code engine中标识controller，同时用于生成的controller.java的命名；在配置文件中应该是唯一的；

springBeanDef用于指出是否在相关的配置文件中添加spring bean的定义，比如xxx-servlet.xml等；否则只是生成controller的java；

template指定freemarker模板；

managers指定要注入manager定义；如果有多个用逗号分割；可选；

services指定要注入service定义；如果有多个用逗号分割；@support用于指定framework下的common service，比如mail，compass等；可选；

defaultMethods里面用于指定生成的controller里面的方法；refModel 指参照的model定义， method@name用于指定方法名，比如list，而且list方法是预定义写在模板里面的; method@style指定代码风格，可选有form，ajax两种；这个风格会同时影响cotroller部分和jsp部分；

method@view指方法返回的tiles定义视图，当然这个属性在style是form的时候有效；可选；

e） <jsp name="edit_user" refController="UserMgr" template="edit_jsp.ftl" >

        <tinyMCE>Description</tinyMCE>

        <tiles>main_layout_1</tiles>

    </jsp>

Jsp的name用于生成的jsp页面的文件名，同时还是tiles的定义，在生成controller时候也是有用的；

refController就是指明jsp所参照的controller定义；通过这个refController，jsp可以找到default_methods的style，refModel等信息；

Template指明所使用的freemarker模板；

这里省略了overwrite属性，overwrite属性是可选的，默认为true；

tinyMCE指定要加入tinyMCE支持，同时，所管理的属性为‘Description’； 可选属性；

tiles属性定义了，此jsp所extend的layout，可选属性；

f)

<model name="city_model" table="city" domain="City" usingLucene="false"

           extends="biz.web.framework.domain.BaseEntity" keyProperty="id"/>

用于生成domain，manager，和sqlmap，可以配置多个；

luceneSupport可选，如为true代表将在domain和manager以及配置文件中加入lucene的支持；

4.创建新项目

A.从codeEngineRunner开始执行createNewProject（“distProject”）；（将copy必需的框架文件到目标目录，同时修改jdbc.properties等文件，同时将初始化abator-config.xml；）

B．分别用到了JDBCPropertiesModifier和CodeEngineInitModifier；

C．执行目标工程project目录下的initdb.bat;初始化数据库，加载初始系统表和数据；当然执行此步骤之前要先创建数据库；

D．利用codeEngineRunner的从数据库表，生成相应的文件后，使用project目录下build.bat编译文件；

开发出高性能的网站，第三部分：压缩和其他服务器端的技术 - 2005-05-01

阅读本文英文原文（翻译：刘松涛）
经Port80软件授权发表

在第一部分 , 我们讲了代码优化的20个技巧，这些代码优化都是针对开发者源代码的；在第二部分 , 我们谈了缓冲控制。我们在此第三部分中，将来和大家一起看看其他的服务器端的技术，来提升网站的速度，我们先来看看HTTP压缩。

什么是HTTP压缩？

HTTP 压缩（或叫HTTP内容编码）作为一种网站和网页相关的标准，存在已久了，只是最近几年才引起大家的注意。HTTP压缩的基本概念就是采用标准的gzip 压缩或者deflate编码方法，来处理HTTP响应，在网页内容发送到网络上之前对源数据进行压缩。有趣的是，在版本4的IE和NetScape中就早 已支持这个技术，但是很少有网站真正使用它。Port80软件公司做的一项调查显示，财富1000强中少于5%的企业网站在服务器端采用了HTTP压缩技 术。不过，在具有领导地位的网站，如Google、Amazon、和Yahoo!等，HTTP内容编码技术却是普遍被使用的。考虑到这种技术会给大型的网 站们带来带宽上的极大节省，用于突破传统的系统管理员都会积极探索并家以使用HTTP压缩技术。

我们可以在浏览器发出的Accept请求的头部看到HTTP内容编码的键值。我们来看看Mozilla Firefox浏览器的这个请求，如下，我们特别注意一下Accept，Accept-Language，Accept-Encoding，和 Accept-Charset的头（header）:

这些个"Accept"值 会被服务器用到，进而决定将适当的内容通过内容协商（Content Negotiation）发回来—这是非常有用的功能，它可以让网站服务器返回不同的语言、字符集、甚至还可以根据使用者的习惯返回不同的技术。关于内容 协商的讨论很多，我们这就不再多讲。我们主要来看看和服务器端压缩有关的一些东西。Accept-Encoding表明了浏览器可接受的除了纯文本之外的内容编码的类型，比如gzip压缩还是deflate压缩内容。

我们下面来看看IE发出的请求headers，我们可以看到类似的Accept-Encoding值：

假设当今主流的每种浏览器都支持gzip和deflate编码(那些不支持的也不会发出Accept-Encoding)，我们可以简单的修改一下网站服务器，从而返回压缩内容到这些浏览器上，并返回标准（也就是没有压缩的）内容到其他的浏览器上。在下例中，如果我们的浏览器告诉Google它不接受内容编码，我们会取回3,358字节的数据；如果我们发出Accept-Encoding，再加上应答header告诉我们Content-Encoding: gzip，我们则会取回仅仅1,213字节 。用浏览器的查看源代码功能来看源代码，我们看不出什么差异，但如果使用网络跟踪的话，我们就会发现其响应是不同的。

图一: Google压缩 / 非压缩对比

上例中，虽然文件不大，但是效果依然很明显—压缩后比原来小了74%。再加上我们前面两部分谈到的HTML、CSS、和JavaScript代码优化，Google在提升网站性能上的成果非常惊人—它的一个网页居然可以放在一个TCP响应包里。

虽 然Google在带宽上的考虑也远远超出其他一般的网站，HTTP内容编码进一步让HTML、CSS、和JavaScript等瘦身50%甚至更多。不好 的地方是，HTTP内容编码（词语‘压缩’和‘内容编码’在本文中基本上是一个意思） 基本上针对文本内容很有效，对于图像和其他二进制文件的压缩效果就一般了，有时可能根本没有效果，但总的来说，即使有很多二进制文件的时候，整体上可以瘦 身15%到30%那么多。

HTTP内容编码的服务器端支持

如果你现在认同HTTP压缩的 价值，下一个大问题是：你如何来实施？在Apache网站服务器上，可以使用mod_deflate来进行HTTP内容的编码。在微软的IIS上，就有些 麻烦了。虽然IIS 5可以支持gzip的编码压缩，但实施起来还是超级麻烦，尤其考虑到因为各种浏览器中细微差异来进行各种细致参数调整的时候。所以在IIS 5上，还是要考虑第三方的采用ISAPI过滤器的压缩插件，比如httpZip 就是最好的一种。IIS 6上集成了压缩功能，也更快更灵活，但是还是配置起来比较复杂。ZipEnable 带给我们第一个专为IIS 6集成压缩细致管理的工具—并且还有浏览器兼容情况监测功能。

服务器内容编码的实质

当 实施HTTP压缩时，要平衡考虑一些因素；如果将服务器配置成‘输出’的内容压缩方式，虽然可以降低带宽的使用，但同时却增加了CPU的开销。多数情况 下，这不是什么大问题，尤其当网站服务器所作工作很少的时候。不过，在网络浏览很繁重的网站服务器上，运行相当多的动态内容就可能会达到CPU工作的极 限，这时再进而进行压缩的话，CPU可能会超负荷运行了。通过添加而外的服务器硬件资源，当然可能会减轻这种问题，并让我们享受通过压缩而节省下来的带 宽， 但最后带宽和CPU的问题还是要看哪个成本更高。

说到底，系统管理员和网站开发者是否对HTTP的压缩有兴趣，还是要看最 后的效果如何。当我们明显的发现带宽的负载下来了，那么访问者也可能会明显感觉转载网页的速度慢了。因为，压缩产生和解压缩会带来的CPU负载， TTFB (time to first byte)也通常会增加，这样浏览器渲染网页的速度也会降下来，但这还算是很好的平衡，因为数据压缩后传输的包变小了、变少了，提交的速度会变快，这个快 速回补偿网页渲染的慢速。然而，对于宽带用户来说，这样的改善可能就不明显了。不过，这两种情况下，对于网站建设者来说，都可以节省一些网络上的投资。当 然，如果可感知的反应时间对某网站来说是主要目标，并且网站的访问者很多都还使用拨号上网，那么本文的第二部分钟所讲的缓冲控制就是比较好的性能提高策 略。

最后，HTTP内容编码的另一个潜在问题是和由脚本产生的网页带来的服务器负载有关的，比如PHP和ASP。在此种情况下， 主要的问题是，网页内容每次请求可能会被再压缩，这样就会给服务器增加更多的负载（相对压缩静态内容来说）。如果，网站中所有的网页都是在请求时生成的 话，那么使用HTTP内容编码就得格外小心了。还好，很多商业上使用的压缩插件，直到如何对内容进行缓冲，但业余（较便宜的）的压缩工具可能就没有这些特 性了。

动态网页：立即生成，还是稍后生成？

有趣的是，很多的开发者都是在网站被访问时开 始动态的生成很多甚至全部他们网站的网页。比如，http://www.domain.com/article.php?id=5就是一个通用的URL， 它暗示了某个网页是由数据库查询时或填充模版生成的。这种常用方法的问题是，在很多情况下，在请求时间生成一个网页是pointless的，因为很多时候 这个主要的静态的（所谓的静态的动态网页、或脚本网页），其内容很长时间也不变化，这显然对于提高网页装载速度没有什么帮助。实际上，在一个高负荷的网站 这种方式会严重的降低服务期的性能。

要避免不必要的动态网页的生成，有一个方法是，每次有变化时，则预先生成有内容的静态. html网页。如果这些生成的.html网页，还是经过了代码优化（在本文第一部分中过这些描述方法），则更好。这不仅会让服务器交付这些网页更快变得更 容易，而且这些技术还会使搜索引擎更友好。

不幸的是，在很多情况下，简单的生成动态的HTML网页并不太容易，也为很多网页只有 在网页被访问时才能够正确的生成动态内容。在这种情况下，你最好是对网页进行‘烘焙’生成快速执行的形式。在ASP .NET的情况下，这种形式则是二进制代码，在服务器端执行的特别快。不好的地方是，在用户访问之前，服务器需要先执行这些网页强制执行这些字节代码。还 好，在ASP .NET 2.0中，这些问题将得到改善。在PHP中，一些诸如Zend等的优化软件是不错的投资。

对于提交静态 和动态网页、或者HTML和图像的不同需要来说，考虑一下针对物理服务器或其他的硬件上的加速可能，也是比较明智的选择。为了网页加速而加强硬件方面的投 入的另一个方法是专业化—不同的部件进行不同的工作，这样产生出最大的效率。虽然，本文是从代码和网站服务器校对来说明如何提高网站的性能的，我们也不妨 讨论讨论其他相关的元素。

对网站服务器进行涡轮增压

加速网站要考虑的一个重点是服务器软 件和服务器硬件。先谈软件，网站系统管理员不太可能来回因为易用性问题、性能问题、安全问题等在Apache和IIS之间切换来切换去。简言之，网站服务 器和其底层的操作系统之间的关系错综复杂、互相影响，再进行系统或服务迁移则更是繁重且有风险的工作。所以，你如果真的考虑放弃一种网站服务器而使用另一 种的话，你必须严肃认真的好好考虑这个问题；而如果速度是考虑的第一要素的话，建议你考虑一下Zeus。

再谈硬件，如果要考虑升 级硬件，则先仔细分析一下服务器上的主要任务。在静态网站上，主要的工作是调整网络连接和把文件从磁盘拷贝到网络上。要加速这样类型的网站，你得把注意力 放在高速硬盘子系统和高速网络子系统上，另外还得有足够多的内存来处理并发请求。实际上，你可能得给服务器添加大量的内存，从而为经常使用的对象尽可能的 增加内存缓冲来减轻磁盘的存取。有趣的是，CPU的速度在这里却不是十分关键。虽然不能否认CPU对网站的整体性能有影响，但瓶颈主要发生在磁盘上。但 是，当网站处理动态网页和静态网页差不多一样多的时候，处理器就显得很关键了，但即便如此高速磁盘或双网卡还是更有效一些。另一种情况下，除了要处理动态 网页，还要处理其他占用CPU的操作（比如SSL和HTTP压缩等）的时候，CPU就显得十分关键了。换句话说，要加速网站服务时，服务器具体所作的工作 决定着什么类型的硬件资源更需要增强。

当你没有那么多增加服务器硬件或软件的预算时，还有一些物美价廉的解决方法。比如，你可以 对服务器的TCP/IP设置进行优化，这样依赖TCP/IP网络的HTTP便可以最优运行。TCP/IP的设置优化里，有一项是TCP的接受窗口，可以把 它调整成最适合应用或者最适合网络连接的，或者是针对确保TCP连接的一些参数（如ACK或TCP_NODELAY等）进行调整，根据具体情况设置成使用 或不使用。还有一些参数，比如TIME_WAIT时间等，也是可以进行调整的。但要记住，不管怎么调整这些网站服务或操作系统的参数，都必须进行真实的加 载试验以验证你的调整会不会反而减慢用户访问的服务或带来新的问题。此外，一定要弄懂这些参数之后，再进行调整。

通过分工进行加速

网站加速还可以考虑的一个出发点是，不同的网站内容可能会拥有不同的提交特性。考虑到不同的内容，其特性也不同，我们可以用多个服务器，每个服务器来执行不同的内容处理，这样可能比用服务器池（server farm）中的每一个服务来处理同样的任务要好得多。

我 们来看一个分工进行加速的简单例子。当你的商务网站给购物车或外部网使用SSL加密的时候，你会发现当有多个用户同时访问的时候，SSL加密带来 HTTPS段的明显负载会使你的服务器的性能会急剧下降。这种情况下，把流量分配给另一台服务器，其意义就十分明显了。比如，把你的主站点放在 www.domain.com上，把结账的处理部分放在shop.domain.com上。这个shop.domain.com就是一个专门处理SSL流 量的服务器，可能会用到SSL加速卡。采取分工的方式，可以让你专心处理结账的用户的SSL流量，而不至于像以往SSL的处理会导致服务器整体性能的下 降。对于图像和其他重量级的二进制的比如PDF文档或.exe文档，服务器处理其下载可能要花些力气，这些连接通常持续的时间比一般的连接都长，会消耗大 量宝贵的TCP/IP资源。进而，对于这些媒体资源(PDF、.exe、图像等)的处理，我们也并不需要把它们和文本资源（HTML、CSS和 JavaScript等）等同对待处理。在这种情况下，让处理文本资源的服务器有高性能的CPU，让处理媒体资源的服务器有大带宽，是有的放矢的解决之 道。

分工还可以进一步应用到网页的生成上。我们可以考虑把生成网页的工作单独放在一个服务器上，把处理静态内容的工作放在另一个 服务器上。现在已然有很多网站是采取这样的模式了，这其中很多网站会使用一个叫做Squid的反向代理（reverse proxy）。在设置过程中，代理服务器专门提供静态的内容，速度很快；而后台的服务器则可以专心处理在访问时才会产生的动态内容。缓冲控制策略和规则， 我们在第二部分中谈到过，在这时的设置过程中就显得十分重要了；我们得确保代理服务器的缓冲中储存的内容在共享缓冲中是安全的。

为了争夺市场而提速

我 们刚才谈的那些东西主要是一些低成本的加速技术，在我们本文即将结束的时候，我们来看看一些需要软硬件成本很高但收益可观的方法。目前市场上提供有一些需 要花些钱的独特加速设备，它们可以进行比如网络连接分流、压缩、缓冲、和其他等技术，从而达到加速的目的。 如果你不在乎投资高带宽的话，这些解决方案就十分有效，但是大多数的网站还是更喜欢我们先前介绍过的物美价廉的方法，比如代码优化、缓冲、和HTTP编码 等。

就算你有很多资金，可以投资一个服务器池（server farm）、并添加最高档的加速设备，也使用压缩和缓冲技术等，但你还是会最后达到一个极限。要想进一步再提速，还有最后一招：把内容放在离访问者最近的 地方，有可能的话，在那个地方再实施上述各类技术（如压缩、缓冲等）。你肯定注意过，有些网站提供镜像服务器等，这样世界各地的访问者就可以就近访问所需 内容。不过，还有比这个更有地理分布意义的方法，并且可以透明的让访问者使用。内容分发网络（Content Distribution Network – CDN），比如Akamai，就可以让我们把重型内容（如图象和其他二进制内容等）搬移到离访问者更近的地方，这样通过内容分发网站在世界各地的边缘缓 冲，访问者访问起来就会更快。这种方式带来了性能上极大提高，目前世界级的一些大网站都在使用。虽然这算不上是经济实用的方法，但作为这些方法的最后补 充，放在这里以飨读者。

Thomas A. Powell 是PINT公司的创始人，也是加州大学San Diego分校计算机科学系的讲师，以及一些网页开发书籍的作者，其所著书目包括《HTML & XHTML: The Complete Reference》和 《JavaScript: The Complete Reference》等。

Joe Lima 是Port80软件公司的首席构架师(architect)，同时教授UCSD 扩展的服务器技术。

Port80软件公司
Port80 Software, Inc. 是微软 Internet Information Services (IIS) 网络服务的领先的开发商. 公司同时提供w3compiler, 一套优化代码的桌面应用软件。Port80 Software 是微软认证合作商(MCP ISV)。它位于San Diego, CA. 更多信息请见公司网站 www.port80software.com.

1.       方案：

a)         Load balancer +reverse proxy server + server cluster；

图一是整体的结构图；思路很清楚；这种的结构的网站系统可以提高系统的响应能力；

       图一

b）细节问题：

       i）web server 是否可以是非同质的server，比如有的负责mail，有的负责web页面，

有的负责文件上传；

             ii)用户的session信息如何在不同的server之间同步；

              iii）如果使用数据库集群的话，则有的dbserver只负责读数据，有的则读写都做；

                     如何实现；Replaication 在mysql中的支持正在研究；

       c）加入reverse proxy server; 图二显示了如何在架构中加入reverse proxy server；

              这里选择的proxy server是squid （http://www.squid-cache.org），（至于为什么选它，

因为很多人都用它；本人奉行拿来主义）；squid用来cache静态的文件，js，image，

css等；squid可以和tomcat，apache等集成；

图二

d）谁来做load balancer呢，如果你使用linux操作系统的话，那么一定要试试Linux Virtual Server（www.linuxvirtualserver.org/ http://zh.linuxvirtualserver.org/ ）, 我国的章文嵩博士主持的开源项目，TelTel的首席科学家；

IBM 的介绍资料：

http://www-128.ibm.com/developerworks/cn/linux/cluster/lvs/part1/index.html

http://www-128.ibm.com/developerworks/cn/linux/cluster/lvs/part2/index.html

http://www-128.ibm.com/developerworks/cn/linux/cluster/lvs/part3/index.html

http://www-128.ibm.com/developerworks/cn/linux/cluster/lvs/part4/index.html

图三

1.       首先应该读取domain对象，从而获取field列表；

    /**

     * getDomainFields via jsp name, and should remove the super fields, like lastUpdatedBy, lastUpdatedDate

     * @param name of jsp

     * @return list of field

     */

    public static List<Field> getDomainFields(String name) {

        List<Field> ret = new ArrayList<Field>();

        try {

            Class clz = Class.forName(CodeEngineConfig.getDomainPackage() + "." +

                    CodeEngineConfig.getControllerDomain(CodeEngineConfig.getJspRef(name)));

            for (Field field : clz.getDeclaredFields()) {

                if(!"lastUpdateDate".equalsIgnoreCase(field.getName())

                        && !"lastUpdateBy".equalsIgnoreCase(field.getName())){

                ret.add(field);

//                System.out.println("field.getName() + field.getType() = " + (field.getName() + field.getType()));

                }

            }

        } catch (Exception e) {

            e.printStackTrace();

        }

        return ret;

    }

2.       将Field List传递给freemarker模板；之所以要传递field而不仅仅是name的原因是，因为希望在模板里根据field的type，从而生成不同的html，比如date可以生成使用js calendar的，boolean生成radio，或checkbox，其他的生成text；

a)         定义macro；

<#macro getHtml field>

 <#if field.type?ends_with('Boolean')>

<input type="radio" id="${field.name}" name="${field.name}" class="inp_txt_30" size="80" value="${'$'}{${domain?uncap_first + '.' + field.name}}">

 <#elseif field.type?ends_with('Date')>

<input type="text" id="${field.name}" name="${field.name}" readonly="readonly" class="inp_txt_30" size="17" value="<fmt:formatDate value="${'$'}{${domain?uncap_first + '.' + field.name}}" pattern="yyyy-MM-dd hh:mm"/>">

<button id="${field.name}Btn" class="button" >...</button>

<script type="text/javascript">

Calendar.setup(

{

inputField : "${field.name}",      // id of the input field

ifFormat    : "%Y-%m-%d %H:%M",       // the date format

showsTime: true,

button      : "${field.name}Btn"    // id of the button

}

);

</script>

 <#elseif field.type?ends_with('Text')>

<textarea id="${field.name}" name="${field.name}" rows="15" cols="80" style="width: 100%">${'$'}{${domain?uncap_first + '.' + field.name}}</textarea>

 <#else>

<input type="text" id="${field.name}" name="${field.name}" class="inp_txt_30" size="80" value="${'$'}{${domain?uncap_first + '.' + field.name}}">

 </#if>

</#macro>

       b）调用macro生成html；

            <#list fields! as field>

              <tr>

                  <td class="txt_tit_s" ><spring:message code="${lbl + '.' + domain?uncap_first + '.' + field.name}"/></td>

                  <td><@getHtml field=field/></td>

              </tr>

            </#list>

不光要考虑开发的简单，还要考虑日后的升级；

甚至足够充分的文档资料支持；还有现有团队的技术能力；以及项目时间等；

MVC：第一要素我个人觉得是要简单，因为在这个部分的中的代码量，通常相对后端是很多的；一个容易上手，并且大家都熟悉并且不讨厌；

           SpringMVC，我个人觉得是很完备的mvc，有着很強的灵活性，但正是这种灵活性，让很多人无所适从；

           Struts 1 标签很糟糕；form对象很别扭，繁琐的配置；

           Struts2 没有用过，如果他还有form我就不打算用；

学习springside（以前）使用Spring 的MultiActionController，减少了很多没有必要的配置；在一个controller里面可以写多个Action；MultiActionController还可以很灵活的从request中绑定Domain对象，非常的方便；

MultiActionController 加 Controller可以满足全部的需要；

JSP部分使用spring form tag；

Tiles 和 sitemesh； 考虑到使用Ajax，而sitemesh是利用filter来修饰；选择Tiles；

ORM用ibatis,当前最实用，简单的ORM；而且可以自动生成，又容易理解；何乐而不为；

FullTextSearch： compass + lucene；

Others：ActiveMQ + ApacheCXF

Form/Ajax Request > Controller > Manager/Service > GenericDao

其他辅助工具：

EMS for mysql；

SVN as version control；

DB/web server：mysql/resin