BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

真正的线性可伸缩性需要新的模式和中间件架构吗?

| 作者 Johan Strandler 关注 0 他的粉丝 ,译者 胡键 关注 0 他的粉丝 发布于 2007年8月9日. 估计阅读时间: 6 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

在构建线性可收缩应用时,需要新的模式和中间件架构吗?GigaSpaces的CTO,Nati Shalom认为,现有中间件是为以分层为基础的方法而设计的,它们不适合真正的线性可伸缩架构。他提出了新的基于自给自足处理单元的中间件栈(middleware stack)作为替代,它支持分区/向外扩展(scale-out)模型。虽然Shalom提出了一个新的中间件栈,但是几年前,微软的Pat Helland就提出了某种事务性模式及形式描述,它们可被用在被他称为准无限可伸缩的系统中。

Nati Shalom声称分层方法(消息传递、数据和业务处理)是一个死胡同,因为在每一层中和层与层之间,它引入了很多状态和“往返的消息”,这样做的目的仅仅是为了保持共享数据的同步。他指出分层方法注定提供非线性可伸缩性,为了使吞吐量线性增加,就必须按指数增加新CPU数目。

Nati提出了一种不同的替代架构方法,该方法中,这些分层被一起放入一个处理单元,确保消息传递、数据和处理发生在相同地址空间内。结合处理单元间的无共享架构(share-nothing architecture),当处理需要增加时,只需增加机器即可,这样它就给出了一个线性可伸缩解决方案。这个模型显然非常适合无状态应用,但是对于有状态应用,事情变得有些复杂。之前,Nati曾提及如何伸缩一个有状态应用。他通过2个基本规则:

  1. 你需要减少相同数据源上的连接。
  2. 你需要移除你的应用中不同单元间的依赖。只有每个工作单元是自给自足,同时不和其它单元共享任何东西,你才能获得线性可伸缩性。

这些是可伸缩性的基本原则。在有状态环境中,要实现这两个原则的一般模式是使用分区,即,将你的应用拆成不同的工作单元,每个单元处理你应用数据特定的子集。接下来,你就可以简单地通过增加更多的处理单元获得伸缩性。

如果数据可被划分成分离的应用数据子集,那么一个应用可以被向外扩展成许多独立的处理单元,其中每个单元拥有子集所需的全部数据。可用这种方法划分的典型数据的例子是Web应用的会话信息。然而,当很多应用进程需要访问/更新相同的共享数据时,这种分区模型不起作用。 Shalom说:“在这种情况下,数据可以通过远程分区被引用,即业务逻辑和消息传递将位于一个处理单元中,而数据在一个远程分区中——以这种方式,你仍然可以获得可伸缩性,虽然它有些滞后。”

但是,要是共享数据的容量巨大该怎么办?一种解决方案是,将同类数据分区进入不同的数据存储分区,但是这种解决方案需要解决两个主要问题:

  • 聚合。在非集中的数据存储上如何执行查询?(即跨越一个很多数据存储分区的查询)
  • 使用原子事务 VS 不使用原子事务。分布式事务可伸缩性不太好,因此需要其它的解决方案。

对于聚合问题,Shalom给出了解决方案:

你可以将查询并行化,这样每个查询针对不同的分区运行。这样做,你利用了每个分区内的CPU和内存能力,使你的请求被真正并行处理。注意,发起查询的客户端获得了被聚合的结果,而不知道分区是物理分离的,仿佛它基于单个的巨大数据存储运行,同时还有一个主要区别——它更快!

为了找出原子事务问题的解决方案,我们求助于Pat Helland,他已在一篇论文(“超越分布式事务的生命:一个变节者的意见”)中着手解决这个问题,该文作于他在Amazon.com工作期间。在文中,他总结:在大的伸缩性系统中,人们基本上不应该使用跨系统事务。

对于在构建可收缩系统中被使用的概念和抽象,缺乏广为人知的术语。作为对此的回应,Helland定义:

- 实体(Entities)是指定(键控)数据的集合,这些数据在实体内会被自动更新,但是更新从不跨实体发生。

- 活动(Activities)由实体内的状态集合组成,被用来管理与单独搭档实体的消息传递关系。

得出决定的工作流,正如已被讨论了多年一样,功能在活动中,活动在实体中。当人们在查看准无限伸缩性时,令人惊讶的发现,它具有工作流细粒度的天性。

通过这个定义,Helland指出在相同的事务中不能更新两个实体。作为替代,他采用了“事务可串行性的多重分离范围”,后来,在论文中他将这个范围定义为实体。在此定义下,一次多个实体的更新不能在单个原子事务中被执行,而必须通过跨实体的消息传递,以实体间P2P(Peer-to-Peer)的风格完成。这种消息传递引入了自身管理会话状态的需要,并且Helland将这种用于每个实体搭档的状态管理定义为活动。他给出了一个例子:

考虑处理一个订单,它包含许多要采购的项目。为每个单独项目的出货预留库存将是一个单独的活动。订单有一个实体,每个被仓库管理的项目有单独的实体。事务不能跨越这些实体被采用。

在订单内,每个库存项被单独管理。消息传递协议必须被单独管理。包含在订单实体中的每个库存项目数据是一个活动。尽管它不是这样被命名的,但是这个模式频繁出现在大规模应用中。

由于这种方法引入的实体和消息传递之间缺乏事务的原子性,它引起了新的问题,对业务逻辑完全隐藏了其踪迹;消息重试和处理必须能处理幂等性。对等实体间也需要异步消息传递——细粒度工作流的对等强制实现——包括取消/确认操作随后的试探性操作。

Nati Shalom所期望的架构已在GigaSpaces平台中被实现,它最近将发布版本6。Pat Helland的论文是永恒的,绝对值得细细品味。

查看英文原文:New patterns and middleware architecture needed for true linear scalability?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

这个是我正在想的事情 by Lv Jili

此应该能够成为下一代企业信息化模型,它具有足够的灵活性和可扩展性;而且,一切都会显有非常自然。

Re: 这个是我正在想的事情 by 胡 键

此新闻也具参考价值:www.infoq.com/cn/news/2007/07/azul。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT