CN113946321A - 计算逻辑的处理方法、电子设备和可读存储介质 - Google Patents

Abstract

本申请涉及计算机软件领域，公开了一种计算逻辑的处理方法、电子设备和可读存储介质。本申请提供的计算逻辑的处理方法，用于包括服务器端和业务端的电子设备，该方法中业务端获取输入数据和配置数据并发送至服务器端，服务器端解析配置数据生成静态计算子图，再将输入数据与静态计算子图连接生成动态计算子图，最后执行动态计算子图得到计算结果，从而实现了计算逻辑与输入数据的解耦，能够实现计算逻辑的重用，提高软件开发人员的开发效率，另外，计算逻辑以独立方式进行实现、部署、管理和运行使得计算逻辑的实现错误与应用模块无关，从而提高了应用模块的可维护性。

Description

计算逻辑的处理方法、电子设备和可读存储介质

技术领域

本申请涉及金融软件领域，特别涉及一种计算逻辑的处理方法、电子设备和可读存储介质。

背景技术

当前，无论是在联机事务处理领域还是在大数据处理领域，数据处理过程用到的计算逻辑如计算过程、计算规则和计算公式等往往通过某种编程语言的编码实现，以编码形式实现计算逻辑对计算逻辑开发人员的要求较高，另外，不同的数据处理应用中相同的计算逻辑的实现多种多样，不利于数据处理应用的维护。

在保险业务领域中，有些组合计算逻辑比较复杂，例如其中包括多种计算逻辑如决策树计算、四则运算、聚合计算和计算条件规则等，组合计算逻辑的运算步骤也可能根据规则发生变化，甚至需要在组合计算逻辑的运算过程如创建新的保险产品中创建新的计算逻辑等，对这些复杂的组合计算逻辑进行编码存在开发难度大、工作效率低的问题。

发明内容

本申请实施例提供了一种计算逻辑的处理方法、电子设备和可读存储介质，用于解决现有技术下计算逻辑与应用模块紧耦合且需要通过编码实现的问题。

第一方面，本申请实施例提供了一种计算逻辑的处理方法，用于包括服务器端和业务端的电子设备，该方法包括：

业务端获取输入数据和配置数据并发送至服务器端，其中，输入数据用于描述执行计算逻辑所需的数据值，配置数据用于描述业务处理过程中计算逻辑的配置信息及计算逻辑之间的关联信息；

服务器端解析配置数据，生成静态计算子图，其中，静态计算子图以计算逻辑为节点，以计算逻辑之间的数据流动方向为边；

服务器端将输入数据与静态计算子图连接，生成动态计算子图；

服务器端执行动态计算子图，获得计算结果。

在上述第一方面的一种可能的实现中，服务器端解析配置数据，生成静态计算子图，包括：

服务器端对具有层次结构的计算逻辑进行串行化；

服务器端根据串行化结果生成静态计算子图。

在上述第一方面的一种可能的实现中，服务器端根据串行化结果生成静态计算子图，包括：

服务器端通过基于流的编程技术，根据串行化结果生成静态计算子图。

在上述第一方面的一种可能的实现中，服务器端将输入数据与静态计算子图连接，生成动态计算子图，包括：

服务器端根据静态计算子图中计算逻辑的数据参数，在输入数据中确定对应的数据值并将数据值连接到数据参数。

在上述第一方面的一种可能的实现中，服务器端执行动态计算子图，获得计算结果，包括：

服务器端执行动态计算子图，获得初步计算结果；根据配置数据中的格式化配置信息对初步计算结果进行格式化处理，得到格式化后的数据，作为计算结果。

在上述第一方面的一种可能的实现中，计算逻辑至少包括如下一种：计算表达式、扩展函数、变量、过滤器、决策树。

在上述第一方面的一种可能的实现中，输入数据的格式为JSON格式，配置数据通过YAML和DSL的组合进行描述。

第二方面，本申请实施例提供了一种电子设备，该电子设备包括：

存储器，用于存储由电子设备的一个或多个处理器执行的指令，以及

处理器，是电子设备的处理器之一，用于执行上述第一方面以及第一方面的各种可能实现中的任意一种计算逻辑的处理方法。

第三方面，本申请实施例提供了一种可读存储介质，可读存储介质上存储有指令，该指令在电子设备上执行时使电子设备执行上述第一方面以及第一方面的各种可能实现中的任意一种计算逻辑的处理方法。

第四方面，本申请实施例提供了一种计算机程序产品，包括计算机程序/指令，其特征在于，该计算机程序/指令被处理器执行时实现上述第一方面以及第一方面的各种可能实现中的任意一种计算逻辑的处理方法。

本申请实施例提供的计算逻辑的处理方法，用于包括服务器端和业务端的电子设备，该方法中业务端获取输入数据和配置数据并发送至服务器端，服务器端解析配置数据生成静态计算子图，再将输入数据与静态计算子图连接生成动态计算子图，最后执行动态计算子图得到计算结果，从而实现了计算逻辑与输入数据的解耦，能够实现计算逻辑的重用，提高软件开发人员的开发效率，另外，计算逻辑以独立方式进行实现、部署、管理和运行使得计算逻辑的实现错误与应用模块无关，从而提高了应用模块的可维护性。

附图说明

图1根据本申请的一些实施例，示出了一种计算逻辑的处理过程的场景示意图。

图2根据本申请的一些实施例，示出了一些计算逻辑的实例示意图。

图3根据本申请的一些实施例，示出了一种电子设备的硬件结构图。

图4根据本申请的一些实施例，示出了一种计算逻辑的处理方法的流程图。

图5根据本申请的一些实施例，示出了一种输入数据格式的示意图。

图6根据本申请的一些实施例，示出了一种计算保险费用的配置数据的实例示意图。

具体实施方式

本申请的说明性实施例包括但不限于计算逻辑的处理方法、电子设备和可读存储介质。

可以理解，如本文所使用的，术语“模块”可以指代或者包括专用集成电路(ASIC)、电子电路、执行一个或多个软件或固件程序的处理器(共享、专用、或群组)和/或存储器、组合逻辑电路、和/或提供所描述的功能的其他适当硬件组件，或者可以作为这些硬件组件的一部分。

可以理解，在本申请各实施例中，处理器可以是微处理器、数字信号处理器、微控制器等，和/或其任何组合。根据另一个方面，所述处理器可以是单核处理器，多核处理器等，和/或其任何组合。

可以理解，本申请的计算逻辑的处理方法适用于对由多种计算逻辑组成的计算逻辑流进行计算的场景。

下面将结合附图对本申请的实施例作进一步地详细描述。

图1根据本申请的一些实施例，提供了一种对由多种计算逻辑组成的计算逻辑流进行计算的场景。如图1所示，用户100将输入数据和配置数据提供给应用模块200，应用模块200接收输入数据和配置数据并发送给计算引擎300进行计算，计算引擎300将计算后得到的计算结果返回给应用模块200，应用模块200根据返回的计算结果进行后续处理或展示给用户100。

计算逻辑(Computational Logic，CL)是指业务应用中实现业务功能所需要的与计算相关的元素，可以包括但不限于计算过程、计算规则、计算公式等。具体来说，一些基本的计算逻辑例如计算表达式、扩展函数、变量、过滤器、决策树等。计算逻辑中通常包括数据参数，计算逻辑根据数据参数的赋值进行计算，得到具体的计算逻辑结果。

用户100可以是熟悉软件项目业务的人员，也可以是专业的软件开发人员，用户100将准备好的输入数据和配置数据提供给应用模块200。在此，输入数据是具体的数据值，用于作为计算逻辑中数据参数的赋值。配置数据用于配置包括多种计算逻辑的复杂业务处理过程，包括多种计算逻辑的相关配置信息和数据参数等，配置数据不包括用于计算逻辑的具体计算的数据值。配置数据与输入数据的分离可以实现计算逻辑与输入数据的解耦，从而能够实现业务处理过程的重用，避免重复开发相同的业务处理过程，提高软件开发人员的工作效率。

应用模块200用于获取用户100提供的输入数据和配置数据，获取方式可以采用多种方式，可以包括但不限于：以界面方式获取、以文件形式获取、根据用户选择获取等。例如，应用模块200可向用户100提供输入数据界面和配置数据界面，用户100在输入数据界面和配置数据界面中进行相关数据的输入，在用户100输入完毕后，输入数据界面和配置数据界面将用户输入数据提交给应用模块200；用户100也可以预先将输入数据和配置数据存储在数据文件中，将数据文件提交给应用模块200，应用模块200通过解析数据文件得到输入数据和配置数据；应用模块200可以向用户100提供多个预设的配置数据模板，并将用户100选择的配置数据模板或修改后的配置数据模板作为使用的配置数据。

应用模块200获取输入数据和配置数据之后，将输入数据和配置数据发送至计算引擎300进行计算。计算引擎300对多种计算逻辑进行了抽象处理，可以将输入数据代入配置数据中定义的计算逻辑中进行计算得到计算结果。计算引擎300处理的输入数据可以包括不同的数据结构，可以包括但不限于层次结构、列表结构等。

图2示出了计算引擎300可以支持的一些计算逻辑的实例，包括List(列表)、Item(列表项)、Filter(过滤器)、DTree(决策树)、Var(变量)、Expr(表达式)等，其中的表达式计算逻辑还可以包括max(最大值)、min(最小值)、sum(求和)、sumif(条件求和)、round(取整)等函数计算逻辑。用户100可以在配置数据中使用这些计算逻辑中的一个或多个，在使用多个计算逻辑的情况下，可在配置数据中将多个计算逻辑组织成计算逻辑流的形式。

最后，计算引擎300将计算逻辑的计算结果返回给应用模块200，由应用模块200进行后续处理。应用模块200可以将计算结果作为后续处理的输入数据，也可以直接向用户展示计算结果。

本申请技术方案提供的方法，在单独设置的计算引擎300上执行包括计算逻辑的配置数据与输入数据，实现了将原本分散在多个应用模块200中的计算逻辑集中到计算引擎300上执行，由计算引擎300统一实现计算逻辑的运算，软件开发人员无需在每个应用模块200中重复实现计算逻辑，从而减少了软件开发人员的工作量，提高了软件应用的开发效率；另外，由计算引擎300统一管理计算逻辑的实现和运行提高了软件应用的可维护性，在计算逻辑的实现存在错误的情况下，只需要在计算引擎300上修改即可将修改后的正确实现应用到多个应用模块200中，从而方便应用模块200的维护。

图3根据本申请的一些实施例，示出了一种用于实现计算逻辑的处理方法的电子设备30的硬件结构框图。在图2所示的实施例中，电子设备30可以包括一个或多个处理器301，与处理器301中的至少一个连接的系统控制逻辑302，与系统控制逻辑302连接的系统内存303，与系统控制逻辑302连接的非易失性存储器(Non-Volatile Memory,NVM)304，以及与系统控制逻辑302连接的网络接口306。

在一些实施例中，处理器301可以包括一个或多个单核或多核处理器。在一些实施例中，处理器301可以包括通用处理器和专用处理器(例如，图形处理器，应用处理器，基带处理器等)的任意组合。在电子设备30采用增强型基站(Evolved Node B，eNB)或无线接入网(Radio Access Network，RAN)控制器的实施例中，处理器301可以被配置为执行各种符合的实施例。例如，处理器301可以用于执行计算逻辑的处理方法。

在一些实施例中，系统控制逻辑302可以包括任意合适的接口控制器，以向处理器301中的至少一个和/或与系统控制逻辑302通信的任意合适的设备或组件提供任意合适的接口。

在一些实施例中，系统控制逻辑302可以包括一个或多个存储器控制器，以提供连接到系统内存303的接口。系统内存303可以用于加载以及存储数据和/或指令。例如，系统内存303可以加载本申请实施例中解析计算逻辑的指令，也可以保存输入数据和配置数据等。

在一些实施例中电子设备30的系统内存303可以包括任意合适的易失性存储器，例如合适的动态随机存取存储器(Dynamic Random Access Memory，DRAM)。

NVM存储器304可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性的计算机可读介质。在一些实施例中，NVM存储器304可以包括闪存等任意合适的非易失性存储器和/或任意合适的非易失性存储设备，例如硬盘驱动器(Hard Disk Drive，HDD)，光盘(Compact Disc，CD)驱动器，数字通用光盘(Digital Versatile Disc，DVD)驱动器中的至少一个。在本申请实施例中，NVM存储器304可以用于存储应用模块获取的输入数据和配置数据。

NVM存储器304可以包括安装电子设备30的装置上的一部分存储资源，或者它可以由设备访问，但不一定是设备的一部分。例如，可以经由网络接口306通过网络访问NVM存储器304。

特别地，系统内存303和NVM存储器304可以分别包括：指令305的暂时副本和永久副本。指令305可以包括：由处理器301中的至少一个执行时导致电子设备30实施如图3所示的方法的指令。在一些实施例中，指令305、硬件、固件和/或其软件组件可另外地/替代地置于系统控制逻辑302，网络接口306和/或处理器301中。

网络接口306可以包括收发器，用于为电子设备30提供无线电接口，进而通过一个或多个网络与任意其他合适的设备(如前端模块，天线等)进行通信。在一些实施例中，网络接口306可以集成于电子设备30的其他组件。例如，网络接口306可以集成于处理器301的，系统内存303，NVM存储器304，和具有指令的固件设备(未示出)中的至少一种，当处理器301中的至少一个执行所述指令时，电子设备30实现如方法实施例中示出的方法。在本申请实施例中，网络接口306可以用于接收应用模块发送的输入数据和配置数据。

网络接口306可以进一步包括任意合适的硬件和/或固件，以提供多输入多输出无线电接口。例如，网络接口306可以是网络适配器，无线网络适配器，电话调制解调器和/或无线调制解调器。

在一些实施例中，处理器301中的至少一个可以与用于系统控制逻辑302的一个或多个控制器的逻辑封装在一起，以形成系统封装(System In a Package，SiP)。在一些实施例中，处理器301中的至少一个可以与用于系统控制逻辑302的一个或多个控制器的逻辑集成在同一管芯上，以形成片上系统(System on Chip,SoC)。

电子设备30可以进一步包括：输入/输出(I/O)设备307。I/O设备307可以包括用户界面，使得用户能够与电子设备30进行交互；外围组件接口的设计使得外围组件也能够与电子设备30交互。

可以理解的是，图3示意的结构并不构成对电子设备30的具体限定。在本申请另外一些实施例中电子设备30可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以由硬件或软件，或软件和硬件的组合实现。

下面结合上述图3所示的结构，根据图4并结合具体场景，详细介绍本申请的技术方案。如图3所示，本申请的一些实施例中计算逻辑的处理方法的技术方案包括：

S401：业务端向服务器端提供输入数据和配置数据。

业务端用于获取用于进行计算逻辑运算的输入数据和配置数据，业务端可以是软件应用中的模块或组件。服务器端用于接收业务端发送的输入数据和配置数据，并根据输入数据和配置数据进行相应计算逻辑的运算，得到计算结果。服务器端和业务端对应的硬件设备可以为电子设备30。

本申请的一些实施例中，用户100可以同时向业务端提供输入数据和对应的配置数据，也可以只向业务端提供输入数据，配置数据由业务端生成。在此，业务端可采用多种方式来生成配置数据，例如，业务端可直接使用预先开发的配置数据模板来生成配置数据，也可以根据用户100对配置数据模板的修改结果来生成配置数据等。

另外，业务端可以向用户100提供相应的输入界面和配置界面，方便用户100进行相关数据的输入。输入界面和配置界面可以是图形化的界面，还可以为相关数据的输入过程提供图形化的引导过程，引导用户100完成输入数据和配置数据的输入，减少输入过程中发生错误的可能性。

本申请的一些实施例中，输入数据的格式可以有多种形式，可以包括但不限于：XML格式、JSON格式等。业务端在接收用户100提供的输入数据后，可以将输入数据转换为业务端中使用的统一数据格式，例如用户100提供的输入数据的格式为XML格式，业务端可将输入数据由XML格式转换为JSON格式；业务端也可以直接使用输入数据的格式，例如用户100提供的输入数据的格式为JSON格式，业务端可以直接使用JSON格式的输入数据。

图5示出了本申请的一些实施例中输入数据的格式示例。如图5所示，[key]表示输入数据中一个具体数据参数的名称，数据参数的名称可以使用任意字符串来描述，例如一个数据参数的名称为“username”。在此，数据参数与配置数据中同名的数据参数相对应，输入数据中数据参数对应的数据值用于在计算逻辑的运算过程中给配置数据中的同名参数进行赋值。[value]表示数据参数对应的数据值，该数据值可以为任意字符或数字组成的字符串。

输入数据中可以定义多个数据参数及对应的数据值，图中以“…”：“…”形式表示。items是输入数据中的关键字，用于描述输入数据中以层次结构组织的数据。items中的[id]表示一个item的唯一标识，可以通过唯一标识来确定对应的item，该唯一标识可以是由任意字符或数字所组成的字符串。items中的[key]、[value]的含义与上述含义基本相同，不同之处在于作用的范围不同，items中的[key]、[value]只在items的范围内使用，而上述[key]、[value]在输入数据的整个范围内使用。

配置数据同样可以使用多种形式来进行表示，例如使用XML格式、JSON格式等。为方便描述计算逻辑及相应的计算图，本申请的一些实施例中，配置数据以YAML并结合DSL的形式进行描述。YAML语言是一种以数据为中心的配置文件语言，实质上提供了一种通用的数据串行化格式，非常方便人类进行数据的读写。YAML可以支持三种数据结构，包括对象、数组和标量，对象是键值对的集合，数组是一组按次序排列的值，标量是单个、不可再分的值。YAML语言的基本语法规则包括：大小写敏感、使用缩进表示层级关系、缩进时不允许使用Tab键，只允许使用空格、缩进的空格数目不重要，只要相同层级的元素左侧对齐即可等。

领域专用语言(Domain Specified Language，DSL)指的是专注于某个业务领域的计算机语言，只能用在某些特定的业务领域，例如金融、保险领域等。DSL能够让业务领域专家以简单的编程方式描述业务领域中所有的业务活动和业务规则，从而能够提高软件代码的可读性，让软件开发人员和业务领域专家更好的交流。

本申请实施例中通过结合YAML和DSL的方式对配置数据进行设置，为金融、保险领域的配置数据设置提供了简单的语法特性，易于学习掌握，降低了用户100的学习曲线，提高了用户100开发配置数据的效率。

图6示出了本申请的一些实施例中用于计算保险费用的配置数据的示例。如图6所示，app用于描述配置数据对应的名称即“policy premium calculation”，配置数据的名称通常用于支持计算逻辑运算过程的可视化。main关键字紧跟app关键字之后，用于指明计算逻辑的运算过程开始。计算逻辑的运算过程可以包括多个计算步骤，计算步骤使用steps关键字进行定义。计算步骤中可以包括多种计算逻辑，如图中的计算逻辑list。计算逻辑有对应的名称，本申请的一些实施例中，计算逻辑的名称可以显式给出，也可以隐式给出，例如图中的计算逻辑list的名称通过“name:policies”显示给出，而图中计算逻辑var的名称没有直接给出，而是以隐式方式给出。类似地，计算逻辑的名称同样可以用于支持计算逻辑运算过程的可视化。

本申请的一些实施例中，计算逻辑还可以包括子计算逻辑，通过子计算逻辑对该计算逻辑的输出数据进行后续处理。如图6所示，计算逻辑list中包括子计算逻辑item，item可以对list的输出数据进行处理。另外，计算逻辑list中可包括多个子计算逻辑item，各个item可以并行执行以提高执行效率。在此，为了指定参与并行计算的item，可通过filters关键字来进行条件过滤，满足过滤条件的item可执行相应计算。图6中的过滤器的名称为“calc own damage part”，过滤条件是item下的数据参数code是否等于预定义的值OD_COMP，code是在输入数据中定义的数据参数，在满足过滤条件即code的值为OD_COMP的情况下，执行名称为“own damage part”的动态计算图。

动态计算图使用graphs关键字来定义，动态计算图中定义了多种用于完成保险费用计算的计算逻辑，包括var、decisiontree和expr，expr中还使用了计算逻辑round。根据图中内容可知，一种保险费用计算的过程包括保险费率的计算和保险费用的计算，保险费率的计算通过计算逻辑decisiontree来完成，保险费用的计算通过计算逻辑expr来完成。计算逻辑decisiontree对应的值SumInsuredRate是对外部数据源中定义数据的引用名称。外部数据源例如可以是Excel文件，Excel文件中定义了对保险费率计算的多种计算公式和相应数据，每种计算公式和对应的结果数据提供对应的引用名称供外部访问。

本申请的一些实施例中，配置数据中既可以包括与计算逻辑的运算过程相关的运算配置，也可以包括与具体计算逻辑对应的特定配置。特定配置只与某些特定的计算逻辑对应，其它的计算逻辑中不对应特定配置。例如，对于计算逻辑decisiontree来说，常见的配置方式包括通过Excel文件来进行配置，Excel文件的内容需要包括有构建决策树所需的特定配置，而计算逻辑expr并不存在构建决策树的特定配置。

S402：服务器端解析配置数据，构建静态计算子图。

服务器端接收到业务端发送的配置数据后，对配置数据进行解析，根据解析结果构建静态计算子图。

本申请的一些实施例中，服务器端对配置数据的解析包括对配置数据中具有层次结构的计算逻辑进行串行化，再根据串行化结果构建静态计算子图。这里的串行化是指将具有层次结构的计算逻辑转变为具有序列结构的计算逻辑。例如，具有层次结构的计算逻辑list可包括多个步骤(step)，其中一个步骤(step)包括item计算逻辑，服务器段对配置数据进行解析后，计算逻辑list和item可被串行化为一个有序的数组(即实际的运算次序)。串行化后得到的数组通过基于流的编程技术(Flow-based Programming，FBP)构建静态计算子图。基于流的编程是一种数据流编程范式，是基于组件的软件工程方法的一种。基于流的编程将软件应用看成一组进程(Process)，进程间通过连接进行通信，进程通过端口(Port)来访问连接，这种方式类似通过计算机网络进行通信。基于流的编程通过使用不同的组件来转换数据，组件本质上是封装的模块或函数，数据流由进程间通信系统负责在组件间传递。基于流的编程中软件应用表示为一个有向图，其中进程作为有向图的节点，进程间的连接作为有向图的边。

在此，静态计算子图是以计算逻辑为节点，计算逻辑之间的数据流动方向为边的有向图。静态计算子图并不是最终的计算链路，其中缺少一些信息。例如，要对计算逻辑item进行并行计算，需要知道item对应的输入数据，而配置数据中并不包括输入数据。又如，要通过过滤器filter来执行计算图graph，需要知道graph对应的输入数据中是否包括数据参数code，并且code的数据值是否等于预设值OD_COMP。

S403：服务器端将输入数据与静态计算子图进行连接，确定计算链路。

服务器端得到静态计算子图后，将输入数据连接到静态计算子图，从而得到包括完整信息的动态计算子图，即计算链路。在此，将输入数据连接到静态计算子图是指将静态计算子图中需要具体数据的地方与输入数据中的正确数据进行对应。例如，静态计算子图中某个数据参数需要具体的数据值，因此将输入数据中通过该数据参数名称指定的数据对应到静态计算子图中该数据参数的位置。

正确数据的传入由静态计算子图中计算逻辑来完成。例如，计算逻辑item可根据计算逻辑items的数量创建相应数量的协程(goroutine)，并完成与item对应的静态计算子图的连接。又如，计算逻辑filter可通过判断输入数据中数据参数的数据值是否满足过滤条件，再决定是将数据值传递到静态计算子图中下一个节点还是连接到对应的静态计算子图。

服务器端得到的动态计算子图中的节点包括一个输入端口和一个输出端口，节点通过输入端口接收上一个节点的输出数据，并通过输出端口输出本节点的计算逻辑运算完成后的计算结果到下一个节点，从而在节点之间实现数据的流动。

S404：服务器端执行计算链路，确定计算结果。

服务器端在得到动态计算子图即计算链路后，由于动态计算子图已经具备了完整信息，图中计算逻辑有对应的输入数据，因此服务器端可以按动态计算子图中的节点方向依次执行节点中的计算逻辑，在动态计算子图的所有节点都执行完毕后，得到最终的计算结果。

S405：服务器端将计算结果返回给业务端。

在此，服务器端将计算结果返回给业务端，可以直接将计算结果返回给业务端，也可以对计算结果进行一定的处理后返回给业务端。本申请的一些实施例中，服务器端可以对计算结果进行格式化处理后再返回给业务端。具体来说，配置数据中可包括计算结果的格式化配置信息，服务器端可根据配置数据中的格式化配置信息对计算结果进行格式化处理。格式化处理例如可以包括移除计算结果中的中间数据、转换计算结果中数据参数的名称等。

本申请的实施例中，业务端将输入数据和配置数据共同提供给服务器端，在输入数据的数据组织结构、数据参数名称等与配置数据中计算逻辑对应的特定配置符合相应约束的情况下，服务器端上运行的计算逻辑处理过程类似无状态应用，从而非常适合无服务器架构模式(serverless)下的部署。

本申请公开的机制的各实施例可以被实现在硬件、软件、固件或这些实现方法的组合中。本申请的实施例可实现为在可编程系统上执行的计算机程序或程序代码，该可编程系统包括至少一个处理器、存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备以及至少一个输出设备。

可将程序代码应用于输入指令，以执行本申请描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本申请的目的，处理系统包括具有诸如例如数字信号处理器(Digital Signal Processor，DSP)、微控制器、专用集成电路(Application Specific Integrated Circuit，ASIC)或微处理器之类的处理器的任何系统。

程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本申请中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。

在一些情况下，所公开的实施例可以以硬件、固件、软件或其任何组合来实现。所公开的实施例还可以被实现为由一个或多个暂时或非暂时性机器可读(例如，计算机可读)存储介质承载或存储在其上的指令，其可以由一个或多个处理器读取和执行。例如，指令可以通过网络或通过其他计算机可读介质分发。因此，机器可读介质可以包括用于以机器(例如，计算机)可读的形式存储或传输信息的任何机制，包括但不限于，软盘、光盘、光碟、只读存储器(CD-ROMs)、磁光盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、可擦除可编程只读存储器(Erasable Programmable Read OnlyMemory，EPROM)、电可擦除可编程只读存储器(Electrically Erasable ProgrammableRead-Only Memory，EEPROM)、磁卡或光卡、闪存、或用于利用因特网以电、光、声或其他形式的传播信号来传输信息(例如，载波、红外信号数字信号等)的有形的机器可读存储器。因此，机器可读介质包括适合于以机器(例如计算机)可读的形式存储或传输电子指令或信息的任何类型的机器可读介质。

在附图中，可以以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可能不需要这样的特定布置和/或排序。而是，在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外，在特定图中包括结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。

需要说明的是，本申请各设备实施例中提到的各单元/模块都是逻辑单元/模块，在物理上，一个逻辑单元/模块可以是一个物理单元/模块，也可以是一个物理单元/模块的一部分，还可以以多个物理单元/模块的组合实现，这些逻辑单元/模块本身的物理实现方式并不是最重要的，这些逻辑单元/模块所实现的功能的组合才是解决本申请所提出的技术问题的关键。此外，为了突出本申请的创新部分，本申请上述各设备实施例并没有将与解决本申请所提出的技术问题关系不太密切的单元/模块引入，这并不表明上述设备实施例并不存在其它的单元/模块。

需要说明的是，在本专利的示例和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

虽然通过参照本申请的某些优选实施例，已经对本申请进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (10)

1.一种计算逻辑的处理方法，用于包括服务器端和业务端的电子设备，其特征在于，包括：

所述业务端获取输入数据和配置数据并发送至服务器端，其中，所述输入数据用于描述执行计算逻辑所需的数据值，所述配置数据用于描述业务处理过程中所述计算逻辑的配置信息及所述计算逻辑之间的关联信息；

所述服务器端解析所述配置数据，生成静态计算子图，其中，所述静态计算子图以所述计算逻辑为节点，以所述计算逻辑之间的数据流动方向为边；

所述服务器端将输入数据与静态计算子图连接，生成动态计算子图；

所述服务器端执行所述动态计算子图，获得计算结果。

2.根据权利要求1所述的方法，其特征在于，所述服务器端解析所述配置数据，生成静态计算子图，包括：

所述服务器端对具有层次结构的计算逻辑进行串行化；

所述服务器端根据串行化结果生成静态计算子图。

3.根据权利要求2所述的方法，其特征在于，所述服务器端根据串行化结果生成静态计算子图，包括：

所述服务器端通过基于流的编程技术，根据串行化结果生成静态计算子图。

4.根据权利要求1所述的方法，其特征在于，所述服务器端将输入数据与静态计算子图连接，生成动态计算子图，包括：

所述服务器端根据所述静态计算子图中计算逻辑的数据参数，在所述输入数据中确定对应的数据值并将所述数据值连接到所述数据参数。

5.根据权利要求1所述的方法，其特征在于，所述服务器端执行所述动态计算子图，获得计算结果，包括：

所述服务器端执行所述动态计算子图，获得初步计算结果；根据所述配置数据中的格式化配置信息对所述初步计算结果进行格式化处理，得到格式化后的数据，作为所述计算结果。

6.根据权利要求1所述的方法，其特征在于，所述计算逻辑至少包括如下一种：计算表达式、扩展函数、变量、过滤器、决策树。

7.根据权利要求1所述的方法，其特征在于，所述输入数据的格式为JSON格式，所述配置数据通过YAML和DSL的组合进行描述。

8.一种电子设备，其特征在于，包括：

存储器，用于存储由电子设备的一个或多个处理器执行的指令，以及

处理器，是电子设备的处理器之一，用于执行权利要求1-7中任一项所述的计算逻辑的处理方法。

9.一种可读存储介质，其特征在于，所述可读存储介质上存储有指令，该指令在电子设备上执行时使电子设备执行权利要求1-7中任一项所述的计算逻辑的处理方法。

10.一种计算机程序产品，包括计算机程序/指令，其特征在于，该计算机程序/指令被处理器执行时实现权利要求1-7中任一项所述的计算逻辑的处理方法。

Images