【51CTO精选译文】编者按：对现有系统进行扩展对于各个技术团队而言都是或大或小的挑战。尤其对于银行这种业务而言，由于要照顾到现有的系统（也就是现有的客户），不太容易通过修改架构或系统重写的方式来实现扩展，一般的做法就是用Oracle RAC等高端硬件来弥补现有扩展性的不足，但是这个做法相对昂贵。本文作者，专注于Java和.NET应用平台的GigaSpaces公司创始人兼CTO Nati Shalom以其一个银行客户Avanza为例，介绍了另一种扩展性的解决思路，其原则就是：无需重写而实现读写扩展性。以下为正文：
上周我参加了我们某位合作伙伴于斯德哥尔摩举办的研讨会，在该活动中我提出了数据扩展性领域的整合趋势——特别是从NoSQL向NewSQL的过渡以及整合趋势使得现有SQL及NewSQL更紧密地联系在一起。正如我在自己之前的某篇文章中就已经指出过的，“YeSQL：一种只存在于后SQL领域中，对各类Query语义进行归纳的概括。”
在本次活动中，Ronnie Bodinger——Avanza银行的IT部门主管给出了精彩的评述，详尽说明了他们是如何将既有银行业务应用程序迁移至读写扩展性更好的新站点的。
Avanza系统概述：
Avanza是一家瑞典银行，以为投资者提供便利的产权交易及资金转移业务而闻名。它同时处理着斯德哥尔摩证券交易所中***比例的交易活动。
该银行通过网上银行系统为其投资者提供服务，其目前的在线系统所使用的是典型的基于Java，JSP及Spring的站点。
现有站点的架构扩展
目前绝大多数站点的交互功能都以读取访问居多，而扩展性方面最主要的挑战是对现有并行读取操作进行调整。读取扩展是由端点缓存结构处理的，该结构通常存在于多数现有的LAMP及分布式缓存部署当中。在那里的***查询指令指向数据库，而其后的查询指令则指向缓存内容。
新系统
新网站的设计理念要求契合当前的实时同步及社交使用的需求。这就意味着大多数流量及网络活动如今都是由用户所发起，而不同于以往常见的由网站所发起。此外，这类指令的执行过程及结果必须实时提交给使用银行业务的所有用户。
挑战
新网页的变更会带来流量及负载响应方面的一系列变化，这些变化无疑对扩展性提出了更高的要求。
写入扩展性
当我们现有的端点缓存架构需要应对大量的更新活动时，其性能表现就会大打折扣。这时缓存响应速度会变得极为缓慢，缓存同步过程也会因此成为一项增加开销却毫无效果的工作。
采用甲骨文出品的RAC高端硬件平台同样无法收到理想的结果。该解决方案不仅贵得离谱，同时也无法契合保证扩展性所必需的各项要求。
与从零开始建造一个应用不同，Avanza目前已然建立起一套服务现有客户群体的在线应用程序。这又带来了以下列举的数项额外挑战：
◆现有数据模型
与应用程序配套的整套数据模型是由这样一种模型关系所衍生的。数据模型的改变或将其迁移至新的NoSQL架构都会被认为将引发巨大的变化，而这些变化可能会在今后的数年时间中持续带来各种不利影响。
◆系统残余
网上银行应用程序中包含着大量残余的应用程序及第三方服务内容。由于其对第三方工具的依赖性，对现有基础设施进行重写既不可能也不实际。
◆复杂的环境
由于通常情况下，很大一部分的剩余应用程序在设计过程中都没有考虑到扩展性的需要，并且也不具备明确的整体架构，因为多年以来这类程序的编写一直习惯于采用分层处理的方式。这也使完善扩展性的复杂程度更进一步。
◆现有基础知识
现有的开发团队在Java及Java EE方面具备良好的知识与技巧，而强迫团队/开发小组立即接受一套全新的基础知识不仅仅是一项沉重的负担。这种毫无缓冲的高速发展要求以及随之而来的系统复杂性也可能会成为难以逾越的巨大障碍，并且需要耗费数年时间才会被克服。
#p#
解决方案：无需重写而实现读/写扩展性
很明显，迎接新的扩展性挑战将会涉及到现有应用程序的变更，其主要问题在于如何缩小变更范围以避免重写波及全部既有内容。第二个目标则是在尽量降低总体运营成本的前提下实施变更。
为了实现上述两个目标，Avanza银行采取了下列方法：
◆通过明确辨别可扩展的热点来最小化变更的影响范围
应用程序中需要强化写入访问效果的区域相对于整个系统来说往往并不大。因此，首先确保只有涉及相关应用程序的热点区域会被变更，而其余应用程序保持原状。在Avanza的实践过程中，所有在线网页应用程序会调用到的热点区域都被标注在特定的表当中。大多数后端系统则仍然通过访问数据库来实现报告生成、同步及批处理操作，因此这些部分可以保持不变。
◆保持数据库原状
当前主流设计的关键条件之一就是必须具备独立于数据库之外的读/写扩展处理能力（详见下一条）。这样就可以保持现有数据库及数据模式不变。如此一来，只要数据库不发生变更，其余所有系统组件都能够继续与其协同运作。
◆将内存中的数据网格作为通往数据库的前端
应用程序的扩展性调整是由应用程序前端借助内存数据网格（简称IMDG）完成的。IMDG中包含全部当前使用中的表格或原始数据库行。在线网页应用程序会转而访问IMDG而非通常情况下的数据库。IMDG分布广泛，因此我们可以通过将读写操作的负载分配到某个计算机群组上的方式来实现扩展性的提高。
◆采用先读后写的方针以降低同步时的系统负荷
自IMDG至底层数据库的更新过程会分期分批地完成，这要归功于一套内部队列机制（即再执行日志）。
◆利用O/R映射功能将数据反向映射到其原始格式中
在多数情况下，为了达到***的扩展效果，我们需要对数据进行划分。这通常涉及到数据模式的改变。数据模式的改变可能会破坏整套系统，这也包括了那些与扩展瓶颈问题无关的其它区域。为了满足这种不谐调的匹配方式，我们将数据模式改变所影响的范围固定在IMDG之中。数据由IMDG模式通过诸如Hibernate或Open JPA之类标准的O/R映射工具映射为原始模式。
◆借助标准的Java API及框架以充分利用已有的基础知识
新的NoSQL数据库替代方案所带来的众多挑战之一，是它们往往强迫我们对架构进行完全重组。对于企业来说，这种彻底的废旧立新使得开发人员不得不重新学习大量基础知识，以应对新API在功能维护及数据库制定方面的种种问题，而这无疑会带来高昂的迁移成本。
IMDG中包括GigaSpaces公司所公布的标准化API及JPA。此外，它们允许企业在移除大部分读/写负载的同时，延伸其对现有数据库的使用范围。无论是使用标准化API还是现有数据库，企业都可以借此充分利用自身的知识储备并满足扩展性调整中的各种需求。这同时使企业在日后得以利用新扩展数据库的插件来尽可能使自身向全新的对外扩展体系结构的过渡变得较为顺畅。
◆利用两个并行（即新旧两个）站点实现逐步过渡
将所有客户立即转移到新系统上常常不是什么好主意。更好的方法是将客户分批选定，逐渐迁移到新网站中。实现这一目的的通常手段是准备两个各自同时进行的网站。这一计划中的挑战在于保持两个网站间的同步状态。在Avanza银行的例子中，他们使用了GigaSpaces公司的镜像服务以保持两个站点间的绝对同步，并同时利用这种方式保持站点的数据更新。
下图从直观的角度向大家描述这种方法的实施要点：
总体运营成本角度
该项目的第二个目标是降低当前系统的总体运营成本。
具体实施方式如下：
◆利用内存提供高性能的访问响应，利用硬盘存储长期数据
正如我在之前的某篇文章中提到，基于内存的性能解决方案比起基于硬盘的同等效果的解决方案，能够节省十倍甚至一百倍的成本。而且，内存价格仍在不断走低。
1GB的内存使用成本只有区区每月1.9美元。利用内存来存储1T数据并要求能够接入单独的真正应用集群，每个月带来的也只是1800美元的成本。
因此，***解决方案是用内存来管理那些对访问的读/写速度要求较高的数据，而用硬盘来存储那些访问频率较低但长期存在的数据。
◆使用普通的数据库及硬件——单独部署Oracle RAC可能要花掉50万美元。将数据网络放入数据库的前端则使我们不需要Oracle RAC数据库所提供的许多高端功能。我们同样不再需要类似存储设备及无限带宽网络等等这类高端硬件配备。
结语
许多现有的应用程序在开发构建过程中采用了一层叠一层再叠一层的方式。相关数据库往往成为这类系统的核心组成部分，对此类系统进行扩展性调整可谓非常具有挑战性的任务。这一现状使得许多企业选择采用更简单的方法，即在高端硬件及数据库上大把大把地花钱。通过研究，我们发现这种方式在很多情况下并不奏效，而且比起其它更便宜、扩展性更好的备选方案，这种方式也实在是太昂贵了。有时候，我们完全可以将数据迁移到MySQL中并使用戴尔服务器来运行整套相关的数据系统。
【编辑推荐】
