主题：【原创】wikipedia架构学习笔记（一）他们的骄傲 -- 羽羊

网站做大了，一台服务器是不够的。

服务器多了，其实真不是好事儿，大有大的难处。

wikipedia的服务器有好几百台，其中web的至少要超过二分之一，这么多的服务器，扑面而来的，不是好处而是问题。

不信？往下看

再看看wikipedia的：

外链图片需谨慎，可能会被源头改

外链图片需谨慎，可能会被源头改

这里头可以说道说道了。

前一个例子（就叫A网站吧）其实和wikipedia一样，部署了CDN，区别在于wikipedia的CDN有统一的入口，A网站采用了要求用户自行选择的方式，作为一个用户，首先肯定感觉晕菜，作为一个搞web的，个人能理解网站技术人员的难处，同时替他们可惜，这么多镜像站点的维护，本身就足够nb了，可惜万里长征就是不愿意走完最后一步，再花点力气整合一下多好，但是反过来想想，是不是读西厢流泪了？A网站实现wikipedia的模式应该不会有技术上不可逾越的问题，那么这种选择肯定有他们的原因。

挂一漏万的分析一下A网站模式的好处：

1、用户自主选择入口，对于运营商之间存在瓶颈，而且瓶颈本身都不稳定的环境，有必要，至少用户可以多试几次，找到对于自己来说最快的节点。

2、网站的部署简单，只要关注内容的同步即可，甚至某些特殊情况下可以故意造成内容不同步，且不用考虑缓存、反向代理因素，技术复杂度低。

3、如果是商业站点，那么就类似与连锁加盟的模式，在共担投资，分享收益方面责权利清晰。

4、有利于提升用户知识水平。

这些好处当中，第三条和wikipedia半毛钱关系都没有；第四条虽然也是wikipedia立站之本，但好像wikipedia没打算通过行为艺术的方式达到目的；至于第二条，对于一个大网站来说，缓存和反向代理是必要的技术手段，A网站看似规避了这样的问题，但是某一个镜像站点如果压力过大，那么终归还是躲不过去的，难不成到时候再弄个XX镜像2？在这样的技术问题上，wikipedia的性格取向就是“硬扛”，用技术的方法解决技术问题；第一条在某些特殊环境下有效，比如中国内地，但大部分场景并不靠谱，河友就有精彩论断“物理距离近，速度未必快”，原因就在于还存在着诸如镜像服务器负载、机房接入带宽、运营商抽风、奥运开幕、CCTV曝光等等靠用户本身并不能确定的因素。

再看看Wikipedia模式的好处：

1、统一的网站入口，用户体验好。这一点很重要，内容的提取和返回是网站的义务，提升网站性能，还是要 靠 自己。

2、具备内部的负载均衡和健康检查机制，节点负载比较均衡，网站整体性能较好。

3、可以部署统一的缓存或者反向代理方案，进一步提升网站整体性能。缓存和反向代理是个好东西。但是在部署管理方面困难不少，如果非要部署的话，那么还是设计好整体架构，然后一次部署的好，反过来说，镜像网站存在部署N次的风险，wikipedia的模式看似“硬扛”，事实上还是走了捷径。

4、可以把自己的方案综合起来，做个技术网站，或者到会议上做presentation，让人家学习并且景仰。

这样子来说，局外人看起来，还是wikipedia模式好阿。

慢着，这篇两次提到了“硬扛”这个词。

“硬扛” ——状中短语，扛：两手举重物，硬：倔强，执拗地。举重物，还倔强、执拗的，看起来搞wikipedia模式这活儿不轻阿。

其实真不轻。