谈谈银行核心系统建设--篇1：核心系统的哲学三问
文章来源：e路向上，文章仅供个人学习
在初步讨论过“产品工厂”、“费用工厂”、“会计引擎”、“内部户”、“机构管理”等内容后（分别见本号相关文章：《建设全行级产品工厂：梦想能否照进现实？》、《因需而变–银行收费管理系统的集中与自治》，《会计引擎：交易与核算分离的前世今生”》，《浅谈银行内部户治理》，《小命题的大乾坤：IT视角下的银行机构设置》，可以尝试谈谈银行核心系统的建设了，后续将以几篇的内容，分别探讨核心系统的发展历程、在全行系统中的定位、核心系统建设中的需求定义、核心系统的服务拆分、核心系统建设的项目组织等等问题。相关思考来自笔者先后几次分别参与主机核心、开放式核心、分布式核心系统建设的折腾经历……
核心系统的起源
很多人或许会有一个疑问，与手机银行、支付系统、信贷系统、资金系统、票据系统等可以望文生义，一看便知是服务于哪一类业务的系统相比，核心系统好像看不出是服务于哪一类业务的。难道是因为银行有一类业务特别举足轻重，具有“核心”地位？如果是这样，那虽不是核心，但重要性不言而喻的手机银行、支付、信贷、资金等系统，难道还不够“核心”？事实上，原因在于核心系统并非如其他系统一样，是以其承载的业务功能进行命名，而是一种承继历史沿革的默认俗成的称呼。
核心系统的出处，并无特别可考的来源，大概率与“Centralized Online Real-time Exchange System”（集中式在线实时交互系统）–简称CORE有关。上世纪60年代，IBM推出CICS（Customer Information Control System，至今如有使用大型机处理业务的银行，开发人员应对CICS仍不陌生），为集中式实时交互提供了技术基础。银行业基于该技术基础而建设的，能够集中处理交易、实时更新数据并支持多终端接入的系统，即被称为“Core-banking System”–翻译过来，便是核心系统。其特点包括：1）、集中式架构。所有业务逻辑、数据存储和计算资源集中在中央服务器（如大型机），分支机构通过终端（哑终端）接入（通讯协议为SNA）；2）、实时交互。用户操作（如存款、转账）通过终端（绿油油的Pcomm应该还有人在使用）提交后，中央服务器立即处理并返回结果，实现“请求-响应”的实时闭环；3）、*高可靠性与强一致性。系统的事务管理严格执行ACID原则，确保每笔交易的原子性、一致性和持久性。在21世纪头十年之前，国内银行提供服务的手段相对单一，不同业务领域尚没有如今这样专业化、精细化、数字化管理需要，存、贷、汇、兑、客户管理、额度管理、票据交换等等所有业务都运行一个CORE系统中，Core-banking System基本上等同于全行重要业务系统，核心系统的重要地位推测由此形成。但从其起源可知，核心系统既不代表所承载的业务类型，也不并不如大多数人可能误以为的那样–代表其所处的地位。*
核心系统的发展
核心系统在国内的发展，跟技术浪潮的演进、国家产业政策、社会经济的发展水平都息息相关，大的时间线上，大致可分为如下几个阶段：
前核心系统时代（上世纪90年代末之前）。前核心系统时代，经历了3个时期，分别是上世纪80年代之前，完全以手工方式办理业务的阶段，柜面通过手工编制传票/凭证，登记账簿；80年代PC电脑出现后，部分银行开始引入PC机辅助手工操作，主要是将柜面的操作，部分以PC机来代替，推动了会计电算化的发展；之后，随着互联网在我国的发展（我国到1994年才全面接入国际互联网），部分银行开始探索区域内网点机构间的数据互联互通，支持区域内的通存通兑。其中特别值得一提的是，1993年，国务院启动，由中国人民银行牵头实施的金卡工程，推动我国金融领域IC卡、POS机、ATM机快速普及，金融电子化发展进入快车道。1997年中国银联的前身–全国银行卡信息交换总中心建成，为当今全球领先的数字支付生态奠定了基础。这一个时期，计算机技术被部分地运用于银行业务中，现在我们所称的一般意义上的核心系统还未出现。
***大集中时代（上世纪90年代末到2008年前后）*。上世纪90年代末，以工行NOVA系统建设为标志，国内商业银行掀起了一波大集中建设的高潮，其核心内容是将全行业务上收总行进行集中处理，在总行建立统一的数据中心，实现交易处理和数据管理的集中、统一，并在此基础上，统一全行的头寸管理与资金调度、定义统一的作业流程。这一阶段，大集中的关键便是核心系统的建设，此时的核心系统主要有如下特点：1）、承载全行关键业务。存款、贷款、内部户、收费、定价、汇票、本票、票据交换、额度管理、国际业务、支付等，全部通过核心系统承载；2）、核心系统的基础设施基本全部由IBM提供，系统运行在IBM390大型机或AS/400等机器上，操作系统是IBM的OS390或OS400，数据存储用的是DB2或VSAM文件；3）、编程语言使用COBOL、RPG、JCL等；4）、系统完全满足ACID原则，由事务管理器保障高可靠性和强一致性，完全没有柔性状态的说法。这一波建设过程锻炼出来的业务、技术骨干，现在应该很多都在不同银行的重要领导岗位上。：）
***瘦核心时代（2007年前后到2017年前后）*。这一时期，随着互联网信息技术和银行业务的快速发展，网上银行、数据仓库等开始出现，国际结算、支付、票据、信贷审批（包括个人和企业）等系统，开始逐步从核心剥离，以更好地适配业务更复杂发展需要。这一过程的最终结果是，核心系统的功能逐渐收缩为以支持以下功能为主的系统：1）、账户类功能。如活期账号、定期账户、保证金账户、内部户、存放同业账户等；2）、与账户功能实现紧密关联，又具备一定全局性作用的功能。如产品工厂（实际上以支持基础存贷产品为主）、费用工厂（管理账户类、卡、ATM、支付类收费）、定价中心（利率、汇率管理）、机构管理（主要是核算机构）、客户信息管理（要开账户首先要建立客户信息）；3）、账务处理。主要是会计引擎。另外，部分银行会将与账务处理关联比较强的现金管理也放在核心系统。这些功能也成为延续至今，我们在讨论核心系统建设时通常需要涵盖的业务范围。这一阶段，随着JAVA技术生态的发展，核心系统逐步脱离IBM大型机，开始基于JAVA技术生态进行建设。对应的，运行的底层硬件由390、AS400等大小型机，开始替换为IBM P系列服务器；数据库开始普遍采用Oracle，存储大量使用EMC的存储设备，此即IOE的由来。这期间，完成了从大型机下迁的核心，因为主要使用开放的JAVA技术生态，又被称为开放式核心。
****分布式核心时代（2017年前后至今）。**分布式核心有两类建设模式，一类是*全局分布式架构建设模式*，以个别头部互联网银行为代表（很少），此类银行没有技术负债，自成立之初即采用彻底的分布式设计原则，其技术特征可概括为以下三方面：1）、*架构全域**覆盖。所有业务系统（包括传统意义上的“核心系统”）均基于分布式理念构建，通过**微服务化拆分**（如存款、贷款、支付等模块细粒度解耦）、**数据分片策略**（如按客户ID哈希分布）及**多活部署**（单元化架构）实现弹性扩展与高可用。2）、**技术栈深度适配。配套技术栈完全围绕分布式需求定制，包括：原生分布式数据库（如OceanBase、TdSql）替代集中式数据库；服务网格（如Istio）与分布式事务框架（如Seata）保障跨服务一致性；云原生工具链（Kubernetes+Prometheus）实现自动化运维。3）、**核心系统概念重构。传统集中式核心系统被彻底解构——存款、贷款、支付清算等基础功能被拆分为独立服务（实践中进一步细化为子服务），通过API协同形成“虚拟核心”。因此，**“核心系统”已不再是一个物理集中的单体模块，而是由分布式组件动态组成的逻辑抽象层，实际上已经没有所谓“核心”了。另一类是部分银行在进行核心系统替换时，对原垂直架构下的核心，采用分布式架构进行重构，过程中同步进行私有云建设，从硬件（使用X86服务集群）、数据（引入分布式数据库–OB、TD等）、应用（微服务化重构，基于Spring Cloud实现服务治理）三层完成核心系统的去IOE化，这一类银行因为技术历史负债的关系，无法如互联网银行一步到位地进行全局分布式建设，因此在建设分布式核心时，哪些功能可以迁移到外围，哪些功能需要重构，微服务定义的颗粒度变得非常重要。因为信创的需要，目前这一架构模式的核心系统正迎来一波建设高潮，在银行新一代核心系统建设项目中，被普遍采用。*******
****核心系统在全局架构中的定位****
**
要谈核心系统在银行全局应用架构中的定位，就需要对核心系统进行准确的定义。这里我们采用目前业内最普遍存在的“瘦核心”的功能范围，将核心系统定义为：核心系统是指承接并提供三大类基础能力–即“基础服务中枢（产品管理、费用管理、机构管理、定价管理）”、”账户服务（活期账户、定期账户、内部户、保证金账户、存放同业账户）”及“会计账处理（会计引擎）”的一揽子服务的系统集合。
银行系统的全局应用架构，可以在基于银行”前中后台”业务特点的基础上，结合技术形态分布，从逻辑上简单地分为五层：
一是服务界面层。即对客服务入口。电子渠道、网点柜面、自助机具、电话银行、银企直连、开放银行都位于这一层。这一层在交互设计上，强调操作的友好性：简单、易懂、准确。在技术实现上，则强调服务可复用、服务组装的灵活性等等。
二是业务产品层。即主要由银行中台部门–零售信贷、财富管理、公司银行、贸易金融、国结业务、普惠金融等进行产品创新所依托的平台。贸易融资、中间业务平台、代收付平台、现金管理平台等，大部分都处于这一层。这一层开始与核心系统的部分功能发生关系，创新类负债产品–如法人账户透支、智能存款、伞形账户、存证账户等，有些由核心系统实现、有些要依赖核心系统的服务。
三是风险控制层。主要面向风险类业务的风险审批控制–各类评级、授信批复、出账审批，即与“贷前调查、贷中审查、贷后检查”相关的内容。这一层主要面向资产类业务，与负债业务、中间业务关系不大。
四是账务作业层。即涉及到银行账务记账处理的服务，落在这一层，这也是核心系统发挥基础枢纽性作用所在。客户在商业银行的服务，绝大部分都与资金相关，与资金相关就涉及动账–有些是动客户自己的账（结算户），有些是以内部户方式登记的账（内部户），有些是涉及到机构往来间清算的账（存放同业账户），由此导致核心系统的服务可用性要求变得极高，一旦核心出问题，便会引起全行性生产事故。
五是数据服务层。从贴源数据、到数仓、到数据集市，及之后各种数据计量、智能决策分析、报表报送类的各种系统。这一部分涉及监管报送、财务计量类的系统，也与核心关系密切，因为核心系统承载了全行绝大部分的分户账，并收口了总账，而报送类的数据来源，一大部分是基于会计账及明细账，并以此为基准进行扩展填充的，因此，核心的各类数据，才是“伏脉千里”的那条“脉”。
总结一下，核心系统在全行业务系统的逻辑架构分层中，核心系统有3个关键角色：1）、核心系统是结算类产品创新的核心抓手；2）、核心系统提供的账户服务是银行关键涉账系统有效运行的关键依赖；3）、核心系统为计量及报送类数据服务提供主要数据来源。因此，核心系统在全行应用系统定位中，确实扮演着“核心”的角色。
但这并不意味着核心系统的业务复杂度、业务重要性高于其他系统。从业务复杂度上看，核心系统提供的服务较信贷、国结、资金、票据等专业类系统低不少；从业务关注度上看，信贷、供应链金融、国结、资金、票据、理财等能直接创造利润的系统，更受前台、中台业务部门关注；从运行稳定性和可用性保障上看，核心系统也并不比手机银行、网银、支付类系统更重要，或他们都应属于极其重要的同一等级。
核心系统很重要，很关键，但没有必要图藤化，随着服务拆分，微服务架构的发展，核心的概念有越来越淡化的趋势。
写在后面
本篇没有实操性的内容，为什么还要探讨，主要几个方面的考虑：其一，搞清楚一个事物”是什么”，才有利于在真正启动核心系统建设的时候，确保人数众多的项目组成员形成共识，在同一语境下进行协同，这也是很多专业领域通常都会有一堆术语，一个大项目的需求书中，术语定义一般都写在前面的原因；其二，了解清楚一个事物“从哪里来”，即了解事物的发展历程，也更有利于理解事物发展的历史沿革，这样才不会陷入理想主义者的陷阱，在项目因种种原因需要进行妥协、折中的时候，敢于取舍，能够快速进行决策；其三，搞清楚一个事物“往哪里去”，即了解事物的发展趋势，对组织而言，在进行新核心建设的时候，一方面能够选择符合未来发展趋势的架构模式，另一方面，能够在新核心建设时，通过做好全局IT治理的顶层设计。于个人而言，则可以据此规划自己的职业发展路径，不断迭代自己的技术能力，避免空有一身屠龙之技，被时代的大浪拍死在沙滩上的尴尬…