具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将对本发明的技术方案进行详细的描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施方式，都属于本发明所保护的范围。

图1是本发明实施例一提供的可视化服务编排方法的流程图。参见图1，一种可视化服务编排方法，包括：

步骤101：接收客户端发送的业务请求指令。

步骤102：确定所述业务请求指令中包含的业务内容及业务种类。其中，业务种类包括：服务业务和消息业务。其中服务业务又包括：Dubbo服务和Http服务；消息业务包括Event消息。

服务编排系统中会预先构建多个服务组件，当研发人员进行产品研发时，可直接根据客户需求调用服务编排系统中的服务组件即可。例如：Dubbo服务组件、http服务组件。可根据编程过程中的功能需求，调用对应的服务组件。

步骤103：依据所述业务种类确定目标编排组件种类。当所述业务种类为所述服务业务时，所述目标编排组件种类为服务业务组件；当所述业务种类为所述消息业务时，所述目标编排组件种类为消息业务组件。根据业务种类的不同选取不同种类的编排组件。

步骤104：依据所述业务内容调取所述目标编排组件种类中的目标编排组件。

步骤105：将所有的所述目标编排组件进行组合，得到所述客户端所需的业务系统。

为了更详细地介绍本申请中的可视化服务编排方法的具体实现过程，现以业务请求为身份验证为例，对编排过程进行详细介绍。具体如下：

当研发人员获知到客户的服务需求后，会根据客户的服务需求进行产品研发。研发人员在研发平台端进行软件研发，首先，客户端会向研发平台发送业务请求指令，该业务请求指令中会包含客户的产品需求信息，也就是目标服务。

然后，依据所述业务请求指令确定此次服务为对所述客户端进行身份校验。

具体的：系统之间进行信息交互时，均是通过请求交互实现，而在进行请求时，客户端发送的请求指令中会包含发送方的身份信息。本申请中则是获取业务请求指令中保护的地址信息，然后对该地址信息进行经纬度解析，若该地址信息中含有经纬度信息，则直接依据客户端的请求进行相关操作。若地址信息中不包含经纬度信息，则直接返回空集至客户端，以此表示身份验证未通过，不能相应客户端的业务请求指令。

此处进行经纬度解析时，确定该经纬度解析为服务业务，然后采用Dubbo服务组件中的经纬度解析组件对所述地址信息中的经纬度进行识别。此时，则调取Dubbo服务组件中对应的经纬度解析组件。

需要注意的是，对地址经纬度进行识别时采用的手段并不局限于Dubbo服务，具体可根据服务组件分组的实际情况而定。

为了更详细清楚的介绍本申请中调取服务组件的过程，现举例进行介绍。图3是本发明实施例一提供的调取服务编排系统中服务组件的界面示意图。参见图3，

在调取服务编排系统中服务组件时，依据业务请求指令中的业务内容和业务种类确定目标编排组件。本实施例中的业务请求指令为：copy快手查询两小时预约件。然后依据预设的流程：开始-调用服务组件-结束。

执行开始之后，依据业务请求指令的内容，首先对客户端身份进行校验，此时调用Dubbo服务中的经纬度解析组件，添加此经纬度解析组件，进而通过该组件进行地址经纬度解析，进行经纬度解析时，具体实现过程如图3，具体解析过程在元器件配置界面进行设置，其中服务名称为地址经纬度解析，然后需要研发人员选择具体服务：数据开发平台和地址解析服务，然后依据界面需求进行相关设置，设置完成后，即完成了Dubbo服务中经纬度解析组件的调用，然后通过经纬度解析组件会进行地址经纬度解析。以此实现客户端的身份校验。

当经纬度解析完成后，判断快手是否支持两小时预约件，此功能的实现过程如下：首先确定判断快手是否支持两小时预约件的业务属于服务业务，然后再确定该请求属于服务业务中的Dubbo服务，然后遍历Dubbo服务组件，查找对应功能的“判断快手是否支持两小时预约件”的功能组件，添加此功能组件实现判断快手是否支持两小时预约件的功能。

以此，依据上述实现过程原理添加服务组件中的“查询两小时预约件”的目标编排组件，“获取两小时预约件”的目标编排组件，以及消息组件中的“返回空集”的目标编排组件，“不支持两小时预约件”的目标编排组件，“返回不控量结果”的目标编排组件，“支持两小时预约”的目标编排组件。

然后将所有的目标编排组件进行组合，实现“copy快手查询两小时预约件”的功能。

在上述实施例的基础上，本申请中在进行可视化服务编排时，对业务请求指令进行识别，确定客户端的业务内容和业务种类，然后依据业务种类确定目标编排组件种类，利用业务内容调取目标编排组件种类中的目标编排组件，然后组合所有的目标编排组件，实现客户端的业务请求。上述实施例提高了产品研发效率、实现低代码需求；同时实现了统一服务治理、业务方与服务提供方关系可视化，服务编排随时调整以满足业务方需求，不依赖版本发布、共性服务编排满足多个业务场景，无需重复开发。

对应于本发明实施例提供的一种可视化服务编排方法，本发明实施例还提供一种可视化服务编排装置。请参见下文实施例。

图2是本发明实施例一提供的可视化服务编排装置的模块图。参见图2，一种可视化服务编排装置，包括：

业务请求指令接收模块201，用于接收客户端发送的业务请求指令。

业务内容种类确定模块202，用于确定所述业务请求指令中包含的业务内容及业务种类。所述业务种类包括：服务业务和消息业务。所述服务业务包括：Dubbo服务和Http服务，所述消息业务包括：Event消息。

组件种类确定模块203，用于依据所述业务种类确定目标编排组件种类。

目标组件确定模块204，用于依据所述业务内容调取所述目标编排组件种类中的目标编排组件。

目标组件组合模块205，用于将所有的所述目标编排组件进行组合，得到所述客户端所需的业务系统。

其中，组件种类确定模块203具体用于：当所述业务种类为所述服务业务时，所述目标编排组件种类为服务业务组件；当所述业务种类为所述消息业务时，所述目标编排组件种类为消息业务组件。

上述装置中可视化形式展示服务提供方与调用方的关系；可视化形式完成服务编排，低代码实现业务需求，提高产研效率；业务方接入服务编排平台，由平台完成多个服务的可视化编排，业务方无需对接各方。

为了更清楚地介绍实现本发明实施例的硬件系统，对应于本发明实施例提供的一种可视化服务编排方法，本发明实施例还提供一种可视化服务编排设备。请参见下文实施例。

图4是本发明实施例一提供的可视化服务编排设备的结构图。参见图4，一种可视化服务编排设备，包括：

处理器401，以及与所述处理器401相连接的存储器402；

所述存储器402用于存储计算机程序，所述计算机程序至少用于上述所述的可视化服务编排方法；

所述处理器401用于调用并执行所述存储器402中的所述计算机程序。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本发明的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器402中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器402，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。