CN114942856A

CN114942856A - 微服务系统的数据处理方法、装置及电子设备

Info

Publication number: CN114942856A
Application number: CN202210860022.XA
Authority: CN
Inventors: 陈晖�; 刘志勇; 洪小敏; 刘得斌
Original assignee: Zhejiang Supcon Technology Co Ltd
Current assignee: Zhongkong Technology Co ltd
Priority date: 2022-07-22
Filing date: 2022-07-22
Publication date: 2022-08-26
Anticipated expiration: 2042-07-22
Also published as: CN114942856B

Abstract

本申请提供一种微服务系统的数据处理方法、装置及电子设备，所述方法包括：通过目标微服务接收第一外部服务的调用服务请求，将所述调用服务请求进行解析并转换为微服务系统对应的第一格式，得到调用服务请求中的请求参数；目标微服务根据所述调用服务请求中的请求参数调用对应的处理函数，由处理函数根据请求参数执行相应的操作并返回执行结果；目标微服务将执行结果转化为第一外部服务对应的第二格式，并发送至第一外部服务。可以使微服务系统实现以多种协议对外提供服务，避免在微服务系统中的每一个微服务中都需要添加第三方系统所需的协议，并且针对不同的第三方系统进行定制修改，避免处理多种协议的高复杂度。

Description

微服务系统的数据处理方法、装置及电子设备

技术领域

本申请涉及通信技术领域，具体而言，涉及一种微服务系统的数据处理方法、装置及电子设备。

背景技术

微服务架构(Micro Service Architecture，简称MSA)目前越来越成为了主流架构，是软件系统的一种新的架构风格。在微服务系统中，所有的模块功能不再像单体系统部署在一个包内，而是由多个微服务组成，每个微服务都能独立设计、开发、部署，在灵活性方面具有很大优势。

现有技术中，第三方系统与微服务系统进行对接时，微服务系统向第三方系统提供接口供第三方系统调用，但第三方系统使用的通信协议各不相同，而微服务系统的服务间通信协议通常是固定的，因此，无法满足同时接入多种通信协议。目前，通过更换第三方系统的通信协议或者修改微服务系统的代码来解决不同的第三方系统与微服务系统之间的对接。

但是，现有的技术存在工作量大，周期长，有些第三方系统受操作系统和编译环境的限制，无法找到对应的通信资源库进行协议的更换；修改微服务系统的代码时，需要为微服务系统中的每一个微服务都添加第三方系统所需的协议，需要对不同的第三方系统进行定制修改，除了工作量大也会影响微服务系统的稳定性，并且，编写代码需要处理多种协议，复杂度高。

发明内容

本申请的目的在于，针对上述现有技术中的不足，提供一种微服务系统的数据处理方法、装置及电子设备，可以使微服务系统实现以多种协议对外提供服务，避免处理多种协议的高复杂度。

为实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请实施例提供了一种微服务系统的数据处理方法，应用于微服务系统，所述微服务系统中部署多个微服务，所述方法包括：

目标微服务接收第一外部服务的调用服务请求，将所述调用服务请求进行解析并转换为所述微服务系统对应的第一格式，得到所述调用服务请求中的请求参数，其中，所述目标微服务为所述微服务系统中的任意一个微服务；

所述目标微服务根据所述调用服务请求中的请求参数调用对应的处理函数，由所述处理函数根据所述请求参数执行相应的操作并返回执行结果；

所述目标微服务将所述执行结果转化为所述第一外部服务对应的第二格式并发送至所述第一外部服务。

可选的，所述目标微服务根据所述调用服务请求中的请求参数调用对应的处理函数，由所述处理函数根据所述请求参数执行相应的操作并返回执行结果之前，还包括：

所述目标微服务接收所述目标微服务对应的上层应用发送的处理函数注册请求，所述处理函数注册请求中包括所述处理函数，所述处理函数注册请求用于请求在所述目标微服务中注册所述处理函数；

所述目标微服务将所述处理函数注册到所述目标微服务的第一目标插件实例中的服务端模块中，所述第一目标插件实例为支持所述第一外部服务的插件实例。

所述目标微服务接收所述第一外部服务发送的处理函数注册请求，所述处理函数注册请求中包括所述处理函数，所述处理函数注册请求用于请求在所述目标微服务中注册所述处理函数；

可选的，所述目标微服务接收第一外部服务的调用服务请求，将所述调用服务请求进行解析并转换为所述微服务系统对应的第一格式，包括：

所述目标微服务通过所述服务端模块接收所述调用服务请求，并通过所述服务端模块将所述调用服务请求进行解析并转换为所述微服务系统对应的第一格式；

所述目标微服务根据所述调用服务请求中的请求参数调用对应的处理函数，由所述处理函数根据所述请求参数执行相应的操作并返回执行结果，包括：

所述目标微服务通过所述服务端模块调用所述处理函数，由所述处理函数根据所述请求参数执行相应的操作并返回执行结果。

可选的，所述方法还包括：

所述目标微服务根据第二外部服务的协议类型，调用支持所述第二外部服务的第二插件实例，由所述第二插件实例对所述第二外部服务的调用参数进行序列化，并通过序列化后的调用参数调用所述第二外部服务；

所述目标微服务通过所述第二插件实例将所述第二外部服务的调用结果进行反序列化，得到反序列化结果。

可选的，所述方法还包括：

所述微服务系统中的插件管理微服务接收待安装插件的安装包；

插件管理微服务运行所述安装包，以将所述待安装插件安装至目标目录下。

可选的，所述插件管理微服务运行所述安装包，以将所述待安装插件安装至目标目录之后，所述方法还包括：

所述目标微服务接收目标插件加载指令，所述插件加载指令用于指示从所述插件管理微服务中加载目标插件；

所述目标微服务从所述插件管理微服务的目标目录下加载所述目标插件，以生成所述目标插件对应的插件实例。

可选的，所述方法还包括：

所述目标微服务接收目标插件禁用指令，所述插件禁用指令用于指示从所述目标微服务中卸载目标插件实例；

所述目标微服务调用所述目标插件实例的反初始化接口，以卸载所述目标插件实例。

第二方面，本申请实施例还提供了一种微服务系统的数据处理装置，所述装置包括：

接收装置，用于接收第一外部服务的调用服务请求，将所述调用服务请求进行解析并转换为所述微服务系统对应的第一格式，得到所述调用服务请求中的请求参数，其中，所述目标微服务为所述微服务系统中的任意一个微服务；

调用装置，用于根据所述调用服务请求中的请求参数调用对应的处理函数，由所述处理函数根据所述请求参数执行相应的操作并返回执行结果；

转化装置，用于将所述执行结果转化为所述第一外部服务对应的第二格式并发送至所述第一外部服务。

可选的，所述调用装置具体用于：

可选的，所述接收装置具体用于：

可选的，所述调用装置还具体用于：

可选的，所述接收装置还具体用于：

可选的，所述接收装置具体用于：

第三方面，本申请实施例还提供了一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的程序指令，当应用程序运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述程序指令，以执行上述第一方面所述的微服务系统的数据处理方法的步骤。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被读取并执行上述第一方面所述的微服务系统的数据处理方法的步骤。

本申请的有益效果是：

本申请提供的一种微服务系统的数据处理方法、装置及电子设备，通过目标微服务接收第一外部服务的调用服务请求，将所述调用服务请求进行解析并转换为微服务系统对应的第一格式，得到调用服务请求中的请求参数；目标微服务根据所述调用服务请求中的请求参数调用对应的处理函数，由处理函数根据请求参数执行相应的操作并返回执行结果；目标微服务将执行结果转化为第一外部服务对应的第二格式，并发送至第一外部服务。通过将调用服务请求转换为微服务系统对应的格式并且调用目标微服务的注册处理函数执行相应的操作，可以使微服务系统实现以多种协议对外提供服务，避免在微服务系统中的每一个微服务中都需要添加第三方系统所需的协议，并且针对不同的第三方系统进行定制修改，极大的减少了工作量，从而避免处理多种协议的高复杂度。

附图说明

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

图1为本申请实施例提供的一种示例性场景示意图；

图2为本申请实施例提供的插件管理页面示意图；

图3为本申请实施例提供的插件内部的结构示意图；

图4为本申请实施例提供的目标微服务内的运行时模块的内部结构示意图；

图5为本申请实施例提供的一种微服务系统的数据处理方法的流程示意图；

图6为本申请实施例提供的外部服务注册处理函数的方法流程示意图；

图7为本申请实施例提供的另一种微服务系统的数据处理方法的流程示意图；

图8为本申请实施例提供的一种微服务系统的数据处理方法的装置示意图；

图9为本申请实施例提供的一种电子设备的结构框图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

图1为本申请实施例提供的一种示例性场景示意图，如图1所示，该方法应用于微服务系统，该微服务系统中可以部署多个微服务，该微服务系统可以与终端设备连接，该终端设备101在本申请实施例中可以指显示前端页面的设备，例如台式电脑、笔记本电脑等，该终端设备中可以包括插件管理页面1011。该微服务系统102可以指后端服务器上运行的系统，则，可以通过终端设备101的插件管理页面向微服务系统102中安装插件，微服务系统102根据安装的插件以及利用本申请实施例提供的方法与外部服务进行交互。

可选的，该微服务系统中可以包括插件管理微服务和其他微服务，该插件管理微服务对应插件管理模块1021，该插件管理模块集成在插件管理微服务中，可以管理多个插件；其他微服务中的每个微服务可以一一对应一个运行时模块1022。每个微服务中的运行时模块指的是集成在每个微服务内的一个组件，用于载入插件、调用插件、接收插件的变动消息并作出响应、对外部服务提供统一的调用接口，每个微服务内的运行时模块的形态由对应的微服务决定。

图2为本申请实施例提供的插件管理页面示意图，如图2所示，插件管理页面1011可以展示被安装到微服务系统内的所有插件的信息，例如插件的插件名、插件版本号、插件上传时间以及插件是否被启用。用户可以通过插件管理页面1011进行删除、启用、禁用、查看详情等操作，同时可以通过插件管理页面上的上传按钮201弹出插件上传对话框202来上传插件，具体地，用户可以点击上传按钮201，在弹出的上传对话框202中通过点击浏览，从其他网页中选择需要的插件进行上传，上传后的插件可以在插件管理页面1011中显示。

可选的，插件可以指的是对不同协议的通信组件进行封装，例如对不同的RPC协议、HTTP协议或者第三方私有协议，并开放统一的接口供微服务进行调用的动态库。

图3为本申请实施例提供的插件内部的结构示意图，如图3所示，该插件内部可以包括API接口301、客户端模块302、服务端模块303、序列化框架304以及通信框架305。

其中，API接口301用于暴露标准接口，供运行时模块调用，该标准接口可以包括初始化接口以及注册处理函数接口；客户端模块302，用于实现调用接口，将外部服务的调用转化为不同特定协议的调用之后向目标微服务调用；服务端模块303，用于实现注册处理函数接口，并监听外部服务的调用，监听外部服务的调用后，回调给目标微服务处理；序列化框架304，用于供客户端模块302和服务端模块303进行调用参数和调用结果的序列化和反序列化；通信框架305，用于执行特定协议的调用，包括RPC框架、HTTP客户端、HTTP服务端和自定义通信框架。

图4为本申请实施例提供的目标微服务内的运行时模块的内部结构示意图，如图4所示，该运行时模块的内部结构可以包括API接口401、插件状态监听模块402、插件实例管理模块403、转发模块404、处理函数管理模块405。

其中，API接口401用于初始化和转发不同插件实例的调用接口和注册处理函数接口；插件状态监听模块402，用于监听插件的变动消息，通知插件实例管理模块403进行动态载入和卸载；插件实例管理模块403，用于动态载入和卸载插件到内存中，并向其他模块提供获取插件实例的接口；转发模块404，用于当微服务作为客户端回调时，根据目标微服务所使用的协议类型，选择对应的插件实例进行调用，该目标微服务所用的协议类型可以在第三方系统接入时，通过配置文件进行配置；处理函数管理模块405，用于保存所有外部服务向运行时模块注册的处理函数，后续在动态新增插件实例时，将所有处理函数注册到插件实例中。

图5为本申请实施例提供的一种微服务系统的数据处理方法的流程示意图，该方法的执行主体如前述的微服务系统。如图5所示，该方法包括：

S501、目标微服务接收第一外部服务的调用服务请求，将所述调用服务请求进行解析并转换为微服务系统对应的第一格式，得到调用服务请求中的请求参数。

可选的，目标微服务可以为微服务系统中的任意一个微服务，第一外部服务可以为任意一个第三方系统服务，不同的第三方系统服务的通信协议可以不同，可以有自己特定的通信协议。

可选的，对于不同的调用通信协议，例如RPC通信协议和HTTP协议所使用的参数个数和参数类型都不同，为了实现统一，可以对不同的调用通信协议的使用做特殊的限制，即对于不同的调用通信协议，可以使用固定的参数个数和参数类型，作为该微服务系统对应的第一格式，在本申请实施例中，可以使用一个Json入参和一个Json出参作为该微服务系统对应的第一格式。

示例性的，若第三方调用通信协议为RPC通信协议，则，在该微服务系统中，RPC调用参数和调用结果为序列化为字符串或字节流类型的Json数据；若第三方调用通信协议为HTTP通信协议，则在该微服务系统中，HTTP通信协议的请求参数和返回参数都序列化为Json数据。

可选的，目标微服务接收第一外部服务的调用请求，该调用请求中包括第一外部服务特定的通信协议，目标微服务将接收到的调用请求进行解析并转换为微服务系统对应的第一格式，得到调用服务请求中的请求参数，例如将第一外部服务特定的通信协议进行解析并转化为该目标微服务对应的Json数据。

S502、目标微服务根据调用服务请求中的请求参数调用对应的处理函数，由处理函数根据请求参数执行相应的操作并返回执行结果。

可选的，该处理函数的接口参数可以包括接口名以及回调函数地址，通过处理函数的接口可以回调对应的处理函数，目标微服务可以根据回调的处理函数进行相应的操作处理，并返回执行结果，该执行结果为该微服务系统对应的第一格式，例如，该执行结果为Json数据。

S503、目标微服务将执行结果转化为第一外部服务对应的第二格式，并发送至第一外部服务。

可选的，第一外部服务对应的第二格式可以为第一外部服务特定的通信协议的数据格式，则目标微服务将第一格式的执行结果转化为第一外部服务对应的第二格式后，将第二格式的执行结果发送至第一外部服务。

本申请实施例通过目标微服务接收第一外部服务的调用服务请求，将所述调用服务请求进行解析并转换为微服务系统对应的第一格式，得到调用服务请求中的请求参数；目标微服务根据调用服务请求中的请求参数调用对应的处理函数，由处理函数根据请求参数执行相应的操作并返回执行结果；目标微服务将执行结果转化为第一外部服务对应的第二格式，并发送至第一外部服务。通过将调用服务请求转换为微服务系统对应的格式并且调用目标微服务的注册处理函数执行相应的操作，可以使微服务系统实现以多种协议对外提供服务，避免在微服务系统中的每一个微服务中都需要添加第三方系统所需的协议，并且针对不同的第三方系统进行定制修改，极大的减少了工作量，从而从而避免处理多种协议的高复杂度。

图6为本申请实施例提供的外部服务注册处理函数的方法流程示意图，如图6所示，上述步骤S502目标微服务根据调用服务请求中的请求参数调用对应的处理函数，由处理函数根据请求参数执行相应的操作并返回执行结果之前，还可以包括：

S601、目标微服务接收目标微服务对应的上层应用发送的处理函数注册请求。

其中，该处理函数注册请求中包括处理函数以及处理函数的接口参数，该接口参数中可以包括处理函数接口名以及回调处理函数地址，通过该处理函数的接口参数可以对该处理函数进行回调。

具体地，目标微服务的对应的上层应用可以预先向目标微服务内的运行时模块注册处理函数，目标微服务内的运行时模块将接收到的注册处理函数保存至运行时模块中的处理函数管理模块405中，以便保持注册的处理函数的持久化，在后续动态新增插件实例时，可以通过处理函数管理模块405将处理函数读取出来，从而注册到运行时模块中的插件实例中。

S602、目标微服务将处理函数注册到目标微服务的第一目标插件实例中的服务端模块中。

其中，第一目标插件实例为支持第一外部服务的插件实例，每个插件实例的内部逻辑不一样，插件实例可以根据不同外部服务的不同通信协议，使用不同的插件实例逻辑执行处理函数。

具体地，目标微服务内的运行时模块可以从插件实例管理模块403获取所有的插件实例，遍历地通过各插件实例的API接口301中的注册处理函数接口将处理函数注册到各插件实例的服务端模块303中，在后续第一目标插件实例的服务端模块303接收到外部服务的调用时，可以对外部服务预先注册的处理函数进行回调并执行相应的操作。其中，目标微服务可以开放部分协议的服务，或者针对不同处理函数启动不同协议的服务。

可选的，上述步骤S502目标微服务根据调用服务请求中的请求参数调用对应的处理函数，由处理函数根据请求参数执行相应的操作并返回执行结果之前，还可以包括：

可选的，目标微服务接收第一外部服务发送的处理函数注册请求。

具体地，第一外部服务向目标微服务内的运行时模块注册处理函数，目标微服务内的运行时模块将接收到的注册处理函数保存至运行时模块中的处理函数管理模块405中，以便保持注册的处理函数的持久化，在后续动态新增插件实例时，可以通过处理函数管理模块405将处理函数读取出来，从而注册到运行时模块中的插件实例中。

可选的，目标微服务将处理函数注册到目标微服务的第一目标插件实例中的服务端模块中。

本实施例中，通过上层应用向目标微服务注册处理函数以及将外部服务的处理函数注册到目标微服务中的插件实例，可以根据不同的调用通信协议选择对应的插件实例执行处理函数。

可选的，上述步骤S501目标微服务接收第一外部服务的调用服务请求，将所述调用服务请求进行解析并转换为微服务系统对应的第一格式，可以包括：

可选的，目标微服务通过第一目标插件实例中的服务端模块303接收第一外部服务的调用服务请求，通过第一目标插件实例中的服务端模块303将调用服务请求进行解析并转换为微服务系统对应的第一格式，得到第一外部服务的请求参数。

可选的，目标微服务通过第一目标插件实例中的服务端模块303调用第一外部服务在服务端模块303中注册的处理函数，并且由处理函数根据第一外部服务的请求参数执行相应的操作，并返回执行结果。

图7为本申请实施例提供的另一种微服务系统的数据处理方法的流程示意图，如图7所示，该方法还包括：

S701、目标微服务根据第二外部服务的协议类型，调用支持第二外部服务的第二插件实例，由第二插件实例对第二外部服务的调用参数进行序列化，并通过序列化后的调用参数调用第二外部服务。

其中，该第二外部服务已将对应的处理函数注册到目标微服务的第二插件实例中，则微服务系统可以对该第二外部服务进行回调。

可选的，当目标微服务接收到回调第二外部服务的请求时，目标微服务利用运行时模块的API接口401进行回调，API接口401调用转发模块404的调用接口，转发模块404将第二外部服务对应的协议类型作为参数，从插件实例管理模块403中获取相应的插件实例作为第二插件实例，并调用第二插件实例的API接口301，通过第二插件实例的API接口301调用第二插件实例内部的客户端模块302的调用接口，第二插件实例的客户端模块302将Json类型的调用参数进行序列化，序列化为第二插件实例中的通信框架305所用的数据格式，通过通信框架305根据序列化后的调用参数调用第二外部服务。

S702、目标微服务通过第二插件实例将第二外部服务的调用结果进行反序列化。

可选的，目标微服务通过运行时模块中插件实例的序列化框架304对调用结果反序列化为Json数据，并将反序列化的调用结果返回至目标微服务。

本实施例中，通过调用支持对应外部服务的插件实例来实现外部服务的回调，可以实现微服务系统对外部服务的回调。

可选的，该方法还包括：

可选的，微服务系统中的插件管理微服务接收待安装插件的安装包。

可选的，当用户在前端插件管理页面1011上传一个待安装插件的安装包时，该待安装插件的安装包可以为一个压缩包，如zip、rar等格式的压缩包，该压缩包内有配置文件，配置文件中包括插件的信息，例如插件的插件名和插件的版本号，通过插件管理页面1011将待安装插件的安装包发送至微服务系统中的插件管理微服务内的插件管理模块1021，插件管理模块1021接收到待安装插件的安装包后，对安装包进行解析得到待安装插件的信息，根据解析后的待安装插件的信息对插件管理模块1021中的数据库进行更新。

可选的，插件管理微服务运行待安装插件的安装包，以将待安装插件安装至目标目录下。

可选的，插件管理微服务内的插件管理模块1021将待安装插件的安装包安装至目标目录中，该目标目录可以为全局插件目录，该全局插件目录可以通过注册表、环境变量等方式进行约定，则目标微服务可以通过注册表、环境变量等方式读取全局插件目录来加载目标插件。

本实施例中，通过将插件安装包安装至微服务系统中的插件管理微服务的目标目录中，可以通过插件管理微服务实现对插件的管理。

可选的，插件管理微服务运行待安装插件的安装包，以将待安装插件安装至目标目录之后，还可以包括：

可选的，目标微服务接收目标插件加载指令，该插件加载指令用于指示从插件管理微服务中加载目标插件。

可选的，当目标插件安装至插件管理微服务时，此时目标插件被存储在插件管理微服务中，若需要启用目标插件时，可以向插件管理微服务中的插件管理模块1021发送目标插件的加载指令，其中，目标插件的启用可以设置为上传后默认自动启用，则当目标插件上传后，插件被自动启用，也可以设置为上传后不启用，需要启动时则需要人工手动在插件管理页面1011启动插件。

可选的，当目标插件需要启用时，向插件管理模块1021发送加载指令，插件管理模块1021将接收到目标插件的加载指令后，通知其他微服务的运行时模块加载目标插件，其中，通知其他微服务的方式可以通过消息队列（Message Queue，简称MQ）进行通知，也可以通过插件对应的协议接口进行通知，也可以由其他微服务内的运行时模块直接监听目标目录中的插件变动来完成目标插件的加载。

可选的，目标微服务从插件管理微服务的目标目录下加载目标插件，以生成目标插件对应的插件实例。

可选的，目标微服务的运行时模块接收到插件管理模块1021发送的消息队列后，目标微服务的运行时模块从插件管理模块1021的目标目录下加载目标插件作为一个插件实例，并调用插件实例的初始化接口将插件实例进行初始化，则，插件实例被启用。每个插件实例中包含特定的通信框架，该通信框架可以用于和外部服务进行通信，例如HTTP通信协议对应的外部服务、RPC通信协议对应的外部服务。

本实施例中，微服务系统可以在不升级不重启系统的情况下通过动态加载插件实例来加载对应的协议。

可选的，该方法还包括：

可选的，目标微服务插件接收目标插件禁用指令。

其中，该目标插件禁用指令用于指示从目标微服务中卸载目标插件实例。当用户需要禁用目标插件时，可以在前端的插件管理页面1011对目标插件进行禁用，并且通过插件管理页面1011向插件管理微服务中的插件管理模块发送禁用指令，插件管理模块接收到目标插件禁用指令后，通知其他微服务内的运行时模块禁用目标插件对应的插件实例。

可选的，目标微服务调用目标插件实例的反初始化接口，以卸载目标插件实例。

可选的，目标微服务内的运行时模块接收到目标插件的禁用指令后，调用目标插件对应的插件实例的反初始化接口，通过反初始化接口卸载目标插件对应的插件实例，由于不同的插件实例具有相应的协议类型，则卸载插件实例的同时，插件实例对应的协议类型也相应的卸载。

本实施例中，微服务系统可以在不升级不重启系统的情况下通过动态卸载插件实例来卸载对应的协议。

图8为本申请实施例提供的一种微服务系统的数据处理方法的装置示意图，如图8所示，该装置包括：

接收装置801，用于接收第一外部服务的调用服务请求，将所述调用服务请求进行解析并转换为所述微服务系统对应的第一格式，得到所述调用服务请求中的请求参数，其中，所述目标微服务为所述微服务系统中的任意一个微服务；

调用装置802，用于根据所述调用服务请求中的请求参数调用对应的处理函数，由所述处理函数根据所述请求参数执行相应的操作并返回执行结果；

转化装置803，用于将所述执行结果转化为所述第一外部服务对应的第二格式并发送至所述第一外部服务。

可选的，调用装置802具体用于：

可选的，接收装置801具体用于：

可选的，调用装置802还具体用于：

可选的，接收装置801还具体用于：

可选的，接收装置801具体用于：

图9为本申请实施例提供的一种电子设备900的结构框图，该电子设备例如可以为前述实施例中所述的运行微服务系统的云端服务器。如图9所示，该电子设备可包括：处理器901、存储器902。

可选的，还可以包括总线903，其中，所述存储器902用于存储有所述处理器901可执行的机器可读指令（例如，图8中的装置中接收模块、调用模块、转化模块对应的执行指令等），当电子设备900运行时，所述处理器901与所述存储器902存储之间通过总线903通信，所述机器可读指令被所述处理器901执行时执行上述方法实施例中的方法步骤。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述微服务系统的数据处理方法实施例中的方法步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，RandomAccess Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。

Claims

1.一种微服务系统的数据处理方法，其特征在于，应用于微服务系统，所述微服务系统中部署多个微服务，所述方法包括：

2.根据权利要求1所述的微服务系统的数据处理方法，其特征在于，所述目标微服务根据所述调用服务请求中的请求参数调用对应的处理函数，由所述处理函数根据所述请求参数执行相应的操作并返回执行结果之前，还包括：

3.根据权利要求1所述的微服务系统的数据处理方法，其特征在于，所述目标微服务根据所述调用服务请求中的请求参数调用对应的处理函数，由所述处理函数根据所述请求参数执行相应的操作并返回执行结果之前，还包括：

4.根据权利要求2所述的微服务系统的数据处理方法，其特征在于，所述目标微服务接收第一外部服务的调用服务请求，将所述调用服务请求进行解析并转换为所述微服务系统对应的第一格式，包括：

5.根据权利要求1-4任一项所述的微服务系统的数据处理方法，其特征在于，所述方法还包括：

6.根据权利要求1所述的微服务系统的数据处理方法，其特征在于，所述方法还包括：

7.根据权利要求6所述的微服务系统的数据处理方法，其特征在于，所述插件管理微服务运行所述安装包，以将所述待安装插件安装至目标目录之后，所述方法还包括：

8.根据权利要求7所述的微服务系统的数据处理方法，其特征在于，所述方法还包括：

9.一种微服务系统的数据处理装置，其特征在于，包括：

调用装置，用于调用所述第一外部服务在所述目标微服务内预先注册的处理函数，由所述处理函数根据所述请求参数执行相应的操作并返回执行结果；

10.一种电子设备，其特征在于，包括存储器和处理器，所述存储器存储有所述处理器可执行的计算机程序，所述处理器执行所述计算机程序时实现上述权利要求1-8任一项所述的微服务系统的数据处理方法的步骤。