Oracle RAC之外的方案 无需重写而实现读写扩展性

Oracle RAC之外的方案 无需重写而实现读写扩展性

编者按：对现有系统进行扩展对于各个技术团队而言都是或大或小的挑战。尤其对于银行这种业务而言，由于要照顾到现有的系统（也就是现有的客户），不太容易通过修改架构或系统重写的方式来实现扩展，一般的做法就是用Oracle RAC等高端硬件来弥补现有扩展性的不足，但是这个做法相对昂贵。本文作者，专注于Java和.NET应用平台的GigaSpaces公司创始人兼CTO Nati Shalom以其一个银行客户Avanza为例，介绍了另一种扩展性的解决思路，其原则就是：无需重写而实现读写扩展性。

相关阅读：Oracle 11g中定位trace文件简便办法

以下为正文：

上周我参加了我们某位合作伙伴于斯德哥尔摩举办的研讨会，在该活动中我提出了数据扩展性领域的整合趋势——特别是从NoSQL向NewSQL的过渡以及整合趋势使得现有SQL及NewSQL更紧密地联系在一起。正如我在自己之前的某篇文章中就已经指出过的，“YeSQL：一种只存在于后SQL领域中，对各类Query语义进行归纳的概括。”

在本次活动中，Ronnie Bodinger——Avanza银行的IT部门主管给出了精彩的评述，详尽说明了他们是如何将既有银行业务应用程序迁移至读写扩展性更好的新站点的。

Avanza系统概述：

Avanza是一家瑞典银行，以为投资者提供便利的产权交易及资金转移业务而闻名。它同时处理着斯德哥尔摩证券交易所中最大比例的交易活动。

该银行通过网上银行系统为其投资者提供服务，其目前的在线系统所使用的是典型的基于Java，JSP及Spring的站点。

现有站点的架构扩展

目前绝大多数站点的交互功能都以读取访问居多，而扩展性方面最主要的挑战是对现有并行读取操作进行调整。读取扩展是由端点缓存结构处理的，该结构通常存在于多数现有的LAMP及分布式缓存部署当中。在那里的首个查询指令指向数据库，而其后的查询指令则指向缓存内容。

新系统

新网站的设计理念要求契合当前的实时同步及社交使用的需求。这就意味着大多数流量及网络活动如今都是由用户所发起，而不同于以往常见的由网站所发起。此外，这类指令的执行过程及结果必须实时提交给使用银行业务的所有用户。

挑战

新网页的变更会带来流量及负载响应方面的一系列变化，这些变化无疑对扩展性提出了更高的要求。

写入扩展性

当我们现有的端点缓存架构需要应对大量的更新活动时，其性能表现就会大打折扣。这时缓存响应速度会变得极为缓慢，缓存同步过程也会因此成为一项增加开销却毫无效果的工作。

采用甲骨文出品的RAC高端硬件平台同样无法收到理想的结果。该解决方案不仅贵得离谱，同时也无法契合保证扩展性所必需的各项要求。

与从零开始建造一个应用不同，Avanza目前已然建立起一套服务现有客户群体的在线应用程序。这又带来了以下列举的数项额外挑战：

◆现有数据模型

与应用程序配套的整套数据模型是由这样一种模型关系所衍生的。数据模型的改变或将其迁移至新的NoSQL架构都会被认为将引发巨大的变化，而这些变化可能会在今后的数年时间中持续带来各种不利影响。

◆系统残余

网上银行应用程序中包含着大量残余的应用程序及第三方服务内容。由于其对第三方工具的依赖性，对现有基础设施进行重写既不可能也不实际。

◆复杂的环境

由于通常情况下，很大一部分的剩余应用程序在设计过程中都没有考虑到扩展性的需要，并且也不具备明确的整体架构，因为多年以来这类程序的编写一直习惯于采用分层处理的方式。这也使完善扩展性的复杂程度更进一步。

◆现有基础知识

现有的开发团队在Java及Java EE方面具备良好的知识与技巧，而强迫团队/开发小组立即接受一套全新的基础知识不仅仅是一项沉重的负担。这种毫无缓冲的高速发展要求以及随之而来的系统复杂性也可能会成为难以逾越的巨大障碍，并且需要耗费数年时间才会被克服。

1 2 下一页

【内容导航】
第1页：情景描述	第2页：解决方案