银行新核心建设 10 个难点问题解读
传统IT建设模式已无法适应互联网金融业务发展需求与竞争压力，进行转型势在必行。社区已陆续组织了多场相关主题探讨，以下是一次交流中几位领域内专家的分享，其经验较具有参考性，供同行参考。
1、银行新核心项目采用的建设模式方面， 业界目前主要有咨询+产品+实施和产品+实施两种模式等，应该采用何种模式？
■ 分享一：
目前银行新核心采用的建设模式方面，业界目前主要有咨询+产品+实施和产品+实施两种模式，其适合的情况如下：
① 咨询+产品+实施:
银行自身的 IT 规划能力及建设能力不太强，需要借助外部咨询公司能力重新规划
银行系统通过核心系统的建设，对原有 IT 架构做出重大优化和调整；
② 产品+实施
银行自身有 IT 强大的技术能力；
银行仅更换核心系统，周边接入系统调整不大。
■ 分享二：
个人认为应该采用带有咨询的模式，原因有以下几点：
首先，就银行核心系统项目建设本身来讲，这个不单单是一个应用系统建设的问题，更多的是对业务的梳理和优化以及业务和技术的结合问题。银行本身对自己的业务把握可能比较清晰，但是对未来发展的模式以及行外各种因素的理解和把握可能无法与专业的咨询公司来相提并论。只有通过专业的理念、专业的服务、专业的优化把前期的业务分析做透彻了，才能很好指导后期的系统开发与建设工作。
其次，核心系统项目建设是一个复杂的系统工程，它的推进牵涉到银行很多部门很多组织，这里面难免会有利益的冲突和工作的协调配合， 银行自己是很难解决这样的问题。 只有通过第三方专业的视角和可观的角度才能协调和解决这样的问题，从而推进核心项目的建设。
■ 分享三：
我行倾向于第一种，对于一个现有业务成熟的银行来说新核心系统建设难点在于业务流程再造，需要知己知彼，既要对标同业又要符合本行实际业务发展情况，往往通过借助咨询公司来完成。
2、新核心建设选型，如重构旧核心升级、采购新核心替换、重构旧核心+采购新核心配套实施，具体现状、原则和理由？
■ 分享一：
更换核心系统的理由：
1 旧系统厂商退出市场(硬件，软件)。
2 系统技术非市场主流，与主流技术对接产生障碍。
3 旧系统开发、维护人才逐渐凋零，借着新系统的开发培养下一代的接班技术人才。
4 旧系统的应用系统时间久了打满补丁，新的需求开发费时费力。
5 每一代的银行面对的社会经济活动不同，对系统的架构与应用要求产生结构性的影响，必须以破坏、重建的思维从根本解决。
6 核心系统经营管理模式随着科技与应用的改变，产生多样的核心系统经营方式可供银行依据自身条件(规模，人力，成本，效益)选择(自建，购买，托管)。
7 业务规模(业务量，经营范围)扩大，旧系统无法应对。
8 因为银行的合并，现存的任何一个核心系统无法对应不同文化的银行多样应用系统整合的需求。
9 因为希望合并迅速整合完成，急急忙忙的系统整合，导致旧系统降低服务水平，缩短原系统寿命。
10 核心系统生命周期，因为科技与社会经济活动改变，而逐渐缩短(30-20-10 年)。
11 旧核心系统与新核心系统在整体系统的角色定位改变。
12 旧核心系统成本贡献比逐渐升高，特别是主机型系统用户。
困难重重的原因：
1 大部分的银行高层都了解核心系统有其生命周期，时间到了就应该投资重建，一延再延的原因是找不到足以放心的资源做这件事。
2 少部分的银行领导的确有认为系统与经营效益没有直接的关系。
3 银行规模普遍小，换核心系统投资金额大，不符合规模经济效益。
4 近年来大部分银行盈利下滑，无力投资。
5 负责核心系统主管抱持多一事不如少一事心态，根本不想要动核心系统。
6 IT 主管对新核心系统要求的技术与应用需求没有明确的构想。
7 由于市场规模较小，无法形成产业知识交流平台(政府要负很大责任)，缺乏 CIO 养成环境。
8 原核心系统维护厂商，对于新核心系统提不出吸引人的方案。
9 有些 IT 厂商己经淡出核心系统市场，反而游说客户换核心系统的风险。
10 提供主机(mainframe)型核心系统的 IT 厂商，甚至为了维护其主机系统的高利润，提案的方向偏向系统延续改造的保守方案，而非破坏、重建建设性方案。
■ 分享二：
采购新核心系统意味着上线成本，实施周期和风险被无限放大，当前互联网金融业务的发展是以月为单位计算的，开发新核心周期至少 5 年，除非彻底无法支撑业务发展，否则都会以现有核心系统升级作为首选方案， 这也是浦发， 光大近期核心系统升级实践的结论。
3、银行新核心建设中存在哪些具体的风险和问题以及针对这些风险和问题的具体应对方案和措施？
■ 分享一：
核心系统建设过程中有几个需要决策的问题：
- 互联网应用系统群是不是要建立独立的互联网核心？这个需要根据行内互联网业务发展的模式和未来的定位来决策。
- 核心系统和总账的关系？也就是所谓的胖核心和瘦核心的决策， 如果总账不分离， 那么会将夜间批量和第二天的正常营业紧耦关联，灵活性极差，包括月度结算和年结的灵活性。如果将总账分离，那么就好充分考虑好总账和核心之间的关系，做好衔接。
- 核心系统项目的基础架构规划？核心系统不同于其他渠道类系统，其负载和业务复杂性会给基础平台带来很大的挑战性，尤其是批量和联机共存的模式，从网络上、计算上、IO 上等等各个方面需要有一个综合的稳健性和性能的评估。
■ 分享二：
银行新核心系统建设是一个巨大的系统工程，不仅仅是一个核心系统的建设，往往通过核心系统的更新，带动周边各业务系统的升级和优化，是个巨大的项目群工程。主要有以下风险：
① 领导力不足。 由于核心系统项目群建设工程巨大， 协调各部门及内外部资源众多，需要具有强有力的领导小组指挥和推动。因此，银行对于核心系统的建设往往是一把手工程，由行长或者 CIO 亲自挂帅总指挥，推动项目进度。
② 周期过长。核心系统项目群建设是个系统工程，涉及的全行各个业务，同时各个系统也都需要更新对接新的核心系统。因此从产品选型招标、IT 架构规划规划、方案设计、需求评审、 组织开发、 测试评估、 试运行、 正式上线、 上线运维等等， 各个环节， 环环相扣，都有很大工作量，消耗人力、物力等资源，很容易延期上线。银行核心系统建设周期往往少则 1 年，多则两三年。
③ 项目经理经验和能力不足。 项目经理是核心系统建设项目的灵魂人物 （包括甲乙双方的项目经理） ， 由于核心系统建设的艰巨性和重要性， 务必选择最合适的人担任项目经理，推进项目有序、可控、健康建设。
④ 耽误银行其他业务的发展。银行新核心系统的建设，鉴于其重要性，往往是头号工程，集合了全行最优势的人力资源， 信息科技部门的各项资源也重点倾斜向核心系统项目。因此，对于其他项目的关注度和支持力度势必有所下降， 尤其是目前市场日新月异的创新产品推出，快鱼吃慢鱼的时代，一旦落后，则后期很难再追赶了。
■ 分享三：
目前我行遇到的主要问题是， 新技术例如互联网架构常用的 redis 等开源产品的与核心应用和业务场景的兼容性， 主要还是通过技术预研提高自主可控能力， 通过非功能测试发现潜在问题去避免。
4、银行新核心架构应该如何选择？分布式与集中式？如何评估？
■ 分享一：
随着人行账户体系的分类出现，目前传统银行出现了两类核心系统：一是传统的一类帐户的核心系统； 二是针对二三类帐户的互联网化核心系统。 目前传统的核心系统主要采用集中式， 互联网类核心采用的是分布式核心。 集中式核心系统对数据的强一致性要求较高，互联网化核心则更有高并发能力。
■ 分享二：
传统的核心应用是以稳定为首要目标， 但是在快速满足业务扩展方面有着一些不足，针对于互联网金融的冲击，也就诞生了“双模 IT”的理念，落到核心上，我们有三种解决方案：
第一是双核心，也就是维持原有核心不变，新建一套互联网核心，一稳一快，来满足银行的业务发展需求。 双核心解决方案也是互联网金融下讨论最多的核心改造方案。 当然一个银行在选择基础架构的时候，哪种核心架构，对于后续 it 支撑的要求是不一样的。如果选择双核心的架构，还需要根据银行的业务特点，划分新老核心的业务边界，面临一二三类账户切分的问题，只有业务层面的东西梳理清楚了，IT 架构才能更好地为业务服务。
第二种解决方案是维持原有单核心的架构， 但是需要对核心进行一些改造， 使之能够满足业务快速发展的需求。
第三种解决方案是无核心，从业务架构看，核心功能扩散到整体基础架构，整体架构提供服务的整合，核心架构将作为整体架构的输入，这种架构业内也有银行在探讨。
5、核心系统建设一般是一个项目群方式进行实施，项目管理是实施的有效保障，但由于项目相关方的复杂性，如何通过项目管理来更好的管控？
■ 分享一：
项目管理是个复杂的系统性科学，也是一门管理学，可以去学习 PMP 或者项目管理的教材。每一个项目，项目的每一个阶段都有不同的管控手段和方法。
■ 分享二：
核心系统升级项目管理主要是开发中心牵头其他部门配合，制定时间节点，按周进行项目协调会，重要节点进行行长协调会，由上到下层层落实推动
6、现在的新核心系统能够具备便于产品快速发布和灵活的产品管理，一般采取参数平台和产品工厂方式实现，那此 2 个系统与核心系统的关系如何？相互的交互机制如何？参数平台和产品工厂需要怎么样的功能？
■ 分享：
目前使用的参数平台，依附于核心系统中。由业务人员通过前端系统及流程系统录入审批后进行参数生效或产品发布，对应业务模块为理财类业务。产品工厂类似，但主要应用于对公贷款类业务。两种技术都为初步探索中。
7、银行核心系统如何微服务化，以及微服务核心的建设的标准
■ 分享一：
银行核心系统微服务的必要性在哪里？核心系统微服务的可行性在哪里？本人认为银行的核心系统没有微服务话的必要性和可行性，微服务最适合的场合是互联网业务，为了满足互联网业务的快速性才有必要去微服务，因为互联网业务的复杂性在于规模，不在于业务交易本身，这是它能微服务话的可行性前提。银行的传统核心业务系统群不具备这两点，所以没有必要为了微服务而微服务。
■ 分享二：
目前核心架构实现微服务需要进行分库分表，改动较大，仅列为技术预研。
■ 分享三：
微服务的最大好处在于体系架构的灵活性，“安全”是银行作为区别于互联网企业的重要特点，因此我们在考虑银行核心架构的时候，要以安全稳定为前提，再去满足架构的灵活性。
另外，还需要考虑的一个重要因素就是数据一致性问题，数据一致性通常有两种方式，一种利用商用数据的能力来保证 SID 一致性要求，这一块相对比较成熟，第二种，不依赖于数据库，把状态的保持提升到应用层面或平层，就是所谓的柔性一致性，保证最终结果的一致性。银行的核心系统，因其数据的强一致性要求，往往我们还是采用商用数据库的方式来保证强一致性，但业务场景中类似于抢红包等就可以采用柔性一致性，混合架构的意义也就在于此。
8、银行核心的通讯及数据标准化问题
■ 分享：
统一的 sop 报文标准，通讯采用 tuxedo 中间键。
9、银行核心系统的交易监控及统计分析经验
■ 分享：
交易码级实时监控， 主要通过 BPC 大数据监控平台抓取核心系统所有交易报文进行分析，对比交易基线生成监控告警信息。
10、银行核心系统容灾架构及智能化自愈
■ 分享一：
传统银行的核心架构一般都是两地三中心的模式，即同城两个数据中心，异地一个数据中心，保证核心系统的高度冗余和业务连续性水平。一般核心系统的设计，同城要求RPO=0,RTO <1 小时。因此，同城往往采用存储级别的数据复制，采用数据同步复制技术。至于存储则无论是 EMC ，HDS，IBM 等存储厂商，都有自己的产品及解决方案。
对于异地数据中心， 其 RTO 也一般达不到 0 的级别。 针对不同规模的银行其采用的方式实现异地数据复制也不一样。有的在存储层面的数据复制，有的在文件系统层面的数据复制，有的在数据库层面的数据复制。不同层面的数据复制其产品、解决方案、实现技术、价格、RPO和 RTO 都存在重大差异。
■ 分享二：
系统容灾架构有很多，其重点解决问题无非是数据复制以及系统切换。
就数据复制来讲，有存储实现的方式也有数据库应用实现的方式，各有利弊，具体来讲在速度、可靠性、难易性能方面都会有所差异。银行的核心系统最高要求还是数据的可靠性，再下来是系统的性能问题。所以从这两点来看，用单一的存储复制方式我觉得不合适。如果用单一的数据库复制方式也似乎不是非常合适， 排除成本的考虑， 最好的方式应该是两者的互补方式。就切换而言，是应用负载引流的切换，由专门的负载均衡以及智能 DNS 解析层来配合实现，这个没有什么太大的争议，就没有必要详细讨论了。
■ 分享三：
核心系统主要实现负载均衡，读写分离架构实现系统容灾。智能自愈主要是全行统一的运维自动化平台实现。
■ 分享四：
银行核心数据库部署模式可采用 2+1 或 1+1，即生产中心 2 台低配或 1 台高配LinuxONE 作为生产机，同城灾备中心一台生产机。
以下专家参与了分享：杨平、赵海、胥骞、聂奎甲、汪莉
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”