老IT系統的升級和改造

導語

維護技術過時的老系統是很多開發人員不情願的事情，利用微服務架構理念，新老並行，可以減輕這種狀況。本文結合作者實踐經驗介紹了老系統平滑改造的一些方法。

老系統的困境

很多公司都有一個或多個老的IT系統，這些系統業務價值很大，在自己的領域內發揮作用，是多年前開發的，開發技術和現在主流技術已經不同，業務在不斷的變化，需要不斷的改進完善系統、升級修復bug。作為開發經理或負責維護的工程師一般有3種方案：

在老系統上改，能少改絕不多動，能用就好。這樣做的好處是安全。但缺點也很明顯：

所需技術過時，招人都難，技術人員缺乏積極性

系統依賴的軟硬體環境變化，升級需要工作量巨大

軟硬體環境會隨時間失去廠商支持，總有必須升級的時刻

隨著模塊增加，越往後越難解決，除非等到業務不做，老系統自然消亡

推倒重來。耗時太久，大多數公司業務不會留出這麼多時間。

新老並行，新模塊用新技術開發，老模塊繼續在老系統上跑。難點在新老融合，如何不給用戶使用上增加額外負擔是需要重點解決的。

實踐新老並行、逐步取代的方式

下面結合我的經驗談下實踐第三個方法。

我接手過一個老系統，這個系統是用jsp、 jdbc與sqlserver 2005等開發的，系統需要跟隨業務頻繁變化，且老系統自身有些性能和bug方面的問題也需要改進優化。開發團隊其他項目使用mybatis、springrest、 mvc等框架在開發，不希望繼續用jsp，和其他項目技術不同也造成了管理方面面臨問題較多。以上是背景。

首先我們搭建了一個框架，包括用戶登錄和導航界面，老系統作為一個子系統加入進來。框架和所有子系統都單獨部署，每個子系統作為單獨的頁面或頁面的一部分在框架中展現，通過鏈接互相跳轉，用戶使用時並不會感覺到是多個系統。之後確立了以後開發維護工作遵循如下幾個原則：

1、新業務模塊開發作為獨立部署的子系統接入到這個框架中來

2、遇到老系統大的修改，獨立開發一個子系統接入到這個框架

3、急需且小的改動在老系統中修改

4、利用項目之間窗口期的空閑，把老系統中一些易變模塊逐步移植

最佳實踐分享

下面是我在實踐中遇到的問題的解決方案

新框架導航實現方法

1、使用iframe包含子系統的頁面，通過js動態隨內容調整iframe寬高，避免出現雙重滾動條

2、框架提供導航部分（可以是JS也可以是HTML），子系統在頁面中加入

2、通過反向代理把老系統中頁面融合到新框架中

3、使用frameset，雖然有些缺點，但在內部管理系統問題不大

老系統的改造成適合的子系統

老系統要加入進來，首先需要去掉原有的導航，避免雙重導航造成困擾。有幾個方法可以實現：

1、改老系統模板代碼去掉

2、全局js/css文件，增加導航可通過js，通過css隱藏不用的導航

3、通過servlet filter或反向代理修改返回的內容（此法實現複雜，如果上面的都有困難才建議使用）

用戶認證

獨立部署後，每個子系統都要進行用戶認證，有幾種實現方式：

1、如果有時間和技術做個獨立的OAuth 認證伺服器，這是最佳技術方案

2、簡單點可以在新框架中做認證，然後通過cookie記錄token，子系統系統都讀cookie獲取當前用戶

3、如果沒有獨立的OAuth伺服器，從token到當前用可以通過共享資料庫方式，也可以通過JWT（JSON Web Token）方式，建議JWT

資料庫存儲

獨立部署後，子系統之間有互相調用的需求，可通過如下幾種方式：

1、共享同一個資料庫，好處是工作量小，缺點是新老系統之間不夠獨立，耦合性高

2、每個系統單獨一個資料庫，耦合性低，缺點是需要處理的子系統間通訊多

子系統之間的通訊

1、子系統間通訊調用對方Web Services（建議RESTful API）通訊

2、子系統間通訊也可通過JMS實現，需增加一個消息伺服器

使用螺旋模型實現升級改造

完全過渡到上面提到的理想模式，需要的較長的時間，利用了項目空閑窗口期，時間不固定，要實現長遠目標需要有一個規劃，把所有工作先分解成若干可以上線發布的子任務（越小越好），子任務完成後即上線運行，隨時發布調整，螺旋式開發模式有利於整個目標的成功。

利用微服務架構理念，一步步平滑改造老系統，新老並行交替，平穩過渡，保障業務不中斷，即使出現問題的風險也在可控範圍內。過渡到多個子系統後，子系統升級修改互相影響較小，避免一處失效，全公司業務暫停的現象。單獨部署的子系統還可解決新老不同時期對同一個jar包不同版本依賴，而且這些版本相互衝突等問題，好處非常多，不再一一列舉。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！