CN108306917A - 数据处理方法和装置、微服务模块的注册方法及装置 - Google Patents

Abstract

本申请公开了一种数据处理方法和装置、微服务模块的注册方法及装置。该数据处理方法应用于引入了微服务架构的业务系统；所述微服务架构的业务系统中设置有微服务网关；所述微服务网关被配置为具备指定的服务管控功能；该方法包括：微服务网关接收服务消费方发送的服务调用请求；根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的微服务模块；触发确定出的微服务模块响应所述服务消费方的请求进行相应的数据处理。本发明实施例至少能够解决现有技术中需要逐一为微服务模块分别配置所指定的服务管控功能，从而耗费较多的处理资源，且便利性较差的问题。

Description

数据处理方法和装置、微服务模块的注册方法及装置

技术领域

本申请涉及面向服务架构技术领域，尤其涉及一种数据处理方法和装置、微服务模块的注册方法及装置。

背景技术

目前，各个运营商通常通过接口平台和企业服务总线(Enterprise Service Bus，ESB)以解决业务系统间的集成问题。对于单一应用建设模式下的业务系统，业务系统其内部多个模块紧耦合，无法拆分部署，关联依赖性较大。为解决这一问题，相关技术提出将在业务系统引入微服务架构引入业务系统。

所述微服务架构由多个微服务模块构成，一个微服务模块一般完成某个特定的功能，此如订单管理、客户管理等。每个微服务模块都是一个微型应用，有着自己六边形架构，包括商业逻辑和各种应用程序编程接口(即Application Programming Interface，API，简称接口)。有的微服务模块通过网页的用户界面(User Interface，UI)与用户进行交互，从而为用户提供服务；有的微服务模块则通过暴露接口(Application ProgrammingInterface，API)被别的微服务模块或者应用客户端所用。如图1所示，为了完成一项业务，业务系统中的微服务模块之间通过相互调用而进行数据交互的示意图。

引入了微服务架构后的业务系统存在下述缺陷：

业务系统被打散为多个自治的微服务模块，为使得由微服务模块构成的业务系统能够具备指定的服务管控功能，现有技术中，要求每个微服务模块都分别具备指定的服务管控功能。其中，所述服务管控功能，包括但不限于微服务模块工作状态的监控功能、负载均衡功能以及日志生成与日志记录功能中的至少一种。

为使每个微服务模块都具备所述指定的服务管控功能，需要技术人员逐一为每个微服务模块分别配置所述指定的服务管控功能，从而耗费较多的处理资源，且便利性较差。

发明内容

本申请实施例提供一种数据处理方法和装置，以及微服务模块的注册方法和装置，用以解决现有技术中为使得引入了微服务架构后的业务系统具备指定的服务管控功能，需要逐一为微服务模块分别配置所述指定的服务管控功能，从而耗费较多的处理资源，且便利性较差的问题。

本发明一个实施例提供了一种数据处理方法，应用于引入了微服务架构的业务系统；所述微服务架构的业务系统中设置有微服务网关；所述微服务网关被配置为具备指定的服务管控功能；所述方法包括：

微服务网关接收服务消费方发送的服务调用请求；

根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的微服务模块，所述信息包括所述业务系统的微服务模块的IP地址和微服务提供接口的名称；

触发确定出的微服务模块响应所述服务消费方的服务调用请求进行相应的数据处理。

本发明另一个实施例提供了一种微服务模块的注册方法，应用于引入了微服务架构的业务系统；所述微服务架构的业务系统中设置有微服务网关；所述微服务网关被配置为具备指定的服务管控功能；所述方法包括：

微服务网关接收所述业务系统的微服务模块发送的注册信息；

将所述注册信息进行存储；

所述注册信息包括所述业务系统的微服务模块的IP地址以及微服务提供接口的名称；

所述注册信息由所述业务系统的微服务模块调用设置在微服务模块中的软件开发工具包SDK所包含的服务注册接口而获取到。

本发明另一个实施例提供了一种数据处理装置，应用于引入了微服务架构的业务系统；所述微服务架构的业务系统中设置有微服务网关；所述微服务网关被配置为具备指定的服务管控功能；所述装置包括：

服务调用请求接收模块，用于微服务网关接收服务消费方发送的服务调用请求；

查询模块，用于根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的微服务模块，所述信息包括所述业务系统的微服务模块的IP地址和微服务提供接口的名称；

触发模块，用于触发确定出的微服务模块响应所述服务消费方的请求进行相应的数据处理。

本发明另一个实施例提供了一种微服务模块的注册装置，应用于引入了微服务架构的业务系统；所述微服务架构的业务系统中设置有微服务网关；所述微服务网关被配置为具备指定的服务管控功能；所述装置包括：

接收模块，用于接收所述业务系统的微服务模块发送的注册信息；

注册信息存储模块，用于将所述注册信息进行存储；

所述注册信息包括所述业务系统的微服务模块的IP地址以及微服务提供接口的名称，并且所述注册信息由所述业务系统的微服务模块调用设置在微服务模块中的软件开发工具包SDK所包含的服务注册接口而获取到。

根据本发明的实施例，由于微服务模块构成的业务系统中设置的微服务网关具备指定的服务管控功能，并且，服务消费方发送的服务调用请求会通过微服务网关统一进行接收，并由微服务网关根据服务调用请求触发微服务模块相应的数据处理，因此，微服务网关可以基于统一接收的服务调用请求或微服务网关与各微服务模块之间建立的连接，实现所述指定的服务管控功能，从而使得业务系统能够具备所述指定的服务管控功能。相较于现有技术，由于本方案仅需在微服务网关中设置指定的服务管控功能，就能够使业务系统具备指定的服务管控功能，无需技术人员逐一为每个微服务模块分别配置所述指定的服务管控功能，因此，本申请实施例提供的方案可以节省处理资源耗费；并且，由于业务系统中微服务网关的数量远小于微服务模块的数量，因此，在微服务网关中设置指定的服务管控功能，相较于在业务系统中的各微服务模块中设置指定的服务管控功能较为便利。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为现有技术中业务系统中的微服务模块之间通过相互调用而进行数据交互的示意图；

图2为本申请实施例提供的一种数据处理方法的实现流程示意图；

图3为申请实施例提供的一种数据处理方法在实际中的应用流程图；

图4为本申请实施例提供的一种微服务模块的注册方法的实现流程示意图；

图5为本申请实施例提供的一种数据处理装置的结构示意图；

图6为本申请实施例提供的一种微服务模块的注册装置的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

为解决现有技术中为使得引入了微服务架构后的业务系统具备指定的服务管控功能，需要逐一为微服务模块分别配置所述指定的服务管控功能，从而耗费较多的处理资源，且便利性较差的问题，本申请实施例1提供一种数据处理方法。

该方法应用于引入了微服务架构的业务系统，所述微服务架构的业务系统中设置有微服务网关。所述微服务网关，是指在引入了微服务架构或者说具备微服务架构的业务系统中设置的网关。该微服务网关，与业务系统中包含的各个微服务模块之间均建立连接。该连接，可以但不限于是基于传输控制协议/因特网互联协议(Transmission ControlProtocol/Internet Protocol，TCP/IP)协议的连接。

本申请实施例中，为使得所述业务系统能够具备指定的服务管控功能，所述微服务网关，被配置为具备指定的服务管控功能。其中，服务管控功能包括但不限于服务调用请求的监控功能、日志生成与日志记录功能以及缓存功能中的至少一种。在实际应用中，可以通过技术人员将实现所述指定的服务管控功能的代码设置到微服务网关中，使得微服务网关具备所述指定的服务管控功能。由后文的介绍可知，服务消费方向业务系统发送的服务调用请求，首先会由该微服务网关统一进行接收，微服务网关可以基于统一接收的服务调用请求，或者基于微服务网关与各微服务模块之间建立的连接，实现所述指定的服务管控功能。此如，可以基于微服务网关与各微服务模块之间建立的连接，实现对于服务模块工作状态进行监控的功能；基于根据服务消费方发送的服务调用请求生成日志的功能；以及基于微服务网关与各微服务模块之间建立的连接，进行负载均衡的功能。

具体的，实施例1提供的一种数据处理方法的实现流程示意图如图2所示。所述方法包括如下主要步骤：

步骤201、微服务网关接收服务消费方发送的服务调用请求。

在本实施例中，服务消费方，此如可以是用户使用的个人终端，或者是所述个人终端上运行的客户端。

服务调用请求用于请求调用微服务网关触发微服务模块提供服务。

步骤202、微服务网关根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的微服务模块。

在本实施例中，所述业务系统的微服务模块的信息可以包括所述业务系统的微服务模块的IP地址和微服务提供接口的名称。这两种信息，可以采用对应存储的方式存储在微服务网关中，以便查找。

所述的微服务提供接口，是微服务模块可对外暴露的接口。微服务网关或者服务消费方通过调用微服务提供接口，可以触发微服务模块提供服务。

本申请实施例中，所述的微服务请求中，可以包含请求调用的微服务提供接口的名称(后称第一名称)。微服务网关根据第一名称，可以查找预先存储的所述业务系统的微服务模块的信息中是否存在与该第一名称相同的微服务提供接口的名称(后称第二名称)，若存在，则从预先存储的所述业务系统的微服务模块的信息中，确定与第二名称对应存储的业务系统的微服务模块的IP地址。确定出的IP地址所对应的微服务模块，即为与所述服务调用请求相对应的微服务模块。

需要说明的是，所述业务系统的微服务模块的IP地址和微服务提供接口的名称通过以下方式进行存储：

步骤21、所述微服务网关接收所述业务系统的微服务模块发送的注册信息。这里所说的注册信息，就包括微服务模块的IP地址和微服务提供接口的名称。

其中，为配合微服务网关的一些功能实现，技术人员在开发微服务模块时，可以在微服务模块中配置软件开发工具包(Software Development Kit，SDK)。该SDK中包含用于实现预定逻辑的代码，该些代码可由微服务模块执行，从而实现相应的预定逻辑；此外，该SDK中还可以包含微服务模块的微服务提供接口的名称。微服务模块在开发完成后，通过Docker容器(所述Docker容器是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化)或手工进行动态部署。所谓动态部署，即将微服务模块部署到微服务网关所在的网络中，并建立起微服务模块与微服务网关的TCP/IP连接。

当微服务模块接入微服务网关所在的网络后，微服务模块通过执行前文所述的代码，实现下述预定逻辑：

触发调用SDK中的服务注册接口，以获得所述服务注册接口返回的IP地址。

其中，该服务注册接口的作用，在于获取所述网络中有效的IP地址，作为部署完成的微服务模块在所述网络中使用的IP地址。

针对IP地址的获取方式而言，比如，该服务注册接口可以通过调用SDK中标准的Java接口(接口名称为：netInterface.getInetAddresses)来获取所述网络的有效的IP地址，作为部署完成的微服务模块在所述网络中所使用的IP地址。

步骤22、微服务网关将所述注册信息进行存储。

其中，微服务网关接收到微服务模块发送的注册信息后，将所述注册信息写入微服务网关的服务注册库中。服务注册库，是微服务网关中的用于保存微服务模块发送的注册信息的数据库。

注册信息的保存形式，比如可以为：http：//10.0.0.1/QueryUserAPI。其中，10.0.0.1为IP地址，QueryUserAPI为微服务提供接口的名称。

在一种实施方式中，所述业务系统的微服务网关在将所述业务系统的微服务模块的IP地址和微服务提供接口的名称进行存储后，为保证根据保存的微服务模块的信息所确定出的对应于服务调用请求的微服务模块确实可用(即处于正常的工作状态)，避免确定出的微服务模块不可用而导致处理资源浪费，在一种实施方式中，将所述注册信息进行存储后，网关服务器还可以执行下述步骤：

步骤31、微服务网关对存储的注册信息对应的微服务模块的服务提供状态是否正常进行验证。

其中，微服务模块的服务提供状态，是指微服务模块是否能正常提供服务的状态，可以有正常和异常两种。

所述微服务模块，可以将自身的服务提供状态的信息，发送给微服务网关，以便微服务网关对微服务模块的服务提供状态是否正常进行验证。

若微服务网关验证出微服务模块的服务提供状态为正常，执行步骤32；若微服务网关验证出微服务模块的服务提供状态为异常，则微服务网关从已经保存的注册信息中，将服务提供状态异常的微服务模块的注册信息删除。

步骤32、微服务网关将服务提供状态正常的微服务模块的注册信息存储到指定存储空间。所述指定存储空间，用于存储根据接收到服务调用请求所查询的所述微服务模块的信息所在的存储空间。该存储空间此如可以是路由表。

由于路由表通过微服务网关进行管理，因此微服务网关可动态刷新路由表中保存的微服务模块的信息(注册信息)。此如，动态刷新方式可以如下：

微服务网关可以对微服务模块的服务提供状态进行监控，并根据监控结果，更新所述路由表。以某一微服务模块为例，若对它的服务提供状态进行监控得到的监控结果为服务提供状态发生变化(如由正常变为异常)，则微服务网关可以更新所述路由表。比如，若由正常变为异常，则从路由表中删除该微服务模块的注册信息。

本申请通过对所述注册信息对应的微服务模块的服务提供状态进行验证，并将验证得出服务提供状态正常的微服务模块的注册信息进行更新存储，实现了微服务网关中存储的业务系统的微服务模块的信息的动态刷新，提高了微服务网关性能。

为了实现微服务网关对于微服务模块的健康监测，所述数据处理方法还可以包括以下步骤：

步骤41、微服务网关通过调用所述业务系统的微服务模块中设置的SDK中的服务可用状态探针接口，尝试获取所述业务系统的微服务模块的心跳检测数据帧。

所述服务可用状态探针接口的作用，在于获取所述业务系统的微服务模块的心跳检测数据帧。

在本实施例中，业务系统的微服务模块可以周期生成一个心跳检测数据帧，微服务网关通过调用微服务模块中设置的软件开发工具包SDK中的服务可用状态探针接口预定间隔时间获取心跳检测数据帧。其中，所述周期可以为“5s、”“10s”或“5min”。相应的，所述预定间隔时间可以为“5s”、“10s”或“5min”。

步骤42、微服务网关根据是否能成功获取到所述心跳检测数据帧，更新所述预先存储的所述业务系统的微服务模块的信息。

在本实施例中，若微服务网关通过调用微服务模块中设置的软件开发工具包SDK中的服务可用状态探针接口，在预定间隔时间内获取到心跳检测数据帧，则判定微服务网管成功获取到所述心跳检测数据帧；若微服务网关通过调用微服务模块中设置的软件开发工具包SDK中的服务可用状态探针接口，未在预定间隔时间内获取到心跳检测数据帧，则判定微服务网管未能成功获取到所述心跳检测数据帧；若微服务网关通过调用微服务模块中设置的软件开发工具包SDK中的服务可用状态探针接口，在预定间隔时间内获取到心跳检测数据帧的次数超过预定次数，则判定微服务网管未能成功获取到所述心跳检测数据帧；其中，预定次数可以为3次。

若微服务网关成功获取到所述心跳检测数据帧，则更新预先存储的所述业务系统的微服务模块的信息。否则，微服务网关与微服务模块之间的交互异常，微服务网关将微服务模块提供的注册信息进行删除。

本申请通过获取业务系统的微服务模块定时发出的心跳检测数据帧，来实时监督微服务网关与微服务模块之间交互情况。当在预定间隔时间内获取到心跳检测数据帧时，更新预先存储的所述业务系统的微服务模块的信息，实现了实时健康监测业务系统；当在预定间隔时间内未获取到心跳检测数据帧时，将微服务模块提供的注册信息进行删除，微服务网关不会路由新的服务调取请求至故障的微服务模块上，从而实现了业务系统故障转移。因此，提高了业务系统可用性。

进一步的，步骤202的具体实现可以采用以下步骤：

步骤51、所述微服务网关根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的各候选微服务模块。

针对“微服务网关根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息”的具体实现方式而言，前文已经介绍过微服务网关如何根据所述服务调用请求，查询到与所述第一名称相同的第二名称，此处不再赘述。需要说明的是，查询到的第二名称所对应的微服务模块的IP地址，可能对应于至少两个微服务模块。在这种情况下，考虑到为保证业务系统的稳定性，可以采用下文所述的步骤52，按照负载均衡原则，从所述至少两个微服务模块中选取微服务模块来提供服务。

为便于描述，下文将所述至少两个微服务模块称为各候选微服务模块。

步骤52、微服务网关按照负载均衡原则，从所述各候选微服务模块中选取负载满足预定条件的候选微服务模块，作为与所述服务调用请求相对应的微服务模块。

在本实施例中，负载均衡原则可以是基于轮询或哈希(HASH)算法实现的负载均衡原则。由于基于轮询或哈希算法的负载均衡是一种标准的负载均衡算法，此处不再赘述。

在执行步骤52之后，执行步骤203，即触发确定出的微服务模块响应所述服务消费方的请求进行相应的数据处理。其中，触发微服务模块响应服务消费方的请求进行相应的数据处理可以采用以下方式实现：

第一种实现方式：将所述确定出的微服务模块的IP地址发送给所述服务消费方，以使得所述服务消费方根据所述地址调用所述确定出的微服务模块进行所述数据处理。

采用此方式，服务消费方在向微服务网关发送服务调用请求(称为第一请求)后，根据微服务网关返回的确定出的微服务模块，对该微服务模块的微服务提供接口直接发起服务调用请求(称为第二请求)。采用这样的方式，微服务模块响应于第二请求执行数据处理(如增删改查中的至少一种)后，将得到的服务输出信息(也即处理结果)，直接发送给服务消费方，从而微服务网关并不能获取到服务输出信息。

基于该方式的特点，该方式可以称为“访问流和数据流分离的方式”。这里所说的访问流，是指第一请求；而数据流，则是指服务输出信息。

第二种实现方式：将所述服务调用请求发送给所述确定出的微服务模块，以使得所述确定出的微服务模块响应于所述服务调用请求进行相应的数据处理。

采用此方式，微服务网关直接将所述服务调用请求路由至确定出的微服务模块，从而该微服务模块在响应于所述服务调用请求进行数据处理后，会将得到的服务输出信息发送给微服务网关，再由微服务网关将服务输出信息转发至服务消费方。

采用该方式，微服务网关能获取到服务输出信息。基于该方式的特点，该方式可以称为“访问流和数据流不分离的方式”。这里所说的访问流，是指所述服务调用请求；而数据流，则是指服务输出信息。

当采用“访问流和数据流不分离的方式”时，为生成与服务调用相关的日志，进一步的，所述数据处理方法还包括以下步骤：

步骤61、微服务网关对所述服务消费方在访问所述确定出的微服务模块时输入的信息进行存储。

其中，针对“在访问所述确定出的微服务模块时输入的信息”举例而言，若服务调用请求调用的是微服务模块的查询类服务接口，那么，相应的输入的消息可以为查询条件(相应的服务输出信息为具体的查询结果)，而若服务调用请求调用的是微服务模块的导人类接口服务，那么，相应的输入的消息是期望导入的数据集(相应的服务输出信息为导入成功与否的信息)。

微服务网关可以将所述服务消费方在访问所述确定出的微服务模块时输入的信息存储在微服务网关的消息中间件中。

步骤62、微服务网关对所述确定出的微服务模块进行所述数据处理后生成的服务输出信息进行存储。

在本实施例中，微服务网关触发确定出的微服务模块响应所述服务消费方的请求进行相应的数据处理后，将生成的服务输出信息存储在所述微服务网关的消息中间件中。

步骤63、微服务网关根据所述输入的信息以及所述服务输出信息，生成包含所述输入的信息以及所述服务输出信息的访问日志。

在本实施例中，微服务网关根据消息中间件中存储的服务调用请求和服务输出信息生成微服务网关访问日志，以便实现服务调用请求和服务输出信息的持久化记录。其中，所述访问日志的形式可以为文件或数据库表。

综上可知，由于微服务模块构成的业务系统中设置的微服务网关具备指定的服务管控功能，并且，服务消费方发送的服务调用请求会通过微服务网关统一进行接收，并由微服务网关根据服务调用请求触发微服务模块相应的数据处理，因此，微服务网关可以基于统一接收的服务调用请求或微服务网关与各微服务模块之间建立的连接，实现所述指定的服务管控功能，从而使得业务系统能够具备所述指定的服务管控功能。相较于现有技术，由于本方案仅需在微服务网关中设置指定的服务管控功能，就能够使业务系统具备指定的服务管控功能，无需技术人员逐一为每个微服务模块分别配置所述指定的服务管控功能，因此，本申请实施例提供的方案可以节省处理资源耗费；并且，由于业务系统中微服务网关的数量远小于微服务模块的数量，因此，在微服务网关中设置指定的服务管控功能，相较于在业务系统中的各微服务模块中设置指定的服务管控功能较为便利。

需要说明的是，虽然本申请实施例1中以方法的执行主体为某电脑为例，对该方法进行了介绍，但本领域技术人员可以理解，本申请实施例1所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。此如，步骤201和步骤202的执行主体可以为同一设备；又此如，步骤201的执行主体可以为设备1，步骤202的执行主体可以为设备2；等等。

将本申请实施例提供的方法应用到实际中，可以产生如图3所示的可应用于微服务架构的业务系统中的一种数据处理方法流程。该流程具体可以包括下述步骤：

步骤301、微服务网关接收消费方发送的服务调用请求；

步骤302、微服务网关根据服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的微服务模块；

步骤303、触发确定出的微服务模块响应所述服务消费方的请求进行相应的数据处理，并将服务输出信息发送给消费方。

步骤304、微服务网关提供软件开发工具包SDK配置给的微服务模块；

步骤305、微服务模块通过Docker容器进行动态部署，微服务网关调用软件开发工具包SDK的服务注册接口，获取动态部署完成的微服务模块的IP地址及微服务提供接口的名称；

步骤306、微服务网关将所述微服务模块的IP地址及微服务提供接口的名称进行存储。

实施例2

本申请实施例2提供微服务模块的注册方法，应用于引入了微服务架构的业务系统，所述微服务架构的业务系统中设置有微服务网关，所述微服务网关被配置为具备指定的服务管控功能。其中，服务管控功能包括但不限于服务调用请求的监控功能、日志生成与日志记录功能以及缓存功能中的至少一种。

具体的，实施例2提供的一种微服务模块的注册方法的实现流程示意图如图4所示。所述方法包括如下主要步骤：

步骤401、微服务网关接收所述业务系统的微服务模块发送的注册信息。这里所说的注册信息，就包括微服务模块的IP地址和微服务提供接口的名称。

其中，为配合微服务网关的一些功能实现，技术人员在开发微服务模块时，可以在微服务模块中配置软件开发工具包(Software Development Kit，SDK)。该SDK中包含用于实现预定逻辑的代码，该些代码可由微服务模块执行，从而实现相应的预定逻辑；此外，该SDK中还可以包含微服务模块能够使用的微服务提供接口的名称。其中，微服务模块能够使用的微服务提供接口，是微服务模块可对外暴露的接口。微服务网关或者服务消费方通过调用微服务提供接口，可以触发微服务模块提供服务。

微服务模块在开发完成后，通过Docker容器(所述Docker容器是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化)或手工进行动态部署。所谓动态部署，即将微服务模块部署到微服务网关所在的网络中，并建立起微服务模块与微服务网关的TCP/IP连接。

当微服务模块接入微服务网关所在的网络后，微服务模块通过执行前文所述的代码，实现下述预定逻辑：

触发调用SDK中的服务注册接口，以获得所述服务注册接口返回的IP地址。

其中，该服务注册接口的作用，在于获取所述网络中有效的IP地址，作为部署完成的微服务模块在所述网络中使用的IP地址。

针对IP地址的获取方式而言，此如，该服务注册接口可以通过调用SDK中标准的Java接口(接口名称为：netInterface.getInetAddresses)来获取所述网络的有效的IP地址，作为部署完成的微服务模块在所述网络中所使用的IP地址。

步骤402、将所述注册信息进行存储。

其中，微服务网关接收到微服务模块发送的注册信息后，将所述注册信息写入微服务网关的服务注册库中。服务注册库，是微服务网关中的用于保存微服务模块发送的注册信息的数据库。

注册信息的保存形式，此如可以为：http：//10.0.0.1/QueryUserAPI。其中，10.0.0.1为IP地址，QueryUserAPI为微服务提供接口的名称。

在一种实施方式中，所述业务系统的微服务网关在将所述业务系统的微服务模块的IP地址和微服务提供接口的名称进行存储后，为保证根据保存的微服务模块的信息所确定出的对应于服务调用请求的微服务模块确实可用(即处于正常的工作状态)，避免确定出的微服务模块不可用而导致处理资源浪费，在一种实施方式中，将所述注册信息进行存储后，网关服务器还可以执行下述步骤：

步骤403、所述微服务网关对存储的注册信息对应的微服务模块的服务提供状态是否正常进行验证。

其中，微服务模块的服务提供状态，是指微服务模块是否能正常提供服务的状态，可以有正常和异常两种。

所述微服务模块，可以将自身的服务提供状态的信息，发送给微服务网关，以便微服务网关对微服务模块的服务提供状态是否正常进行验证。

若微服务网关验证出微服务模块的服务提供状态为正常，执行步骤302；若微服务网关验证出微服务模块的服务提供状态为异常，则微服务网关从已经保存的注册信息中，将服务提供状态异常的微服务模块的注册信息删除。

步骤404、将服务提供状态正常的微服务模块的注册信息存储到指定存储空间。所述指定存储空间，用于存储根据接收到服务调用请求所查询的所述微服务模块的信息所在的存储空间。该存储空间此如可以是路由表。

由于路由表通过微服务网关进行管理，因此微服务网关可动态刷新路由表中保存的微服务模块的信息(注册信息)。。此如，动态刷新方式可以如下：

微服务网关可以对微服务模块的服务提供状态进行监控，并根据监控结果，更新所述路由表。以某一微服务模块为例，若对它的服务提供状态进行监控得到的监控结果为服务提供状态发生变化(如由正常变为异常)，则微服务网关可以更新所述路由表。此如，若由正常变为异常，则从路由表中删除该微服务模块的注册信息。

本申请通过对所述注册信息对应的微服务模块的服务提供状态进行验证，并将验证得出服务提供状态正常的微服务模块的注册信息进行更新存储，实现了微服务网关中存储的业务系统的微服务模块的信息的动态刷新，提高了微服务网关性能。

由于微服务模块构成的业务系统中设置的微服务网关具备指定的服务管控功能，并且，服务消费方发送的服务调用请求会通过微服务网关统一进行接收，并由微服务网关根据服务调用请求触发微服务模块相应的数据处理，因此，微服务网关可以基于统一接收的服务调用请求或微服务网关与各微服务模块之间建立的连接，实现所述指定的服务管控功能，从而使得业务系统能够具备所述指定的服务管控功能。相较于现有技术，由于本方案仅需在微服务网关中设置指定的服务管控功能，就能够使业务系统具备指定的服务管控功能，无需技术人员逐一为每个微服务模块分别配置所述指定的服务管控功能，因此，本申请实施例提供的方案可以节省处理资源耗费；并且，由于业务系统中微服务网关的数量远小于微服务模块的数量，因此，在微服务网关中设置指定的服务管控功能，相较于在业务系统中的各微服务模块中设置指定的服务管控功能较为便利。

实施例3

以上为本申请实施例提供的数据处理方法，基于同样的思路，本申请实施例还提供了相应的数据处理装置，如图5所示。

图5为本申请实施例提供的数据处理装置结构示意图，所述数据处理装置，应用于引入了微服务架构的业务系统；所述微服务架构的业务系统中设置有微服务网关；所述微服务网关被配置为具备指定的服务管控功能；所述数据处理装置具体包括：

服务调用请求接收模块501，用于微服务网关接收服务消费方发送的服务调用请求；

查询模块502，用于根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的微服务模块；所述信息，包括所述业务系统的微服务模块的IP地址和微服务提供接口的名称；

触发模块503，用于触发确定出的微服务模块响应所述服务消费方的请求进行相应的数据处理。

其中，所述业务系统的微服务模块的信息包括所述业务系统的微服务模块的注册信息；

所述装置还包括：

注册信息接收模块504，用于所述微服务网关接收所述业务系统的微服务模块发送的注册信息；

第一存储模块505，用于将所述注册信息进行存储；

所述注册信息，包括所述业务系统的微服务模块的IP地址以及微服务提供接口的名称；

所述注册信息，由所述业务系统的微服务模块调用设置在微服务模块中的软件开发工具包SDK所包含的服务注册接口而获取到。

其中，所述业务系统的微服务模块的信息还包括所述业务系统的微服务模块的服务提供状态；

所述查询模块502包括：

查询单元，用于所述微服务网关根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的各候选微服务模块；

选取单元，用于按照负载均衡原则，从所述各候选微服务模块中选取负载满足预定条件的候选微服务模块，作为与所述服务调用请求相对应的微服务模块。

所述触发模块503包括：

第一发送单元，用于将所述服务调用请求发送给所述确定出的微服务模块，以使得所述确定出的微服务模块响应于所述服务调用请求进行相应的数据处理。

所述装置还包括：

第三存储模块508，用于对所述服务消费方在访问所述确定出的微服务模块时输入的信息进行存储；

第四存储模块509，用于对所述确定出的微服务模块进行所述数据处理后生成的服务输出信息进行存储；

生成模块510，用于根据所述输入的信息以及所述服务输出信息，生成访问日志。

所述触发模块503包括：

第二发送单元，用于将所述确定出的微服务模块的IP地址发送给所述服务消费方，以使得所述服务消费方根据所述IP地址调用所述确定出的微服务模块进行所述数据处理。

其中，所述预先存储的所述业务系统的微服务模块的信息，包括预先存储的所述业务系统的微服务模块的服务提供状态；

所述装置还包括：

获取模块511，用于微服务网关通过调用所述业务系统的微服务模块中设置的软件开发工具包SDK中的服务可用状态探针接口，尝试获取所述业务系统的微服务模块的心跳检测数据帧；

更新模块512，用于根据是否能成功获取到所述心跳检测数据帧，更新所述预先存储的所述业务系统的微服务模块的信息。

由于微服务模块构成的业务系统中设置的微服务网关具备指定的服务管控功能，并且，服务消费方发送的服务调用请求会通过微服务网关统一进行接收，并由微服务网关根据服务调用请求触发微服务模块相应的数据处理，因此，微服务网关可以基于统一接收的服务调用请求或微服务网关与各微服务模块之间建立的连接，实现所述指定的服务管控功能，从而使得业务系统能够具备所述指定的服务管控功能。相较于现有技术，由于本方案仅需在微服务网关中设置指定的服务管控功能，就能够使业务系统具备指定的服务管控功能，无需技术人员逐一为每个微服务模块分别配置所述指定的服务管控功能，因此，本申请实施例提供的方案可以节省处理资源耗费；并且，由于业务系统中微服务网关的数量远小于微服务模块的数量，因此，在微服务网关中设置指定的服务管控功能，相较于在业务系统中的各微服务模块中设置指定的服务管控功能较为便利。

实施例4

以上为本申请实施例提供的微服务模块的注册方法，基于同样的思路，本申请实施例还提供了相应的微服务模块的注册装置，如图6所示。

图6为本申请实施例提供的微服务模块的注册装置结构示意图，所述微服务模块的注册装置，应用于引入了微服务架构的业务系统；所述微服务架构的业务系统中设置有微服务网关；所述微服务网关被配置为具备指定的服务管控功能；所述微服务模块的注册装置包括：

接收模块601，用于微服务网关接收所述业务系统的微服务模块发送的注册信息；

注册信息存储模块602，用于将所述注册信息进行存储；

所述注册信息，包括所述业务系统的微服务模块的IP地址以及微服务提供接口的名称；

所述注册信息，由所述业务系统的微服务模块调用设置在微服务模块中的软件开发工具包SDK所包含的服务注册接口而获取到。

所述装置还包括：

验证模块，用于所述微服务网关对所述注册信息对应的微服务模块的服务提供状态是否正常进行验证；

确定模块，用于若所述注册信息对应的微服务模块的服务提供状态正常正常，则在接收到包含所述微服务提供接口的名称的服务调用请求时，根据所述注册信息确定用于响应所述服务调用请求的微服务模块。

由于微服务模块构成的业务系统中设置的微服务网关具备指定的服务管控功能，并且，服务消费方发送的服务调用请求会通过微服务网关统一进行接收，并由微服务网关根据服务调用请求触发微服务模块相应的数据处理，因此，微服务网关可以基于统一接收的服务调用请求或微服务网关与各微服务模块之间建立的连接，实现所述指定的服务管控功能，从而使得业务系统能够具备所述指定的服务管控功能。相较于现有技术，由于本方案仅需在微服务网关中设置指定的服务管控功能，就能够使业务系统具备指定的服务管控功能，无需技术人员逐一为每个微服务模块分别配置所述指定的服务管控功能，因此，本申请实施例提供的方案可以节省处理资源耗费；并且，由于业务系统中微服务网关的数量远小于微服务模块的数量，因此，在微服务网关中设置指定的服务管控功能，相较于在业务系统中的各微服务模块中设置指定的服务管控功能较为便利。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (18)

1.一种数据处理方法，其特征在于，应用于引入了微服务架构的业务系统，所述微服务架构的业务系统中设置有微服务网关，所述微服务网关被配置为具备指定的服务管控功能，所述方法包括：

微服务网关接收服务消费方发送的服务调用请求；

根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的微服务模块，所述信息包括所述业务系统的微服务模块的IP地址和微服务提供接口的名称；

触发确定出的微服务模块响应所述服务消费方的服务调用请求进行相应的数据处理。

2.根据权利要求1中所述的方法，其特征在于，所述业务系统的微服务模块的信息通过下述方式进行存储：

所述微服务网关接收所述业务系统的微服务模块发送的注册信息；

将所述注册信息进行存储；

其中，所述注册信息包括所述业务系统的微服务模块的因特网互联协议IP地址以及微服务提供接口的名称，并且所述注册信息由所述业务系统的微服务模块调用设置在微服务模块中的软件开发工具包SDK所包含的服务注册接口而获取到。

3.如权利要求1或2所述的方法，其特征在于，根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的微服务模块，包括：

所述微服务网关根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的各候选微服务模块；

按照负载均衡原则，从所述各候选微服务模块中选取负载满足预定条件的候选微服务模块，作为与所述服务调用请求相对应的微服务模块。

4.如权利要求3所述的方法，其特征在于，触发确定出的微服务模块响应所述服务消费方的请求进行相应的数据处理，包括：

将所述服务调用请求发送给所述确定出的微服务模块，以使得所述确定出的微服务模块响应于所述服务调用请求进行相应的数据处理。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

对所述服务消费方在访问所述确定出的微服务模块时输入的信息进行存储；

对所述确定出的微服务模块进行所述数据处理后生成的服务输出信息进行存储；

根据所述输入的信息以及所述服务输出信息，生成访问日志。

6.如权利要求3所述的方法，其特征在于，触发确定出的微服务模块响应所述服务消费方的请求进行相应的数据处理，包括：

将所述确定出的微服务模块的IP地址发送给所述服务消费方，以使得所述服务消费方根据所述IP地址调用所述确定出的微服务模块进行所述数据处理。

7.如权利要求1所述的方法，其特征在于，所述预先存储的所述业务系统的微服务模块的信息，包括预先存储的所述业务系统的微服务模块的服务提供状态；

所述方法还包括：

微服务网关通过调用所述业务系统的微服务模块中设置的软件开发工具包SDK中的服务可用状态探针接口，尝试获取所述业务系统的微服务模块的心跳检测数据帧；

根据是否能成功获取到所述心跳检测数据帧，更新所述预先存储的所述业务系统的微服务模块的信息。

8.一种微服务模块的注册方法，其特征在于，应用于引入了微服务架构的业务系统中设置的微服务网关，所述微服务网关被配置为具备指定的服务管控功能，所述方法包括：

微服务网关接收所述业务系统的微服务模块发送的注册信息；

将所述注册信息进行存储；

所述注册信息包括所述业务系统的微服务模块的IP地址以及微服务提供接口的名称；

所述注册信息由所述业务系统的微服务模块调用设置在微服务模块中的软件开发工具包SDK所包含的服务注册接口而获取到。

9.如权利要求8所述的方法，其特征在于，将所述注册信息进行存储后，所述方法还包括：

所述微服务网关对所述注册信息对应的微服务模块的服务提供状态是否正常进行验证，若正常，则在接收到包含所述微服务提供接口的名称的服务调用请求时，根据所述注册信息确定用于响应所述服务调用请求的微服务模块。

10.一种数据处理装置，其特征在于，应用于引入了微服务架构的业务系统，所述微服务架构的业务系统中设置有微服务网关，所述微服务网关被配置为具备指定的服务管控功能，所述装置包括：

服务调用请求接收模块，用于微服务网关接收服务消费方发送的服务调用请求；

查询模块，用于根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的微服务模块，所述信息包括所述业务系统的微服务模块的IP地址和微服务提供接口的名称；

触发模块，用于触发确定出的微服务模块响应所述服务消费方的请求进行相应的数据处理。

11.如权利要求10中所述的装置，其特征在于，所述装置还包括：

注册信息接收模块，用于所述微服务网关接收所述业务系统的微服务模块发送的注册信息；

第一存储模块，用于将所述注册信息进行存储；

所述注册信息，包括所述业务系统的微服务模块的因特网互联协议IP地址以及微服务提供接口的名称，并且所述注册信息由所述业务系统的微服务模块调用设置在微服务模块中的软件开发工具包SDK所包含的服务注册接口而获取到。

12.如权利要求10或11所述的装置，其特征在于，所述查询模块包括：

查询单元，用于所述微服务网关根据所述服务调用请求，查询预先存储的所述业务系统的微服务模块的信息，以确定与所述服务调用请求相对应的各候选微服务模块；

选取单元，用于按照负载均衡原则，从所述各候选微服务模块中选取负载满足预定条件的候选微服务模块，作为与所述服务调用请求相对应的微服务模块。

13.如权利要求12所述的装置，其特征在于，所述触发模块包括：

第一发送单元，用于将所述服务调用请求发送给所述确定出的微服务模块，以使得所述确定出的微服务模块响应于所述服务调用请求进行相应的数据处理。

14.如权利要求13所述的装置，其特征在于，所述装置还包括：

第三存储模块，用于对所述服务消费方在访问所述确定出的微服务模块时输入的信息进行存储；

第四存储模块，用于对所述确定出的微服务模块进行所述数据处理后生成的服务输出信息进行存储；

生成模块，用于根据所述输入的信息以及所述服务输出信息，生成访问日志。

15.如权利要求12所述的装置，其特征在于，所述触发模块包括：

第二发送单元，用于将所述确定出的微服务模块的IP地址发送给所述服务消费方，以使得所述服务消费方根据所述IP地址调用所述确定出的微服务模块进行所述数据处理。

16.如权利要求10所述的装置，其特征在于，所述预先存储的所述业务系统的微服务模块的信息，包括预先存储的所述业务系统的微服务模块的服务提供状态；

所述装置还包括：

获取模块，用于微服务网关通过调用所述业务系统的微服务模块中设置的软件开发工具包SDK中的服务可用状态探针接口，尝试获取所述业务系统的微服务模块的心跳检测数据帧；

更新模块，用于根据是否能成功获取到所述心跳检测数据帧，更新所述预先存储的所述业务系统的微服务模块的信息。

17.一种微服务模块的注册装置，其特征在于，应用于引入了微服务架构的业务系统中设置的微服务网关，所述微服务网关被配置为具备指定的服务管控功能，所述装置包括：

接收模块，用于接收所述业务系统的微服务模块发送的注册信息；

注册信息存储模块，用于将所述注册信息进行存储；

所述注册信息包括所述业务系统的微服务模块的IP地址以及微服务提供接口的名称，并且所述注册信息由所述业务系统的微服务模块调用设置在微服务模块中的软件开发工具包SDK所包含的服务注册接口而获取到。

18.如权利要求17所述的装置，其特征在于，所述装置还包括：

验证模块，用于对所述注册信息对应的微服务模块的服务提供状态是否正常进行验证；

确定模块，用于若所述注册信息对应的微服务模块的服务提供状态正常正常，则在接收到包含所述微服务提供接口的名称的服务调用请求时，根据所述注册信息确定用于响应所述服务调用请求的微服务模块。