Oracle RAC之外的方案 無需重寫而實現讀寫擴充性

編者按：對現有系統進行擴充對於各個技術團隊而言都是或大或小的挑戰。尤其對於銀行這種業務而言，由於要照顧到現有的系統（也就是現有的客戶），不太容易通過修改架構或系統重寫的方式來實現擴充，一般的做法就是用Oracle RAC等高端硬體來彌補現有擴充性的不足，但是這個做法相對昂貴。本文作者，專註於Java和.NET應用平台的GigaSpaces公司創始人兼CTO Nati Shalom以其一個銀行客戶Avanza為例，介紹了另一種擴充性的解決思路，其原則就是：無需重寫而實現讀寫擴充性。

相關閱讀：Oracle 11g中定位trace檔案簡便辦法

以下為本文：

上周我參加了我們某位夥伴於斯德哥爾摩舉辦的研討會，在該活動中我提出了資料擴充性領域的整合趨勢——特別是從NoSQL向NewSQL的過渡以及整合趨勢使得現有SQL及NewSQL更緊密地聯絡在一起。正如我在自己之前的某篇文章中就已經指出過的，“YeSQL：一種只存在於後SQL領域中，對各類Query語義進行歸納的概括。”

498)this.width=498;">

在本次活動中，Ronnie Bodinger——Avanza銀行的IT部門主管給出了精彩的評述，詳盡說明了他們是如何將既有銀行商務應用程式遷移至讀寫擴充性更好的新網站的。

Avanza系統概述：

Avanza是一家瑞典銀行，以為投資者提供便利的產權交易及資金轉移業務而聞名。它同時處理著斯德哥爾摩證券證券交易所中最大比例的交易活動。

該銀行通過網上銀行系統為其投資者提供服務，其目前的線上系統所使用的是典型的基於Java，JSP及Spring的網站。

現有網站的架構擴充

目前絕大多數網站的互動功能都以讀取存取居多，而擴充性方面最主要的挑戰是對現有並行讀取操作進行調整。讀取擴充是由端點緩衝結構處理的，該結構通常存在於多數現有的LAMP及分布式緩衝部署當中。在那裡的首個查詢指令指向資料庫，而其後的查詢指令則指向緩衝內容。

新系統

新網站的設計理念要求契合當前的即時同步及社交使用的需求。這就意味著大多數流量及網路活動如今都是由使用者所發起，而不同於以往常見的由網站所發起。此外，這類指令的執行過程及結果必須即時提交給使用銀行業務的所有使用者。

挑戰

新網頁的變更會帶來流量及負載回應程式面的一系列變化，這些變化無疑對擴充性提出了更高的要求。

寫入擴充性

當我們現有的端點緩衝架構需要應對大量的更新活動時，其效能表現就會大打折扣。這時緩衝響應速度會變得極為緩慢，緩衝同步過程也會因此成為一項增加開銷卻毫無效果的工作。

採用甲骨文出品的RAC高端硬體平台同樣無法收到理想的結果。該解決方案不僅貴得離譜，同時也無法契合保證擴充性所必需的各項要求。

與從零開始建造一個應用不同，Avanza目前已然建立起一套服務現有客戶群體的線上應用程式。這又帶來了以下列舉的數項額外挑戰：

◆現有資料模型

與應用程式配套的整套資料模型是由這樣一種模型關係所衍生的。資料模型的改變或將其遷移至新的NoSQL架構都會被認為將引發巨大的變化，而這些變化可能會在今後的數年時間中持續帶來各種不利影響。

◆系統殘餘

498)this.width=498;">

網上銀行應用程式中包含著大量殘餘的應用程式及第三方服務內容。由於其對第三方工具的依賴性，對現有基礎設施進行重寫既不可能也不實際。

◆複雜的環境

498)this.width=498;">

由於通常情況下，很大一部分的剩餘應用程式在設計過程中都沒有考慮到擴充性的需要，並且也不具備明確的整體架構，因為多年以來這類程式的編寫一直習慣於採用分層處理的方式。這也使完善擴充性的複雜程度更進一步。

◆現有基礎知識

現有的Team Dev在Java及Java EE方面具備良好的知識與技巧，而強迫團隊/開發小組立即接受一套全新的基礎知識不僅僅是一項沉重的負擔。這種毫無緩衝的高速發展要求以及隨之而來的系統複雜性也可能會成為難以逾越的巨大障礙，並且需要耗費數年時間才會被克服。

1 2 下一頁

【內容導航】
第1頁：情景描述	第2頁：解決方案