web表单按钮的使用

Filed Under (Tech) by mantian on 09-09-2009

Article copyright by Gabriel Svennerberg
Gabriel Svennerberg版权所有

原作者:Gabriel Svennerberg;译者:UCD翻译小组mysmth2003原文网址:http://www.svennerberg.com/2008/09/the-use-of-buttons-in-web-forms/

动作按钮存在于每个web表单的底端。它们太平常了,以至于我们甚至不能仔细思考实际怎么去设计它们。从一堆伟大的易用性思想和我自己的经验中可收集到的信息中,我想提出一套做法来让这种设计更高效些。

Action buttons exists at the bottom of almost every web form. They’re so common that we often doesn’t even reflect on how to actually design them. By gathering information from a few of the great minds in the field of web usability and also from my own experiences, I’ve tried to come up with a set of best practices on how to design them efficiently.

Position 位置

根据Jakob Nielsen(雅各布·尼尔森)的观点,按钮的规则并没有那么麻烦。每个位置都有它的优点和缺点。而重要的一点是一致,如有可能遵照GUI标准平台的规范。

在网络世界以外,也有GUI标准,问题是他们在不同的平台上是不同的。在Windows平台上,GUI规范表明“确认”应该在左侧,而“退出”在右侧。而在苹果平台下,恰恰相反。

According to Jakob Nielsen, the order of the buttons doesn’t matter that much. Both positions has it’s pros and cons. The important thing is to be consistent and if possible follow platform GUI standards [1].

Outside the web world there are GUI standard. The problem is that they are different on different platforms. On the Windows platform the GUI guidelines state that OK should be positioned to the left and Cancel to the right. On the Apple platform it’s the other way around.


在web中,并没有固定的标准要求怎么去做,所以我们必须聪明地找出什么位置是最合适的。
On the Web there really is no standard on how to do this, so we have to try to find out which position is the smartest on our own.

Luke Wroblewski(卢克·罗博乌斯奇)在《网络应用表单设计》一文中专注于这个话题的探索。他建议把首要动作“确定”放置在表单的左侧,次要动作“退出”放置在表单右侧。

他进一步在《网络表单设计》一书中,阐述了从易用性对比测试中的发现:测试表明主要动作在左侧而次级动作在右侧具有更快的绩效。

Luke Wroblewski elaborates on this topic in his article Web Application Form Design [2]. His recommendation is to position the Primary action (OK) aligned to the left part of the form and the Secondary action (Cancel) to the right.

He elaborates even further on this topic in the book Web Form Design [3], where he presents the finding from a usability test performed on a form with different designs. What the test showed is that having the Primary action left-aligned and the Secondary action to the right of it makes for the fastest performance

Robert Hoekman, jr.(罗布特·霍克曼)也思考了不少关于这方面的内容,并且在《设计片段》(Designing the Moment)提出他的想法。

他同意Luke Wrobleski的关于首要动作在表单左侧的观点,这样做的原因在于可以形成一条很好的线,视线可以跟随,推下表格,从而轻松扫描。另一个原因在于如果用户用tab键(键盘左上方的制表符)操控表单,首要动作可以先于次要动作在表格命令下进行。

Robert Hoekman, jr. has also thought a lot about this and presents his thoughts in the book Designing the Moment [4].

He agrees with Luke Wroblewski that the Primary action should be left-aligned with the form. The reason for this is that this forms a nice line for the eye to follow, working it’s way down the form, thereby making it easy to scan. Another reason is that if the user is navigating the form with the tab-key, the Primary action comes before the Secondary action in the tab order.

Labeling the actions 标记动作

Robert Hoekman, jr. 也有一些关于按钮标记的想法,比恰当标记“确定”和“退出”按钮更好的办法是直接标记实际的动作。如果执行一个“存储一个笔记”(save a note)动作,为什么不让“存储笔记(save a note)”按钮替代“确定”按钮呢?Jakob Nielsen也建议按钮上的文字要说明这个按钮究竟要干嘛,不要只用类似于”确定”这种空泛的文字。 这么做用户会更有自信地使用,因为他知道当他按动按钮的时候将会发生什么。

Robert Hoekman, jr. also have some thoughts about the labeling of buttons. Instead of just labeling the buttons OK and Cancel it’s better to label them after what they actually do [4]. If it’s to save a note, then why not label the OK-button “Save note” instead. Jakob Nielsen also recommends using a label that explains what it does instead of just a generic label [1]. By doing this the user is more confident using the form since he knows what to expect when he pushes that button.


Visual distinction 视觉的差别

另一件事是Robert Hoekman,jr.讨论视觉上区分动作,使得用户能够很轻松地做出正确的选择。

Luke Wroblewski也推断出,做首要的动作要比次要的动作更突出。在易用性测试的调查中,他发现如果首要比次要动作有一点不同的设计的时候,用户会花多一些时间去完成表单。而另一方面,用户会更有信心,较少做出错误的选择。他建议使用不同颜色制作按钮或者让次要动作变成一个普通的链接。

一个简单的方法从视觉上区分两点:我经常去做,则使用粗体(bold font weight),放在首要动作上,而一个正常的字体放在次要动作上。

One other thing Robert Hoekman, jr. discusses is to visually distinguish the actions making it easier for the user to pick the right one.

Luke Wroblewski also concludes that making the Primary action stand out more than the Secondary action is a good thing. In the findings of the usability test, he finds that it takes the user a little more time to complete the form if the Primary and Secondary action has a different design. But on the other hand it makes the user more confident and less prone to choose the wrong one. He suggest making the buttons in different colors or making the Secondary action a plain link.

A simple way to visually distinguish the two that I sometimes do, is to use a bold font weight on the Primary action and a normal font weight on the Secondary.

Robert Hoekman, jr.推荐“对次要动作使用一个普通的链接”,他的理由是说这可以更清楚的判断谁是首要的。但是它也适用于费茨法则,即距离和目标尺寸设多大可被触及并且点击——目标越大会越快些(被触及、点击)。首要动作因此应该比次要动作大一些。

Robert Hoekman, jr. recommends using a plain link for the Secondary action [4]. He’s arguments for this is that it makes it clear which one is the most prominent. But it also applies to Fitt’s Law, which suggest that the distance and the size of a target determines how long it takes to reach it and click it. The bigger the target the faster. The Primary action should therefor be bigger than the Secondary action.


The Reset button 复原按钮

复原按钮被用来复原一个完整的表单。这种早期相当常见的应用,到如今却很少被看到。不过我想我也说一些关于这个按钮的话,当它经常被当作成对的按钮出现在表单中的时候。

在多数情况下,这个按钮最好是完全不用。所有经常错误点击复原按钮的用户因此会删掉他们输入的一切内容。(我在Confusing Northface contact form中写过),并且认真地说,你需要多频繁重设一个整个的表单,并且如果你这么做,会产生怎样的问题?

The Reset button is used to reset an entire form. It was pretty common in the early days of the web but is rarely seen nowadays. Nevertheless I thought I would say a few words about this button too since when it appears in a form, it’s usually paired with the Primary action.

In most situations it’s best not to use this button at all. All to often users click the Reset button by mistake thereby deleting everything they’ve entered. (I did it as I wrote in Confusing Northface contact form) And seriously, how often do you want to reset an entire form, and if you do, how hard is it?
这个按钮所具有的风险简单要同可能的收益做一个大的对比,加之在很多情况下,会对表单增加更大的混乱。

正如Jakob Nielsen放到他的警示框专栏《复原和退出按钮》中的话:

网络将会变成更开心的地方,如果所有的复原按钮被虚拟的移走之后。这种按钮几乎不能帮助用户,反而会伤害他们。

The risk with this button is simply to big compared to the possible benefit of it. Plus in most cases it just adds more clutter to the form.

Or as Jakob Nielsen put it in his alertbox column Reset and Cancel Buttons [5]:

The Web would be a happier place if virtually all Reset buttons were removed. This button almost never helps users, but often hurts them. 

可能唯一的时间是当复原按钮被请求的时候,是当一个表单被同一个用户重复使用的时候,并且每次输入的信息是不同的。

关于复原按钮Luke Wroblewski有一个想法,他认为如果你提供一个也应该提供一个撤回(undo)选项。用户点击复原按钮重新恢复表单,可以起到撤回的作用。此举意味着你不得不暂时的存储表单数据,但为用户的方便提供了很小的价值。

Possibly the only time when a Reset button is called for, is when a form is used repeatedly by the same user and the information entered differs from each use.

Luke Wroblewski has an idea about the Reset button [3]. He thinks that if you provide one you should also provide an undo for it. By changing the Reset button into an Undo after being clicked the user can restore the form. This means that you have to temporarily store the form data, but that’s a small price to pay for the convenience of the user. 

Best practices 最佳方法

基于以上所有的观点,加上我使用并设计web表单的经验,我提出一些好办法。

Taking all of the opinions above in consideration, plus my own experience in using and designing web forms, I’ve come up with these best practices.

  • Position the Primary action to the left 首要动作放在左边

    把按钮放在表单的左边,可以使得眼睛跟随一条清晰的路线。通过首要动作放在次要动作的左边,也便于tab次序。Having the buttons aligned with the left side of the form makes a clear path for the eye to follow. By putting the Primary action to the left of the Secondary action it’s also positioned first in the tab order.

  • Label the actions in a natural language 标签动作用自然的语言

    通过描述实际动作发生,用户更舒适的感受他期待使用的内容。By describing what the action actually does, the user feels more comfortable using it since he know what to expect.

  • Make the Primary action stand out 使首要动作凸显

    这样可以让用户更轻松选择他们想要的选项,而不会从一堆选项中艰难的发现。This makes it easier for the user to choose the option that’s most likely without making it harder to find the other option.

  • (Almost) Never use a iReset button (几乎)不要使用复原按钮

    复原按钮经常会伤害用户,而不会太多帮助他们。唯一的可能是他们在表单中需要它们,是同一个用户反复再三做不同输入的时候,即一旦你使用了“复原”,也就意味着为用户提供了一个撤回功能。Reset buttons often hurts user more than it helps them. The only time it’s called for is in a form that the same user uses over and over again with different input. If you use a Reset, also try to provide an undo function.

Do you agree with my conclusions or do you have a different opinion about this? Please share!
你同意我的结论或者对此有不同观点,请分享吧!

原文网址:http://www.svennerberg.com/2008/09/the-use-of-buttons-in-web-forms/

关于作者
Gabriel Svennerberg是一位网络开发人员和互动设计师,35岁,自从1996年就从事web的工作。起先自我雇佣,后来在Växjö、Varberg 和Stockholm等不同的代理商工作,如今为Saab Security构建网络应用以及强化用户体验工作。
http://www.svennerberg.com/about/

与林昊的交流

Filed Under (Kills, Tech, 架构) by mantian on 07-09-2009

林昊,网名BlueDavy,China OSGi User Group Director,淘宝网平台架构部架构师,个人的研究方向主要为 Java模块化、动态化系统的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc,为OSGi 在中国的推广起到了很大的作用。

王速瑜:数据集群问题:当数据增长到一定的数量级,必须要进行分布部署、备份、容灾、切割扩容等工作。请问什么程度的数量级需要分布部署,如何合理分布部署,需要考虑哪些情况?

林昊:一般来说,也没有固定的数量级,通常是根据硬件资源的状况以及所能接受的性能状况(例如一次查询必须在 3ms内完成)来决定。当达到性能瓶颈时,通常需要进行数据的拆分或备份等策略,在这个过程中最需要考虑的,就是对应用的影响程度,因此通常会需要一个强 大、透明的数据层,以屏蔽数据的拆分或备份、迁移操作给应用带来的影响,另外一方面就是应尽量能做到不停机完成。当然,这很难,因为需要面对多套数据结构 并存、数据冗余和同步等问题。

王速瑜:数据备份问题:对于大容量的数据备份,技术上如何做到不影响正常的服务?如何合理制定冷备、热备的实施策略、方式、时间段?在数据损坏、主服务器硬件损坏等故障情况下,如何最短时间内监控到故障并调度请求到备份服务器等容灾措施?

林昊:对于大容量的数据备份,技术上来说:多数情况下比较好的是选择异步消息通知实现数据备份,或基于高端数据 库的特性(例如Oracle的Standby)。对于冷备、热备的实施,原则要求均为不影响正常业务功能,因此可选的时段只能是系统访问量较低的时段。方 式则需要根据数据量以及备份的速度来决定,多数均为采取相对高频率的进行热备,低频率的进行冷备;在数据损坏、主服务器硬件损坏等故障时,要做到尽快切 换,就必须依赖强大的及时监控系统,在主服务器不可用时能够做到迅速报警。最理想状况就是能够有一种机制,自动切换备库为主库,并通知所有应用转换为连接 和使用新的主库,如果做不到自动的话,这个过程就仍然得基于“人肉”来进行操作了。

王速瑜:开放平台设计问题:开放平台API设计中,调用协议设计时有哪些考虑要求?对于请求类的调用协议设计, 倾向于call?A=a&B=b这种方式(这种方式对调用者比较方便,但对二进制的传输有一定限制,比如上传图片等),还是基于纯文本的方式,比 如WSDL、XML等?对用户鉴权的Token机制是怎样的?有没有对接入方进行QoS的考虑,是怎么做的?

林昊:对于开放平台而言,基本上目前Facebook引领了开放平台的技术,因此在协议上多数都采用Http, 接口的设计上则都倾向于REST风格;对于用户鉴权的Token机制上通常都是采用一个公私钥的匹配方式,并且此Token一定是由开放平台公司所提供; 开放平台中是肯定会对接入方的QoS有限制的,并且这通常也影响到了开放平台的收费标准,在实现时多数采用基于缓存进行实时费用计算,这点更强的应该是电 信行业。

王速瑜:跨IDC部署程序模块在业务发展到一定阶段后在所难免,跨IDC的专线资源相对有限。架构师该如何合理规划和使用同城、跨城的专线进行传输数据,以及专线意外中断的容灾措施?

林昊:跨IDC部署确实会存在很高的技术难度,部署结果的验证是最为关键的地方,其次是部署所耗费的带宽成本和 时间成本,对于部署结果验证而言,通常可采用的方法为业务脚本的测试;对于部署所耗费的带宽成本而言,通常需要借助多播技术,对于时间成本而言,通常需要 借助自动化的部署系统。

王速瑜:Web2.0网站的海量小文件的存储,如用户头像、相册微缩图等文件,这些文件的特点是尺寸小(100KB以内),数量巨大(数以百万计),这些文件的存储、读取、备份都是问题,请问您是如何提供具体解决方案的?

林昊:目前互联网公司,例如Google、优酷等,对于小文件或大文件的存储都有自己的一套解决方案,而并不会 去依赖高端的存储设备来解决。一方面是成本问题,另外一方面是伸缩问题,因此对于这些文件的存储、读取和备份多数都采用了类似GFS的方案或直接采用 Hadoop提供的HDFS方案。

王速瑜:互联网产品部署是一个很关键的环节,很多互联网公司依然采取手工部署发布产品版本的方式,但是这种方式 比较复杂而且低效,往往很容易出错,如果同时发布几个产品时,如果产品之间关联比较紧密,其中一个发布出错就会影响到其他的发布,请问作为架构师,您在日 常工作中是如何解决这样的问题?您的团队中是否考虑自动化动态部署,具体方案是怎么样的?

林昊:在部署这个问题上,目前好像只有国外的几家互联网公司做的不错,其中最典型的是eBay。eBay在很多 年前就已经做了一套自动化部署系统,在这套系统中,eBay可以将一次发布中的几个产品进行依赖关系的分析,从而决定其发布顺序,并可实现自动的发布、校 验和回滚,这套系统相信也是现在中国几家互联网公司都在追求的目标。

王速瑜:作为互联网技术架构师,您能简单总结一下海里互联网服务技术架构方面的理念、原则,方法吗?

林昊:我觉得eBay的五点总结基本已经够全面:

(1)“ 拆分”,数据库的拆分以及应用的拆分,当然这需要强大的技术的支撑,这点要做到的目标通常是便于应用的无限水平伸缩;

(2)能异步就异步,这需要业务的允许;

(3)能自动就自动,就像自动化的部署系统;

(4)记住所有失败的事情,这点非常重要;

(5)容忍不一致性,这句话的含义是尽量少用强事务,而是采用最终一致性这类方案。

当然,除了上面这五点之外,还有像多用缓存、自行实现关键技术(以控制稳定性、性能和做到及时响应)等。

王速瑜:有很多优秀的软件架构师能力很强,但是由于缺乏海量服务技术应用和实践的机会,不能很好地进行海量服务应用的架构设计,您能给他们一些宝贵建议,分享一下您是如何不断学习成长起来的?您有哪些提高技术视野的方法和途径,比如有哪些书籍可以推荐,哪些优秀的网站可以推荐?

林昊:这个问题提到点子上了,很多架构师不知道如何应对大型、高并发的场景,最主要的原因是没有这样的实践的机 会,毕竟目前只有在大型企业系统或互联网才能获得这类难得的实践机会,通常在没有实践机会的情况下是很难完全理解这些技术的。多数情况下,互联网中的技术 方案都是在多次血泪宕机下成长起来的,建议只能是多看各种互联网技术介绍的文章,例如Google共享了很多,还有网上也有很多各家互联网公司技术架构文 章的介绍,尤其是那类技术发展历程的介绍,可以设想下如果自己碰到这样的问题,会如何去解决,也许这样能慢慢掌握和理解大型、高并发系统的解决方案。书籍 方面目前国内各种高性能方面的书也开始不断冒出了,例如有《MySQL性能调优与架构设计》、《构建高性能的Web站点》、《构建Oracle高可用环 境》等,这些高性能的书通常都来源于作者亲身的经验,是非常值得学习的;另外要知道:如果想做到高性能,通常意味着要对软件(包括OS等)以及硬件技术都 有充分的掌握,因此像《深入理解JDK》、《深入理解Linux内核》、《深入理解计算机系统》这些书也是非常值得一看的。至于网站方面,像http://highscalability.com/http://www.javaperformancetuning.com/这些都是非常不错的网站。

(本文来自《程序员》杂志0909期,更多精彩内容敬请关注0909期杂志。)

微软:Dryad

Filed Under (Tech) by mantian on 23-07-2009

Tagged Under :

Dryad是微软分布式并行计算基础平台,使程序员可以利用数据中心的服务器集群对数据进行并行处理。Dryad程序员在操作数千台机器时,无需关心并行处理的细节。据Dryad论文描述:Dryad被设计为伸缩于各种规模的计算平台:从单台多核计算机、到由几台计算机组成的小型集群,直至拥有数千台计算机的数据中心。Dryad执行引擎负 责处理大型分布式、并行应用程序中会出现的各种难题:对计算机和它们的CPU进行调度,从通信或计算机的失败中恢复,以及数据在节点之间的传递等等。

其在微软体系结构中的地位:

延伸阅读:Dryad, Dryad论文

——EOF——-

Heroku的架构

Filed Under (SAAS, Tech, 架构) by mantian on 15-03-2009

Tagged Under :

很早之前在Infoq上看到Heroku的介绍,不过当时这个网站并没有推出,今天在整理收藏夹的时候发现,Heroku已经推出一段时间,而且现在作为云计算平台已经有很快的发展了。

Heroku是Rails应用最简单的部署平台。只是简单的把代码放进去,然后启动、运行,没人会做不到这些。Heroku会处理一切,从版本控制到 自动伸缩的协作(基于Amazon的EC2之上)。我们提供一整套工具来开发和管理应用,不管是通过Web接口还是新的扩展API。

HeroKu的架构大部分是采用开源的架构来实现的,:)其实构建云计算平台,开源的世界已经解决一切了,不是吗?下面看看HeroKu的架构图,非常漂亮:

Heroku架构图

一、反向代理服务器采用Nigix

Nigix是一个开源的,高性能的web server和支持IMAP/POP3代理的反向代理服务器,Nigix不采用多线程的方式来支持大并发处理,而是采用了一个可扩展的Event-Driven(信号asynchronous)的网络模型来实现,解决了著名的C10K问题。

Nigix在这里用来解决Http Level的问题,包括SSL的处理,Http请求中转,Gzip的传输压缩等等处理,同时应用了多个前端的Nigix 服务器来解决DNS及负载均衡的问题。

二、Http Cache采用Varnish

Varnish is a state-of-the-art, high-performance HTTP accelerator. It uses the advanced features in Linux 2.6, FreeBSD 6/7 and Solaris 10 to achieve its high performance.

Varnish在这里主要给采用来处理静态资源,包括对页面的静态化处理,图片,CSS等等,这里请求获取不到的再通过下一层的Routing Mess去获取。通常还有另外一个选择Squid,不过近几年来,Varnish 给大型网站应用的更加的多了。

三、动态路由处理层,这里采用了Erlang 实现的,是由该团队自己实现的,Erlang 提供了高可靠性和稳定性的服务端实现能力(其实,我们也可以这样去使用),这个层主要是解决路由寻址的问题,通过合理分配动态过来的请求,跟踪请求的负载能力,并合理的分配可获取的下一层app 服务。这个层实现了对业务app的可扩展性和容错性,可以根据下一层服务的负载容量来合理进行路由的选择。原理上它是一个分布式的动态HTTP请求的路由池子。

四、动态网格层,用户部署的app是部署在这一层,可以看成是一个服务器集群,只是粒度会更加的细小。

五、数据库层,这里不用多说了

六、Memory Cache

也不需要多说,现在大部分互联网公司都在应用,而且基于它开发了很多好的连接器,我们公司其实也有在采用,不过我们还有自己开发的分布式内存系统,如原来的TTC Server,现在好像叫WorkBench。

如何构建Large Scale PHP架构?

Filed Under (PHP, SAAS, Tech) by mantian on 14-03-2009

Tagged Under : , ,

一、构建Large Scale Php代码框架要先了解什么是SNA的架构。

SNA的意思是Share Nothing Architecture,其实很简单,就3个意思:

1、类似Http请求,每个请求之间都是独立的,没有状态的;

2、共享的数据都放在数据存储层,如数据库中或分布式数据库中;

3、避免前端的控制;

SNA的框架带来如下好处:

1、容易部署负载均衡服务;

2、程序模块化划分更好;

3、容易开发和Debug;

4、避免导致数据存储中心出现大范围瘫痪;

二、不要在运行时采用模板技术

记住,PHP本身就是基于模板技术的语言,不要再引用另外一个了,如果有时候你不得不采用模板技术,那么千万不要在运行时采用模板技术;

三、采用APC Opcode Cache

详情见apc,对PHP有效的开放源高速缓冲储存器工具,它能够缓存opcode的php中间码。lfacebook也在采用Apc作为PHP加速器

四、推荐的框架如下:

php_app_arch

五、还有一些注意细节:

  • No more than 1 stat() per PHP file per request;
  • Add a stat cache to PHP’s expand_filepath code;
  • Don’t stat if Apache has already stat’ed the file;
  • Get rid of excessive stats in the streams code;
  • Remove ./ from include_path and use relative path includes;
  • Use just a single base dir in include_path;
  • No open_basedir or safe_mode;
  • Use non-PIC Apache DSO (gcc -prefer-non-pic;
  • Use platform-specific gcc flags;
  • ./configure –disable-all;
  • Plenty of custom extensions and limit RINIT;
  • Filter all user data by default;
  • No $_COOKIE for you;
  • Careful use of the session extension;
  • others….

【收藏】大型网站架构演变和知识体系

Filed Under (Tech, 收藏夹) by mantian on 05-03-2009

Tagged Under :

之前也有很多介绍大型网站架构演变的文章,例如LiveJournal的、ebay的,都是非常值得参考的,下面这个博客介绍的更加详细,希望给团队的同事推荐一下,可以了解一下系统是如何从小到大的发展过程,和为什么是这样发展的!

 

架构演变第一步:物理分离webserver和数据库

最开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可能主机都是租借的,但由于这篇文章我们只关注架构的演变历程,因此就假设这个时候 已经是托管了一台主机,并且有一定的带宽了,这个时候由于网站具备了一定的特色,吸引了部分人访问,逐渐你发现系统的压力越来越高,响应速度越来越慢,而这个时候比较明显的是数据库和应用互相影响,应用出问题了,数据库也很容易出现问题,而数据库出问题的时候,应用也容易出问题,于是进入了第一步演变阶段:将应用和数据库从物理上分离,变成了两台机器,这个时候技术上没有什么新的要求,但你发现确实起到效果了,系统又恢复到以前的响应速度了,并且支撑住了更高的流量,并且不会因为数据库和应用形成互相的影响。

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

这一步架构演变对技术上的知识体系基本没有要求。

 

架构演变第二步:增加页面缓存

好景不长,随着访问的人越来越多,你发现响应速度又开始变慢了,查找原因,发现是访问数据库的操作太多,导致数据连接竞争激烈,所以响应变慢,但数据库连 接又不能开太多,否则数据库机器压力会很高,因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力,这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面(例如一两天才会有更新的页面)进行缓存(当然,也可以采用将页面静态化的方案),这样程序上可以不做修改,就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争,OK,于是开始采用squid来做相对静态的页面的缓存。

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

前端页面缓存技术,例如squid,如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法、命中率这些基本概念和实现原理等。

架构演变第三步:增加页面片段缓存

增加了squid做缓存后,整体系统的速度确实是提升了,webserver的压力也开始下降了,但随着访问量的增加,发现系统又开始变的有些慢了,在尝 到了squid之类的动态缓存带来的好处后,开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢,因此考虑采用类似ESI之类的页面片段缓存策略OK,于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

页面片段缓存技术,例如ESI等,想用好的话同样需要掌握ESI的实现方式等;

架构演变第四步:数据缓存

在采用ESI之类的技术再次提高了系统的缓存效果后,系统的压力确实进一步降低了,但同样,随着访问量的增加,系统还是开始变慢,经过查找,可能会发现系 统中存在一些重复获取数据信息的地方,像获取用户信息等,这个时候开始考虑是不是可以将这些数据信息也缓存起来呢,于是将这些数据缓存到本地内存,改变完毕后,完全符合预期,系统的响应速度又恢复了,数据库的压力也再度降低了不少。

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

缓存技术,包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。

架构演变第五步: 增加webserver

好景不长,发现随着系统访问量的再度增加,webserver机器的压力在高峰期会上升到比较高,这个时候开始考虑增加一台webserver,这也是为了同时解决可用性的问题,避免单台的webserver down机的话就没法使用了,在做了这些考虑后,决定增加一台webserver,增加一台webserver时,会碰到一些问题,典型的有:
1
、如何让访问分配到这两台机器上,这个时候通常会考虑的方案是Apache自带的负载均衡方案,或LVS这类的软件负载均衡方案;
2
、如何保持状态信息的同步,例如用户session等,这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等;
3
、如何保持数据缓存信息的同步,例如之前缓存的用户数据等,这个时候通常会考虑的机制有缓存同步或分布式缓存;
4
、如何让上传文件这些类似的功能继续正常,这个时候通常会考虑的机制是使用共享文件系统或存储等;
在解决了这些问题后,终于是把webserver增加为了两台,系统终于是又恢复到了以往的速度。

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

负载均衡技术(包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等)、主备技术(包括但不限于ARP欺骗、linux heart-beat等)、状态信息或缓存同步技术(包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等)、共享文件技术(包括但不限于NFS等)、存储技术(包括但不限于存储设备等)。

架构演变第六步:分库

享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了,这次又是什么状况呢,经过查找,发现数据库写入、更新的这些操作的部分数据库连接的 资源竞争非常激烈,导致了系统变慢,这下怎么办呢,此时可选的方案有数据库集群和分库策略,集群方面像有些数据库支持的并不是很好,因此分库会成为比较普遍的策略,分库也就意味着要对原有程序进行修改,一通修改实现分库后,不错,目标达到了,系统恢复甚至速度比以前还快了。

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

这一步更多的是需要从业务上做合理的划分,以实现分库,具体技术细节上没有其他的要求;

但同时随着数据量的增大和分库的进行,在数据库的设计、调优以及维护上需要做的更好,因此对这些方面的技术还是提出了很高的要求的。

 

架构演变第七步:分表、DAL和分布式缓存
随着系统的不断运行,数据量开始大幅度增长,这个时候发现分库后查询仍然会有些慢,于是按照分库的思想开始做分表的工作,当然,这不可避免的会需要对程序 进行一些修改,也许在这个时候就会发现应用自己要关心分库分表的规则等,还是有些复杂的,于是萌生能否增加一个通用的框架来实现分库分表的数据访问,这个在ebay的架构中对应的就是DAL,这个演变的过程相对而言需要花费较长的时间,当然,也有可能这个通用的框架会等到分表做完后才开始做,同时,在这个阶段可 能会发现之前的缓存同步方案出现问题,因为数据量太大,导致现在不太可能将缓存存在本地,然后同步的方式,需要采用分布式缓存方案了,于是,又是一通考察和折磨,终于是将大量的数据缓存转移到分布式缓存上了。

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

分表更多的同样是业务上的划分,技术上涉及到的会有动态hash算法、consistent hash算法等;

DAL涉及到比较多的复杂技术,例如数据库连接的管理(超时、异常)、数据库操作的控制(超时、异常)、分库分表规则的封装等;

 

架构演变第八步:增加更多的webserver

在做完分库分表这些工作后,数据库上的压力已经降到比较低了,又开始过着每天看着访问量暴增的幸福生活了,突然有一天,发现系统的访问又开始有变慢的趋势 了,这个时候首先查看数据库,压力一切正常,之后查看webserver,发现apache阻塞了很多的请求,而应用服务器对每个请求也是比较快的,看来 是请求数太高导致需要排队等待,响应速度变慢,这还好办,一般来说,这个时候也会有些钱了,于是添加一些webserver服务器,在这个添加 webserver服务器的过程,有可能会出现几种挑战:
1
Apache的软负载或LVS软负载等无法承担巨大的web访问量(请求连接数、网络流量等)的调度了,这个时候如果经费允许的话,会采取的方案是购 买硬件负载,例如F5NetsclarAthelon之类的,如经费不允许的话,会采取的方案是将应用从逻辑上做一定的分类,然后分散到不同的软负载集群中;
2
、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈,需要进行改进,也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等;
在做完这些工作后,开始进入一个看似完美的无限伸缩的时代,当网站流量增加时,应对的解决方案就是不断的添加webserver

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

到了这一步,随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高,这个时候要求对所采用的技术都要有更为深入的理解,并需要根据网站的需求来做更加定制性质的产品。

 

架构演变第九步:数据读写分离和廉价存储方案

突然有一天,发现这个完美的时代也要结束了,数据库的噩梦又一次出现在眼前了,由于添加的webserver太多了,导致数据库连接的资源还是不够用,而这个时候又已经分库分表了,开始分析数据库的压力状况,可能会发现数据库的读写比很高,这个时候通常会想到数据读写分离的方案,当然,这个方案要实现并不 容易,另外,可能会发现一些数据存储在数据库上有些浪费,或者说过于占用数据库资源,因此在这个阶段可能会形成的架构演变是实现数据读写分离,同时编写一些更为廉价的存储方案,例如BigTable这种。

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解,同时会要求具备自行实现的技术;

廉价存储方案要求对OS的文件存储有深入的掌握和理解,同时要求对采用的语言在文件这块的实现有深入的掌握。

 

架构演变第十步:进入大型分布式应用时代和廉价服务器群梦想时代

经过上面这个漫长而痛苦的过程,终于是再度迎来了完美的时代,不断的增加webserver就可以支撑越来越高的访问量了,对于大型网站而言,人气的重要毋 庸置疑,随着人气的越来越高,各种各样的功能需求也开始爆发性的增长,这个时候突然发现,原来部署在webserver上的那个web应用已经非常庞大 了,当多个团队都开始对其进行改动时,可真是相当的不方便,复用性也相当糟糕,基本是每个团队都做了或多或少重复的事情,而且部署和维护也是相当的麻烦, 因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间,出问题的时候也不是很好查,另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导 致了全站都不可用,还有其他的像调优不好操作(因为机器上部署的应用什么都要做,根本就无法进行针对性的调优)等因素,根据这样的分析,开始痛下决心,将 系统根据职责进行拆分,于是一个大型的分布式应用就诞生了,通常,这个步骤需要耗费相当长的时间,因为会碰到很多的挑战:
1
、拆成分布式后需要提供一个高性能、稳定的通信框架,并且需要支持多种不同的通信和远程调用方式;
2
、将一个庞大的应用拆分需要耗费很长的时间,需要进行业务的整理和系统依赖关系的控制等;
3
、如何运维(依赖管理、运行状况管理、错误追踪、调优、监控和报警等)好这个庞大的分布式应用。
经过这一步,差不多系统的架构进入相对稳定的阶段,同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量,结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

这一步涉及的知识体系非常的多,要求对通信、远程调用、消息机制等有深入的理解和掌握,要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。

运维这块涉及的知识体系也非常的多,多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。

说起来确实不怎么费力,整个网站架构的经典演变过程都和上面比较的类似,当然,每步采取的方案,演变的步骤有可能有不同,另外,由于网站的业务不同,会有不同的专业技术的需求,这篇blog更多的是从架构的角度来讲解演变的过程,当然,其中还有很多的技术也未在此提及,像数据库集群、数据挖掘、搜索等,但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量,因此在真实的发展过程中还会有很多的不同,另外一个大型网站要做到的远远不仅仅上面这些,还有像安全、运维、运营、服务、存储等,要做好一个大型的网站真的很不容易!

实现高可用性的7R原则

Filed Under (Tech) by mantian on 18-02-2009

这里列举了七条在不打破预算的情况下,最大化可用性的方法。由于每种方法的首字母都是R,所以又称高可用性的7R原则。他们是:
冗余(Redundancy)
名声(Reputation)
可靠性(Reliability)
修补能力(Repairability)
恢复能力(Recoverability)
响应(Responsiveness)
活力(Robustness)
冗余
多 年来,制造商一直在设计他们的产品中保存一定的冗余,包括多余的能源供应,多处理器,内存分段,以及多余的磁盘。对于整个采用热备模式运行的服务器系统来 说也是如此。基础架构分析人员在配置磁盘、磁盘控制器和服务器使用双路径;把网络负载分散到两条线上;以及提供备用的控制台,这也是采用了同样的方法– 总而言之,尽可能地减少单点的故障造成服务中断的可能性。

名声
后面三个”R”–名声、可靠性和修补能力–紧密相关。名声指的是主要供应商一贯的记录。可靠性是关于产品中所使用的部件和代码的可 依赖的程度。修补能力是衡量供应商能够多快,并且多方便地修理好(或者替换掉)有问题的部件。下面,我们将仔细看看这三项。在服务器,磁盘存储系统,数据 库管理系统和网络硬件以及软件领域中,供应商的名声是获得高可用性的重要因素。最好是选用最好的供应商。你可以通过下面几中方法来衡量一个厂商的名声。
市场分额百分比
行业分析家和华尔街的报告
在该领域内的历史记录
客户参考(尤其在确认诸如费用,服务,产品的质量,服务人员的培训以及可信程度等因素时,这点格外有用)。
可靠性
软件或者硬件的可靠性也可以通过客户参考和行业分析家来证实。除了这些,你应该考虑采用经验性部件可靠性分析的方法。这需要以下步骤:
检查并分析问题管理日志
检查并分析供应商日志
从操作人员那里获得反馈
从支持人员那里获得反馈
从供应商的维修人员那里获得反馈
同其他人的经验做比较
研究行业分析家的报告
一个对于问题日志的分析应该显示出任何不寻常的失败模式。你应该从供应商、产品、使用部门、发生失败的时间和日期、失败出现的频率以及维修的时间等角度去研究它们。供应商经常保存站内维修日志,你可以用它们来进行相似的分析。

你将发现操作人员的反馈通常是公正的,而且有启迪的作用,能够反映出各个部件真正的性能。尤其是对于那些离站的操作者们。例如每天早晨,在启动前他 们可能要对某一个特定的网络部件做数不清的重启动,但是由于这一情况经常出现,他们可能懒得做日志进行记录。和不同支持人员,比如系统管理员、网络管理员 和数据库管理员进行的相似的交流可能反映出相似的要求。

你可能认为供应商的维修人员提供的反馈会有偏私,但是根据我的经验,他们对于自己产品的反馈和使用那些产品的人的反馈一样公正而且有启迪的作用,能 够正确显示出那些产品的可靠性。这样,那些维修人员就成为评估部件可靠性、以及和其他公司的经验做比较的一个有价值的信息来源。那些和你使用的平台、配 置、提供的服务和客户都很相似的公司的经验特别有帮助。有名的行业分析家的报告也可以预测部件的可靠性。

修补能力
修补能力是技术服务人员能够解决或者替换有问题的部件的能力。衡量这项能力的两个通常的标准是完成维修的时间长短和维修工作多长时 间就要进行一次。在比较成熟的系统里,维修的工作可以通过远程诊断中心来完成,在那里,错误被查明并修正或解决,并执行了永久的解决方案,这个过程只需要 很少或者根本不需要操作人员的介入。

恢复能力
恢复能力指的是克服瞬间的失败的能力,它使最终用户端的可用性完全不受这类事件的影响。它小到从一个内存单元的错误中恢复,大到整个服务器系统转移到热备的系统上而不丢失数据和传输。恢复能力还包括重新尝试对于磁盘或者磁带进行读取或者写入,还包括沿着网线重新尝试传输。

响应
响应指的是紧急情况下,所有相关人员及因素解决问题、排除故障的能力。它包括有训练有素的供应商和内部支持人员能够对问题做出快速而有效的反应。它还包括对于资源,比如磁盘或者服务器的自动恢复能够在多长的时间内起作用。

活力
关于高可用性的最后一个词就是”活力”,它描述的是可用性程序的整体设计。一个有活力的程序将能够经受很多不同的考验–无论是来自内 部的还是外部的–而这些问题可能轻而易举地就能够破坏一个比较脆弱的系统的可用性。要保持活力需要对于文件和培训投入相当的额外费用。这些技术培训包 括:为了适应和平台、产品、服务和顾客相关的技术的变化的培训;为了适应相关的人员变动的培训;为了适应新经营方向、合并和收购等新的商业变化的培训。

理解并应用这7有关高可用性的单词,可以帮助你实现高可用性的梦想。本文来自:Net130

web优化checklist

Filed Under (Tech) by mantian on 22-01-2009

Tagged Under : ,

自检项目:

* 资源检查(针对html,js,swf,css,图片等)

是否新增加了文件请求?
是否有404请求?
新增加的文件请求响应中是否有expirex头(好头)?
新增加的文件请求响应中是否有etag头(坏头)?
新增加的文件请求是否支持gzip压缩?
新增加的文件请求下载过程是否有block?
新增加的文件请求下载过程是否导致其他资源block?
新增加的文件请求能否延迟加载?
是否减少了文件请求或者合并了文件请求?
新增加的请求能否被浏览器缓存?
新增加的请求是否适合进行长时间缓存?
在empty cache和full cache两种情况下,是否有重复的文件请求?
在empty cache和full cache两种情况下,是否有abort的文件请求?
新增加的文件请求是否需要通过一个301/302跳转
(针对imgcache)新增加的文件是否适合分散到新域名下?

* Js检查

新增加的js请求能否合并到现有的js请求或者页面请求中?
新增加的js请求是否在关键路径上?
新增加的js请求能否放到body之后加载?能否延迟异步加载?
新增加的js文件是否重写了大量已有js文件的代码?
Js文件能否进行混淆和压缩?
循环中的计算有没有能提出到循环外进行的?
有没有大量连续的字符串连接操作(如有考虑用数组join)

* CSS检查

新增加的CSS是否有相互import?
新增加的CSS是否大量复写了原有CSS文件的大量规则?
新增加的多个CSS能否合并?
CSS能否直接写到html页面中(可复用性高吗?)?
是否使用了expression?
是否在hover样式中重新声明了背景图片(会导致重复请求)?

* 限速检查

是否进行过netlimiter限速测试?
在限制IE下载进程为2个和8个两种情况下打开页面的速度是否有明显差异?
是否进行过cpukiller限速测试?

* http检查

DNS Lookup次数:
Block 请求个数(请求的):
关键路径上Block请求个数

*Cookie检查

是否创建了新的cookie?
是否创建了新的文件cookie?
是否创建了新的qq.com域名cookie?
能否用user-data或者share object代替cookie?

* 图片检查

新增加的图片能否延迟到用户要看的时候再加载?
新增加的图片是否用innerHTML方式填充到页面中的(可能导致重复请求)?
新增加的图片是否需要进行预加载?
新增加的图片能否合并到已有的图片中?

* Html检查

是否使用了iframe?
Css是否写在head中?
Script是否(能否)写到页面最下面?
Html文件能否进行混淆和压缩?
Inline的css是否使用了了expression,是否在hover样式中重新声明了背景图片?

* flash检查

Flash是否使用了比较耗费cpu的渲染效果?
Flash是否超过了100k?
Flash是否需要下载额外的网络资源?
Flash能否延迟加载?

* Ajax检查

页面能否分阶段渲染?
页面能否边显示(或者交互)边渲染
写操作是否用post方式提交
读操作能否用json方式请求?
CGI能否允许cache,能否支持304响应,能否支持Gzip压缩

Sd2.0大会的web系统架构经验分享精华

Filed Under (Kills, Tech) by mantian on 30-12-2008

Tagged Under : ,

一,不要过设计:never over design

这是一个常常被提及的话题,但是只要想想你的架构里有多少功能是根本没有用到,或者最后废弃的,就能明白其重要性了,初涉架构设计,往往倾向于设计大而化 一的架构,希望设计出具有无比扩展性,能适应一切需求的增加架构,web开发领域是个非常动态的过程,我们很难预测下个星期的变化,而又需要对变化做出最 快最有效的响应。。

ebay的工程师说过,他们的架构设计从来都不能满足系统的增长,所以他们的系统永远都在推翻重做。请注意,不是ebay架构师的能力有问题,他们 设计的架构总是建立旧版本的瓶颈上,希望通过新的架构带来突破,然而新架构带来的突破总是在很短的时间内就被新增需求淹没,于是他们不得不又使用新的架 构。

web开发,是个非常敏捷的过程,变化随时都在产生,用户需求千变万化,许多方面偶然性非常高,较之软件开发,希望用一个架构规划以后的所有设计,是不现实的

二,web架构生命周期:web architecture‘s life cycle

既然要杜绝过设计,又要保证一定的前瞻性,那么怎么才能找到其中的平衡呢?希望下面的web架构生命周期能够帮到你所设计的架构需要在1-10倍的增长 下,通过简单的增加硬件容量就能够胜任,而在5-10倍的增长期间,请着手下一个版本的架构设计,使之能承受下一个10倍间的增长。

google之所以能够称霸,不完全是因为搜索技术和排序技术有多先进,其实包括baidu和yahoo,所使用的技术现在也已经大同小异,然而,google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的。

三,缓存:Cache

空间换取时间,缓存永远计算机设计的重中之重,从cpu到io,到处都可以看到缓存的身影,web架构设计重,缓存设计必不可少,关于怎样设计合理的缓 存,jbosscache的创始人,淘宝的创始人是这样说的:其实设计web缓存和企业级缓存是非常不同的,企业级缓存偏重于逻辑,而web缓存,简单快 速为好。。

缓存带来的问题是什么?是程序的复杂度上升,因为数据散布在多个进程,所以同步就是一个麻烦的问题,加上集群,复杂度会进一步提高,在实际运用中,采用怎样的同步策略常常需要和业务绑定。

老钱为搜狐设计的帖子设计了链表缓存,这样既可以满足灵活插入的需要,又能够快速阅读,而其他一些大型社区也经常采用类此的结构来优化帖子列表,memcache也是一个常常用到的工具

钱宏武谈架构设计视频 http://211.100.26.82/CSDN_Live/140/qhw.flv

Cache的常用的策略是:让数据在内存中,而不是在比较耗时的磁盘上。从这个角度讲,mysql提供的heap引擎(存储方式)也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?

我们这里只说到了读缓存,其实还有一种写缓存,在以内容为主的社区里比较少用到,因为这样的社区最主要需要解决的问题是读问题,但是在处理 能力低于请求能力时,或者单个希望请求先被缓存形成块,然后批量处理时,写缓存就出现了,在交互性很强的社区设计里我们很容易找到这样的缓存

四,核心模块一定要自己开发:DIY your core module

这点我们是深有体会,钱宏武和云风也都有谈到,我们经常倾向于使用一些开源模块,如果不涉及核心模块,确实是可以的,如果涉及,那么就要小心了,因为当访 问量达到一定的程度,这些模块往往都有这样那样的问题,当然我们可以把问题归结为对开源的模块不熟悉,但是不管怎样,核心出现问题的时候,不能完全掌握其 代码是非常可怕的

五,合理选择数据存储方式:reasonable data storage

我们一定要使用数据库吗,不一定,雷鸣告诉我们搜索不一定需要数据库,云风告诉我们,游戏不一定需要数据库,那么什么时候我们才需要数据库呢,为什么不干脆用文件来代替他呢?

首先我们需要先承认,数据库也是对文件进行操作。我们需要数据库,主要是使用下面这几个功能,一个是数据存储,一个是数据检索,在关系数据库中,我们其实非常在乎数据库的复杂搜索的能力,看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了)

select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id
select a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d,review as e where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id and a.Id=e.Reviewid group by a.Id ……………………………………….

我们可以看出需要数据库关联,排序的能力,这个能力在某些情况下非常重要,但是如果你的网站的常规操作,全是这样复杂的逻辑,那效率一定 是非常低的,所以我们常常在数据库里加入许多冗余字段,来减小简单查询时关联等操作带来的压力,我们看看下面这张图,可以看到数据库的设计重心,和网站 (指内容型社区)需要面对的问题实际是有一些偏差的

同样其他一些软件产品也遇到同样的问题所以具我了解,有许多特殊的运用都有自己设计的特殊数据存储结构与方法,比如有的大型服务程序采取树形数据存储结构,lucene使用文件来存储索引和文件。

从另外一个角度上看,使用数据库,意味着数据和表现是完全分离的(这当然是经典的设计思路),也就是说当需要展示数据时,不得不需要一个转 换的过程,也可以说是绑定的过程,当网站具备一定规模的时候,数据库往往成为效率的瓶颈,所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑 定

这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫,而是我们在设计数据的持久化时,需要根据实际情况来选择存储方式,而数据库不过是其中一个选项

六,搞清楚谁是最重要的人:who’s the most important guy

在用例需求分析的时候常常讲到涉众,就是和你的设计息息相关的人,在web中我们一定以为最重要的涉众莫过于用户了。,在一个传统 的互动社区开发中,最重要的东西是内容,用户产生内容,所以用户就是上帝,至于内容挑选工具,不就是给坐我后面三排的妹妹们用的吗?凑或行了,实在有问题 我就在数据里手动帮你加得了。。这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题:实际上网站每天产生的内容非常 的多,普通人是不可能看完的,而编辑负责把精华的内容推荐到首页上,所以很多用户读到的内容其实都依赖于编辑的推荐,所以设计让编辑工作方便的工具也是非 常重要,有时甚至是最重要的。

七,不要执着于文档:don’t be crazy about document

web开发的文档重要吗?什么文档最重要?我的看法是web开发中交流>文档,

现在大的软件公司比较流行的做法是:

注重产品设计文档,在这种方法里,产品文档非常详尽,并且没有歧义,开发人员基于设计文档开发,测试人员基于设计文档制定测试方案,任何新人都可以通过阅读产品设计文档来了解项目的概况。

而web项目从概念到实现的时间是非常短的,而且越短越好,并且由于变化迅速,要想写出完整的产品和需求文档是几乎不可能的,大多数情况是 等你写出完备的文档,项目早就是另外一个样子,但是没有文档的问题是,如果团队发生变化,添加新成员怎样才能了解软件的结构和概念呢,一种是每个人都了解 软件的整个结构,除非你的团队整体消失,否则任何一个人都能够担当培养新人的责任,这种face2face交流比文档有效率很多。

于是就有了前office开发者,现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差,他说,我们的项目是吵出来的,我听完会心一笑

八,团队:team

不要专家团队,而要外科手术式的团队,你的团队里一定要有清道夫,需要有弓箭手,让他们和项目一起成长,才是项目负责人的最大成就

总结:

0)架构是一种权衡

1)web开发的特点是是:没有太复杂的技术难点,一切在于迅速的把握需求,其实这正式敏捷开发的要旨所在,一切都可以非常快速的建立,非常快速的重构,我们的开发工具,底层库和框架,包括搜索引擎和web文档提供的帮助,都提我们供给了敏捷的能力。

2)此外,相应的,最有效率的交流方式必须留给web开发,那就是face2face(面对面),不要太担心你的设计不能被完备的文档所保留下来,他们会以交流,代码和小卡片的方式保存下来。

3)人的因素会更加重要,无论是对用户的需求,还是开发人员的素质。

另:有关web效率,有著名的14条规则,由yahoo性能效率小组所总结,并广为流传。业已出现相关插件(YSlow),针对具体网页按彼规则评分,这 次该小组负责人Tenni Theurer也受邀来到此次大会,我把Tenni小姐(之前真的没有想到她是个女孩,并且如此年轻)和她的团队的14 rules列在下面。

Make Fewer HTTP Requests
Use a Content Delivery Network
Add an Expires Header
Gzip Components
Put CSS at the Top
Move Scripts to the Bottom
Avoid CSS Expressions
Make JavaScript and CSS External
Reduce DNS Lookups
Minify JavaScript
Avoid Redirects
Remove Duplicate Scripts
Configure ETags
Make Ajax Cacheable

通过安装firebug和YSlow这两个firefox插件(请注意要先安装firebug再安装yslow,下载后拖动到firefox里即可)我们 可以看到你的网页根据下面的规则的评分

FireStats icon Powered by FireStats
MC Inside