Oracle RAC之外的方案 無需重寫而實現讀寫擴展性
原創【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中并使用戴爾服務器來運行整套相關的數據系統。
【編輯推薦】
