CN116107549A - 逻辑编排和变更业务逻辑处理方法、系统及存储介质 - Google Patents

Abstract

本申请提供一种逻辑编排和变更业务逻辑处理方法、系统及存储介质，涉及计算机领域；该逻辑编排方法包括根据目标物料，生成多个处理器逻辑元；其中，目标物料包括目标业务对应的本地变量和在线代码；根据目标业务和多个处理器逻辑元，对多个处理器逻辑元进行线性编排，以获得处理器编排结果；根据处理器编排结果，生成逻辑元列表。该变更业务逻辑处理方法使用该逻辑编排方法生成的逻辑元列表，处理变更的业务。使用本申请实施例提供的逻辑编排和变更业务逻辑处理方法，能够快速响应业务变更，敏捷友好，能够极大程度提高开发效率。

Description

逻辑编排和变更业务逻辑处理方法、系统及存储介质

技术领域

本申请涉及计算机领域，具体而言，涉及一种逻辑编排和变更业务逻辑处理方法、系统及存储介质。

背景技术

Node.js是一个基于Chrome V8引擎的JavaScript运行环境。随着互联网技术的飞速发展，Web的功能复杂性日益提高，前后端分离已经成为主流；而Node.js的出现，进一步促进了前后端分离。Node.js使用事件驱动，非阻塞I/O模型而得以轻量和高效，非常适合在分布式设备上运行数据密集型的实时应用。

目前，前端人员往往既要做页面渲染，又要写复杂的逻辑；而简单的Node开发整个构建、部署和发布的流程耗时长，开发效率低；对于发生变更的业务的响应能力弱，无法高效地处理变更的业务。

发明内容

本申请实施例的目的在于提供一种逻辑编排和变更业务逻辑处理方法、系统及存储介质，该业务逻辑编排方法能够实现原子化开发，能够适应复杂业务的未来需求，可持续对复杂程度日益增长的业务逻辑进行完整、快速地配置。该变更业务逻辑处理方法在该逻辑编排方法的基础上，实现无需服务重新发版或者本地代码修改，便可对原服务新增接口或者处理接口数据，提高开发灵活性和响应效率。

第一方面，本申请实施例提供一种逻辑编排方法，方法包括：根据目标物料，生成多个处理器逻辑元；其中，目标物料包括目标业务对应的本地变量和在线代码；根据目标业务和多个处理器逻辑元，对多个处理器逻辑元进行线性编排，以获得处理器编排结果；根据处理器编排结果，生成逻辑元列表。

在上述实现过程中，本申请实施例提供的逻辑编排方法，根据目标物料生成处理器逻辑元之后，对处理器逻辑元进行编排；进一步地，根据编排后的逻辑元得到逻辑元列表；由此可知，通过该逻辑编排方法能够实现代码动态管理；通过原子化代码片段，根据不同场景，配置组装代码，提高了服务物料复用能力及灵活性；并且通过将组装后的代码逻辑版本化和发布规范化，提高服务稳定性及安全性。

可选地，在本申请实施例中，根据目标物料，生成多个处理器逻辑元，包括：根据目标物料，进行可视化变编排和/或源码编排，生成多个处理器逻辑元。

在上述实现过程中，在本申请实施例中根据目标物料生成多个处理器逻辑元的过程中，进行逻辑编排的方式有三种，分别是源码编排、可视化编排、源码编排和可视化编排结合；提供三种可选的方法能够面向不同能力的业务文员，提高业务开发的效率。

可选地，在本申请实施例中，根据目标业务和多个处理器逻辑元，对多个处理器逻辑元进行线性编排，以获得处理器编排结果，包括：根据目标业务的逻辑顺序，对多个处理器逻辑元进行线性编排，以获得线性编排结果。

在上述实现过程中，由于路由入参的不同，可能或存在多种逻辑分支，每个逻辑分支都可以自由选择需要的处理器；从而实现了处理器逻辑编排，将每个逻辑分支匹配对应的处理器；因此，本申请实施例提供的逻辑编排方法，能够根据业务需求，适应多种不同的场景。

可选地，在本申请实施例中，根据处理器编排结果，生成逻辑元列表，包括：基于线性编排结果，根据目标业务，对处理器逻辑元进行场景设置，并调试多个线性编排逻辑元，以获得逻辑元列表。

在上述实现过程中，对于进行处理器编排后的处理器编排结果中的处理器逻辑元，进行场景设置和/或监控埋点；进一步地，生成的逻辑元进行调试，具体地，调试的方法可以用Mock、映射和测试用例等。因此，使用本申请实施例提供的逻辑编排方法能够对生产的逻辑元进行编辑和调试，使最终的逻辑元列表中的逻辑元是性能良好的，能够保证业务的顺利进行。

可选地，在本申请实施例中，在根据处理器编排结果，生成逻辑元列表之后，方法还包括：将逻辑元列表中的多个处理器逻辑元转化为多段目标代码；其中，多段目标代码对应多个目标版本；激活目标业务对应的目标版本；判断目标业务是否对应多个应用实例版本；其中，应用实例版本包括目标版本；若判定目标业务对应多个应用实例版本，则控制目标业务流量进行灰度发布。

在上述实现过程中，本申请实施例提供的逻辑编排方法在根据处理器编排结果生成逻辑元列表之后，将逻辑元列表中的多个处理器逻辑元转换为多段目标代码；进一步地，激活目标业务对应的目标版本，该逻辑业务编排方法还支持版本的灰度发布和回滚，能够有效地对版本进行管理；通过将组装后的代码逻辑版本化和发布规范化，提高服务稳定性及安全性。

第二方面，本申请实施例提供一种变更业务逻辑处理方法，方法包括：对当前业务流程引入流程编排工具包；对业务接口进行路由拦截，并判断业务接口对应的目标业务是否发生变更；若判定目标业务发生变更，则使用流程编排工具包，根据变更业务和逻辑元列表，处理变更业务；其中，逻辑元列表的生成方法包括本申请第一方面提供的任一的方法。

在上述实现过程中，本申请实施例提供的变更业务逻辑处理方法，通过对当前业务流程引入流程编排工具包；对业务接口进行路由拦截，并判断业务接口对应的业务是否发生了变更；在目标业务发生变更的情况下，使用流程编排工具包根据变更业务和逻辑元列表处理该变更业务。本申请实施例提供的变更业务处理方法，通过在线可视化编排Node逻辑来控制业务侧Node的处理流程，能够进行统一高效管理。这种方式接入成本低，侵入小，上手快；去中心化，更好的容灾；天然热更新，线上代码秒级更新；适应了复杂业务的未来需求，可持续对复杂程度日益增长的业务逻辑进行完整、快速地配置。

可选地，在本申请实施例中，根据变更业务和逻辑元列表，处理变更业务，包括：判断变更业务对应的请求逻辑是否为动态逻辑；若判定变更业务对应的请求逻辑为动态逻辑，则根据请求逻辑和逻辑元列表，处理变更业务。

在上述实现过程中，当判定业务发生变更之后，判断变更业务对应的请求逻辑是否为动态逻辑；如果是动态逻辑，就根据该请求逻辑和逻辑元列表来处理该变更业务；如果不是动态逻辑，就根据本地逻辑进行处理；因此，使用本申请提供的变更业务处理方法能够及时迅速地响应业务变更。

可选地，在本申请实施例中，根据动态逻辑和逻辑元列表，处理变更业务，包括：判断请求逻辑是否满足动态逻辑准入条件；若判定请求逻辑满足动态逻辑准入条件，则将请求逻辑与逻辑元列表进行匹配，并获得逻辑元匹配结果；根据逻辑元匹配结果，处理变更业务。

在上述实现过程中，在本申请实施例提供的变更业务处理方法中判定请求逻辑是否满足逻辑动态逻辑准入条件，如果请求逻辑元满足动态逻辑准入条件，那么将请求逻辑和逻辑元列表进行匹配，并获得逻辑元匹配结果；进一步地，根据逻辑元匹配结果处理该变更业务。也就是说，本申请实施例提供的变更业务处理方法，能够通过逻辑元的匹配来处理变更的业务，不用对整个接口的逻辑全部重新构建发布，能够准确、高效地响应业务的变更。

可选地，在本申请实施例中，根据逻辑元匹配结果，处理变更业务，包括：判断匹配结果是否为逻辑元列表中包括请求逻辑对应的请求逻辑元；若判定匹配结果为逻辑元列表中包括请求逻辑元，则从逻辑元列表中获取请求逻辑元；对请求逻辑元进行分支匹配，并在沙箱中执行请求逻辑元，获得执行结果。

在上述实现过程中，当判定匹配结果是逻辑元列表中包括该请求逻辑对应的请求逻辑元，就从逻辑元列表中获取对应的请求逻辑元；进一步地，通过独立沙箱环境执行动态逻辑片段；因此。使用本申请实施例提供的变更业务处理方法能够实现无侵入式接入，引入SDK之后，数据和代码片段通过沙箱执行，仅对现有逻辑进行扩展，不会对项目造成污染。

可选地，在本申请实施例中，该方法还包括：若判定匹配结果为逻辑元列表中不包括请求逻辑元，则返回默认接口数据至本地逻辑；

根据本地逻辑处理变更业务，并进行异常提示。

在上述实现过程中，当匹配结果是逻辑元列表中不包括对应的请求逻辑元时，就进行兜底或异常处理；具体地，当逻辑元列表不包括对应的请求逻辑时，返回默认的接口数据传到本地逻辑，或抛出错误，或进行异常记录；本申请实施例提供的变更业务逻辑处理方法，提供的完备的异常处理措施，保证业务正常进行。

第三方面，本申请实施例提供一种逻辑编排系统，逻辑编排系统包括：逻辑元生成模块、逻辑编排模块和逻辑元列表生成模块；逻辑元生成模块用于根据目标物料，生成多个处理器逻辑元；其中，目标物料包括目标业务对应的本地变量和在线代码；逻辑编排模块用于根据目标业务和多个处理器逻辑元，对多个处理器逻辑元进行线性编排，以获得处理器编排结果；逻辑元列表生成模块用于根据处理器编排结果，生成逻辑元列表。

第四方面，本申请实施例提供一种变更业务逻辑处理系统，变更业务逻辑处理系统包括：工具包引入模块、业务变更判断模块和业务处理模块；工具包引入模块用于对当前业务流程引入流程编排工具包；业务变更判断模块用于对业务接口进行路由拦截，并判断业务接口对应的目标业务是否发生变更；业务处理模块用于在判定目标业务发生变更时，使用流程编排工具包，根据变更业务和逻辑元列表，处理变更业务；其中，逻辑元列表通过本申请第三方面提供的逻辑编排系统获取。

第五方面，本申请实施例提供一种电子设备，所述电子设备包括存储器和处理器，所述存储器中存储有程序指令，所述处理器读取并运行所述程序指令时，执行上述第一方面和第二方面任一实现方式中的步骤。

第六方面，本申请实施例还提供一种计算机可读存储介质，所述可读取存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行上述第一方面和第二方面任一实现方式中的步骤。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的逻辑编排的第一流程图；

图2为本申请实施例提供的版本发布流程图；

图3为本申请实施例提供的逻辑编排的第二流程图；

图4为本申请实施例提供的变更业务逻辑处理的第一流程图；

图5为本申请实施例提供的变更业务逻辑处理的第二流程图；

图6为本申请实施例提供的变更业务逻辑处理的第三流程图；

图7为本申请实施例提供的变更业务逻辑处理的第四流程图；

图8为本申请实施例提供的业务处理示意图；

图9为本申请实施例提供的业务处理整体流程图；

图10为本申请实施例提供的逻辑编排系统的模块示意图；

图11为本申请实施例提供的变更业务逻辑处理系统的模块示意图；

图12为本申请实施例提供的电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。例如，附图中的流程图和框图显示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。另外，在本发明各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

申请人在研究过程中发现，前端人员往往既要做页面渲染，又要写复杂的逻辑；而前端需要关注例如机器运维、性能、稳定性、登录鉴权等领域，因此，因此繁杂的逻辑编写给前端工作人员带来了较大的工作量。并且目前使用的简单Node开发，在应用的构建、部署和发布整个流程中，耗时较长，导致开发效率降低。另一方面，目前使用Node进行的应用开发中使用的Node代码的复杂度不高，模板多，导致开发过程变成机械化的重复，开发流程不能高效、灵活响应业务的变更。

基于此，本申请提供一种业逻辑编排和变更业务逻辑处理方法、系统及存储介质；其中，该业务逻辑编排方法能够实现原子化开发，能够适应复杂业务的未来需求，可持续对复杂程度日益增长的业务逻辑进行完整、快速地配置。该变更业务逻辑处理方法在该逻辑编排方法的基础上，实现无需服务重新发版或者本地代码修改，便可对原服务新增接口或者处理接口数据，提高开发灵活性和响应效率。

请参看图1，图1为本申请实施例提供的逻辑编排的第一流程图；该逻辑编排方法包括：

步骤S100：根据目标物料，生成多个处理器逻辑元。

在上述步骤S100中，根据目标物料生成多个处理器逻辑元；具体地，获取逻辑编排需要的物料，在目标物料的基础上进行处理器逻辑编写。其中，目标物料可以包括目标业务对应的本地变量和在线代码；可以理解的是，其中，本地变量可以是本地的环境变量等；在线代码可以从在线代码库或由工作人员输入，从而得到上述的在线代码。

应理解，在进行逻辑编排的过程中需要使用到处理器函数，该函数需要支持使用路由生命周期CTX、请求参数、业务Node本地原子方法和上一个在线函数的处理结果等。在此过程中，可以根据需要添加业务逻辑，并且与上下游处理器串联起来，形成一个完整的逻辑链。

步骤S101：根据目标业务和多个处理器逻辑元，对多个处理器逻辑元进行线性编排，以获得处理器编排结果。

在上述步骤S101中，在得到处理器逻辑元之后，根据目标业务和处理器逻辑元对处理器逻辑元进行线性编排，从而获得处理器编排结果。

需要说明的是，对处理器逻辑元进行线性编排的原因在于，根据路由入参的不同，可能会有多种逻辑分支，每个逻辑分支可以自由选择需要的处理器。因此，处理器编排主要是可视化管理Node路由各种逻辑分支所需要的处理器；最终通过JSON的方式，存储分支和对应的处理器引用ID。

步骤S102：根据处理器编排结果，生成逻辑元列表。

在上述步骤S102中，进一步地，对处理器编排结果进行处理得到逻辑元列表，可以将逻辑元列表理解为可以被业务Node逻辑中间件消费的逻辑块。

通过图1可知，本申请实施例提供的逻辑编排方法，根据目标物料生成处理器逻辑元之后，对处理器逻辑元进行编排；进一步地，根据编排后的逻辑元得到逻辑元列表；由此可知，通过该逻辑编排方法能够实现代码动态管理；通过原子化代码片段，根据不同场景，配置组装代码，提高了服务物料复用能力及灵活性；并且通过将组装后的代码逻辑版本化和发布规范化，提高服务稳定性及安全性。

在一可选地实施例中，根据目标物料，生成多个处理器逻辑元，包括：根据目标物料，进行可视化变编排和/或源码编排，生成多个处理器逻辑元。

在进行处理器逻辑元编辑时，可使用的方法有源码编排、可视化编排、源码编排和可视化编排；需要说明的是，源码编排是针对专业人员可使用的一种逻辑编辑形式，可视化编排是针对非专业人员使用的逻辑编辑形式，而使用可视化编排和源码编排两种方式结合进行逻辑元编辑。因此，存在源码编排和可视化编排两种方式能够满足不同能力的业务人员。

由此可知，在本申请实施例中根据目标物料生成多个处理器逻辑元的过程中，进行逻辑编排的方式有三种，分别是源码编排、可视化编排、源码编排和可视化编排结合；提供三种可选的方法能够面向不同能力的业务文员，提高业务开发的效率。

在一可选地实施例中，根据目标业务和多个处理器逻辑元，对多个处理器逻辑元进行线性编排，以获得处理器编排结果，包括：根据目标业务的逻辑顺序，对多个处理器逻辑元进行线性编排，获得线性编排结果。

在进行逻辑编排之后，根据业务形态，需要在路由配置中，编排处理器。处理器编排主要是可视化管理Node路由各种逻辑分支所需要的处理器。根据路由入参的不同，可能会有多种逻辑分支，每个逻辑分支可以自由选择需要的处理器。最终通过JSON的方式，存储分支和对应的处理器引用ID。

由此可知，由于路由入参的不同，可能或存在多种逻辑分支，每个逻辑分支都可以自由选择需要的处理器；从而实现了处理器逻辑编排，将每个逻辑分支匹配对应的处理器；因此，本申请实施例提供的逻辑编排方法，能够根据业务需求，适应多种不同的场景。

在一可选地实施例中，根据处理器编排结果，生成逻辑元列表，可以包括：基于线性编排结果，根据目标业务，对处理器逻辑元进行场景设置，并调试多个线性编排逻辑元，以获得逻辑元列表。

在上述实现过程中，在对处理器逻辑进行逻辑编排，得到逻辑编排结果之后，对逻辑编排结果进行进一步处理，得到逻辑元列表。为了得到逻辑元列表，对线性编排后的逻辑元列表中的处理器逻辑元进行场景设置，调试，而后得到逻辑元列表。

需要说明的是，在对逻辑元进行线性编排、场景设置等编辑行为时，也可以对逻辑元进行监控埋点；可以通过埋点获取：访问次数（UV/PV）、地域数据（IP）、在线时长、区域点击次数等数据。当这些单点数据按照特定的纬度进行数据聚合，就可以获得全流程视角下的数据如：用户留存率/流转率、用户转化率、用户访问深度等数据。而在埋点数据进行上报的同时，也可以同步收集页面基础数据/接口相关数据如：页面加载/渲染时长、页面异常、请求接口等数据。同时对于前端监控来说，大致可以分成三个方向：数据监控、性能监控、异常监控。因此，对逻辑元进行监控埋点，可以大概反映前端性能的好坏，根据性能监测的结果可以进一步的去优化前端性能。

而对于逻辑元的调试可以包括Mock、映射和测试用例；其中，使用Mock对逻辑元进行测试可以避免开发模块之间的耦合，也可以使用具有较好通用性的逻辑单元映射单元进行测试，或使用测试用例进行测试。通过Mock、映射和测试用例中的任意一种方式对逻辑元进行调试，从而获得最终的逻辑元列表。

由此可知，对于进行处理器编排后的处理器编排结果中的处理器逻辑元，进行场景设置和/或监控埋点；进一步地，生成的逻辑元进行调试，具体地，调试的方法可以用Mock、映射和测试用例等。因此，使用本申请实施例提供的逻辑编排方法能够对生产的逻辑元进行编辑和调试，使最终的逻辑元列表中的逻辑元是性能良好的，能够保证业务的顺利进行。

请参看图2，图2为本申请实施例提供的版本发布流程图；在本申请实施例的可选实施方式中，在根据处理器编排结果，生成逻辑元列表之后，该逻辑编排方法还包括：

步骤S200：将逻辑元列表中的多个处理器逻辑元转化为多段目标代码。

在上述步骤S200中，将得到的逻辑元列表中的多个处理器逻辑元转化为多段目标代码；其中，多段目标代码对应多个目标版本。其原因在于，经过处理器编排之后，得到的JSON是基于处理器和分支的引用关系，不能直接运行，而且没有版本控制。经过发布操作，可以将JSON转化为含有可执行JS代码的DSL，可以被业务Node逻辑中间件消费。

步骤S201：激活目标业务对应的目标版本。

在上述步骤S201中，在进行格式转化之后，根据目标业务激活对应的目标版本。

步骤S202：判断目标业务是否对应多个应用实例版本。

在上述步骤S202中，判断目标业务是否对应多个应用实例版本，一般来说，目标业务可能对应着新旧版本，可能部分版本没有完成更新迭代，可能出现多个应用实例版本。

步骤S203：若判定目标业务对应多个应用实例版本，则控制目标业务流量进行灰度发布。

在上述步骤S203中，如果判定目标业务对应着多个应用实例版本，那么就控制目标业务流量进行灰度发布。

为了更好的理灰度发布，以AB test进行说明，AB test就是一种灰度发布方式，指为产品已发布A版本，在发布B版本时，在同一时间维度，让一部分用户继续用A版本，一部分用户开始用B版本，如果用户对B版本没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B版本上面来。灰度发布可以保证整体系统的稳定，在初始灰度发布时就可以发现及调整问题，以保证其影响度。

示例性地，除去上述的灰度发布操作，也支持版本回滚，回滚在开发中是降低开发风险的最重要途径之一，回滚指的是程序或数据处理错误，将程序或数据恢复到上一次正确状态的行为；在回滚之后，程序依然能够正常处理。

通过图2可知，本申请实施例提供的逻辑编排方法在根据处理器编排结果生成逻辑元列表之后，将逻辑元列表中的多个处理器逻辑元转换为多段目标代码；进一步地，激活目标业务对应的目标版本，该逻辑业务编排方法还支持版本的灰度发布和回滚，能够有效地对版本进行管理；通过将组装后的代码逻辑版本化和发布规范化，提高服务稳定性及安全性。

在一可选地实施例中，在将逻辑元列表中的多个处理器逻辑元转化为多段目标代码之后，将多段目标代码保存至资源服务器，如加密后发布至CDN，或保存至其他能够实现快速访问的资源服务器，提高业务开发的效率。

请参看图3，图3为本申请实施例提供的逻辑编排的第二流程图；在图3中，首先进行处理编辑，处理器编辑可通过可视化编排、源码编排、可视化和源码编排三种方式进行，实现处理器编辑，形成逻辑。

在完成处理器编辑后，对逻辑元编辑。逻辑元编辑主要包括线性编排、场景设置和监控埋点几个方面。

进一步地，对逻辑元进行调试，可使用Mock、映射和测试用例等方法实现对逻辑元的调试。最后，将逻辑元发布、激活，若存在问题可回滚。

通过图3可知，本申请实施例提供的逻辑编排方法，实现了代码动态管理，通过原子化代码片段，根据不同场景，配置组装代码，提高了服务物料复用能力及灵活性。通过将组装后的代码逻辑版本化和发布规范化，提高服务稳定性及安全性。

请参看图4，图4为本申请实施例提供的变更业务逻辑处理的第一流程图；该变更业务逻辑处理方法包括以下步骤：

步骤S300：对当前业务流程引入流程编排工具包。

在上述步骤S300中，业务Node端接入流程编排专用SDK（软件开发工具包），在Node路由执行流程中插入流程编排，对Node流程进行路由拦截及流程扩展。

需要说明的是，流程编排SDK具备两种模式。

一种是完整路由模式：该请求通过前置流程进入流程编排SDK后，接口处理逻辑完全由流程编排接管执行，完成后直接到达请求返回流程。该模式增加了Node服务灵活性，只需在工作台正确配置后，Node服务无需发版即可完成新增路由接口或者替换原路由接口。

另一种是前置补充路由模式：该请求通过前置流程进入流程编排SDK后，流程编排SDK执行对应的动态逻辑片段，再将执行结果传递给原业务逻辑处理流程，后续流程由原Node服务接管。该模式用于对原路由接口进行逻辑补充，如校验参数，补充参数。

步骤S301：对业务接口进行路由拦截，并判断业务接口对应的目标业务是否发生变更。

步骤S302：若判定目标业务发生变更，则使用流程编排工具包，根据变更业务和逻辑元列表，处理变更业务。

在上述步骤S302中，对业务接口进行路由拦截，并判断业务接口对应的目标业务是否发生变更；如果判定目标业务发生变更，则使用流程编排工具包，根据变更业务和逻辑元列表来处理该变更业务。其中，逻辑元列表可通过本申请第一方面提供的逻辑编排方法获取。

通过图4可知，本申请实施例提供的变更业务逻辑处理方法，通过对当前业务流程引入流程编排工具包；对业务接口进行路由拦截，并判断业务接口对应的业务是否发生了变更；在目标业务发生变更的情况下，使用流程编排工具包根据变更业务和逻辑元列表处理该变更业务。本申请实施例提供的变更业务处理方法，通过在线可视化编排Node逻辑来控制业务侧Node的处理流程，能够进行统一高效管理。这种方式接入成本低，侵入小，上手快；去中心化，更好的容灾；天然热更新，线上代码秒级更新；适应了复杂业务的未来需求，可持续对复杂程度日益增长的业务逻辑进行完整、快速地配置。

请参看图5，图5为本申请实施例提供的变更业务逻辑处理的第二流程图；在本申请实施例的可选实施方式中，述根据变更业务和逻辑元列表，处理变更业务，可以包括以下步骤：

步骤S400：判断变更业务对应的请求逻辑是否为动态逻辑。

在上述步骤S400中，当确认目标业务发生变更之后，若要根据变更业务和逻辑元列表处理该变更了的业务，首先需要判断变更业务对应的请求逻辑是否为动态逻辑。

需要说明的是，根据不同应用，流程编排SDK拉取对应的动态逻辑配置，每一次请求进入，流程编排SDK会根据请求的路径，参数，请求方法匹配对应的动态逻辑片段。

步骤S401：若判定变更业务对应的请求逻辑为动态逻辑，则根据请求逻辑和逻辑元列表，处理变更业务。

在上述步骤S401中，如果判断变更业务对应的请求逻辑为动态逻辑，那么就根据该请求逻辑和逻辑元列表处理变更业务。

另一方面，若判断变更业务对应的请求逻辑不为动态逻辑，那么就根据本地逻辑处理该变更的业务。

通过图5可知，当判定业务发生变更之后，判断变更业务对应的请求逻辑是否为动态逻辑；如果是动态逻辑，就根据该请求逻辑和逻辑元列表来处理该变更业务；如果不是动态逻辑，就根据本地逻辑进行处理；因此，使用本申请提供的变更业务处理方法能够及时迅速地响应业务变更。

请参看图6，图6为本申请实施例提供的变更业务逻辑处理的第三流程图；在本申请实施例的可选实施方式中，根据动态逻辑和逻辑元列表，处理变更业务，可以通过以下步骤实现：

步骤S500：判断请求逻辑是否满足动态逻辑准入条件。

步骤S501：若判定请求逻辑满足动态逻辑准入条件，则将请求逻辑与逻辑元列表进行匹配，并获得逻辑元匹配结果。

在上述步骤S500-S501中，若判定请求逻辑是动态逻辑元；进一步地，判定请求逻辑是否满足逻辑动态逻辑准入条件，如果请求逻辑元满足动态逻辑准入条件，那么将请求逻辑和逻辑元列表进行匹配，并获得逻辑元匹配结果。

需要说明的是，在上述过程中判别的动态逻辑准入条件可以是接口的存在与否、当前上述的商户号和/或产品号是否符合预设要求。

步骤S502：根据逻辑元匹配结果，处理变更业务。

在上述步骤S502中，当判定请求逻辑符合动态逻辑准入条件之后，根据逻辑匹配结果来处理变更业务。应理解，逻辑元匹配结果一般存在两种，一种是逻辑元列表中包括该请求逻辑对应的请求逻辑元，一种是逻辑元列表中不包括该请求逻辑对应的请求逻辑元。

通过图6可知，在本申请实施例提供的变更业务处理方法中判定请求逻辑是否满足逻辑动态逻辑准入条件，如果请求逻辑元满足动态逻辑准入条件，那么将请求逻辑和逻辑元列表进行匹配，并获得逻辑元匹配结果；进一步地，根据逻辑元匹配结果处理该变更业务。也就是说，本申请实施例提供的变更业务处理方法，能够通过逻辑元的匹配来处理变更的业务，不用对整个接口的逻辑全部重新构建发布，能够准确、高效地响应业务的变更。

请参看图7，图7为本申请实施例提供的变更业务逻辑处理的第四流程图；在本申请实施例的可选实施方式中，根据逻辑元匹配结果，处理变更业务，可以通过以下步骤实现：

步骤S600：判断匹配结果是否为逻辑元列表中包括请求逻辑对应的请求逻辑元。

步骤S601：若判定匹配结果为逻辑元列表中包括请求逻辑元，则从逻辑元列表中获取请求逻辑元。

在上述步骤S601中，若判断匹配结果是逻辑元列表中包括该请求逻辑对应的请求逻辑元，就从逻辑元列表中获取对应的请求逻辑元。

步骤S602：对请求逻辑元进行分支匹配，并在沙箱中执行请求逻辑元，获得执行结果。

在上述步骤S602中，获取对应的请求逻辑元之后，对获取的请求逻辑元进行分支匹配，并在沙箱中执行，获得执行结果。需要说明的是，为了项目安全性，减少对原项目侵入及数据污染，流程编排SDK通过独立沙箱环境执行动态逻辑片段，流程编排SDK可以接受数据及环境变量传入，但是不会对参数及环境变量进行修改，仅在执行后返回结果。

通过图7可知，当判定匹配结果是逻辑元列表中包括该请求逻辑对应的请求逻辑元，就从逻辑元列表中获取对应的请求逻辑元；进一步地，通过独立沙箱环境执行动态逻辑片段；因此。使用本申请实施例提供的变更业务处理方法能够实现无侵入式接入，引入SDK之后，数据和代码片段通过沙箱执行，仅对现有逻辑进行扩展，不会对项目造成污染。

在一可选地实施例中，该变更业务处理方法还包括：若判定匹配结果为逻辑元列表中不包括请求逻辑元，则返回默认接口数据至本地逻辑；根据本地逻辑处理变更业务，并进行异常提示。

由此可知，当匹配结果是逻辑元列表中不包括对应的请求逻辑元时，就进行兜底或异常处理；具体地，当逻辑元列表不包括对应的请求逻辑时，返回默认的接口数据传到本地逻辑，或抛出错误，或进行异常记录；本申请实施例提供的变更业务逻辑处理方法，提供的完备的异常处理措施，保证业务正常进行。

请参看图8，图8为本申请实施例提供的业务处理示意图；当接收到业务请求进入之后，对业务相关数据进行数据校验；在流程编排成功的情况下，将本申请第一方面提供的逻辑编排流程插入该流程，对业务逻辑进行处理，完成业务逻辑的处理之后，返回相应的结果。在流程编排不成功的情况下，则使用本地业务逻辑进行处理，处理后再请求返回。

在图8中，将关于流程编排后产生的数据和代码片段，通过独立沙箱环境执行动态逻辑片段，流程编排SDK可以接受数据及环境变量传入，但是不会对参数及环境变量进行修改，仅在执行后返回结果，不会对项目造成污染。

请参看图9，图9为本申请实施例提供的业务处理整体流程图；在图9中，业务端发出请求，Node端进行路由拦截；路由拦截之后判断请求的逻辑是否为动态逻辑，若是动态逻辑就进入Node动态逻辑处理中间件，若不是动态逻辑就由本地逻辑处理，处理后记录关键日志。

Node动态逻辑处理中间件主要包括：分析请求逻辑是否满足请求逻辑准入条件，在满足条件的情况下进行逻辑元匹配，将请求逻辑和逻辑元列表进行匹配；若能够获取到匹配的逻辑元，则获取对应的逻辑元，进行逻辑元分支匹配，进行逻辑元分支加工沙箱处理，最后返回本地；若无法得到匹配的逻辑元，则进行兜底或异常处理，然后返回本地逻辑元。

其中，逻辑元列表的获取方法主要为，Node其中，初次或定时拉取工作台已经发布的逻辑元列表，该逻辑元列表的生成方式请参照本申请第一方面提供的逻辑编排方法。

请参看图10，图10为本申请实施例提供的逻辑编排系统的模块示意图；该逻辑编排系统100包括逻辑元生成模块110、逻辑编排模块120和逻辑元列表生成模块130。

逻辑元生成模块110用于根据目标物料，生成多个处理器逻辑元；其中，目标物料包括目标业务对应的本地变量和在线代码。

逻辑编排模块120用于根据目标业务和多个处理器逻辑元，对多个处理器逻辑元进行线性编排，以获得处理器编排结果。

逻辑元列表生成模块130用于根据处理器编排结果，生成逻辑元列表。

在一可选地实施例中，根据目标物料，逻辑元生成模块110生成多个处理器逻辑元，包括：逻辑元生成模块110根据目标物料，进行可视化变编排和/或源码编排，生成多个处理器逻辑元。

在一可选地实施例中，逻辑编排模块120根据目标业务和多个处理器逻辑元，对多个处理器逻辑元进行线性编排，以获得处理器编排结果，包括：逻辑编排模块120根据目标业务的逻辑顺序，对多个处理器逻辑元进行线性编排，以获得线性编排结果。

在一可选地实施例中，逻辑元列表生成模块130根据处理器编排结果，生成逻辑元列表，包括：逻辑元列表生成模块130基于线性编排结果，根据目标业务，对处理器逻辑元进行场景设置，并调试多个线性编排逻辑元，以获得逻辑元列表。

在一可选地实施例中，逻辑编排系统100还包括发布模块（图中未示出）、版本判别模块（图中未示出）和灰度发布模块（图中未示出）；在逻辑元列表生成模块130根据处理器编排结果，生成逻辑元列表之后，发布模块将逻辑元列表中的多个处理器逻辑元转化为多段目标代码；其中，多段目标代码对应多个目标版本；版本判别模块激活目标业务对应的目标版本；版本判别模块判断目标业务是否对应多个应用实例版本；其中，应用实例版本包括目标版本；若判定目标业务对应多个应用实例版本，则灰度发布模块控制目标业务流量进行灰度发布。

请参看图11，图11为本申请实施例提供的变更业务逻辑处理系统的模块示意图；该变更业务逻辑处理系统200包括：工具包引入模块210、业务变更判断模块220和业务处理模块230。

工具包引入模块210用于对当前业务流程引入流程编排工具包；业务变更判断模块220用于对业务接口进行路由拦截，并判断业务接口对应的目标业务是否发生变更；业务处理模块230用于在判定目标业务发生变更时，使用流程编排工具包，根据变更业务和逻辑元列表，处理变更业务；其中，逻辑元列表通过逻辑编排系统获取。

在一可选地实施例中，业务处理模块230根据变更业务和逻辑元列表，处理变更业务，包括：业务处理模块230判断变更业务对应的请求逻辑是否为动态逻辑；若判定变更业务对应的请求逻辑为动态逻辑，则业务处理模块230根据请求逻辑和逻辑元列表，处理变更业务。

在一可选地实施例中，业务处理模块230根据动态逻辑和逻辑元列表，处理变更业务，包括：业务处理模块230判断请求逻辑是否满足动态逻辑准入条件；若判定请求逻辑满足动态逻辑准入条件，则业务处理模块230将请求逻辑与逻辑元列表进行匹配，并获得逻辑元匹配结果；业务处理模块230根据逻辑元匹配结果，处理变更业务。

在一可选地实施例中，业务处理模块230根据逻辑元匹配结果，处理变更业务，包括：业务处理模块230判断匹配结果是否为逻辑元列表中包括请求逻辑对应的请求逻辑元；若判定匹配结果为逻辑元列表中包括请求逻辑元，业务处理模块230从逻辑元列表中获取请求逻辑元；业务处理模块230对请求逻辑元进行分支匹配，并在沙箱中执行请求逻辑元，获得执行结果。

在一可选地实施例中，该变更业务逻辑处理系统200还包括异常处理模块（图中未示出）；若判定匹配结果为逻辑元列表中不包括请求逻辑元，则异常处理模块返回默认接口数据至本地逻辑；根据本地逻辑处理变更业务，并进行异常提示。

请参见图12，图12为本申请实施例提供的电子设备的结构示意图。本申请实施例提供的一种电子设备300，包括：处理器301和存储器302，存储器302存储有处理器301可执行的机器可读指令，机器可读指令被处理器301执行时执行如上的方法。

基于同一发明构思，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行上述任一实现方式中的步骤。

所述计算机可读存储介质可以是随机存取存储器（Random Access Memory，RAM），只读存储器（Read Only Memory，ROM），可编程只读存储器（Programmable Read-OnlyMemory，PROM），可擦除只读存储器（Erasable Programmable Read-Only Memory，EPROM），电可擦除只读存储器（Electric Erasable Programmable Read-Only Memory，EEPROM）等各种可以存储程序代码的介质。其中，存储介质用于存储程序，所述处理器在接收到执行指令后，执行所述程序，本发明实施例任一实施例揭示的过程定义的电子终端所执行的方法可以应用于处理器中，或者由处理器实现。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

可以替换的，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。

所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（DSL））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。

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

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

Claims (13)

1.一种逻辑编排方法，其特征在于，所述方法包括：

根据目标物料，生成多个处理器逻辑元；其中，所述目标物料包括目标业务对应的本地变量和在线代码；

根据所述目标业务和多个所述处理器逻辑元，对多个所述处理器逻辑元进行线性编排，以获得处理器编排结果；

根据所述处理器编排结果，生成逻辑元列表。

2.根据权利要求1所述的方法，其特征在于，所述根据目标物料，生成多个处理器逻辑元，包括：

根据所述目标物料，进行可视化变编排和/或源码编排，生成多个所述处理器逻辑元。

3.根据权利要求1所述的方法，其特征在于，根据所述目标业务和多个所述处理器逻辑元，对多个所述处理器逻辑元进行线性编排，以获得处理器编排结果，包括：

根据所述目标业务的逻辑顺序，对多个所述处理器逻辑元进行线性编排，以获得所述线性编排结果。

4.根据权利要求1所述的方法，其特征在于，所述根据所述处理器编排结果，生成逻辑元列表，包括：

基于所述线性编排结果，根据所述目标业务，对所述处理器逻辑元进行场景设置，并调试多个所述线性编排逻辑元，以获得所述逻辑元列表。

5.根据权利要求1所述的方法，其特征在于，在所述根据所述处理器编排结果，生成逻辑元列表之后，所述方法还包括：

将所述逻辑元列表中的多个所述处理器逻辑元转化为多段目标代码；其中，多段所述目标代码对应多个目标版本；

激活所述目标业务对应的所述目标版本；

判断目标业务是否对应多个应用实例版本；其中，所述应用实例版本包括所述目标版本；

若判定所述目标业务对应多个应用实例版本，则控制目标业务流量进行灰度发布。

6.一种变更业务逻辑处理方法，其特征在于，所述方法包括：

对当前业务流程引入流程编排工具包；

对业务接口进行路由拦截，并判断所述业务接口对应的目标业务是否发生变更；

若判定所述目标业务发生变更，则使用所述流程编排工具包，根据变更业务和逻辑元列表，处理所述变更业务；其中，所述逻辑元列表的生成方法包括权利要求1至5中任一项所述的方法。

7.根据权利要求6所述的方法，其特征在于，所述根据变更业务和逻辑元列表，处理所述变更业务，包括：

判断所述变更业务对应的请求逻辑是否为动态逻辑；

若判定所述变更业务对应的请求逻辑为动态逻辑，则根据所述请求逻辑和所述逻辑元列表，处理所述变更业务。

8.根据权利要求7所述的方法，其特征在于，所述根据所述动态逻辑和所述逻辑元列表，处理所述变更业务，包括：

判断所述请求逻辑是否满足动态逻辑准入条件；

若判定所述请求逻辑满足所述动态逻辑准入条件，则将所述请求逻辑与所述逻辑元列表进行匹配，并获得逻辑元匹配结果；

根据所述逻辑元匹配结果，处理所述变更业务。

9.根据权利要求8所述的方法，其特征在于，所述根据所述逻辑元匹配结果，处理所述变更业务，包括：

判断所述匹配结果是否为所述逻辑元列表中包括所述请求逻辑对应的请求逻辑元；

若判定所述匹配结果为所述逻辑元列表中包括所述请求逻辑元，则从所述逻辑元列表中获取所述请求逻辑元；

对所述请求逻辑元进行分支匹配，并在沙箱中执行所述请求逻辑元，获得执行结果。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括：若判定所述匹配结果为所述逻辑元列表中不包括所述请求逻辑元，则返回默认接口数据至本地逻辑；

根据本地逻辑处理所述变更业务，并进行异常提示。

11.一种逻辑编排系统，其特征在于，所述逻辑编排系统包括：逻辑元生成模块、逻辑编排模块和逻辑元列表生成模块；

所述逻辑元生成模块用于根据目标物料，生成多个处理器逻辑元；其中，所述目标物料包括目标业务对应的本地变量和在线代码；

所述逻辑编排模块用于根据所述目标业务和多个所述处理器逻辑元，对多个所述处理器逻辑元进行线性编排，以获得处理器编排结果；

所述逻辑元列表生成模块用于根据所述处理器编排结果，生成逻辑元列表。

12.一种变更业务逻辑处理系统，其特征在于，所述变更业务逻辑处理系统包括：工具包引入模块、业务变更判断模块和业务处理模块；

所述工具包引入模块用于对当前业务流程引入流程编排工具包；

所述业务变更判断模块用于对业务接口进行路由拦截，并判断所述业务接口对应的目标业务是否发生变更；

所述业务处理模块用于在判定所述目标业务发生变更时，使用所述流程编排工具包，根据变更业务和逻辑元列表，处理所述变更业务；其中，所述逻辑元列表通过权利要求11所述的系统获取。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器运行时，执行权利要求1-10任一项所述方法中的步骤。

Images