主题：【原创】wikipedia架构学习笔记（一）他们的骄傲 -- 羽羊
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本人，对于系统架构的看法，颇有些另类：
听其言，观其行，再结合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 帖 引用 (帖内工具实现)
- 相关回复 上下关系8
