特性简介:

• 简洁,快速的验证语法
• 无需编写验证提示信息(当然也支持自定义提示信息)
• 错误消息在指定地方显示
• 支持组合验证
• Ajax支持
• 基于prototype.js
• 支持国际化
• 易于扩展
• 基于标准的Html属性(class)添加验证,易于其它标准的jsp taglib集成
• 特殊应用场景支持,如:密码确认,结束日期必须大于开始日期
• 完整详细的单元测试，保证框架质量

在线演示：　http://svn.javascud.org/svn/si/validation/trunk/doc/index.html

在线文档说明：　http://wiki.javascud.org/display/si/Javascript_RapidValidation

下载: http://code.google.com/p/rapid-validation/downloads/list

本人的另一作品rapid-framework既然发布，本验证表单也将集成在里面,敬请期待

并且欢迎大家加入圈子讨论

http://rapidframework.group.javaeye.com/

    对于规模稍大的网站来说，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。那么下面，我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。

    操作系统

    我们首先就从应用服务器的操作系统说起。一个应用服务器，从软件的角度来说他的最底层首先是操作系统。要先选择操作系统，然后才是操作系统基础上的应用软件。在淘宝网，我们的应用服务器上采用的是Linux操作系统。Linux操作系统从1991年第一次正式被公布到现在已¾¬走过了十七个年头，在PC Server上有广泛的应用。硬件上我们选择PC Server而不是小型机，那么Server的操作系统供我们选择的一般也就是Linux，FreeBSD, windows 2000 Server或者Windows Server 2003。如果不准备采用微软的一系列产品构建应用，并且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么还是应该在Linux和FreeBSD之间进行选择。可以说，现在Linux和FreeBSD这两个系统难分伯仲，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应该是各有所长。那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉，这个熟悉一方面是系统管理方面，另外一方面是对于内核的熟悉，对内核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。而应用全面的优化、提升性能也是从操作系统的优化开始的。

    应用服务器

    在确定了服务器的硬件、服务器的操作系统之后，下面我们来说说业务系统的构建。淘宝网有很多业务系统应用是基于JEE规范的系统。还有一些是C C++构建的应用或者是Java构建的Standalone的应用。那么我们要选择一款实现了JEE规范的应用服务器。我们的选择是JBoss Applcation Server。JBoss AS是RedHat的一个开源的支持JEE规范的应用服务器。在几年前，如果采用Java技术构建互联网应用或者企业级应用，在开源软件中的选择一般也就是Apache组织的Tomcat、JBoss的 JBoss AS和Resin。严格意义上讲，Tomcat和Resin并不能算是一个应用服务器，他们是实现了部分J2EE规范的一个容器。而商业软件的选择就是IBM的WebSphere和BEA的WebLogic。到了现在，除了JBoss AS外，Apache的Geronimo，Sun的Glassfish也都是很优秀的JEE应用服务器。也给现在的开发人员提供了更多的选择。具体对于目前JEE应用服务器的比较。这边就不在赘述。

    在应用服务器前端，我们采用了Web Server做了一次转发，我们选择的Web服务器是大名鼎鼎的Apache。几年前，Apache几乎是Linux系统上开源Web Server的唯一选择。那个时候虽然也有一些其他的开源的Web Server，但是从功能和稳定性上来说都无法和Apache相对。在今天来说，Lighty也会是一个非常好的选择。Lighty是一个非常轻量级、占用内存资源也比较少的Web Server。虽然功能上没有Apache强大，但是在不少场景下，性能是非常出色、强于Apache的。而微软的IIS，就只能工作在Windows的系统上了。并且使用IIS的话，基本上也就是选择了ISAPI、ASP或者ASP.NET进行Web应用的开发了。



   数据库

    说完了我们采用的操作系统、应用服务器、WebServer后，下面就来谈谈我们的数据库。在淘宝网的应用中，采用了两种关系型数据库管理系统。一个是Oracle公司的Oracle 10g，另外一个是Sun MySQL的MySQL。Oracle是一款优秀的、广泛采用的商业数据库管理软件。有很强大的功能和安全性，可以处理相对海量的数据。而MySQL是一款非常优秀的开源数据库管理软件，非常适合用多台PC Server组成多点的存储节点阵列(这里我所指的不是MySQL自身提供的集群功能)，每单位的数据存储成本也非常的低廉。用多台PC Server安装MySQL组成一个存储节点阵列，通过MySQL自身的Replication或者应用自身的处理，可以很好的保证容错(允许部分节点失效)，保证应用的健壮性和可靠性。可以这么说，在关系数据库管理系统的选择上，可以考虑应用本身的情况来决定。

    一个互联网应用，除了服务器的操作系统，Web Server软件，应用服务器软件，数据库软件外，我们还会涉及到一些其他的系统，比如一些中间件系统、文件存储系统、搜索、分布式框架、缓存系统等等。在淘宝网，这些系统都是自主开发的，没有采用目前商业的或者开源的产品。有些系统，会存在着一些开源的产品或者商业产品。但是，考虑到淘宝网自己的需求和大并发量的压力，这些系统都选择了自主开发。

    开发框架

    前面谈的都是系统级的产品，下面我们说说开发框架的使用。可能有朋友想问，作为一个如此大规模的网站，淘宝网的Web展现层采用的是什么框架，是怎么实现的呢？曾¾¬也有到淘宝的应聘者问过我这个问题，他问我说是不是用的struts。我告诉他说不是的。其实淘宝网的Web展现层的框架用的不是struts，不是webwork，不是spring mvc等等。淘宝网的Web展现层的框架用的是集团内部自主开发的一套Web框架。这个框架能够解决一些其他Web框架不能解决的、在淘宝的应用中又会出现并需要解决的问题。在淘宝的多个应用中，也采用了一些开源的框架，比如Spring、iBatis、jBPM、Hessian、Mina等等。这些开源软件的采用为我们构建应用系统提供了很大的帮助。

    采用开源软件构建系统，我想有两个很大的好处：

    一个是降低成本。假设你有1000台应用服务器，如果你每台服务器上采用的不是JBoss AS或者其他开源的软件，而是使用商业的Oracle BEA的Weblogic或者IBM的WebSphere，那么为这1000台机器的应用购买License的费用是非常高的。

    另外一个好处(我觉得最大的好处)是你可以看到软件的源码，你可以研究了解软件内部的工作过程、原理。这对于应用设计、开发、查错、优化都是非常有帮助的。

    淘宝网的开源观

    对于开源软件的应用，有些人可能担心质量的问题，有些人可能担心软件本身发展更新的问题，等等。对于质量的问题，我想现在很多的开源软件尤其是一些很著名的开源软件都有很完善的组织，有完善的开发、测试、发布流程。在一个新版本完成前，会有多次的测试版本发布，最后才是正式版。这和商业软件是一样的。并且因为代码公开，反而更加的容易发现错误，提高质量。至于第二个问题，我想跟第一个问题一样，关键是组织和规划而不在是否开源，并且在很多著名的开源软件背后，会有厂商在进行支持。软件本身的发展应该是不会成为问题的，不太会出现软件突然停止发展的情况。

    在今后的发展中，我们还是会一如既往的关注开源软件的发展，也还会根据需要采用不同的开源软件。在选择一个开源产品的时候，我会考虑以下几点：

    1. 这个软件目前的功能和它的RoadMap

    2. 软件本身的架构

    3. 该软件开发的活跃度

    4. 该开源软件是否是遵守该领域内的国际规范的

    5. 在同类产品中，要挑选有比较优势的。并且要考虑可能存在的移植代价。这个移植指的是采用了这款开源软件后现有系统的移植，或者是从这个开源软件到其他软件的移植。

    对于企业级系统、互联网应用来说，采用开源软件不仅可以降低成本，更重要的是能够真正了解软件的内部工作机制。还可以在现在的基础上进行增强和定制，也能够从开源软件中借鉴到很多好的设计和实现。希望国内能有更多的企业在使用开源软件的同时，也能开源自身的一些软件，或者能够成为一些开源软件的贡献者。而作为淘宝网，我们也会非常积极的参与到开源的活动中，也会努力为开源的发展做出我们应有的贡献。

虽然它看似不重要，但这些在一定程度上也对你的网站的访问量产生了影响。这里列出了一份31 个我最喜爱的免费在线测试工具，你可以通过这些工具来测试你的网站，并根据结果对你的网站进行修改。

网站代码验证

没人可以细致到保证自己的网站代码都是正确的，你可以通过以下测试来验证网站代码是否正确。

1 . WDG HTML Validator 一个很好的工具，能找出网站语法错误的地方，并标注出来，也可选择对网站上单独的每一页进行单页分析。（ 强烈推荐 ）

2 . W3C Markup Validation Service 对 HTML 和 XHTML 都能进行代码测试，自称是互联网络上第一个（也是使用者最多的）的 HTML 验证工具。

3 . W3C CSS Validation Service 用于验证 css 源代码，能够标注出不好的 css 代码设计。例如：“Same colors for color and background-color in two contexts”。

4 . RUWF XML Syntax Checker 用于查找 XML 文件的错误。

5 . W3C Feed Validation Service 用于查找 Atom 和 RSS feed 中的错误语法。（ 这个我经常用到 ）

6 . W3C Link Checker 用于搜寻查明你网站内的所有链接里是否有断链。（ 强烈推荐 ）

7 . Juicy Studio Link Analyser 测试网站内的链接的 URL 是否存在死链，与 W3C Link Checker 很类似。

网站的使用性

我们常常看到网站设计者把重点放在怎网站的吸引力上，而完全不考虑会不会影响来访者的使用，一个浏览难度很大的网页是注定要失败，要让你的来访者方便的得到他要的信息（从而成为重复访客），你的网站应当遵循 WCAG section 508 易用性规则。

8 . Watchfire WebXACT 所有严谨的设计师和开发者都必须使用的工具，它会生成一个非常详尽的报告书，包括：网站质量，易用性和隐私等。（ 强烈推荐 ）

9 . ATRC Web Accessibility Checker 测试网站的 WCAG 2.0 Level2 兼容性，它会生成一份报告，提出一系列建议，如：如何提升页头，链接，数据，图表和文字的访问速度。

10 . WAVE 3.0 Web Accessibility Tool 高度可定制的工具，它采用了图形化模型展示网站兼容性问题（ WCAG 1.0 and section 508 ）。（ 强烈推荐 ）

11 . TAW Web Accessibility Test 测试网页是否存在冲突（ WCAG 1.0 兼容性 ），通过图形模式生成一份依据 wcag 优先模式为基础的网站修改建议。

12 . HiSoftware CynthiaSays portal 采用了非常严格的规则来测试网页（ 根据 section 508 和 WCAG 1.0 规则 ），生成的报告也极为详细（ 详细到很难看懂 ）。

13 . HERA Accessibility testing with Style 使用一种极为复杂但容易理解方式指出网页的 wcag1.0 兼容性问题。

14 . Juicy Studio CSS Analyser 进行了色彩对比测试，以确保你的网站的色调会符合 WCAG 1.0 的要求。

15 . Juiciy Studio Readability Test 分析你网站上的文字是否有语法错误或拼写错误等问题，容易让人理解不（ 根据 the Flesch Reading Ease 和 Flesch-Kincaid grade level algorithms 规则 ）。（ 适合英文网站使用 ）

网站的速度

打开你的网站的速度快慢，是来访者会不会再次访问网站的关键因素，在一般情况下，一个网络不是很快的来访者是不愿意访问一个充满着图片、flash 动画、多媒体文件的网站。为了使你的网站覆盖人群的范围最大化，你必须优化你的网站，使它的打开速度尽可能的快。

16 . Web Page Analyzer from Website Optimization 一个很好的工具，它在分析完一个网页后，会为减少加载时间提出优化建议，着重优化物体的数目，图片和网站的总体大小。（ 强烈推荐 ）

17 . WebSitePulse Test Tools 有一系列的工具来确定网站的加载速度和主机信息。

18 . Internet Supervision Url Check 从世界各地不同的服务器来测试你的网站的加载时间，用于确定是不是各地的来访者都能顺利快速的打开你得网站。

浏览器模拟工具

这是一个普遍的问题，因为现在有着很多的操作系统和浏览器，你得网站必须得兼容它们，但这绝不是一件容易的事。通过下列工具，你可以了解你得网站在各种浏览器上的显示效果。

19 . Browsershots 能给出你的网站在不同浏览器下显示效果的截图，包括：Firefox 和 Internet Explorer （ Windows ）、Firefox 和 Safari （ Mac OS X ）、Iceweasal 和 Konqueror （ Linux ），但是结果要在 1 - 3 小时后才能出来。

20 . IE NetRenderer 实时生成你的网站在 Internet Explorer 5.5 、6.0 和 7.0 下的截图。

21 . MobiReady Report 分析使用手机访问网页的兼容性问题，会生成一份详细的报告，并提供了在两种不同类型的手机浏览器上你得网站可能显示的样子。

搜索引擎优化 (SEO)

一个网站，如果对搜索引擎有着比较好的友好度，一定会比较有竞争力。像一些小说网站.

22 . UrlTrends 会显示网站的访客是如何通过搜索引擎来到你的网站，还有各个流量是多少。这些数据是包括 Google, Yahoo, MSN, Alexa, AlltheWeb, AltaVista 和其他一些网站。（ 强烈推荐 ）

23 . iWEBTOOL Backlink Checker 一个很好的工具，它能找出有什么站点链接到你的站点，那些站点是什么类型的站点。

24 . iWEBTOOL Multi-Rank Checker 显示你网站的 Alexa 和 Google PageRank 数值。

25 . Microsoft adCenter Labs: Advertising and Keyword Research Tools 一个极好的工具，用于分析和预测你网站的来访者和市场。（ 强烈推荐 ）

26 . Domain Tools Whois lookup 一个 WHOIS 网络工具。

27 . SEO-Browser 可以让你看到在搜索引擎眼里一样的网站（ 去掉所有的”美丽”配件 ）。

28 . SEO Workers SEO Analysis Tool 非常有用的工具，分析了网站上的各种分类特征，包括 meta 标签、关键字密度及加载时间。（ 强烈推荐 ）

29 . Seekport Seekbot 可以分析网站的数据和内容，以得出搜索引擎会如何有效的解释分析的网站。

30 . SEO Chat SEO Tools 用以分析网站 Google adsense 盈利潜力，关键字密度，Meta tag 等等……

31 . Marketleap Search Engine Marketing Tools 用来分析网页，让你知道你的网站检索、设定的关键字好不好。

原文：avivadirectory.com

    myspace火了，中国冒出更多的myspace

    youtube刚刚起来，中国的视频网站就遍地开花

    51拔地而起，中国出了无数的SNS

    facebook则改变了中国站长的抄袭方式，不再学chianren了，校内火了
    ..........

    当抄袭变成习惯，我想说的是，模仿，站长，你准备好了吗？

    如果你打算做垃圾站，或者赚点广告费的网站，请不要点击这篇文章，我从技术角度方面谈谈WEB2.0网站的模仿问题。

    当投资和流量都不是问题的时候，我想说的是，您真的一帆风顺吗？

    拿SNS网站来说，当匆匆上线的2.0，当一笔笔投资砸进去的时候，当流量上去的时候，您的困惑在什么地方？

    我做过多个2.0公司的技术顾问，简单的谈谈2.0公司遇到的问题(涉及隐私，我用A B C D代替)，这里就不再赘述大家众所周知的页面静态化，缓存和代码安全等问题了，有点技术的2.0公司的CTO都知道这些东西，我们谈点发展之后的问题

A公司

    A公司做的是SNS网站，程序是两个毛头小伙子做的，目标直指51，程序开发是一帆风顺，功能也比51牛多了，推广也是一帆风顺（A公司有自己独到的推广方式。但是当ALEXA到2W的时候问题出来了，每天下午4点左右，网站速度慢的惊人，基本上打不开，公司三台服务器CPU100%，让人郁闷的是公司的网络配置方式，居然是双WEB的集群，而单独一台DB数据库。整个瓶颈在数据库，于是我建议做DB的集群，分析了一下数据结构，MD，典型的WEB程序员的作品，没有一点数据库设计规范，功能实现是可以，如果要扩展，不可能，集群基本上是不可能的，怎么办？不能办，于是，一个月的时间修改程序，数据结构基本上换了一遍 前期砸进去的几十万打了水飘，用户走光了。

    结论：WEB2.0前期设计的时候不应该只考虑功能，应该认真考虑一下底层和数据结构了。

B公司

    B公司也是做的SNS网站，程序是3个人开发的，CEO是某名牌大学的经济学硕士，有点知己网的味道，又有一些特色出来，说实话，公司的潜力不错，CEO有很强的运作能力，感觉前景不错。系统架构还行，但是---但是系统崩溃了，why?系统没有考虑到用户有个海量的说法，文件也有个海量的说法，用户的相册，图片全部存贮在WEB服务器的一个分区上，每个用户一个目录，而打开性能监视器，磁盘的IO高的惊人，基本上无暇响应。众所周知，文件系统也是一个数据库，单独大文件无所谓，关键是整个是300多个G的零碎文件，大量的读写操作，系统崩溃，数据丢失，文件系统的一个链断了，用户数据全部丢失！！！Raid并不能解决所有问题，磁盘阵列只能保证在硬盘损坏的时候进行恢复，但是这个是文件系统的损坏，raid不能恢复。这是一个非常沉重的问题，系统整整停了一个月来做数据恢复（单独文件很容易，但是海量文件目前还没有一个软件能组织起来软件架构，数据恢复软件一般在建立目录结构索引的时候就已经死掉了，尝试过用16G内存的服务器做恢复，无效）。解决方案：修改程序架构，做分布式文件存贮（程序修改用了8天，但是文件转移却又用去了将近一个月），20万用户损失殆尽 像这种 http://www.bt285.cn bt下载

    结论：WEB2.0前期的设计应该有应付海量存贮的考虑，整个涉及了程序架构的修改，前期规划不好的话基本上思路一条。

C公司

    结论：WEB2.0前期设计应该有良好的散列考虑，程序应该能有配合的扩充性，符合数据库的扩充

D公司

    D公司是一个各个方面做的比较好的公司，做了CDN加速，图片也独立分出了N个服务器，数据库不错的一个，(CTO是个数据库专家），系统崩溃的原因在于WEB，按道理说WEB很容易做集群的，但是发现集群并解决不掉问题，他们的集群只允许做4台的WEB集群，但是4台都当掉了。仔细分析，找到原因，我估计整个也是大部分CTO最容易犯的一个错误，或者说他们根本就想不到的问题，就是WEB上传的问题，上传的时候由于数据传输的原因，线程是保持链接的，300个线程就可以把一个WEB Server当掉了。解决方案：这个最简单，把上传和其他耗能大户分离出独立出来，同时做异步分布式上传。程序改动不是很大，但是之前半个月速度满对用户体验的损失也不可小视。像这种http://www.5a520.cn 小说520网

    结论：没有什么结论了，毕竟有海量访问经验的CTO不多，也就是那几个大站的。

    总结：不是泼冷水，模仿其实是很容易的，随便找几个WEB程序员就能做到，并且很简单，速度可能还很高效，因为WEB2.0无非就是跟数据库打交道，会操作数据库就会做。但是真正做大并不容易，因为能应付海量访问的程序并不简单，现在的程序员都太自命不凡，其实真正有经验的并不多，不要相信一个月薪5K--10K的程序员能给你多大的惊喜，能应付海量访问的程序员不是那个价格。如果您想做2.0，想做大，有几个个建议：

    一.找DBMS的专家设计好数据库，大部分程序员都不知道分区视图，数据散列，数据组的概念

    二.设计好程序架构（这个其实不难，有个高人指导就行了），保持良好的扩展性，成本考虑可以找兼职的系统架构设计师做好系统架构，确定将来的发展瓶颈。

    三.考虑好文件存贮的问题。文件存贮的技术含量看起来很低，其实是很高的，可以考虑反向代理的方案。文件存贮出问题了，站点基本上就完蛋了，不仅仅是RAID的问题和存贮服务器的问题，不过道理倒是一点就破的

    四.中国国情考虑，这个最致命，需要考虑电信和网通的问题，CDN并不能解决所有问题。互动性的东西并CDN并不是很有效。最关键的是，现有的双线机房遇到DDOS攻击基本上都会当掉，原因很简单，双线机房都是私人机房，本身就不会有太高的带宽，随便攻击一下就可以D掉（顺带提一个笑话，我知道一个双线机房的老总总共1G的带宽却买了4G的金盾墙，很简单800M的攻击就可以搞定）。

    五.网络延迟的问题，这是分布式系统必须要考虑的，程序要能容忍0到100秒的数据延迟的功能，也就是同步的问题。不要小看这几十秒，问题很大的，如果你的站点有交互式功能，比如即时聊天，你可以想象一下是个什么结果。对于即时聊天的东西，可以用反向代理来解决（成本较高）。但是对于留言和评论的影响不大，但是如果系统为了健壮做了缓存和静态化的时候，这个东西可能就是灾难性的了。静态文件的更新和重写需要异步的方式来做。

    六.分散你的程序，如果你没有太多的资金构筑动辄百万的服务器，建议把功能分散开来，比如相册一台服务器，留言一台服务器

    七.看好你的程序员，如果没有很好的激励措施的话你的程序员很容易写出敷衍性的代码，而这个可能就是将来的大患，程序架构定下来后要修改可能就要费牛劲了。最好你的CTO能对你100%的衷心，100%的负责。