01

工商银行信创现状猜想

相信业界没有人会质疑工行老大哥的IT实力，2022年报数据，工行年度科技投入 262.24亿；金融科技人员 3.6 万人【总行IT人员1万+ | 数据分析师超7700人】，占全行员工的 8.3%，相信是很多金融同业难以望其项背的高度吧。

 

 

上述基础确立了工行IT必须是坚定的自研实践者，先后自主研发了SAFE、CB2000、NOVA、NOVA+为代表的四代核心系统[i]，实现了数据大集中、“两地三中心”等重大创新突破。现在，相信举全行之力打造的第五代新系统《智慧银行ECOS工程》，也必会是信创方面有很大示范、标杆效应的灯塔项目【大家自己品味抄作业的力度哈】。

 

智慧银行ECOS工程

 

先来盘点一下官方信息，北京金融科技产业联盟、移动支付网联合举办的《金融科技大讲堂》曾邀请工行软开云计算实验室主任王鑫，在2020年8月分享了工商银行在分布式技术体系的实践[ii]，核心内容[iii]发布在北京金融科技产业联盟官方网站[iv]上。我提炼、总结成一张图来概览一下全景。 

 

 

ECOS的更多细节 

 

我们来摘录ECOS系统的一些有趣细节。

 

•       企业级架构方法为指导，经过七年建设和生产大规模实践，建设了技术领先、体系完备、安全可控的分布式技术体系，初步建成了开放平台核心银行系统，具备支撑主机业务下移，贴合开放化、高频次、高并发的金融级处理需求，涵盖核心系统分布式转型所需的研发、运行、运维等全方位企业级能力，实现大型商业银行信息系统从传统集中式架构向全分布式转型突破。

 

•      技术体系基于39项相关主流开源技术，采用“开源 + 自研”模式，对分布式服务、分布式事务等关键技术进行了深度定制，覆盖研发、运行、运维全生命周期，相较于开源版本在性能、功能、稳定性方面得到全面提升[v]。

• 一是面向研发环节为开发人员提供一站式方案。建设开发支持、资产共享、研发协同等一系列支持平台和工具，实现从需求受理到版本上线的研发协同及一站式工具链，帮助提升研发速度，促进各团队研发协作。

• 二是面向生产运行环节提供涵盖接入处理、服务集成和数据处理的运行支撑能力。建设分布式服务、软负载，事务、消息、批量、缓存、数据库、对象存储、文件存储等九大运行支撑平台，实现公共技术能力的集约建设与运营。

• 三是面向运维环节建设完备的运维支持体系。面向运维环节，建设了配置中心、日志中心、全链路监控、流量调度等一系列运维支持平台，实现可监控、可追溯、易定位、可隔离、可限流，适应分布式架构的高效运维体系。

 

•       截至2022年9月，工商银行95%以上的应用系统运行在“云+分布式”开放平台，完成分布式转型250余个应用，实现“应转尽转”，入云节点超13万个，服务数量超3万个，服务日均调用量超140亿次，日均处理消息请求超过3500亿次，峰值 403万TPS，可支撑日均千亿指标实时聚合、百亿链路信息实时分析。

 

•       工商银行信息系统全分布式转型实践项目在国际数据公司（IDC）举办的“2022 IDC中国数字金融论坛”中摘得“2022 IDC中国金融行业技术应用场景创新奖”殊荣[vi]。

 

另外，值得额外特殊强调的是，2022年初，工行智慧银行生态建设工程（ECOS）获得2020年人行科技发展特等奖[vii]，这可是工行IT历史上第三个人行特等奖。前面2个是9991数据大集中工程和两地三中心工程，大家可以据此自己判断、品味一下抄作业的力度。

 

摘录几个有趣的数字：

 

• 覆盖全渠道、全产品、全客户的全新生态化业务架构

• “云计算+分布式”技术底座，11万节点，23万容器，日均服务调用量超过120亿次

• 主机下移，完成客户信息、会计核算、账户体系等核心基础业务和快捷支付、信用卡等重点产品从主机下移； 创立“6步工程实施工艺”，建立了可复制、可推广的主机业务下移新路径，于2020年完成10亿+借记卡账户下移。 

 

工行基于“云+分布式”开放平台核心系统的方案还积极对外输出，为中航信、农发行、锦州银行等同业转型提供方案输出和产品与服务。

 

分布式数据库的猜测

 

 

相信工行这个级别的企业，分布式数据库架构标准明确下来之前，主流的选项都会去尝试与验证。考虑到目前的技术现状，可以想象选型过程的复杂和纠结，其过程，外部可见一波三折。

 

 

图表来源：知乎《工行MySQL转型实践》[viii]【2020 Gdevops全球敏捷运维峰会】

 

大体上可以分成3个阶段：基于MySQL的自研数据库；OceanBase和华为GaussDB。第一阶段是从2014年开始的MySQL之路，对外宣贯的高点在2019年左右，生产环境MySQL节点数量发展到近万个；应用场景也从外围低等级应用逐步推广到核心高等级应用【支持交易量达到7亿量级，峰期1.5万TPS】。

 

第二阶段，2019年12月工行和OceanBase官宣合作，2020年9月投产“对公理财系统“完成分布式改造，从主机下移、迁移到OB分布式架构。但2020外滩大会之后形势变化太快，貌似工行OB之路停顿。

 

2021之后，进入第三阶段，工行和华为官方都在发布工行大型业务系统 Oracle转型 GaussDB 的技术攻关的相关消息，应用范围逐步拓展到信贷类重要系统。2023年1月，信通院将华为与工行联合共创的分布式数据库转型实践方案评为2022“星河”标杆案例[ix]，相信后续一定是有内、外部的力量继续推广、拓展的。

 

当然，需要强调，工行这个级别的客户，在技术选项不完全成熟的背景下，多种尝试可能还会并存较长的时间，甚至可能还会有新的变数。目前来看，目测工行分布式数据库选型的赢家是华为GaussDB，后续重要的OLTP数据库，估计会择机慢慢收敛到华为GaussDB。更多信息，可以移步《探秘工行老大哥的去Oracle之旅》。

 

 

探秘工商银行去Oracle之旅

 

如果问Oracle在中国金融行业最大的客户，答案可能非工行莫属了吧。那去Oracle之路，大家是不是可以从工行抄作业。

 

【说在前面】本文是收集整理公开信息后得出的推测和预判，无法保障正确性与准确性。日常工作中和工行没有直接的接触，也没有任何内部信息源，如有异议，你是对的。

 

工行的分布式数据库选型可谓一波三折。先说结论：目测工行分布式数据库选型的最后赢家是华为GaussDB。当然短期之内，基于MySQL的自研数据库，OceanBase和华为GaussDB可能还会并存较长的时间，但后续重要的OLTP数据库，估计会择机收敛到华为GaussDB。

 

 

01

核心应用MySQL实践

 

 

 

第一阶段，按照第11届中国数据库大会DTCC工行软开林镇熙的演讲《工商银行核心应用MySQL治理实践》[i]，工行自身在MySQL投入了大量的资源，2014年就开始尝试、储备和试点使用MySQL，到了2020年，生产环境MySQL节点数量已经发展到近万个；应用场景也从外围低等级应用，推广到核心高等级应用【实施200 + 应用，MySQL支持交易量达到7亿的交易，峰期1.5万TPS】。有趣的技术细节包括：基于社区开源5.7版本；一主多从、两地三中心架构；90%以上容器化部署【1个主机4个以上的容器，4~8个，还有的10%跑物理机】；存储使用本地SSD等。

 

 

图表来源：知乎《工行MySQL转型实践》[ii]【2020 Gdevops全球敏捷运维峰会】

 

结合知乎2019年《工行基于MySQL构建分布式架构的转型之路》等[iii]，似乎宣告了围绕MySQL构建整个分布式架构转型方向，整体体系建设貌似达到了一定认同度，都是瞄准承接核心应用去的，貌似推广决心不小。

 

 

02

对公理财迁移到OceanBase

 

 

世事难料，2020年9月工行和OceanBase官宣牵手[iv]。

同时对外公布“对公理财系统“完成分布式改造，从主机下移，迁移到OB分布式架构[v]。工行搭建了横跨两地三中心的分布式集群，以五副本+主备模式提升高可用，给人感觉也同期搭建了后续推广的技术标准规范，第二篇章开启了。

但2020外滩大会之后形式变化非常快，网上没有了任何工行OB后续推广拓展的信息，工行的OB之路停顿了。

 

一些有趣的信息[vi]：

•  2019年12月，双方达成合作意向；2020年9月，试点对公理财投产[vii]。

•  两地三中心，同城机房级容灾、异地城市级容灾切换【支持数据库同城双活、异地 RPO=0，达到工商银行 5 级容灾要求，满足 7x24 小时服务要求】

•  下移到国产化 ARM 服务器，国产服务器，国产操作系统

•  便捷的水平扩展，阀值设定为据库服务器资源利用率的 75% 

 

 

03

GaussDB的技术攻关与普适性方案

 

 

第三阶段，真命天子貌似确定华为 GaussDB 。

2022年7月，华为开发者社区文章[viii]”【云驻共创】华为云之深入探秘GaussDB如何助力工商银行打造金融核心数据”，解密了工行大型业务系统 Oracle 数据库转型 GaussDB 的技术攻关路径，透露出2021年就有20多个业务系统上线，覆盖办公系统、一般业务系统和关键业务系统各类典型场景，形成一套覆盖工行主要商用交易数据库的转型方案；2022年工作重点，构建整套系统性技术资产和解决方案，在大型业务系统集中数据库领域持续展开技术攻关，对标主机“两地三中心“方案基于存算分离形成多集群部署架构【参考下图】。

 

 工行软开公众号“科技筑梦”，2022年4月发布了一个信贷系统采用GaussDB的双集群双活方案的例子[ix]，介绍新架构数据库硬件从x86架构转为国产ARM架构、系统从SLE12SP3替换为中标麒麟V10SP1、数据库架构从Oracle转向GaussDB，驱动从OJDBC转向GSJDBC等全面的架构改变。另外，亮点包括保证集群切换时数据的零丢失（RPO= 0），实测故障恢复时间只需2分钟（RTO ~2 分钟），仅为原来的十分之一等。从我盘点的角度来看，某种程度上算是侧面验证了华为的说法。

 

分布式数据库选型，工行经历了3段不同的旅程，现在应该收敛沉淀下来了。2023年1月，华为与工行联合共创的工商银行传统集中式数据库转型解决方案荣膺第中国信通院2022“星河”标杆案例[x]，工行的华为GaussDB旅程有了外部认证、加持，估计后续应会继续发力。

 

另外，多说一句，工行是华为GaussDB的老用户【从OLAP开始】。华为官网上报道[xi]：“2015年，华为与工商银行一起联合创新，Gauss OLAP数据库也开始在工商银行上线。从一开始的十几个节点到后来单个集群超过二百个节点，这大概是目前国内数据仓库中最大的。事实上Gauss OLAP数据库的产品交付过程也并非一帆风顺，在MPP大规模通信上踩过不少坑。“ 

 

以上，都是个人看法，是我基于已知公开信息作出的“有限理性”判断。如有异议，你是对的。如觉有益，请关注本公众号、点赞、转发和“在看”让更多人看到。更多人同行，我们可以走得更远。

 

 

 

02

建设银行信创现状猜想

 

 

 

整理一下金融标杆企业的信创进展情况，对！就是扒一扒建设银行的信创工程进展情况。

本文内容是结合公开信息作出的“有限理性”的推测和推断，不保证正确性和准确性。我在日常工作中和国有大银行没有任何直接的接触，也没有任何内部信息源，如有异议，你是对的。

 

为什么是建行？

 

建行核心系统最新，2017年才完成。网上建行历时6年多，采用企业级建模的核心系统（7层12P + 四个一：一套业务模型、一套IT架构、一套实施工艺和一套管理流程）信息丰富。更重要的是，和信创的时间节点最接近，重构的基础最好。

银行IT支出较为集中于头部大行，金融信创先锋开路。2021年中国银行业IT投入达到2200亿元，其中国有大行投入占比约为40%，率先展开信创国产替代。2023年1月31日，建行董事长田国立在建行云发布会上[1]表示，每年在科技上的投入约有200多亿元，占建行营业收入的比例逐年提高。

 

先易后难，全面替换

 

先易后难，相信以建行的资源和IT投入，2023年的今天，已经全面完成了第一类系统的信创工作。替换要求 “全面替换”，OA、门户、邮箱、纪检、党群、档案、经营管理。

比如相对复杂一点的OA系统，根据中国电子/长城的官网案例信息，已于2022年9月完成全面替换、顺利上线了[2]。技术全栈信创，基于中国电子旗下全链路产品，包括飞腾CPU、长城服务器、麒麟操作系统、麒麟云、麒麟云桌面、达梦数据库等。

 

• 建行2018年率先启动OA系统全国产化替换，2022年9月可见公开报道完成全面替换、上线。

• 总行数据中心：（服务器、存储、备份、网络、运维、安全保密、云平台）为总行、直属机构及各级下属机构商密文件的收文、发文、签报等提供办公服务。基于麒麟云和麒麟云桌面平台，麒麟云负责业务处理；麒麟云桌面承载原有X86桌面终端的接入，并把业务请求转发至麒麟云，用于兼容原X86桌面终端。业务终端：为各级业务部门提供桌面操作平台。国产化桌面终端直接接入总行办公云完成业务办理；原X86桌面终端通过麒麟云桌面进行业务转发。

• 金融行业首个基于中国电子“PK体系”全链（CPU、服务器、操作系统、云平台、数据库、终端桌面）创新技术大型办公系统。

• 覆盖建行总行、直属机构、海外机构、一级机构、二级机构等，日均处理公文及事项数量超30万件，平均交易处理时长3秒以内。

 

最麻烦的核心系统，先说信用卡核心

 

建行信用卡核心的起点是源讯公司基于IBM主机的Cardlink系统，2020年网上开始有天阳科技参与建设银行信用卡主机下移工程的公开信息，表明建行的卡核心下移不晚于招行[3]，略早于农行[4]。

作为对比，2022年1月17日，中国银行信用卡核心系统下移项目/新一代信用卡核心系统建设项目发布数据迁移服务分包采购公告[5]。建行在2022年实现全量1.4亿信用卡客户切换至信用卡国产化系统生产运行，使建行贷记卡系统成为业内首个用户量过亿的全栈国产化信用卡核心系统[6]。

卡核心的关键合作技术厂商是华为[7]，这个项目还获评《年度优秀金融科技解决方案奖》。披露出来的项目细节包括：采用分布式架构、微服务、全局路由与配置中心机制、共享数据访问、分布式消息机制、集中调度自动任务、分库分表、NoSQL数据库、分布式日志采集等技术；实现了系统的高性能、高可用、高可扩展性,使系统具备充分的横向扩展能力,实现近乎线性的处理能力扩展,支持海量的客户和发卡量。同时,也实现了系统核心模块软硬件平台的自有,采用鲲鹏硬件平台、GaussDB服务、中标麒麟V7SP1 (openEuler版)操作系统的组合,与存量x86系统组成融合异构基础设施,双线并行运行。

 

重头戏：多技术栈的银行核心系统

 

2022-07-26《金融电子化》杂志社刊登了建行金融科技部傅坚和孙代勇的署名文章，公开了核心系统的部分信创推进情况[8]。

建行2019年启动了基于多技术栈的银行核心系统建设工作，建设范围涵盖存款、贷款、借记卡、信用卡、客户信息等原本运行在IBM主机上的核心业务领域全量业务功能。

• 转型后的多技术栈银行核心系统实现多技术栈融合运行、分布式部署、模型化设计开发、全量并行验证、业务连续性保障等技术目标。

• 建行提出涵盖应用层、平台层、基础设施层端到端的体系化解决方案。首先利用前述核心系统建设中对外反复强调的企业级开发框架及分布式平台技术服务，分离非业务逻辑功能并在平台层统一实现和供给；然后通过分布式平台统一对多技术栈技术能力进行适配与封装，解决平台技术服务和底层技术栈升级、替换对上层应用的影响，保证应用专注业务逻辑开发以及开发效率和质量。

• 并行验证，为了检验系统的准确性，建行提出 “三真实、四比对、五验证”的核心系统异构并行比对方法。【“三真实”：使用真实的生产数据、生产交易、生产环境基础实施准实时运行。“四比对”：比对主机和分布式系统的联机交易输出报文、批量文件结果文件、每日数据库增量返回、交易产生的会计分录等。“五验证”：验证目标架构下的分布式系统的功能完整性、可靠性、稳定性、高可用性及高性能，和招行对外宣传的“动态跟帐”基本类似】

• 信创进展：截至2021年底，对私存款借记卡（分布式）已在青海、宁夏两家分行投产运行，下移2000万账户；信用卡业务全量；个人贷款业务已完成境内业务全量运行在开放分布式平台；客户信息已完成境内外超8亿客户全量运行在开放分布式平台。有了这个基础，后续推广是可以加速的【想象成大集中的逆操作】

   

 

个人的几点感悟

 

• 从公开的信息来看，建行按时完成信创问题好像不大。在细节部分可能还存在一些困难和挑战，比如部门Windows桌面需求【考虑到一部分存量用户U盘需求；强势关联方如税务、海关、大客户等】，过渡期通过一些管理手段是可以搞定的。

• 服务级别的挑战： 对外提供7×24连续不间断服务，在推进分布式架构转型过程中面临诸多问题与挑战：首先是在系统迁移过程中不仅要做到客户无感、对外服务水平不降低，而且还要完整承接现有核心银行业务功能，同步支撑新的业务需求。这些都必须通过大量细致的工作和严格的测试和验证才能保障，所以我们可以看到各种并行验证机制，建行的提法是“三真实、四比对、五验证”，到招行的提法是“动态跟帐”，不管怎么叫，重要性和工作量都不言而喻。

• 整体来说，信创产品功能基本就绪，非功能性方面略差一些，就需要运维体系重构，工具、人员技能更新。随着新技术栈渐次投入生产变成“主”，运维工具、技术技能和经验的积累需要一定的加速度，对现有人员挑战还是非常大的。放眼国内、外，金融企业的集中式运维体系和技能，尚未发现有四大行规模和复杂度的银行运维方案可供借鉴，管理层对服务级别的要求需给技术团队一定的空间。

• 前面提过一句，建行核心系统的基础好，可能重构和流程重组的需求并不高。但是，对其他企业来说，信创横竖要做，这就构成了企业级转型和核心架构重构千载难逢的良机。在企业管理层对科技条线支撑数字化转型的要求日益增高的背景下，信创提供了核心重构非常好的良机，四大行基本都是这么干的，其他企业是可以借鉴的。

• 说到这，多说一句，建行的实践对外借鉴的意义技术上其实不大，毕竟大家的资源和建行完全不在一个量级。四大行资源多，科技能力强，倾向于自建，IT厂商提供人力外包输送；中小行更依赖科技厂商提供IT解决方案，倾向基于标准版本产品进行定制改造。瞄准大行，找寻自己的路径才是正道。