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

作者 Johan Strandler 译者 胡键 发布于 2007年8月7日

领域

架构 & 设计,

语言 & 开发

主题

集群与缓存 ,

架构 ,

性能和可伸缩性

在构建线性可收缩应用时，需要新的模式和中间件架构吗？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?

译者 胡键 热心开源技术，《开源技术选型手册》作者，《SOA实践指南》译者。目前致力于Groovy/Grails的研究和推广。

1. 返回顶部

   这个是我正在想的事情

   发表人 Lv Jili

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

   回复

2. 返回顶部

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

   发表人 胡 键

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

   回复

• 更早的 >