交行“啃下”一小块硬骨头

采写|郭娟

自2013年起，中国的银行业在面对自己的基础IT架构时，就有一个大愿望——以自研创新实现核心部件替代。

数年过去，银行业依然在这条道上“小步慢走”，主要原因在于，银行对于系统的稳定性、交易的连续性要求极高，“IOE”（ IBM的大型机/小型机、Oracle数据库和EMC存储设备）方案中提供的大型机/小型机的稳定性暂时无人能及，另外，采用开放式架构的中小银行，可以不用IOE中的服务器，但也一直没有出现能替换的国产服务器。【1】

以自研创新实现核心部件替代，也从“愿望”变为银行业比较“难啃的一块骨头”。

始建于1908年的交通银行，历经时代变迁，目前在国内分设246家分行机构，其中省分行30家，直属分行7家，省辖行209家，共有2923个网点。【2】2020年5月，在行长一职空缺半年之久后，交通银行迎来了一位70后的年轻领导，他叫刘珺。

当时的交通银行百废待兴，在2019年年报中，六大国有银行中的工、农、中、建净利润超过千亿，唯独交通银行掉队，并被股份行招商银行以929亿元净利润的绝对优势超越。而让交行一向引以为傲的信用卡业务，在“贷款余额”和“交易额”上，也于2019年出现“双双负增长”，交行也成为当年（国有大行中）“信用卡不良率”最高的银行。【3】

新领导的上任，外界都对交通银行投来期待的目光，能发生点什么改变。

刘珺本人特别重视科技在银行发展中的作用，上任初始，他就在一次内部会议上强调：科技是银行的未来，科技发展代表银行在老百姓心目中的形象和份量，“我们在业务上落后于工农中建，但最可怕的是，我们在科技上也大幅度落后，就像跑田径400米，我们已经被别人套圈了，没有时间再继续跑马拉松，我们只有换新的模式去做。”

核心部件替代并不等于用ABC替换IOE，而是“用一套新的技术体系去替换原来的技术体系”——阿里云新金融和互联网事业部总经理刘伟光常年跟进金融领域的技术趋势，他的观点与交通银行要在“科技上换新模式”的想法不谋而合。

交通银行打算从暂时掉队的信用卡系统“开刀”，2020年7月22日，刘伟光带领团队，着手准备应对与交通银行的前期沟通，反过来看，寻求“外在技术力量”的支持也是交通银行“技术选型”的过程，在阿里云内部，一致认为这件事意义重大，并将其称为“史诗级的项目”。

然而，一波三折的磨合也由此开始。

当“分布式架构”成为一种替代方案

刘珺上任之后不久，交行科技部也来了一位新负责人，他对科技转型提出了更为具体的目标：“下大机”，这属于自研创新中最核心的部分。

众所周知，“IOE”架构包括IBM的大型机/小型机、Oracle数据库和EMC存储设备，长期以来，这三者深度绑定，占据主导地位。

早在2012年7月，国务院发布《关于大力推进信息化发展和切实保障信息安全若干意见》（国发〔2012〕23号），称信息安全工作的战略统筹和综合协调不够，重要信息系统和基础信息网络防护能力不强，移动互联网等技术应用给信息安全带来严峻挑战。必须进一步增强紧迫感，采取更加有力的政策措施，大力推进信息化发展，切实保障信息安全。依据这份文件精神，“大机”

之所以用“逐年减轻”，在于“下大机”这件事的确存在难度，尤其是IBM的大型机以及Oracle的关系型数据，成本极高，替代难度极大。例如，单在“I”的架构中就有“两道墙”：“一堵”是IBM的中型机AS/400 ，这是一种数据库中间件、存储、计算一体化的机器；另一堵“高墙”则是大型机（main frame，如S/390），在中国市场上，使用大型机的客户到目前只有11家，且全部在银行，即9+2，九大银行和两家农村信用社。

公开资料显示，AS/400每年的计划外停机时长为5.52小时，稳定性达到99.94%；而性能更优越的S/390，每年的计划外停机时长做到了10分钟，稳定性达到99.998%，接近100%。【5】

交通银行属于使用大型机的“九大银行”之一，提出“下大机”战略，体现了领导层“弯道超车”的决心，而且一开始，交通银行的针对极强，专门从信用卡系统“开刀”，此计划一旦实现，就意味着交行8000万账户从大型机上下移，这是拿“核心系统”动手术。

在这之前，银行业也不时有“下大机”的消息传出，但实质上只涉及一些边缘业务及用户数量较小的“对公业务”，账户数据量庞大的“核心系统”则绕开不碰。

信用卡系统在银行的“核心系统”里属于“贷记卡”业务，“核心系统”的英文表述为CORE Banking，CORE直译过来是“核心”，但它也是 Centralized Online Real-time Exchange （集中式在线实时交互）的缩写，“核心系统”承载了银行的存款贷款、支付结算、借记卡、贷记卡、投资理财以及所有对公金融服务和监管报送等核心业务，被称为经营的大脑，重要性不言而喻。【6】

另一方面，经过多年发展，IOE架构表面上看起来无懈可击，但它跟不上时代的一面已经出现，我国科技的自研创新始终是个首要问题，面对中国金融业的高速发展，IOE架构的“根基”也受到动摇。

例如，中国商业银行的多数业务，无论是与行业的深度绑定，还是对用户的触达，都实现了数字化手段的融合，再比如，商业银行客群的变化，涌现出了“移动金融、场景金融、消费金融等诸多新形态，新形态的背后亟需新技术架构的支撑”，阿里云金融部的架构师郑淼分析。

但重新建立一种新的技术架构谈何容易。大机集中化和分布式的运维方式，不仅是一个架构，更是深入骨髓的观念，非常难以改变。

长期在集中式架构的“熏陶”下，提及“上系统”，银行体系里的人几乎都在想“配什么软件、配什么硬件，配什么服务器，成为一种固有思维模式”，刘伟光回忆，阿里云提供的分布式架构，则不存在这些“障碍”，想要实现什么应用，能够快速调取资源，拿来就用。

另外，集中式架构有统一的技术战略，因为只有三家长期公司长期合作，因此，从硬件到软件，都比较好协调统一。如果换成分布式架构、切换到上云模式，“光硬件都不是一个标准化的设备，分布式架构面临着比较大的挑战，就是要协同其它开发商去适配阿里云的技术栈”，郑淼说道。

最后，迁移之后，能不能保证系统平稳运行，会不会出现一些无法预见的适配问题而导致系统故障，业务宕机？

分布式架构部署的应用服务器数量大大高于集中式架构，不仅面对分布式架构存储后的多数据管理，还需要处理微服务器架构下服务相互调用带来的一系列故障排查与服务治理，传统的运维手段很难满足运维要求，而以阿里云为代表的智能化运维时代已经开启。

从交通银行自身的发展来看，为了避免与同行产生过度的同质化竞争，结合自身优势，这家银行更重视零售业务，它着力于理财、基金、信用卡等发展特色业务，甚至为了发展好理财基金业务，单独成立了理财子公司，针对信用卡业务，成立了独立的信用卡事业部。

例如，交通银行的信用卡业务在某天推出理财促销活动，必然会出现大量的弹性访问，如果按照“IOE”架构，为了应对这样的活动，就要为此提前增加数据库的投入，这样的投入，周期长、成本高，且不必要。由于促销活动存在太多的突发情况，如果按照分布式架构的思路来构建弹性、高可用的资源，则可形成一套完美的“平替”，而这对于经过双11多年锤炼的阿里云来说，早就不是个问题。

这也是这些年，当银行业心怀自研创新的想法后，经常来自“灵魂拷问”的另一个问题：现存的哪种方案才能实现对核心部件的替代？

事实上，在金融体系探索自研创新的这些年里，支撑互联网公司高速运转的分布式架构也在不断成熟和完善，并开始实践于银行的非核心系统，例如2019年初阿里云中标的四川农信项目。四川农信属于国内银行体系9+2“上大机”中的“2”之一，另一家为江苏农信。

阿里云中标后，先从四川农信的边缘业务着手，先将该行的智能贷款、手机业务等非大机部署的业务迁移到分布式云平台上，平稳运行一年后，业务表现直观可见，“更敏捷、更快捷，资源使用更简单、不用独立性去扩容”，刘伟光回忆。

这次改造，也给四川农信近距离观察分布式架构带来的实际效果，到了2021年11月30日，四川农信核心系统也开启了分布式架构的迁移，据公开信息，“这是国内首个银行核心系统从传统大型主机向分布式云平台+分布式数据库+单元化架构+异地多活的全新架构开始全量迁移的战略性项目。”【7】

关于分布式架构的重要性，中国人民银行科技司司长李伟曾撰文分析，这是国家安全可控战略的要求，也是随着互联网发展，商业银行提升自身金融服务能力的需要。

李伟指出，“银行业关注分布式架构大概始于2013年”，主要有如下原因：一是国家对于技术安全可控的要求越来越高。二是互联网企业的跨界渗透，让商业银行在产品的推出效率、客户体验、精准营销、业务场景方面作出改进和安排，这就要求银行的IT架构必须灵活、开放。三是银行业经营竞争日趋激烈，要求IT的投入必须低廉高效。四是中国大型商业银行的客户数量和账户数量，基本都在“亿”级规模，传统软件供应商给出的方案，难以满足互联网时代业务快速发展的要求。【8】

“打光最后一颗子弹”

阿里云方面也意识到交行信用卡体系“下大机”意义重大，“单元化架构，同城三中心的架构在大型商业银行、银保监会的定义里，这是第一次落地”，郑淼解释。

交通银行方面，也把这次转型作为“重要的业务系统改造”上报给银保监会，据了解，这种年初上报、年底检查评选的机制，是银保监会为了鼓励各商业银行保持科技创新能力而设置，例如中国工商银行做的“两地三中心”架构在早年就获得过“特别奖”。

“两地三中心”具有鲜明的时代特色，背后的支撑架构仍然是“IOE”，所谓两地，是指本地、异地，三中心是指三个数据中心：生产中心、同城容灾中心和异地容灾中心。“两地三中心”的推出，一度让其他商业银行效仿。

在这种模式下，多个中心是主备关系，即只有生产中心对外提供服务，同城容灾中心是生产中心的备份，当生产中心无法提供服务时，将流量切换至同城容灾中心，当同城双机房都发生故障时，启用异地灾备中心。

今天看来，“两地三中心”的实质，是“通过资源的堆砌与冗余来应对不确定事件的发生”，由于存在对灾难的响应和机房的切换周期长，无法实现业务的零中断，对设备资源的利用率低下等问题，也让各个企业寻求转变。【9】

阿里云给交通银行提供的同城三中心、单元化架构的解决方案，与银行业普遍认为最优的“两地三中心”架构相比，有本质的区别，“同城三中心”的设置对于阿里云是一件再正常不过的事，阿里云在各城市自建数据中心一贯走的也是同城三中心，这种设置对于银行业来说有什么优势呢？

从原理上来说，同城三中心，意味着三个数据心同时承担流量，如果其中一个数据中心宕掉后，损失掉三分之一的业务量，剩下两个数据中心则能很快做到全量接管，“这能更好地帮助商业银行实现一个比较好的业务连续性的同时，还能节省不止他们用来买大型机的成本”，郑淼分析。

在银保监会那里，商业银行里的任何交易一旦发生事故，都要求半小时内必须恢复正常，事实上，按照传统架构，商业银行里，一个业务交易可能跨很多台机器，如果发生故障，去切换的时候，怎么能够切过去保证交易的一致性，这对商业银行至关重要。

“大型商业银行，只有工商银行敢于做切换”，业内之所以有这样的评价是因为工商银行对于科技的投入特别大，公开数据显示，其科技部有3.6万人的设置，而其他银行对于切换这件事非常慎重。在阿里云给到交通银行的同城三中心、单元化架构的方案里，“能很快把交行的业务从A数据中心迁移到B数据中心”，做到“常切”“敢切”和“能切”。

郑淼解释，“常切，支持的是长期切换，随时能切；敢切，出现了计划外的风险，有信心去处理；能切，表明阿里云具备切换的能力。”

交通银行“下大机”的项目从2021年4月开始招标，到了当年8月基本上与阿里云达成合作，其中，第一期的计划上线时间为2021年12月，但到了11月24日，交行方面忽然作出一个决定，当时的环境能力不具备上线条件，要推到2022年1月份上线。

“如果再推到2月份，阿里云基本没有机会了，这意味着项目的失败。所以只有一个窗口，就是1月份”，刘伟光回忆，他至今仍记得当时这个项目遗留了70多bug，要在1月份完美交作业，只剩下40多天的时间，“我的汗哗哗下来，也立即把群名改为‘交行四十天生死决战群’”。

好在一期交付时，交行方面给了很高的评价，不仅发了感谢信，也向阿里云提出了新问题：这件事有没有意义，能不能超越邮储银行？刘伟光回应，“我们做的这件事，在国际上都是最先进的。”

“要从传统IBM架构变到云平台，同时这个云平台还设计多地多活、单元化部署的能力。这个世界上目前最先进的架构，云上面还有叠加分布式数据库，这个改造量、工程量是非常庞大的，国内没有干过这件事情。”

与邮储银行也没有可比性，“一是邮储本身不是大机，而交行这次下的是大机；二是邮储银行没有技术上投产，业务也没有上，而交行完成了信用卡的投产；三是对分布式架构的理解，阿里云对分布式架构已经从早年的云+数据库，衍生到一个更广义的云原生架构体系即云+分布式数据库+容器化部署+全链路压测+单元化部署+异地多活能力。”

交行的信用卡体系不仅顺利转换为分布式架构，在2022年1月，一期上线充分取得交行信任后，到2022年4月，又陆续完成了其他十几个业务体系的切换。

这个项目背后的推进过程相当曲折，上文提及，2020年7月22日，阿里云就开启了与交通银行的接触，到了2020年9月，阿里云、蚂蚁金服以及交通银行方面初步达成一个合作意向，但到了2020年11月，蚂蚁金服折戟IPO，波及到阿里云与交通银行的合作，甚至其他正在合作中的金融项目都受到影响，市场信心降到冰点。

2021年4月，交通银行的项目招标正式开启后，阿里云中标，然而，到了当年6月，一众阿里人见到交行新上任的副行长钱斌时，他的开场白便是：“这个标来得太早，如果当时我在，我不认为应该选阿里云”……

好在磨合到2021年8月，才最终定下来，从拿到项目到计划交付第一期的12月，倒计时四个月！刘伟光当时承担了巨大的压力，在负面舆论排山倒海的情形下，如果交行的信用卡体系“下大机”失败，“我们从此将被舆情淹没”。

刘伟光抱着“一将功成万骨枯”的心态去开启这个项目，他在心里给自己立下“军令状”：“这个项目我们不能输，必须要打光所有子弹，不留遗憾。

为了打赢这个“战役”，最艰苦的时候，阿里云方面投入了200多名精兵强将，“不关心合同多大、服务是否亏本”，在交行数据中心空间有限的情形下，这200多名驻场人员把咖啡馆、走廊上、乒乓球桌甚至女更衣室都变成他们的办公地。

正是这个团队用“打光最后一颗子弹”的决心，让我国银行业核心系统的自研创新迈出了实质性的一步。

（本文采写于2022年7月，原文首发自钛媒体·阿里云合作的《云栖战略参考》）