大型银行核心系统“迭代式”敏捷迁移之路( 二 ) 本文根据黄丽丽老师在〖2022

文章图片
2、第二次大迁移
5年前第一次大迁移基本上完成，我们又开始了对这个大型核心系统第三代的构想。
1）第一个灵魂拷问：还是IBM-I吗，如果不是，又将是什么呢？
IBM-I ，曾经的王者。随着时代的变迁，它特别支持的编程语言，对于我们采用新的架构和设计理念有很多的限制。大而全的架构和设计，令到更新的速度已经跟不上业界需要的节奏。最迫在眉睫的问题就是，老系统已经无法吸引年轻人和新的人才加入了。因此， 5年前我们就做了一个决定，我们开始搬离IBM-I ，如果不是IBM-I ，那又是什么呢？
微服务架构、分布式设计、云原生系统。我们的系统需要支持环球市场， 7*24在线模式是必须的。金融市场瞬息万变，这个行业对系统更新的要求，不比互联网行业慢。然而金融系统需要在灵活快速更新和扩展的同时，和稳定安全的要求上要取得一个平衡点，分布式的架构能够满足我们的要求。数据为王，基于大数据的分析预测和AI/MI的应用，已经是基本需求，也是银行保持竞争力的必备要求，所以，我们的新系统要有能力和大数据分析以及AI/ML模型的对接。
最后还有一个重要原则：坚持内部研发，特别是核心模块。
2）第二个灵魂拷问：系统迁移只能一步到位吗？
系统迁移，在需求上面，业务部门是希望一步到位的，而不是在新旧两个系统之间转换。脱离了业务的技术就是伪技术，所以我们做任何的技术方案一定得到业务部门的支持。但我们也问自己，问业务部门，能否再来一次为期5年的系统迁移？如果5年以后新系统才上线，世界已经发生了巨大的变化， 5年我们等得起吗？我们是否可以迭代式敏捷迁移，通过双机并行数据同步统一入口等手段，最小化对业务部门的影响呢？

文章图片
三、“迭代式”敏捷迁移的挑战
1）第一个挑战：全面了解原系统
30年是一个足够久远的年代，我们组里第一代的程序员甚至已经退休了，运行了30多年且至今还在不断更新的老系统，已经没有人能说完全懂它，对原来的系统进行全面的了解是第一个巨大的挑战。
2）第二个挑战：找到切入点模块化迁移，新旧系统有机并行
原来的系统大而全，内外部错综复杂，我们如果要做迭代式的迁移，就需要找到一个合适的切入点，能够把它整个模块解剖解构，再模块化迁移，难度也较大。引用一位同事的比喻，就像做外科手术一样，手术中的精准和术后的缝合都是非常重要的。
3）第三个挑战：新旧系统有机并行，一起敏捷，统一运维
迭代式敏捷迁移必须解决的一个挑战就是新老系统需要健康交互、有机并行。业界有一个挺好的比喻，如今，银行核心系统做转型，就像在做一个不能停的换心手术，所以用什么方法能够保持新老系统的健康交互和有机并行，而我们的开发运维团队也能够同时跟得上这两个系统？这就是我们最后一个也是最大的难点。
1、全面了解原系统
10年前第一次迁移，我们采用的是翻箱倒柜，找历史文档，然后再人工分析，把文档和代码比对。但是随着时间的迁移，这一套方法已经行不通了。懂IBM-I的人越来越少，就像之前说的，第一代的程序员甚至已经退休。人工分析，工程量大，周期长，原系统一直还在被持续不断地更新改进中，人工分析根本跟不上进度，人为错误的机率也大。