CN115640143A - 微服务处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明涉及人工智能技术领域，提供一种微服务处理方法、装置、电子设备及存储介质，所述方法包括：基于多个微服务之间的合并关系，对多个微服务的启动应用包进行打包，得到多个目标启动应用包；当侦测到任意一个目标启动应用包启动时，基于每个微服务与部署的微服务之间的映射关系，对每个微服务中的远程接口的接口名称进行转换，并将转换结果加载到内存中；响应于接收的HTTP请求，获取页面的加载数据；基于加载数据从内存中获取目标微服务，并基于目标微服执行其他微服务调用。本发明通过在微服务启动时对远程接口进行转换，避免造成远程接口调用的性能损失，提高了微服务的处理效率。

Description

微服务处理方法、装置、电子设备及存储介质

技术领域

本发明涉及人工智能技术领域，具体涉及一种微服务处理方法、装置、电子设备及存储介质。

背景技术

微服务架构的生态组件已经非常成熟，现有应用系统大都采用微服务架构设计，一般会根据业务或功能来进行服务拆分，拆分成一个个微服务，每个微服务独立部署，互不影响，当前比较流行的微服务架构就有spring cloud，其中关键的服务间调用方法是通过feign组件完成。

然而，通过微服务之间的调用组件feign，在调用时，使用动态代理来做转换，根据映射关系调到正确的服务上，没有从源码层面上解决，且是在微服务接口真正调用时，才去找映射关系，对远程接口的调用造成一定的性能损耗，导致微服务处理效率低下。

因此，有必要提出一种可以快速进行微服务处理的方法。

发明内容

鉴于以上内容，有必要提出一种微服务处理方法、装置、电子设备及存储介质，通过在微服务启动时对远程接口进行转换，避免造成远程接口调用的性能损失，提高了微服务的处理效率。

本发明的第一方面提供一种微服务处理方法，所述方法包括：

接收多个微服务及所述多个微服务之间的合并关系；

基于所述合并关系，对所述多个微服务的启动应用包进行打包，得到多个目标启动应用包；

当侦测到任意一个目标启动应用包启动时，读取所述任意一个目标启动应用包中的每个微服务与部署的微服务之间的映射关系；

基于所述每个微服务与部署的微服务之间的映射关系，对所述每个微服务中的远程接口的接口名称进行转换，并将转换结果加载到内存中；

响应于接收的HTTP请求，获取页面的加载数据；

基于所述加载数据从所述内存中获取目标微服务，并基于所述目标微服执行其他微服务调用。

可选地，所述读取所述任意一个目标启动应用包中的每个微服务与部署的微服务之间的映射关系包括：

执行所述任意一个目标启动应用包中的第一代码；

基于所述第一代码从配置中心中读取所述每个微服务与部署的微服务之间的映射关系。

可选地，所述基于所述每个微服务与部署的微服务之间的映射关系，对所述每个微服务的远程接口的接口名称进行转换包括：

识别所述每个微服务与部署的微服务之间的映射关系；

根据所述映射关系识别每个微服务的远程接口的接口名称是否需要转换；

当识别到每个微服务的远程接口存在合并关系时，确定每个微服务的远程接口的接口名称需要转换，将每个微服务的远程接口的接口名称转换为对应部署的微服务的接口名称；

当识别到每个微服务的远程接口不存在合并关系时，确定每个微服务的远程接口的接口名称不需要转换。

可选地，所述基于所述加载数据从所述内存中获取目标微服务包括：

从所述加载数据中获取加载的微服务的服务名称；

根据所述微服务的服务名称，通过微服务网关路由到对应的目标微服务上。

可选地，所述基于所述目标微服执行其他微服务调用包括：

从配置中心提取所述目标微服务的启动应用包中的第二代码；

根据所述第二代码确定所述目标微服务调用的其他微服务，并基于所述其他微服务的远程接口发起调用。

可选地，在所述基于所述目标微服执行其他微服务调用之前，所述方法还包括：

从注册中心的微服务列表中提取其他微服务的远程接口；

根据所述其他微服务与部署的微服务之间的映射关系对所述其他微服务的远程接口进行识别；

当识别到所述其他微服务的远程接口存在合并关系时，获取所述其他微服务的原始微服务的服务名称对应的第一IP地址和第一服务端口；

将所述其他微服务的原始微服务的服务名称对应的第一IP地址和第一服务端口替换为部署的微服务的服务名称对应的第二IP地址和第二服务端口。

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

基于所述多个微服务之间的合并关系，编写配置文件，并将所述配置文件存储至配置中心。

本发明的第二方面提供一种微服务处理装置，所述装置包括：

接收模块，用于接收多个微服务及所述多个微服务之间的合并关系；

打包模块，用于基于所述合并关系，对所述多个微服务的启动应用包进行打包，得到多个目标启动应用包；

读取模块，用于当侦测到任意一个目标启动应用包启动时，读取所述任意一个目标启动应用包中的每个微服务与部署的微服务之间的映射关系；

转换模块，用于基于所述每个微服务与部署的微服务之间的映射关系，对所述每个微服务中的远程接口的接口名称进行转换，并将转换结果加载到内存中；

获取模块，用于响应于接收的HTTP请求，获取页面的加载数据；

调用模块，用于基于所述加载数据从所述内存中获取目标微服务，并基于所述目标微服执行其他微服务调用。

本发明的第三方面提供一种电子设备，所述电子设备包括处理器和存储器，所述处理器用于执行所述存储器中存储的计算机程序时实现所述的微服务处理方法。

本发明的第四方面提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现所述的微服务处理方法。

综上所述，本发明所述的微服务处理方法、装置、电子设备及存储介质，能够推动智慧城市的建设，应用于智慧建筑、智慧安防、智慧社区、智慧生活、物联网等领域，通过根据多个微服务之间的合并关系，对所述多个微服务的启动应用包进行打包，减少了微服务的数量，进而减少了资源的浪费。当侦测到任意一个目标启动应用包启动时，基于所述每个微服务与部署的微服务之间的映射关系，通过扫描微服务启动应用包中的远程接口，并对所述远程接口的接口名称进行转换，真正调用时无需对微服务的远程接口再进行映射匹配，可以直接调用，并不会造成远程接口的性能损失，提高了微服务远程接口的调用效率及准确率，进而提高了微服务的处理效率。响应于接收的HTTP请求，获取页面的加载数据，基于所述加载数据从所述内存中获取目标微服务，并基于所述目标微服执行其他微服务调用，无需对远程接口做映射匹配，避免了远程接口调用的性能损失，提高了微服务的处理效率。

附图说明

图1是本发明实施例一提供的微服务处理方法的流程图。

图2是本发明实施例二提供的微服务处理装置的结构图。

图3是本发明实施例三提供的电子设备的结构示意图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施例对本发明进行详细描述。需要说明的是，在不冲突的情况下，本发明的实施例及实施例中的特征可以相互组合。

除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明。

实施例一

图1是本发明实施例一提供的微服务处理方法的流程图。

在本实施例中，所述微服务处理方法可以应用于电子设备中，对于需要进行微服务处理的电子设备，可以直接在电子设备上集成本发明的方法所提供的微服务处理的功能，或者以软件开发工具包(Software Development Kit，SDK)的形式运行在电子设备中。

本发明实施例可以基于人工智能技术对相关的数据进行获取和处理。其中，人工智能(Artificial Intelligence，AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。

人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理技术、操作/交互系统、机电一体化等技术。人工智能软件技术主要包括计算机视觉技术、机器人技术、生物识别技术、语音处理技术、自然语言处理技术以及机器学习、深度学习等几大方向。

如图1所示，所述微服务处理方法具体包括以下步骤，根据不同的需求，该流程图中步骤的顺序可以改变，某些可以省略。

101，接收多个微服务及所述多个微服务之间的合并关系。

本实施例中，客户在进行微服务处理时，通过客户端发送微服务处理的报文信息，其中，所述微服务处理的报文信息中包含有多个微服务及所述多个微服务之间的合并关系，其中，所述合并关系是客户基于实际需求设置的，例如，客户的系统中有10个微服务，正常需要10台服务器，但是客户目前只有5台服务器，故需要根据项目需求，设置所述10个微服务的合并关系，根据合并关系对所述10个微服务进行合并处理，最终将所述10个服务器部署至5台服务器中。

102，基于所述合并关系，对所述多个微服务的启动应用包进行打包，得到多个目标启动应用包。

本实施例中，所述目标启动应用包是基于合并关系，对所述多个微服务的启动应用包进行打包得到的，其中，每个目标启动应用包中可以包含有一个微服务的启动应用包或者多个微服务合并后的启动应用包。

进一步地，所述方法还包括：

基于所述多个微服务之间的合并关系，编写配置文件，并将所述配置文件存储至配置中心。

本实施例中，可以根据多个微服务之间的合并关系，为所述多个微服务编写配置文件。

示例性地，合并关系为：微服务B和微服务C合并为微服务X，根据合并关系将所述微服务B的启动应用包和微服务C的启动应用包进行合并，并增加配置，将所述微服务B的服务名称和实际部署的微服务X的服务名称做映射，及将所述微服务C的服务名称和实际部署的微服务X的服务名称做映射，其中，映射左边为原始微服务的服务名称，右侧为合并后的部署的微服务的服务名称，配置后的映射关系为：微服务B：微服务X；微服务C：微服务X。

本实施例中，所述配置文件中包含有每个微服务的映射关系、合并关系、启动应用包等，将上述写好的配置文件存储至配置中心，便于后续进行微服务处理时，可以直接在配置中心拉取需要的数据信息。

在其他可选的实施例中，合并后的微服务的服务名称也不一定需要使用新的服务名称，可以采用合并之前的原始微服务的服务名称，例如：微服务A、微服务B和微服务C进行合并，合并后的微服务的服务名称还可以为A，其中，合并后的微服务的服务名称取决于下一步的代码组织结构。

本实施例中，通过根据多个微服务之间的合并关系，对所述多个微服务的启动应用包进行打包，减少了微服务的数量，帮助客户节省成本和资源，尤其是很多中、小客户，节省资源的同时，也减少他们后续运维的难度和复杂度。

103，当侦测到任意一个目标启动应用包启动时，读取所述任意一个目标启动应用包中的每个微服务与部署的微服务之间的映射关系。

本实施例中，由于每个目标启动应用包中可以包含有一个微服务的启动应用包或者多个微服务合并后的启动应用包，在侦测到任意一个目标应用启动包启动时，需要读取所述目标启动应用包中的所有微服务及每个微服务与部署的微服务之间的映射关系，快速确定出每个微服务是否被合并，便于后续进行微服务调用时，获取正确的调用接口，提高了微服务调用的准确率。

在一个可选的实施例中，所述读取所述任意一个目标启动应用包中的每个微服务与部署的微服务之间的映射关系包括：

执行所述任意一个目标启动应用包中的第一代码；

基于所述第一代码从配置中心中读取所述每个微服务与部署的微服务之间的映射关系。

本实施例中，所述第一代码是指所述任意一个目标启动应用包中的公共代码，所述公共代码为通用代码，每个微服务中都包含有公共代码。

示例性地，配置中心中存储有微服务与部署的微服务之间的映射关系：微服务A：部署的微服务A；微服务B：部署的微服务X；微服务C：部署的微服务X；其中，合并关系为微服务B和微服务C合并得到微服务X。

104，基于所述每个微服务与部署的微服务之间的映射关系，对所述每个微服务中的远程接口的接口名称进行转换，并将转换结果加载到内存中。

本实施例中，所述内存可以为Springbean容器。

在一个可选的实施例中，所述基于所述每个微服务与部署的微服务之间的映射关系，对所述每个微服务的远程接口的接口名称进行转换包括：

识别所述每个微服务与部署的微服务之间的映射关系；

根据所述映射关系识别每个微服务的远程接口的接口名称是否需要转换；

当识别到每个微服务的远程接口存在合并关系时，确定每个微服务的远程接口的接口名称需要转换，将每个微服务的远程接口的接口名称转换为对应部署的微服务的接口名称。

进一步地，所述识别所述每个微服务与部署的微服务之间的映射关系还包括：

当识别到每个微服务的远程接口不存在合并关系时，确定每个微服务的远程接口的接口名称不需要转换。

示例性地，当识别到微服务B的远程接口存在合并关系，所述微服务B和微服务C进行合并得到微服务X，根据合并关系将微服务B的远程接口的接口名称转换为X。

本实施例中，在微服务启动时，通过扫描微服务启动应用包中的远程接口，并对所述远程接口的接口名称进行转换，真正调用时无需对微服务的远程接口再进行映射匹配，可以直接调用，并不会造成远程接口的性能损失，提高了微服务远程接口的调用效率及准确率，进而提高了微服务的处理效率。

105，响应于接收的HTTP请求，获取页面的加载数据。

本实施例中，在微服务合并之后，客户使用时，通过客户端发送HTTP请求，其中，所述HTTP请求中包含有页面的加载数据，例如，当客户在页面上点击了下单按钮时，获取下单按钮的加载数据。

106，基于所述加载数据从所述内存中获取目标微服务，并基于所述目标微服执行其他微服务调用。

本实施例中，目标微服务是指加载数据中的微服务的服务名称对应的微服务，不同的加载数据对应不同的微服务的服务名称。

在一个可选的实施例中，所述基于所述加载数据从所述内存中获取目标微服务包括：

从所述加载数据中获取加载的微服务的服务名称；

根据所述微服务的服务名称，通过微服务网关路由到对应的目标微服务上。

在一个可选的实施例中，所述基于所述目标微服执行其他微服务调用包括：

从所述配置中心提取所述目标微服务的启动应用包中的第二代码；

根据所述第二代码确定所述目标微服务调用的其他微服务，并基于所述其他微服务的远程接口发起调用。

本实施例中，所述第二代码是指每个微服务的启动应用包中的业务逻辑代码，其中，所述第二代码中包含有业务逻辑，可以通过第二代码获知每个微服务调用的其他微服务。

在一个可选的实施例中，在所述基于所述目标微服执行其他微服务调用之前，所述方法还包括：

从注册中心的微服务列表中提取其他微服务的远程接口；

根据所述其他微服务与部署的微服务之间的映射关系对所述其他微服务的远程接口进行识别；

当识别到所述其他微服务的远程接口存在合并关系时，获取所述其他微服务的原始微服务的服务名称对应的第一IP地址和第一服务端口；

将所述其他微服务的原始微服务的服务名称对应的第一IP地址和第一服务端口替换为部署的微服务的服务名称对应的第二IP地址和第二服务端口。

示例性地，若A微服务为订单微服务A，根据订单微服务A的业务逻辑可以知道订单微服务A生成订单后，开始调用库存微服务B，在订单微服务调用库存微服务B的远程接口之前，从Springbean内存中获取库存微服务B的bean实例，从所述bean实例发现库存微服务B的远程接口的接口名称被转换为部署的X微服务的接口名称时，从注册中心的微服务列表中提取部署的X微服务的IP地址和服务端口，将所述库存微服务的IP地址和服务端口替换为部署的X微服务对应的IP地址和服务端口，在替换之后，部署的X微服务接收远程接口的调用，成功扣减库存，返回订单服务成功。

本实施例中，通过在微服务启动时就对远程接口进行了改写，真正调用时不用再做映射匹配，避免了远程接口调用的性能损失，提高了微服务的处理效率。

在其他可选的实施例中，为了实现各个微服务之间自由的合并打包，通过将每个微服务的代码拆分为三个maven模块，具体地：cmpc-a-main//只有一个启动类，只是一个外壳；cmpc-a-service//所有的业务逻辑代码都在这里面；cmpc-a-remote-api//a服务对外提供的所有@FeignClient接口，其中main工程的maven pom文件引用了service工程，service工程引用了remote-api工程，启动应用包打包时，以main工程去打包和部署的。

示例性地，如果要将微服务a和微服务c合并部署，则只需建一个cmpc-d-main的壳子工程(不需要cmpc-d-servcie和cmpc-d-remote-api模块)，cmpc-d-main的maven pom文件中引用cmpc-a-service和cmpc-c-service的业务模块即可。也可以直接将微服务c合并到微服务a中，只需在a-main模块的maven pom文件中引用cmpc-c-servie模块即可。无论采用拿着合并方式，原有的每个微服务的remote-api和service代码及结构都不需要做任何改动，当微服务b调用微服务a的FeignClien接口时，会根据微服务a名称找到映射配置中的实际部署的微服务d，然后从注册中心找到微服务d对应的IP地址和服务端口，进而发起调用。

本实施例中，通过将每个微服务的代码拆解为3个maven模块，实现了各个微服务之间的自由的合并打包，提高了合并打包的多样性和灵活性。

综上所述，本实施例所述的微服务处理方法，通过根据多个微服务之间的合并关系，对所述多个微服务的启动应用包进行打包，减少了微服务的数量，进而减少了资源的浪费。当侦测到任意一个目标启动应用包启动时，基于所述每个微服务与部署的微服务之间的映射关系，通过扫描微服务启动应用包中的远程接口，并对所述远程接口的接口名称进行转换，真正调用时无需对微服务的远程接口再进行映射匹配，可以直接调用，并不会造成远程接口的性能损失，提高了微服务远程接口的调用效率及准确率，进而提高了微服务的处理效率。响应于接收的HTTP请求，获取页面的加载数据，基于所述加载数据从所述内存中获取目标微服务，并基于所述目标微服执行其他微服务调用，无需对远程接口做映射匹配，避免了远程接口调用的性能损失，提高了微服务的处理效率。

实施例二

图2是本发明实施例二提供的微服务处理装置的结构图。

在一些实施例中，所述微服务处理装置20可以包括多个由程序代码段所组成的功能模块。所述微服务处理装置20中的各个程序段的程序代码可以存储于电子设备的存储器中，并由所述至少一个处理器所执行，以执行(详见图1描述)微服务处理的功能。

本实施例中，所述微服务处理装置20根据其所执行的功能，可以被划分为多个功能模块。所述功能模块可以包括：接收模块201、打包模块202、编写模块203、读取模块204、转换模块205、获取模块206及调用模块207。本发明所称的模块是指一种能够被至少一个处理器所执行并且能够完成固定功能的一系列计算机可读指令段，其存储在存储器中。在本实施例中，关于各模块的功能将在后续的实施例中详述。

接收模块201，用于接收多个微服务及所述多个微服务之间的合并关系。

本实施例中，客户在进行微服务处理时，通过客户端发送微服务处理的报文信息，其中，所述微服务处理的报文信息中包含有多个微服务及所述多个微服务之间的合并关系，其中，所述合并关系是客户基于实际需求设置的，例如，客户的系统中有10个微服务，正常需要10台服务器，但是客户目前只有5台服务器，故需要根据项目需求，设置所述10个微服务的合并关系，根据合并关系对所述10个微服务进行合并处理，最终将所述10个服务器部署至5台服务器中。

打包模块202，用于基于所述合并关系，对所述多个微服务的启动应用包进行打包，得到多个目标启动应用包。

本实施例中，所述目标启动应用包是基于合并关系，对所述多个微服务的启动应用包进行打包得到的，其中，每个目标启动应用包中可以包含有一个微服务的启动应用包或者多个微服务合并后的启动应用包。

编写模块203，用于基于所述多个微服务之间的合并关系，编写配置文件，并将所述配置文件存储至配置中心。

本实施例中，可以根据多个微服务之间的合并关系，为所述多个微服务编写配置文件。

示例性地，合并关系为：微服务B和微服务C合并为微服务X，根据合并关系将所述微服务B的启动应用包和微服务C的启动应用包进行合并，并增加配置，将所述微服务B的服务名称和实际部署的微服务X的服务名称做映射，及将所述微服务C的服务名称和实际部署的微服务X的服务名称做映射，其中，映射左边为原始微服务的服务名称，右侧为合并后的部署的微服务的服务名称，配置后的映射关系为：微服务B：微服务X；微服务C：微服务X。

本实施例中，所述配置文件中包含有每个微服务的映射关系、合并关系、启动应用包等，将上述写好的配置文件存储至配置中心，便于后续进行微服务处理时，可以直接在配置中心拉取需要的数据信息。

在其他可选的实施例中，合并后的微服务的服务名称也不一定需要使用新的服务名称，可以采用合并之前的原始微服务的服务名称，例如：微服务A、微服务B和微服务C进行合并，合并后的微服务的服务名称还可以为A，其中，合并后的微服务的服务名称取决于下一步的代码组织结构。

本实施例中，通过根据多个微服务之间的合并关系，对所述多个微服务的启动应用包进行打包，减少了微服务的数量，帮助客户节省成本和资源，尤其是很多中、小客户，节省资源的同时，也减少他们后续运维的难度和复杂度。

读取模块204，用于当侦测到任意一个目标启动应用包启动时，读取所述任意一个目标启动应用包中的每个微服务与部署的微服务之间的映射关系。

本实施例中，由于每个目标启动应用包中可以包含有一个微服务的启动应用包或者多个微服务合并后的启动应用包，在侦测到任意一个目标应用启动包启动时，需要读取所述目标启动应用包中的所有微服务及每个微服务与部署的微服务之间的映射关系，快速确定出每个微服务是否被合并，便于后续进行微服务调用时，获取正确的调用接口，提高了微服务调用的准确率。

在一个可选的实施例中，所述读取模块204读取所述任意一个目标启动应用包中的每个微服务与部署的微服务之间的映射关系包括：

执行所述任意一个目标启动应用包中的第一代码；

基于所述第一代码从配置中心中读取所述每个微服务与部署的微服务之间的映射关系。

本实施例中，所述第一代码是指所述任意一个目标启动应用包中的公共代码，所述公共代码为通用代码，每个微服务中都包含有公共代码。

示例性地，配置中心中存储有微服务与部署的微服务之间的映射关系：微服务A：部署的微服务A；微服务B：部署的微服务X；微服务C：部署的微服务X；其中，合并关系为微服务B和微服务C合并得到微服务X。

转换模块205，用于基于所述每个微服务与部署的微服务之间的映射关系，对所述每个微服务中的远程接口的接口名称进行转换，并将转换结果加载到内存中。

本实施例中，所述内存可以为Springbean容器。

在一个可选的实施例中，所述转换模块205基于所述每个微服务与部署的微服务之间的映射关系，对所述每个微服务的远程接口的接口名称进行转换包括：

识别所述每个微服务与部署的微服务之间的映射关系；

根据所述映射关系识别每个微服务的远程接口的接口名称是否需要转换；

当识别到每个微服务的远程接口存在合并关系时，确定每个微服务的远程接口的接口名称需要转换，将每个微服务的远程接口的接口名称转换为对应部署的微服务的接口名称。

进一步地，所述识别所述每个微服务与部署的微服务之间的映射关系还包括：

当识别到每个微服务的远程接口不存在合并关系时，确定每个微服务的远程接口的接口名称不需要转换。

示例性地，当识别到微服务B的远程接口存在合并关系，所述微服务B和微服务C进行合并得到微服务X，根据合并关系将微服务B的远程接口的接口名称转换为X。

本实施例中，在微服务启动时，通过扫描微服务启动应用包中的远程接口，并对所述远程接口的接口名称进行转换，真正调用时无需对微服务的远程接口再进行映射匹配，可以直接调用，并不会造成远程接口的性能损失，提高了微服务远程接口的调用效率及准确率，进而提高了微服务的处理效率。

获取模块206，用于响应于接收的HTTP请求，获取页面的加载数据。

本实施例中，在微服务合并之后，客户使用时，通过客户端发送HTTP请求，其中，所述HTTP请求中包含有页面的加载数据，例如，当客户在页面上点击了下单按钮时，获取下单按钮的加载数据。

调用模块207，用于基于所述加载数据从所述内存中获取目标微服务，并基于所述目标微服执行其他微服务调用。

本实施例中，目标微服务是指加载数据中的微服务的服务名称对应的微服务，不同的加载数据对应不同的微服务的服务名称。

在一个可选的实施例中，所述调用模块207基于所述加载数据从所述内存中获取目标微服务包括：

从所述加载数据中获取加载的微服务的服务名称；

根据所述微服务的服务名称，通过微服务网关路由到对应的目标微服务上。

在一个可选的实施例中，所述调用模块207基于所述目标微服执行其他微服务调用包括：

从所述配置中心提取所述目标微服务的启动应用包中的第二代码；

根据所述第二代码确定所述目标微服务调用的其他微服务，并基于所述其他微服务的远程接口发起调用。

本实施例中，所述第二代码是指每个微服务的启动应用包中的业务逻辑代码，其中，所述第二代码中包含有业务逻辑，可以通过第二代码获知每个微服务调用的其他微服务。

在一个可选的实施例中，在所述基于所述目标微服执行其他微服务调用之前，从注册中心的微服务列表中提取其他微服务的远程接口；根据所述其他微服务与部署的微服务之间的映射关系对所述其他微服务的远程接口进行识别；当识别到所述其他微服务的远程接口存在合并关系时，获取所述其他微服务的原始微服务的服务名称对应的第一IP地址和第一服务端口；将所述其他微服务的原始微服务的服务名称对应的第一IP地址和第一服务端口替换为部署的微服务的服务名称对应的第二IP地址和第二服务端口。

示例性地，若A微服务为订单微服务A，根据订单微服务A的业务逻辑可以知道订单微服务A生成订单后，开始调用库存微服务B，在订单微服务调用库存微服务B的远程接口之前，从Springbean内存中获取库存微服务B的bean实例，从所述bean实例发现库存微服务B的远程接口的接口名称被转换为部署的X微服务的接口名称时，从注册中心的微服务列表中提取部署的X微服务的IP地址和服务端口，将所述库存微服务的IP地址和服务端口替换为部署的X微服务对应的IP地址和服务端口，在替换之后，部署的X微服务接收远程接口的调用，成功扣减库存，返回订单服务成功。

本实施例中，通过在微服务启动时就对远程接口进行了改写，真正调用时不用再做映射匹配，避免了远程接口调用的性能损失，提高了微服务的处理效率。

在其他可选的实施例中，为了实现各个微服务之间自由的合并打包，通过将每个微服务的代码拆分为三个maven模块，具体地：cmpc-a-main//只有一个启动类，只是一个外壳；cmpc-a-service//所有的业务逻辑代码都在这里面；cmpc-a-remote-api//a服务对外提供的所有@FeignClient接口，其中main工程的maven pom文件引用了service工程，service工程引用了remote-api工程，启动应用包打包时，以main工程去打包和部署的。

示例性地，如果要将微服务a和微服务c合并部署，则只需建一个cmpc-d-main的壳子工程(不需要cmpc-d-servcie和cmpc-d-remote-api模块)，cmpc-d-main的maven pom文件中引用cmpc-a-service和cmpc-c-service的业务模块即可。也可以直接将微服务c合并到微服务a中，只需在a-main模块的maven pom文件中引用cmpc-c-servie模块即可。无论采用拿着合并方式，原有的每个微服务的remote-api和service代码及结构都不需要做任何改动，当微服务b调用微服务a的FeignClien接口时，会根据微服务a名称找到映射配置中的实际部署的微服务d，然后从注册中心找到微服务d对应的IP地址和服务端口，进而发起调用。

本实施例中，通过将每个微服务的代码拆解为3个maven模块，实现了各个微服务之间的自由的合并打包，提高了合并打包的多样性和灵活性。

综上所述，本实施例所述的微服务处理装置，通过根据多个微服务之间的合并关系，对所述多个微服务的启动应用包进行打包，减少了微服务的数量，进而减少了资源的浪费。当侦测到任意一个目标启动应用包启动时，基于所述每个微服务与部署的微服务之间的映射关系，通过扫描微服务启动应用包中的远程接口，并对所述远程接口的接口名称进行转换，真正调用时无需对微服务的远程接口再进行映射匹配，可以直接调用，并不会造成远程接口的性能损失，提高了微服务远程接口的调用效率及准确率，进而提高了微服务的处理效率。响应于接收的HTTP请求，获取页面的加载数据，基于所述加载数据从所述内存中获取目标微服务，并基于所述目标微服执行其他微服务调用，无需对远程接口做映射匹配，避免了远程接口调用的性能损失，提高了微服务的处理效率。

实施例三

参阅图3所示，为本发明实施例三提供的电子设备的结构示意图。在本发明较佳实施例中，所述电子设备3包括存储器31、至少一个处理器32、至少一条通信总线33及收发器34。

本领域技术人员应该了解，图3示出的电子设备的结构并不构成本发明实施例的限定，既可以是总线型结构，也可以是星形结构，所述电子设备3还可以包括比图示更多或更少的其他硬件或者软件，或者不同的部件布置。

在一些实施例中，所述电子设备3是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的电子设备，其硬件包括但不限于微处理器、专用集成电路、可编程门阵列、数字处理器及嵌入式设备等。所述电子设备3还可包括客户设备，所述客户设备包括但不限于任何一种可与客户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互的电子产品，例如，个人计算机、平板电脑、智能手机、数码相机等。

需要说明的是，所述电子设备3仅为举例，其他现有的或今后可能出现的电子产品如可适应于本发明，也应包含在本发明的保护范围以内，并以引用方式包含于此。

在一些实施例中，所述存储器31用于存储程序代码和各种数据，例如安装在所述电子设备3中的微服务处理装置20，并在电子设备3的运行过程中实现高速、自动地完成程序或数据的存取。所述存储器31包括只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable Read-Only Memory，PROM)、可擦除可编程只读存储器(ErasableProgrammable Read-Only Memory，EPROM)、一次可编程只读存储器(One-timeProgrammable Read-Only Memory，OTPROM)、电子擦除式可复写只读存储器(Electrically-Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(CompactDisc Read-Only Memory，CD-ROM)或其他光盘存储器、磁盘存储器、磁带存储器、或者能够用于携带或存储数据的计算机可读的任何其他介质。

在一些实施例中，所述至少一个处理器32可以由集成电路组成，例如可以由单个封装的集成电路所组成，也可以是由多个相同功能或不同功能封装的集成电路所组成，包括一个或者多个中央处理器(Central Processing unit，CPU)、微处理器、数字处理芯片、图形处理器及各种控制芯片的组合等。所述至少一个处理器32是所述电子设备3的控制核心(Control Unit)，利用各种接口和线路连接整个电子设备3的各个部件，通过运行或执行存储在所述存储器31内的程序或者模块，以及调用存储在所述存储器31内的数据，以执行电子设备3的各种功能和处理数据。

在一些实施例中，所述至少一条通信总线33被设置为实现所述存储器31以及所述至少一个处理器32等之间的连接通信。

尽管未示出，所述电子设备3还可以包括给各个部件供电的电源(比如电池)，可选的，电源可以通过电源管理装置与所述至少一个处理器32逻辑相连，从而通过电源管理装置实现管理充电、放电、以及功耗管理等功能。电源还可以包括一个或一个以上的直流或交流电源、再充电装置、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。所述电子设备3还可以包括多种传感器、蓝牙模块、Wi-Fi模块等，在此不再赘述。

应该了解，所述实施例仅为说明之用，在专利申请范围上并不受此结构的限制。

上述以软件功能模块的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，电子设备，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分。

在进一步的实施例中，结合图2，所述至少一个处理器32可执行所述电子设备3的操作装置以及安装的各类应用程序(如所述的微服务处理装置20)、程序代码等，例如，上述的各个模块。

所述存储器31中存储有程序代码，且所述至少一个处理器32可调用所述存储器31中存储的程序代码以执行相关的功能。例如，图2中所述的各个模块是存储在所述存储器31中的程序代码，并由所述至少一个处理器32所执行，从而实现所述各个模块的功能以达到微服务处理的目的。

示例性的，所述程序代码可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器31中，并由所述处理器32执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令段，该指令段用于描述所述程序代码在所述电子设备3中的执行过程。例如，所述程序代码可以被分割成接收模块201、打包模块202、编写模块203、读取模块204、转换模块205、获取模块206及调用模块207。

在本发明的一个实施例中，所述存储器31存储多个计算机可读指令，所述多个计算机可读指令被所述至少一个处理器32所执行以实现微服务处理的功能。

具体地，所述至少一个处理器32对上述指令的具体实现方法可参考图1对应实施例中相关步骤的描述，在此不赘述。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

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

另外，在本发明各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或，单数不排除复数。本发明中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

最后应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或等同替换，而不脱离本发明技术方案的精神和范围。

Claims (10)

1.一种微服务处理方法，其特征在于，所述方法包括：

接收多个微服务及所述多个微服务之间的合并关系；

基于所述合并关系，对所述多个微服务的启动应用包进行打包，得到多个目标启动应用包；

当侦测到任意一个目标启动应用包启动时，读取所述任意一个目标启动应用包中的每个微服务与部署的微服务之间的映射关系；

基于所述每个微服务与部署的微服务之间的映射关系，对所述每个微服务中的远程接口的接口名称进行转换，并将转换结果加载到内存中；

响应于接收的HTTP请求，获取页面的加载数据；

基于所述加载数据从所述内存中获取目标微服务，并基于所述目标微服执行其他微服务调用。

2.如权利要求1所述的微服务处理方法，其特征在于，所述读取所述任意一个目标启动应用包中的每个微服务与部署的微服务之间的映射关系包括：

执行所述任意一个目标启动应用包中的第一代码；

基于所述第一代码从配置中心中读取所述每个微服务与部署的微服务之间的映射关系。

3.如权利要求1所述的微服务处理方法，其特征在于，所述基于所述每个微服务与部署的微服务之间的映射关系，对所述每个微服务的远程接口的接口名称进行转换包括：

识别所述每个微服务与部署的微服务之间的映射关系；

根据所述映射关系识别每个微服务的远程接口的接口名称是否需要转换；

当识别到每个微服务的远程接口存在合并关系时，确定每个微服务的远程接口的接口名称需要转换，将每个微服务的远程接口的接口名称转换为对应部署的微服务的接口名称；

当识别到每个微服务的远程接口不存在合并关系时，确定每个微服务的远程接口的接口名称不需要转换。

4.如权利要求1所述的微服务处理方法，其特征在于，所述基于所述加载数据从所述内存中获取目标微服务包括：

从所述加载数据中获取加载的微服务的服务名称；

根据所述微服务的服务名称，通过微服务网关路由到对应的目标微服务上。

5.如权利要求1所述的微服务处理方法，其特征在于，所述基于所述目标微服执行其他微服务调用包括：

从配置中心提取所述目标微服务的启动应用包中的第二代码；

根据所述第二代码确定所述目标微服务调用的其他微服务，并基于所述其他微服务的远程接口发起调用。

6.如权利要求4所述的微服务处理方法，其特征在于，在所述基于所述目标微服执行其他微服务调用之前，所述方法还包括：

从注册中心的微服务列表中提取其他微服务的远程接口；

根据所述其他微服务与部署的微服务之间的映射关系对所述其他微服务的远程接口进行识别；

当识别到所述其他微服务的远程接口存在合并关系时，获取所述其他微服务的原始微服务的服务名称对应的第一IP地址和第一服务端口；

将所述其他微服务的原始微服务的服务名称对应的第一IP地址和第一服务端口替换为部署的微服务的服务名称对应的第二IP地址和第二服务端口。

7.如权利要求1至6中任意一项所述的微服务处理方法，其特征在于，所述方法还包括：

基于所述多个微服务之间的合并关系，编写配置文件，并将所述配置文件存储至配置中心。

8.一种微服务处理装置，其特征在于，所述装置包括：

接收模块，用于接收多个微服务及所述多个微服务之间的合并关系；

打包模块，用于基于所述合并关系，对所述多个微服务的启动应用包进行打包，得到多个目标启动应用包；

读取模块，用于当侦测到任意一个目标启动应用包启动时，读取所述任意一个目标启动应用包中的每个微服务与部署的微服务之间的映射关系；

转换模块，用于基于所述每个微服务与部署的微服务之间的映射关系，对所述每个微服务中的远程接口的接口名称进行转换，并将转换结果加载到内存中；

获取模块，用于响应于接收的HTTP请求，获取页面的加载数据；

调用模块，用于基于所述加载数据从所述内存中获取目标微服务，并基于所述目标微服执行其他微服务调用。

9.一种电子设备，其特征在于，所述电子设备包括处理器和存储器，所述处理器用于执行所述存储器中存储的计算机程序时实现如权利要求1至7中任意一项所述的微服务处理方法。

10.一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任意一项所述的微服务处理方法。

Images