CN111309290A - 一种灵活可扩展业务规则矩阵系统 - Google Patents

Abstract

本发明公开了一种灵活可扩展业务规则矩阵系统，针对不同的业务可使用现有业务处理规则和新增业务处理规则，业务规则也可任意组合，很大程度上提高了系统及系统代码的维护性。其技术方案为：系统包括多个规则矩阵模块，每一规则矩阵模块中包含一个规则事件模块和一个规则集模块，其中规则事件模块用于存储业务场景中规则执行所需要的数据以及规则矩阵模块执行的数据初始化和数据获取；规则集模块用于规则的执行，包含多个规则单元和预先设置的规则单元的执行顺序，其中所有规则单元共享规则事件模块，每一规则单元用于实现一个业务原子操作，每一规则单元在执行结束后根据执行结果按照规则单元的执行顺序执行下一个规则单元。

Description

一种灵活可扩展业务规则矩阵系统

技术领域

本发明涉及金融交易软件领域，具体涉及一种灵活可扩展业务规则矩阵系统。

背景技术

金融交易软件需要处理很多复杂的业务场景，一个业务场景一般对应一个业务逻辑流程图，通常的业务开发常常是面向过程的，即将业务流程图直接转换为代码，当业务较为复杂时，会导致金融系统和代码可维护性大大降低。对于一个复杂的业务场景，可以将其拆分为多个不同的小的业务处理单元，而不同的业务场景又存在可复用的处理单元。

如何利用好这些可复用的处理单元来解决面向过程的业务开发中导致的系统代码可维护性低的问题，是目前业界亟待解决的关键。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种灵活可扩展业务规则矩阵系统，针对不同的业务可使用现有业务处理规则和新增业务处理规则，业务规则也可任意组合，很大程度上提高了系统及系统代码的维护性。

本发明的技术方案为：本发明揭示了一种灵活可扩展业务规则矩阵系统，系统包括多个规则矩阵模块，每一规则矩阵模块中包含一个规则事件模块和一个规则集模块，其中：

规则事件模块，用于存储业务场景中规则执行所需要的数据以及规则矩阵模块执行的数据初始化和数据获取；

规则集模块，用于规则的执行，包含多个规则单元和预先设置的规则单元的执行顺序，其中所有规则单元共享规则事件模块，每一规则单元用于实现一个业务原子操作，每一规则单元在执行结束后根据执行结果按照规则单元的执行顺序执行下一个规则单元。

根据本发明的灵活可扩展业务规则矩阵系统的一实施例，规则事件模块中包含数据初始化接口单元和数据获取接口单元。

根据本发明的灵活可扩展业务规则矩阵系统的一实施例，规则单元根据不同业务场景来增减。

根据本发明的灵活可扩展业务规则矩阵系统的一实施例，规则单元的执行顺序根据不同业务场景进行调整。

根据本发明的灵活可扩展业务规则矩阵系统的一实施例，规则集模块在执行前由规则集事件模块先调用数据重置再调用数据初始化接口单元初始化数据。

根据本发明的灵活可扩展业务规则矩阵系统的一实施例，规则集模块在执行过程中，各个规则单元通过统一的数据获取接口单元从规则事件模块中获取数据，实现业务处理逻辑和数据的分离。

根据本发明的灵活可扩展业务规则矩阵系统的一实施例，规则事件模块根据业务来定义，规则矩阵模块从多个规则事件模块中选取自己的规则事件模块，其中规则事件模块是可复用的。

根据本发明的灵活可扩展业务规则矩阵系统的一实施例，规则事件模块中所存储的数据对应的业务场景包括但不限于订单指令报送、双边报价指令报送、撤单指令报送、订单通知处理、成交通知处理，数据包括但不限于交易合约数据、交易账户配置数据、交易风控配置数据、行情数据、交易指令、交易所订单通知、交易所成交通知，其中不同的业务场景依赖于不同的数据集。

本发明对比现有技术有如下的有益效果：本发明的系统是通过规则矩阵模块来实现，规则矩阵模块针对业务数据进行抽象，参考模板化状态机实现原理，将复杂的业务处理逻辑抽象成具有共性的业务原子操作。此外，本发明使用模板方式提供基础的规则，后续业务处理规则继承自基础的规则，做到统一封装回调处理和统一封装处理函数。每个规则只关注于自身的业务处理，而无需关注于业务上下文。采用规则事件模块保存业务上下文数据，做到业务处理逻辑与业务数据的隔离。相较于现有技术灵活可扩展，本发明针对不同的业务可使用现有业务处理规则和新增业务处理规则，业务规则可任意组合，很大程度上提高了系统及系统代码的维护性。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的规则矩阵的示意图。

图2示出了本发明的规则矩阵模块的一实施例的原理图。

图3示出了本发明的灵活可扩展业务规则矩阵系统的一实施例的原理图。

图4示出了本发明的规则事件模块的一个示例的示意图。

图5示出了本发明的规则集模块的一实施例的原理图。

图6示出了本发明的规则集模块的一个示例的示意图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

本发明参考模板化状态机的实现原理，提出针对业务数据进行抽象的规则矩阵体系。将业务处理单元称为规则，将规则通过特定的方式串联起来完成业务场景的功能称为规则矩阵。规则矩阵是描述处理一个业务场景的所有规则、规则的先后执行顺序，及执行该规则矩阵所依赖事件的组合。

图1所示的规则矩阵包含三个组成部分：规则事件、规则、规则的顺序。其中，一个规则矩阵内包含一个规则事件。规则事件内存储业务场景需要的基础数据，也就是业务处理的上下文。一个规则矩阵内包含若干个规则，一个规则负责实现一个具体的业务原子操作，即一个最小业务处理单元。一个规则矩阵内的各个规则将按照指定的顺序被执行。规则的执行顺序可根据不同的业务场景进行顺序的调整。每个规则执行结束后，规则矩阵将根据执行结果，按照设定的链路来执行下一个业务规则，针对每个规则执行结果的不同，可设置不同的下个执行规则。

如图2所示，本实施例中的规则矩阵模块由规则事件模块和规则集模块两大部分组成。规则事件模块用于规则矩阵执行的数据初始化和数据获取，规则事件模块包含数据初始化接口单元和数据获取接口单元。规则集模块由规则及规则执行顺序组成，负责规则的执行。规则集模块由任意个规则单元组成，规则单元的数量不限制，规则单元的执行顺序也无限制，视具体的业务场景决定。

图3示出了本发明的灵活可扩展业务规则矩阵系统的一实施例的原理，本实施例的灵活可扩展业务规则矩阵系统包括多个规则矩阵模块(图示为2个)。如图3所示，规则事件模块中维护了规则执行需要的数据，提供数据初始化接口单元及数据获取接口单元，也就是业务处理的上下文。规则矩阵模块内的所有规则单元共享一个规则事件。规则集模块在执行之前，规则集事件模块内部先调用数据的重置，再调用数据初始化接口单元初始化数据。规则集模块在规则执行过程中，各个规则单元通过统一的数据获取接口单元从规则事件模块中获取所需的数据，实现了业务处理逻辑与数据的分离。

规则事件模块为规则集模块执行提供基础数据。以金融系统订单发送业务场景为例，规则事件模块中的数据包含订单初始信息、该订单的合约信息、产品信息、持仓信息等。订单发送事件定义如图4所示。

规则矩阵模块运行前，先调用Reset和Init函数，进行数据初始化，如发送的订单规则事件初始化基础信息，并校验基础数据的有效性，如校验合约(instrument)信息，若基础信息存在错误，则终止规则矩阵的执行。

规则事件模块根据具体的业务定义，可以定义任意个，各规则事件模块相互独立。在处理特定的业务场景时，每个规则矩阵模块可选取不同的规则事件，因此规则事件模块可以复用到不同的业务场景中。

规则事件模块将业务数据与业务规则隔离，每个业务场景的上下文保存在规则事件模块中。业务规则只需关注自身的业务处理逻辑，所有依赖数据从规则事件模块中获取。规则单元执行会涉及到上下文的修改，进而影响下个规则单元的执行。

规则集模块的一个实施例如图5所示。如图5所示，本实施例的规则集模块由若干个规则单元和规则单元的执行顺序组成。规则单元可以根据具体业务场景进行增减，规则单元的执行顺序也可以根据具体的业务场景进行调整。本发明提供业务规则的基类接口，后续业务处理的规则继承自该基类，在实现业务时只关注于实现自身的业务处理。

规则集模块中设置一个起始运行的规则，除最后执行的规则外，每个规则设置下个执行的规则，可设置多个下个执行规则。每个规则执行会有执行结果，执行结果可以有多种情况，可以为不同的执行结果设置不同的后续执行规则，规则矩阵将根据规则的执行结果决定下一步执行哪个规则。如图5示，规则1为起始规则，规则1执行结果满足①条件则执行规则2，满足②条件则继续执行规则3，满足③条件则执行规则4，其他规则以此类推，其中规则3、规则4、规则7、规则8是结束规则，运行这些规则后，规则矩阵模块运行结束。

如果业务场景需新增业务处理逻辑，可新增一个业务规则，添加到规则集模块中现有某个规则单元之后即可。如果业务处理场景的处理逻辑顺序改变，可直接更改规则单元的执行顺序达成业务处理逻辑顺序修改的效果。由于将业务原子操作独立抽象成规则单元，一个规则单元的修改不会影响到其他已有规则，实现了业务功能的灵活可扩展。

本发明的应用场景包括订单指令报送、双边报价指令报送、撤单指令报送、订单通知处理、成交通知处理等，涵盖了金融交易的主要业务操作场景。业务数据包括交易合约数据、交易账户配置数据、交易风控配置数据、行情数据、交易指令、交易所订单通知、交易所成交通知等数据，不同的业务依赖于不同的数据集。

以订单指令报送业务场景为例，该业务的主要目的是对金融系统中产生的订单指令进行一系列合法性检查，将通过检查的订单报送至交易所。在该业务的规则集内，规则事件内包含了订单信息(如合约、价格、数量等)、合约数据、行情数据、交易风控配置数据等。规则矩阵执行前，先调用规则事件的Reset和Init函数，这两个函数负责初始化这些数据，后续规则可通过规则事件内提供的数据获取接口来获取相关数据。

该业务的规则集定义如图6所示，处理订单发送的规则包含如下规则：

(1)订单生成规则(Rule_generate_order)：根据规则事件内的订单信息，生成符合交易所规定格式的订单指令。

(2)价格检查规则(Rule_check_price)：根据规则事件内的合约信息和行情信息，对订单内价格字段的合法性进行检查。

(3)订单数量检查规则(Rule_check_volume)：根据规则事件内的合约信息，对订单内数量字段的合法性进行检查。

(4)订单最大数量检查规则(Rule_check_max_volume)：从规则事件内获取风控配置数据，检查订单内的数量是否小于风控配置数据中的最大合法订单数量。

(5)合约持仓检查规则(Rule_check_position)：从规则事件内获取持仓数据和风控配置数据，检查当前持仓是否符合超过风控配置数据中的持仓数量上限。

(6)订单发布规则(Rule_publish_order)：如果订单通过检查，该规则将订单报送至交易所。

(7)错误订单应答规则(Rule_rsp_error_order)：如果订单未通过检查，改规则将订单打回，并报告错误详情。

上述所有规则执行结果包括“通过”“不通过”两种情况。生成订单规则为开始规则，若规则执行结果为通过，执行下一规则(Rule_check_price)；若执行结果为不通过，执行错误订单应答规则。如果后续业务逻辑发生修改，如增加了判断增加合约交易权限的检查，可在Rule_check_position后新增对应的规则Rule_instrument_trading_right即可，而无需改动其他规则。

此外，上述应用场景所包含的规则也可以复用于其他业务场景中。以双边报价指令报送业务场景为例，该业务场景的目的是对金融系统中产生的双边报价指令进行一系列合法性检查，将通过检查的双边报价指令报送至交易所。在该业务中，也需要进行订单最大梳理检查和合约持仓检查，因此可以直接复用相关规则。只需要在本业务场景下的规则事件内提供获取风控配置数据的接口，即可在规则集内直接使用Rule_check_max_volume和Rule_check_position两个规则。

由于金融业务处理场景复杂度高、场景多等特性，因此本发明需要具备高灵活，高扩展、高复用特性。

(1)高灵活：将复杂的业务场景抽象成各个小的业务处理单元(即规则单元)，在处理特定的场景再进行业务单元(规则单元)的组装，做到场景处理的高灵活性。

(2)高扩展：处理新的业务场景，如没有特定的业务处理规则，只需新增规则单元，添加到规则矩阵模块中即可。

(3)高复用：不同的业务场景可以重复使用规则。金融业务场景中，很多场景存在共同的处理流程，将业务处理单元抽象成规则单元，可以实现规则单元在不同业务场景中的复用。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (8)

1.一种灵活可扩展业务规则矩阵系统，其特征在于，系统包括多个规则矩阵模块，每一规则矩阵模块中包含一个规则事件模块和一个规则集模块，其中：

规则事件模块，用于存储业务场景中规则执行所需要的数据以及规则矩阵模块执行的数据初始化和数据获取；

规则集模块，用于规则的执行，包含多个规则单元和预先设置的规则单元的执行顺序，其中所有规则单元共享规则事件模块，每一规则单元用于实现一个业务原子操作，每一规则单元在执行结束后根据执行结果按照规则单元的执行顺序执行下一个规则单元。

2.根据权利要求1所述的灵活可扩展业务规则矩阵系统，其特征在于，规则事件模块中包含数据初始化接口单元和数据获取接口单元。

3.根据权利要求1所述的灵活可扩展业务规则矩阵系统，其特征在于，规则单元根据不同业务场景来增减。

4.根据权利要求1所述的灵活可扩展业务规则矩阵系统，其特征在于，规则单元的执行顺序根据不同业务场景进行调整。

5.根据权利要求2所述的灵活可扩展业务规则矩阵系统，其特征在于，规则集模块在执行前由规则集事件模块先调用数据重置再调用数据初始化接口单元初始化数据。

6.根据权利要求2所述的灵活可扩展业务规则矩阵系统，其特征在于，规则集模块在执行过程中，各个规则单元通过统一的数据获取接口单元从规则事件模块中获取数据，实现业务处理逻辑和数据的分离。

7.根据权利要求1所述的灵活可扩展业务规则矩阵系统，其特征在于，规则事件模块根据业务来定义，规则矩阵模块从多个规则事件模块中选取自己的规则事件模块，其中规则事件模块是可复用的。

8.根据权利要求1至7中任一项所述的灵活可扩展业务规则矩阵系统，其特征在于，规则事件模块中所存储的数据对应的业务场景包括但不限于订单指令报送、双边报价指令报送、撤单指令报送、订单通知处理、成交通知处理，数据包括但不限于交易合约数据、交易账户配置数据、交易风控配置数据、行情数据、交易指令、交易所订单通知、交易所成交通知，其中不同的业务场景依赖于不同的数据集。

Images