修正版 疯狂代码 写给WEB2.0的站长

    当互联网吵吵嚷嚷的进入2.0时代,当互联网的技术不再是那么高不可攀,当复制变成家常便饭,互联网热闹起来了

    myspace火了,中国冒出更多的myspace

    youtube刚刚起来,中国的视频网站就遍地开花

    51拔地而起,中国出了无数的SNS

    facebook则改变了中国站长的抄袭方式,不再学chianren了,校内火了
    ..........

    当抄袭变成习惯,我想说的是,模仿,站长,你准备好了吗?

    如果你打算做垃圾站,或者赚点广告费的网站,请不要点击这篇文章,我从技术角度方面谈谈WEB2.0网站的模仿问题。

    当投资和流量都不是问题的时候,我想说的是,您真的一帆风顺吗?

    拿SNS网站来说,当匆匆上线的2.0,当一笔笔投资砸进去的时候,当流量上去的时候,您的困惑在什么地方?

    我做过多个2.0公司的技术顾问,简单的谈谈2.0公司遇到的问题(涉及隐私,我用A B C D代替),这里就不再赘述大家众所周知的页面静态化,缓存和代码安全等问题了,有点技术的2.0公司的CTO都知道这些东西,我们谈点发展之后的问题

A公司

   A公司做的是SNS网站,程序是两个毛头小伙子做的,目标直指51,程序开发是一帆风顺,功能也比51牛多了,推广也是一帆风顺(A公司有自己独到的推广方式。但是当ALEXA到2W的时候问题出来了,每天下午4点左右,网站速度慢的惊人,基本上打不开,公司三台服务器CPU100%,让人郁闷的是公司的网络配置方式,居然是双WEB的集群,而单独一台DB数据库。整个瓶颈在数据库,于是我建议做DB的集群,分析了一下数据结构,MD,典型的WEB程序员的作品,没有一点数据库设计规范,功能实现是可以,如果要扩展,不可能,集群基本上是不可能的,怎么办?不能办,于是,一个月的时间修改程序,数据结构基本上换了一遍 前期砸进去的几十万打了水飘,用户走光了。

    结论:WEB2.0前期设计的时候不应该只考虑功能,应该认真考虑一下底层和数据结构了。

B公司

   B公司也是做的SNS网站,程序是3个人开发的,CEO是某名牌大学的经济学硕士,有点知己网的味道,又有一些特色出来,说实话,公司的潜力不错,CEO有很强的运作能力,感觉前景不错。系统架构还行,但是---但是系统崩溃了,why?系统没有考虑到用户有个海量的说法,文件也有个海量的说法,用户的相册,图片全部存贮在WEB服务器的一个分区上,每个用户一个目录,而打开性能监视器,磁盘的IO高的惊人,基本上无暇响应。众所周知,文件系统也是一个数据库,单独大文件无所谓,关键是整个是300多个G的零碎文件,大量的读写操作,系统崩溃,数据丢失,文件系统的一个链断了,用户数据全部丢失!!!Raid并不能解决所有问题,磁盘阵列只能保证在硬盘损坏的时候进行恢复,但是这个是文件系统的损坏,raid不能恢复。这是一个非常沉重的问题,系统整整停了一个月来做数据恢复(单独文件很容易,但是海量文件目前还没有一个软件能组织起来软件架构,数据恢复软件一般在建立目录结构索引的时候就已经死掉了,尝试过用16G内存的服务器做恢复,无效)。解决方案:修改程序架构,做分布式文件存贮(程序修改用了8天,但是文件转移却又用去了将近一个月),20万用户损失殆尽。

    结论:WEB2.0前期的设计应该有应付海量存贮的考虑,整个涉及了程序架构的修改,前期规划不好的话基本上思路一条。

C公司

   C公司是一个值得尊敬的公司,CEO技术出身,和比尔盖茨一样,大学未毕业出来做网络,01到03年做短信狠赚了一笔,后来做的小项目也小有所成,说实话,我很佩服。公司做的是校友方面,但是更偏重myspace风格,注重个人主页,推广方面也下了大手笔。系统崩溃的原因其实很简单,由于采用的是微软的SqlServer,而微软的MSDN直接就告诉了我们,SQLSERVER不支持负载集群,只支持灾难恢复的集群,他们的数据库超负载,100%就没有下去过,只能横向增加配置,采用了4路4核CPU系统,但是系统还是崩溃了... 高互动注定了高负载。解决方案:现从基本入手,解决掉几个程序耗能大户,对数据库采用横向切割,将用户每10万进行分组,同时对数据库系统进行散列,将多个表垂直分割,同时进行文件分组,解决问题. 因为修改了数据结构,程序也基本上大动了一下。 好在系统没有出大错,损失不算很大,不过对用户体验造成了很坏的影响。

it知识库修正版 疯狂代码 写给WEB2.0的站长,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。