最近的两则新闻引起了人们的关注：一个是老牌RSS阅读器bloglines再推了beta版，同时推出了Display（显示）广告，这至少说明到目前为止bloglines也找不到更好的盈利方式；另外一个就是RoJo马上也要撤了，并被blogs.com替换成blogger推荐门户。

　　对应的国内的情况是：作为feed烧录代表企业的feedsky经营状况不佳，不断传出出售的传闻。当然，如果能卖掉，特别是卖给广告网络（代理）运作的公司，应该是个不错的选择；另外，就是国内最早的阅读器抓虾，已经退守到尝试adsense和阿里妈妈的份，相信前不久推出的互动营销平台也不会有什么效果；鲜果则暂时未考虑盈利问题。

　　目前从全球范围来看，即便拥有巨大的使用用户，阅读器依然鲜有好的盈利突破点。Newsgator原本的收费使用服务，在Google Reader这种免费服务大张旗鼓的冲击下，也已经开启了免费的大门；而企业级信息收集方面也并未形成规模性的收入。

　　对应到国内的话，还有一个用户规模的问题：到目前为止，抓虾经营了两年半的时间，用户积累20多万，其中有多大比例的“活用户”并不乐观，相当多用户只是注册了也就over了；新秀鲜果半年时间拿到了5万多用户，估计不少是从抓虾迁移过来的。

　　用户短期内，很难有一个大的突破；没有规模用户，何谈收入？

　　对于国内的阅读器参与者而言，是时候考虑下定位和盈利方向的问题了。美国如此成熟的市场环境下，价值阅读的诉求要远高于中国这个“娱乐之上”的互联网，在盈利探索上尚且如此，我们怎么办？更何况还有Google这种完全没有收入压力的对手！

　　另外，阅读器比较难建立商业模式的问题，还在于，阅读器本身只是一个信息流动的通道，它本身不产生内容，不掌控内容，可替代性太强。这些都决定了，阅读器比blog服务商（BSP）、社交网站（Facebook、Myspace）、信息聚合服务（Twitter、friendfeed）、甚至于是feed烧录者（feedburner）更难建立营销的机会。

　　如何解决（产生或者是聚合）内容，是阅读器应该考虑的一个思路。事实上，过去一段时间，Google Reader已经在note、share等方面做了一些尝试。<via:⊙ 一言谈>

　　我的矛头不单是指向各个互联网企业的C[X]O，还有那些若干想靠一篇评论出位的bloger。或者大家也会觉得我是这样的一个人，那我们一起先来看看我们现在所知道的WEB2.0的几点：

• WEB2.0是一个并非以技术为主导的概念；
• WEB2.0是以一系列网站做为代表的统称；
• WEB2.0是以用户作为内容来源的；
• WEB2.0是出自于2004年3月，在欧雷利媒体公司（O’Reilly Media Inc.）在线出版及研究的副总裁戴尔·多尔蒂（Dale Dougherty）之手。

　　　这里要说说的就是从这里的提出人和公司。Dale Dougherty是最早提出API的人之一。对于这样的一个技术型的人说出了一个并非以技术作为主导的概念，单是这一点就可以认定这个是一个不可让人相信的骗局。记得EMU说过的这样的一句话：“一个有技术影响力的技术型的人，一旦从事的工作失去了技术影响力就是说已经没有了影响力。当没有了影响力他从事的任何工作都会失去信心，进而失效。”

　　另外的一方面来说，一系列的网站作为代表的统称。那是否按照那些网站的模式和架构就是叫做WEB2.0时代的网站呢？所以出现了这么多“找死的WEB2.0”。因为从一个终点描述去多向发展是根本不可能到达所谓的终点的。

　　第三点，很多所谓的内容为王，进而的还有以用户作为内容来源。那么我们的用户在哪里来？是不是就是说国内的除了Tencent、Taobao等这些有着大型用户群体的公司以外别的公司都没法进入WEB2.0？

　　大家可以看到就依耐Tim O'Reilly整理后的演讲一文《What is WEB2.0》（官方指定译文）当中，被国人传达后所注重的几点是那么的漏洞百出。也就正如页面界没有人不知道的一本书《网站重构》到了中国就变成了DIV+CSS。但是大家不知道有没有认真地读过这本书，里面有着Jeffrey Zeldman所说这样的一句话——“即大量的使用div标签作为结构元素，没有固定的标准和道理说不行，但事实上这是一种更高级的table滥用。”原文为“Well, if know anything about templates, you will know that you can use tables or <div> tags. Well, it's the same for nested templates. In other words, if you wanted to yank out the tables and replace them with <div> tags, you still can use nested templates and it will still work. There is no rule or technical reason that says you can't use <div> tags in templates or nested templates or library items.”（网络的出处）。所以真正阻碍我们的发展的并不是我们“拿来”的别人的书，而是那些鲁迅笔下的被无形的手掐着的鸭子。

　　然而本文并不是单纯的像很多人一样只是说出他的问题而不去解决它，也就是我想让大家知道的WEB2.0的单手原则。按照Tim O'Reilly的演讲中后半段以及Dale Dougherty的意向我们可以将中间的所提到的技术合并同类项按照历史中出现的顺序归结为以下的5点（如RSS和XML合并到XHML一类等）：

1. API
2. XHTML
3. CSS
4. AJAX
5. SEO

　　我们再将以上5个技术点按照我们手指的先后分别命名：

　　我们大家再将自己的一只手竖起来，正如你在物理课上面学“右手定律”和“左手定则”一样跟着我做一个试验：（当然前提是基于一个身体正常的人类）将任意一只手指单独的弯曲到贴近手心，看看其余的四只手指是否还能与手背成一直线并且舒适。大家是否发现了一些奇异的事情：单只手指弯曲的时候，只有拇指[API]才能完成指定动作。

我们看看这说明了什么：

　　当单项技术结合到落实的时候，只有单做API能完成任务。然而单做API在我们看来在互联网当中应当只有我们的用户，因为这些用户只会不断地开源自己的“接口”（这里先不讲技术上的API），不断地输出我们想要的资料和信息，同时我们的WEB2.0也是能单靠这一点可以先存活下来的，也就是我们常见的VC砸钱。在这样的WEB2.0时代，冒头的产品就已经很困难了；生存下去就更加的困难，而且在一种无期的持久战中折腾于一个存活阶段却不懂得使用这些技术手法去维持自己的生计，不会开源节流就是等同于自己找死。

　　举例一一的说明，比如尾指[SEO]也就是大家常见的垃圾站，没有什么技术技巧单纯的作静态页面，被移动封杀以后多少垃圾站站长要被迫转型为服务器提供商。接着是无名指[AJAX]，这里就想以饭否为例说一说，之前在群里和人打赌过一顿饭他们不能支撑过两年，除非转型。不看好他的原因是因为过多的使用服务器操作，无法将页面静态化，数据静态化；这里会有过多的流量消耗以及服务器吐页面的性能消耗。再谈到中指[CSS]，过往的WEB1.0的对应形式是什么，针对一项业务开拓新的终端平台就需要重新的招收一批开发团队；而在WEB2.0的时代，我们只是需要用一个开发团队和一个出色的页面重构人员，通过页面当中CSS连接的media属性连接到“screen”、“handheld”、“TV”等去展现不同的表现，从而实现开源节流。

　　由此可见，在WEB2.0当中，要真正的立于不败之地就必须五个手指一同弯曲，就是五样技术一起抓。然后很多人会奇怪，SEO和AJAX两者技术而言其本身就是有所冲突的；那么他们两者怎么能一起的并存于WEB2.0的技术领域呢？我们看一看我们的手，无名指[AJAX]和尾指[SEO]相近，相连。而在我们的产品形式当中这样的状态就只有出现在我们的“Portal端”和“client端”。我们就应当针对用户访问最多（对于全站而言）的client端做AJAX，静态化模板、动态拉去数据，同时也能借助AJAX的不被搜索引擎收录性保护起用户未公开发布的、加密的以及点对点的信息以及内容；而另外的一方面我们应当在portal端进行页面文件的静态化，使得用户想要发布的信息更加容易的去被搜索引擎所收录增加网站以及用户的知名度和将信息凝聚。（这里说的是信息的本身而不是像当前很多所谓WEB2.0网站做的用户本身，当然这里存有若干的技术细节技巧。）而另外的一方面使用完善的XHMTL（当中包括语义化的页面文件和RSS）表现页面结构，和使用多向的CSS作为多平台终端的低成本扩展。最后使用多支持性的插件和标准化的API（这里指的就是技术上的API）去蚕食那些不属于你的互联网领地，就比如饭否的插件（11个blog服务商）、以及叽歪的输入途径（9种）和API这一块个人觉得就做得非常的成功；相比起来当前的其它老大哥反倒表现出一种“吃老本”的味道，比如“搬家工具”失势的blogcn，输入途径失势的滔滔……等等。

　　这个定则放在我这里已经快一年了。
　　一直本着看3做2说1的方式，然而这个3看了做了也快一年了；到现在才把他说出来皆因暂时心里面还没有看到一个更高的3。不过我相信“舍得”——有舍必有得，正如当初想通这些前也是经历着这样的没有3的阶段。但现在的状况是确实需要把他写出来的。大家也可以看到这里当中提到的五样技术都是我们网站重构人员的职责范围（是指网站重构而非页面重构和页面制作），所以我们应当有责任也有义务去把中国的WEB2.0做好。
　　虽然我们只是技术层面，而真正的WEB2.0当然还有有其他层面的把握。不过本定则当中的一些实现细节技巧因为商业保密原则不能公开，希望大家原谅。[via/Twinsen Liang]

　　不废话了，看原文吧：

---------------------分割线---------------------

当互联网吵吵嚷嚷的进入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次亏。     

　　十.最后，祝各位站长一番风顺，大展宏图。(via:尤来尤去)