Tag Archives: flickr

闲说 Yahoo 中国

深受网民喜爱的 Flickr 这两天被封掉了，不少网友愤怒之余，不知道是否有人产生这样的疑问:雅虎中国会不会把 Flickr 移植到国内来? Flickr 是个好产品，但想到 del.icio.us 的在国内的正宗克隆版: Yahoo! 收藏+ 的发展状况，几乎可以断言，Flickr 进入国内怕也不能有多大作为。

抛开其他的原因不谈，个人觉得雅虎中国(中国雅虎)现在的产品状况有些陷入”焦油坑”，尤其是在技术上，很难真正的施展拳脚。所作的一些产品还是依赖于美国的技术架构，尤其是底层的基础架构，举例来说，对于很多 Web 页面，用户发起的 URL 请求都必须要和美国的服务器发生 IO 交互。有这样的问题存在，无论 UE 工程师怎么在本地改进，都是无济于事的。近日有传言谷歌打算把服务器放到国内一部分，而雅虎中国可是早在 2005 年就把 2000余台服务器搬到了国内。这么久还藕断丝连，只能说已经太过于纠缠，没办法大刀阔斧的调整了。

在另一方面，域名的混乱程度我认为也导致了很多问题。域名是：yahoo.com.cn (跳转到 cn.yahoo.com , 服务大多是三级域名,相册是: gallery.i.cn.yahoo.com, 这么复杂的域名 100个人有 99 不能正确输入，四级域名的服务也有，’博客’, blog.i.cn.yahoo.com…), 搜索 yahoo.cn …… 我一直很好奇 Alexa 怎么正确统计雅虎中国的访问量 :)

雅虎最近的动作不可谓不多，比如新推出的 Omni-Search ，的确让人眼前一亮，可是看业界的反应，总有些怪怪的，对，就是不够轰动，没有神秘感。试想，如果是 Google 发布这样的产品，业界的反响会是怎样的?

对于一些除搜索外的其他老牌产品，比如电子邮件，现在越来越不够重视。我觉得电子邮件是一个很好的突破口，如果可以做到市场第一，为什么偏偏要跑到第二去呢? 电子邮件本身或许不赚钱，但是带来的相关收益可绝对不容忽视。远的不说，腾讯不也是 QQ 一个产品带活了一大片麽 ? 而现在，埋头做社区、SNS 那一套玩意儿，胜算不知几何。

BTW: Blog 首页最下方有文责声明.

–EOF–

学习 Flickr 的基于 LAMP 的容量规划经验

好久没怎么正式更新 Blog 了，快荒芜了，长满了 Spam 的荒草。

最近其实发现了不少可以和大家一起学习的好内容。Flickr 的 John Allspaw 在 MySQL Conf 2007 作了一个题为 Capacity planning for LAMP (下载PDF文件) 的技术报告，说起容量规划，多少有点空对空的意思，不过这个 PPT 还是介绍了不少 Flickr 的网站运维经验。

Flickr 的数据量的确越来越惊人了，根据文档中透漏的数据：

Squid Cache 中共有 3500 万张图片；
在 Squid RAM 中有 200 万张图片；
4.7亿的图片，每张图片有4到5种尺寸；
每秒钟 38000 个到 memcached 的请求;
2 PB 裸存储容量(周日需要消耗1.5T 的空间)

三个主要步骤：

计划

基于实际业务，而不是抽象的理论。John Allspaw 认为基准测试(Benchmark) 作用并不大，这一点我也很赞同。在业务频繁变化的环境中，Benchmark 根本不能与实际业务情况匹配。

部署

Flickr 使用SystemImager/SystemConfigurator(自动化安装、软件分发)，CVSup(网络中的文件分发、更新)，Subcon(配置管理工具)提高部署效率。

度量(图形化展现)

Flickr 使用了 Ganglia 来进行容量数据的展现。Ganglia 最初设计是用于高性能集群计算的监控上面，也是以 RRDTool 为基础来进行图形展示。Ganglia 最主要的优点还是管理的方便性: Client/Server 结构, 各自跑 Demon 进行数据交互(XML形式)。相比起来， Cacti + Collectd 需要进行很多手工配置，在面对大量需要监控的主机的时候的确不那么方便。

Web 2.0 站点的运维似乎大家都在摸索着走。期望这次阿里巴巴组织的侠客行大会上也有有朋友坐下来聊聊这个话题(Flickr 的架构师本来可以来的，因为时间的问题不能成行，挺遗憾的)。

–EOF–

Web 2.0 站点扩展性问题随感

最新一期《程序员》杂志上有篇《Web 2.0 构建要素》的文章，里面描述了一些 Web 2.0 的扩展性问题，这可能也是 Web 2.0 站点从小到大必须承受的苦恼。该文简单介绍了有些站点通过 Amazon S3 服务来解决存储扩展带来的压力。有些站点则必须自己动手构建最适合自身业务的技术方案。
很多比较成功的站点，有的时候会透露出一些关于站点扩展性的技术信息，像我收集的 Flickr 的开发者的 Web 应用优化技巧、Technorati 的后台数据库架构、Craigslist 的数据库架构等，往往是蜻蜓点水，看过之后让人心痒难当，可是更细节的东西又很难获取。尽管这些站点基本都是构建在 OpenSource 软件上，但这一点上看，似乎不够 Open ，唯一一个做的比较好的倒是要算 LiveJournal ，他们通过 Danga 站点贡献了几个经典的软件与一些很有参考价值的文档(如这篇对LiveJournal扩展性的介绍)，是为很多后起 Web 2.0 站点必备的参考信息。
在国内，很多 Web 2.0 站点也同样面临着这样的问题，象豆瓣，阿北还需要身兼 DBA, 而抓虾，虽然数据库已经有上亿级别的记录量，就上次我在北京和谌振宇聊天，感觉抓虾在扩展性上也是还有很多细节需要完善，在杭州，Yupoo 也因为日益增长的数据量而不得不着手考虑如何更为成功的实现分布式存储解决方案……
这些似乎表明，Web 2.0 站点扩展性问题越来越突出，已经成为制约 Web 2.0 发展的一个障碍，”多、快、好、省”的构建新型互联网应用，不知道正在让多少人犯愁。
在传统互联网领域，很多技术解决方案往往是软硬件厂商提出来，类似自上而下的推动，而 Web 2.0 站点变化太快，到现在为止，似乎只有 MySQL 一家公司是比较大的赢家，可是因为面对的客户情况各异，解决方案似乎无从说起(比较简略的实现案例倒是能找到几个)，再者，这些站点基本上是把 MySQL 这样的产品当作基本工具，和其他软硬件相互结合，然后在这个上面灵活构建出很多具有创新性的应用。这是一种自下而上的变化。
另一方便，Web 2.0 架构方面的人才还是稀缺，这个架构不是指某一方面(比如Java)的架构，而是整个产品环境的架构，象 Flickr 技术大牛 Cal Henderson 这样的人几乎是可遇不可求。操作系统、网络、数据库、开发语言每样都能那起来并且能够涉及足够灵活的技术方案，这要求，也的确高了一些。或许有人说，一个人不行，那么多几个人分别负责某几个环节不就成了? 这又带来另外一个问题：人力成本。
上一篇 Blog 我提到五月份的”侠客行“大会，我倒是希望能有一群网络技术人才能够就 “Web 站点可扩展性” 这个话题作一番探讨，每个站点如果都说说自己的心得，那么汇集在一起参考价值会对整个 Web 2.0 环境起到很大的促进作用。
最后，还拿 MySQL 说事儿，去年网志年会上，就有人感叹，国内 MySQL 好手太少了，考虑到物以稀为贵，有的 Oracle DBA 已经开始学习 MySQL 啦.
–EOF–

雅虎中国新品迭出，期待掌声

Yahoo! 中国这几天接连发布产品。昨天看到雅虎空间测试版上线。不少试用者的评价都是负面的，影响最大的应该是 Keso 的寥寥几语。其他人的评价也基本上是基于没有 Flickr 集成、没有 RSS 导入这些。我觉得这多少有点不公平的。Flickr 这个产品考虑到被 Yahoo! 收购的时间，应该不在雅虎中国可引入的范围内，自然不能汉化到中国来，而且雅虎空间是集成雅虎相册的，对国内很多普通用户来说，雅虎相册更为熟悉。至于 RSS 功能，现在没有不排除以后的版本中加进来，现在还是 Beta 版嘛。我这么说当然不是说雅虎中国没有缺点，我在使用的过程中第一个感觉是不够简洁，这个”简洁”不是指功能简单，而是说要让用户对一些功能一目了然，对一些提示不产生歧义，能够无障碍上手开玩。
今天雅虎中国正式发布了雅虎通网页版。其实我在中午的时候已经看到 CWR 在报道 Yahoo China Launches Ajax Web Messenger。这篇文章中提到了我的 Blog 名字，通过 egosurf 的机制几乎是第一时间看到的。这个产品因为时间问题，我还没有进行试用。
正如有人说的我们对Google 太不厚道了，对于雅虎中国在新产品上的努力，我倒是我觉得我们也有些太苛刻了。雅虎中国一直在进步，或许我们应该给雅虎中国、也给谷歌一些鼓励，给一些掌声!
BTW：个人观点，个人观点。
–EOF–
另外一个消息，微软准备支持 OpenID 了。