网站运营 | 站长学院 | 技术文档 | 成语 | 歇后语 | 桌面壁纸 | 帝国时代 | 代码收藏 | IP地址查询 | 生活百科 | 生日密码 | CSS压缩 | 用户评论

写给WEB2.0的站长 不仅仅是泼冷水

【 网络作者:佚名 更新时间:2008-01-01 | 字体:
[导读]当互联网吵吵嚷嚷的进入2.0时代<,当互联网的技术不再是那么高不可攀<,当复制变成家常便饭,互联网热闹起来了 myspace火了<,中国冒出更多的myspace youtube刚刚起来<,中国的视频网站就遍地开花 51拔地而起,中国出了无...

    当互联网吵吵嚷嚷的进入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的零碎文件,大量的读写操作,系统崩溃,数据丢失<,文件系统的一个链断了<<,用户数据全部丢失?<<。<

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

C公司

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

    结论:WEB2.0前期设计应该有良好的散列考虑,程序应该能有配合的扩充性,符合数据库的扩充

D公司

    D公司是一个各个方面做的比较好的公司<<,做了CDN加速,图片也独立分出了N个服务器<,数据库不错的一个<<<,(CTO是个数据库专家)<,系统崩溃的原因在于WEB<,按道理说WEB很容易做集群的,但是发现集群并解决不掉问题,他们的集群只允许做4台的WEB集群<,但是4台都当掉了<。仔细分析,找到原因<,我估计整个也是大部分CTO最容易犯的一个错误<<,或者说他们根本就想不到的问题,就是WEB上传的问题,上传的时候由于时间的原因,线程是保持链接的<,300个线程就可以把一个WEB Server当掉了。解决方案:这个最简单<<,把上传和其他耗能大户分离出独立出来。程序改动不是很大<,但是之前半个月速度满对用户体验的损失也不可小视。

    结论:没有什么结论了<,毕竟有海量访问经验的CTO不多,也就是那几个大站的。

    总结:不是泼冷水,模仿其实是很容易的,随便找几个WEB程序员就能做到<,并且很简单,速度可能还很高效,因为WEB2.0无非就是跟数据库打交道,会操作数据库就会做<。但是真正做大并不容易,因为能应付海量访问的程序并不简单,现在的程序员都太自命不凡<,其实真正有经验的并不多<,不要相信一个月薪5K--10K的程序员能给你多大的惊喜,能应付海量访问的程序员不是那个价格<。如果您想做2.0,想做大<,有几个个建议:

    一.找DBMS的专家设计好数据库,大部分程序员都不知道分区视图<<<,数据散列<<<,数据组的概念

    二.设计好程序架构(这个其实不难,有个高人指导就行了)<<,保持良好的扩展性,成本考虑可以找兼职的系统架构设计师做好系统架构<<,确定将来的发展瓶颈。

    三.考虑好文件存贮的问题<<。文件存贮的技术含量看起来很低,其实是很高的<<,可以考虑反向代理的方案。文件存贮出问题了,站点基本上就完蛋了<<<,不仅仅是RAID的问题和存贮服务器的问题<,不过道理倒是一点就破的

    四.中国国情考虑,这个最致命<,需要考虑电信和网通的问题,CDN并不能解决所有问题?;ザ缘亩鞑DN并不是很有效<。最关键的是,现有的双线机房遇到DDOS攻击基本上都会当掉<,原因很简单,双线机房都是私人机房,本身就不会有太高的带宽,随便攻击一下就可以D掉(顺带提一个笑话<,我知道一个双线机房的老总总共1G的带宽却买了4G的金盾墙,很简单800M的攻击就可以搞定)<。

    五.网络延迟的问题<,这是分布式系统必须要考虑的<,程序要能容忍0到100秒的数据延迟的功能,也就是同步的问题<。不要小看这几十秒<,问题很大的<,如果你的站点有交互式功能<<<,比如即时聊天,你可以想象一下是个什么结果<。对于即时聊天的东西,可以用反向代理来解决(成本较高)。但是对于留言和评论的影响不大<<<,但是如果系统为了健壮做了缓存和静态化的时候,这个东西可能就是灾难性的了<。

    六.分散你的程序,如果你没有太多的资金构筑动辄百万的服务器,建议把功能分散开来<,比如相册一台服务器<<,留言一台服务器

    七.看好你的程序员<,如果没有很好的激励措施的话你的程序员很容易写出敷衍性的代码,而这个可能就是将来的大患<<,程序架构定下来后要修改可能就要费牛劲了<<<。最好你的CTO能对你100%的衷心,100%的负责。

    八.文件同步的问题,这个问题可能你觉得没有必要,如果你看一下网通和电信的TTL就明白了<,同步要支持续传,并且不能是持续的,否则你的成本会高出N倍,不要期望能通过你的软件实现<<<,交给你的程序员吧<,把上面的话告诉他他就知道怎么做了<<。

    九.最狠的一个问题了,也是吃亏最大的问题,不管您跟网警的关系多好<,看好你的用户,审核好你的东西<,一被?;赡芫椭旅?<<<,本人就吃过N次亏<。

    十.最后,祝各位站长一番风顺<<,大展宏图。


来源:http://www.chinawobo.com/article/20071013/58493.shtml

友荐云推荐
  • 转载请注明来源:网站运营 网址:http://www.chinawobo.com/ 向您的朋友推荐此文章
  • 特别声明: 本站除部分特别声明禁止转载的专稿外的其他文章可以自由转载<,但请务必注明出处和原始作者<<。文章版权归文章原始作者所有。对于被本站转载文章的个人和网站,我们表示深深的谢意。如果本站转载的文章有版权问题请联系我们<,我们会尽快予以更正。
RSS订阅
  • QQ邮箱
  • 填写您的邮件地址,订阅我们的精彩内容:
更多
© 2014 网站运营 - T086.com(原itlearner.com)
微商货源 | 冠珠陶瓷 | 迪威乐云商devmsn | 易奇八字 | wwe美国职业摔角 | 八字算命 | 河南旅游景点大全 |
RunTime:8.83ms QueryTime:7