企业2.0雾里看花

　　用一句话来定义企业2.0并不是件容易(甚至有意义)的事，但无论如何，本文至少试图让大家看到企业2.0这朵“花”的轮廓，而且正当如今“和谐”这个字眼被四处滥用时，我也发现它恰恰成为能够从一个很有意思的侧面反映何谓企业2.0。

　　企业2.0是指企业或组织借助信息技术实现和谐、透明、高效的协作式工作模式。企业2.0的核心思想是沟通和协作。

　　在下面的文章中，我们先从思想、工具和方法论三个角度近距离了解企业2.0——如同行军打仗，你需要有正确的战略(思想) + 高效的武器(工具) + 合理的战术(方法论)，然后我再逐渐拉远镜头，以将笼罩在企业2.0周围的迷雾呈现出来。

　　企业2.0的思想、工具以及方法论

　　1. 企业2.0思想

　　企业2.0的核心思想是沟通和协作。总的来说，企业2.0是为了实现企业管理中信息的高效沟通以及利益相关者的高效协作，而不局限于某种技术(如ajax， soa等)或某种应用(如wiki， blog等).企业2.0思想认为：当信息的流通和交换愈加畅通时，企业人与同事、团队、客户及其合作伙伴等的沟通也会愈加高效(从而避免囚徒困境的出现)，而当沟通变得更加自由和开放时(在合理范围内)，企业人就可以从周围得到更多的反馈，从而实现更多的互动(从而产生协作)，同时企业人对问题的反应也会愈加迅速、敏捷，因此做出的判断也会愈加准确。

　　企业2.0的主体是处于组织机构中“绝大多数”的人，因此我们之所以认为企业2.0是对企业管理思想的变革，是因为它前所未有地更加重视人在企业中的主观能动性，而不是某种工具、流程或模式在“企业基础设施”上带来的变化。同时，企业2.0在某种意义上再次将松下幸之助的管理名言“企业管理过去是沟通，现在是沟通，未来还是沟通”基于信息技术发扬光大。

　　2. 企业2.0工具

　　企业2.0工具指以Web 2.0为代表的社交软件平台，它们赋予了每个企业人平等参与，以及分享信息的权利，从工具上满足了将企业人的主观能动性最大化之需要。Andrew McAfee先生(MIT教授，著名博客作者)早在2006年4月的麻省理工学院斯隆管理评论中就首次明确了Enterprise 2.0的定义，并随后陆续修订至“2.0版本”，但坦白讲，我的看法跟Tom Graves的观点一样：Andrew先生的定义极大地忽略了人的因素，但他的定义却对“企业2.0工具”做了很好的诠释：

　　企业2.0是指在企业内部、企业与其合作伙伴之间、企业与其客户之间的成长性社交软件平台的 应用。(你不妨也参考一下原文)

　　1.  “成长性”(Emergent)意味着这种社交软件的是可以自由成长的，因此，随着时间的推移，它可以逐渐呈现出人类潜在的、或者与生俱来的沟通模式和习惯。最典型的具有“成长性”的例子就是标签(tags)和wikis，最典型的反面例子就是论坛(forum)——随着信息量日益增大，你会发现论坛里的知识日益难于管理。

　　2. “社交软件”前所未有地通过计算机网络使得人们可以迅速交流、沟通和协作，以及组建社区。

　　3. “平台”特别地指出企业2.0工具与所谓“企业1.0工具”的不同——企业2.0工具中的信息是可以长久保留，而且开放的(如果你愿意的话)，而企业1.0工具中的内容则大多是不持久而且封闭的，例如Email.

　　典型的企业2.0工具有：

　　1. 企业Wiki

　　2. Blog

　　3. 企业Tagging

　　感谢Web 2.0！ 是它为企业2.0的蓬勃发展奠定了重要的“工具”基础。

　　3. 企业2.0方法论

　　如果Web 2.0可以解释为“互联网应用的变革”，企业2.0则可以解释为“局域网应用的变革”(虽然我们也看到很多企业开始用facebook， tweeter等开拓市场，但我更倾向于认为这并不应属于企业2.0的范畴，Andrew教授的观点同样如此。)

　　学会如何使用工具远远比向工具本身投入过多精力重要的多。企业2.0的方法论旨在研究人们如何在企业中应用企业2.0工具的问题(这也是维基道创建的初衷)，从而将人们从落后的生产力中解放出来。我们必须第一重视方法的 重要性，而不是过度依赖于某种工具——但事实上人们常常犯这种错误，比如很多人会以为部署一套昂贵的ERP系统后你的企业就可以高枕无忧了——这些都是被 那些软件厂商天花乱坠的字眼忽悠的。乌鸦用石块就可以填满瓶子取水喝，但母鸡也许永远也不会，即使你给它插个吸管。可见把主要精力放在深入了解某个工具， 并适应它，从而善用它是多么的重要。

　　从实践层面看，企业2.0的方法论概括起来有如下几个主要方面：

　　1. 不要因为企业2.0而造成合作的不愉快。如果众人反对，那就先放一放。企业2.0的思想决定了其性格是轻松、自由的。

　　2. 知人善用。建议你选择这样的人做你的企业2.0项目带头人。

　　3. 充分了解、发掘影响企业协作的因素和问题。企业2.0的实施的唯一目的就是为了解决这些发展问题。

　　4. 充分了解你要应用、部署的企业2.0平台。(如果是wiki，这里有几乎所有的wiki产品信息).

　　5. 通过试点项目总结实践经验和教训，从而为全面的实施打下坚实基础。

　　6. 自上而下的推动会更见效(但注意不是强制性的).

　　企业2.0实施实际上是企业2.0发展至今最困难也最具挑战的一环，之所以困难是因为它实际上是在改变人们的工作习惯，而改变一种习惯所要付出的精力是足以让你的老板迟疑、让你的同事望而却步的——这也就是为什么我们经常听人们说自己公司虽然有wiki但使用很少的缘故。但是，不要怕，只要你铭记企业2.0的思想无非就是提高人们工作效率，你就不会迷路，我们会不遗余力地在维基道分享、讨论企业2.0实施的最佳实践。

　　企业2.0迷雾

　　现在，我们把镜头拉远一点，看一看笼罩在企业2.0之上的迷雾。

　　迷雾之一：企业2.0 v.s ROI

　　我们必须承认，老板最关心的永远是投资收益(ROI)，而且最好是看得见、摸得着的收益。但企业2.0在这一点上仍旧未能交出一个让人信服的答卷 ——即使几乎每个人都确信高效的协作会给企业经营带来好处——但是，这些好处值多少钱？正如前面所说，商业社会中企业及其投资人永远是利益驱动，我们不能 意气用事地怀疑这个命题本身，即使我们可以发一发牢骚：这个命题貌似很荒谬，以至于荒谬到你的老板似乎在追问这么一个问题“员工晚上高质量的睡眠能给公司带来多少收益？”

　　迷雾之二：企业2.0 v.s 企业文化

　　很多企业2.0的狂热者认为企业2.0能够改变企业文化，使之变得更加透明、自由、和谐，他们也认为企业2.0能够驱使企业组织结构更加扁平化，甚至去官僚化。但另外一部分人认为企业2.0只能是开放式工作方法的具体体现，它从根本上没有足够的力量改变一个组织的企业文化和结构，但却可以施加影响。后者听起来确实没有那么振奋人心，但我们确实需要在企业2.0实施中直面可能摆在你面前的冷酷事实。

　　我们在“企业2.0思想”中谈到过企业应确保信息在“合理范围”内完全开放，但“合理范围”的限定会受到企业文化的影响。如果企业文化原本是趋向自 由、开放、透明的，那么最终可以开放的信息可能占到全部信息的80%；但如果企业文化原本是趋向保守、官僚等，最终这个比例可能只会是60%.很多情况 下，企业领导者决定了其企业文化的趋向。

　　究竟企业2.0和企业文化谁能够左右对方，留给历史去回答，而且回答这个问题也许并没有我们想象中的那么重要。在企业2.0应用实施中，只要我们牢 记其初衷和宗旨，即可以不变应万变，我们有足够的理由相信，只要一个企业是愿意成长的，那么它一定愿意拥抱企业2.0，因为分工协作始终是商业社会之本。

　　迷雾之三：企业2.0 v.s 人

　　很多曾经试图应用企业2.0但遭遇挫折的人多少会怀疑企业2.0是不是只是个噱头，究其表面原因想必多种多样，但终究是犯了形而上学的基本错误，我们要划开表面看本质——人，才是企业2.0中第一重要的，而不是某种工具(在上文中我们也已讲过).我们经常问自己的团队：“are you comfortable with your work？”富含同样的道理。如果硬是要把这句英文翻译过来，或许“和谐”这个词最合适：你的团队和谐吗？

　　人，远比流程、模式或者工具等重要，如果说“企业1.0”是流程、模式或者工具的爆炸式发展和应用的时代，那么“企业2.0”一定是构建和谐团队，发挥人主观能动性的时代。

　　迷雾之四：气势汹汹的企业2.0？

　　这一层其实是最容易拨云见日的，而且也是最应该清扫掉的：企业2.0应用并不是要气势汹汹地取代现有的工作平台。例如很多人鼓吹的“Email is dying”——现在来看，Email绝对不是一个合适的共享、协作平台，但Email在迅速传达信息上仍然拥有其他工具不可替代的优势。

　　如果你有兴趣，还可以看一看最近Andrew Mcafee和Dennis Howlett关于企业2.0的一场争论，其源于Dennis说Enterprise 2.0“太挫了”。但请记住，争论也是企业2.0能够发展的源泉之一！

　　来源：维基道投稿

Google图书遭遇滑铁卢

　　最近谷歌图书在中国遇了这么一纠纷，只不过比美国著作权人的诉讼晚了那么三年时间。

　　首先我们要确认一件事，Google Book Search在翻译为中文的时候把最后一个单词给省略了，所以中国版旧叫做谷歌图书。直译过来的结果应该是谷歌图书搜索，所以我们不能忽略这么一产品本质上是一个搜索产品（关于 Google 图书搜索），所以适用搜索引擎作恶的保护伞——避风港原则。

　　所以Google完全可以依据这一条款继续使用这些书籍，大不了收到书面通知的时候删除个几本，事实上国内大多数音乐搜索也就是这么干的。但是为什么Google会尝试去与著作权人去和解，这里面有两个深层次的原因：

　　Google Book Search想要打造的是一个基于互联网的数字图书馆，而且重点是All for free，这是一种颠覆性的模式。而图书馆与图书搜索最大的区别在于图书馆的资料更为全面，分类更为详细，所以Google愿意去和解来换取长期的发展。

　　最重要的是，Google Book Search对用户是免费的，但是其中投放的广告是可以带来收入的，由于这款搜索产品已经产生了商业收入，所以与作者、出版社进行分成是应该的。

　　Google和美国的版权方达成和解了，这时候中国的作者和出版商们出来找麻烦，这样的时机不可违不合适。本来嘛，自己应得的利益应该去积极争取。一时间CCTV、各大电视媒体、各大网络媒体、各大平媒不约而同将枪口对准了Google图书搜索，要求给个说法，这钱到底怎么分。

　　这事儿本来没错，但是似乎大家的反应过激了，甚至有人说到激愤之处声称中国应建立自己的数字图书馆来对抗垄断，未免太过犹不及。我觉着这事儿咱们不明真相的群众看看就好，有免费的书我们就先用着，至少我去体验之后觉得很不错，而且还不用我给钱。

　　按我的猜测，双方最后还是会达成一个和解协议，确定一个合理的分成比例，到时候大家也就偃旗息鼓。不过更重要的是，李开复离职后，谷歌刘允与杨文洛的双龙头架构第一次面临重大考验，至少目前还没有看到他们作出任何有效的策略应对。至于我们，看戏就好，别太认真。

　　来源：XJP投稿，原文地址。

谷歌图书遭央视曝光

　　“色情门”风波初定，10月13日，谷歌中国再遭央视曝光，中央电视台《朝闻天下》报道，谷歌数字图书馆涉嫌大范围侵权中文图书，从中国文字著作权协会获悉，570位权利人17922部作品在未经授权已被谷歌扫描上网。

　　中国文字著作权协会相关负责人表示，这570位包括国家领导人、政府官员和作家在内的权利人对此毫不知情，且没有证据表明谷歌公司取得了权利人的授权。法学专家认为，谷歌的这种未经许可的复制和网络转载的行为均涉嫌侵犯著作权。

　　所涉及的570位权利人中，有政府官员，也有著名学者和作家，如冯友兰、王蒙、张抗抗、海岩等，还有社会科学与自然科学领域学者的论著。

　　仅中国社会科学院，就有132名学者的1000多部图书被收录。

　　事实上，早在2004年，谷歌就已经在全球范围内“悄悄”进行数字图书馆的建设。

　　今年8月30日，谷歌高调宣布，将在原有的谷歌数字图书馆基础上，构建全球最大的在线图书馆，全球用户均可通过免费搜索，在线浏览相关的图书内容。

　　这一计划，让谷歌频频遭到全球出版界的抗议和诉讼。

　　“我们也是在接到国际复制权组织(IFRRO)秘书长奥拉夫先生的致函，希望我会在谷歌侵权事件中对中国著作权人权益的维护做出积极地配合时，才开始关注中国著作权人被侵权的问题。之前谷歌的行为，我们完全蒙在鼓里。”张洪波告诉记者。

　　2005年，美国作家协会与美国出版商协会，就谷歌未经授权即对图书进行数字化一事提起集体诉讼。

　　2008年10月，谷歌公布其与美国作家协会和美国出版商协会达成的和解协议。根据该协议，谷歌将其通过合法途径获得的图书进行数字化制作，建立数字图书馆，进行多功能开发利用，包括团体订阅、个人用户购买、公众免费查阅以及对有关数据进行技术研究和开发等使用方式。

　　根据美国民事诉讼法规定，该协议一旦生效，也会对中国的著作权人产生法律效力。

　　按照和解协议的内容，如果权利人不想被包括在和解协议范围之内，就必须在今年9月4日之前选择退出。中国权利人如果接受该协议，可获得每部60美元左右的费用，但必须向谷歌主动申请。

　　“这个协议有300多页，我们已经在网站上公布了相关通知。但我们协会很难接受这个协议，这等于默认了谷歌侵权是正确的，而权利人不主张权利就要被视为放弃权利。”张洪波说，“版权法规的核心准则，就是只有得到著作权所有者的许可，并且支付使用费后，才可以复制并传播书籍，而谷歌明显违反了这个准则。”

　　“数字图书馆的背后商机无限，如果掌握了大量的读者、作者群，那么以后可能带来衍生的服务模式非常多。这块市场，将是未来争夺的重要目标。”律师杨立表示，这件事情所涉及的，不仅仅是出版社和出版人的利益，它将关系到谁来主宰未来的数字图书馆，实际上就是谁来掌控全世界范围内巨大的文化资源。

　　来源：南方网

Google应该让Android走山寨路线

　　Google Android的竞争对手决不会是摩托罗拉、索尼爱立信，Android想要做的是一款移动操作系统，一个移动产品的软件帝国，现在能让Google入得了法眼的也不过就是诺基亚控股的Symbian和微软旗下的Windows Mobile。

　　诺基亚的强势并不是没有道理的，Symbian算不上技术特别优秀，但是可怕之处在于它的东家诺基亚是全球最大的移动通讯设备制造商，简而言之有销量和市场，然后旗下的Symbian自然也获得巨大的市场份额，多少有点鸡犬升天的味道。从这个层面来说Windows Mobile和Android可谓是同病相怜，他们都是只做软件而并没有足够优势的移动产品。

　　Android忙着拉拢摩托罗拉、索尼爱立信等被诺基亚长期压着打的手机厂商，意思很明确：以前你们被诺基亚压着是因为没有足够强势的操作系统和软件平台，但是现在这些问题全部由我Google来帮你们解决，你们只需要做好你们的手机，其他的事情我来搞定。所以最近基于Android的手机产品到也是雨后春笋一般，一拨一拨地冒出来，这说明Android的策略是有效的。

　　也许诺基亚在早前就感受到了Android将会对自己产生巨大冲击，毕竟以前自己有平台优势，现在Google这么一互联网巨鳄搀和进来，鹿死谁手尚未可知。所以诺基亚也把旗下的Symbian给开源了，不过感觉一直扭扭捏捏，就像女生第一次难以放开。诺基亚担心的是自己的Symbian养肥了竞争对手，而老诺的竞争对手们则是不敢大幅跟进，担心Symbian是诺基亚控制下的，要是真的傻头傻脑跟着混，万一哪天诺基亚随便使个绊子，恐怕命根子都得赔进去。

　　所以开源后的Symbian并不能给Android的结盟机会造成伤害，Google不做手机反倒成为了它的优势，因为手机厂商不怕Google来抢自己的饭碗。人家Google说了，你们卖你的手机，我做我的软件，井水不犯河水。暂且不说这承诺是否有效，不过的确为Android赢得了不少盟友。

　　不过按照Android目前这点国内市场份额来看，称之为星星之火也不为过，Android这点星星之火想要燎原需要的是一点恰到好处的东风，需要借一个势。东风和势是谁？自然就是几经衰败的山寨机。

　　中国的山寨机成就了一家联发科，成就你Android成为手机软件霸主那也并不是不可能的事情。回过头看看当年联发科助力山寨机厂商却也和现在的Android有相似之处，联发科为山寨机降低了生产门槛，但是山寨机要真正与诺基亚竞争纯属痴人说梦，软件是山寨机的最大的一个短板之一。

　　联发科提供硬件，Android提供软件，而且这软件还是不需要授权费的，没准真能迎来山寨机的第二春。几百块钱就可以享受数倍价格的功能，山寨手机不再以所谓的大喇叭、双卡双待双蓝牙作为主打，那时候山寨机不说与诺基亚平分天下，至少让诺基亚脱层皮那是绝对没有问题的。

　　我有一个梦想，有一天能够300快钱买一个高配的Android手机，可以流畅地使用Wifi和3G畅游网络，QQ、Opera自然不在话下，还是双卡双待双蓝牙……

　　来源：读者xjp投稿，原文地址。

Twitter同步到新浪微博和开心网

　　新浪微博和开心网等SNS虽然很流行，但Twitter的用户大多对其不感冒，不过即使如此，Twitter用户可能也会需要一个功能，就是能自动将自己的Twitter信息同步到新浪微博、开心网、人人网等国内SNS网站。以前我曾经介绍的一个同步方案因为嘀咕的维护而无法使用，这里我就介绍一下最新的同步方法。

　　首先是处理Twitter的Feed功能，主要功能包括删除feed中的username，过滤掉@回复的信息等，我这里提供了两个版本，一个是PHP的，一个是Python的，Python版可以安装到GAE上。

　　接着，翻墙登录TwitterFeed，在里面设置RSS Feed为上面做好的过滤Feed的网址，目标服务可以选择Ping.FM或HelloTXT这两者之一，设置时候需要API Key，可以去Ping.FM或HelloTXT网站上获取。

　　之后，翻墙登录Ping.FM或HelloTXT，在里面设置一个Custom URL，用来实现自定义同步服务，同步信息到火兔，具体代码参见这里。

　　最后，使用原先嘀咕的帐号登录火兔后，在嘀神服务中，绑定新浪微博、开心网、人人网等，这样就可以实现从Twitter同步信息到新浪微博和开心网。

　　整个同步的流程图如下： twitter -> appspot -> twitterfeed -> ping.fm -> customurl -> huotu -> 新浪微博。

　　这种同步方式，虽然设置的时候要翻墙设置好几个服务，但设置好了以后，同步功能完全正常，可以方便的实现自动将Twitter的信息同步到国内网站，其缺点也是有的，就是同步不是即时的，有大约一小时左右的时差，这个时差是由TwitterFeed引起的，另外使用者还需要有一个支持PHP的虚拟主机。

通过Ping.FM和HelloTXT的Custom URL自定义同步服务

　　Ping.FM和HelloTXT都是知名的微博客同步工具，可以一次同步多个微博，这两个服务都支持Custom URL，即自定义网址，利用这个自定义网址，用户只要写上一点代码，基本上只要是支持API的迷博网站都能同步了。

　　我们知道，这两个服务都是英文服务，因此对中文微博客支持较少，我们可以通过Custom URL让这两个服务都支持中文微博客，例如火兔、新浪微博、开心网、人人网等。

　　这里从forgotthemilk（原博已关）那里找了一个Custom URL的代码包，包中有四个文件：class-snoopy.php、JSON.php、miniblog.php、pingfm.php.

　　class_snoopy.php：从WordPress源代码中找到的，略微修改了一下以支持xml的发送；

　　JSON.php：可有可无的文件，如果你需要的话；

　　miniblog.php：主文件，这个文件上传到服务器上的所在地址也就是Ping.FM所说的自定义网址；

　　pingfm.php：定义了一个叫PingFM的twitter虚拟机，通过创建它的一个实例即支持一个迷博网站。

　　在pingfm.php中书写了支持Twitter等多个微博的实例创建方式。我将pingfm.php文件修改了一下，让其也支持嘀咕火兔的更新，这样，可以更新火兔的同时，让火兔去更新其他微博客，如新浪微博、开心网等。

　　点击下载：支持Ping.fm和Hellotxt的Custom URL（PHP）

平台网站架构设计之我所见

　　从架构设计师的角度来看，架构就是一套构建系统的准则。通过这套准则，我们可以把一个复杂的系统划分为一套更简单的子系统的集合，这些子系统之间应该保持相互独立，并与整个系统保持一致。而且每一个子系统还可以继续细分下去，从而构成一个复杂的企业级架构。

　　一 选择技术方案和物理架构

　　如何选择技术方案和物理架构，对很多刚接触平台网站研发的人来说这可能是个头疼的问题。这些问题的源头很简单就是能否提高开发效率，使平台具有高性能高负载性。就我遇到的常见的有这么几个问题：

　　a） 开发语言和数据库

　　一说到开发语言和数据库，很多人便开始做语言的比较，最常见的争论有：“asp.net和java哪个好”，“解释性语言和编译性语言哪个好”等。我个人觉的最关键是你和你的团队最擅长的开发语言和数据库是哪个，古语有云：“工欲善其事，必先利其器！”，趁手的开发语言和数据库有助于事半功倍。试想如果你选择了一个并不很熟悉的语言，也许这个语言和数据库在基础性能上的确比你掌握的语言好，但是在研发过程中学习曲线肯定长。而且遇到问题的时候因为不熟悉的原因，浪费更多的时间去寻找解决方法，而且找到的方法不一定是最好的，说不定还不如你自己用熟悉的语言解决来的快。

　　也许有朋友会说：“这几种开发语言和数据库我都熟悉”，那么就要看你对这几种开发语言和数据库的熟悉程度了，对各种开发语言和数据库的特性了解的越深入，越有助于提高开发效率。而且目前主流的开发语言和数据库都提供性能调优，只有深入了解了开发语言和数据库的特性和原理，那么性能调优就很容易。

　　个人觉的重要的就这两点，开发效率和性能。

　　b） 成熟框架还是自己实现

　　目前主流的开发语言的使用者中有很多前辈都提供了他们自己总结实现的框架，比如JAVA中的“S-S-H”组合，PYTHON的DJANGOO等。我个人的一些经验是，尽量使用开源的成熟框架，因为平台研发初期使用成熟的开源框架，能提高开发效率，并且在质量上有保证。我曾经接手过一个平台的改版，框架是前面开发人员自己写的，里面的一些设计思想不是很成熟，导致平台在负载增高后性能很差，整改起来很麻烦，只能一点一点的分离出来，耗费时间和经历。

　　有的朋友可能会问什么才是成熟的框架，个人总结的几点：

　　1 能提供使用指南，比如 COOKBOOK， USE GUIDE等。有这些提供，那么入门使用变的容易，也方便维护，而且有助于深入了解其特性和原理。

　　2 有官方支持，比如官方讨论社区，邮件列表等，并且有BUG收集处理机制。有句话叫大树底下好乘凉，有了官方支持，当使用过程中遇到问题的时候，直接就可以通过查找前人的使用心得和问题来解决问题，遇到BUG的时候，提交上去，也能找到解决之法。

　　3 官方在不断的更新发布稳定版本。这一点很重要，官方如果及时帮你解决目前已知的或者未知的BUG，那么对使用者来讲，就没什么后顾之忧了，如果官方停止更新了，那么我建议还是早点换下家吧，因为如果这个框架好，那么肯定会越来越好，官方也会不断的更新它。还有就是稳定永远是第一位，可以在不影响生产环境的情况下进行无缝升级更新。

　　4 身边使用者很多，经常能看到相关的讨论或者总结。目前很多成熟框架都是国外开发者发布的，如果使用者E文不好也是个讨厌的事情，那么如果身边有很多同样的使用者和很多讨论，那么对于使用者来说是种福音，共同探讨和学习。

　　那么除此之外最好是开源的框架，平台初期访问量不大，因此对性能的要求不高，成熟的框架的使用都不会出现什么问题。当访问量急剧增高之后，那么性能要求也变高，一些框架中隐藏的问题也因此出现。这时候如果是开源的框架，使用者可以深入了解它的源代码，洞悉其实现机制，根据自己的实际情况进行调优。如果不是那么使用者也只能改变方向去解决问题，条条大路通罗马。

　　c） web server/db server/cache server 相关

　　在架构设计中web server/db server/cache server是很重要的一点，我个人觉的这一块必须是使用具有前瞻性，易配置，能监控和维护的产品，总结的几点：

　　1 丰富和深入的配置选项。如果能提供丰富和深入的配置选项，那么在安全和性能调整上可以很方便的进行操作，并且不中断实际的生产环境。

　　2 基于高并发模型。比如这几年热门的基于epoll的nginx，可以有效的减少连接处理时间，增大同时并发数。

　　3 支持负载均衡和请求分发。当平台的访问量增高之后，单台服务器肯定是很难支撑，这时候就需要增加服务器来分担压力，这时候server的负载均衡和请求分发就很重要了。

　　4 高效的缓存机制。高效的缓存机制可以帮助平台提高负载能力，减少重复资源的读取和处理时间。比如用于小文件缓存的SQUID，VARNISH，用于数据库缓存的memcached等。

　　5 实时的状态监控机制。实时的监控状态报告，可以有助于平台维护人员迅速了解平台性能运行状况，根据状况进行调整。

　　如果是开源的那就更好了，可以深入了解其源代码，并根据自己的实际需要进行配置和定制。

　　d） 操作系统

　　选择合适的操作系统，个人觉的最主要是稳定安全，易管理和维护，易监控。稳定安全的操作系统一般官方会持续的发布补丁和新版本，解决BUG和漏洞等。并且官方或者第三方会不断的提供新的管理维护监控工具，并且能让管理维护人员通过编写脚本来维护管理。而且合适的操作系统能让研发人员充分利用其特性，发挥平台的最大性能。

　　f） 物理架构

　　这里的物理架构是指服务器的搭建方式。有的朋友可能资源有限只有一台服务器，有的朋友资源充分有十几台服务器或者更多，我个人觉的这都不是问题。平台初期的话，我想大部分访问量都不高，web server/db server/cache server放在一台服务器上都没问题。但是自己心里最好能预估一下这个平台会发展到什么样的规模，在做架构设计的时候，按照事先预估的来决定怎么做物理架构，并为以后的架构升级做准备。说到这里，想到前百度架构师雷鸣说过的一句话，当你的会员数达到目前的5倍或10倍的时候，架构就要升级。

　　二 平台研发

　　前期做好了技术方案，就进入到实质研发过程中来了，个人感觉平台网站的研发有别于传统的IT项目研发，因为以前就是客户/需求分析人员/美工之间进行交涉，而现在平台网站研发会多接触一个角色叫产品，产品决定了最后的平台网站是什么样的，有什么功能，每个功能的流程和用例是什么样子的，也就是原型设计。并且在研发人员实现之后，还要由测试人员进行测试。关于原型设计，请看我的另外一篇文章《项目需求原型设计》。

　　在上述过程中，产品会经常要求研发人员：“某某功能是这样的，你赶快给我实现并解决。这个功能不对，要改。那个功能出现问题，要改”，而研发人员可能正在忙着其他功能的实现，于是很容易产生冲突。在此我推荐使用敏捷开发方式，设立短的发布周期进行迭代开发，产品提出来的问题统一在一个周期内解决，到下一个周期一起发布，到下一个周期再进行下一周期的功能改进和BUG修正。并使用JIRA这种成熟的项目管理系统进行管理，为以前的更改留下历史，总结经验。

　　那么在正常的研发过程中，特别是团队研发，我个人觉的需要注意的几点：

　　1 合适的开发工具。还是那句话“工欲善其事，必先利其器！”，使用合适的开发工具和插件，能提高开发效率，节省开发成本。团队使用统一的开发工具，可以减少出错的几率，防止版本冲突等。

　　2 如何控制代码质量。因为团队里大家的水平有高有低，所以团队研发的时候，需要去建立固定的开发规范，比如：“命名规范”，“代码包引用规范等”。当某个人解决某个功能的时候，为了确保代码质量和减少出错几率，最好能画出流程图和配上设计意图说明，来进行讨论确定，同时也可以帮助新人快速成长。

　　3 需要引入新框架。有时候，某个成员会觉的某某框架的新特性非常好用或者非常合适手头的问题，那么就想引入这个新框架，我的建议，在充分了解的基础上来决定，不能因为某个特性而引入一堆用不到的特性，那样会让项目代码显的冗余。

　　4 知识总结和培训。当某个成员遇到问题，并解决后或者学习到新东西的时候，不妨拿出来大家一起探讨一下，说不定就有助于提高平台的性能，为大家提供更好的设计思路。

　　三 架构优化

　　“过早优化是万恶之源”，所以关于架构优化，我放在研发完成并上线之后来讲。个人觉的没有百分百可用的架构，得看你实际的业务流程和运行情况来进行优化。当你运行了一段时间后，收集到一定的数据，找出性能的弱点后进行针对性调整和优化，当平台的负载强度达到一定程度，就得立即着手做架构升级。

　　有的朋友会问，有时候网站就是莫名其妙的变慢，但是不知道从何下手怎么办，或者凭经验改改这个改改那个选项，好了一点但好的不彻底。我的经验是从数据开始，从最外围开始画圈，找到源头。先从外围开始收集日志，比如access_log访问日志或sql_log数据库操作日志，找出访问最多的10条日志和执行时间最长的10条日志，然后根据日志去反查到底是什么引起的操作，然后一条条的解决。如果解决不了，那么就考虑重构。其他问题解决方式跟这个差不多，就不赘述了。从我自己已有的经验来看，往往就是因为几个功能点的恶化，引起了整体的性能变差。

　　所以在研发的时候，功能点的实现要好好考虑，前端部分，页面，图片等的大小和有效缓存，后端的局部数据和全局数据的缓存高效利用，数据库层SQL语句尽量避免跨表查询，数据库索引的利用等。

　　四 其他相关

　　存储

　　当平台网站的访问量不断增长的同时，数据也会跟着不断的增长，所以早期做好数据如何存储的方案非常重要。

　　现在比较常见的是HASH URL，根据文件名的HASH来选择存储不同的目录，比如20091014131213_abc.xxx 那么就存储到 2009/10/14/a/20091014131213_abc.xxx这样的目录下，方便以后根据目录来划分服务器。

　　搜索

　　当平台网站的访问量不断增长的同时，数据搜索也变成了一个问题。肯定有朋友会说，直接数据库模糊查询有什么问题，你试想当你的数据表里有几百万数据你用select * from table where title like '%key%' 没法用索引，那就是全表扫描，拿得花多少时间，一个人查询还没问题，那几百个呢，那你的平台不就歇菜了。还好现在已经有了成熟方案Lucene，只要按照它提供的接口去实现，你就可以使用。

　　五 相关资料

　　架构实例

　　新型的大型bbs架构（squid+nginx）

　　nginx图片服务器的架构方案

　　来源：读者欧拉投稿 QQ：4465618