非推倒重来式的读/写伸缩扩展

Avanza银行是一家瑞典的银行,让投资者易于作出股权交易和基金交易。它通过自己的在线银行提供很好工具给投资者使用,当前在线系统是典型的基于Java/Jsp和Spring的Web网站。

当前大部分操作是读取,主要可伸缩性的挑战是并发读操作,采取的是目前很多系统采取的架构LAMP + Memcached,第一次从数据库中获取,以后直接从缓存中获得。

新的系统改造将设计目标为实时性和社会性领域,这就意味着很多内容将不是由网站管理者来产生,而是由用户自己来创造,由此带来新的大量的流量和活动。

系统将改变到以流量负载为主要目标。

写伸缩的挑战:
前面提到的数据库之前缓存(side-cache)的问题是带来副作用,由于大量数据更新,导致缓存中的数据过时,同步缓存增加了开销。

使用Oracle RAC 并没有象它宣称那样,而且成本非常昂贵。

不像一些Green Field绿色领域应用,Avanza 有自己的在线应用,属于Brown Field,这就带来如下问题:
已经存在成熟的数据模型,整个数据模型设计为关系数据库,将这些关系数控模型迁移到NoSQL架构,将耗费几年的努力。还有一些遗留系统,重写这些遗留系统几乎是不可能的。还有复杂的环境。

采取不重写整个系统前提下进行读写伸缩扩展:
1.圈定需要伸缩扩展的范围

2.保留数据库,在数据库之外进行读写伸缩,这样不必改变数据库表结构。

3.将数据网格In Memory Data Grid(IMDG)放在数据库之前。IMDG中包含所有热点表或数据表记录,在线Web应用将访问IMDG而不是数据库,IMDG可分布地将读写操作分散到集群服务器上。

4.使用write-behind策略减少过多的同步负载。将IMDG中数据持久更新到下面的数据库中是使用异步的批操作,这是通过一种内部查询机制( internal queuing mechanism (redo-log))

5.使用O/R mapping等框架将IMDG中对象数据和关系数据库进行映射,例如Hibernate或OpenJPA。切分数据带来好可伸缩性,但是这不代表改变数据表结构,在IMDG数据网格中保存的是另外一种不同于数据库表格式的可切分数据格式应为一种领域对象模型格式)。

6.使用标准的Java API,例如IMDGs使用 GigaSpaces提供的标准 APIs, 比如 JPA等等,能够在创新和继承已有之间取得技能上的平衡。

7.使用两个并行站点促使逐步转换。

最后的软件架构如下:


原文:read/write scale without complete rewrite

我认为Avanza银行的内存数据模型IMDG和我之前一直倡导的内存中领域模型应该是同一个概念,如下图:

我曾经在下面帖子把我们倡导的缓存Cache与普通Cache区分开来,认为是一种内存模型,方便大家辨识:
Spring 3.1 终于加入了Cache支持

使用了IMDG,也可以帮助我们更好地采取面向对象的思维方式,以对象生命周期为第一切入点考虑:
关于对象的生命周期问题
[该贴被banq于2011-06-08 08:22修改过]

一些Green Field绿色领域应用,Avanza 有自己的在线应用,属于Brown Field,这就带来如下问题:
已经存在成熟的数据模型,整个刷信用数据模型设计为关系数据库,将这些关系数控模型迁移到NoSQL架构,将耗费几年的努力。还有一些遗留系统,重写这些遗留系统几乎是不可能的。还有复杂的环境