一种互联网银行分布式核心业务系统事务管理方法与流程

1.本发明涉及软件系统开发技术领域，具体而言，涉及一种互联网银行分布式核心业务系统事务管理方法。


背景技术：

2.传统银行核心系统采用单体架构，所有业务场景运行在同一个数据库上，事务采用单数据库事务管理器完成，运行结构简单，但业务实施难度大，架构扩展性差。
3.随着微服务架构的兴起，为巨型单体应用的扩展提供了良好的解决方案。互联网银行的核心系统为应对巨大的互联网流量，多采用分布式架构。核心业务系统负责实现银行的账务记录、登记、核算等功能，核心业务系统的同一个记账类交易需保证事务性，才能确保业务功能的准确实现，才能确保银行账务的准确。对于核心系统而言，这种微服务的多边形分布式架构带来了同一个业务场景可能分布在多个子系统的多个节点上完成，同一个服务需要横跨多个节点的多个资源。
4.传统rdbms xa transactions的方案整个提交阶段耗时长，无法引入超时机制，也无法主动发起查询各参与者的状态，不能满足银行交易系统强一致性，交易时效高的要求。此外，业务活动管理器对于事务控制信息的读写，比较通常的做法是，类似于传统日志记录。该日志记录方案中存在的不足有：写日志易引起磁盘io，耗时高；日志只能单机写，如果写分布式日志，实现方案复杂，代价昂贵。


技术实现要素：

5.本发明的目的在于提供一种互联网银行分布式核心业务系统事务管理方法，用于互联网银行的核心业务系统在分布式环境下保证账务类交易的一致性、原子性、隔离性和持久性。
6.为调度上述技术问题，本发明采用的技术方案是：一种互联网银行分布式核心业务系统事务管理方法，应用于核心基础平台和服务中心上，所述核心基础平台包括核心平台支撑模块和业务活动管理器，所述核心平台支撑模块配置有多个核心业务系统，所述服务中心包括服务发现管理模块和服务注册管理模块，所述方法包括如下步骤：所述核心业务系统基于核心平台支撑模块将服务发布至服务中心，所述服务注册管理模块进行注册服务；服务请求者向所述服务中心发出入口请求服务，根据返回的服务入口信息，调用核心业务系统；所述核心业务系统向服务中心发出服务发现请求，所述服务发现管理模块响应后返回服务发现信息；根据所述服务发现信息生成事务控制信息，并将所述事务控制信息写入redis集群；所述业务活动管理器读写事务控制信息，依次调用各核心业务系统的执行函数，完成事务管理。
7.作为优选方案，所述根据所述服务发现信息生成事务控制信息，包括：所述核心业务系统将服务发现信息传递至业务活动管理器，所述业务活动管理器添加全局流水号、业务类型、子交易类型生成事务控制信息。
8.作为优选方案，所述核心业务系统上配置有一个或多个子交易节点，所述执行函数包括try、query、recovery、confirm和cancel方法，所述事务管理包括发起阶段、确认阶段和回滚阶段；在发起阶段，依次调用各子交易节点的try方法，各核心业务系统接收调用请求后预执行；接收各子交易节点回复，若有子交易节点未在规定的时间内完成回复，则核心业务系统调用相应子交易节点的query方法，进行事务信息查询和事务执行状态查询；若查询失败，则调用recovery方法释放资源，同时调用cancel方法，表示本次交易失败；若所有子交易节点回复成功，所述核心业务系统调用各子交易节点的confirm方法，进入确认阶段；在确认阶段，各子交易节点提交本地事务，回复核心业务系统，若所有子交易节点全部响应成功，则交易流程结束，整个交易成功返回服务请求者；在发起阶段和确认阶段，若有任何服务节点回复状态失败，则所述核心业务系统分别调用子交易节点的cancel方法，交易失败；若子交易节点在规定的时间内没有收到核心业务系统的命令，则进入回滚阶段，自动回滚本地事务。
9.作为优选方案，所述预执行包括：完成所有业务检查和预留业务资源，实现一致性保证和隔离性保证。
10.作为优选方案，所述服务发现信息的数据结构为：{servicename：a，part：{0：{function:{ip:ipvalue,port:portvalue,protocol:http/rpc}}}}；其中，servicename为业务服务名称，part结构表示子交易组成，数字序号0,1表示子交易调用顺序，根据数字序号依次从小到大调用对应子交易，如果数字序号相同，表明子交易可以并发调用，function结构表示具体的子交易系统，包括ip、端口port和协议protocol信息。
11.作为优选方案，所述事务控制信息的数据结构为：{systemnodeid:globaltraceno-》{{type:globaltraceno-》type},{model:globaltraceno-》model},{time:globaltraceno-》time}，systemnodeid:businesstype:biztype-》[{current:0,list＝0,1,2}]}；其中，systemnodeid是各个核心业务系统的节点编号，globaltraceno是全局流水号，type是实体对象的交易类型，model是交易对象，time是最后一次的操作执行操作的时间戳，业务子列表为list结构中businesstype为业务类型，biztype为子类型，即对应服务发现中function描述的信息。
[0012]
作为优选方案，所述业务活动管理器读写事务控制信息，包括：使用全局流水号、交易类型和交易对象实例化出trans对象；核心业务系统调度trans对象的运行；trans对象根据state对象，依次调用tcctask的阶段性任务；tccservice根据trans对象的状态，可以增加或者定制化保存当前工作的上下文信息。
[0013]
与现有技术相比，本发明的有益效果包括：在事务控制信息的数据结构中设置全局唯一流水号，依据该流水号，所有参与者报告状态后才进行业务状态的变更和流转，使得在调用redis时不存在部分成功的情况，保证了事务的强一致性。同时在服务的发起阶段、确认阶段和提交阶段的api中都有超时的设置，对于超时场景，核心业务系统会主动发起事务状态查询，满足银行交易系统强一致性，交易时效高的要求。本方案采用redis来存储，相较于传统的磁盘写入，redis写入性能更高，速度更快，从而提高交易时效。在宕机情况下，业务管理器也可以快速恢复执行，在健壮性和容错性方面，redis记录状态的方案明显强于日志系统。本发明提出了一种根据银行核心系统具体的业务场景设计出的分布式事务管理方案，该分布式核心的事务管理框架和功能，交易时效性高，又能保证事务的强一致性。
附图说明
[0014]
参照附图来说明本发明的公开内容。应当了解，附图仅仅用于说明目的，而并非意在对本发明的保护范围构成限制。在附图中，相同的附图标记用于指代相同的部件。其中：
[0015]
图1为本发明实施例核心基础平台和服务中心的结构示意图；
[0016]
图2为本发明实施例互联网银行分布式核心业务系统事务管理方法的流程示意图；
[0017]
图3为本发明实施例事务管理的流程示意图；
[0018]
图4为本发明实施例状态流转示意图；
[0019]
图5为本发明实施例事务控制信息读写接口示意图。
具体实施方式
[0020]
容易理解，根据本发明的技术方案，在不变更本发明实质精神下，本领域的一般技术人员可以提出可相互替换的多种结构方式以及实现方式。因此，以下具体实施方式以及附图仅是对本发明的技术方案的示例性说明，而不应当视为本发明的全部或者视为对本发明技术方案的限定或限制。
[0021]
根据本发明的一实施方式结合图1示出。一种互联网银行分布式核心业务系统事务管理方法，应用于核心基础平台和服务中心上，核心基础平台包括核心平台支撑模块和业务活动管理器，核心平台支撑模块配置有多个核心业务系统，服务中心对外提供具体的服务查询功能，查询某个交易具体的功能组合，其包括服务发现管理模块和服务注册管理模块。
[0022]
参见图2，上述方法包括如下步骤：
[0023]
s101，核心业务系统基于核心平台支撑模块将服务发布至服务中心，服务注册管理模块进行注册服务。
[0024]
s102，服务请求者向服务中心发出入口请求服务，根据返回的服务入口信息，调用核心业务系统。服务请求者即具体的交易请求者。
[0025]
s103，核心业务系统向服务中心发出服务发现请求，服务发现管理模块响应后返回服务发现信息。
[0026]
调用某个具体的核心业务系统时，核心业务调用服务中心查询出该业务交易由哪些子交易功能组成，同时查询出这些服务由集群中的哪些机器节点提供，查询结果支持本地缓存。
[0027]
具体的，服务发现信息的数据结构为：
[0028]
{servicename：a，part：{0：{function:{ip:ipvalue,port:portvalue,protocol:http/rpc}}}}；其中，servicename为业务服务名称，part结构表示子交易组成，数字序号0,1表示子交易调用顺序，根据数字序号依次从小到大调用对应子交易，如果数字序号相同，表明子交易可以并发调用，function结构表示具体的子交易系统，包括ip、端口port和协议protocol信息。
[0029]
s104，根据服务发现信息生成事务控制信息，并将事务控制信息写入redis集群。
[0030]
其中，根据服务发现信息生成事务控制信息，包括：核心业务系统将服务发现信息传递至业务活动管理器，业务活动管理器添加全局流水号、业务类型、子交易类型生成事务
控制信息。
[0031]
具体的，事务控制信息的数据结构为：
[0032]
{systemnodeid:globaltraceno-》{{type:globaltraceno-》type},{model:globaltraceno-》model},{time:globaltraceno-》time}，systemnodeid:businesstype:biztype-》[{current:0,list＝0,1,2}]}；其中，systemnodeid是各个核心业务系统的节点编号，globaltraceno是全局唯一流水号，type是实体对象的交易类型，model是交易对象，time是最后一次的操作执行操作的时间戳，业务子列表为list结构中businesstype为业务类型，biztype为子类型，即对应服务发现中function描述的信息。
[0033]
s105，业务活动管理器读写事务控制信息，依次调用各核心业务系统的执行函数，完成事务管理。
[0034]
在核心业务系统上配置有一个或多个子交易节点，比如一个本行客户a转账至本行客户b这种场景，至少包含扣减客户a余额，增加客户b余额两个子交易。
[0035]
本发明实施例中，执行函数包括try、query、recovery、confirm和cancel方法。try方法实现子交易的预执行；query方法实现事务的信息查询和事务执行状态的查询，例如是否完成，状态是否正常等；recovery方法是放弃try锁定的资源；confirm方法在预执行完成后提交相应事务；cancel是释放所有资源，流程中止。
[0036]
参见图3，上述事务管理包括发起阶段、确认阶段和回滚阶段。
[0037]
在发起阶段，依次调用各子交易节点的try方法，各核心业务系统接收调用请求后预执行。预执行包括：完成所有业务检查和预留业务资源，实现一致性保证和隔离性保证。
[0038]
接收各子交易节点回复，若有子交易节点未在规定的时间内完成回复，则核心业务系统调用相应子交易节点的query方法，进行事务信息查询和事务执行状态查询；若查询失败，则调用recovery方法释放资源，同时调用cancel方法，表示本次交易失败；若所有子交易节点回复成功，核心业务系统调用各子交易节点的confirm方法，进入确认阶段。
[0039]
在确认阶段，各子交易节点提交本地事务，回复核心业务系统，若所有子交易节点全部响应成功，则交易流程结束，整个交易成功返回服务请求者；在发起阶段和确认阶段，若有任何服务节点回复状态失败，则核心业务系统分别调用子交易节点的cancel方法，交易失败。
[0040]
若子交易节点在规定的时间内没有收到核心业务系统的命令，则进入回滚阶段，自动回滚本地事务。
[0041]
参见图4，本发明实施例中，交易执行的状态具体有pending(等待执行)，success(成功)，fail(失败)，processing(处理中)，missing(丢失，状态未知)，missing状态下，由服务功能节点自动回滚。
[0042]
参见图5，本发明采用redis来记录业务管理器的状态，业务管理信息存储在redis中的数据结构设计为hash结构。具体的，业务活动管理器读写事务控制信息，包括如下步骤：
[0043]
(1)使用全局流水号、交易类型和交易对象实例化出trans对象；
[0044]
(2)核心业务系统(即tcccontrlservice)调度trans对象的运行；
[0045]
(3)trans对象根据state对象，依次调用tcctask的阶段性任务(具体的业务状态流转)；
[0046]
(4)tccservice根据trans对象的状态，可以增加或者定制化保存当前工作的上下文信息。
[0047]
上述方式中，全局的state状态控制可以实现定制化，可以增加超时或者查询机制；task独立封装，各业务节点可以并行的开发，并独立的测试；新增全局状态时，直接扩展trans即可，不需要改变整个框架的基本架构和逻辑；可以调整整个事务期间默认的try(包含query和recovery)，cancel和confirm阶段策略。
[0048]
综上所述，本发明的有益效果包括：提出了一种根据银行核心系统具体的业务场景设计出的分布式事务管理方案，该分布式核心的事务管理框架和功能，交易时效性高，又能保证事务的强一致性。本方案未采用传统的日志系统来记录业务管理器的状态，而是采用redis来保存，提高了记录的速度。在宕机情况下，业务管理器也可以快速恢复执行。在健壮性和容错性方面，redis记录状态的方案明显强于日志系统。
[0049]
应理解，集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0050]
本发明的技术范围不仅仅局限于上述说明中的内容，本领域技术人员可以在不脱离本发明技术思想的前提下，对上述实施例进行多种变形和修改，而这些变形和修改均应当属于本发明的保护范围内。