写点什么

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

  • 2007-08-07
  • 本文字数:2122 字

    阅读完需:约 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?

2007-08-07 23:211324
用户头像

发布了 255 篇内容, 共 63.9 次阅读, 收获喜欢 10 次。

关注

评论

发布
暂无评论
发现更多内容

如何使用Python去除文件后缀名?

霍格沃兹测试开发学社

Sora给你带来的真实变化

脑极体

AI

雷龙科技Nand flash芯片试用体验

芯动大师

存储 芯片 Flash

【教程】为什么要为 App 应用加固 ?如何为 App 应用加固 ?

美国科技行业今年裁员超 5 万人;宁德时代一年净赚超 440 亿丨 RTE 开发者日报 Vol.167

声网

What’s new in Apache/dubbo-getty 1.4.10

apache/dubbo-go

牛刀专业低代码开发实战—配件出入库管理

牛刀专业低代码

低代码开发 低代码平台 牛刀低代码 牛刀专业低代码

低代码助力企业数据资产价值升级

Crabc低代码平台

低代码 数字化 数据服务

招个Java工程师,却发现了一个宝藏平台

王磊

Java 面试

【教程】苹果iOS证书制作教程

Python教程:如何获取颜色的RGB值

霍格沃兹测试开发学社

被 AI 写的游戏代码砸中是什么感觉 | 10 分钟打造你的超级 AI 编码助手

阿里巴巴云原生

阿里云 云原生 通义灵码

ChatGPT教程:使用资源聚合盘点—入门、GPT工具、AI工具

蓉蓉

openai ChatGPT GPT-4

从海外开发者大会的亲身体悟聊起,谈谈 AI 与开发者关系的重构 | 编码人声

声网

Java 文件处理完全指南:创建、读取、写入和删除文件详细解析

小万哥

Java 程序人生 编程语言 软件工程 后端开发

2023 re:Invent 使用 PartyRock 和 Amazon Bedrock 安全高效构建 AI 应用程序

亚马逊云科技 (Amazon Web Services)

生成式人工智能

[人脸修复]基于CodeFormer的人脸修复模型配置

alexgaoyh

环境配置 CodeFormer 人脸修复 人脸复原 旧照片修复

探秘服务器云托管的优势与特点,助你选择最佳方案

一只扑棱蛾子

Python实现:教你轻松统计文件夹下文件个数

霍格沃兹测试开发学社

牛市下 AI + Web3 叙事引关注,Verasity 或成又一黑马项目?

股市老人

arthas火焰图(async-profiler)在云交易中的运用

京东零售技术

后端 效能提升

《Java核心技术·卷 I(原书第11版)》PDF

程序员李木子

深度解析大模型:概念、架构与应用价值

木南曌

AI 大模型

Github 每日热榜 2024.03.18

天马行空的大杂烩

程序员 开源软件 最新软件

真正的线性可伸缩性需要新的模式和中间件架构吗?_架构_Johan Strandler_InfoQ精选文章