当互联网吵吵嚷嚷的进?.0时代Q当互联|的技术不再是那么高不可攀Q当复制变成家常侉KQ互联网热闹h?br />
myspace火了Q中国冒出更多的myspace
youtube刚刚hQ中国的视频|站遍地开?br />
51拔地而vQ中国出了无数的SNS
facebook则改变了中国站长的抄袭方式，不再学chianren了，校内火了
..........
当抄袭变成习惯，我想说的是，模仿Q站长，你准备好了吗Q?br />
如果你打做垃圾站，或者赚点广告费的网站，请不要点击这文章，我从技术角度方面谈谈WEB2.0|站的模仉K题?br />
当投资和量都不是问题的时候，我想说的是，您真的一帆风吗Q?br />
拿SNS|站来说Q当匆匆上线?.0Q当一W笔投资砸进ȝ时候，当流量上ȝ时候，您的困惑在什么地方？
我做q多?.0公司的技术顾问，单的谈谈2.0公司遇到的问?涉及隐私Q我用A B C D代替)Q这里就不再赘述大家众所周知的页面静态化Q缓存和代码安全{问题了Q有Ҏ术的2.0公司的CTO都知道这些东西，我们谈点发展之后的问?br />
A公司
A公司做的是SNS|站Q程序是两个毛头伙子做的，目标直指51Q程序开发是一帆风，功能也比51牛多了，推广也是一帆风（A公司有自q到的推广方式。但是当ALEXA?W的时候问题出来了Q每天下?点左叻I|站速度慢的惊hQ基本上打不开Q公怸台服务器CPU100%Q让人郁L是公司的|络配置方式Q居然是双WEB的集，而单独一台DB数据库。整个瓶颈在数据库，于是我徏议做DB的集，分析了一下数据结构，MDQ典型的WEBE序员的作品Q没有一Ҏ据库设计规范Q功能实现是可以Q如果要扩展Q不可能Q集基本上是不可能的，怎么办？不能办，于是Q一个月的时间修改程序，数据l构基本上换了一?前期砸进ȝ几十万打了水飘，用户走光了?br />
l论QWEB2.0前期设计的时候不应该只考虑功能Q应该认真考虑一下底层和数据l构了?br />
B公司
B公司也是做的SNS|站Q程序是3个h开发的QCEO是某名牌大学的经学士Q有点知q的味道，又有一些特色出来，说实话，公司的潜力不错，CEO有很强的q作能力Q感觉前景不错。系l架构还行，但是---但是pȝ崩溃了，why?pȝ没有考虑到用h个v量的说法Q文件也有个量的说法，用户的相册，囄全部存贮在WEB服务器的一个分ZQ每个用户一个目录，而打开性能监视器，盘的IO高的惊hQ基本上无暇响应。众所周知Q文件系l也是一个数据库Q单独大文g无所谓，关键是整个是300多个G的零文Ӟ大量的读写操作，pȝ崩溃Q数据丢失，文gpȝ的一个链断了Q用h据全部丢失！Q！Raidq不能解x有问题，盘阵列只能保证在硬盘损坏的时候进行恢复，但是q个是文件系l的损坏Qraid不能恢复。这是一个非常沉重的问题Q系l整整停了一个月来做数据恢复Q单独文件很ҎQ但是v量文件目前还没有一个Y件能l织h软g架构Q数据恢复Y件一般在建立目录l构索引的时候就已经L了，试q用16G内存的服务器做恢复，无效Q。解x案：修改E序架构Q做分布式文件存贮（E序修改用了8天，但是文g转移却又用去了将q一个月Q，20万用h失殆?像这U?http://www.bt285.cn bt下蝲
l论QWEB2.0前期的设计应该有应付量存贮的考虑Q整个涉及了E序架构的修改，前期规划不好的话基本上思\一条?br />
C公司
C公司是一个值得敬的公司，CEO技术出w，和比盖茨一P大学未毕业出来做|络Q?1?3q做短信狠赚了一W，后来做的项目也有所成，说实话，我很佩服。公司做的是校友斚wQ但是更偏重myspace风格Q注重个Z，推广斚w也下了大手笔。系l崩溃的原因其实很简单，׃采用的是微Y的SqlServerQ而微软的MSDN直接告诉了我们QSQLSERVER不支持负载集，只支持灾难恢复的集群Q他们的数据库超负蝲Q?00%没有下去过Q只能横向增加配|，采用??核CPUpȝQ但是系l还是崩溃了... 高互动注定了高负载。解x案： C基本入手Q解x几个E序耗能大户Q对数据库采用横向切Ԍ用h10万进行分l，同时Ҏ据库pȝq行散列Q将多个表垂直分Ԍ同时q行文g分组 Q解决问? 因ؓ修改了数据结构，E序也基本上大动了一下?好在pȝ没有出大错，损失不算很大Q不q对用户体验造成了很坏的影响?br />
附注QSqlServer其实是可以实现集的Q一般是通过复制和分发的形式实现Q但是应用程序需要对数据库操作进行分c，更新和查询。但是同时存在一个问题，在高互动下的数据库更新操作频J的情况下，复制的gq时间会很长Q甚至会?分钟的gq！应用E序应该有应对gq的准备Q?br />
l论QWEB2.0前期设计应该有良好的散列考虑Q程序应该能有配合的扩充性，W合数据库的扩充
D公司
D公司是一个各个方面做的比较好的公司，做了CDN加速，囄也独立分ZN个服务器Q数据库不错的一个，(CTO是个数据库专ӞQ系l崩溃的原因在于WEBQ按道理说WEB很容易做集群的，但是发现集群q解决不掉问题，他们的集只允许?台的WEB集群Q但?台都当掉了。仔l分析，扑ֈ原因Q我估计整个也是大部分CTO最Ҏ犯的一个错误，或者说他们Ҏ想不到的问题，是WEB上传的问题，上传的时候由于数据传输的原因Q线E是保持链接的，300个线E就可以把一个WEB Server当掉了。解x案：q个最单，把上传和其他耗能大户分离出独立出来，同时做异步分布式上传。程序改动不是很大，但是之前半个月速度满对用户体验的损׃不可视。像q种http://www.5a520.cn 说520|?br />
l论Q没有什么结ZQ毕竟有量讉Kl验的CTO不多Q也是那几个大站的?br />
ȝQ不是泼hQ模仿其实是很容易的Q随便找几个WEBE序员就能做刎ͼq且很简单，速度可能q很高效Q因为WEB2.0无非是跟数据库打交道，会操作数据库׃做。但是真正做大ƈ不容易，因ؓ能应付v量访问的E序q不单，现在的程序员都太自命不凡Q其实真正有l验的ƈ不多Q不要相信一个月?K--10K的程序员能给你多大的惊喜Q能应付量讉K的程序员不是那个h。如果您惛_2.0Q想做大Q有几个个徏议：
一.找DBMS的专家设计好数据库，大部分程序员都不知道分区视图Q数据散列，数据l的概念
?设计好程序架构（q个其实不难Q有个高人指导就行了Q，保持良好的扩展性，成本考虑可以扑օ职的pȝ架构设计师做好系l架构，定来的发展瓶颈?br />
?考虑好文件存贮的问题。文件存贮的技术含量看h很低Q其实是很高的，可以考虑反向代理的方案。文件存贮出问题了，站点基本上就完蛋了，不仅仅是RAID的问题和存贮服务器的问题Q不q道理倒是一点就破的
?中国国情考虑Q这个最致命Q需要考虑电信和网通的问题QCDNq不能解x有问题。互动性的东西qCDNq不是很有效。最关键的是Q现有的双线机房遇到DDOSd基本上都会当掉，原因很简单，双线机房都是Uh机房Q本w就不会有太高的带宽Q随便攻M下就可以D掉（带提一个笑话，我知道一个双U机房的老Ld1G的带宽却C4G的金监֢Q很?00M的攻d可以搞定Q?br />
?|络延迟的问题，q是分布式系l必要考虑的，E序要能容忍0?00U的数据延迟的功能，也就是同步的问题。不要小看这几十U，问题很大的，如果你的站点有交互式功能Q比如即时聊天，你可以想象一下是个什么结果。对于即时聊天的东西Q可以用反向代理来解冻I成本较高Q。但是对于留a和评论的影响不大Q但是如果系lؓ了健壮做了缓存和静态化的时候，q个东西可能是N性的了。静态文件的更新和重写需要异步的方式来做?br />
?分散你的E序Q如果你没有太多的资金构{动辄百万的服务器，把功能分散开来，比如相册一台服务器Q留a一台服务器
?看好你的E序员，如果没有很好的激励措施的话你的程序员很容易写出敷衍性的代码Q而这个可能就是将来的大患Q程序架构定下来后要修改可能p费牛劲了。最好你的CTO能对?00%的衷心，100%的负责?br />
?文g同步的问题，q个问题可能你觉得没有必要，如果你看一下网通和电信的TTL明白了Q同步要支持l传Qƈ且不能是持箋的，否则你的成本会高出N倍，量大的时候需要采用同步服务器q行更新Q不要期望能通过你的软g实现Q交l你的程序员吧，把上面的话告诉他他就知道怎么做了?
?最狠的一个问题了Q也是吃亏最大的问题Q不您跟网警的关系多好Q看好你的用P审核好你的东西，一被停机可能就致命Q本人就吃过Nơ亏?br />
?对于~存和静态文Ӟ应该采用独立的缓存服务器Q对~存l护和文件烦引维护，q更新和删除
最后，各位站长一番风，大展宏图?/p>
原文出处Q?a >http://e.hnce.com.cn/xinjingji/web2.0/2009/5/12678559.html
]]>