CN111427608B - 用于银行核心系统的灰度发布方法 - Google Patents

Abstract

本发明涉及数据切换技术领域，具体公开了用于银行核心系统的灰度发布方法，包括如下步骤：S101、在主数据库建立新的主用户B；在备数据库建立新的备用户B，并赋予主用户B共享主用户A资源的权限，备用户B共享备用户A资源的权限；S102、对主用户B和备用户B进行网络访问授权，并对网络接出接入部分进行改造；S201、应用层面：在主数据中心的应用集群中建立双活双节点的主应用A和主应用B；在备数据中心应用集群中建立双活双节点的备应用A和备应用B；使主数据中心和备数据中心互为热备；S202、数据库层面：通过Oracle RAC机制实现主数据库和备数据库的集群部署。采用本发明的技术方案能在升级时不暂停核心服务。

Description

用于银行核心系统的灰度发布方法

技术领域

本发明涉及数据切换技术领域，特别涉及用于银行核心系统的灰度发布方法。

背景技术

银行的核心系统技术平台依赖于数据库端存储过程实现业务逻辑，在进行版本升级过程中为避免数据库失效对象产生的服务调用报错，在部署过程中需要暂停核心服务，数据库版本部署完成且编译后，启动核心服务。

核心系统技术平台升级部署过程的完成时间较长，且期间核心系统无法正常提供服务，在一定程度上影响核心系统服务能力以及服务时间。

为此，需要一种升级时不暂停核心服务的方法。

发明内容

本发明提供了用于银行核心系统的灰度发布方法，能在升级时不暂停核心服务。

为了解决上述技术问题，本申请提供如下技术方案：

用于银行核心系统的灰度发布方法，包括如下步骤：

S101、主数据库包括主用户A，备数据库包括备用户A；在主数据库建立新的主用户B；在备数据库建立新的备用户B，并赋予主用户B共享主用户A资源的权限，备用户B共享备用户A资源的权限；

S102、对主用户B和备用户B进行网络访问授权，并对网络接出接入部分进行改造；

S201、应用层面：在主数据中心的应用集群中建立双活双节点的主应用A和主应用B；在备数据中心应用集群中建立双活双节点的备应用A和备应用B；使主数据中心和备数据中心互为热备；

S202、数据库层面：通过Oracle RAC机制实现主数据库和备数据库的集群部署；网点基于访问流量策略访问主数据中心和备数据中心；通过DNS访问策略，将银行核心系统间的访问流量控制在主数据中心和备数据中心内部；依托ADG技术，建立Oracle数据库的跨主数据中心和备数据中心的主从架构。

基础方案原理及有益效果如下：

本方案中，进行数据库双用户改造，整体架构采用双中心集群+数据库双用户的方式，从应用层面和数据库层面两个层面增强了高可用。

在双用户模式下，能够有效避免单用户部署过程中存储过程包失效，或连接失效等系统性问题；可以将业务逻辑和数据进行分离。例如，可以在修改主应用A、备应用A用户业务逻辑的情况下，将业务流量迁移至主应用B、备应用B上，不会影响主应用A、备应用A用户业务逻辑的处理，当主应用A、备应用A用户升级部署完毕业务启动成功后将业务流量迁移至主应用A、备应用A用户上来再进行主应用B、备应用B用户的升级部署工作，备数据库用户同理并且主应用A、备应用A是同时进行，主应用B、备应用B是同时进行，从而保证不中断业务处理，降低系统升级的影响范围。本方案能够进一步增强系统容灾性，使新老版本业务功能并行运行，实现变更功能的平滑过渡。

综上，应用双中心集群+数据库双用户的方式能够使核心系统具有灰度发布能力，进而做到版本升级维护不停机，业务不中断，进一步增强了核心系统的服务能力，增加了核心系统的服务时间。

进一步，所述S102中，改造时，将主用户A的表的触发器调用过程改造为单独的存储过程包，供主用户B调用，将备用户A的表的触发器调用过程改造为单独的存储过程包，供备用户B调用。

改造前因为新用户(主用户B和备用户B)没有原用户(主用户A和备用户A)的表的所有权，含有全局变量的触发器新用户无法调用，通过改造，能便于新用户快速调用。

进一步，所述S201中，热备时，通过应用交互网络实现两个应用节点的横向扩展与负载均衡。

可以达到利用效率的最大化。

进一步，还包括S103、跨用户调用全局变量初始化：通过补丁版本，将触发器中使用的全局变量放到CFQ触发器存储过程包中，每次主用户B和备用户B有交易接入时，初始CFQ触发器存储过程包。

通过初始CFQ触发器存储过程包，能方便主用户B和备用户B接入后调用数据。

进一步，还包括S104、触发器程序单独拆分：修改触发器，使触发器直接调用触发器单独的CFQ触发器存储过程包。

将触发器的过程独立出来，成为单独的存储过程包，能避免在部署主用户A和备用户A的DB版本时，其他存储过程包或者程序的失效影响触发器的执行。

进一步，所述S103中，通过补丁版本部署触发器后，根据不同的数据库用户名的值修改应用系统服务器地址配置表中配置的ip地址为对应的服务器地址。

实现了根据具体业务从哪个应用服务器接入，判断它应该接出到哪个数据库用户下。使各个用户调用各自对应的应用通讯接出，能避免出现异常。

附图说明

图1为实施例一用于银行核心系统的灰度发布系统的逻辑框图；

图2为实施例一用于银行核心系统的灰度发布方法的流程图；

图3为实施例一中银行核心系统版本进行升级时的流程图。

具体实施方式

下面通过具体实施方式进一步详细说明：

实施例一

用于银行核心系统的灰度发布系统,如图1所示，包括主数据中心和备数据中心。

主数据中心包括应用集群和主数据库。

应用集群包括主应用A和主应用B。

本实施例中，主应用A和主应用B均用于报文接收处理、格式转换、与其它系统通讯的接入接出等。

主数据库包括主核心数据库，在其他实施例中，还可以包括其他非核心数据库；主数据库用于系统框架和业务逻辑校验，业务逻辑实现，数据存储等。

主核心数据库包括主用户A和主用户B。一个主数据库下面有很多用户，比如核心用户，支付用户，柜面用户等；本实施例中，主用户A和主用户B都只是主核心数据库下的核心数据库用户。主用户A和主用户B下存放着所有数据以及存储过程代码。

本实施例中，主用户A和主用户B均包括全套的表。

本实施例中，表包括若干触发器，换句话说，某个表跟它的触发器属于一对多的关系，一个表可能有多个触发器。

触发器是与表事件相关的特殊的存储过程，触发器的执行不是由程序调用，也不是手工启动，而是由事件来触发，比如当对一个表进行操作(例如插入insert、删除delete、更新update)时就会激活表的触发器自动执行。

主用户A和主用户B均还包括存储过程包，本实施例中，具体为核心系统存储过程的程序包，分为包头和包体。包头包含了过程和函数的说明，而没有过程和函数的实现代码。包体为用于实现包规范中的过程和函数的具体代码。

备数据中心与主数据中心结构相同，备数据中心包括应用集群和备数据库；

应用集群包括备应用A和备应用B；换句话说，主数据中心和备数据中心的应用集群分别部署了两台应用；主应用A、主应用B、备应用A、备应用B仅为了描述上便于区分。

备数据库包括备核心数据库，在其他实施例中，还可以包括其他非核心数据库；备数据库用于系统框架和业务逻辑校验，业务逻辑实现，数据存储等。

备核心数据库包括备用户A和备用户B。

本实施例中，备用户A和备用户B均包括全套的表；具体的，主用户A和备用户A的表定义了全局变量。备用户A和备用户B均还包括存储过程包。

如图2所示，基于用于银行核心系统的灰度发布系统，本实施例还提供用于银行核心系统的灰度发布方法，包括如下步骤：

S1、数据库双用户改造，具体为：

S101、主数据库包括主用户A，备数据库包括备用户A；在主数据库建立新的主用户B；在备数据库建立新的备用户B，并赋予主用户B共享主用户A资源的权限，备用户B共享备用户A资源的权限；

S102、对主用户B和备用户B进行网络访问授权，并对网络接出接入部分进行改造。本实施例中，具体为将主用户A的表的触发器调用过程改造为单独的存储过程包，供主用户B调用，将备用户A的表的触发器调用过程改造为单独的存储过程包，供备用户B调用。因为新用户(主用户B和备用户B)没有原用户(主用户A和备用户A)的表的所有权，含有全局变量的触发器新用户无法调用，因此需要进行改造。

S2、系统应用双中心集群部署，具体为：

S201、应用层面：

在主数据中心的应用集群中建立双活双节点的主应用A和主应用B；在备数据中心的应用集群中建立双活双节点的备应用A和备应用B；使主数据中心和备数据中心互为热备。

本实施例中，在热备时通过应用交互网络实现两个节点的横向扩展与负载均衡。具体的，应用交互网络采用F5。

两个节点的横向扩展与负载均衡，例如：银行大部分系统一般都是两套互为备份，比如支付，核心，票据等，每个系统都是冷备或者热备，比如X银行在Y地和Z地各有一个机房，每个机房的机器都分别部署了一套核心系统应用，而在单一机房下核心系统的使用中，它会横向扩充多台机器来作为性能或者业务的支持，比如用户量为1000的时候，所有用户都流入到了Y地的机房，一台机器不够就再加一台，由F5来分配业务流量，使得每台机器都在分别处理不同的流量。

名词解释：

1.热备是指与目标设备共同运转，当目标设备发生故障或停机时，热备设备立即承担起故障设备的工作任务；

2.冷备是指当目标设备发生故障或停机后，冷备设备才开始由停机等待状态进入启动运转状态，并承担起故障设备的工作任务；

3.双活是指让同时让主应用A和主应用B，或者备应用A和备应用B承担用户业务，主应用A和主应用B，或者备应用A和备应用B之间互为备份，并且进行实时备份，一般来说主应用A的负载可能会多一些，比如分担60％的业务，主应用B分担40％的业务。

S202、数据库层面：通过Oracle RAC机制实现主数据库和备数据库的集群部署；网点基于访问流量策略访问主数据中心和备数据中心；通过DNS访问策略，将银行核心系统间的访问流量控制在主数据中心和备数据中心内部；依托ADG技术，建立Oracle数据库的跨主数据中心和备数据中心的主从架构。本实施例中，网点指业务流量，也就是所有的银行交易。

本实施例中，主数据中心和备数据中心都通过F5进行主应用A、主应用B、备应用A、和备应用B的负载均衡和业务流量控制。

如图3所示，当对银行核心系统版本进行升级时：

通过F5迁移主应用A和备应用A的访问流量至主应用B和备应用B；

在主应用A和备应用A无流量进入时，停止主应用A和备应用A的原应用节点服务；

备份主应用A和备应用A的原应用节点服务；

部署主应用A和备应用A的新应用节点服务；本实施中，部署新应用节点服务具体为部署新应用版本及数据库版本；

重启主应用A和备应用A的新应用节点服务；

通过F5控制访问流量只接入主应用A和备应用A的新应用节点服务；

停止主应用B和备应用B的原应用节点服务；

部署主应用B和备应用B的新应用节点服务；

重启主应用B和备应用B的新应用服务，通过F5恢复主应用B和备应用B的访问流量。

这样即可做到银行核心系统不停机灰度发布版本。

实施例二

本实施例和实施例一的区别在于，本实施例的S1、数据库双用户改造中，还包括：

S103、跨用户调用全局变量初始化：通过补丁版本，将触发器中使用的全局变量放到CFQ触发器存储过程包中，每次主用户B和备用户B有交易接入时，初始CFQ触发器存储过程包，以及其他过程需要的全局变量。

S104、触发器程序单独拆分：修改触发器，使触发器直接调用触发器单独的CFQ触发器存储过程包，不再调用其他存储过程包。本实施例中，将触发器的过程独立出来，成为单独的存储过程包，能避免在部署主用户A和备用户A的DB版本时，其他存储过程包或者程序的失效影响触发器的执行(例如部署主用户A和备用户A时，主用户B和备用户B正在跑交易)。

名词解释：

DB版本：所有的系统程序代码都是在不断的修改更新迭代，比如维护人员发现核心系统某个交易执行报错有BUG的时候，就会去修改代码，然后部署上线从而解决这个问题，修改的这部分代码对于使用存储过程作为编程语言的系统版本来说就是DB版本。

实施例三

本实施例和实施例二的区别在于，本实施例在S103中，通过补丁版本部署触发器后，根据不同的数据库用户名(本实施例中指应用系统名称字段，具体为SCHEAM_NAME字段)的值修改应用系统服务器地址配置表(本实施例中具体指SOCKET CONFIG表)中配置的ip地址为对应的服务器地址。

例如，目前主用户B和备用户B的应用正在部署DB版本(处于停止服务状态)，所有的业务会流入主用户A或备用户A(这个是由F5流量负载均衡控制的)，从主用户A或备用户A接入的流量必须保证它所访问的数据库用户是数据库用户A；相应的，从主用户B或备用户B接入的流量必须保证它所访问的数据库用户是数据库用户B。实现了根据具体业务从哪个应用服务器接入，判断它应该接出到哪个数据库用户下。能实现各个用户调用各自对应的应用通讯接出，能避免出现异常。

实施例三

本实施例与实施例一的区别在于，本实施例中，对银行核心系统版本进行升级时，还包括建立虚拟应用X，通过F5迁移主应用A和备应用A的访问流量至主应用B和备应用B时，还判断访问流量是否大于阈值，如果大于阈值，F5迁移主应用A和备应用A的访问流量至虚拟应用X；虚拟应用X用于将主应用A和备应用A的访问流量转跳至主应用B和备应用B。

通过F5控制访问流量只接入主应用A和备应用A的新应用节点服务时，还判断访问流量是否大于阈值，如果大于阈值，F5迁移主应用A和备应用A的访问流量至虚拟应用X；访问流量进虚拟应用X后再转跳至主应用A和备应用A。

当对银行核心系统版本进行升级时，如果遇到访问流量过大的情况，容易导致主应用A和备应用A，或主应用B和备应用B无法承载的情况，通过建立虚拟应用X，让访问流量先经过虚拟应用X，能减轻主应用A和备应用A，或主应用B和备应用B的访问压力；而且，增加了新访问流量的整个访问时间，给了主应用A和备应用A，或主应用B和备应用B更多时间消化之前的旧访问流量。本实施例中，不必对主应用A和备应用A，以及主应用B和备应用B进行改造，调整成本低，而且一个虚拟应用X在主应用A和备应用A，以及主应用B和备应用B都能用，维护成本低。

以上的仅是本发明的实施例，该发明不限于此实施案例涉及的领域，方案中公知的具体结构及特性等常识在此未作过多描述，所属领域普通技术人员知晓申请日或者优先权日之前发明所属技术领域所有的普通技术知识，能够获知该领域中所有的现有技术，并且具有应用该日期之前常规实验手段的能力，所属领域普通技术人员可以在本申请给出的启示下，结合自身能力完善并实施本方案，一些典型的公知结构或者公知方法不应当成为所属领域普通技术人员实施本申请的障碍。应当指出，对于本领域的技术人员来说，在不脱离本发明结构的前提下，还可以作出若干变形和改进，这些也应该视为本发明的保护范围，这些都不会影响本发明实施的效果和专利的实用性。本申请要求的保护范围应当以其权利要求的内容为准，说明书中的具体实施方式等记载可以用于解释权利要求的内容。

Claims (5)

1.用于银行核心系统的灰度发布方法，其特征在于，包括如下步骤：

S101、主数据库包括主用户A，备数据库包括备用户A；在主数据库建立新的主用户B；在备数据库建立新的备用户B，并赋予主用户B 共享主用户A资源的权限，备用户B共享备用户A资源的权限；

S102、对主用户B和备用户B进行网络访问授权，并对网络接出接入部分进行改造；

S201、应用层面：在主数据中心的应用集群中建立双活双节点的主应用A和主应用B；在备数据中心应用集群中建立双活双节点的备应用A和备应用B；使主数据中心和备数据中心互为热备；

S202、数据库层面：通过Oracle RAC机制实现主数据库和备数据库的集群部署；网点基于访问流量策略访问主数据中心和备数据中心；通过DNS访问策略，将银行核心系统间的访问流量控制在主数据中心和备数据中心内部；依托ADG技术，建立Oracle数据库的跨主数据中心和备数据中心的主从架构；

所述S102中，改造时，将主用户A的表的触发器调用过程改造为单独的存储过程包，供主用户B调用，将备用户A的表的触发器调用过程改造为单独的存储过程包，供备用户B调用。

2.根据权利要求1所述的用于银行核心系统的灰度发布方法，其特征在于：所述S201中，热备时，通过应用交互网络实现两个应用节点的横向扩展与负载均衡。

3.根据权利要求2所述的用于银行核心系统的灰度发布方法，其特征在于：还包括S103、跨用户调用全局变量初始化：通过补丁版本，将触发器中使用的全局变量放到CFQ触发器存储过程包中，每次主用户B和备用户B有交易接入时，初始CFQ触发器存储过程包。

4.根据权利要求3所述的用于银行核心系统的灰度发布方法，其特征在于：还包括S104、触发器程序单独拆分：修改触发器，使触发器直接调用触发器单独的CFQ触发器存储过程包。

5.根据权利要求4所述的用于银行核心系统的灰度发布方法，其特征在于：所述S103中，通过补丁版本部署触发器后，根据不同的数据库用户名的值修改应用系统服务器地址配置表中配置的ip地址为对应的服务器地址。

Images