[文章作者:张宴 本文版本:v1.0 最后修改:2009.05.28 转载请注明原文链接:http://blog.zyan.cc/post/414/]
“客户端访问”与“服务器端响应”,犹如一场战争。初期,访问量较小,弄几台服务器随便拉起一只队伍,就能抵抗住客户端的进攻。慢慢的,访问量大起来,这时候,就需要讲究排兵布阵、战略战术、多兵种协调作战。于是,开始有了负载均衡服务器、Web服务器、缓存服务器、数据库服务器、存储服务器等多兵种;开始有了系统架构等战略战术。随着新项目和运营需求的越来越多,我们开始了多线作战。慢慢地,我总结了以下一些思考:
1、“收编绿林队伍”与“自己招兵买马”:
两者的关系就犹如“使用开源软件、框架”与“自己开发模块、写框架”,如果已有的开源软件、框架、架构能够较好地用于自己的项目,并便于扩展,则优先使用开源软件;如果没有现成的东西,或者已有的开源软件性能不高、扩展性差、学习成本高,则可以取长补短,在项目中打造自己的“队伍”。
2、适当利用“雇佣军”:
在多个项目同时进行时,不要认为自己能打赢每一场战斗,而每一场战斗都由自己亲自去打。确实,我相信很多人能够打赢一场场战斗,却只有少数人能够打赢一场战争。前暴雪北方“四大佬”创建的旗舰工作室的倒闭,印证了这样一个事实:一群天才,却没有让一个划时代意义的游戏诞生。旗舰工作室放着捷径不走却事必躬亲,自己做客户端、自己做语聊系统、自己做图像引擎、自己做客服系统,最终自己被自己给拖垮了。
不要让战线拉得太广,适当利用“雇佣军”,项目中的一些非重要、非核心的组成部分可以购买其他公司的成熟产品与服务,时间、费用、维护成本可能要更低。最近,我工作中的两项服务使用了“雇佣军”:(1)、购买ChinaCache CDN的Flash Media Server点播加速服务,支撑金山游戏视频宣传站点,节省了部署多节点的成本和时间;(2)、购买快网的智能DNS解析服务,来做金山游戏官网动态内容“北京多线、珠海电信、天津网通”三个机房服务器的智能DNS解析服务,节省了收集、整理,将来更新维护IP信息等工作。
3、打造“高技术兵器”:
现代战争的特点都拥一个有共同的前提那就是:都不可能离开“高技术兵器”。同样,要想承担高并发访问,而又希望系统架构简单一点、程序开发快捷一点,那么,则需要一款服务器端的“高技术兵器”。Web 2.0网站主要组成部分有内容页和列表页,内容页可以采用key-value形式的Memcached、Squid等开源产品来实现缓存,高并发访问下需要实时更新的列表页缓存,目前还没有合适的开源产品来解决。MySQL等数据库在高并发连接、大数据记录情况下性能低下,实时更新的列表页,成为最主要的瓶颈。我目前正在基于一些开源类库,开发的一款简单关系型数据库,将实现MySQL单表拥有的大部分复杂条件查询功能,并将达到单表千万级以上记录下,Memcached 60%左右的并发查询性能,预计6月6日开发完成进入测试阶段。
4、精简军队,提高战斗力:
军队越多,补给、后勤等开支也会越大,同样,服务器越多,维护成本、托管成本、复杂度也越高。所以,服务器不是越多越好,在能够保证容错性、避免单点故障的情况下,如果能用一台高配置服务器来解决的事,不要同两台低配置的服务器来干。
传统的系统架构只不过围绕负载均衡设备或服务器、Web服务器集群、数据库服务器集群、搜索引擎服务器集群、分布式存储服务器集群、缓存系统服务器集群等等,技术含量并不是特别高,只不过很多人没有生产环境的机会去实践而已。随着内存价格的下降,单台服务器扩充到64G内存的事情不再罕见;Intel将会在下周面向高端服务器领域发布代号为Nehalem-EX的8核XEON处理器。随着硬件性能的不断提高,我预测,将来的系统架构与服务器集群将不再从服务类型上划分,而将按“CPU密集型服务器集群”、“内存密集型服务器集群”、“存储密集型服务器集群”划分。我现在所设计的架构与开发的服务器端程序,也逐渐向后者转移。
最近,Google的工程师Luiz André Barroso and Urs Hölzle发表了一篇长达120页的论文,提出了一个数据中心就是一台计算机(The Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines )
该论文全文下载(PDF):
“客户端访问”与“服务器端响应”,犹如一场战争。初期,访问量较小,弄几台服务器随便拉起一只队伍,就能抵抗住客户端的进攻。慢慢的,访问量大起来,这时候,就需要讲究排兵布阵、战略战术、多兵种协调作战。于是,开始有了负载均衡服务器、Web服务器、缓存服务器、数据库服务器、存储服务器等多兵种;开始有了系统架构等战略战术。随着新项目和运营需求的越来越多,我们开始了多线作战。慢慢地,我总结了以下一些思考:
1、“收编绿林队伍”与“自己招兵买马”:
两者的关系就犹如“使用开源软件、框架”与“自己开发模块、写框架”,如果已有的开源软件、框架、架构能够较好地用于自己的项目,并便于扩展,则优先使用开源软件;如果没有现成的东西,或者已有的开源软件性能不高、扩展性差、学习成本高,则可以取长补短,在项目中打造自己的“队伍”。
2、适当利用“雇佣军”:
在多个项目同时进行时,不要认为自己能打赢每一场战斗,而每一场战斗都由自己亲自去打。确实,我相信很多人能够打赢一场场战斗,却只有少数人能够打赢一场战争。前暴雪北方“四大佬”创建的旗舰工作室的倒闭,印证了这样一个事实:一群天才,却没有让一个划时代意义的游戏诞生。旗舰工作室放着捷径不走却事必躬亲,自己做客户端、自己做语聊系统、自己做图像引擎、自己做客服系统,最终自己被自己给拖垮了。
不要让战线拉得太广,适当利用“雇佣军”,项目中的一些非重要、非核心的组成部分可以购买其他公司的成熟产品与服务,时间、费用、维护成本可能要更低。最近,我工作中的两项服务使用了“雇佣军”:(1)、购买ChinaCache CDN的Flash Media Server点播加速服务,支撑金山游戏视频宣传站点,节省了部署多节点的成本和时间;(2)、购买快网的智能DNS解析服务,来做金山游戏官网动态内容“北京多线、珠海电信、天津网通”三个机房服务器的智能DNS解析服务,节省了收集、整理,将来更新维护IP信息等工作。
3、打造“高技术兵器”:
现代战争的特点都拥一个有共同的前提那就是:都不可能离开“高技术兵器”。同样,要想承担高并发访问,而又希望系统架构简单一点、程序开发快捷一点,那么,则需要一款服务器端的“高技术兵器”。Web 2.0网站主要组成部分有内容页和列表页,内容页可以采用key-value形式的Memcached、Squid等开源产品来实现缓存,高并发访问下需要实时更新的列表页缓存,目前还没有合适的开源产品来解决。MySQL等数据库在高并发连接、大数据记录情况下性能低下,实时更新的列表页,成为最主要的瓶颈。我目前正在基于一些开源类库,开发的一款简单关系型数据库,将实现MySQL单表拥有的大部分复杂条件查询功能,并将达到单表千万级以上记录下,Memcached 60%左右的并发查询性能,预计6月6日开发完成进入测试阶段。
4、精简军队,提高战斗力:
军队越多,补给、后勤等开支也会越大,同样,服务器越多,维护成本、托管成本、复杂度也越高。所以,服务器不是越多越好,在能够保证容错性、避免单点故障的情况下,如果能用一台高配置服务器来解决的事,不要同两台低配置的服务器来干。
传统的系统架构只不过围绕负载均衡设备或服务器、Web服务器集群、数据库服务器集群、搜索引擎服务器集群、分布式存储服务器集群、缓存系统服务器集群等等,技术含量并不是特别高,只不过很多人没有生产环境的机会去实践而已。随着内存价格的下降,单台服务器扩充到64G内存的事情不再罕见;Intel将会在下周面向高端服务器领域发布代号为Nehalem-EX的8核XEON处理器。随着硬件性能的不断提高,我预测,将来的系统架构与服务器集群将不再从服务类型上划分,而将按“CPU密集型服务器集群”、“内存密集型服务器集群”、“存储密集型服务器集群”划分。我现在所设计的架构与开发的服务器端程序,也逐渐向后者转移。
最近,Google的工程师Luiz André Barroso and Urs Hölzle发表了一篇长达120页的论文,提出了一个数据中心就是一台计算机(The Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines )
该论文全文下载(PDF):
下载文件
我想寻求一个能分地域的智能DNS服务,比如两电信服务器,上海用户访问上海电信,北京用户访问北京电信.
有知道的朋友请帮忙联系系下我:mail/msn: goao#msn.com
2009-6-1 11:06
最关键一点没有讲推荐看一篇文章“系统的力量”
还有这位兄台,能不能说一下网址,网上搜的话都是搞营销的,好烦!