分享Sify.com的架构经验

来源:百度文库 编辑:神马文学网 时间:2024/04/28 06:43:24
  • Home
  • kafka0102的侧面照

分享Sify.com的架构经验

Posted in architecture on 五月 15th, 2010 by kafka0102

今天分享的网站架构来自于Sify.com Architecture - A Portal at 3900 Requests Per Second(该标题有标题党嫌疑),对英文熟稔并不屑于我的中文简述的可以跳过该文。Sify.com是印度的一家portal网站,应该是信息集成类网站。它给出的月pv是1.5亿次,每秒请求数是3900次(应该是针对所有服务的页面请求,包括异步的,并且是高峰的,否则就和pv对不上了)。按规模来说,算是个中等规模的网站,不过它的架构却是很值得说道的。

网站架构

1、为了节约机器资源并最大化利用机器资源,Sify.com也广泛采用了虚拟机。对于同一服务,Sify.com将其部署在多台机器上,使一台机器挂掉后仍有其他机器提供服务。对于冗余和负载均衡,目前Sify.com是将其做成配置手工修改,将来可能会自动化管理和扩展。对于运维来说,别说中小网站,就是一些大网站也没有做到自动化运维,很多还是收到报警后人肉解决。尽管自动化运维很酷,但从成本角度来说,大多中小网站不必追求这点,把监控做好,能在最快时间发现问题并解决问题就够了。

2、Sify.com的存储很特别,它没有使用通用的数据库,它的关系数据存在检索系统中,全文数据存在分布式文件系统中。这种围绕检索系统+kv文件系统的解决方案,我以前也读到过一篇文章。Sify.com的检索系统基于Solr,我最近也在看Solr,打算重做的检索系统也是基于Solr。Sify.com的查询会从检索系统检索出id,如果需要全文,再从文件系统(它用的是GFS,该GFS不是google的,而是一个开源的集群文件系统,我也不是很了解的说,感兴趣的可以访问http://sourceware.org/cluster/gfs/参观)取出全文内容。这个策略也是通常的检索系统处理策略。

3、Sify.com的提交操作采用异步处理模式,就是提交到ActiveMQ/Camel,然后分发到相应的服务处理。其中的Camel是开源的ESB实现,我也不甚了解。Sify.com各服务间似乎都是走HTTP协议,很有爱的表现。

展望未来

Sify.com提了一些愿景,我就不一一罗列,其中最吸引我的是,它打算采用Drools这个规则引擎做Cache失效处理。它提到Cache来源是Akamai和Varnish,所以失效的应该是来自CDN和本地的页面内容Cache。因为同一个URL请求可能会引起多个Cache项失效,而这种前端页面Cache失效让业务逻辑代码处理也不够友好,有个统一处理的系统在管理和操作上就方便很多。它的做法是,对于引起Cache失效的URL,将URL等信息打到日志中去,由Drools根据配置的规则来执行Cache失效策略。感觉上来说,还是很有意思的做法。

经验教训

Sify.com总结的经验都是和使用的软件的缺陷相关的,总结如下:

1、首先是ActiveMQ,把Sify.com搞得很狼狈。我目前对ActiveMQ只有初步的了解,也没什么发言权。它提到ActiveMQ的问题有两个:1)ActiveMQ耗尽socket资源的问题,尽管ActiveMQ5.0声称解决了,但Sify.com还是没看到效果,使得ActiveMQ需要不断重启,最后折中解决了,部署两台ActiveMQ,轮流切换,这解决方案真是够山寨的。2)它使用Topic订阅发布机制时有4个消费者,结果经常ActiveMQ会hang住数个小时,折中的解决是使用4个Queue代替(够囧),但运行还是不稳定,时有抛出异常或内存溢出的情况。按说ActiveMQ也够成熟了,也不知是真有问题还是Sify.com自己没用好。公司也有使用ActiveMQ,也打算有时间会对ActiveMQ和JMS做些深入的研究。

2、Solr的问题有3个:1)Solr有时会对请求没有响应或超时,就需要重启解决问题,这个可能我需要关注下。2)Solr对复杂查询(比如加NOT查询)处理慢,这个应该是lucene的问题了,只能尽可能规避,把复杂查询拆成多个简单查询后再合并处理。3)对实时检索的需求,目前Solr没有提供该功能,Sify.com打算采用LinkedIn的Zoie(有Solr plugin),不过因为Sify.com索引数据的主键是字母+数字组合,而Zoie的是数字的,需要Sify.com做些扩展工作。我前段时间也有专门对Zoie做了一些分析。

3、GFS锁问题造成GFS不能访问,显然是个很严重的臭虫,升级版本解决问题。

4、Sify.com使用Lighty和PHP合作的不是很愉快,说是PHP_FCGI不稳定,会使进程hang住CPU飚满,这个我没什么经验,也不发言。

总结

夜已深,睡意浓,到此为止。


=============================== 华丽的终止符 ================================