作者文章: Fenng

桌面工具向 Web 应用的跃迁

“跃迁”这个词借鉴自阿西莫夫的机器人系列故事。类似一个世界向另一个世界的瞬间移动，具体怎么移动的，阿西莫夫一语带过，类似古龙的小李飞刀，如何之快你也不知道–扯远了，扯回来：最近越来越觉得(我实在有些后知后觉)桌面工具与客户端工具被淘汰的趋势已经不可逆转，用户习惯慢慢转向并会习惯 Web 应用。

举几个例子：

Outlook –> Gmail
Booksmarks–>del.icio.us
FeedDemon / GreatNews–>Google Reader
MS Office –> Zoho Suite / Google Docs
Media Player –> YouTube

这个名单还可以拉得很长。把计算能力和存储能力交给“大计算机”来做，而浏览器(或提供同样功能的软件)作为 “元(Meta)工具” 将会长时间存在。

用户习惯一旦发生改变，再想逆转怕是不现实的事情。上大学的时候，没事的时候就去电脑城买 D 版软件光盘，那时候信息的载体很大一部分是通过 CD 走的，现在，还会有大学生去买电脑城的盗版软件么? 或许有，但会极少。单机版游戏盛行的时候，网络游戏虽然也有(如 Mud)，但毕竟是小众，现在呢，守着单机版游戏的玩家怕是太少了。这个“迁移”一旦发生，几乎就不可能有回头路。当初有多少 FeedDemon D 版的死忠用户，可现在习惯了 Google Reader 的我们即使 FeedDemon 免费了也不愿意再次使用它了。

记得有段时间在讨论 Web OS ，可能是长时间没见到比较接近的产品，大家的兴趣又减退了。或许将来，世界只需要五台超级计算机。一旦我们把习惯切换过去，还会再回来么?

微软的 Live.Com 没什么起色，而 Google 在这方面已经走的很远了。绕来绕去，好像又绕到 SaaS 上去了，但其实我没扯那么远。

–EOF–

上苍保佑回家的人们

昨天在家看了《盲井》，就像期待的那样沉重。今天想想，回味出来两个字：”回家“。

互联网传来的消息也只有两个字：雪灾。根深蒂固的家的传统观念…一年一度的人口大迁徙偏偏碰上这五十年(百年)不遇的雪灾…年，这个中国人永远摆脱不了的节日啊

上苍保佑! 上苍保佑回家的人们

–EOF–

Yupoo! 的网站技术架构

又有机会爆料国内 Web 2.0 网站的架构了。这次是 Yupoo! 。非正式的采访了一下 Yupoo!(又拍网) 的创建人之一的阿华（沈志华）同学，了解了一些小道消息。

作为国内最大的图片服务提供商之一，Yupoo! 的 Alexa 排名大约在 5300 左右。同时收集到的一些数据如下：

带宽：4000M/S (参考)
服务器数量：60 台左右
Web服务器：Lighttpd, Apache, nginx
应用服务器：Tomcat
其他：Python, Java, MogileFS 、ImageMagick 等

首先看一下网站的架构图：

该架构图给出了很好的概览(点击可以查看在 Yupoo！上的大图和原图，请注意该图版权信息)。

关于 Squid 与 Tomcat

Squid 与 Tomcat 似乎在 Web 2.0 站点的架构中较少看到。我首先是对 Squid 有点疑问，对此阿华的解释是”目前暂时还没找到效率比 Squid 高的缓存系统，原来命中率的确很差，后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去，所以命中率彻底提高了”

对于应用服务器层的 Tomcat，现在 Yupoo! 技术人员也在逐渐用其他轻量级的东西替代，而 YPWS/YPFS 现在已经用 Python 进行开发了。

名次解释：

YPWS–Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器，提供基本的 Web 服务外，可以增加针对用户、图片、外链网站显示的逻辑判断，可以安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。
YPFS–Yupoo File System 与 YPWS 类似，YPFS 也是基于这个 Web 服务器上开发的图片上传服务器。

【Updated: 有网友留言质疑 Python 的效率，Yupoo 老大刘平阳在 del.icio.us 上写到 “YPWS用Python自己写的，每台机器每秒可以处理294个请求, 现在压力几乎都在10％以下”】

图片处理层

接下来的 Image Process Server 负责处理用户上传的图片。使用的软件包也是 ImageMagick，在上次存储升级的同时，对于锐化的比率也调整过了(我个人感觉，效果的确好了很多)。”Magickd“ 是图像处理的一个远程接口服务，可以安装在任何有空闲 CPU资源的机器上，类似 Memcached的服务方式。

我们知道 Flickr 的缩略图功能原来是用 ImageMagick 软件包的，后来被雅虎收购后出于版权原因而不用了（?）；EXIF 与 IPTC Flicke 是用 Perl 抽取的，我是非常建议 Yupoo! 针对 EXIF 做些文章，这也是潜在产生受益的一个重点。

图片存储层

原来 Yupoo! 的存储采用了磁盘阵列柜，基于 NFS 方式的，随着数据量的增大，”Yupoo! 开发部从07年6月份就开始着手研究一套大容量的、能满足 Yupoo! 今后发展需要的、安全可靠的存储系统“，看来 Yupoo! 系统比较有信心，也是满怀期待的，毕竟这要支撑以 TB 计算的海量图片的存储和管理。我们知道，一张图片除了原图外，还有不同尺寸的，这些图片统一存储在 MogileFS 中。

对于其他部分，常见的 Web 2.0 网站必须软件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面采用不少相对比较成熟的开源软件，一方面也在自行开发定制适合自己的架构组件。这也是一个 Web 2.0 公司所必需要走的一个途径。

非常感谢一下 Yupoo! 阿华对于技术信息的分享，技术是共通的。下一个能爆料是哪家?

–EOF–

AIX 上配置 rsync 简记

前提: OpenSSH 配置完毕。并且，目标端到源端通过 SSH 登录无需提示密码验证. (参见我以前的也是关于 rsync 的废话)

下载 AIX 5L Expansion Pack CD 中的 rsync，这个版本稍微有点低。其实也足够了，不过如果和更高版本混用的话，会报告另外一个错误：

sync: connection unexpectedly closed (24 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) ...

在 AIX 上 rsync 需要依赖 Popt–A C library for parsing command line parameters，通过 rpm 命令安装即可. 现在的 AIX 系统默认应该就有安装 rpm （AIX-rpm) 工具包的.

在维基百科上有对 rsync 算法的介绍。简单的理解是这么回事：待传送的文件被分成若干定长的文件段，然后对每个文件段做个 “Rolling Checksum”，加上一个强 MD4 校验码, 传送这些信息给接收方, 接收方查找本地类似文件–定长的每个文件段, 对比 Rolling Checksum 与 MD4, 然后传送差异(Delta)数据.

rsync 1996 年才被搞出来，最初是用来对付在低速网络连接上传送差异化文件的。

我一直比较好奇的是 Oracle 的 Data Guard 用什么算法保证所有的归档能无差错传送到远地(?)。

–EOF–