28 12
发新话题
打印

[转帖] 写给WEB2.0的站长 不仅仅是泼冷水

本主题由 admin 于 2008-3-9 14:13 移动

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

写给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的零碎文件,大量的读写操作,系统崩溃,数据丢失,文件系统的一个链断了,用户数据全部丢失!!!这是一个非常沉重的问题,系统整整停了一个月来做数据恢复(单独文件很容易,但是海量文件目前还没有一个软件能组织起来软件架构)。解决方案:修改程序架构,做分布式文件存贮(程序修改用了8天,但是文件转移却又用去了将近一个月),20万用户损失殆尽

结论: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并不能解决所有问题。互动性的东西并CDN并不是很有效。最关键的是,现有的双线机房遇到DDOS攻击基本上都会当掉,原因很简单,双线机房都是私人机房,本身就不会有太高的带宽,随便攻击一下就可以D掉(顺带提一个笑话,我知道一个双线机房的老总总共1G的带宽却买了4G的金盾墙,很简单800M的攻击就可以搞定)。

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

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

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

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

九.最狠的一个问题了,也是吃亏最大的问题,不管您跟网警的关系多好,看好你的用户,审核好你的东西,一被停机可能就致命,本人就吃过N次亏。

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

TOP

嗯,文章不错。
沒楞角的時候就拿錘子在圓乎乎的自己上使勁砸,不要怕粉身碎骨,使勁砸,往死里砸…………

TOP

好文章。
Life is like a box of chocolates: you never know what you're gonna get.

TOP

把文章内容写的详细点,就可以出版成书赚稿费了。
是jessonq 原创的吗?

TOP

国内的网站,有创意的确实不多,软件下载站和音乐下载站多如牛毛,真的能赚钱吗?

TOP

不是原创 是我转的,标题标明了。

做网站赚钱的方式有很多,有人做垃圾网站,靠googleAds也能月收万刀。这样的多半是靠作弊,给人中病毒一类下三烂的手法来捞钱。正是因为国内骗子横行,所以什么东西拿到国内一推广,很快就烂掉了。

到底怎样才能从互联网中赚钱,我相信很多人都在动这个脑子。

以前有个朋友(非计算机科班人士)在淘包开店,卖点小东西什么的也能过的挺滋润。但想想我们这些搞计算机的人,只靠着辛辛苦苦买苦力赚钱,真是不甘心阿。我们中间的很多人,估计90%以上吧,除了工资之外,你真的从互联网,或者说你熟悉的这个行业拿过一分钱吗 ?

我们现在需要的不仅仅是一个idea,还需要你一个好的商业模式。这个商业模式至少要包括下面几个方面

1,盈利手段,不赚钱你做他干什么啊?除非你是搞公益的

2,商业壁垒,让你的对手很难模仿你。这个很重要,有一天你搞了一个东西刚放到网上去,点击率一上来,好,你的孪生兄弟立马到处都是了,什么感觉。。。。

其他的略掉了,属于收费内容。。。。。 哈哈

TOP

引用:
原帖由 jessonq 于 2008-3-10 13:28 发表
1,盈利手段,不赚钱你做他干什么啊?除非你是搞公益的
做网站赚钱的方式有很多,有人做垃圾网站,靠googleAds也能月收万刀。这样的多半是靠作弊,给人中病毒一类下三烂的手法来捞钱。正是因为国内骗子横行,所以什么东西拿到国内 ...
支持半公益 半盈利的网站。

TOP

引用:
原帖由 jessonq 于 2008-3-10 13:28 发表
不是原创 是我转的,标题标明了。

做网站赚钱的方式有很多,有人做垃圾网站,靠googleAds也能月收万刀。这样的多半是靠作弊,给人中病毒一类下三烂的手法来捞钱。正是因为国内骗子横行,所以什么东西拿到国内 ...
国内的网站,有技术含量的不多,所以容易被模范。

我觉得discuz就很聪明,对非商业用户免费开源,让你模仿都没有价值。

TOP

引用:
原帖由 robotfish 于 2008-3-10 14:37 发表

  支持半公益 半盈利的网站。
名利双收

TOP

所以现在我一直想搞一个开源项目,找帮志同道合的朋友,做点自己喜欢的事情先。

PS :开源不等于免费, 很多人认为开源就是免费这是不对的。 搞开源也可以以营利为目的,比如 readhat,jboss

TOP

回复 #11 jessonq 的帖子

在代码不是很成熟之前,不开源也没事,关键是作出别人没有的东西。

现在搞BBS,博客,购物网站的很多,为它们做些共通工具也是一个思路。

我现在对词典,字典之类的比较感兴趣,但是大多数词典软件都是把词库加密了,每家的字典格式也不统一。

如果能把收集到的词典,字典都导入到数据库中,那就方便多了。

TOP

admin的建议很好。 你可以做个词库的webservice ,人家仍过一个词来,你把意思什么的用xml也好,用json也好返回去就OK,以前我曾经这样想过,但是我对词库不太熟,所以只是想了想。

SNS也很多,给他们做个protal不是也很好。(不是我的想法,那到这里来说只是希望大家开阔思路)

TOP

回复 #13 jessonq 的帖子

这个已经有了,excite.co.jp里面的翻译功能。 可以用,虽然不是
webserive的形式,一样可以自动化。

TOP

说实在的,我们能想到的东西,网上肯定有。我们想不到的东西网上不见的没有。
做一个东西,如果想做就把它做到极致,就像google search 那样。

TOP

把中文kakaku做到极致,你觉得如何?
http://www.rakudoor.com/kakaku

TOP

to robotfish

我感觉我没有资格对你要做的东西提什么建议 ,毕竟你有了自己的想法而且付诸行动了 ,这已经很好了 。你接着去做就行了,不用征求别人什么意见 。

有时候成败 要靠一点运气,至少起步的时候是这样的 。希望你能成功haha。

TOP

引用:
原帖由 robotfish 于 2008-3-10 18:31 发表
这个已经有了,excite.co.jp里面的翻译功能。 可以用,虽然不是
webserive的形式,一样可以自动化。
excite只有中日,日中,中英,英中,可以做的词典还有很多啊。

TOP

引用:
原帖由 jessonq 于 2008-3-10 18:40 发表
说实在的,我们能想到的东西,网上肯定有。我们想不到的东西网上不见的没有。
做一个东西,如果想做就把它做到极致,就像google search 那样。
对,如果每个人都能用ruby开发一个工具,并且做到第一,那么联合起来就很强大了。

为什么要用ruby呢?因为它有魔力,相信童话的人可以试试看。

TOP

引用:
原帖由 jessonq 于 2008-3-10 17:53 发表
admin的建议很好。 你可以做个词库的webservice ,人家仍过一个词来,你把意思什么的用xml也好,用json也好返回去就OK,以前我曾经这样想过,但是我对词库不太熟,所以只是想了想。
词库这种东西在日本都是大学来做的,国内那些只教授们业务太忙了,如果个人做需要很多人协同作战。

目前挑儿头做词典的有coffeejp,按照日本人的标准自己编epwing格式的词典,使用shift-jis编码+外字文件,出发点是好的,可惜选错了路,很多汉字难看的不得了。

TOP

引用:
原帖由 jessonq 于 2008-3-10 20:42 发表
to robotfish

我感觉我没有资格对你要做的东西提什么建议 ,毕竟你有了自己的想法而且付诸行动了 ,这已经很好了 。你接着去做就行了,不用征求别人什么意见 。

有时候成败 要靠一点运气,至少起步的时候 ...
我没有去做呀,其实我最感兴趣的东西不是软件,是硬件和软件的结合。 不过目前条件还不具备。

TOP

 28 12
发新话题