洞若觀火，聊聊舊系統升級改造那些事兒

首發在聊聊架構 ，發到這裏備份一下：

由於經常在聊聊架構羣裏看到有不少朋友在問舊系統升級改造的一些原則與經驗，你們面臨着各類各樣的問題，因而在這裏跟跟你們聊聊我經歷的那些舊系統改造的那些事兒。

本文是整個系列的第一篇內容，文章以使用COBOL語言開發於70年代的某日本公司W系統的改造升級爲例，來介紹系統升級改造的總體思路。

當系統日益臃腫，情況頻出，難以知足公司業務發展的須要，運維感到壓力山大，但公司出於保護投資的動機，又不能徹底拋棄現有系統，另起爐竈。那麼對該系統進行升級改造呢就不得不提上日程，所以咱們首先要作的是直面系統所存在的問題，明確系統升級所須要達到的目標，再根據目標提出相應的架構解決方案。

咱們來看一個案例：某日本公司W系統使用COBOL語言開發於70年代，運行在IBM 的Mainframe 大型機上，數據存儲使用VSAM（Virtual Storage Access Method），結構上採用C-S架構，用戶使用仿真終端工具遠程登錄主機；批處理使用JCL（Job control language）；在使用了30多年後，公司不得不進行改造升級。首先咱們應當分析其存在的問題：

一、運行平臺維護困難，成本高昂。

該系統運行於IBM Mainframe大型機系統，誕生於1964年的S/360，系統爲OS 360，後面陸續推出OS 370，OS390，最新的是IBM Z13大型機，以其強大的計算能力，極高的可靠性（年維護時間不超過5分鐘）以及其安全性深受各個行業所信賴，尤爲普遍應用於銀行金融等關鍵領域。但購置費用極其昂貴（注：2014年Z10 報價2000萬美圓，最便宜配置也是500萬，據說近來降價了）， 其運維成本更是十分巨大，運維人員費用昂貴你們都知曉，其餘僅機房空調電費一項就很是可觀，不是土豪用不起啊。

在30多年前性能強安全穩定的服務器屈指可數，價格昂貴天然是情理之中，但現在各類架構服務器價格已經親民許多，所以在服務器上已有足夠多的選擇，採夠相對實惠的硬件能夠將有限的預算花到其餘更須要的地方；尤爲是對於企業而言，如何將預算使用的更加高效是天天都要面對的問題；所以成本概念不只僅是公司老闆和財務經理須要，做爲架構師也是須要具有成本成本意識，關注軟件架構在各個階段的成本。

二、數據和代碼維護困難，難以跟其餘企業信息系統進行數據交換

COBOL語言還屬於面向過程的高級語言，有着嚴格的代碼格式，位置寫錯了都編譯不過，在主機上debug極其不便，基本只能靠log文件輸出查看數據；何況這些代碼都用了近30年，當時比我年齡都大，也是歷經屢次更改，具體業務也幾經變遷， 當年寫代碼的程序員只怕是都退休了，維護極爲困難。使用了CICS（Customer Information Control System）中間件，因爲IBM 主機系統的封閉性，該系統與其餘企業信息系統進行數據交換困難，COBOL 調JAVA，COBOL調C 等異構程序間的數據交互的開發很是繁瑣，對人員技術要求較高。數據存儲採用了 VSAM，是一種文件存儲方式，遠遠不能知足當今數據存儲的要求；在對數據分析挖掘的需求日益增多的今天，更是沒法知足這些新需求的須要。

三、主機終端資源有限，同時在線用戶數難以擴容

在C-S架構下，使用系統是經過終端設備鏈接至主機系統，因爲主機資源有限，各系統同時終端鏈接數是固定的，所以當須要進一步擴大同時在線用戶數量則受到諸多限制；畢竟主機資源昂貴，開一顆CPU核心也是須要付出不菲的美刀的。

針對上述三個主要矛盾點，咱們發現主要的問題在於平臺架構和運行環境所帶來的桎梏使得非改不可。因此就這樣的需求而言，解決方案就很是直接:

一、平臺總體移植至windows，數據存儲由vsam向數據庫遷移。

首先是決定將IBM COBOL代碼經過轉換使其運行在Windows平臺的Micro Focus Net/Enterprise Server Express服務器上，解決了硬件昂貴的問題，畢竟相對於主機而言，Windows服務器的購置成本和運維成本僅僅是主機的九牛一毛，從而使系統運維成本大幅降低，運維人員也更易招募。其次，變VSAM文件存儲爲Oracle數據庫，解決數據管理和使用上的種種障礙，畢竟在二十一世紀了，數據庫較文件存儲不知高到哪裏去了（+1s）。最後，將批處理代碼由JCL遷移至BAT腳本，調度控制採用了Hitachi JP1 server，由這主要的三步將平臺所有代碼完整遷移至Windows平臺。固然，同語言的異平臺間的遷移的項目在平常工做當中難以見到，但給了咱們一種思路，就是不要被底層運行環境所限制了思想，跳出來反而能得到新的收穫。

二、系統由C-S架構轉向B-S架構

將用戶界面作總體轉換，由以前的UI由CICS實現的LMAP頁面轉換爲Java web 應用，因爲採用了流行的BS架構，以前因爲終端數量限制的問題則獲得解決。因爲，CICS系統自己有較多頁面控制功能，所以咱們採用Java自行實現了其前端框架的主要功能，如先後端數據轉換與傳輸，頁面顯示及跳轉這些基礎功能。

由於客戶公司要求界面及控制方式要與原有系統一致，保證徹底的界面及功能與原有系統相同，從而減小對原有員工的培訓和適應期，保證系統的順利切換，避免所以帶來的風險。固然這個跟日本的文化或者是人的特質決定的，他們在這方面要求比較古板，甚至顯得十分使人難以理解的迂腐，但他們作事情的嚴謹態度仍是值得學習。

三、將COBOL程序服務化

經過Micro Focus Net Express爲COBOL 程序配置web service接口定義，並生成相應的Java 接口代碼，並將轉換後的COBOL源代碼部署至Micro Focus Server Express ，Java /.NET工程經過SOAP 調用web service，由server express傳遞數據給相應 COBOL服務。經過服務化將原有封閉的COBOL程序轉變成web服務，使其不只可使得現有程序能夠調用，也使得第三方程序在須要的狀況下能夠有接入的可能，轉封閉爲開放。

從以上三個對策而言，從根本上解決了原有的三個主要問題，使舊系統煥發了新的活力，再也不收到昂貴硬件平臺的限制，採用現有的廉價平臺就能知足以前系統的所有功能，同時還提供了種種新特性知足各方面新的須要，兼顧了下降了企業的運維成本，保護了既有投入，在方案當中也徹底符合現有用戶使用習慣，避免了新老系統切換過程當中用戶出現不適應的狀況，更是將人員培訓成本降到最低，會使用瀏覽器就能使用新系統。固然以上方案的實施並不是我描述的這般簡單，當中有着各類各樣的挑戰，在克服這些挑戰的同時，這樣的移植升級項也花費了近200我的月的成本。最終呈現的系統架構如：

對於這樣陳舊的系統的移植升級改造，有着以下流程：

一、首先作好技術調研，拿典型的程序作好技術的試點驗證（所謂pilot）。

異構系統，在選則移植方案的時候，首先要作的就是要嘗試手動作一次程序移植，把關鍵技術點解決掉，使得方案可行性獲得足夠的驗證。在這個過程中搞清楚兩個系統間的異同，從環境到代碼，採用到的各類技術都要造成完整的文檔。若是選定的典型程序移植後，功能和數據驗證經過，才能進行下一步的擴大規模的嘗試移植升級。好比說，我這個案例當中提到的這個項目，在pilot階段，就完成了Java web框架，把CICS系統當中的頁面控制，數據傳輸的95%的功能都完成了；更是驗證了IBM COBOL程序轉換爲MF-COBOL的規範，制定了相應的轉換規則，也經過MicroFocus Net xpress 實現了COBOL代碼的服務化。後面會講到的如何製造和使用工具一節，起到關鍵的做用，有了轉換規則才能編寫工具去完成代碼轉換。

因此pilot階段是作好系統移植和升級的最重要階段，要完成整個項目的絕大部分技術難點的調研。只有作好了這個階段，才能往下作較大規模的展開改造，由於即便這個階段失敗了，發現方案有缺陷，連最基本的程序都完不成轉換的話，這個方案基本上就能夠否決，這樣一來經過試錯，來驗證方案的可行性，爲將來的總體工做打好基礎，與此同時也下降了項目風險。

二、經過pilot階段後，須要作進一步的較大規模驗證。

在pilot階段成功後，只是說明方案可行，但離實際應用還有一段距離。切不可掉以輕心，認爲基本方案驗證了就沒有了問題。因此在全面鋪開前再作中等規模的方案驗證，將完整流程再驗證一番，進一步排查出pilot階段未發現的各類問題。這個階段尤爲重要，咱們在這個階段進一步完善了工具，完善了Java Web框架，把新系統中運行的各類部署問題都一一化解，爲最終的大規模鋪開奠基堅實的基礎。把系統從轉換到開發，測試以及部署的完整鏈條所有打通。也在此階段培訓新人加入項目，由於pilot階段，項目人不多，在此階段後，在中等規模和全面鋪開的階段須要完成對人員的培訓，各類規範的實施和監督，確保完成移植的代碼知足項目制定的需求。

三、大規模鋪開前，人員培訓和規範相當重要

這個屬於管理問題，創建文檔，項目開發流程代碼規範等，在後面的文章裏面會詳細講到。培訓則是贊成全體成員的認識，確保工做成果不走樣，創建基本的質量保證。

言而總之，無論是對既存系統的升級改造，或是新建立業務系統，對於架構而言，選擇什麼樣的技術方案，都須要預先作好技術調研，瞭解好方方面面的問題。好比選擇微服務很是火，不少人就想是否是所有整成微服務？在作這樣的決定以前，必定要了解你既有系統的狀況，根據你的業務場景來判斷，是否是適合作成微服務？作成微服務後如何部署管理等等後續措施是否是可以跟上？等等問題都須要在調研階段給出答案。大膽嘗試，當心驗證，是不會錯的。

做者介紹

王巍，漣拓網絡架構師，先後就任於Achievo、IBM、HP，關注前沿技術，分佈式系統架構，組件化系統開發，機器學習和大數據，如今創業公司負責系統架構，樂於與你們一塊兒聊聊架構