注：本文首發於CSDN，轉載請標明出處。
【編者按】在年前的「技術揭祕12306改造」專題中，負責12306改造的技術架構師劉雲程從技術的角度、用科學論證的方式說明 12306是如何實現高流量高併發的關鍵技術，以及深入探討了12306兩地三中心混合雲架構，今天，他繼續爲大家帶來第三篇：傳統框架雲化遷移到內存數據平臺。
以下爲正文》》
摘要
12306混合雲成功案例給予最大的啓發就是打造一個從下到上都可做彈性擴展的“雲應用”系統，企業客戶可將關鍵業務的“子系統”部署在資源豐富的雲計算數據中心，“雲化”後的子系統可“按需”獲取所需要的服務器虛機資源和動態調整網絡帶寬，利用這些資源解決在高流量和高負載情況下，系統無法快速彈性擴展導致的性能瓶頸。
此篇文章列舉不同類型的系統改造遷移到雲平臺方案，從改造思路探討，系統框架設計和項目實施的整個遷移過程，供大家參考和交流。在此以Pivotal Gemfire雲平臺爲例子， 因爲它已有大規模部署成功案例。 客戶IT環境是五花八門， 對系統改造的思路和目的也不盡相同，Gemfire是不錯的選擇，但它不是唯一的選項。
前言
在過去20年，系統架構師最常用的系統框架是三層架構設計， 即Web層， 應用業務邏輯層和數據庫層；Web層和應用邏輯層可隨着業務變化做快速彈性擴展，但絕大部分關係型數據庫層無法實現此功能。 在雲計算，大數據和移動互聯網時代，由於業務成長快速，服務多樣化， 數據量急劇增加，用戶對系統響應時間有更嚴格的要求； 在高負載情況下，無法橫向擴展的數據庫層往往成爲系統性能的絆腳石。
在此篇文章，討論重點是從軟件中間件平臺（PaaS）和應用系統（SaaS）層面出發，使用“分佈式內存數據網格( In Memory Data Grid)”技術，將傳統架構改造遷移到雲平臺。系統改造有多種不同的方式，主要是要看改造的目的和所受的限制來決定; 爲了具體化說明， 我們以下列三個案例提供給讀者參考和交流。
- 12306項目：整個售票環節的一系列核心子系統都經過高度“雲化”。 目的是可以將雲化後的子系統“按需”靈活部署在不同的數據中心（公有云或私有云），提供優質服務。 雲化的手段是將子系統業務邏輯和數據都放在Gemfire集羣上執行， 利用Map Reduce的技術，建立可彈性擴展平臺，提供“高性能CPU計算能力”。
- 某市社保項目：採取短平快的局部“子系統雲化”，針對有高併發需求會導致瓶頸的子系統進行改造。改造的手段是將子系統業務邏輯和數據放在Gemfire節點上執行, 建立可彈性擴展平臺，利用Gemfire分佈式並行查詢技術來解決“高併發查詢”的要求。
- 金融單位POC測試項目： 問題在於系統的查詢業務量多，關聯表格多，在高併發情況下，查詢反應時間長。 POC目的是要驗證在不更改子系統業務邏輯限制下，以最小的代價，對“數據訪問層 （DAO）”進行修改，建立可擴展的“內存數據緩存層”，解決“高併發查詢“的方案；另外，還有數據庫與Gemfire集羣之間“失效轉移 fail over”的設計。 以此爲基礎，以後再將業務邏輯逐漸放到Gemfire平臺，進行改造升級。
一、12306 混合雲的啓示
在前兩篇文章提到，2012年春運後12306承辦單位-鐵科院引入”分佈式內存數據網格” 技術，將餘票計算/查詢子系統改造遷移到Gemfire雲平臺，局部解決12306的主要瓶頸；改造後的子系統在2013年春運時上線，其效果是顯著的，雖然整個系統運行還是有”卡，頓”等不足之處，但鐵科院對此技術深具信心堅持改革，纔有後續一連串的子系統改造出爐。在2015年春運，建立兩地三中心混合雲的服務模式，將大部分餘票查詢流量引導到阿里雲提供查詢服務；此舉的目的是要藉助雲計算數據中心的資源，“臨時性”解決在春運期間由於互聯網購票和刷票軟件所引發的難預測，高流量，和高併發請求，降低系統不穩定的風險。
12306混合雲成功案例最大的啓發是給企業客戶和政府部門帶來新的思路，就是將關鍵業務的“子系統”改造遷移到雲平臺架構，根據實際情況，將“雲化”後的子系統部署在資源豐富的雲計算數據中心（私有云或公有云）。 例如， 12306核心系統在經過全面改造和優化後， 每個雲化後的子系統都具有特定的獨立性，因爲相關數據都放在Gemfire內存數據網格節點；這意味着這些子系統類似“雲”一樣， 可以隨着業務需求變大或變小，一分爲多，任性的漂移到多個不同數據中心來協同合作，避免在IT設備方面的重複投資， 並提高資源的使用率。
雲化後的子系統部署在多數據中心，需要特別注意下列兩點建議 ：
- 如果將子系統部署在公有云提供服務時，數據隱私的保護和安全性應爲首要考慮。
- 如果規劃將子系統部署在多數據中心時，在系統框架上必需考慮上下游子系統之間的數據傳輸或同步/異步的設計。
以12306爲例，兩地多中心混合雲的架構示意圖如下；在春運售票高峯期間可以將餘票查詢功能部署在多個公有云數據中心提供快速服務（例如阿里雲和電信天翼雲）。
兩地多中心混合雲架構
二、系統改造遷移的思路和需求
隨着企業成長，對於一個複雜的大系統來說， 其業務功能不斷增加，服務方式多樣化，數據存儲量越來越大，但系統性能越來越慢，而用戶對響應時間的要求越來越嚴格；尤其是在過去5年裏，每年都有新技術的演進 （大數據和分佈式內存數據平臺）和新業務的衍生（物聯網應用，社交應用平臺和移動應用）。
當傳統架構系統已逐漸無法滿足日趨成長的業務需求時，有兩種方案可供選擇， 一是從硬件着手，scale up的選項， 就是更換性能更強大的服務器；二是scale out的選項，從軟件平臺着手， 進行應用系統改造，採取彈性可擴展的框架設計。
更換硬件服務器是最簡單的做法， 但以後更換成本會越來越高，系統性能提升是越來越有限。 軟件應用系統的改造，是一勞永逸從根本做起，改造成本是與系統的複雜度有關，是需要全面改造？ 還是選擇性的局部改造 ？這需要根據實際使用情況來決定。
針對系統的scale out設計，如果要推翻以前的架構，重建系統，那是個大工程，除非有下列三鍾情況：
- 系統已經是千瘡百孔， 無法再打補丁也無人後續維護
- 原有的框架設計已優化到極致，無論如何優化，都已經無法滿足日益增加的業務需求。 例如，12306就是典型例子。
- 業務流程和組織管理方式有巨大的變動， 需要重建系統
否則，最省錢和最有效的方法就是針對系統瓶頸做“局部改造”來提高性能，保護過去的投資。例如，社保項目就是典型例子
在此篇文章，討論的重點是如何將系統改造遷移到雲應用平臺， 由於每個系統都有其特殊性和複雜性的開發背景，其設計的系統框架，所採用的軟件平臺和開發技術也都隨着時間演進而不一樣。 因此改造的方式需要依據實際的環境來進行。
1. 12306 系統改造思路和需求 – 按階段逐步雲化核心子系統
- 原來系統是使用Stored Procedure開發，系統已經優化到極致，很難再進一步提升性能。
- 如果採用scale up的硬件升級，投資過於龐大； 隨着鐵路基礎建設不斷擴大，業務量也會隨着增加，無法保證硬件升級後的系統性能會滿足未來業務成長的需求。另外， 就是春運高峯期過後該如何處置過剩的Unix小型機也必須列爲考慮。
- 承辦單位- 鐵科院經過仔細評估後，認爲高流量和高併發問題必需採用雲計算可彈性擴展的平臺和技術來解決。
- 以分佈式內存數據網格” - Gemfire技術爲切入點，以餘票計算/查詢子系統爲試點項目。 採取穩妥的改造策略， 逐年逐步改造和優化其子系統，解決一系列環節上的瓶頸，保證在改造期間整個12306系統的穩定運行。
- 在改造初期，新舊兩套系統必須同時並行運行。 利用CDN（Content Delivery Network）的流量管理功能， 逐漸將流量加壓到Gemfire集羣，測試集羣在高負載下是否能平穩過渡高峯售票期。
- 採用“多重Gemfire集羣”相互備份的設計，同時並行運行，爲未來“多數據中心”的部署當試點和鋪路。
2. 社保系統改造思路和需求 – 短平快的局部子系統雲化
- 社保制度逐年改革，新編制組織架構不斷擴大，新業務不斷增加，省市社保人數從數百萬級別到某些人口大省超過億的級別；這些社保繳費資料需要保存達數十年以上， 永隨一生， 每年都有數百T甚至P量級的數據存儲單位。社保單位必須考慮如何存儲這些資料？ 如何在大數據量情況下提供快速查詢服務？ 如何建設一個IT平臺能隨着未來業務成長而不斷的彈性擴容，此爲主要的改造思路。
- 社保系統是對外的公共服務平臺於2008年上線，此平臺是以互聯網爲載體，開通企業單位和個人網上申報業務的服務。 在面對日益增加的網絡業務辦理需求，平臺硬件系統（多部高端Unix小型機）所承載壓力逐漸加大。 系統硬件已逐漸出現瓶頸。在2012年1月集中申報期間， 系統的CPU（包含應用服務器和數據庫服務器）高達90%以上， 導致系統不穩定，無法正常訪問，影響重大。
- 經過社保相關單位仔細評估，確立系統改造的策略應由兩方面着手， 一是建立虛擬化的雲環境， 二是針對子系統瓶頸進行局部改造， 改造後的子系統平臺需要支持“彈性擴展”，滿足未來日益增加的網上業務。
- 採用VMware技術搭建虛擬化雲平臺來提升基礎架構的擴展能力，採用Pivotal Gemfire 可彈性擴展的高速緩存功能， 支持高併發“熱點數據”查詢服務，降低原有數據庫的I/O瓶頸，提高整個系統性能和穩定性。
3. 金融單位POC測試改造思路和需求 –建立可擴展的 “分佈式內存緩存數據層”
金融單位系統龐大複雜，所有的子系統從設計到開發都需要嚴格遵循統一開發流程，
核心子系統業務邏輯不輕易更改。對系統而言，查詢業務量多，數據量大，關聯表格多，在高併發情況下，查詢反應時間長。
POC測試目的：
- 在不改系統業務邏輯情況下, 對“數據訪問層 DAO – Data Access Object”進行改造， 建立可擴展的 “分佈式內存緩存數據層”；目的是提高業務查詢性能，快速反應查詢結果，降低原有數據庫的I/O瓶頸，提高整個系統性能。
- 考慮系統穩定性和安全性， 還需要驗證“分佈式內存緩存數據層”與關係型數據庫之間“失效轉移 fail over”的設計。
三、12306系統改造遷移到Gemfire平臺
在最初的框架設計已考慮系統性能問題，所以使用Stored Procedure開發來提升系統執行速度。此設計思路是參考德國和英國互聯網售票經驗 – 即總售票量20%的比率是透過互聯網售票，也就是說當初12306系統規劃是要滿足每天售票量100萬張的需求來設計。
在2012年春運12306對外開放時，涌入將近2千萬人次登錄，遠遠超過當初的預設目標，但又受限於系統架構無法彈性擴展，導致整個12306系統裏裏外外都不穩定， 無法正常訪問。在採用Pivotal-Gemfire雲化後的12306系統有了“質與量“的大躍進，在2015年春運售票高峯日已達560萬張，佔了整體售票量的60%；避免過去日夜排隊購票的痛苦， 也節省大量社會成本。
由於12306業務邏輯複雜，系統龐大， 在此只以餘票計算/查詢爲案例。有關整個系統的業務邏輯設計不在此討論。下列的描述如果有誤， 也請各位先進指正。
2012年 改造前的餘票計算/查詢子系統架構描述
1. 路局“實時”提供售票記錄
火車票的席位銷售是由每個路局規劃和調控（鐵路總公司共有18個路局）， 而12306與每個路局是共享同一個“票庫”。 換句話說，“線上”的12306是與“線下”的火車站點售票窗口，電話售票，和各地的售票點搶票。每個路局將每張票的銷售記錄都“實時“傳送到12306在鐵總數據中心“主數據庫服務器”做彙總。
2. 數據庫複製到餘票集羣：
在鐵總的數據中心 - 餘票計算服務器集羣是由“主數據庫服務器”和72部Unix小型機組成；主數據庫服務器彙總各個路局傳輸過來的數據後，利用數據庫複製的機制，實時將數據“複製“到72部Unix小型機。
3. 並行處理餘票計算： 其中8部小型機做售票預處理，再將預處理結果送到64部小型機，64部小型機“同時並行”處理餘票計算。
4. 應用緩存服務器： 64部小型機將餘票計算後的結果彙總產生餘票表，將餘票表放置在前端的應用緩存服務器集羣；此舉是要解決在高併發的情況下，緩存服務器提供更快速的餘票查詢服務。
5. CDN(Content Delivery Network)服務器：12306最外圍部署CDN網絡，其目的是使用戶可就近取得所需信息，將用戶的請求重新導向離用戶最近的服務節點解決 Internet網絡擁擠的狀況，還有調整負載均衡的功能，提高用戶訪問的響應速度。
6. 餘票信息更新機制：餘票信息更新是以“車次“爲基準，每隔10分鐘更新一次。當用戶提交“區間站點”的餘票查詢時，先從CDN服務器查詢資料，假如CDN的資料已超過10分鐘，會從應用緩存服務器索取最新的數據。同理，當應用緩存服務器的資料超過時效，會觸發餘票計算流程，重新計算餘票產生餘票表， 提交給應用緩存服務器。每隔10分鐘更新的參數是可調整的。
12306改造原則和目標
（1）設定性能指標：
以餘票計算子系統爲例，Gemfire集羣的餘票計算性能指標需要達到10，000 TPS以上， 並可以隨着業務成長做彈性擴展。配合應用緩存服務器集羣和最前端的CDN負載均衡服務器集羣，預估12306可以支持每秒達百萬次的餘票查詢。此部分的系統性能是與服務器CPU類型， 內存大小，Gemfire節點數和x86服務器數量都有關聯。
（2）餘票計算處理能力可隨着虛機的增加而線性增加
餘票查詢是要反映最新的餘票情況，作爲購票的依據。 在上篇文章已談到餘票計算的複雜度，需要很強大的CPU處理能力爲後盾來計算每個區間站點的餘票量；將計算結果放置到緩存數據服務器和CDN服務器。餘票計算是利用Gemfire Data Grid和Map Reduce的技術提供巨大CPU處理能力。
（3）在不改變原有的體系框架上增加Gemfire集羣， 新舊兩套系統並行運算
爲確保12306生產環境的穩定性和平穩過渡，新舊兩套系統必須同時運行，由最前端的CDN服務器控制訪問流量，逐漸將需要餘票計算的請求加壓到Gemfire集羣，測試Gemfire的承載能力，檢驗可擴展的功能。
（4）系統高可用性（High Availability）
Gemfire的數據節點都有其它節點的備份數據， 也可以將內存數據持久化到硬盤或是同步/異步寫到數據庫。
（5）x86服務器
考慮未來多數據中心和混合雲的部署，必須使用x86服務器爲生產機。
根據12306改造設計原則在不改變原有的體系框架上增加Gemfire集羣， 在過渡期間，新舊兩套系統並行運算，在過渡期後，以Gemfire集羣爲主。 所以此步的改造是針對上述”改造前的餘票計算/查詢子系統架構”的第2項和第3項進行分析和改造。
12306改造步驟：
（1）系統架構改造和數據上載
爲確保12306生產系統的穩定運行和平穩過渡，在不改變原有的體系框架上增加Gemfire集羣， 新舊兩套系統並行運算。那就必須考慮如何將數據從數據庫實時同步到Gemfire集羣做餘票計算。
A．數據庫複製服務器 ：增加一部數據庫服務器，將鐵總數據中心“主數據庫服務器”彙總的數據實時複製到此部數據庫服務器。
B．實時同步機制和SQL解析服務器 ： 此步驟是從數據庫取出Log數據並解析SOL語句，因爲原來代碼是用Stored Procedure開發的。
C．Rabbit MQ服務器 ：同步機制服務器將解析過的SQL語句透過Rabbit MQ傳輸給Gemfire集羣做餘票計算。
D．Gemfire集羣將餘票計算結果彙總後，提交給前端的應用緩存服務器提供餘票快速查詢。
（2）系統數據結構分析
數據結構分析和設計是在改造過程中最關鍵的一步，影響到後續性能的提升； 利用“數據網格Share Nothing”的特性, 將數據切割, 把 “數據關聯性強”的數據放在同一個Gemfire 數據節點，再配合業務邏輯的設計，降低節點之間數據交換的延遲，提高系統處理能力。
（3）Benchmark （基準點）測試
- 進行Benchmark測試, 評估每部Gemfire服務器的TPS和餘票計算反應時間
- -驗證Gemfire集羣性能可隨着x86虛機的增加而線性增加
- 測試“實時同步”機制, 量測數據同步到Gemfire集羣的穩定性，延遲和吞吐量
（4）系統穩定性, 安全性和HA設計
在Gemfire的數據節點都有其它節點的備份數據來達到HA的目的，也可以將內存數據持久化到硬盤或是數據庫。
使用Gemfire改造的實施流程：
1. 需求分析階段：
- 需求調研，確定改造方案、
- 分析數據表結構、樣本數據、數據量及應用訪問特性信息
2. 架構設計：
- 設計Region結構，確定分區方式，和 設計二級索引
- 數據切割（partition）放在Gemfire的節點， 每個節點數據量大小是根據物理機內存來決定。例如， 在阿里雲的節點一般是30G左右，在鐵總數據中心的節點是60G-120G左右。 從項目經驗來說，Gemfire數據節點以不超過128G可得到最佳效果。
- 利用Data Grid和Map Reduce的分佈式技術提供強大的CPU處理能力。
- 使用到的Gemfire功能參考下列描述
3. 編碼和單元測試：
- 12306是採用Stored Procedure開發，必須將Stored Procedure解析， 採用Java開發和編碼，並將業務邏輯代碼和數據都放在Gemfire節點， 此舉可以達到最高的系統性能
- 單元測試
4. 集成測試/準確度測試/性能調優：
- 在集羣環境下進行準確度測試
- 在集羣環境下進行性能及壓力測試
- 依據測試結果進行性能調優
- 性能調優可能需要調整細部架構的重新設計
5. HA和熱部署測試
6. 線上運維：
- 創建Release版本並納入管理
- 配置部署生產環境並進行持續監控
主要的Gemfire功能特性：
在12306改造過程中，使用到下列Gemfire的功能特性：
- Rich Objects: 以objects的形式體現和編碼，自己定義數據結構
- Elastic Growth w/o pausing ： 彈性擴展和熱部署
- Partitioned Active Data ： 根據數據屬性，例如：客戶，訂單，車次，站名，做合理的數據切割，放在不同的數據節點。
- Redundancy for instant FT：HA的設置
- Colocated Active Data： share nothing的概念，將關聯性強的數據放在同一個Gemfire 數據節點， 例如，車次，站名
- Replicated Master Data： 數據量不大的常用數據，例如：站名字典和席位類別等，在每個Gemfire節點都有一份拷貝，此舉是要減少數據的交換。
- Server-side Event Listeners： 當數據在Server端產生變化時，會觸發相應的操作
- Client-side Durable Subscriptions：當Server端滿足客戶端訂閱的某些條件時，會推送信息
- Parallel Map-Reduce Function Execution： 車次餘票在每個Gemfire 節點並行運算，再彙總運算結果
- Parallel OQL Queries
- Continuous Queries
- LRU Overflow to disk in native format for fast retrieval
- Parallel, Shared Nothing Persistence to disk w/ online backup
- Asynchronous Write Behind, Write Through or Read Through
四、社保項目子系統改造遷移到Gemfire雲平臺
社保申報子系統改造原則和目標
從訪問量和併發量規模來說，社保所遇到的問題遠遠遜於12306所碰到的挑戰。子系統改造是基於VMware虛擬化雲平臺基礎上提升申報系統的查詢性能。
（1）設定性能指標：
性能指標需要達到原有子系統性能50倍以上
（2）針對下列兩個子系統瓶頸進行局部改造
- 繳費工資申報
- 城鎮職工增加
（3）改造後的子系統性能可隨着Gemfire節點虛機的增加而線性增加
（4）系統高可用性（HA）
參考12306描述。
子系統瓶頸的局部改造步驟：
社保系統是很複雜龐大的系統，由上百個模塊構成。此係統採取三層架構設計， 使用Java開發。主要問題在於高併發申報過程中， 頻繁的數據庫寫入和大量查詢導致硬件平臺高負載，子系統不穩定， 無法正常訪問。
- 子系統的改造是針對數據庫瓶頸提出改良方案
- 採取數據庫“讀/寫分離“的方式，將數據“寫入”關係型數據庫；將“讀”的操作由Gemfire集羣來提供，因爲查詢的訪問量數十倍於數據的寫入量。
- 客戶端資料寫入時，同時將數據寫入Gemfire節點和關係型數據庫
- 將“欲改造“的子系統業務邏輯代碼改寫後移到Gemfire節點執行
- Gemfire集羣提供剛錄入“熱點數據“的快速查詢
- 不同子系統數據庫之間的數據批量同步，將其它子系統“完整”的熱點數據上載到Gemfire集羣提供快速查詢
相關的改造步驟和實施流程請參考上述的12306章節，改造後的架構如下圖所示。
五、某金融單位POC項目 - 建立可擴展的 “分佈式內存緩存數據層”
金融單位系統是由上百個子系統構成， 所有的子系統從設計到開發都要遵循標準統一開發流程，子系統採取三層架構設計，應用邏輯層與數據訪問層設計層次分明。由於業務查詢量大，牽涉到十幾張關聯表的查詢，系統反應時間長。數據庫讀寫頻繁，CPU時常滿負載，導致系統性能瓶頸。
POC子系統改造目標
改造方式是在不改變子系統業務邏輯情況下，對數據訪問層進行修改DAO接口，引入“分佈式緩存數據層”架構。
（1）設定性能指標：
性能指標需要達到原有子系統性能20倍以上
（2）針對兩個子系統進行DAO接口改造
（3）驗證改造後的子系統查詢性能可隨着Gemfire虛機的增加而線性增加
（4）系統高可用性（HA）
除了Gemfire集羣的HA以外，還要考慮系統穩定性和安全性， 採用“失效轉移 fail over”設計，萬一Gemfire集羣異常時，改由數據庫提供查詢服務
數據訪問層（DAO）改造步驟：
根據客戶場景的要求，子系統的改造是針對數據庫提出改良方案，對數據訪問層進行修改DAO接口，嵌入“緩存數據代理層” （Delegator）架構。
緩存數據代理層有如下功能設計：
- 緩存數據代理層向上封裝數據訪問接口，向下同時支持DB和Gemfire緩存數據層
- 與業務邏輯相關的API可以隨着業務需求，按需彈性增加API接口的支持
- 根據Gemfire的特性，對SQL語句進行修改，設計成並行查詢功能
- 考慮數據一致性的要求，客戶端數據直接寫入關係型數據庫，再將數據同步到Gemfire集羣提供快速查詢。
- 萬一Gemfire集羣有異常，客戶端可直接訪問數據庫，實現緩存數據層和DB之間的無縫切換
- 另外，其他數據庫或Hadoop集羣存儲全量業務數據，可將“熱點數據”上載到緩存數據層
- 通過Gemfire異步隊列也可以將Gemfire的“熱點數據”持久化到DB或Hadoop集羣
- 當查詢在Gemfire緩存數據層未命中時，通過Cache loader從DB或Hadoop集羣加載數據到緩存數據層， 提供查詢服務。
相關的改造步驟和實施流程請參考上述的12306章節，改造後的架構示意圖如下：
六、結論和啓示
由上面幾個案例說明，不同的用戶有不同的訴求，不同的系統開發環境和不同的限制條件所採用的改造方式也不一樣。總結如下：
（1）12306項目： 流量高，併發性強，服務器負載高，反應時間要求嚴格；爲了避免某一個環節的瓶頸，需要理順整個流程, 將一系列的子系統做“雲化”的改造。根據實際需求，將雲化後的子系統按需部署在公有云提供服務。 改造的手段是用“分佈式數據網格”的技術，結合業務邏輯特性和數據結構，將業務邏輯和關聯性強的數據放在同個Gemfire數據節點，利用Map Reduce的技術提供強大的CPU計算能力來解決問題。
（2） 社保項目： 社保試點項目的改造重點是針對會發生瓶頸的子系統進行改造，將子系統業務邏輯和關聯性強的數據放在同個Gemfire數據節點，利用Gemfire分佈式並行查詢技術來解決高併發查詢的要求，併爲政府行政部門管理透明化，內容更豐富的“Open Data”服務平臺鋪路。
對於人口大省，例如廣東，河南，江蘇和四川人口接近上億的省份，隨着社保體制的改革，更要考慮“大數據”的存儲和查詢，因爲這些社保資料達P量級，需要存儲數十年以上。 大數據和快數據的設計可以借鑑 12306 訂單分級查詢的機制，將“熱點數據”放在Gemfire緩存集羣提供快速查詢，將歷史數據存放在Hadoop集羣。當查詢在Gemfire緩存數據層未命中時，通過Cache loader從DB或Hadoop集羣加載數據到緩存數據層，提供查詢服務。
（3） 金融單位POC項目： 此POC的改造與上述兩個項目不一樣，在12306和社保項目改造都是需要將業務邏輯改寫在Gemfire集羣； 此金融單位POC的測試目的是在不改寫業務邏輯的情況下，對原來系統的數據訪問層（DAO）進行改造， 提供可擴展的分佈式緩存數據層提供快速服務，並提供失效轉移的設計。