首页


1 2 3 4 5 6 (Page 5 of 6)



November 11, 2007

财帮子(caibangzi.com)网站架构

财帮子(caibangzi.com) 定位在”基金理财社区"。是国内访问量最大的基于 Ruby on rails 的 startup 项目。“理财”这个词据说是光大银行发明的,且不去管,不可否认的是,目前国内"理财"是个很有潜力的切入点。财帮子网站潜在用户群还是很大的。

1.创建人员

创建者有三人。Robin Lu(石锅拌饭)Meng Yan ( 孟岩 ) ,还有一位"不写Blog的家伙"。前两位都是技术人员。很早就看过孟岩 的 Blog,那时候他还在 Sun。Robin Lu 的 Blog 也一直在我的订阅列表中的,所以财帮子刚成立我就知道的。倒没有细问第三位是技术人员还是负责商务。(Updated: Robin Lu留言说”财帮子那位不写blog的创建者也是工程师,叫赵路,曾经是 Mozilla 项目accessibility模块的module peer."

2.服务器信息

Web 服务器用的是 Lighttpd ,出于节省成本的目的,服务器是自行组装的。数据库采用的是 MySQL 5,目前还没有使用 Replication. 正准备扩充服务器,服务器数量...暂且保密一下。

3.统计分析及监控

统计分析采用 Google Analytics 和 Awstats 。目前 Alexa 排名是 2 万一点。监控工具用 monit,"以及自己写的一些分析 Proc 的脚本",再有就是 Unix 性能工具等。(Fenng: 服务器处于规模化之前基本上要这个样子)。

4.优化之路

Robbin 在此前的一篇 财帮子性能优化简报披露:“财帮子两个星期以前,遇到严重的性能问题,最终我们采用了相当非主流的部署方案和打了自己补丁的web server,成功度过了难关”,我很好奇这具体是个什么问题。得到的答案是:“Apache的负载均衡是有问题的,算法太简单了,对Ror的应用来说,会造成某一个app instance的阻塞,从而阻塞了所有的request”。

谈及 Cache 的感慨:

Fenng: ... 我个人感觉你们需要Cache服务器, 这一类的站点内容需要 Cache 的太多
Meng Yan: ...Web 2.0网站的 cache 非常重要。我们从Mem的cache,到disk的cache,
再到数据库的cache,架构还不错,否则当前机器撑不住 :)
Fenng: 很多站点扩展作不好,也是Cache没用好
Meng Yan: 是啊,Cache非常重要,非常非常
Fenng: 豆瓣的阿北说他们 Memcached 用的非常爽,命中率非常之高
Meng Yan: 确实,我们的内存cache就是用的memcached,真的很棒

5.挑战

这是就这次采访的最后一个问题。
Fenng:还要采访你一个问题:caibangzi.com 现在运营、开发面临的最大的一个问题是什么? 
Meng Yan:目前可能我们遇到最多的是合作、商务上的事情。真正开发、运营上来说对我们的挑战还不大。

6.后记

这次采访(如果可以说这是采访的话)非常顺利。财帮子从三月底上线,到现在已经积累了一定数量的用户,当然不是十全十美的(我个人就感觉应该提供更多的RSS输出才是,不要太在乎站点流量,流量本身也是开销),网站也还有很长的路要走。真诚希望财帮子能成为更多人的理财工具(至少我已经开始用了)。

这是我第一次写国内 Web 2.0 网站架构技术。感谢 Meng Yan 提供的第一手信息。关于网站架构,我在这个 Blog 上写过不少国外的站点分析。一直想采访一些国内的 Web 2.0 站点并且能披露点技术信息,相对来说,国内站点还是比较保守,各自闷头折腾。为什么不换个角度,分享、借鉴、壮大,这个方式不也不错麽?

BTW: 如果你有 Web 2.0 站点技术信息要报料,联系我!(要写软文就免了)。

--EOF--

November 7, 2007

eBay 的数据层扩展经验

对于 eBay ,我盲人摸象一样写了好几篇 Blog ,暂列一下:

今天又重新读了一下这篇《The eBay Architecture --Striking a balance between site stablility, feature velocity, performance, and cost》,觉得数据层的扩展经验也很有意思。

通过功能划分不同数据库,然后根据主要访问路径水平分割数据库。这句话太空了,类似 MySQL DB 大家常采用的 Shard 思路。

减小 DB 资源开销

数据库上没有业务逻辑。这包括:不用存储过程; 只有少量比较简单的触发器。 把CPU 开销比较高的工作迁移到应用上。这包扩:参考完整性检查(嗯,检查一下你的 DB 是否再用外键? ); 连接(Join), 排序。
应用服务器尽量 Prepared 语句以及绑定变量的广泛使用。

最小化 DB 事务

自动提交(Commit)大多数主要的数据库写操作。 客户端绝对没有事务(业务逻辑) 。这包括: 单个数据库通过匿名 PL/SQL 块进行事务管理; 没有分布式事务。对于"事务", 相关信息可以从 eBay 首席架构师 Dan Pritchett 的访谈得到确认。没有事务更没有分布式事务这一点比较关键,这也是因为 eBay 的商业逻辑天然性质(否则也不容易做),所以可以做到 Scale Out,而最近了解到 Paypal 则因为交易逻辑比较复杂,只能是 Scale Up. Paypal 的技术信息一向比较封闭,谁能告诉我一点额外的信息呢?

--EOF--

November 5, 2007

Twitter 的架构扩展: 100 倍性能提升

Twitter 是我最近一段时间用的最多的网络服务之一.还记得刚开始有段时间发消息速度那叫一个慢. 难得的是 Twitter 的开发者在用户激增的情况下性能提升的不错, 据说,相比当初有 100 倍的性能提升, 那我们就来看看他们都做了什么.(发现我这个 Blog 快成了 High Scalability 的中文镜像站了.)

是否真的是 100 倍性能提升, 大可不必较真, 但 Twitter 的一些经验是足以借鉴的.

Ruby on rails

似乎 Twitter 是用 RoR 开发的流量最大的站点(有待于求证). 开始使用DRb ("Distributed Ruby".), 该库可以通过 TCP/IP 从远程 Ruby 对象发送接收消息, 其缺点是不那么好用,并且没有冗余, 于是转向 Rinda , Rinda 基于 DRb 开发, 使用简单. Twitter 也证明了 Ror 应用同样可以支撑比较繁忙的站点, 工具没有对于错,关键是否能运用好.

twitter_drb.png

图片来源. (这里面我非常疑惑的一点是据说只有两台DB(Master/Slave),可要支撑这么大的并发更新似乎有些难度.)

ETag

Twitter 对于Etag 的态度让不少人疑惑. 这恰恰是因技术制宜的一个体现, 因为 Etag 不是万能药. 另外一点比较重要的原因是 Twitter 有超过 90% 的流量来自 API, 而 多数 API 客户端不支持 Etag.

数据库方面的经验

尽可能的索引(Fenng补充:不要过度索引). 因为 RoR 应用的特殊性, 索引是在代码中向 DB 提交的. 另外一个值得议题的是, 反范式. 严格遵守范式是要吃苦头的.建立可行的测试方法,明确的知道你的SQL都在用什么方式运行.(另外,我有个疑问是 rails 不支持 2 阶段提交的吧?)

避免资源过度被占用

哪个站点都不避免的有"水葫芦用户",对于这样的 Spam 类型用户, 肯定会影响原有的应用处理资源. 该处理就要处理掉. 另一个方面,对于间歇性占用系统资源过多的进程用 Monit 处理.

另外一个很重要的环节是 Cache, 不废话了,没有好的Cache机制怕这样的站点不会成功的. (建议阅读车东辛苦翻译的这篇面向站长和网站管理员的Web缓存加速指南[翻译]). Twitter 运营的一个可取之处是能够积极听取社区的意见并改进, 同时社区上也有很多用户给他们提供了不少技术支持. 这也是开放而带来的好处吧.

--EOF--

October 9, 2007

Digg 网站架构

digg-ready.gif

本篇描述一下 Digg 的网站架构.

国庆期间又收集了一些关于网站架构的信息。一直没有进行系统的整理。越来越发现其实都是自我重复的劳动,后续的信息都是嚼别人剩下的甘蔗。--by Fenng

Digg 工程师采用 LAMP (Linux, Apache, MySQL and PHP) 模式。这个 Alexa 排名在 100 左右的、自我估价 1.5 亿美金的站点目前有超过 100 台的 PC 服务器(足够少了),可以粗略分成三个部分:数据库服务器,Web 服务器,搜索服务器。

数据库方面,和其他成功的 Web 2.0 站点一样,也是 MySQL,不过 Digg 稍微"激进"一点,用 MySQL 5,而且号称从 MySQL 4 升级到 5 性能没有什么影响。 OLTP 应用用 InnoDB 引擎, OLAP 用 MyISAM。后端数据库的读比例达到 98%,写只有 2%,实际的读写比例应该高于这个数字,这应该是 Digg 在前端用 Memcached 以及 APC PHP accelerator / MCache 做缓存后的效果。在 IO 上似乎压力并不大。

数据库分割用 Sharding (分片)的机制。从透露出来的信息看,Digg 数据量并不大,仅仅刚超 30g . 看起来是只存储了一些元数据。至于这个 Sharding 或者 Shard, 其出发点有些类似于数据库的分区,差别可能就是不再一个库上吧,其实都是结合业务和应用来对一些数据对象进行分割。

搜索服务器用的是 Lucene

进一步阅读:

--EOF--

1 2 3 4 5 6 (Page 5 of 6)