IT系统对比.doc

  1. 1、本文档共3页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
IT系统对比

前不久,一则中行宕机的消息引起了网上IT人士的热议。其中对于大型机或者RISC系统的稳定性可靠性的质疑更是热议中的主流声音,很多人拿现在互联网系统做对比,认为大型机所谓的几个9都是吹出来的云云。在这里我想说几句公道话:首先,这次宕机到底是什么原因,什么形式的宕机我们都没有很清楚的了解,在这种情况下就去评论大型机或者RISC系统的稳定性或者可靠性其实都是不负责任,站不住脚的。但是,我觉得倒是可以基于这次的事件来稍微发散一下,说一说我对互联网系统和传统企业IT系统的一些看法和观点。 现在被炒的很火热的互联网,云计算架构,其相对于传统的大型企业系统架构,最大的区别就是以 HYPERLINK /art/201209/357433.htm \t _blank 分布式的架构去替代原先的集中式系统架构。 打个比方,原先的大型企业系统架构,就好像一架大型的民航客机。作为出行来讲,飞机无疑是最舒适最快的交通工具,同时安全性也很好。但飞机却也不是人人都能坐的。首先:做飞机要经过换领登机牌,安检等若干道手续,乘客必须提前一个多小时到机场办理各种手续,而坐火车大巴则随到随买随上车,方便的多;其次:坐飞机很多东西不能随身携带甚至不能托运,火车大巴则相对宽松;还有:机票很贵坐飞机花销很大而且飞机运载能力也不如火车。当你有数万数千人要一次性到达某地时,一两架飞机的运载能力根本不够,要调动成批飞机的话整体成本又太高。最后:虽然飞机很少出事故,飞机一旦出现事故的话危险级别往往都会很高。 但是,以前除了飞机之外,就只有火车,大巴这种交通方式选择了。相比之下,这些方式虽然收费低廉,乘车,携带物品都比较方便,但是速度实在太慢而且受外界因素诸如雨雪等等的影响太大,乘坐也不是很舒适。只能满足那些相对时间宽裕,或者囊中羞涩人群的出行需求。 于是,为了满足更多人,更便利更高速的交通运输需求,新的交通运输模式—动车/高铁就出现了。它和火车最大的区别是:火车只有一节车头有动力,后面能拖几节车厢跑多快基本就是看一个车头有多强劲。但个体的力量终究有限,一个车头再强劲也有个极限,发展???间也就那点了,实在难以有太大作为。动车则不同,它每节列车都独立有自己的动力系统,连在一起各节车厢动力系统就是一个叠加递增的关系。所以理论上越多节车厢接在一起就可以拉更多人跑的更快,是一个无限扩展的系统!而且因为动车可以搭载的乘客很多,所以均摊到每个乘客头上,坐动车的速度可以某种程度上接近坐飞机,但成本要低很多。 现在互联网,云计算的系统架构其实和动车的理念相类似,就是分布式系统的架构 – 将任务分解交由每个小计算单元进行分布式的并行处理,充分利用每个单元的计算和存储能力,理论上性能可以无限线性扩展,任何一个节点的故障不影响整个系统的运行,整个系统没有单点故障。 也就是说:我们可以简单把大型企业核心架构,或者说就是大型机,RISC系统比作飞机;而把互联网,云计算的系统架构比作动车。现在,就可以做些很有意思的讨论了。 还是来说说稳定性和可靠性:就说2012年吧,飞机也好,动车也好,新闻里面都有报道过出现严重事故,可见没有一种系统是完全稳定可靠不会出现任何宕机风险的,但是其概率都是非常非常小的。从整体来讲,都是很稳定很可靠很安全的选择。只不过各自对于如何防灾冗余的策略还是有些不一样。先说飞机,因为飞在空中,万一出了事情没有后备可用,所以能采取的方式只有想尽一切办法提高飞机自身个部件的冗余度,设计时尽可能多的考虑各种小概率事件。哪怕发生某故障的概率只有千万分之一甚至亿万分之一,只要有可能,也要把应对措施设计进去。这也是飞机造价为什么会那么高,对携带物的要求会那么多的原因。而动车则相对简单:反正多拖几节车厢又不影响我速度,那我就尽量多拖些备用车厢跑着呗。万一某节车厢出事了,就把里面乘客挪到备用车厢里,车照样跑得欢。然后等到了站再去更换检查有问题车厢也不迟。 回到IT世界也是一样。分布式系统基本都是基于x86的PC服务器。单就一台服务器而言,虽然性能可靠性在不断加强,但肯定还是不如RISC系统的。但是没关系,咱可以用数量来弥补单机冗余度的不足啊。设计没你好冗余度没你考虑的多我就多拉几台呗。坏了几台没事,应用任务再分配到别的空闲机器上就好了。坏了的机器也不用马上修,反正没坏的机器加起来也够用。等到故障机器到了一定数量我再一次性批量检修更换部件效率更高。对于用户来讲,即使我坏了100来台服务器只要剩下的服务器还能正常工作,应用就不会受任何影响。谷歌,Facebook那些超大??数据中心现在的工作思路大致如此。这么做看起来是个很简单有效,很聪明的方法,但其实也有不少问题存在。 首先我觉得这个架构好处是实现原理简单,而且扩展性弹性比起RISC架构来好处不言而喻。但其实这个架构里面也存在着无谓的资源浪费可能性。例如

文档评论(0)

qwd513620855 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档