大型系统架构中的BASE思想及可伸缩性最佳实践.doc

大型系统架构中的BASE思想及可伸缩性最佳实践.doc

  1. 1、本文档共9页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
大型系统架构中的BASE思想和可伸缩性最佳实践 之前我在一篇blog中有提到一个例子,/lovingprince/archive/2008/08/21/2807986.aspx ,我称之为业务事务,其实可能定义有点偏颇,不过表达的意思很明确,即使用业务的方法来保证最终数据一致性,尽量避免使用分布式事务。 这几天我看到一篇文章,恍然大悟,才明白原来这种思想本来早就有了它的专业术语:BASE. 这里我来和大家分享一下,BASE其实是下面三个术语的缩写: 基本可用(Basically Available) 软状态(Soft state) 最终一致(Eventually consistent) 它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢,缘由就在于大型系统往往由于地域分布和极高性能的要求,不可能采用分布式事务来完成这些指标,要想获得这些指标,我们必须采用另外一种方式来完成,这里BASE就是解决这个问题的办法。 具体的理论基础,我也就不说了,这里我给大家推荐几篇更专业一点的文章,大家自己去研究研究吧: 1. /cn/news/2008/03/ebaybase 很好的以ebay为例子的BASE介绍 2. /groups/IEEE/ind-acad/brewer/index.htm 专门介绍BASE的PPT哦,呵呵 3. /cn/articles/ebay-scalability-best-practices 说起ebay,那我就推荐一个和base无关的,他的 架构介绍吧 4. /cn/interviews/fengdahui-database-architecture 这个是支付宝数据库架构师冯大辉先生的见解(和BASE无关,呵呵) ---------------------------------------------------------------------------------------------------------------- 作者 Randy Shoup译者 郭晓刚 发布于 2008年6月12日 下午7时5分 在eBay,可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策,身前身后都能看到它的踪影。当我们面对的是全世界数以亿计的用户,每天的页面浏览量超过10亿,系统中的数据量要用皮字节(1015或250)来计算——可伸缩性是生死交关的问题。 在一个可伸缩的架构中,资源的消耗应该随负载线性(或更佳)上升,负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消耗,可伸缩性则是衡量当工作单元的数量或尺寸增加时,资源消耗的变化情况。换句话说,可伸缩性是整个价格-性能曲线的形状,而不是曲线上某一点的取值。 可伸缩性有很多侧面——事务的方面、运营的方面、还有开发的方面。我们在改善一个Web系统的事务吞吐量的过程中学到了很多经验,本文总结了其中若干关键的最佳实践。可能很多最佳实践你会觉得似曾相识,也可能有素未谋面的。这些都是开发和运营eBay网站的众人的集体经验结晶。 最佳实践 #1:按功能分割 相关的功能部分应该合在一起,不相关的功能部分应该分割开来——不管你把它叫做SOA、功能分解还是工程秘诀。而且,不相关的功能之间耦合程度越松散,就越能灵活地独立伸缩其中的一部分。 在编码层次,我们无时不刻都在运用这条原则。JAR文件、包、Bundle等等,都是用来隔离和抽象功能的机制。 在应用层次,eBay将不同的功能划分成几个应用程序池。销售功能由一组应用服务器运行,投标功能由另一组负责,搜索又是另外一组服务器。我们把总共约16,000台应用服务器分成220个池。这样就可以根据某项功能的资源消耗,单独地伸缩其中一个池。我们也因此得以进一步隔离及合理化资源依赖关系 ——比如销售池只需要访问后台资源的一个相对较小的子集。 在数据库层次,我们也采取同样的做法。eBay没有无所不包的单一数据库,相反我们有一组数据库主机存放用户数据、一组存放商品数据、一组存放购买数据……总共1000个逻辑数据库分布在400台物理主机上。同样,这种做法让我们得以单独为某一类数据伸缩其数据库设施。 最佳实践 #2:水平切分 按功能分割对我们的帮助很大,但单凭它还不足以得到完全可伸缩的架构。即使将功能一一解耦,单项功能的资源需求随着时间增长,仍然有可能超出单一系统的能力。我们常常提醒自己,“没有分割就没有伸缩”。在单项功能内部,我们需要能把工作负载分解成许多我们有能力驾驭的小单元,让每个单元都能维持良好的性能价格比。这就是水平分割出场的时候了。 在应用层次,由于eBa

文档评论(0)

189****6140 + 关注
实名认证
内容提供者

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

1亿VIP精品文档

相关文档