关于"大型"网站的架构问题

常在有大网站牛人参与的文章/会议/多人交流中,提到的大字都是用x百万用户,y千万pv来评估是否是"大网站",但是这些数字真的是衡量程序的架构是否能承载这么"大"的网站的数据么?以我的经验,答案只能是仅仅可以作为17%左右的参考依据

以基于.net和windows server架构的网站,做架构时需要以数据来支撑:

1. 每秒可以处理多少请求(与cpu个数的一个正比关系)
2. 处理每个请求的平均时间
3. 最大每秒请求用户数
4. 每时段用户访问量/并发量
5. 每时段用户访问的url

从这5点出发,再去考虑架构的问题,从经验上来讲,我觉得是最科学的.

第1点和第2点,可以直观的看出目前系统的吞吐量,知道了当前系统处理问题的快慢,就能意识到我未来6个月的架构和性能要求.第3点和第4点可以看到系统崩溃边缘的场景,看到悬崖了,总归会安全一些,至少心里有数了.第5点,就可以清晰的看到自己的哪些业务逻辑是消耗性能的最大杀手,然后挑个大的整治. 基于这5点,那么要求有一个至少能记录到5分钟间隔时间点的数据的工具集,比如cacti+perfcon+IIS Log就能基本完成要求了.

看似很简单的吧?但是这需要超强的对整体网站的业务理解.所以架构师应该看到应用和项目两种架构,这个怎么理解,说到最普通的,3点就可以基本概括:

1. 最小化/最简单化功能单元
2. 异步!
3. 避免分布式事务

OK. 说完了,更简单了. 我只所以崇尚简单,是因为我做过一件很疯狂的事,我曾经费劲想法去折腾GC,我把一些东东pin住,让GC少干活.费了N多的劲,CPU确实下来了,但没下来多少,4天后的早上,我开始拆解了这个功能,又恢复了以前,继续让GC去跑,原因就是我虽然不觉得自己技术上牛逼,但是我想当我离开这公司以后,应该很少有人能理解我为什么做,为什么这样做能有收益,我甚至在自恋的怀疑接替我工作的大牛们是否理解pinned object.为了不让其他人抓狂/熬夜/吃不下饭/睡不好觉/骂娘所以用最简单的方式去实现.

最后,3个重点问题:

1. 简单化不是说砍掉功能,而是去思考如何简化业务模型
2. 实验说话,不能人云亦云,更不要意淫.如果你担心你的iis支撑不了800 requests/sec,就去做个实验. 很多人都跟我说过很普通的PC server确实做不到的,windows server/iis/.net都有问题,后来我做了多次试验,然后不断改进,最高支撑到860,只所以没能测到更高,是因为在生产环境下实在是没有那么频繁的用户访问了.
3.测试环境下我没有继续压,是因为:如果一个网站每秒有800次访问,那这个网站应该可以买的起4-6台稍微好一点的pc server了,那么用户访问量还要朝着更高的目标做,单纯去挑战技术上的极限,对老板对企业是不合情理的,这是当老婆和做情妇的区别,撒娇的事儿不能总干.

做.net的人最最最最容易产生的误区:

1. 内存占用高,接受不了. 如果不是memory leak,你怕啥? 32bit支持2G的进程内存分配,一个asp.net的website,内存占用才700MB,你怕啥?
2. CPU高了,接受不了. 想方设法的把cpu降到最低,然后再想方设法的提高cpu占用率,程序不就跑的更快了么? 闲置资源都是浪费.
3. 以上两点,你可以有一个理由来作为浪费资源的充要条件:降低开发成本.你给老板省的钱多还是老板用网站经营赚的钱快?

今晚早睡觉...QCon上没有.net领域的网站架构的session,有点失落,毕竟.net可以做到