一、基于IBM-I的大型银行核心系统基本现状核心系统改造是近年来银行业的热点话题。银行是最早开始构建自己的数字化和自动化IT系统的行业之一。经过几十年的发展，这些IT系统和背后的庞大数据成为了银行的一笔财富，但也成为了一种负担。比如我今天介绍的一个大银行基于IBM-I的核心系统，完全是汇丰自己开发的。历经30多年的开发和运营，积累了数千万行代码和海量数据。迄今为止，该系统仍然支持我们全球市场50多个国家和地区的多个中后台业务领域，包括运营、财务和风险管理等，不仅要支持全球统一标准化的业务流程市场，也满足许多区域需求。同时，作为骨干系统之一，它与汇丰其他300多个内部系统相连，错综复杂，犹如古木之根。我在这个团队整整10年，基本上都是在为这个骨灰级的核心系统寻找各种新技术和新的替代方案，有失败也有成功。今天，我的分享将围绕我过去10年参与的两次大规模重构迁移的故事展开。都说时代创造人，其实时代也创造格局和选择。在技??术世界中，每5年就是一个新时代。十年两次迁移，我们在平台、架构、技术栈、整个开发部署模型上的选择和决策都有很大的不同。这次回顾分享，背后的思考和思考，希望能给自己和大家带来一些参考。二、两次大迁移1、第一次大迁移10年前，我开始参与这个核心系统的第一次迁移。主要目标是将全球50个独立运营的第一代实例聚合成3个亚洲、欧洲和美国大面积的实例也在我们的第二代系统上，类似于“大集中”项目当时在国内外颇为流行。十年前，IBM还是行业的老大，尤其是在金融科技领域。IBM-I具备健壮性和稳定性等中后台系统必备的优良品质，在后台处理和批处理方面也有其优势。所以当时二代系统的迁移还是选择了IBM-I。这个跨越5年的重构和迁移项目总体上是成功的。改制后的二代系统采用了当时更为先进的设计理念。同时，在整合和迁移的过程中，我们在全球范围内简化、优化、标准化和自动化了全球市场运营的整个业务流程。此外，我们在IBM-I上对核心模块进行了瘦身，清理了约30%的旧功能和无用代码，解构了部分功能、新服务以及很多与其他系统交互的接口模块，独立运行。第一次迁移总体上还是比较成功的，也为我们第二次迁移打下了良好的基础。不过跑项目的过程有点受不了。我们以瀑布模型运行整个项目。第一代系统支持的所有业务、功能和数据一次性迁移到第二代系统。即使50个国家分几批上线，平均周期也是一年一批，每批10个左右，每批还是比较大的。忙碌了整整一年，成败决定于终于上线的那一刻。更确切地说，是激动人心的48小时周末。如果成功，旧系统将被一键关闭。自周一以来，来自全球不同国家的所有用户都在使用新系统开展日常工作。这就是我们常说的“BIGDAY”。所有的投资和风险一直在积累，价值和回报只有在“BIGDay”成功推出后才开始，投资回收期长达数年。2.第二次大迁移第一次大迁移5年前基本完成，我们开始构思这个大规模核心系统的第三代。1）第一个灵魂拷问：还是IBM-I，如果不是，会是什么？IBM-I，曾经的王者。随着时代的变化，它支持的编程语言对我们采用新的架构和设计理念有很多限制。庞大而全面的结构和设计，使得更新速度跟不上行业需求的节奏。最紧迫的问题是，旧体制已经无法吸引年轻和新的人才加入。所以，我们5年前就做了一个决定，我们开始远离IBM-I，如果不是IBM-I，那是什么？微服务架构、分布式设计、云原生系统。我们的系统要支持全球市场，7*24在线模式是必须的。金融市场瞬息万变，这个行业对系统更新的要求并不比互联网行业慢。但金融体系需要在灵活快速的更新扩容与稳定性和安全性要求之间取得平衡。分布式架构可以满足我们的要求。数据为王。基于大数据的分析预测和AI/MI的应用已经是基本需求，也是银行保持竞争力的本质要求。因此，我们的新系统必须具备分析大数据和AI/ML模型对接的能力。最后，还有一个重要原则：坚持内部研发，尤其是核心模块。2）第二个灵魂拷问：系统迁移只能一步完成吗？对于系统迁移，在需求上，业务部门希望一步完成，而不是在新旧系统之间切换。技术脱离业务是伪技术，所以我们做的任何技术方案都必须有业务部门的支持。但是我们也问问自己，问问业务部门，能不能再有5年的系统迁移？如果五年后推出新系统，世界已经发生翻天覆地的变化，我们还能等五年吗？能否通过双机并行数据同步、统一录入等方式迭代敏捷迁移，将对业务部门的影响降到最低？3、“迭代式”敏捷迁移的挑战1）第一个挑战：对原有系统的全面理解。30年时间足够长了。我们组的第一代程序员都已经退休了。它们已经运行了30多年，没有人可以声称完全了解迄今为止仍在更新的旧系统。对原始系统的全面了解是第一个巨大的挑战。2）第二个挑战：找到模块化迁移的切入点，新旧系统有机并行。原系统庞大完备，内外错综复杂。如果我们要做迭代迁移，我们需要找到一个合适的切入点。它的整个模块被解剖解构，再模块化迁移，难度也比较大。引用一位同事的比喻，就像做外科手术一样，手术中的精准度和手术后的缝合非常重要。3）第三个挑战：新旧系统有机并行，一起敏捷，统一运维迭代敏捷迁移必须解决的挑战之一是新旧系统需要良性交互和有机并行。业内有一个很好的类比。如今，银行核心系统的改造犹如一场不停歇的心脏置换手术。那么通过什么方法可以保持新旧系统的良性交互和有机并行，我们的开发运维团队能否同时跟上两个系统呢？这是我们最后也是最大的困难。1、充分理解10年前原系统的第一次迁移。我们采用翻箱倒柜的方式，寻找历史文档，然后人工分析，将文档与代码进行对比。但是随着时间的推移，这套方法已经行不通了。了解IBM-I的人越来越少。前面说过，第一代程序员甚至已经退休了。人工分析工作量大，周期长。原有系统仍在不断更新完善中。人工分析跟不上进度，人为失误的概率也很高。对于这次迁移，我们开始寻找新的解决方案。首先，什么是可以完全信任的？是生产机器上还在日以继夜运行的上千万行代码，以及每天新鲜产生的海量数据。那么，是否只能靠人工分析呢？如果我们把IBM-I上的这些代码和数据变成大数据。此外，让我们的技术和业务专家输入他们的知识和分析逻辑，将其转化为规则并构建在规则引擎中。最后，利用当今自然语言处理、大数据分析、AI的各种技术库，我们可以造一个机器人来辅助自己，所以我们有了自主研发的智能分析引擎。最后，为了方便大家的搜索和检索，我们使用了一些开源的自动构图工具，根据知识库自动构建图形和流程图，将知识库可视化，这样我们就得到了一本活字典。2、找到模块化迁移的切入点，新旧系统有机并行。在有了智能分析引擎帮助我们理解旧系统之后，我们的第二个问题是：我们的旧系统内外复杂，我们需要找到一个合适的切入点进行集成、拆解和迁移。1）MVP（MinimumViableProduct）功能和范围定义第一步也是重要的一步是定义MVP的功能和范围。MVP的成败，决定了我们能否得到业务层和管理层的后续支持。大多数技术迁移的成功在于我们必须证明它具有商业价值并且在可接受的投资回收期内。首先，我们选择了一个旧系统没有的功能。从一个新的功能开始，意味着一旦出现故障，对当前系统和业务的影响不会太大。此外，还要考虑从最适合用新技术解决的业务痛点出发。痛点还不够痛，大家就不动了。一旦成功，将使业务部门和企业感受到真正的价值和回报，更容易获得业务部门、管理层和后续资金的支持。我们选择了后台系统最核心也是最重要的部分——支付结算，以及一个贯穿整个流程的小服务——智能审核控制服务。利用大数据分析预测技术，可以大大提高整个审核控制的准确性，帮助我们的客户、业务部门和银行控制支付风险。除了实现功能，我们还在MVP中搭建了基础设施。我们并不急于推出新功能，而是通过各种测试和改进来保证新架构的灵活扩展、稳定性、性能和弹性。2）新服务与旧系统交互，有机并行第二步。我们需要将新服务与旧系统打通，有机地并行化。我们选择构建与旧系统中的消息中间件交互的API端点和适配器。在这里我也想分享一个理念，就是旧制度不能破。保证老系统与新系统的对接，是支撑我们完成整个迭代跨技术平台迁移计划的重要保障。同时，为了尽量减少对业务部门的影响，我们在MVP中加入了统一的用户界面，同时连接到新旧系统背后的数据库，以便相应的业务部门可以统一入口看全貌，享受新系统带来的更丰富的前端功能，在这个过渡阶段不会受到太大影响。简单来说，还有很多工作要做。这个MVP还是比较成功的，得到了??业务部门的支持，我们把纯技术迁移转化为业务和技术，同时推陈出新。3）已有功能模块的迁移在已有的功能架构和基础打好后，我们开始迁移已有的功能模块。我们选择了电子邮件交易确认功能。考虑的点是风险比较低，容错率比较高的业务模块。另外，自动化测试是迁移的重要保障，尤其是跨技术栈的重构迁移。业务系统本身的重构、迁移、开发和自动测试所使用的用例设计和自动化工具应该是同步的。五年过去了，这就是今天双IT架构的整体面貌。我们已经基本摸清了自己的思路和路线，找到了一条可持续发展的道路。此外，更重要的是，在业务部门、管理层和后续资金的支持下，我们也从单纯的技术迁移转变为技术和业务的同步迁移和创新。3、新旧系统保持一致的敏捷节奏和统一的运维模型。打好架构和基础之后，我们面临的第三个挑战是两个系统是有机并行的，所以我们需要开发和维护两个系统，平台技术栈和使用的工具不一样，团队越来越少并且负担更轻。通过应用与自研相结合，我们构建了自动化工具链，以及新旧系统适配的一站式开发运维平台，助力自救。下图是我们当前团队使用的工具集的概览。有一些工具在业界被广泛使用，你应该熟悉，比如Jira、Jenkins、CheckMarx，还有一些特别适合IBM-I系统的工具。比如RTC、RDI、Arcad，带星号的是我们自己开发搭建的工具和平台。分享我们在工具选择和自主研发设计上的一些想法。1）优先选择行业内的优秀工具。因为行业里的工具会有很多场景跟用户一起去论证和不断完善，一定程度上会比我们自研的更全面。此外，采用行业工具可以让我们将精力和时间集中在我们自己在金融科技和业务领域的专业知识上。2）当行业没有合适的工具时，我们可以自己开发构建。例如，我们为IBM-I开发了IBM-I特有的编程语言RPG自动扫描工具，以确保代码的安全和质量，以及上述新旧系统适配的自动化测试框架。当所有的行业和自研工具都搭建完成后，一个新的问题是：我们在不同的工具平台之间轮换，这极大地影响了我们的工作效率和质量。为了解决这个痛点，我们搭建了适合自己的一站式开发维护平台，让大家可以在一个平台上完成大部分日常工作。我们集成平台的实现并不复杂：现在大部分工具都是API接口，我们只是在上面搭建一个一站式的平台，通过API自动触发和连接不同工具上的动作，然后从不同的地方使用API平台捕获所需的信息。之前，我们需要登录10多个工具平台，点击200多次，才能完成一个标准的变更流程。现在您只需登录我们的一站式平台，20多次点击即可完成整个流程。这个平台对我们需要同时支持新旧系统的团队很有帮助。此外，我们还为同事使用不同的工具节省了大量的学习和培训成本。最后，跟大家分享一下我们在开发构建工具时对技术栈选择的一些考虑。首先，工具和平台的构建和运行也是为了脱离IBM-I，这与我们的愿景是一致的。同时，我们的目标是一套新旧系统适配的工具和平台。二是采用更加开放的新技术栈开发构建工具，为原IBM-I技术人员提供从实战中学习新技术栈的机会。我们有相当数量的IBM-I程序员，他们在开发工具的实战中掌握了新技术，成功地进行了新老系统的转换，新老技术栈都懂，业务也精通。他们已经成为我们迁移团队大计划的骨干力量。4.思考与总结技术或者模型不分高低，IBM-I还是云，瀑布还是敏捷，没有好坏对错之分，最适合的就是最好的。人和文化比技术更重要。各种技术只是工具，架构和设计的理念，以及一直在探索、学习和创新的团队和文化，才是永恒的。
