老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包不同版本依赖，而且这些版本相互冲突等问题，好处非常多，不再一一列举。