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

这一次迁移，我们开始寻找新的解决思路。
首先，有什么是可以完全信赖的呢？就是至今还在生产机上日日夜夜跑动的千万行代码，以及每天都在新鲜产生的海量数据。
然后，我们只能依靠人工分析吗？如果我们把IBM-I上的这些代码和数据，都变成大数据。另外，让我们的技术和业务专家们输入他们的知识和分析逻辑，转换成规则建立在规则引擎。最后，利用今天自然语言处理、大数据分析以及AI的各种技术库，我们完全可以构建一个机器人来协助自己，所以我们就有了自研智能分析引擎。
最后为了方便大家的搜索检索，我们利用了一些开源的自动构图工具根据知识库去自动构建图形和流程图，可视化了知识库，这样我们就得到了一部活字典。

文章图片
2、找到切入点模块化迁移，新旧系统有机并行
有了智能分析引擎去帮助我们了解老系统之后，我们的第二个难题就是：我们的老系统内外部错综复杂，需要找到一个合适的切入点将它进行拆解和迁移。
1)MVP(MinimumViableProduct)功能和范围定义
第一步也是重要的一步就是定义MVP的功能和范围， MVP的成败决定了我们是否可以得到业务层和管理层后续的支持。大部分技术迁移的成功就在于我们要证明它有商业价值，并且在可接受的回收期。
首先我们选择了一个老系统没有的功能，从全新功能开始，意味着万一失败，对现在的系统和业务的影响不会太大。另外，也要考虑从最适合用新技术解决的业务痛点开始，痛点不够痛，大家不会动。一旦成功了，会让业务部门和企业感受到实实在在的的价值和回报，这样更容易得到业务部门、管理层和后续资金的支持。我们选择了后台系统最核心最重要的一块业务——支付和结算，以及整个流程中一个小服务——智能审查控制服务。利用大数据分析预测的技术可以大大提升整个审查控制的精确度，帮助我们客户、业务部门和银行控制支付风险。
除了实现功能，我们也在MVP里把基础设施构建好，并没有急着上线新功能，而是通过各种测试和完善，保证新架构的灵活扩展、稳定、性能和弹性等。
2）新服务和旧系统交互，有机并行
第二步，我们需要把新服务和旧系统连接起来，有机并行。我们选择了在老系统建立了APIendpoints以及和消息中间件交互的适配器。这里我也想分享一个理念，就是老系统不能破罐子破摔。保证老系统对新系统的对接，是支持我们完成整个迭代式跨技术平台迁移大计划的重要保证。同时，为了尽可能减少对业务部门的影响，我们在MVP加入了统一的用户界面，它同时连接着新老系统背后的数据库，让对应业务部门在统一的入口看到了全貌，既享受了新系统带来的更丰富的前端功能，也不会在这个过渡阶段受到太大的影响。简单一句话就是，门面功夫还是要做足的。
这个MVP还是挺成功的，它收到了业务部门的支持，我们把单纯的技术迁移转变为业务和技术的同时推陈出新。
3）迁移现有功能
架构和基础都打好以后，我们才开始迁移现有功能模块。我们选择了邮件交易确认功能。考虑点就是，相对风险较小和容错率相对高一点的业务模块。另外，自动测试是迁移，特别是跨技术栈重构迁移的重要保证。业务系统本身的重构迁移开发和自动测试所用到的用例设计以及自动化工具，应该是同步的。