1.本发明涉及信息化应用软件的开发
技术领域：
：，具体涉及一种基于零代码平台的可视化业务服务编排方法及装置。
背景技术：
：：2.随着企业数字化转型的进程加快，零代码平台的的应用越来越广泛，逐渐被企业级的客户认可和接受。零代码顾名思义就是在不写代码的情况下可以搭建应用和功能来满足客户的需求，但事实是残酷的，真实的客户需求永远比我们想象的要复杂，传统的信息化应用软件零代码产品需要提供各种扩展能力，比如可以让开发人员编写复杂的业务逻辑的代码，并对接到平台中。具体的开发步骤是：需求分析师和客户确认好需求，并形成需求文档，提交给开发；开发经理理解需求并拆分出零代码平台能直接配置的部分和需要写代码扩展的部分；开发人员针对扩展部分编写restfulapi接口；发布部署restfulapi接口；在测试平台中进行接口的注册接口方法，在调用的地方进行接口方法的选择以及入参出参的配置；在测试环境中验证通过后，发布到生产环境；客户需求有变化时，重复一遍前面的步骤。这样虽然能够满足需求，但会有两个问题：1.客户的需求随时可能发生变化，需求一变就需要进行代码的修改；2.一线业务人员无法直接在平台中进行调整。这时就需要进行业务服务编排，例如：仓储物流出库先进先出更新库存量，在仓储物流系统中，商品的入库有时间的先后顺序，出库时需要遵循先入库的先进行出库，如图1所示，在不具备业务服务编排的信息化应用软件零代码产品系统中，搭建好功能后，还需要编写处理出库逻辑的api接口方法和系统中的某个方法对接起来，这个工作只能由开发人员来完成。如果使用业务服务器编排工具，就能轻松地通过可视化拖拽予以实现，如图2所示；再例如，如图3所示，人员离职后需要处理一些列的操作，包括修改hr系统中对应用户的状态、删除企业微信中的账号、禁用邮箱、发送通知，这些操作使用业务服务编排也可以很轻松就能实现，前提是要有丰富的业务组件。服务业务的编排其实就是一系列单个的业务组件通过流程的方式进行组合起来，最终达到业务的目的。提到流程，一般想到的是oa、crm等系统中的各种请假审批流、合同审批流。事实上，广义上的工作流是对工作流程及其各操作步骤之间业务规则的抽象、概括、描述。简单理解，为了实现某个业务目标，抽象拆解出来的一系列步骤及这些步骤之间的协作关系，就是工作流。也就是上面所说的业务服务的编排流程。服务编排引擎的总体架构如图4所示，目前的服务编排，常见的有三种模式：1.orchestration(编制)，通过一个可执行的流程来协同内部及外部的服务交互，通过流程来控制总体的目标、涉及的操作、服务调用顺序。这种模式必须有一个流程控制服务，用来接收请求，组织服务间的调用，并最终完成业务逻辑。这种方案中大多是同步调用，虽然在某个时刻能够很清晰的知道服务的执行情况，但当业务复杂，服务很多的情况下，在控制服务中会存在大量的耦合，难以维护；2.choreography(编排)，通过消息的交互序列来控制各个部分资源的交互，参与交互的资源都是对等的，没有集中的控制。可以看作一种消息驱动模式，或者说是订阅发布模式，不同的服务之间通过消息机制串联起来，这种方式大多都是异步的。好处就是耦合度低，但也会带来一些问题，比如：业务流程是通过订阅的方式来体现的，很难直接监控每笔业务的处理，因此难于调试，订阅是消息中间件中的一个常用概念，在消息中间件中，有生产者和消费者，消费者订阅某个类型的消息通道，当生产者往该消息通道进行消息发送的时候，消费者就会接收到消息，并进行处理。业务流程中使用订阅的方式处理指的是：流程中比如有a和b两个节点，a节点完成后发送消息(相当于生产者)，消息处理逻辑接收到后进行处理后流转到b节点(相当于消费者)；由于没有预定义流程，所以很难在事前保证流程正确性，基本靠事后分析数据来判断等；3.api网关，api网关是一种简单的接口聚合/拆分的方式：业务组件的请求后先到达网关，网关调用各微服务，并最终聚合/拆分需反馈的结果；api网关其实就是一个适配网关，比如对于web端，可以一个页面同时发起几十个请求，而对于移动端，最好是一个页面就几个请求；而采用api网关，后面的微服务可以是相同的。但只能应对一些逻辑简单的场景。参见最相关专利201811084640.x，通过设计原子服务来调用api，解决api需要的参数，为满足业务服务需求，将多个原子服务组织为流程，借助现有的工作流引擎支持，实现原子服务的编排和api自动化执行，从而达到快速编排业务快速执行业务的目的。3.发明专利201811084640.x《一种基于参数驱动的自动业务编排方法及装置》公开了通过设计原子服务来调用api，解决api需要的参数，为满足业务服务需求，将多个原子服务组织为流程，借助现有的工作流引擎(即可执行的流程)支持，实现原子服务的编排和api自动化执行，也就是将orchestration(编制)和api网关的结合，从而达到快速编排业务快速执行业务的目的。但对于orchestration(编制)模式存在的缺点和问题没有得到解决，也没有涉及利用可视化拖拽方式进行业务服务编排。技术实现要素：4.本发明针对现有技术的缺陷和改进需求，提供一种基于可视化的业务服务编排工具，包含可视化界面拖拽引擎、服务编排引擎、参数解析引擎，5.本发明的具体技术方案如下：6.一种基于零代码平台的可视化业务服务编排方法，所述方法应用于零代码平台，直接在平台中进行拖拽配置，实现所述可视化业务服务编排，包括如下步骤：7.配置可视化界面拖拽引擎，所述可视化界面拖拽引擎用于满足界面层的业务组合和编排操作；8.配置服务编排引擎，所述服务编排引擎用于将用户编排好的业务服务进行逻辑重组并进行存储；9.配置参数解析引擎，所述参数解析引擎用于进行解析参数，用于衔接上下游的服务；10.配置测试环境，所述测试环境用于用户直接在测试环境中根据对业务需求的理解，进行服务编排，在编排的同时添加数据进行测试；11.配置生产环境，所述生产环境用于用户将测试正常后的业务服务发布到生产环境；12.配置执行引擎，所述执行引擎用于当用户触发了某个编排好的业务服务时，执行引擎就会进行各种调度最后将结果返回给用户；13.构建服务控制层，一个服务的编排由一个或多个业务服务组件组成；14.构建模型层，15.一个业务服务组件拆解为1个或多个原子服务；16.每个原子服务可以抽象成一个通用模型；17.每个原子服务提供restapi接口或者事件监听机制；18.构建持久层，每个原子服务根据持久化适配器将数据更新到订阅的持久化组件中；19.用户进行可视化业务服务编排时，平台api接收到前端收集的配置数据，通过服务编排引擎将其转化为xml模型，模拟执行时，从缓存中获取到xml模型数据，服务编排引擎对其进行解析和执行。20.进一步地，所述可视化拖拽引擎包括页面渲染器，所述页面渲染器用于业务服务组件页面渲染时的异步加载，页面渲染时的步骤如下：21.前端先进行显示器屏幕大小的计算，作为参数传递给后端；22.后端查找当前页面的所有组件，并统计组件的渲染顺序和大小；23.根据屏幕大小和组件大小进行对比，以决定组件是否进行拆分；24.若拆分，则将拆分后的数据返回到前端，前端根据拆分后的数据进行按需异步加载。25.进一步地，所述决定组件是否进行拆分的具体方法是：26.对比屏幕宽高像素值和组件设置的宽高像素值，27.若所述屏幕宽高像素值是所述组件设置的宽高像素值的n倍数，则根据统计的组件的渲染顺序，在所述屏幕上加载n个所述组件，n为自然数。28.进一步地，所述每个服务组件都定义有自己的入参和出参，在一个服务编排的请求上下文中会随着执行的阶段不同，动态组织参数，参数适配器会根据名称、类型等进行自动适配，或者根据在设置界面中的手动绑定进行适配。29.进一步地，所述原子服务通过一个原子服务或多个原子服务，可以组装出来各种不同功能的业务组件，通过事件监听机制让服务之间、组件之间可以彻底解耦，以便能够灵活组装。30.进一步地，所述事件监听机制让服务之间、组件之间可以彻底解耦的具体方法为：利用消息中间件，每一个组件中既有生产者也有消费者，消费者接收消息进行处理，处理完成后根据配置决定是否发送消息出去。如果有消息发送出去，其他有对此消息类型有监听的组件就会接收到消息进行处理。31.进一步地，32.所述业务服务组件的调用是同步还是异步调用，通过由用户设置的方式由用户决定，并提供重试机制，确保数据的最终一致性；所述一个完整的业务调用开始时，会生成一个唯一id，这个id会一直存储在调用上下文中；33.原子服务会有两种方式被执行，restapi或者事件监听的方式，两者选择其中一种，如果是restapi，id会放在请求头中传递到下一层，如果是事件监听，id会做为消息体的一部分进行传递；34.最终的调用结果(过程中的入参、出参、原子服务耗时、业务组件耗时、异常日志等)，会在界面中予以展现，根据id就可以查询出这个id相关的所有调用信息。35.进一步地，所述id会一直存储在调用上下文中的具体方法为：全局的唯一id可以设计为消息传输实体中的一个属性字段，在最源头生成id后进行赋值，然后一直跟随着该消息进行流转，流转过程中是存储在内存中，如果消息中间件出现异常情况，数据便会进行持久化，这是数据是存储在硬盘中。36.进一步地，还包括补偿机制：假设现在用户已经编排了一个复杂的业务，针对每个调用组件操作，注册一个与其对应的补偿(即撤销)操作，操作本身和其补偿操作在一个事务里完成，当其后续操作失败后，需要按相反顺序完成前面注册的所有撤销操作。37.进一步地，所述补偿机制分为两种：38.特定服务组件上的独立设置；39.全局控制调用补偿，所有被调用服务被记录到一个列表中，如果出现需要重试或者回滚的操作，再从列表中获取出来进行相应的操作；在补偿模式中，要求能够提供补偿的服务的操作必须支持幂等(否则当多次执行的时候就会出现数据错误)40.跟现有技术相比，本发明的方法具有如下优点：41.本发明提供一种基于可视化的业务服务编排工具，包含可视化界面拖拽引擎、服务编排引擎、参数解析引擎，将原来需要开发人员进行逻辑编写来满足业务服务需求转变为可以直接在平台中进行拖拽配置的方式，让熟练掌握业务但不懂编程技术的企业业务人员可以轻松的进行业务功能的实现，具体将原来需要通过需求提请、需求调研、开发、测试、上线这种漫长的周期才能实现的业务服务需求，转变成在界面中进行简单拖拽、配置即能实现，极大地提升开发效率，快速响应企业用户的不断变更的业务需求；42.再者，在界面中进行拖拽配置过程中，如果一个页面中元素很多时会影响页面整体的加载速度，因为浏览器渲染页面需要消耗cpu/gpu，对于可视化页面来说，每一个可视化组件都需要渲染大量的信息元，信息元可以理解为无数的html元素，这会对页面性能造成不小的影响，所以本发明采取让组件异步加载到画布上，而不是一次性加载几十个几百个组件，以解决减少页面体积以及使用户可以更早的看到页面元素，具体地本发明的方法编制的软件系统的web开发是前后端分离架构，新的前端的框架不存在抖动的问题，本发明前端即浏览器，前端用浏览器渲染，用户看到界面，后端即后端程序处理业务逻辑。本发明的异步组件的渲染主要解决的页面渲染性能的问题，尤其能够按照屏幕的大小来算出要渲染哪些组件，提升页面渲染性能；43.同时结合了orchestration(编制)和choreography(编排)的优点，开发一种业务服务编排引擎，用原子服务来调用api采用是同步还是异步方式时，根据用户的需要予以决定，避免了控制服务中的高耦合度又在事前保证流程正确性。附图说明44.图1为传统方法的仓储物流出库先进先出更新库存量示意图；45.图2为本发明方法的可视化拖拽仓储物流出库先进先出更新库存量示意图。46.图3为本发明方法的可视化拖拽人员离职后需要处理一些列的操作示意图；47.图4为本发明方法的服务编排引擎的总体架构示意图；48.图5为本发明方法的可视化拖拽引擎的架构示意图；49.图6为本发明方法的页面渲染时的具体流程图示意图；50.图7为本发明方法的服务编排整体流程示意图；51.图8为本发明方法的特定服务组件上的独立设置补偿机制示意图；52.图9为本发明方法的在调用失败的日志列表中管理进行手动重试补偿机制示意图。具体实施方式53.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。54.一种基于零代码平台的可视化业务服务编排方法，所述方法应用于零代码平台，直接在平台中进行拖拽配置，实现所述可视化业务服务编排，包括如下步骤：55.配置可视化界面拖拽引擎，可视化界面拖拽引擎用于满足界面层的业务组合和编排操作；56.用户可以直接在web界面中使用拖拽的方式进行节点的添加、删除、修改以及各个服务节点的属性设置和参数的配置。所见即所得，配置完成后可以立即进行在线模拟运行查看效果；57.可视化拖拽引擎的架构图如图5所示，图中拖拽器是可视化拖拽引擎的核心模块，可以使用原生的js实现，也可以使用第三方库，原生js就是使用最基础的js语言的语法进行开发，比较灵活，但开发成本较高；第三方库是开源社区多年积累沉淀的一些框架，方便使用，但功能上可能受到限制；58.本实施例中使用的是vue.draggable。下面是核心实现的代码片段：59.[0060][0061]其中，代码标注中“选中的表单控件变化时，生成对应的控件属性并动态渲染到界面上”，是指将存储在数据库中的模型数据，通过代码逻辑的方式让其展示在页面上。[0062]通常，一个页面中元素很多时会影响页面整体的加载速度，因为浏览器渲染页面需要消耗cpu/gpu。对于可视化页面来说，每一个可视化组件都需要渲染大量的信息元，信息元可以理解为无数的html元素。这会对页面性能造成不小的影响，所以在本发明中采取了让组件异步加载到画布上，而不是一次性加载几十个几百个组件。[0063]页面渲染器就是提供了这样一种机制，确保组件的加载都是异步的，一方面可以减少页面体积，另一方面用户可以更早的看到页面元素。[0064]异步加载的原理是：当平台中有100个组件，页面上拖拽了10个组件的时候，页面渲染只请求这10个组件的js文件，然后进行渲染，大大提升了性能。再加上根据首屏加载的判断，在打开页面的时候，可能只会请求2到3个js，会进一步提升页面渲染的速度。[0065]具体本实施例中可视化界面拖拽引擎分为两个大的部分：拖拽和服务间的节点之间的连接和控制，[0066]拖拽：[0067]1、本发明中拖拽部分使用开源的vue.draggable组件；[0068]2、vue.draggable是一款基于sortable.js实现的vue拖拽插件，可以支持pc端和移动端、可以拖拽和选择文本和其他元素不同列表间拖拽；[0069]3、通过importdraggablefrom'vuedraggable'；就可以引用改拖拽组件[0070]4、在使用的地方放上一个draggable的代码块[0071]《draggableclass＝"widget-form-listwidget-form-list-drag"[0072]v-model＝"data.layoutdetail"style＝"min-height:600px；"[0073]v-bind＝"{group:'people',ghostclass:'ghost',swapthreshold:0.5}"@add＝"handlewidgetadd"[0074]5、在handlewidgetadd函数中进行面板中元素的添加handlewidgetadd(evt){constnewindex＝evt.newindex；[0075]this.selectwidget＝this.data.layoutdetail[newindex]；[0076]this.addservicenode()；}；[0077]服务间的节点之间的连接和控制：[0078]1、服务间节点的连接使用了开源组件antv/g6；[0079]2、g6是一个图可视化引擎，它提供了图的绘制、布局、分析、交互、动画等图可视化的基础能力；[0080]3、正如上面所说，g6提供的是一种基础能力，本发明的服务编排的可视化还需要在此基础之上进行扩展，有三个关键点：[0081]服务节点在有条件判断时的连接线的分支处理，[0082]提供组的拖拽块，可以将多个服务节点加入其中来实现循环逻辑，[0083]服务节点在连接时的辅助线对齐；[0084]连接线的分支处理：[0085]1、鼠标点中节点的锚点，记住线的起点，[0086]2、鼠标在画布拖拽时，获取鼠标在画布上的位置，渲染连接线，[0087]3、判断鼠标和目标节点的距离，如果很近，连接线直接吸附到节点上，[0088]4、鼠标松开点中，判断连接线是否吸附到了节点，没有吸附就移除连接线，[0089]5、点中连接点，展示设置节点，设置条件，如果设置条件就改变连接线的渲染属性，让连接线渲染成虚线；[0090]循环逻辑：[0091]1、鼠标点中节点组，记住节点数据，[0092]2、鼠标点中节点组在画布拖拽时，获取鼠标在画布的位置，在画布上渲染虚拟的线框，[0093]3、鼠标松开点中，获取鼠标在画布上的位置，渲染节点组，[0094]4、重复上面的步骤将服务节点拖到节点组里；[0095]辅助线对齐：[0096]1、鼠标点中节点组在画布拖拽时，获取鼠标在画布的位置，在画布上渲染虚拟的线框，[0097]2、找出画布上所有和拖拽节点的顶线、底线、中线、左边线、中竖线、右边线在同一条线的最近一个节点，[0098]3、在找到的节点和拖拽的节点在画布的线框之间渲染辅助线，4、鼠标松开点中，获取鼠标在画布上的位置，渲染节点，并移除显示在画布上的辅助线。[0099]具体地，可视化拖拽引擎包括页面渲染器，页面渲染器用于业务服务组件页面渲染时的异步加载，页面渲染时的步骤如下：[0100]前端先进行显示器屏幕大小的计算，作为参数传递给后端；本实施例中前端可以理解为浏览器；[0101]后端查找当前页面的所有组件，并统计组件的渲染顺序和大小；[0102]根据屏幕大小和组件大小进行对比，以决定组件是否进行拆分；[0103]若拆分，则将拆分后的数据返回到前端，前端根据拆分后的数据进行按需异步加载。所述拆分后的数据具体是指：当前页面的所有组件数如果有100个，根据像素大小比较之后的拆分出来的首屏能显示的组件的个数可能是2，也可能是4或者其他的个数；不断加载往下滚动所有页面才能加载完100个所有组件。[0104]本发明的程序是前后端分离的架构，前端用浏览器渲染，用户看到的是界面，后端处理业务逻辑，这里的后端就是后端程序。[0105]决定组件是否进行拆分的具体方法是：[0106]对比屏幕宽高像素值和组件设置的宽高像素值，[0107]若所述屏幕宽高像素值是所述组件设置的宽高像素值的n倍数，则根据统计的组件的渲染顺序，在所述屏幕上加载n个所述组件，n为自然数。例如屏幕宽1000px(像素)、高800px，第一个组件宽1000px、高400px，第二个组件宽1000px、高400px，屏幕就可以同时加载这两个组件；如果第一个组件宽1000px、高800px，则屏幕只加载这一个组件；如果当前页面的所有组件有100个组件，则后端统计组件的渲染顺序和大小，会一次性返回100个组件的配置信息给前端，根据拆分后的数据进行按需异步加载，这样异步加载是本发明的优点之一，如果同步加载则用户体验不好，性能较差。[0108]具体流程图如图6。分为两种情况：[0109]1.所有组件像素加起来小于屏幕像素时，因为首屏就能显示下所有的组件，所以直接返回所有的组件的配置信息给前端，遍历所有组件进行异步渲染；[0110]2.所有组件加起来大于屏幕时，根据计算来判断首屏能加载多少组件，进行分组返回屏幕能加载的每一组组件的配置信息给前端，遍历每组组件进行异步渲染；比如一共有100个组件，首屏能显示10个，那就会分成多组返回。[0111]下面代码片段为异步动态渲染部分的核心代码：[0112][0113][0114][0115]配置服务编排引擎，所述服务编排引擎用于将用户编排好的业务服务进行逻辑重组并进行存储；[0116]业务服务的编排其实就是一系列单个的业务组件通过流程的方式进行组合起来，最终达到业务的目的。[0117]一般流程有oa、crm等系统中的各种请假审批流、合同审批流，事实上，广义上的工作流是对工作流程及其各操作步骤之间业务规则的抽象、概括、描述。简单理解，为了实现某个业务目标，抽象拆解出来的一系列步骤及这些步骤之间的协作关系，就是工作流。也就是上面所说的业务服务的编排流程。[0118]服务编排引擎就类似一个编程语言的语法解析器，在界面中设置的判断规则、循环规则等等，通过服务编排引擎进行配置的解析，转化成机器能够执行的指令。[0119]服务编排引擎的总体架构如图4所示：[0120]本实施例中服务编排的步骤如下：[0121]构建服务控制层，一个服务的编排由一个或多个业务服务组件组成；[0122]构建模型层，[0123]一个业务服务组件拆解为1个或多个原子服务；[0124]每个原子服务可以抽象成一个通用模型；例如扣款为一个原子服务，转账需要一个服务组件用来做转账用，但转账过程里面包含两个原子服务，一个是目标账户要进行金额增加，另一个是源账户要进行金额的扣减，如此完成扣款这一个原子服务；[0125]每个原子服务提供restapi接口或者事件监听机制；[0126]构建持久层，每个原子服务根据持久化适配器将数据更新到订阅的持久化组件中；[0127]用户进行可视化业务服务编排时，平台api接收到前端收集的配置数据，通过服务编排引擎将其转化为xml模型，模拟执行时，即在配置阶段(也就是没有正式发布上线的阶段)可以使用测试数据来模型运行来判断程序的正确性，从缓存中获取到xml模型数据，服务编排引擎对其进行解析和执行。解析即是获取数据库中存储的xml配置，将其转换成程序能够识别的逻辑，然后程序就能够执行编排的逻辑了。[0128]服务的编排整体过程如图7所示：[0129]在可视化编排界面中进行拖拽节点和属性设置并保存后，整个业务编排模型的配置数据会形成一个xml的模型存在数据库中，下面是一个模型片段：[0130][0131][0132][0133]用户进行可视化的服务编排后，平台api接收到前端收集的配置数据，通过服务编排引擎将其转化为xml模型。模拟执行时，从缓存中获取到xml模型数据，服务编排引擎对其进行解析和执行，例如uelse属性的设置用来控制服务的条件判断，分支走向；ufor属性用来控制循环内容的处理。[0134]服务组件的调用分为同步和异步，这个决定权交给用户是一种更好的实现方式，可以通过设置的方式来进行，并提供重试机制，确保数据的最终一致性。重试机制是指当因为某些原因(网络、数据库问题等)导致一个业务执行失败的时候，进行重新执行来保证业务的正确性的一种机制。重试的机制的实现方式有很多种，本实施例采用的是消息队列。例如扣款，发起扣款时，扣款发起方将扣款这个任务发送给消息队列，消息队列处理完后会有一个回执代表正常处理完成，如果没有回执，标识处理失败，就会继续排在队列中等待处理。这样就能保证最终的一致性。如图8所示。[0135]前述业务服务组件页面渲染时的异步加载，以及这里所述的业务服务组件的调用是同步还是异步调用，逻辑是一致的，只是用的场景不同。页面的渲染中：同步是指页面上所有的内容全部获取到后，才开始渲染操作，异步是指可以一部分一部分的进行渲染，例如淘宝首页的首屏很快就出来，往下滚动页面的时候下面的菜开始加载也属于异步的范围；重试机制中的同步是指：如果重试要进行两个服务的调用，是有顺序的，先调用第一个，第一个结束后再调用第二个，异步就是两个可以同时进行调用。[0136]每个服务组件都不是孤立存在的，都有自己的入参和出参，比如现在有一个业务逻辑是将电话号码中间的四位用星号表示，会使用到两个业务组件，一个组件进行电话号码的查询，一个组件进行星号的处理：[0137]获取电话号码的组件：[0138]入参：用户姓名[0139]出参：根据用户姓名查询出用户的电话号返回[0140]星号处理组件：[0141]入参：从上一个组件获取到的电话号码[0142]出参：经过处理后的带星号的电话号码[0143]每个服务组件都定义有自己的入参和出参，在一个服务编排的请求上下文中会随着执行的阶段不同，动态组织参数，参数适配器会根据名称、类型等进行自动适配，或者根据在设置界面中的手动绑定进行适配。具体是说这个参数值的获取是在运行时指定的，而不是事先赋值的固定的值，例如扣款是一个原子服务，其中一个服务组件就是用来做转账用的，这个转账用服务组件包含了两个原子服务，一个是目标账户要进行金额增加，另一个是源账户要进行金额的扣减，到运行时才知道应该给哪个账户转钱，转多少钱，这个账户和转账的金额就是参数，是在运行的时候动态取出来的。[0144]原子服务只做一件事情，通过一个原子服务或多个原子服务，可以组装出来各种不同功能的业务组件，通过事件监听机制让服务之间、组件之间可以彻底解耦，以便能够灵活组装。例如还是转账，一个服务组件就是用来做转账用的，但这个里面包含两个原子服务，一个是目标账户要进行金额增加，另一个是源账户要进行金额的扣减。[0145]现在有另一个服务组件是用来做扣款的，里面就可以包含一个原子服务，也就是上面例子中的第二个服务，扣减某个账户中的金额。这样这个原子服务就可以重用了，他的作用就是将某个账户的钱扣减指定的额度，只要有业务需要用到账户金额的扣减即可用。[0146]事件监听机制让服务之间、组件之间可以彻底解耦的具体方法为：利用消息中间件，每一个组件中既有生产者也有消费者，消费者接收消息进行处理，处理完成后根据配置决定是否发送消息出去。如果有消息发送出去，其他有对此消息类型有监听的组件就会接收到消息进行处理。[0147]随着服务和组件的增多，调用链会变得越来越复杂，当一个服务编排整个处理完后，调用链会形成一个复杂网络，这对排查问题造成很大的麻烦。我们采用全链路跟踪来解决这个问题，在一个完整的业务调用开始时，会生成一个唯一id，这个id会一直存储在调用上下文中。全局的唯一id可以设计为消息传输实体中的一个属性字段，在最源头生成id后进行赋值，然后一直跟随着该消息进行流转，流转过程中是存储在内存中，如果消息中间件出现异常情况，数据便会进行持久化，这是数据是存储在硬盘中。[0148]上面说到原子服务会有两种方式被执行，restapi和事件监听的方式，这两种方式是根据情况选择其中一种进行，restapi是调用者直接访问被调用者，通常是有针对性的功能对接时，例如被调用者的这个功能只被这个调用者使用。事件监听常用于通用功能模块。如果是restapi，id会放在请求头中传递到下一层，如果是事件监听，id会做为消息体的一部分进行传递，例如：因为在服务编排的一个完整调用中可能会涉及到很多不同的原子服务，这些原子服务还有可能是分布式部署，所以为了能够追踪到所有的调用情况，在调用的开始就会生产一个全局唯一id，这个全局唯一id会作为消息体的一个属性进行存储，所以在调用的过程中就会带着这个id。[0149]restapi是一种主动调用的方式，本质上调用者和被调用者是耦合关系的，但也能做到解耦，比例如使用代理模式。代理模式是如何做到解耦的？代理模式就是在调用方和被调用方之间加了一层中间层。调用方和这个中间层进行交互，被调用方也和这个中间层进行交互。这样调用方和被调用方就不用直接交互了，就实现了解耦。具体地，客户借钱，从支付宝的花呗借，支付宝可能也是从银行拿到钱给客户，客户是调用方，银行是被调用方，支付宝的花呗就是中间层。[0150]最终的调用结果(过程中的入参、出参、原子服务耗时、业务组件耗时、异常日志等)，会在界面中以树状的形式展现，根据id就可以查询出这个id相关的所有调用信息。这个是最终的一个日志的展现，因为在多服务的调用中，需要有完整的日志来进行调试或者错误的排查。[0151]假设现在用户已经编排了一个复杂的业务，服务组件之间的调用有同步也有异步，当某个环节出现问题时候，我们需要保证数据的最终一致性。常用的一种方式就是补偿机制：[0152]补偿模式核心思想是：针对每个操作，都要注册一个与其对应的补偿(撤销)操作，一般来说操作本身和其补偿操作会在一个事务里完成，当其后续操作失败后，需要按相反顺序完成前面注册的所有撤销操作。事务是指是程序中一系列严密的逻辑操作，而且所有操作必须全部成功完成，否则在每个操作中所作的所有更改都会被撤消。可以通俗理解为：就是把多件事情当做一件事情来处理，要么都成功，要么都失败。比如：电商买东西，会涉及到下订单，然后扣减库存，生成订单和扣减库存是两个操作，如果订单生成成功，库存的扣减失败了，则会让订单进行回滚。[0153]本发明的补偿机制分为两种：[0154]1、特定服务组件上的独立设置，如图8所示；[0155]2、全局控制调用补偿，所有被调用服务会记录到一个列表中，如果出现需要重试或者回滚的操作，再从列表中获取出来进行相应的操作。[0156]在补偿模式中，要求能够提供补偿的服务的操作必须支持幂等，否则当多次执行的时候就会出现数据错误。幂等(idempotent、idempotence)是一个数学与计算机学概念，常见于抽象代数中。在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。例如某个接口的作用是做信用卡的扣款，某个业务场景下需要调用接口扣一定的金额，那么这个接口调用多次也只会扣一定的金额，这就是符合幂等的。[0157]正常情况下，所有的补偿都是自动触发的，但有些特殊的场景还是需要人工干预，在调用失败的日志列表中管理有可以进行手动重试，如图8所示：[0158]配置参数解析引擎，参数解析引擎用于进行解析参数，用于衔接上下游的服务；[0159]参数解析在服务编排中是一个很重要的环境，起到串联各个服务节点的作用，一个节点的输出是另一个节点的输入，多个服务节点的数据组合等都需要依赖参数解析引擎。[0160]具体地，在业务服务编排中，存在两种类型的参数，入参和出参入参：使用动态表达式进行设置[0161]出参：大多是固定的json格式[0162]所以参数解析引擎主要是针对入参进行解析。入参解析分为两个大的部分[0163]参数表达式解析[0164]自定义函数解析[0165]参数表达式解析步骤：[0166]1、参数解析引擎中的解析函数接收到参数表达式，例如表达式：{f_745b066857}+{f_e2b90aea19}表示两个字段的相加；[0167]2、根据表达式中的大括号识别出两个字段的code[0168]3、识别表达式中的操作符号+[0169]4、从数据源中根据识别出来的字段进行字段值的获取[0170]5、根据操作符对两个值进行运算[0171]6、将运算后的结果返回；[0172]自定义函数的解析步骤：[0173]1、在参数解析引擎中有抽象基类function，该类中有抽象方法parse[0174]2、所有的函数类都继承自function抽象基类，并实现抽象方法parse[0175]3、比如一个计算字符串长度的函数定义如下：[0176][0177][0178]4、比如参数表达式length({f_745b066857})用来获取一个字段的长度，通过小括号识别前面的length函数，然后识别大括号中的字段，并根据字段从数据源中获取值，将值作为length函数的入参，最终代码会执行到上面第三步的parse方法中。[0179]配置测试环境，测试环境用于用户直接在测试环境中根据对业务需求的理解，进行服务编排，在编排的同时添加数据进行测试；[0180]配置生产环境，生产环境用于用户将测试正常后的业务服务发布到生产环境；[0181]配置执行引擎，执行引擎用于当用户触发了某个编排好的业务服务时，执行引擎就会进行各种调度最后将结果返回给用户。[0182]根据本发明的基于零代码平台的可视化业务服务编排方法，如果客户的业务需求发生的变更，需要实现的流程步骤如下：[0183]客户业务部门的人员或者平台的配置人员直接在测试环境中根据自己对业务需求的理解，进行服务编排；[0184]边编排可以边添加数据进行测试；[0185]测试正常后发布到生产环境。[0186]根据同一发明构思，本技术实施例提供一种基于零代码平台的可视化业务服务编排装置，该装置包括：[0187]可视化界面拖拽引擎，所述可视化界面拖拽引擎用于满足界面层的业务组合和编排操作；[0188]服务编排引擎，所述服务编排引擎用于将用户编排好的业务服务进行逻辑重组并进行存储；[0189]数解析引擎，所述参数解析引擎用于进行解析参数，用于衔接上下游的服务；[0190]测试环境模块，所述测试环境模块用于用户直接在测试环境中根据对业务需求的理解，进行服务编排，在编排的同时添加数据进行测试；[0191]生产环境模块，所述生产环境模块用于用户将测试正常后的业务服务发布到生产环境；[0192]执行引擎，所述执行引擎用于当用户触发了某个编排好的业务服务时，执行引擎就会进行各种调度最后将结果返回给用户；[0193]服务控制层，一个服务的编排由一个或多个业务服务组件组成；[0194]模型层，[0195]一个业务服务组件拆解为1个或多个原子服务；[0196]每个原子服务可以抽象成一个通用模型；[0197]每个原子服务提供restapi接口或者事件监听机制；[0198]构建持久层，每个原子服务根据持久化适配器将数据更新到订阅的持久化组件中；[0199]用户进行可视化业务服务编排时，平台api接收到前端收集的配置数据，通过服务编排引擎将其转化为xml模型，模拟执行时，从缓存中获取到xml模型数据，服务编排引擎对其进行解析和执行。[0200]在一个实施例中，可视化拖拽引擎包括页面渲染器，页面渲染器用于业务服务组件页面渲染时的异步加载，页面渲染时的步骤如下：[0201]前端先进行显示器屏幕大小的计算，作为参数传递给后端；[0202]后端查找当前页面的所有组件，并统计组件的渲染顺序和大小；[0203]根据屏幕大小和组件大小进行对比，以决定组件是否进行拆分；[0204]若拆分，则将拆分后的数据返回到前端，前端根据拆分后的数据进行按需异步加载。[0205]根据本发明的基于零代码平台的可视化业务服务编排方法和装置，进行了以下两个业务服务的编排：[0206]1、仓储物流出库先进先出更新库存量[0207]在仓储物流系统中，商品的入库有时间的先后顺序，出库时需要遵循先入库的先进行出库，如图1所示；[0208]在不具备业务服务编排的系统中，搭建好功能后，还需要编写处理出库逻辑的api接口方法和系统中的某个方法对接起来。这个工作只能由开发人员来完成。[0209]使用本发明的业务服务器编排工具，就能轻松地可视化拖拽就能实现了，如图2所示。[0210]2、人员离职后需要处理一些列的操作，例如：[0211]修改hr系统中对应用户的状态[0212]删除企业微信中的账号[0213]禁用邮箱[0214]发送通知[0215]使用本发明的业务服务编排可以很轻松就能实现，前提是要有丰富的业务组件，如图3所示。当前第1页12当前第1页12