第二十季第7篇:应用迁移——上层软件是重写还是兼容,这是个生死问题

应用迁移——上层软件是重写还是兼容，这是个生死问题

老周干了二十三年ATM，见过的机器里，最让他紧张的不是硬件，是屏幕上的那行字：“应用加载中……”

硬件换完了，系统烧好了，外设也认了，最后那道坎是：银行自己的应用能不能在这台新机器上跑起来。

ATM的应用层，比你想的厚

一台ATM跑的软件，远不止"插卡输密码吐钱"那么简单。底层是工控机系统和驱动，上面一层是XFS中间件，再上面是银行的核心交易系统对接模块——负责和后台通讯、走ISO 8583报文、做交易路由。最上面是前端界面，也就是客户看到的触摸屏菜单、广告、语音提示。

这套东西，银行往往养了一个几十人甚至上百人的团队维护，有些模块是十年前写的，用C++或者C#，跑在Windows上，和Windows的API深度绑定。

重写还是兼容，两条路各有代价

路线一：重写。 银行把核心应用从零适配国产操作系统，把C#代码改成C++或者Java，把Windows API换成Linux接口。优点是干干净净，跑得稳；缺点是工程量巨大，老代码里很多业务逻辑没人说得清，重写等于重新做一遍需求分析。

"有些银行的核心交易模块，是2008年写的，"老周说，“当年写代码的人早离职了，文档不全，逻辑藏在代码注释里。这种东西你敢重写？”

路线二：兼容层。 用Wine或者类似的兼容运行环境，让Windows应用直接在Linux下跑。优点是快，几乎不用改代码；缺点是性能打折、稳定性没保障，遇到底层调用不支持的Windows API，应用会崩。

老周见过最离谱的：某银行的应用用了Windows的一个冷门组件，兼容层不支持，整个前端界面打不开。最后找了一圈，发现那个组件是用来显示广告轮播的，临时去掉，才让机器勉强上线。

还有第三种选择：换平台

部分银行借信创之机，干脆把前端界面换成Web架构——用浏览器内核渲染H5页面，后端用Java微服务。这样前端和操作系统解耦，Windows和Linux都能跑，反而省了重写之苦。

"这招聪明，"老周说，“但不是所有银行都敢这么干。核心交易系统牵一发动全身，换成Web架构等于动了银行信息化的地基。”

最难的是交易对接模块

前端界面换换还能凑合，真正要命的是核心交易模块。它要和银行后台核心系统通讯，走的是各家银行自己的私有协议，加上银联的CUPS、外卡组织的ISO 8583。这些协议在Windows下跑了几十年，换成国产系统，报文格式、加密算法、超时机制都要一一对齐。

老周遇到过一个故障：某网点信创机器上线后，偶尔出现"交易成功但客户没出钞"的纠纷。查了三天，发现是新系统下网络超时设置比旧系统短了两秒，遇到后台响应慢的时候，交易超时回滚了，但出钞模块已经执行了。这种问题，测试阶段测不出来，要真跑了几个月才暴露。

迁移的本质是风险转移

老周有个判断很到位：“信创迁移，表面上是技术替换，实际上是风险从’境外厂商’转移到’国内厂商’和’银行自己’身上。”

以前机器出问题，银行可以找NCR、Diebold、微软追责。现在换成国产，出问题找谁？找整机厂？找系统厂商？找驱动团队？责任链条一长，扯皮就多。而且问题往往不是某一家造成的，是芯片、系统、驱动、应用几家拼起来的"组合问题"。

"所以银行信创上线，最怕的不是哪一家不行，是几家都不行的时候，没人能拍板说’这锅我背’。"老周说。

应用迁移这一层，是整个信创链条里最看不见、却最致命的一环。硬件能拆能换，应用是长在机器里的神经。神经能不能在新身体里重新接通，决定了这台机器到底是一台能用的国产设备，还是一台昂贵的摆设。