CN117787989A - 一种基于dpu的风控验证的规则管理平台、设备及存储介质 - Google Patents

Abstract

本申请公开了一种基于DPU的风控验证的规则管理平台、设备及存储介质，该管理平台包括：规则配置模块，用于配置规则的基础信息和风控因子的自定义配置；规则管理模块，用于对所述规则配置模块的规则配置进行管理，其中包括可视化规则配置，以及可自定义化管理规则配置；规则生成模块，用于将规则管理模块提供的规则数据生成规则描述信息；规则发送模块，用于将规则生成模块提供的规则描述信息发送给其他外部系统。通过该管理平台，能够实现多平台部署以及可以自定义选择任意风控因子生成不同的规则。

Description

一种基于DPU的风控验证的规则管理平台、设备及存储介质

技术领域

本发明涉及数据处理领域，具体涉及一种基于DPU的风控验证的规则管理平台、设备及存储介质。

背景技术

随着金融行业的发展，证券交易的实时性要求越来越高，交易报单的频率也在不断提升。在这种高频、高速的交易中，在同一套风控规则管理平台中无法对不同股东配置出相应的风控规则，传统的风控规则管理实现封闭在系统内部，不利于业务人员接触和了解，同时仅能在本地运行，不利于其他平台使用。因此，如何在同一套风控规则管理平台中对不同股东配置出相应的风控规则成为了一个函待解决的技术问题。

发明内容

本申请实施例提供一种基于DPU的风控验证的规则管理平台，能够多平台部署以及可以自定义选择任意风控因子生成不同的规则。

第一方面，一种基于数据处理单元DPU风控验证的规则管理平台，其特征在于，包括：

规则配置模块，用于配置规则的基础信息和风控因子的自定义配置；

规则管理模块，用于对所述规则配置模块的规则配置进行管理，其中包括可视化规则配置，以及可自定义化管理规则配置；

规则生成模块，用于将规则管理模块提供的规则数据生成规则描述信息；

规则发送模块，用于将规则生成模块提供的规则描述信息发送给其他外部系统。

通过以上规则管理平台，可以让用户自定义配置新的风控规则，能够多平台部署，减少了新增一条新规则需要开发工程师重新修改代码写一套新的规则配置的人力成本。

结合第一方面，在第一方面的某些实现方式中，所述规则配置模块包括路由模块、数据模块、视图模块和样式模块，其中：

所述路由模块用于配置前端路由；

所述数据模块用于管理前端的数据状态；

所述视图模块用于视图方式展示页面和组件；

所述样式模块用于设置所述页面的样式。

结合第一方面，在第一方面的某些实现方式中，所述规则管理模块包括后端路由模块、控制器模块和模型模块；其中：

所述后端路由模块用于管理不同统一资源定位符URL路径对应的请求处理函数；

所述控制器模块用于处理前端发送的业务逻辑的请求；

所述模型模块用于定义数据模型和数据库交互的接口。

结合第一方面，在第一方面的某些实现方式中，所述规则生成模块包括JavaScript对象表示法json规则生成接口、规则数据处理模块和json规则获取接口；其中：

所述json规则生成接口，用于提供add_rule_json(dict_rule_str)接口供其他模块调用，用来生成一条完整的规则；

所述规则数据处理模块用于将模型模块的json串处理提取数据生成最终的规则json串；

所述json规则获取接口用于提供get_json_str()接口供其他模块调用，用来获取所有启用的规则形成的json串。

结合第一方面，在第一方面的某些实现方式中，所述规则发送模块包括通用协议模块和服务端模块；其中：

所述通用协议模块用于定义数据包的协议，对数据进行封装和解包；

所述服务端模块用于创建一个服务端与客户端通信。

结合第一方面，在第一方面的某些实现方式中，所述视图模块所展示的组件，包括设置规则的基础信息的组件，以及设置规则的风控因子的组件。

结合第一方面，在第一方面的某些实现方式中，所述规则数据处理模块用于定义描述规则的json模板。

结合第一方面，在第一方面的某些实现方式中，所述服务端模块用于通过配置文件配置IP和端口号，创建一个服务端监听当前端口号，对客户端的请求进行判断，当收到相应的请求则发送规则json串。

第二方面，本申请提供了一种基于数据处理单元DPU的风控验证的规则管理设备，包括存储器和处理器；所述存储器和所述处理器耦合；所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令；其中，当所述处理器执行所述计算机指令时，使得所述规则管理设备实现如第一方面中任意一项规则管理平台的功能。

第三方面，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)当其在数据传输装置上运行时，使得规则管理设备实现如第一方面中任意一项规则管理平台的功能。

附图说明

图1为本申请实施例提供的基于数据处理单元DPU风控验证的规则管理平台的结构示意图；

图2为本申请实施例提供的规则配置模块的结构示意图；

图3为本申请实施例提供的规则管理模块的结构示意图；

图4为本申请实施例提供的描述规则的json模板示意图；

图5本申请实施提供的规则发送模块的规则发送流程图；

图6为本申请实施提供的规则发送模块中通用协议的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明作进一步的详细说明，本发明的示意性实施方式及其说明仅用于解释本发明，并不作为对本发明的限定。本申请中被描述为“示例”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a、b和c中的至少一项(个)，可以表示：a，或，b，或，c，或，a和b，或，a和c，或，b和c，或，a、b和c。其中a、b和c分别可以是单个，也可以是多个。涉及网元A向网元B发送消息、信息或数据，以及网元B接收来自网元A的消息、信息或数据的相关描述，旨在说明该消息、信息或数据是要发给哪个网元，而并不限定它们之间是直接发送还是经由其他网元间接发送。“当……时”、“在……的情况下”、“若”以及“如果”等描述均指在某种客观情况下设备会做出相应的处理，并非是限定时间，且也不要求设备在实现时一定要有判断的动作，也不意味着存在其它限定。

此外，本申请实施例描述的架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

下面是本申请中的一些术语的缩写及中英文全称：DPU(Data Processing Unit，数据处理单元)，json(JavaScript Object Notation，JavaScript对象表示法)，URL(Uniform Resource Locator，统一资源定位符)。

DPU是数据处理单元(Data Processing Unit)的简称，是最新发展起来的专用处理器的一个大类，被业界认为是继CPU、GPU之后，数据中心场景中的第三颗重要的算力芯片，为高带宽、低延迟、数据密集的计算场景提供计算引擎。DPU是以数据为中心构造的专用处理器，和CPU(中央处理器)一样，DPU可以作为一颗独立的ASIC芯片，插入服务器主板上的PCIe插槽，或者与CPU集成在同一芯片中，作为其中的一个功能单元。DPU的主要作用是为通常的CPU减负，就是把通常说计算资源(CPU)的负荷卸载下来，使得CPU可以释放出计算能力来去做别的工作。

DPU适合各种应用工作负载，具有低成本和高性能，相当于为AI和云计算定制的新一类专用处理器。DPU能卸载其宕机应用的有效负载，提升整个计算系统效率，降低整体系统的总体拥有成本，提升性价比。

URL也被称为网页地址，是因特网上标准的资源的地址。互联网上的每个文件都有一个唯一的URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它。

json是一种轻量级的、基于文本的、开放的数据交换格式，主要用来在浏览器和服务器之间进行通信。它采用完全独立于编程语言的文本格式来存储和表示数据，使得数据交换变得简单和方便。JavaScript的中文全称是“JavaScript脚本语言”。它是一种轻量级的解释型或即时编译型的编程语言，广泛用于客户端的脚本语言，最早是在HTML网页上使用，用来给HTML网页增加动态功能。

随着着市场的不断发展和交易量的增加，证券交易的实时性要求越来越高。这意味着交易报单的频率在不断提升，交易系统需要能够迅速处理大量的交易请求，并在毫秒级别内做出响应。然而，高频交易也带来了更高的风险，因此需要相应的风控规则管理系统来监控和控制交易风险。

传统的风控规则管理实现通常封闭在系统内部，由技术人员进行开发和维护。这种实现方式不利于业务人员接触和了解风控规则的运作方式，也不便于调整和优化规则。此外，传统的风控规则管理系统通常只能在本地运行，无法适应跨平台的需求，限制了其在其他平台上的使用。

现有的风控规则管理系统通常采用预先设定好的固定规则，根据规则类型进行相应的增删改查操作以及配置阈值等基本数值。这种方式虽然在一定程度上可以实现风控管理，但在面对复杂的金融市场和高频交易时，固定的规则往往无法满足灵活多变的风险控制需求。此外，现有的风控规则管理系统使用的前端技术栈通常为Qt，前端界面是在本地运行的UI界面，无法进行跨平台部署，这也限制了其在不同平台上的应用范围。。

图1是本申请提供的一种基于数据处理单元DPU风控验证的规则管理平台的结构示意图，包括以下模块：

规则配置模块，用于配置规则的基础信息和风控因子的自定义配置；

规则管理模块，用于对所述规则配置模块的规则配置进行管理，其中包括可视化规则配置，以及可自定义化管理规则配置；

规则生成模块，用于将规则管理模块提供的规则数据生成规则描述信息；

规则发送模块，用于将规则生成模块提供的规则描述信息发送给其他外部系统。

规则配置模块是风控规则管理平台中的模块之一，在一种实施方式中，其主要功能是提供友好的用户界面和操作方式，使业务人员能够方便地接触和了解风控规则的运作方式并进行相应的配置和调整。下面将对规则配置模块中包含的路由模块、数据模块、视图模块、样式模块进行详细解释。如图2所示，规则配置模块包含路由模块、数据模块、视图模块、样式模块；其中路由模块用于前端路由配置，数据模块用于管理前端的数据状态，视图模块用于各个页面和组件的视图展示，样式模块用于页面的样式设计和布局。

在路由模块中，设置根路由展示的页面即是所有规则显示界面，用户可以直观地看到当前已经创建的所有规则信息。该模块主要用于前端路由配置，实现页面的切换和跳转。在风控规则管理系统中，路由模块设置根路由展示的页面为所有规则显示界面，即用户进入系统后首先看到的是所有已经创建的规则信息列表。这样设计可以使得用户直观地了解当前系统中已经存在的规则，方便进行后续的编辑和管理。

在数据模块中，对用户填写的数据进行获取、存储和处理。数据模块主要负责管理前端的数据状态，包括用户填写的数据、系统生成的数据等。在风控规则管理系统中，数据模块需要实现用户填写数据的获取、存储和处理功能。具体来说，当用户创建或编辑规则时，需要获取用户填写的数据并进行验证和处理；当规则保存或更新时，需要将数据存储到后端数据库中。

在视图模块中，对各个页面的各个组件进行展示，对于规则的基础信息设置为必选组件，对于规则可选的风控因子设置为可选组件，根据用户自主选择显示不同组件。视图模块用于各个页面和组件的视图展示，包括页面的布局、组件的样式和交互等。在风控规则管理系统中，视图模块需要对各个页面的各个组件进行展示，对于规则的基础信息设置为必选组件(如规则名称、规则描述等)，对于规则可选的风控因子设置为可选组件(如风险等级、阈值等)。这样设计可以使得用户根据需要自定义显示内容，提高系统的灵活性和可用性。

在样式模块中，设置页面的布局为页头、菜单栏、主页面，主页面根据菜单栏的点击不同选项，显示出规则展示界面、规则编辑界面、规则保存界面等。样式模块用于页面的样式设计和布局，包括页面的整体风格、颜色、字体等。在风控规则管理系统中，样式模块需要设置页面的布局为页头、菜单栏、主页面三个部分。其中，主页面根据菜单栏的点击不同选项显示出规则展示界面、规则编辑界面、规则保存界面等。这样设计可以使得用户在不同的操作场景下都能够获得清晰明了的页面展示和操作体验。

通过合理设计和实现路由模块、数据模块、视图模块和样式模块，可以构建出一个功能完善、操作简便的风控规则管理系统前端界面，为用户提供便捷高效的规则配置和管理体验。

规则管理模块是风控规则管理系统中的组成模块之一，其主要职责是对所述规则配置模块的规则配置进行管理，其中包括可视化规则配置，以及可自定义化管理规则；通过配置处理前端发送的业务逻辑请求，并与数据库进行交互，实现规则的增删改查等操作。在一种实施方式中，如图3所示，规则管理模块包含后端路由模块、控制器模块、模型模块；其中：后端路由模块用于管理不同URL路径对应的请求处理函数，控制器模块用于处理前端发送的业务逻辑的请求，模型模块用于定义数据模型和数据库交互的接口等。

在后端路由模块中，设置前端请求或修改规则数据均为query()处理函数。该模块主要负责管理不同URL路径对应的请求处理函数。在风控规则管理系统中，后端路由模块设置前端请求或修改规则数据均为query()处理函数。在这种设计中，所有前端请求或修改规则数据的操作都被映射到一个名为query()的处理函数上。这样做的目的是为了统一处理前端发送过来的各种请求，简化后端的处理逻辑。query()处理函数是一个在后端路由模块中定义的特定函数，它负责接收并处理前端发送过来的请求。当用户在前端进行某些操作(如请求数据、提交表单等)时，这些操作会发送HTTP请求到后端。后端路由模块根据请求的URL路径和HTTP方法(GET、POST等)来判断应该使用哪个处理函数来处理这个请求。在这个设计中，前端发送的请求或数据修改操作，都会统一由query()函数来处理。

query()函数通常会包含一些逻辑来判断请求的具体内容，并据此执行相应的操作(如查询数据库、更新数据等)。它可能还需要与其他后端模块(如控制器模块、模型模块等)进行交互，以完成复杂的业务逻辑。通过这种设计方式，可以确保所有前端请求和数据修改操作都能得到统一、规范的处理，从而提高系统的稳定性和可维护性。

需要注意的是，query()函数的具体实现会根据具体的业务需求和系统设计而有所不同。在实际开发中，需要根据具体情况来设计和实现这个函数，以确保它能正确地处理各种前端请求和数据修改操作。这样设计可以简化后端的处理逻辑，所有前端发送的请求都会统一由query()函数来处理，提高了代码的可维护性和复用性。

在控制器模块中，定义前端发送的请求包中，table表示数据表名、id表示数据表的key、operate表示前端请求的操作如增加数据、删除数据、修改数据、查询所有数据、按页查询数据等。控制器模块用于处理前端发送的业务逻辑的请求。在风控规则管理系统中，控制器模块需要解析前端发送的请求包，其中table表示数据表名、id表示数据表的key、operate表示前端请求的操作如增加数据、删除数据、修改数据、查询所有数据、按页查询数据等。根据解析出的请求信息，控制器模块会调用相应的模型类和方法来完成具体的业务逻辑操作。

在模型模块中，使用django的model库，每个模型类均能与数据库中的数据表相互对应，直接创建模型类的实例，即可获取到数据库中的所有数据，定义update_data函数，用来更新数据库中的数据，定义to_json函数，用来将数据库中的每条数据生成json串便于打印数据。"json串"则是生成的符合JSON格式规则数据的具体表现形式。它是一个字符串，按照JSON的语法规则进行组织和格式化，包含了所需的数据和信息。这个JSON串可以被解析和读取，用于指导或驱动系统中的某些操作。比如，它可以被解析为一个JavaScript对象，然后在程序中使用这些数据进行相应的处理或操作。模型模块用于定义数据模型和数据库交互的接口。在风控规则管理系统中，使用Django的model库来创建模型类，每个模型类均能与数据库中的数据表相互对应。通过直接创建模型类的实例，可以获取到数据库中的所有数据。

当用户通过前端界面进行规则管理操作时(如添加、编辑、删除规则等)，前端会发送相应的请求到后端。后端路由模块根据请求的URL路径将请求转发给query()处理函数。query()函数会根据请求中的操作类型(由控制器模块解析出来)调用相应的模型类和方法来完成具体的数据库操作(如增加、删除、修改数据等)。模型类与数据库中的数据表相互对应，因此可以直接对数据库进行操作。操作完成后，模型类会将结果返回给控制器模块，由控制器模块将结果打包成JSON格式并返回给前端。前端收到结果后会对页面进行相应的更新操作(如刷新规则列表等)。

总之，通过合理设计和实现后端路由模块、控制器模块和模型模块，可以构建出一个高效可靠的风控规则管理系统后端服务，为用户提供便捷灵活的规则管理功能。

规则生成模块是风控规则管理系统中的组成模块之一，在一种实施方式中，如图3所示，规则生成模块包含json规则生成接口、规则数据处理模块、json规则获取接口；其中：json规则生成接口，提供add_rule_json(dict_rule_str)接口供其他模块调用，用来生成一条完整的规则，规则数据处理模块用于将模型模块的json串处理提取数据生成最终的规则json串，json规则获取接口提供get_json_str()接口供其他模块调用，用来获取所有启用的规则形成的json串。

json规则生成接口：该接口主要提供一个add_rule_json(dict_rule_str)函数供其他模块调用，用来生成一条完整的规则。该函数接受一个字典类型的参数dict_rule_str，其中包含了规则的所有必要信息(如规则名称、规则描述、风险等级、阈值等)。函数内部会将这些信息按照预设的格式转换成JSON字符串，并返回给调用方。这样设计可以使得其他模块能够方便地生成规则，并且保证了生成的规则格式统一、易于处理。

规则数据处理模块：该模块主要负责将模型模块的JSON串处理提取数据生成最终的规则JSON串。具体来说，当模型模块将数据以JSON格式返回给规则生成模块时，规则数据处理模块会对这些JSON数据进行解析和处理，提取出其中的关键信息(如规则名称、条件表达式等)，并按照预设的格式生成最终的规则JSON串。这个过程可能涉及到数据的清洗、转换和计算等操作，以确保生成的规则准确无误。

json规则获取接口：该接口主要提供一个get_json_str()函数供其他模块调用，用来获取所有启用的规则形成的JSON串。该函数会查询数据库中所有启用的规则，并将这些规则转换成JSON格式的字符串返回给调用方。这样设计可以使得其他模块能够方便地获取所有启用的规则，并且以统一的格式进行处理和展示。

具体来说，当用户通过前端界面进行规则生成操作时(如添加新规则)，前端会发送相应的请求到后端。后端接收到请求后，会调用json规则生成接口的add_rule_json(dict_rule_str)函数来生成一条新的规则。该函数会根据用户输入的信息生成一个JSON字符串，并将其保存到数据库中。接着，规则数据处理模块会对这条新生成的规则进行处理和转换，生成最终的规则JSON串。最后，json规则获取接口会调用get_json_str()函数来获取所有启用的规则形成的JSON串，并将其返回给前端进行展示。

通过合理设计和实现json规则生成接口、规则数据处理模块和json规则获取接口，可以构建出一个灵活高效的规则生成系统，为用户提供便捷的规则生成和管理功能。同时，这些接口也可以与其他系统进行集成和交互，实现更广泛的应用场景。

在规则数据处理模块中，通过如图4所示的一种实施方式的描述规则的json模板，将模型模块生成的json串数据提取出值，生成对应的规则json的值。这个JSON模板会详细列出规则中需要的所有字段，它定义了如何从模型模块生成的json串中提取出相应的值，并生成对应的规则JSON。

通过这种方式，规则数据处理模块能够灵活地处理不同来源和格式的规则数据，并将其转换成统一、结构化的规则JSON格式，从而提高了整个系统的可扩展性和可维护性。同时，通过使用JSON模板，规则数据处理模块也提供了更大的配置灵活性，使得用户可以根据实际需求自定义规则的结构和内容。

规则发送模块是风控规则管理系统中的组成模块之一，在一种实施方式中，规则发送模块包含通用协议模块、服务端模块；其中：通用协议模块用于定义数据包的协议，对数据进行封装和解包，服务端模块用于创建一个服务端与客户端通信。如图5所示，规则发送模块主要负责与其他系统进行通信，将生成的规则json串发送给其他系统或接收其他系统发送的请求，通过配置文件配置IP和端口(port)，然后启动并运行服务端，当接收到客户端连接请求和客户端的规则请求后，判断规则请求是否合法，当判断合法，则发送规则json数组串。

在通用协议模块中，定义通用协议，如图6所示，对发送的数据进行封装成固定协议数据包，将接收到的数据进行解包。通用协议模块用于定义数据包的协议，对数据进行封装和解包。具体来说，在通用协议模块中，会定义一个通用的协议格式，如图6所示。该协议格式规定了数据包的结构和各个字段的含义，以确保发送方和接收方能够正确地解析和处理数据包。当规则发送模块需要发送数据时，它会使用该协议将数据封装成一个固定协议的数据包；当接收到数据时，它会使用该协议对数据进行解包，提取出其中的有效信息。

在服务端模块中，通过配置文件配置IP和端口(port)，创建一个服务端监听当前端口号，对客户端的请求进行判断，收到相应的请求则发送规则json串。服务端模块用于创建一个服务端与客户端通信。在服务端模块中，首先需要通过配置文件配置IP地址和端口号，指定服务端监听的地址和端口。然后，服务端模块会创建一个服务端实例，并开始监听指定的端口。当有客户端连接到该端口时，服务端模块会接受客户端的请求，并根据请求的类型进行相应的处理。如果请求是获取规则JSON串的请求，服务端模块会从数据库中获取最新的规则JSON串，并将其发送给客户端；如果请求是其他类型的请求，服务端模块会根据具体情况进行响应或拒绝。

为了确保通信的安全性和可靠性，可选的，规则发送模块还具备安全功能，如数据加密、身份验证等。例如，可以使用加密算法对数据进行加密，以确保数据在传输过程中不会被截获或篡改；可以使用数字签名技术对数据进行签名，以验证数据的完整性和来源；可以使用访问控制机制对客户端进行身份验证和授权，以防止未经授权的访问和操作。

通过合理设计和实现通用协议模块和服务端模块，规则发送模块可以与其他系统进行高效、安全的通信，实现规则的共享和交换。同时，这些模块也可以根据实际需要进行扩展和优化，以适应不同的应用场景和需求。

根据本发明的web系统前端配置风控因子生成一条自定义的json形式的金融风控规则操作，得到能够通过前端选择不同因子，生成统一为json形式的风控规则，解决了目前仅能对固定了的金融风控规则的阈值进行配置，而不能自定义一条金融风控规则的问题。

此外，在另一种实施方式中，可以使用JavaWeb框架作为后端，结合原生JavaScript、HTML和CSS作为前端界面展示。这种架构可以使前后端分离，提高开发效率和代码可维护性。

在后端方面，JavaWeb框架(如Spring、Spring Boot、Struts等)提供了丰富的功能和工具，用于处理HTTP请求、管理数据库连接、实现业务逻辑等。通过使用这些框架，开发人员可以快速构建稳健可靠的后端服务，并与前端进行通信。

前端方面，使用原生JavaScript、HTML和CSS可以创建交互式的用户界面。JavaScript用于实现动态效果和交互逻辑，HTML用于定义页面结构，CSS用于控制样式和布局。通过合理组织和使用这些技术，可以构建出美观、易用的前端界面，并与后端进行数据交互。

前后端之间的通信通常使用HTTP协议或WebSocket协议。后端提供RESTful API或WebSocket接口，前端通过Ajax或WebSocket与服务端进行通信，实现数据的获取和更新。这种方式使得前后端可以独立开发和测试，提高了开发效率和代码质量。

使用JavaWeb框架作为后端，结合原生JavaScript、HTML和CSS作为前端界面展示。这种架构可以实现前后端分离，提高开发效率和代码可维护性，并且可以与其他系统进行集成和交互，实现更广泛的应用场景。

本申请实施例的管理平台也可称为管理系统。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。

虽然本说明书实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书实施例的实施例而已，并不用于限制本说明书实施例。对于本领域技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的权利要求范围之内。

Claims (10)

1.一种基于数据处理单元DPU的风控验证的规则管理平台，其特征在于，包括：

规则配置模块，用于配置规则的基础信息和风控因子的自定义配置；

规则管理模块，用于对所述规则配置模块的规则配置进行管理，其中包括可视化规则配置，以及可自定义化管理规则配置；

规则生成模块，用于将规则管理模块提供的规则数据生成规则描述信息；

规则发送模块，用于将规则生成模块提供的规则描述信息发送给其他外部系统。

2.根据权利要求1所述的管理平台，其特征在于，所述规则配置模块包括路由模块、数据模块、视图模块和样式模块，其中：

所述路由模块用于配置前端路由；

所述数据模块用于管理前端的数据状态；

所述视图模块用于视图方式展示页面和组件；

所述样式模块用于设置所述页面的样式。

3.根据权利要求1所述的管理平台，其特征在于，所述规则管理模块包括后端路由模块、控制器模块和模型模块；其中：

所述后端路由模块用于管理不同统一资源定位符URL路径对应的请求处理函数；

所述控制器模块用于处理前端发送的业务逻辑的请求；

所述模型模块用于定义数据模型和数据库交互的接口。

4.根据权利要求1所述的管理平台，其特征在于，所述规则生成模块包括JavaScript对象表示法json规则生成接口、规则数据处理模块和json规则获取接口；其中：

所述json规则生成接口，用于提供add_rule_json(dict_rule_str)接口供其他模块调用，用来生成一条完整的规则；

所述规则数据处理模块用于将模型模块的json串处理提取数据生成最终的规则json串；

所述json规则获取接口用于提供get_json_str()接口供其他模块调用，用来获取所有启用的规则形成的json串。

5.根据权利要求1所述的管理平台，其特征在于，所述规则发送模块包括通用协议模块和服务端模块；其中：

所述通用协议模块用于定义数据包的协议，对数据进行封装和解包；

所述服务端模块用于创建一个服务端与客户端通信。

6.根据权利要求2所述的管理平台，其特征在于，所述视图模块所展示的组件，包括设置规则的基础信息的组件，以及设置规则的风控因子的组件。

7.根据权利要求4所述的管理平台，其特征在于，所述规则数据处理模块用于定义描述规则的json模板。

8.根据权利要求4所述的管理平台，其特征在于，所述服务端模块用于通过配置文件配置IP和端口号，创建一个服务端监听当前端口号，对客户端的请求进行判断，当收到相应的请求则发送规则json串。

9.一种基于数据处理单元DPU的风控验证的规则管理设备，其特征在于，包括存储器和处理器；所述存储器和所述处理器耦合；所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令；其中，当所述处理器执行所述计算机指令时，使得所述规则管理设备实现如权利要求1-8中任意一项所述的规则管理平台的功能。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令；其中，当所述计算机指令在规则管理设备上运行时，使得所述规则管理设备实现如权利要求1-8中任意一项所述的规则管理平台的功能。