洞若观火，聊聊旧系统升级改造那些事儿

因为常常在聊聊架构群里看到有很多朋友在问旧系统升级改造的一些原则与经验，大家面临着各种各样的问题，于是在这里跟跟大家聊聊我经历的那些旧系统改造的那些事儿。

当系统日益臃肿，状况频出，难以满足公司业务发展的需要，运维感到压力山大，但公司出于保护投资的动机，又不能完全抛弃现有系统，另起炉灶。那么对该系统进行升级改造呢就不得不提上日程，因此我们首先要做的是直面系统所存在的问题，明确系统升级所需要达到的目标，再根据目标提出相应的架构解决方案。

我们来看一个案例：某日本公司 W 系统使用 COBOL 语言开发于 70 年代，运行在 IBM 的 Mainframe 大型机上，数据存储使用 VSAM（Virtual Storage Access Method），结构上采用 C-S 架构，用户使用仿真终端工具远程登陆主机；批处理使用 JCL（Job control language）；在使用了 30 多年后，公司不得不进行改造升级。首先我们应当分析其存在的问题：

1、运行平台维护困难，成本高昂。

该系统运行于 IBM Mainframe 大型机系统，诞生于 1964 年的 S/360，系统为 OS 360，后面陆续推出 OS 370，OS390，最新的是 IBM Z13 大型机，以其强大的计算能力，极高的可靠性（年维护时间不超过 5 分钟）以及其安全性深受各个行业所信赖，尤其广泛应用于银行金融等关键领域。但购置费用极其昂贵（注：2014 年 Z10 报价 2000 万美元，最便宜配置也是 500 万，听说近来降价了）， 其运维成本更是十分巨大，运维人员费用昂贵大家都知晓，其他仅机房空调电费一项就非常可观，不是土豪用不起啊。

在 30 多年前性能强安全稳定的服务器屈指可数，价格昂贵自然是情理之中，但如今各种架构服务器价格已经亲民许多，因此在服务器上已有足够多的选择，采够相对实惠的硬件可以将有限的预算花到其他更需要的地方；尤其是对于企业而言，如何将预算使用的更加高效是每天都要面对的问题；因此成本概念不仅仅是公司老板和财务经理需要，作为架构师也是需要具备成本成本意识，关注软件架构在各个阶段的成本。

2、数据和代码维护困难，难以跟其他企业信息系统进行数据交换

COBOL 语言还属于面向过程的高级语言，有着严格的代码格式，位置写错了都编译不过，在主机上 debug 极其不便，基本只能靠 log 文件输出查看数据；况且这些代码都用了近 30 年，当时比我年龄都大，也是历经多次更改，具体业务也几经变迁， 当年写代码的程序员只怕是都退休了，维护极为困难。使用了 CICS（Customer Information Control System）中间件，由于 IBM 主机系统的封闭性，该系统与其他企业信息系统进行数据交换困难，COBOL 调 JAVA，COBOL 调 C 等异构程序间的数据交互的开发非常繁琐，对人员技术要求较高。数据存储采用了 VSAM，是一种文件存储方式，远远不能满足当今数据存储的要求；在对数据分析挖掘的需求日益增多的今天，更是无法满足这些新需求的需要。

3、主机终端资源有限，同时在线用户数难以扩容

在 C-S 架构下，使用系统是通过终端设备连接至主机系统，由于主机资源有限，各系统同时终端连接数是固定的，因此当需要进一步扩大同时在线用户数量则受到诸多限制；毕竟主机资源昂贵，开一颗 CPU 核心也是需要付出不菲的美刀的。

针对上述三个主要矛盾点，我们发现主要的问题在于平台架构和运行环境所带来的桎梏使得非改不可。所以就这样的需求而言，解决方案就非常直接:

1、平台整体移植至 windows，数据存储由 vsam 向数据库迁移。

首先是决定将 IBM COBOL 代码通过转换使其运行在 Windows 平台的 Micro Focus Net/Enterprise Server Express 服务器上，解决了硬件昂贵的问题，毕竟相对于主机而言，Windows 服务器的购置成本和运维成本仅仅是主机的九牛一毛，从而使系统运维成本大幅下降，运维人员也更易招募。其次，变 VSAM 文件存储为 Oracle 数据库，解决数据管理和使用上的种种障碍，毕竟在二十一世纪了，数据库较文件存储不知高到哪里去了（+1s）。最后，将批处理代码由 JCL 迁移至 BAT 脚本，调度控制采用了 Hitachi JP1 server，由这主要的三步将平台全部代码完整迁移至 Windows 平台。当然，同语言的异平台间的迁移的项目在日常工作当中难以见到，但给了我们一种思路，就是不要被底层运行环境所限制了思想，跳出来反而能获得新的收获。

2、系统由 C-S 架构转向 B-S 架构

将用户界面做整体转换，由之前的 UI 由 CICS 实现的 LMAP 页面转换为 Java web 应用，由于采用了流行的 BS 架构，之前由于终端数量限制的问题则得到解决。由于，CICS 系统本身有较多页面控制功能，因此我们采用 Java 自行实现了其前端框架的主要功能，如前后端数据转换与传输，页面显示及跳转这些基础功能。

因为客户公司要求界面及控制方式要与原有系统一致，保证完全的界面及功能与原有系统相同，从而减少对原有员工的培训和适应期，保证系统的顺利切换，避免因此带来的风险。当然这个跟日本的文化或者是人的特质决定的，他们在这方面要求比较古板，甚至显得十分令人难以理解的迂腐，但他们做事情的严谨态度还是值得学习。

3、将 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 个人月的成本。最终呈现的系统架构如：

对于这样陈旧的系统的移植升级改造，有着如下流程：

1、首先做好技术调研，拿典型的程序做好技术的试点验证（所谓 pilot）。

异构系统，在选则移植方案的时候，首先要做的就是要尝试手动做一次程序移植，把关键技术点解决掉，使得方案可行性得到足够的验证。在这个过程当中搞清楚两个系统间的异同，从环境到代码，采用到的各种技术都要形成完整的文档。如果选定的典型程序移植后，功能和数据验证通过，才能进行下一步的扩大规模的尝试移植升级。比如说，我这个案例当中提到的这个项目，在 pilot 阶段，就完成了 Java web 框架，把 CICS 系统当中的页面控制，数据传输的 95%的功能都完成了；更是验证了 IBM COBOL 程序转换为 MF-COBOL 的规范，制定了相应的转换规则，也通过 MicroFocus Net xpress 实现了 COBOL 代码的服务化。后面会讲到的如何制造和使用工具一节，起到关键的作用，有了转换规则才能编写工具去完成代码转换。

所以 pilot 阶段是做好系统移植和升级的最重要阶段，要完成整个项目的绝大部分技术难点的调研。只有做好了这个阶段，才能往下做较大规模的展开改造，因为即使这个阶段失败了，发现方案有缺陷，连最基本的程序都完不成转换的话，这个方案基本上就可以否决，这样一来通过试错，来验证方案的可行性，为未来的整体工作打好基础，与此同时也降低了项目风险。

2、通过 pilot 阶段后，需要做进一步的较大规模验证。

在 pilot 阶段成功后，只是说明方案可行，但离实际应用还有一段距离。切不可掉以轻心，认为基本方案验证了就没有了问题。所以在全面铺开前再做中等规模的方案验证，将完整流程再验证一番，进一步排查出 pilot 阶段未发现的各种问题。这个阶段尤其重要，我们在这个阶段进一步完善了工具，完善了 Java Web 框架，把新系统中运行的各种部署问题都一一化解，为最终的大规模铺开奠定坚实的基础。把系统从转换到开发，测试以及部署的完整链条全部打通。也在此阶段培训新人加入项目，因为 pilot 阶段，项目人很少，在此阶段后，在中等规模和全面铺开的阶段需要完成对人员的培训，各种规范的实施和监督，确保完成移植的代码满足项目制定的需求。

3、大规模铺开前，人员培训和规范至关重要

这个属于管理问题，建立文档，项目开发流程代码规范等，在后面的文章里面会详细讲到。培训则是同意全体成员的认识，确保工作成果不走样，建立基本的质量保证。

言而总之，不管是对既存系统的升级改造，或是新创建业务系统，对于架构而言，选择什么样的技术方案，都需要预先做好技术调研，了解好方方面面的问题。比如选择微服务非常火，很多人就想是不是全部整成微服务？在做这样的决定之前，一定要了解你既有系统的情况，根据你的业务场景来判断，是不是适合做成微服务？做成微服务后如何部署管理等等后续措施是不是能够跟上？等等问题都需要在调研阶段给出答案。大胆尝试，小心验证，是不会错的。

作者介绍：

王巍，涟拓网络架构师，前后就职于 Achievo、IBM、HP，关注前沿技术，分布式系统架构，组件化系统开发，机器学习和大数据，现在创业公司负责系统架构，乐于与大家一起聊聊架构。

本文是老系统升级改造的第四篇文章，点击链接，阅读前三篇文章：

磨刀不误砍柴工，聊聊旧系统升级改造那些事儿

量力而行，聊聊旧系统升级改造那些事儿

未雨绸缪，聊聊旧系统升级改造那些事儿