五千年(敝帚自珍)

主题:【原创】wikipedia架构学习笔记(一)他们的骄傲 -- 羽羊

共:💬62 🌺262
全看分页树展 · 主题 跟帖
家园 【原创】大有大的难处——硬扛

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

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

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模式这活儿不轻阿。

其实真不轻。

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河