五千年(敝帚自珍)

主题:【原创】wikipedia架构学习笔记(一)他们的骄傲 -- 羽羊

共:💬62 🌺262
全看分页树展 · 主题 跟帖
家园 【原创】外一篇:闲话37signals,rails及其他

web该怎么做?怎么运营?

写wikipedia架构这篇文章的过程中,脑子里总是想着37signals这个公司,这一家公司和wikimedia基金会简直就是两个极端,前者致力于知识传播、和谐社会、世界和平,37signals从一开始就钻到钱眼儿里头坚决不出来(Free is bull****,What's so good about free ? I don't get that,Having 4 million users use your free thing doesn't mean anything. If you charged $1,,you'd probably lose almost all of them,so is it any good at all ?——Jason fried) ,酷吧,让小羊想起了微软关于“用户/客户”的八卦。但是人家赚钱,在geek们看来,却是很少铜臭味道,并且怎么着都透出一股子特立独行的味道,作产品,做出ruby on rails一炮而红,卖服务,捎带着写出一本《getting real》,吸引无数startup.com追捧,公开个人形象都好像美剧剧照——精心装扮、味道十足,西装领带站人家跟前那真是不好意思打招呼,明星人物DHH更是青年才俊,一时风流无限。你说都是做生意,这差距,唉~~~

点看全图

外链图片需谨慎,可能会被源头改

说实话,真不知道该怎么说37signals的架构,和wikipedia不同,wikipedia架构庞大精细严整,透出一股大巧若拙的正规军味道,37signals就显得有些向剑走偏锋的土包子了,跟wikipedia比,真没什么好谈的了。

37signals的王牌产品bashcamp,用rails写成,关于rails,开发的速度毋庸置疑,而性能和伸缩性则一直是非不断,例如和twitter之间那些扯不清的口水官司,至于DHH本人,对于系统架构的看法,颇有些另类:

On the application side and web side, we scale them horizontally. If we want more capacity, we add more application servers, more mongrels, more web servers, etc. On the database side, we're scaling up. We just bought a even bigger box to handle the database for BaseCamp.

Basecamp is a pretty big application, have a lot of customers, a lot of usage, but we don't even need to shard yet. As technology moves on, hardware gets cheaper and cheaper. In my mind, you don't want to shard unless you positively have to, sort of a last resort approach.

DHH访谈

听其言,观其行,再结合rails一些特点:

1、默认适用cookie维持状态,share nothing的一个重要条件。

2、部署推荐fast cgi 或者 mongel cluster,天生适合横向扩展。

3、active record拼装出的SQL, 有些故意的引发N+1问题。

4、多数据库支持,rails核心没有,想要的自己找plugin。

基本上脉络比较清楚了:

1、比较重视程序本身横向扩展的潜力,由于rails框架某种程度上强制程序实现了share nothing架构,所以在加入应用服务器的时候,程序本身不会构成障碍。

2、部署方式无论单台server还是cluster,都是一样的,甚至虚拟机,无非是改改配置文件,加入一个节点就得。

以上两条,决定架构在应用层面都很容易一路横向复制下去,所以rails社区甚至对于ruby本身性能的不满都能容忍下来,反正性能不够,机器来凑。

3、默认ROM拼装出来的SQL都简单至极,从sqlite到oracle都有很好的适应能力,数据量上去了,换更好的dbms都不太用改代码。

4、对于多数据库是漠视的,这样想玩儿shard就比较有难度了。

DBA为什么能拿高薪?sql语句优化,数据库性能调优,shard的维护和管理这些都得拿钱买。rails生成的sql语句基本上都能用的上主键索引,而且语句极其简单,老实说,看不出什么能优化的地方了,如果效率低下了,要么dbms级别太低,要么服务器性能太差,这两条问题都可以很方便的定位,DHH的看法是于其花钱雇人,不如花钱升级服务器,赤裸裸的资本家思维阿。

综上,多么简洁明了的架构阿:

前端nginx或者haproxy或者apache作负载均衡,请求分发到数个分布在N台服务器上的ruby进程或者mongrel服务,然后统一访问一个big ass数据库服务器。

另外,截止07年的数据,5.9 T 用户上传的数据,888 GB 上传文件 (900,000 请求),2 TB 文件下载 (8,500,000 请求),到今天应该更多了,37signals更绝,连买硬盘租带宽的钱都抠,人家直接扔到amazon的s3上头去了。最新的消息,原先37signals用了xen做了一部分虚拟化,前些日子人家做了个实验,比较下面两幅图:

点看全图

外链图片需谨慎,可能会被源头改

点看全图

外链图片需谨慎,可能会被源头改

看起来还是硬碰硬踏实,虚拟化堪忧。

总而言之,这帮家伙真没在性能上费神太多,至少比不上wikipedia花的精力,人家的态度太明确了,挣钱——然后砸钱——然后解决性能问题。

他们的架构师是谁?分明是intel和amd阿。


本帖一共被 1 帖 引用 (帖内工具实现)
全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河