注：本文首發于CSDN，轉載請標明出處。

【編者案】在年前的「技術揭秘12306改造」專題中，負責12306改造的技術架構師劉云程從技術的角度、用科學論證的方式說明 12306是如何實現高流量高并發的關鍵技術，和深入探討了12306兩地3中心混合云架構，今天，他繼續為大家帶來第3篇：傳統框架云化遷移到內存數據平臺。

以下為正文》》

摘要

12306混合云成功案例給予最大的啟發就是打造1個從下到上都可做彈性擴大的“云利用”系統，企業客戶可將關鍵業務的“子系統”部署在資源豐富的云計算數據中心，“云化”后的子系統可“按需”獲得所需要的服務器虛機資源和動態調劑網絡帶寬，利用這些資源解決在高流量和高負載情況下，系統沒法快速彈性擴大致使的性能瓶頸。

此篇文章羅列不同類型的系統改造遷移到云平臺方案，從改造思路探討，系統框架設計和項目實行的全部遷移進程，供大家參考和交換。在此以Pivotal Gemfire云平臺為例子， 由于它已有大范圍部署成功案例。 客戶IT環境是5花8門， 對系統改造的思路和目的也不盡相同，Gemfire是不錯的選擇，但它不是唯1的選項。

前言

在過去20年，系統架構師最經常使用的系統框架是3層架構設計， 即Web層， 利用業務邏輯層和數據庫層；Web層和利用邏輯層可隨著業務變化做快速彈性擴大，但絕大部份關系型數據庫層沒法實現此功能。 在云計算，大數據和移動互聯網時期，由于業務成長快速，服務多樣化， 數據量急劇增加，用戶對系統響應時間有更嚴格的要求； 在高負載情況下，沒法橫向擴大的數據庫層常常成為系統性能的絆腳石。

在此篇文章，討論重點是從軟件中間件平臺（PaaS）和利用系統（SaaS）層面動身，使用“散布式內存數據網格( In Memory Data Grid)”技術，將傳統架構改造遷移到云平臺。系統改造有多種不同的方式，主要是要看改造的目的和所受的限制來決定; 為了具體化說明， 我們以以下3個案例提供給讀者參考和交換。

1. 12306項目：全部售票環節的1系列核心子系統都經太高度“云化”。 目的是可以將云化后的子系統“按需”靈活部署在不同的數據中心（公有云或私有云），提供優良服務。 云化的手段是將子系統業務邏輯和數據都放在Gemfire集群上履行， 利用Map Reduce的技術，建立可彈性擴大平臺，提供“高性能CPU計算能力”。
2. 某市社保項目：采取短平快的局部“子系統云化”，針對有高并發需求會致使瓶頸的子系統進行改造。改造的手段是將子系統業務邏輯和數據放在Gemfire節點上履行, 建立可彈性擴大平臺，利用Gemfire散布式并行查詢技術來解決“高并發查詢”的要求。
3. 金融單位POC測試項目： 問題在于系統的查詢業務量多，關聯表格多，在高并發情況下，查詢反應時間長。 POC目的是要驗證在不更改子系統業務邏輯限制下，以最小的代價，對“數據訪問層 （DAO）”進行修改，建立可擴大的“內存數據緩存層”，解決“高并發查詢“的方案；另外，還有數據庫與Gemfire集群之間“失效轉移 fail over”的設計。 以此為基礎，以后再將業務邏輯逐步放到Gemfire平臺，進行改造升級。

1、12306 混合云的啟示

在前兩篇文章提到，2012年春運后12306承辦單位-鐵科院引入”散布式內存數據網格” 技術，將余票計算/查詢子系統改造遷移到Gemfire云平臺，局部解決12306的主要瓶頸；改造后的子系統在2013年春運時上線，其效果是顯著的，雖然全部系統運行還是有”卡，頓”等不足的地方，但鐵科院對此技術深具信心堅持改革，才有后續1連串的子系統改造出爐。在2015年春運，建立兩地3中心混合云的服務模式，將大部份余票查詢流量引導到阿里云提供查詢服務；此舉的目的是要借助云計算數據中心的資源，“臨時性”解決在春運期間由于互聯網購票和刷票軟件所引發的難預測，高流量，和高并發要求，下降系統不穩定的風險。

12306混合云成功案例最大的啟發是給企業客戶和政府部門帶來新的思路，就是將關鍵業務的“子系統”改造遷移到云平臺架構，根據實際情況，將“云化”后的子系統部署在資源豐富的云計算數據中心（私有云或公有云）。 例如， 12306核心系統在經過全面改造和優化后， 每一個云化后的子系統都具有特定的獨立性，由于相干數據都放在Gemfire內存數據網格節點；這意味著這些子系統類似“云”1樣， 可以隨著業務需求變大或變小，1分為多，任性的漂移到多個不同數據中心來協同合作，避免在IT裝備方面的重復投資， 并提高資源的使用率。

云化后的子系統部署在多數據中心，需要特別注意以下兩點建議 ：

1. 如果將子系統部署在公有云提供服務時，數據隱私的保護和安全性應為重要斟酌。
2. 如果計劃將子系統部署在多數據中心時，在系統框架上必須斟酌上下游子系統之間的數據傳輸或同步/異步的設計。

以12306為例，兩地多中心混合云的架構示意圖以下；在春運售票高峰期間可以將余票查詢功能部署在多個公有云數據中心提供快速服務（例如阿里云和電信天翼云）。 

兩地多中心混合云架構

2、系統改造遷移的思路和需求

隨著企業成長，對1個復雜的大系統來講， 其業務功能不斷增加，服務方式多樣化，數據存儲量愈來愈大，但系統性能愈來愈慢，而用戶對響應時間的要求愈來愈嚴格；特別是在過去5年里，每一年都有新技術的演進 （大數據和散布式內存數據平臺）和新業務的衍生（物聯網利用，社交利用平臺和移動利用）。

當傳統架構系統已逐步沒法滿足日益成長的業務需求時，有兩種方案可供選擇， 1是從硬件著手，scale up的選項， 就是更換性能更強大的服務器；2是scale out的選項，從軟件平臺著手， 進行利用系統改造，采取彈性可擴大的框架設計。

更換硬件服務器是最簡單的做法， 但以后更換本錢會愈來愈高，系統性能提升是愈來愈有限。 軟件利用系統的改造，是1勞永逸從根本做起，改造本錢是與系統的復雜度有關，是需要全面改造？ 還是選擇性的局部改造 ？這需要根據實際使用情況來決定。

針對系統的scale out設計，如果要顛覆之前的架構，重建系統，那是個大工程，除非有以下3鐘情況：

1. 系統已是千瘡百孔， 沒法再打補釘也無人后續保護
2. 原本的框架設計已優化到極致，不管如何優化，都已沒法滿足日趨增加的業務需求。 例如，12306就是典型例子。
3. 業務流程和組織管理方式有巨大的變動， 需要重建系統

否則，最省錢和最有效的方法就是針對系統瓶頸做“局部改造”來提高性能，保護過去的投資。例如，社保項目就是典型例子

在此篇文章，討論的重點是如何將系統改造遷移到云利用平臺， 由于每一個系統都有其特殊性和復雜性的開發背景，其設計的系統框架，所采取的軟件平臺和開發技術也都隨著時間演進而不1樣。 因此改造的方式需要根據實際的環境來進行。 

1. 12306 系統改造思路和需求 

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈