分类归档: Web

消除小型 Web 站点单点故障(Single Point of Failure)

针对小型站点的技术普及信息,中大型网站的牛人不用看,耽误您的时间我负不起这责任。
用 Windows 做网站的也别看了,不适合。

说起单点故障(Single Point of Failure,SPOF),倒是可以想起电影 《2012》中,一把焊枪把齿轮卡住,从而导致整个舱门无法关闭,进而整个引擎无法发动。这是个有点生动的例子–如此庞大的一个系统,居然因为一把小小的焊枪而险些毁于一旦。投入巨大人力物力生产的救命方舟居然做不到高可用(High availability),这是致命的事情。

大脑对与人来说,就是一个单点,大脑损坏,人也完蛋;手是不是单点? 一只没了,另一只还能日常生活,从这个角度来说,不是单点。消除单点的最常见的做法:增加冗余。比如,人有两只手。其次,层次化。当然,分层的目的是便于隔离问题。电影 《2012》 中的这个问题,不知道谁是总架构师,看起来,隔离做得不太够 :)

一般来说,只要系统能够比较清楚的分出层次来,要消除单点故障还是有章可循的事情。比如,一个网站,从基础的硬件层,到操作系统层,到数据库层,到应用程序层,再到网络层,都有可能产生单点故障。如果要有效的消除单点故障,最重要的一点是设计的时候要尽量避免引入单点,而随着架构的变化,定期审查系统潜在单点也是有必要的。

有人或许会问,假设一个起步中的站点,只有一台服务器,什么东西都在一个盒子里,到底要怎么做呢? 这里的建议是先抛开主板、CPU 、内存这些,首先必须考虑硬盘(存储层)的问题,如果机器只有一块硬盘,即使你备份计划再完善(不要说你的备份也是备份在这块硬盘上的),还是建议你起码再弄一块。做镜像,让出错的概率降低,这是划算的投入,当然消除单点,成本几乎不可避免的要增加。如果硬盘多,或者有其他备份机制,可选的方法就更多,别刻舟求剑。

第二个要考虑网卡与网线的单点问题。先说网线,如果要问一个系统里面最容易物理损坏的是哪个组件,答案恐怕非网线莫属,对于网线这样多数时候因为距离需要定制的东西,总是购买成品还是有成本的,从我观察到的情况来看,各个 IDC 的网线使用手工制作的比例不小,这个质量几乎很难控制,一根线,两个水晶头,哪一个出问题都不能正常传输。怎么办? 想办法提升网线整体质量还是弄两根网线放在那里? 解决办法早都有了,网卡绑定 (NIC bonding)一个很简单很通用的办法(refer),但是问题是并非很多人在用。多数 PC 服务器应该都是配置了多块网卡,如果是自己攒服务器,记得网卡多一块成本没多大,但是用处会有很多。如果耐着性子看到这里,先别急着去 Google,还有问题呢,两根网线如何接到上行交换机,什么样的交换机支持绑定,如何确定绑定是真正生效的? 答案是,尝试一下。

然后是什么? 是跑多个数据库,还是跑两个 Web 服务器,一个不行用另一个顶? 对于单台服务器,其它能消除单点的地方恐怕收效也不会特别大,现在少做无用功,或许要重点考虑如何备份,如何优化,以及出现问题的时候如何做到快速恢复。有一个或许会引起争议的建议是,除了 SSH 登录之外,要不要留一个 Telnet 登录的服务呢? 毕竟 SSH 服务器端守护进程不是百分百靠谱的事儿,如果 IDC 距离较远,需要斟酌一下。好吧,网站有了一点发展,用户量也增加了,感觉需要增加服务器了。再增加一台服务器,抗风险能力一下子加强了许多,毕竟一台机器质量再好,也有出错的时候。现在,Web 服务器、DB 服务器可以考虑引入 HA 的方案,如果单台服务能力够,主备模式也不错。随着网站的发展,服务器数量继续增加…

随着服务器数量的增加,到了必须要自己购买网络设备的时候了。同样的设备,一买恐怕就要买双份,原因无它–一台总要出错,哪怕是电源被拔错–而这样的情况实际上并不少见。如果预算不够,那就再等等,但是要记住,定期审查,有可能的话,进行弥补总不会错。

到现在,所有的服务器都还在一个 IDC 呢,IDC 本身也是个单点啊,服务器被黑怎么办? 机房光线被施工工人挖断怎么办? 机房停电怎么办? 找第二个机房吧。现在选 IDC 首先要考虑什么? 中国特色的互联网问题总要考虑吧,”南北互通”怎么样…或许在选择第一个机房的时候已经遇到了类似的问题,或许现在正在受到这个问题的困扰。选好 IDC 之后,首先计划一下数据如何备份过来,然后,网站的配置信息如何同步或备份过来(这是保证第一个 IDC 出了致命问题之后的最基本的恢复要求)。多个 IDC 之后不得不提上议程的要算 DNS 这个事儿了。你的 DNS 解析商靠谱么? 如果域名提供商遭受攻击,对自己的网站影响能承受么?

更多的服务器,提供更多的应用,更多的用户,更多的收入… 接下来该怎么办呢? 现在,您所面对的已经不是一个小型 Web 站点了,可以不用看这篇文章了。

到现在,我还没说人的问题,如果这些信息只有一个人知道,万一这个人出了点事情怎么办? 作为老板,还要考虑人的单点问题。

EOF

Updated: DNS 的健康程度检查重要性应该提升一些。如何检查?有很多在线的工具可供使用,简单直接。

此文作者:, 位于 Web 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

网站优化应重视 DNS 预获取(DNS Prefetching)

网站优化技术总是在进化。今天重新阅读了一下以前的前端优化笔记,发现对于 YSlow 优化 34 条准则关于减少 DNS 查找 (Reduce DNS Lookups)的部分或许应该修正一下了。

DNS 作为互联网的基础协议,其解析的速度似乎容易被网站优化人员忽视。现在浏览器厂商已经有在针对 DNS 进行优化,典型的一次 DNS 解析耗费 20-120 毫秒,减少 DNS 解析数是个优化的方式,而能够缩减 DNS 解析的时间也是有经济效益的事情。这就是浏览器厂商重视 DNS Prefetching 的主要原因。DNS Prefetching 对于性能的收益可以简单的用”DNS 同步请求到异步”来解释,也就是具有此属性的域名不需要用户点击链接就在后台解析,而域名解析和内容载入是串行的网络操作,所以这个方式能减少用户的等待时间,提升用户体验。

Google Chrome 内置就有 DNS Prefetching 技术(注意之前有几个小版本因为这一特性反而带来了性能问题) ,而 Firefox 3.5 也引入了这一 新特性。至于 IE 8,暂时还看不到有什么举措(或许是我没注意到?)。

对于一个网站来说,如果希望能充分利用用户浏览器端的这个功能,可以在页面添加 link 属性的锚点来做到。类似:

<link rel="dns-prefetch" href="http://www.google-analytics.com/">

另外还有这个 x-dns-prefetch-control 也有必要适当用一下。对于某些站点引用了 Google 的某些服务脚本,可能这尤其有用。

另外一种加速 DNS 的途径是考虑使用 pdnsd 之类的缓存 DNS 代理服务器来加速某些 DNS 请求。

在 Chrome 中,可以通过在地址栏输入 about:histograms/DNS 来观测一些有趣的 DNS 性能数据。

EOF

登陆框的密码遮盖问题以及其他

几天前看到的这个关于密码遮盖(Password Masking) 问题的讨论,顺着链接有找到了一些讨论来看,继而发现相关文章已经有人翻译了(refer),但中文技术社区好像很少见到讨论(也可能是我孤陋寡闻)。

这是个令人印象深刻的话题,因为挑战的是习惯性的设计方式。放眼看去,所有需要输入密码才可登录的网站都是遮盖密码的。密码遮盖带来的坏处是显而易见–用户的输入成了盲区,不知道自己输入的是否对,点击登录变成了变相的试错操作,产生比较多的再次登录操作,对给用户造成非常糟糕的使用感受。然而似乎很少有人如何去考虑改进这个现状。关注别人视而不见的问题才会带来革新与创新,要不怎么说人家 Jakob Nielsen 是用户体验方面的大牛呢,要从别人口中出来这个论断可能会被人笑话,而大牛就敢于挑战常规,弄个问题就给大家带来思考了–扯远了。

似乎多数人赞同添加一个额外的检查框(CheckBox),安全性要求不高的应用,默认不遮挡,用户输入完毕之后,再选择旁边的检查框对密码进行遮挡;对于安全性要求比较高的应用,默认密码遮挡,但可以选择显示一下密码明文一下,方便用户检查是否有拼写错误。

如果你用过苹果的产品,比如 iPhone 新 OS 3.0 的版本,你会发现密码的处理又进了一步,密码输入时是显示明文的,方便用户确认没有输错,在几秒钟后或者输入下一个字符的时候再对这个字符遮盖。(很多移动厂商好像现在都这么设计了)

iPhone_Password_Masking.png

(截图有点喧宾夺主,对付着看吧)

这个想法真的很让人欣赏,对于手持设备能够比较有效的防止了窥探(peeking over your shoulder),也减少了用户输入错误的频率。只是不知道是不是已经被手机厂商申请了专利。对于大屏幕显示器来说,窥探的可能性有多大?缺乏数据支持,很难说明。或许,这里的安全专家的分析对质疑者也会有点帮助。

其实我觉得密码遮盖问题在用户初次注册的时候带来的问题尤其严重。在这个环节如果添加一个 CheckBox 要用户知道自己连续两次输入的密码是什么应该是有必要的(有人举手同意麽?) ,否则的话,用户要的密码可能不是自己输入的,短时间内连续两次输入,出现键入错误的几率并非不存在。

好吧,现在开始审视一下自己的网站登录框设计以及注册页面吧…新的问题或许是,你有勇气做点修改麽?


如果觉得上面说的都是废话,那么不妨考虑这两个问题:

  • 为什么我们之前就没考虑到这一点?
  • 如何才能先于别人一步想到这一点?

EOF

延伸阅读:Better Password Inputs, iPhone Style

此文作者:, 位于 Web 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

关于团队 BLOG 这件事

现在网络上已经可以看到很多公司的团队对外的 BLOG ,关于这个话题,在这里记录一下我的一些个人看法。当然贵团队如果已经开博或者即将开博的话,毋须照搬,这不是什么指导。

明确团队开博目的

首先必须确定要传递哪些信息给读者? 宣传公司团队文化? 技术宣传? 产品宣传? 还是兼而有之? 如果只是为了跟风,那就没必要的。实际上,我相信大部分团队 BLOG 不过是跟风而已,不过跟风跟的好,也能起到不错的作用。如果能认真经营 BLOG ,它就能给你带来价值,超乎你想象的价值。

一般而言,建议对外开博前,可以在内部先试运行一下,给大家熟悉网络环境一个缓冲期。

不与业绩指标挂钩

据说很多团队的 BLOG 居然和 KPI 挂钩的,这是非常不适合的做法。很明显这会导致一个现象:到了接近考核的时候,团队每个成员都流水帐一样连发多篇文章凑数,对读者来说,是一种信息轰炸,起不到什么正面作用,对团队多数成员来说,也觉得这样圆满完成任务也不错嘛,势必影响真正用心写文章的成员。当然我相信很多人看了我这个帖子后会改变 KPI 的设置方式,比如”每月要发布几篇”… 简言之,本末倒置。

控制文章发布频率

团队 BLOG 管理员(没错,应该有个管理员)应该控制文章正式发布的频率。细水长流,尤佳。记住,节奏最有力量。

控制频率的另外一点是要做好长期性准备,不要几天热乎劲儿过去之后就乏于更新。如果潜在读者偶尔访问过来,发现最近一篇更新是一年前,或许就会留下负面印象。

不要强制团队成员

必须要认清的一件事情是,一个团队中,肯定有些人员的确不善于文字表达,如果要他写一篇文章,可能比杀了他还更难受。如果强制性的压着他憋文章,恐怕只能适得其反。好的方式是发起者能够引导团队成员中的那些低调者,使他觉得这事情有意思,可以尝试一下,能够更多锻炼自己。比如针对技术人员来说,写文章过程中如果熟悉一下 HTML 基本语法,在日常工作中也不无裨益。

不要堆砌垃圾文章

这里面的一条铁律是:不要转贴那些网上随处可见的”心得”,”感悟”之类的心灵鸡汤文章,那些文章不能改变外界对你团队的正面看法(当然有可能增加负面看法)。适当的转载关于自己团队或者公司的第三方文章是可以接受的。

记住,垃圾信息和网站质量成反比的。信息不是越多越好。

内容格式非常重要

内容是团队向外展示的载体,固然重要,可如果文章不经过很好的格式化,就好比一块好田地长满了庄稼也同样长满野草一样让人讨厌。这是如此简单的一点,但我们还是能看到有许多团队对此熟视无睹。一篇连段落都不分的技术文章内容再好,也不会有更多技术人喜欢看。

不但 Web 页面要注重格式化,对 RSS 输出也同样也要注意,甚至应该更加以重视。至于输出全文,那是必须的。团队 BLOG 不要在乎什么 PV 之类的事情,那是非常土鳖的做法。内容是否有价值,不在于有多少人看了这篇文章,而是有多少目标读者从中得到收益。

–待续-

此文作者:, 位于 Web 分类 标签: , , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.