CN115633073A - 微服务调用方法、电子设备、系统及可读存储介质 - Google Patents

Abstract

本申请涉及计算机技术领域，具体涉及一种微服务调用方法、电子设备、系统及可读存储介质。其中该方法包括：第一终端响应于用户操作，向服务器发送请求多个微服务的业务请求，多个微服务包括运行在服务器提供的第一执行环境中的至少一个微服务、以及运行在多个终端中的至少一个终端提供的第二执行环境中的第一微服务，业务请求包括第一微服务的识别信息；向服务器发送请求多个微服务的业务请求；服务器将生成的第一调用请求发送给包括微服务调用模块的第二终端；第二终端基于第一调用请求调用第一微服务。本申请方案能够在不借助外部工具的情况下突破终端本地与Kubernetes的环境隔离限制，实现跨环境互相调用微服务，有效减少了开发人员的工作量。

Description

微服务调用方法、电子设备、系统及可读存储介质

技术领域

本发明涉及计算机技术领域，具体涉及一种微服务调用方法、电子设备、系统及可读存储介质。

背景技术

在各类系统的开发项目中，例如保险业务系统的开发项目，需要实现容器集群的自动化部署、自动扩缩容和维护等功能来完成对保险业务系统的维护和功能部署开发。例如，保险业务系统可以被切分为若干微服务，每个微服务对应的容器可以被独立地开发、部署和扩缩。微服务架构和容器可以进一步简化微服务交付，加强整体系统的弹性和健壮性。然而，由大量的微服务构成的分布式应用架构也会增加运维、调试、和安全管理的复杂性，比如保险方案智能组合、保单合约线上签约、保单生成、翻译服务、保费计算器、汇率计算器等相关服务的开发过程均可以被拆分为不同的微服务进行开发及测试维护，此类系统的开发项目数量大、维护项目多，因而需要开发者应用大量的集群来运行虚拟化容器以完成开发工作及相应的维护工作。

在现有技术中，开发者可以应用Kubernetes，一个开源的容器集群管理系统，用于实现容器集群的自动化部署、自动扩缩容、维护等功能。然而，Kubernetes作为一个跨越技术栈的平台，本身却是个封闭的内网系统，在Kubernetes中开通对微服务的外部访问十分困难，因此开发者难以从本地运行微服务来调用Kubernetes内的微服务。在实际业务场景下，如何响应一个业务请求调用本地和Kubernetes内的各个微服务处理该业务请求，是本申请亟需解决的技术问题。

发明内容

本申请实施例提供了一种微服务调用方法、电子设备、系统及可读存储介质，解决了保险业务系统的开发过程中应用Kubernetes开通微服务的外部访问困难、借助外部工具建立外部网络连接后对操作系统要求过高、对保险业务系统具有侵入性和需要对工具本身进行二次开发，导致应用Kubernetes容器集群来开发和维护保险业务系统局限性大的技术问题。

第一方面，本申请实施例提供了一种集群本地开发的方法，应用于包括服务器和多个终端的系统，该方法包括：多个终端中的第一终端响应于用户操作，向服务器发送请求多个微服务的业务请求，多个微服务包括运行在服务器提供的第一执行环境中的至少一个微服务、以及运行在多个终端中的至少一个终端提供的第二执行环境中的第一微服务，业务请求包括第一微服务的识别信息；

服务器基于业务请求以及第一微服务的调用参数，生成用于调用第一微服务的第一调用请求，其中第一微服务的调用参数基于第一微服务的识别信息获取；

服务器将生成的第一调用请求发送给包括微服务调用模块的第二终端；

第二终端基于第一调用请求调用第一微服务。

即集群本地开发的系统中，可以包括一个服务器和多个终端，其中，该服务器可以用于提供容器集群环境，多个终端可以用于提供终端本地环境。多个终端中的第一终端响应于用户操作，向服务器发送请求多个微服务的业务请求，并在业务请求中加入对运行于第二终端的第一微服务的识别信息，以便于服务器生成跨环境调用运行于第二终端的第一微服务的第一调用请求，使得服务器上的微服务无需借助第三方工具，就可以跨环境完成对终端本地微服务的调用。

上述终端可以用于对接业务服务系统客户端，例如保险业务系统客户端，用于获取开发人员或用户的维护请求或开发请求，将上述维护请求或开发请求作为业务请求发送至服务器，进而通过加入对运行于第二终端的第一微服务的识别信息，实现容器集群环境中运行的微服务可以直接跨环境调用终端本地环境运行的微服务。上述第一微服务调用请求，即本申请实施例中的对本地微服务的调用请求，上述第二终端，即本申请实施例中的终端，上述第一微服务，即本申请实施例中运行于终端本地的微服务。本申请方案避免了外部工具的介入，也有利于减少开发人员为实现跨环境调用微服务所需付出的工作量。

在上述第一方面的一种可能的实现中，该第一微服务的调用参数包括调用地址和调用端口信息，并且，服务器基于业务请求以及第一微服务的调用参数，生成用于调用第一微服务的第一调用请求，包括：使用第一微服务的调用地址和调用端口信息，替换业务请求中的第一微服务的识别信息，生成第一调用请求。

即在生成用于调用第一微服务的第一调用请求的过程中，可以使用第一微服务在终端本地的调用地址和调用端口信息，来替换业务请求中第一微服务的识别信息。上述第一微服务的识别信息包括但不限于第一微服务在容器集群中的调用地址和调用端口信息，因而借由业务请求头部信息(Header)来传递第一微服务在终端本地的调用信息和调用端口信息，将业务请求指引到终端本地来调用终端本地运行的第一微服务，以便于不借助外部工具实现终端本地和容器集群的协同开发。

在上述第一方面的一种可能的实现中，业务请求包括第二微服务的识别信息，其中第二微服务运行于第一执行环境，并且，业务请求对第一微服务的调用早于对第二微服务的调用，服务器基于业务请求以及第一微服务的调用参数，生成用于调用第一微服务的第一调用请求，还包括：服务器基于业务请求以及第一微服务的调用参数，生成第二调用请求；

服务器在生成的第二调用请求的头部信息中添加第二微服务的调用参数，生成用于调用第一微服务的第一调用请求。

即在生成第一调用请求的的过程中，将运行于服务器提供的容器集群环境的第二微服务识别信息加入第一调用请求的头部信息中。在第一调用请求发送至终端本地环境调用第一微服务时，第一调用请求头部信息传递了第二微服务的识别信息至终端本地，第一微服务可以根据第二微服务的识别信息在终端本地生成调用第二微服务的调用请求，实现从终端本地跨环境调用容器集群上运行的微服务，将微服务调用请求转回到容器集群中。

在上述第一方面的一种可能的实现中，第二终端基于第一调用请求调用第一微服务，包括：第二终端检测到第一调用请求的头部信息包括第二微服务的调用参数，基于第一调用请求以及第二微服务的调用参数，生成用于调用第二微服务的第三调用请求；

第二终端将生成的第三调用请求发送给服务器，以调用运行于第一执行环境内运行的第二微服务。

即在第二终端基于第一调用请求调用第一微服务的过程中，将第一调用请求头部信息中第二微服务的调用参数加入到第二微服务在终端本地的默认调用请求中，生成第三调用请求，用于从终端本地跨环境调用容器集群上微服务的第三调用请求，实现从终端本地跨环境调用容器集群上运行的微服务，将微服务调用请求转回到容器集群中。

在上述第一方面的一种可能的实现中，第一终端包括请求获取模块，并且，第一终端响应于用户操作，向服务器发送请求多个微服务的业务请求，包括：第一终端基于请求获取模块响应于用户操作，向服务器发送请求多个微服务的业务请求。

上述第一终端，即本申请实施例中的客户端，包含请求获取模块，用于响应用户操作得到请求多个微服务的业务请求，以便于将业务请求转发至服务器中。

在上述第一方面的一种可能的实现中，服务器包括检测模块和请求生成模块，并且，服务器基于业务请求以及第一微服务的调用参数，生成用于调用第一微服务的第一调用请求，包括：

检测模块检测到业务请求包括第一微服务的识别信息，并将检测结果发送给请求生成模块；

请求生成模块基于接收到的检测结果以及业务请求，生成用于调用第一微服务的第一调用请求。

即在生成用于调用第一微服务的第一调用请求的过程中，检测模块用于检测业务请求中是否包含第一微服务识别信息，得到检测结果，将该检测结果发送至请求生成模块。请求生成模块基于接收到的检测结果、根据业务请求来生成用于调用第一微服务的第一调用请求。

在上述第一方面的一种可能的实现中，请求生成模块基于接收到的检测结果以及业务请求，生成用于调用第一微服务的第一调用请求，包括：基于业务请求以及第一微服务的调用参数，生成第二调用请求；

在生成的第二调用请求的头部信息中添加第二微服务的调用参数，生成用于调用第一微服务的第一调用请求。

即请求生成模块生成用于调用第一微服务的第一调用请求，可使用第一微服务的调用参数更新业务请求来生成第二调用请求，并在生成的第二调用请求的头部信息中添加第二微服务的调用参数，来生成用于调用第一微服务的第一调用请求，从而保证了第一调用请求头部包含第二微服务的调用参数、并可以跨环境调用终端本地的微服务。

在上述第一方面的一种可能的实现中，基于业务请求以及第一微服务的调用参数，生成第二调用请求，包括：使用第一微服务的调用参数替换业务请求中的第一微服务的识别信息，生成第二调用请求。

即生成第二调用请求的过程中，第一微服务的调用参数包括第一微服务的调用地址和调用端口信息，使用第一微服务的调用地址和调用端口信息替换业务请求中的第一微服务的识别信息，将业务请求更新为上述第二调用请求，以保证基于第二调用请求生成的第一调用请求可以发送至第二终端本地调用第一微服务。

在上述第一方面的一种可能的实现中，第二终端包括微服务调用模块，并且，第二终端基于第一调用请求调用第一微服务，包括：微服务调用模块基于第一调用请求调用第二执行环境内的第一微服务。

即第一调用请求可以通过微服务调用模块在第二终端上执行对第一微服务的调用。

在上述第一方面的一种可能的实现中，第二终端基于第一调用请求调用第一微服务，包括：

微服务调用模块检测到第一调用请求的头部信息包括第二微服务的调用参数，基于第一调用请求以及第二微服务的调用参数，生成用于调用第二微服务的第三调用请求；

微服务调用模块将生成的第三调用请求发送给服务器，以调用运行于第一执行环境内运行的第二微服务。

即第二终端基于第一调用请求调用第一微服务的过程中，微服务调用模块必须检测第一调用请求的头部信息，以保证生成所有需要转发至服务器的第三调用请求，防止在完成终端本地微服务的调用后，遗漏后续容器集群上需要调用的微服务。

在上述第一方面的一种可能的实现中，微服务调用模块基于第一调用请求以及第二微服务的调用参数，生成用于调用第二微服务的第三调用请求，包括：微服务调用模块使用第二微服务的调用参数替换第一调用请求的头部信息中第一微服务的调用参数，生成第三调用请求。

即微服务调用模块生成用于调用第二微服务的第三调用请求的过程中，第一调用请求中包含默认的对第二微服务的调用地址和调用端口，使用第二微服务的调用参数更新上述默认调用地址和默认调用端口来生成上述第三调用请求。

在上述第一方面的一种可能的实现中，服务器包括对应第一执行环境采用的开发模式预设的配置文件，并且，方法包括：

服务器基于配置文件中对应于是否启动本地开发模式的配置信息，检测业务请求中是否包括第一微服务的识别信息。

即上述服务器可以获取到第一执行环境与开发模式相关的配置文件，通过获取到的上述配置文件来确定是否启动本地开发模式的配置信息，基于是否启动本地开发模式来确定是否检测业务请求。

在上述第一方面的一种可能的实现中，服务器基于配置文件中对应于是否启动本地开发模式的配置信息，检测业务请求中是否包括第一微服务的识别信息，包括：

若配置信息指示启动本地开发模式，则检测模块检测业务请求中是否包括第一微服务的识别；

若配置信息指示关闭本地开发模式，则检测模块对业务请求不进行检测。

即配置信息中可以被配置指示是否开启本地开发模式的内容，例如配置文件中被预设置了一个配置项，当配置项的值为enable时启动本地开发模式，当配置项的值不为enable时关闭本地开发模式。当启动本地开发模式时，检测模块才需要检测业务请求头部信息是否包括第一微服务的识别信息；当关闭地开发模式时，检测模块不需要检测业务请求的头部信息，上述服务器可以根据业务请求直接调用对应的微服务。

在上述第一方面的一种可能的实现中，第一终端和第二终端为同一终端或者不同终端。

上述第一终端即为本申请实施例中的客户端，第二终端即为本申请实施例中的终端本地，客户端和终端可以为同一终端或不同终端。

第二方面，本申请实施例提供了一种微服务调用系统，该系统包括多个终端和服务器，其中，多个终端中的第一终端用于响应用户操作，向服务器发送请求多个微服务的业务请求，多个微服务包括运行在服务器提供的第一执行环境中的至少一个微服务、以及运行在多个终端中的至少一个终端提供的第二执行环境中的第一微服务，业务请求包括第一微服务的识别信息；

服务器用于基于业务请求以及第一微服务的调用参数，生成用于调用第一微服务的第一调用请求，其中第一微服务的调用参数基于第一微服务的识别信息获取；

服务器用于将生成的第一调用请求发送给包括微服务调用模块的第二终端；

第二终端用于基于第一调用请求调用第一微服务。

第三方面，本申请实施例提供了一种电子设备，包括：一个或多个处理器；一个或多个存储器；一个或多个存储器存储有一个或多个程序，当一个或者多个程序被一个或多个处理器执行时，使得设备执行上述第一方面提供的微服务调用方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，存储介质上存储有指令，指令在计算机上执行时，使计算机执行上述第一方面提供的微服务调用方法。

附图说明

图1所示为根据本申请一方面提供的一种进行集群本地开发的场景示意图；

图2所示为根据本申请实施例提供的一种在跨环境调用微服务的场景示意图；

图3所示为根据本申请实施例提供的一种集群本地开发系统的软件结构示意图；

图4所示为根据本申请实施例提供的一种集群本地开发的方法的实施流程示意图；

图5a所示为根据本申请实施例提供的一种集群微服务调用方法的实施流程示意图；

图5b所示为根据本申请实施例提供的一种集群本地协同调用微服务的方法的实施流程示意图；

图6所示为根据本申请实施例提供的一种服务器200的结构示意图。

具体实施方式

为了便于理解本申请实施例提供的技术方案，下面相对本申请实施例涉及的一些相关领域术语的含义进行释明。

(1)Kubernetes：用于自动部署、扩展和管理容器化应用程序的开源系统，本申请应用于基于Kubernetes开发的如下实际应用场景：Kubernetes本身是一个完整的内网系统，外部无法访问，而通常在开发阶段，开发者会在Kubernetes以外的地方来完成整个开发过程，例如在本地机器上启动一个微服务，以此来跟Kubernetes中的微服务进行数据交互，为了实现数据交互，需要成功建立Kubernetes和本地机器服务的网络连接。

(2)微服务：用于实现应用(APP)的单一业务功能的服务。相较于传统服务，微服务可实现的业务功能更少，一个微服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。可以理解的是，开发人员可根据业务模块来划分微服务的种类，每个微服务均可以独立部署并且互相隔离。在应用场景中，微服务均可被轻量的HTTP资源API请求来调用。在微服务架构中，这些独立的微服务不需要部署在同一个虚拟机、同一个系统和同一个应用服务器中，因而可以采用容器集群的方式实现对系统微服务的整体开发处理。

(3)头部信息(Header)，即HTTP消息头，又称标头，是指在超文本传输协议(Hypertext Transfer Protocol，HTTP)的请求和响应消息中，协议头部分的那些组件。Header部分用来准确描述正在获取的资源、服务器或者客户端的行为，定义了HTTP事务中的具体操作参数。

(4)KtConnect(Kubernetes Toolkit Connect)：一款用于Kubernetes系统与本地测试联调微服务的小工具。

可以理解，本申请实施例所提供的技术方案可以应用不同行业的业务服务系统开发及运行场景，例如应用于在Kuberntes基础上开发的业务服务系统对应的微服务调用场景等，该业务服务系统例如可以是保险业务系统等，在此不做限制。

为了使本申请实施例的目的、技术方案和优点更加清楚，下面将结合说明书附图以及具体的实施方式对本申请实施例所提供的技术方案进行详细的说明。

图1示出了一种进行集群本地开发的场景示意图。

如图1所示，该场景包括终端01、服务器02和客户端03，其中服务器02提供用于开发业务服务系统的容器集群环境，其中，服务器02所开发的业务服务系统，例如可以是保险业务系统。服务器02可以调用用于开发业务服务系统的容器集群04，通过开发服务器为大量的容器分配开发项目任务，例如开发测试任务，在开发项目中容器集群04可以灵活扩缩容，便于调用合适的容器完成对开发项目任务的开发工作，例如调用微服务进行测试开发。

参考图1所示场景，根据业务服务系统开发项目的需要，目前用户如需进行本地联合集群的微服务测试开发，可以通过客户端03发起一条用于联合测试开发的业务请求或发起一条用于维护业务服务系统的业务请求，该业务请求通常为API微服务调用请求。接着，该业务请求发送至服务器02来调用联合测试开发所使用的所有微服务，其中，用户可以为开发人员或业务人员。此时，开发人员可以在终端01本地启动一个微服务，使用该本地微服务来配合服务器02上启动的微服务完成对业务服务系统的联合测试开发或维护处理，其中，上述业务服务系统例如可以为保险业务系统。

可以理解，服务器02可以调用容器集群04提供容器集群环境，而该容器集群04所提供的容器集群环境本质为一个内网环境。在容器集群环境提供的相应开发页面上启动(或者说写入)对本地微服务的调用请求后，需由开发人员利用外部工具，例如KtConnect(Kubernetes Toolkit Connect)，来建立终端01本地与服务器02之间的网络连接。如此，终端01便可以服务器02通过KtConnect调用服务器02上容器集群04内的微服务，例如通过KtConnect创建的域名来调用容器集群04内的微服务。另外，KtConnect工具还可以将容器集群04内网中的服务请求转发到终端01的本地环境内。

基于上述图1所示场景，如前，目前在向容器集群环境中进行系统项目开发的过程中，为了本地服务联合容器集群04的开发测试以及维护需要，可以引入外部工具完成终端的本地环境与开发服务器上容器集群04内网环境之间传递微服务调用请求。但是，该外部工具例如KtConnect，需要在终端01的本地环境内建立虚拟网络并开设代理，并在容器集群04内建立相关的代理工具，方可在终端本地与开发服务器容器集群04内网之间建立连接，传递跨环境的调用微服务的微服务调用请求。因而，这些外部工具的适用局限性较大。

可以理解，引入外部工具会产生大量新概念需要开发者进行学习，增加了开发人员学习成本。并且，为了适应特殊复杂系统的开发需要引入新的外部工具时，还需要针对外部工具在容器集群04中创建相应代理工具，以实现外部工具与容器集群04内的微服务同步，即需要进行二次开发，也会导致开发工作量的增加。上述容器集群04例如可以是基于Kubernetes开发的容器集群，本申请实施例中除非特别说明，以下描述中Kubernetes可以用于指代基于Kubernetes调用的容器集群，在此不做赘述。

此外，该上述用于传递微服务调用请求的外部工具所适用的操作系统也有限，例如KtConnect无法应用到Windows7操作系统中。当开发人员使用的终端01搭载Windows7操作系统时，则无法通过KtConnect调用Kubernetes内的微服务进行联合容器集群04的开发测试。

为了解决上述技术问题，本申请提供了一种微服务调用方法，应用于需要跨环境调用微服务处理业务请求的系统中。具体地，该方法通过在调用当前环境内的第一微服务时，将即将要调用的另一环境中的第二微服务所对应的调用地址和调用端口等，添加到对第一微服务的调用请求数据中，例如将上述调用地址和调用端口等添加到用于请求第一微服务的HTTP请求的Header部分中。进而，在跨环境调用微服务时，可以根据上述已添加Header部分中对应于第二微服务调用地址和调用端口等，实现对另一环境中的第二微服务的调用。

同时，如果第二微服务后续调用的第三微服务仍需要在当前环境中执行，可以将第三微服务所对应的调用地址和调用端口等，添加到对第二微服务的调用请求数据中，例如将上述第三微服务调用地址和调用端口等添加到用于请求第二微服务的HTTP请求的Header部分中。进而，在跨环境调用微服务时，可以根据上述已添加Header部分中对应于第三微服务调用地址和调用端口等，从另一环境中实现对当前环境中的第三微服务的调用。

如此，则可以在不借助外部工具的情况下突破终端本地与Kubernetes的环境隔离限制，并且本申请方案不限定操作系统，在终端本地与Kubernetes提供的微服务执行环境之间可以实现多次跨环境调用微服务。本申请方案避免了外部工具的介入，也有利于减少开发人员为实现跨环境调用微服务所需付出的工作量。

其中，上述基于本申请方案实现的跨环境调用微服务的场景，可以包括从调用本地环境的微服务A切换调用Kubernetes内的微服务B、或者从调用Kubernetes内的微服务A切换调用本地环境的微服务B等。例如，当需要本地微服务与开发服务器端的容器集群04服务同步联测来完成开发项目时，可以在调用上一个本地微服务的过程中，将之后调用Kubernetes微服务的调用地址和调用端口添加到上一个本地微服务对应的HTTP请求中。又例如，调用微服务的微服务调用请求在进入Kubernetes后如果需要再调用本地微服务，则可以在Kubernetes内相应微服务的调用请求中添加后续将要调用的本地微服务的调用地址及调用端口等。

在另一些实施例中，终端对多个微服务的调用过程，也可以通过在终端调用的第一个微服务或者第一个即将跨环境的微服务对应的微服务调用请求的Header部分，依次加入后续多个跨环境的微服务调用地址及调用端口等。例如在对微服务A的调用请求Header部分依次加入微服务B、微服务C以及微服务D的调用地址和调用端口，其中微服务B和微服务D在本地环境内、微服务C在Kubernetes内，在此不做限制。

可以理解，外部访问微服务需要通过相应的IP地址和端口，因此通过获取Header部分加入的各个微服务的地址信息和调用端口即可调用对应的微服务。比如HTTP地址“http://192.168.0.16:8080”中http://192.168.0.16部分为IP地址部分，而“8080”部分则为调用端口部分。而例如常用的注册http地址“https://www.baidu.com”中隐藏了默认端口443，该HTTP地址用于访问相应的微服务时需要将被隐藏的端口加入其中。

如此，可以确保将相应业务对微服务的调用请求顺利发布到Kubernetes和本地环境中，进而顺利完成对Kubernetes内微服务及本地微服务的调用及过渡过程。如此，可以避免借助外部工具对终端设备操作系统的限制、以及技术栈等方面限制的问题。

可以理解，上述开发人员可以理解为服务器02调用的容器集群04的管理类用户，上述用户可以理解为开发项目对应业务服务系统的管理类用户，即这类用户对容器集群04提供的业务服务、微服务以及业务服务系统拥有进行管理和维护的权限，包括发布对微服务的调用请求等。

其中，微服务可以在用户通过终端01或者客户端02发布业务请求之前，根据开发人员在相应开发页面上的设置操作而在相应的容器集群04和开发终端本地生成。例如，开发人员可以在容器集群环境对应运行的开发服务系统提供的开发页面上设置相应微服务，也可以在终端本地对应运行的开发服务系统提供的开发页面上设置相应微服务。在实际应用场景中，例如保险业务系统可以根据用户操作来智能组合例如保险方案、签约保单、生成保单、以及提供翻译服务、保费计算器、汇率计算器等相关业务服务，而开发人员可以通过拆分上述业务功能来生成多个微服务，这些微服务可以在终端01上运行，这些微服务还可以在服务器02调用的容器集群04上运行。可以理解，在一些实施例中，上述容器集群环境可以运行在服务器02的容器集群04和/或终端01本地。该服务器02例如可以是基于Kubernetes容器集群搭建的云服务器，而对应的开发项目可以为保险业务系统。具体的集群本地开发过程将在下文详细描述，在此不做赘述。

图2根据本申请实施例提供了一种在跨环境调用微服务的场景示意图。

如图2所示，该场景包括终端100、服务器200和客户端300。其中，终端100的用户可以为开发人员，客户端300的用户可以为开发人员、业务服务系统运维人员或业务服务系统业务人员，在此不作限制。服务器200可以为用于通过操控容器集群400来完成开发项目的服务器，该服务器200可以被客户端300访问。其中，客户端300可以为保险业务系统客户端，终端100可以为用于开发的终端。

可以理解，在一些实施例中，客户端300可以为除了服务器200以外的任何一端，因此，客户端300可以与终端100为同一端，在此不作限制。客户端300的用户可以为业务服务系统开发人员或业务服务系统运维人员，在此不作限制。业务请求可以是容器集群400以外的终端100或者客户端300上的某个服务发起的，在此不作限制。例如，开发人员可以在客户端300上发起本地和容器集群400联合开发测试的业务请求；或者，保险业务人员，也就是使用保险业务系统的用户，可以在安装有保险业务系统的客户端300上发起对保险业务系统进行功能维护的业务请求等。

继续参考图2所示的场景，开发人员可以通过终端100访问服务器200，在服务器200所提供的容器集群环境中预设本地服务调用配置，例如开发人员可以在容器集群环境中预先定义本地开发模式对应的配置文件，该模式下对应定义了本地微服务的优先调用规则。即本地开发模式开启时，基于该优先调用规则可以限定先根据业务请求头部信息中的对本地微服务的调用参数，优先调用终端100本地启动的相应微服务。若业务请求Header部分不包含对本地微服务的调用参数，则无需适用上述优先调用规则。如此，在一些微服务调用场景中，例如上述图2所示意的跨环境调用微服务的场景中，可以确保整个服务调用过程不会遗漏本地的微服务。而在另一些只需要调用本地微服务、或者只需要调用容器集群内微服务的场景中，也可以通过上述配置文件关闭本地开发模式。关闭模式后无需检测业务请求的Header部分是否包含对本地微服务的调用参数，如此也可以提高微服务调用效率。

其中，上述本地开发模式对应的配置文件，即为容器集群环境中终端100本地协同容器集群400进行微服务调用时所设置的配置文件。上述对本地微服务的调用参数例如可以包括本地微服务对应的调用IP地址和调用端口。

例如，在容器集群环境中可以预设一个xml类型的配置文件模板，该模板中可以定义检测到对本地微服务的调用参数时对应生成的配置文件内容。该配置文件可以包含服务调用的优先级，例如当检测到对本地微服务的调用参数时，即使在服务器200上运行有与终端100的本地相同的服务，优先调用终端100本地的微服务。在一些实际应用场景下的实施例中，在容器集群环境中可以在容器集群400的默认配置文件中直接添加一个配置项以更新该配置文件，该配置项的里值用于定义本地微服务的优先调用规则，当检测到对本地微服务的调用参数时，基于配置文件中配置项的值对应启动相应的本地开发模式。

如此，开发人员在通过终端100访问服务器200的容器集群环境后，在服务器200上完成对本地协同微服务调用的配置文件的设置，接着用户可以通过客户端300发起业务请求，其中，业务请求可以包括终端100本地和容器集群400联合开发测试的业务请求或保险业务系统功能维护的业务请求。业务请求为对业务请求相关服务的调用请求。

在一些实施例中，保险业务系统可以根据用户操作来智能组合例如保险方案、签约保单、生成保单、以及提供翻译服务、保费计算器、汇率计算器等相关业务服务，而开发人员可以通过拆分上述业务功能来生成多个微服务，这些微服务可以在终端100上运行，这些微服务还可以在服务器200调用的容器集群400上运行。

在另一些实施例中，业务请求可以为API微服务调用请求，其中，微服务调用请求可包含所有微服务的域名、IP地址和调用端口等信息，用于精确调用对应的微服务，例如调用容器集群400中的微服务或终端100上运行的微服务。容器集群400中的所有微服务可以基于预设的配置文件启动本地开发模式，进而在本地开发模式下，检测微服务调用请求中是否包含本地微服务调用地址和本地端口参数，若是，则在容器集群400中也包含相应微服务的情况下，基于该微服务调用请求优先调用终端100上的微服务，继而生成对本地微服务的调用请求，将该对本地微服务的调用请求发送至终端100。如此，开发人员便可以在终端100上基于终端100发送的业务请求，例如开发测试请求或运维请求，来调用终端100上该业务请求对应的微服务，以在本地完成对该微服务的开发调试处理或运维处理。

在又一些实施例中，终端100中的所有微服务可以检测发送至终端100的微服务调用请求中是否包含容器集群400的微服务IP地址和对应的调用端口，若是，则基于该微服务调用请求优先调用容器集群400上的微服务，继而生成新的微服务调用请求，将该新的微服务调用请求发送至被服务器200调用的容器集群400，以跨环境完成对容器集群400上的微服务的调用。如此，开发人员便可以在客户端300输入同时调用容器集群400微服务和本地微服务的业务请求，来调用业务请求对应的所有微服务，以在容器集群400和终端100本地协同完成对所有微服务的开发调试处理或运维处理。

可以理解，在一些实施例中，本地微服务在调用下一个在容器集群400中启动的微服务时，从对本地微服务的调用请求中确定下一个在容器集群400中启动的微服务对应的IP地址和调用端口参数，基于上述IP地址和端口参数对本地默认微服务调用请求进行更新。比如，为了调用容器集群400上运行的微服务，使用该微服务在容器集群400上的调用参数替换该微服务在本地的默认调用参数，以生成新的微服务调用请求。进而将新的微服务调用请求发送至容器集群400的微服务中，成功建立终端100和服务器200所操控的容器集群400所处内网的网络连接。

参考图2所示，用户在通过客户端300发起业务请求时，客户端300可以调用容器集群环境的API向服务器200发送对相应微服务的调用请求参数，该调用请求参数例如可以包括所有调用的微服务的IP地址、端口参数和调用顺序。用户在通过客户端300发起业务请求时，客户端300可以调用容器集群环境的容器集群400向服务器200发送添加本地微服务的IP地址信息和本地微服务的调用端口的微服务调用请求信息，以在容器集群环境中匹配对应的配置启动对应的开发模式，基于该对应的开发模式完成本地微服务及容器集群400微服务的调用过程，具体过程将在下文中详细描述，在此不做赘述。

可以理解，本申请实施例所提供的服务调用方法，可以适用于包括上述终端100、服务器200和客户端300的集群本地开发系统，该系统可以用于终端100、服务器200和客户端300，该系统可调用容器集群400和终端100的微服务，从而实现容器集群协同终端本地完成业务服务系统所需微服务的联合开发以及联合测试处理。其中，上述服务器200可以为包括容器集群400的云服务器，该容器集群400可以是上述基于Kubernetes开发管理的用于运行容器化程序的集群，也可以称为云服务器集群。需要说明的是，该容器集群400可运行多个微服务，在此不做限制。

另外，上述终端100或客户端300可以为桌面型计算机、膝上型计算机、手持计算机、上网本等嵌入或耦接有一个或多个处理器的、或能够访问网络的其他电子设备，在此不作限制。终端100该终端100或客户端300所搭载的操作系统包括但不限于Linux、Windows和MacOS，在此不做限制。

图3根据本申请实施例示出了一种集群本地开发系统的软件结构示意图。

如图3所示，集群本地开发系统300可以包括请求获取模块301、检测模块302、请求生成模块303和微服务调用模块304。其中，请求获取模块301可以设置在客户端300上，检测模块302、请求生成模块303可以设置在服务器200上，微服务调用模块304可以设置在终端100上。在另一些实施例中，请求获取模块301与微服务调用模块304也可以均设置在终端100或客户端300上，在此不做限制。

示例性地，基于图3所示集群本地开发系统300开发的系统服务例如可以是保险业务系统所提供的服务等，开发过程中可以涉及对终端100本地环境、以及服务器200上的容器集群400所提供环境中的微服务的跨环境调用。在此不做限制。

其中，请求获取模块301可以在客户端300上运行，用于为用户提供发起业务请求的页面。当用户需要针对具体开发项目发起相应业务请求以调用相应微服务时，请求获取模块301生成包含相应调用参数的业务请求。其中，调用参数包括相应微服务的调用地址和调用端口等，该调用地址例如可以是互联网协议地址(Internet Protocol Address，IP地址)，在此不作限制。

检测模块302可以在服务器200上运行，用于获取预设在容器集群400中的本地开发模式相关的配置文件。可以理解的是，该配置文件用于决定是否根据获取到的业务请求在容器集群400中调用终端100本地的微服务。在此，当本地开发模式为启动时，检测获取到的业务请求的Header部分中是否包含对本地微服务的调用参数，若检测模块302检测到相应业务请求的Header中包含对本地微服务的调用参数，可以将检测结果发送给请求生成模块303，以使请求生成模块303生成跨环境调用本地微服务的微服务调用请求。当存在对本地微服务的调用参数时，即使容器集群400存在同样域名同样IP地址的微服务，容器集群400也将优先调用在终端100上运行的本地服务，以实现容器集群400调用终端100上的本地服务。而当本地开发模式关闭时，容器集群400无需检测获取到的业务请求的Header部分，直接基于业务请求中包含的用于调用微服务的容器集群地址和微服务资源对象名来调用容器集群400中的微服务。

请求生成模块303可以运行在服务器200上，用于基于检测模块302的检测结果、以及客户端300发来的业务请求中的Header部分生成对应的微服务调用请求。例如当上述检测模块302检测到业务请求的Header部分包含对本地微服务的调用参数时，请求生成模块303可以基于该检测结果以及客户端300发来的业务请求中的Header部分，生成对终端100本地微服务的调用请求，并发送至终端100。或者，当上述检测模块302检测到业务请求的Header部分不包含对本地微服务的调用参数时，请求生成模块303可以基于该检测结果以及客户端300发来的业务请求，生成对容器集群400内微服务的调用请求。

微服务调用模块304可以运行在终端100上，用于获取请求生成模块303发送的对本地微服务的调用请求，以调用运行于终端100上的本地微服务。微服务调用模块304还可以基于对本地微服务的调用请求生成新的微服务调用请求，以保证业务请求中的所有微服务均可以被业务请求中设定的顺序完成自动调用。当新的微服务调用请求是对容器集群400内微服务的调用请求时，微服务调用模块304还可以将该对容器集群400微服务的调用请求发送至容器集群400，以跨环境完成对容器集群400微服务的调用。

可以理解，本地服务调用模块304还可以运行在终端100上向开发人员提供开发页面，开发人员可以在该开发页面上设置是否联动容器集群400内微服务的相关配置文件，例如在容器集群400中设置用于启动/关闭本地开发模式的配置文件中的配置项。在一些实施例中，该配置项可以设置为local_mode，当该配置项的值为enable或1等值时表示开启本地开发模式，当该配置项的值为unable或0等值时表示关闭本地开发模式。可以理解，该配置项例如可以存储在Kubernetes的配置中心，在此不做限制。

可以理解，终端100本地和容器集群400协同开发的场景下，若要在终端100本地调试容器集群400上的微服务H，则需要在终端100本地启动与容器集群400上一致的微服务H，由此提出一个业务请求，该业务请求用于调用包含微服务H的多个微服务。容器集群400中的配置文件可以指示是否启动本地开发模式，在启动本地开发模式时，容器集群400必须检测所有业务请求的Header，以优先调用终端100本地启动的微服务H。而通过容器集群400中预设的配置文件，开发人员可以随时随地切换本地开发模式和容器集群开发模式，关闭本地开发模式后容器集群400无需再检测业务请求的Header，而是直接基于业务请求调用容器集群400上的微服务。当本地开发模式开启时，容器集群400就优先去调用Header里面对本地微服务的调用参数对应的终端100本地上的微服务，这样可以保证不漏掉终端100本地启动的微服务。

可以理解，基于本申请实施例提供的集群本地开发的方案实现的集群本地开发系统无需借助外部工具即可实现Kubernetes容器集群与终端本地的开发联测，避免了外部工具对开发系统的限制。该方案通过借助HTTP协议的头部信息(Header)传递本地微服务的IP地址和调用端口，没有技术栈限制，任何技术栈只需要做个简单的Header检查替换逻辑即能实现容器集群与终端本地协同开发，对开发人员来说工作量小，且所有用到的技能都是开发人员所熟悉的。

基于上述图3所示结构，结合图4所示流程详细介绍本申请实施例提供的一种集群本地开发的方法的具体实施过程。图4根据本申请实施例示出了一种集群本地开发的方法的实施流程示意图。其中，图4所示流程主要涉及请求获取模块301、检测模块302、请求生成模块303和微服务调用模块304之间的交互。

具体地，如图4所示，该流程包括以下步骤：

401：请求获取模块301获取用户通过客户端300发送的指令来确定业务请求，并根据业务请求确定位于不同环境中待调用的各个微服务。在此，上述客户端300与服务器200连接，可以实现请求获取模块301将业务请求从客户端300发送至服务器200。上述不同环境为微服务的执行环境，例如容器集群400环境或终端100本地环境。

示例性地，请求获取模块301可以响应于用户在终端100或客户端300显示的相应业务界面上的操作指令，以获取相应的业务请求。该业务请求例如可以是上述开发人员操作发起的对于保险业务系统功能模块开发的业务请求，也可以是保险业务人员操作发起的对于保险业务系统功能模块进行维护的业务请求，在此不做赘述。

402：请求获取模块301在业务请求的头部信息中添加待调用微服务的调用参数。

示例性地，参考上述图3所示场景，用户可以通过客户端300提交业务请求，例如通过客户端300提交针对保险业务系统的维护请求或本地开发联测请求，在业务请求中借助于http请求的头部(Header)部分传递终端本地服务的IP地址和端口给容器集群400内的微服务。在此，请求获取模块301在获取到用户提交的输入指令数据来确定业务请求，并根据业务请求确定待调用微服务，此处待调用微服务可以为本地微服务也可以为容器集群内的微服务，业务请求可以为网络请求(API请求)，在该API请求的头部信息中添加待调用微服务的调用参数。在此，HTTP协议的规范里是可以传递Header，这里是借助于HTTP协议的规范中的Header机制来传递一些信息，例如在业务请求的Header中添加待调用微服务的调用地址及调用端口，其中，调用地址可以为IP地址。

可以理解的是，通常来说一个微服务需要有IP地址和端口，这样才能被外部访问。比如HTTP地址“http://192.168.0.16:8080”中http://192.168.0.16部分为IP地址部分，而“8080”部分则为调用端口部分；而http地址https://www.baidu.com则是隐藏了默认端口443。

可以理解的是，此处待调用微服务的调用参数包括但不限于所有待调用微服务的调用地址、所有待调用微服务的调用端口和所有待调用微服务的调用顺序。在此，在所有待调用微服务的调用地址可以为所有待调用微服务的域名，其中，该待调用微服务的调用端口为微服务调用方的接入端口。在一些实施例中，所有待调用微服务的调用地址可以为微服务的IP地址。

403：请求获取模块301发送上述业务请求至检测模块302。

示例性地，参考上述图3所示场景，用户基于待调用微服务的调用参数将业务请求通过客户端300发送至容器集群400，在此，容器集群400可以被用户和/或开发人员借由服务器200所操控，便于灵活使用容器完成对业务服务系统的开发项目，例如，对保险业务系统的维护项目和对保险业务系统的开发项目。此时，请求获取模块301将业务请求发送至运行于服务器200上的检测模块302中，以便于后续检测是否需要调用终端100本地运行的微服务。

404：检测模块302获取容器集群中的预设配置文件。

示例性地，预设配置文件设置于容器集群400中，容器集群400中的所有微服务基于预设配置文件启动本地开发模式，在容器集群环境中可以预设一个xml类型的配置文件模板，该模板中可以定义检测到对本地微服务的调用参数时对指定环境下运行的微服务的调用优先级，例如当检测到对本地微服务的调用参数时，即使在容器集群400上运行有与终端100本地相同的微服务，将优先调用终端100本地的微服务。在本地开发模式下，借由业务请求头部信息中包含的对本地微服务的调用地址和相应的调用端口优先调用终端100上的服务，继而生成对本地微服务的调用请求，将该对本地微服务的调用请求发送至终端100。如此，用户便可以在客户端300上发送同时涉及容器集群400和终端100的业务请求，例如本地协同集群联测开发请求和本地协同集群共同运行的运维请求等，启动对本地微服务的调用请求对应的微服务，以在本地完成对该微服务的开发调试处理。

可以理解的是，在一些实施例中，预设配置文件可以为开发人员在容器集群400的配置文件中添加的配置项，容器集群400可以为Kubernetes集群，开发人员可以在Kubernetes集群的配置中心中设置该配置项，比如可以设置一个本地开发模式local_mode的配置项，当该配置项的值为enable时开启本地开发模式。在本地开发模式下，当容器集群400检测到对本地微服务的调用参数时，即使在容器集群400上运行有与终端100本地上启动的相同的微服务，优先调用终端100本地运行的微服务。

405：检测模块302基于上述预设配置文件判断是否启用本地开发模式，若是，则进入步骤406a，便于容器集群400中的微服务调用终端100本地的微服务；若否，则进入步骤406b，请求生成模块303基于业务请求直接调用容器集群内运行的微服务。

示例性地，容器集群400在启动本地开发模式后，检测模块302检测收到的业务请求头部信息来确定该头部信息中是否包含对本地微服务的调用参数，若否，则在步骤406b中，在容器集群400中基于业务请求中的包含的用于调用微服务的容器集群地址和微服务资源对象名来常规调用业务请求对应的所有微服务。

可以理解的是，业务请求的头部信息中可包含所有待调用微服务的调用参数，待调用微服务的调用参数包括但不限于所有待调用微服务的调用地址、所有待调用微服务的调用端口和所有待调用微服务的调用顺序。根据所有待调用微服务的调用顺序对所有待调用微服务进行调用。

可以理解的是，本申请的业务请求可调用的微服务数量在此不作限制，可以基于需求进行灵活调整。

可以理解的是，本申请中的待调用微服务的调用参数所指的调用顺序为不作限制数量的微服务的调用顺序，可以对不作限制数量的微服务进行并行调用和/或串行调用，在此不作限制。

406a：检测模块302检测业务请求的头部信息中是否包含对本地微服务的调用参数，若是，则进入步骤407，以便于请求生成模块303生成对本地微服务的调用请求来调用本地微服务；若否，则进入步骤406b：请求生成模块303基于业务请求调用容器集群400中对应的微服务。

示例性地，容器集群400在启动本地开发模式后，将基于业务请求的头部信息是否包含对本地微服务的调用参数来确定是否需要生成对本地微服务的调用请求。检测模块302检测收到的业务请求头部信息来确定头部信息中是否包含对本地微服务的调用参数，若否，则在步骤406b中，在容器集群400中基于业务请求中的包含的用于调用微服务的容器集群地址和微服务资源对象名来常规调用业务请求中对应的微服务。

407：请求生成模块303基于对本地微服务的调用参数更新本地微服务的预设调用请求。

示例性地，对本地微服务的调用参数用于指示与实现对本地微服务的调用。在一些实施例中，容器集群400可以基于业务请求启动当前调用的微服务。当前调用的微服务可以根据对本地微服务的调用参数确定下一个调用的微服务为本地微服务，并使用对本地微服务的调用参数更新对本地微服务的调用请求的预设调用地址。例如容器集群400内当前调用的微服务可以使用对本地微服务的调用参数替换对本地微服务的调用请求的预设微服务调用地址和预设调用端口。也就是说，通过本地微服务在本地的IP地址和调用端口替换该微服务在容器集群400中的默认调用参数，可以将业务请求中的对本地微服务的调用请求从容器集群400转入终端100本地。

在此可以理解，对本地微服务的调用请求的预设调用地址可以为容器集群400的默认调用方式对应的调用地址，例如通过在容器集群400中预设的IP地址以及预设端口或预设微服务资源对象名来完成前一个微服务对后一个微服务的调用。在启动本地调用模式的情况下，检测到业务请求Header中包含对本地微服务的调用参数时，则基于对本地微服务的调用参数替换下一个微服务原本预设的微服务调用地址，以生成对本地微服务的调用请求。生成的对本地微服务的调用请求可以使得容器集群400得以与终端100的本地系统建立网络连接。

可以理解，在一些实施例中，同一个微服务的调用地址只能被使用一次，不可以被多个微服务所使用，因此不同的微服务对应的调用地址将基于头部信息中该微服务的预设调用地址进行替换操作以实现调用不同的微服务，在此，预设调用地址可以为默认调用地址。

可以理解的是，在一些实施例中，对本地微服务的调用参数包括本地微服务的有效IP地址和调用端口。

408：请求生成模块303在更新后的预设调用请求的头部信息中添加容器集群微服务的调用参数，得到对本地微服务的调用请求。

示例性地，请求生成模块303在更新后的预设调用请求的头部信息中添加容器集群微服务的调用参数，以便于在进入终端100本地调用对应的微服务后，本地微服务可以基于该容器集群微服务的调用参数生成对容器集群微服务的调用请求，从而将微服务的调用请求从终端100本地跨环境发送至容器集群400中，实现了终端100本地与容器集群400内网的连接。

409：请求生成模块303发送对本地微服务的调用请求至微服务调用模块304。

示例性地，请求生成模块303可以将所生成的对本地微服务的调用请求发送给终端100上运行的微服务调用模块304，以完成对终端100本地运行的微服务的调用。

410：微服务调用模块304基于对本地微服务的调用请求调用对应的本地微服务。

示例性地，微服务调用模块304可以在接收到容器集群400上运行的请求生成模块303发送的对本地微服务的调用请求后直接调用本地微服务。微服务调用模块304获取对本地微服务的调用请求后可以检测该调用请求的头部信息，并基于检测结果来决定是否根据该头部信息生成对容器集群400微服务的调用请求。

示例性地，对本地微服务的调用请求的头部信息中可以包含业务请求的头部信息，当业务请求的头部信息包含后续微服务的调用参数时，对本地微服务的调用请求的头部信息也可以包含后续调用参数。微服务调用模块304在调用启动于终端100本地的微服务时，可以检测对本地微服务的调用请求的头部信息中是否包含本地微服务对应的下一个待调用微服务的调用参数，以便于生成新的服务调用请求。

可以理解的是，下一个待调用微服务的调用参数可以为对本地微服务的调用参数或对容器集群微服务的调用参数，在此不作限制。

411：微服务调用模块304检测对本地微服务的调用请求的头部信息中是否存在对容器集群微服务的调用参数。若是，则进入步骤412a，以便于生成对容器集群微服务的调用请求，并将该对容器集群微服务的调用请求跨环境发送至容器集群400中，完成对相应微服务的调用。若判断结果为否，则进入步骤412b，继续调用后续终端100本地上的微服务。

示例性地，本申请提出的Header信息输送以及对Header的判断可以应用于当微服务的调用需要从容器集群400跨越至终端100的应用场景，以及可以应用于当微服务的调用需要从终端100跨越至容器集群400的应用场景。当后续调用参数对应的微服务运行于容器集群400中时，微服务调用模块304将生成的对容器集群微服务的调用请求发送至容器集群400，以完成对容器集群400中运行的微服务的调用。

412a：微服务调用模块304使用上述对容器集群微服务的调用参数更新容器集群微服务的预设调用请求，以生成对容器集群微服务的调用请求。

示例性地，当对本地微服务的调用请求的头部信息包含对容器集群微服务的调用参数时，该对本地微服务的调用请求指示后续待调用微服务运行于容器集群400中，则使用对容器集群微服务的调用参数更新该微服务的预设调用地址，以生成对容器集群微服务的调用请求，从而实现终端100本地微服务对容器集群400中微服务的跨环境调用。

412b：微服务调用模块304使用上述对本地微服务的调用请求调用后续本地微服务。

示例性地，对本地微服务的调用请求可以直接继续调用后续本地微服务，以完成业务请求中所有微服务的调用，避免遗漏调用本地微服务。

413：微服务调用模块304向容器集群400发送上述对容器集群400微服务的调用请求，以完成对容器集群400微服务的调用。

示例性地，对容器集群微服务的调用请求的调用地址已经被对容器集群微服务的调用参数更新，其指向运行于容器集群400环境中的对应微服务的有效IP地址和调用端口，从而便于微服务调用模块304基于对容器集群微服务的调用请求跨环境调用容器集群400上对应的微服务，以完成业务请求中所有微服务的调用，进而自动推进对业务服务系统开发项目相关的微服务调用，其中，该业务服务系统可以为保险业务系统。

可以理解，基于上述步骤401至413的实施流程，本申请实施例提供的集群本地开发的方法，首先能够确保容器集群与终端本地的微服务调用请求可以跨环境互相传递，从而解决了无法从容器集群的微服务中完成对本地微服务的调用的问题，进而实现了本地微服务与容器集群微服务的互相调用，切实实现了容器集群和本地开发联测。其次，本申请能够实现在不借助于外部工具的情况下完成容器集群内网与本地的网络连接和微服务调用，减少开发人员的工作量和学习坡度，有利于提高开发人员对相应业务的开发效率。

在一些实施例中，微服务调用请求进入终端100本地或者容器集群400后可以继续使用本申请提出的Header机制来确定下一个微服务调用地址和端口，在此不作限制。

在另一些实施例中，请求获取模块301、检测模块302、请求生成模块303和微服务调用模块304可以集成为集群本地开发底层工具包，以便于使用。

可以理解，本申请实施例提供的集群本地开发的方法，需要对所有业务请求添加头部信息，也就是步骤402中的所有业务请求均需要添加包含所有调用参数的头部信息。在后续在容器集群环境中调用微服务的过程中，容器集群400便可以均按照预设的开发配置结合头部信息来确定是否要调用终端100上运行的本地服务，终端100接收到容器集群400发送的对本地微服务的调用请求后，便可以对本地启动的本地微服务进行相应的调用。

换而言之，在调用微服务的过程中，如果启用了本地开发模式，仅需要引入包含调用参数的Header来确定后续跨越容器集群与终端本地的微服务的调用地址和调用端口，容器集群便可以自动完成对所有本地微服务和容器集群内运行的微服务的调用，无需人工介入，因此可以节约开发成本，且不受任何技术栈和操作系统的限制。

可以理解的是，在另一些实施例的实际应用场景中，上述步骤404至414的实施流程的执行主体均可以为运行于容器集群400和终端100本地的微服务。

需要说明的是，上述步骤的标号仅用于标识各步骤，不代表其执行顺序，步骤的执行顺序在此不作限制，其他可能的实施方式均包含与此。

在一些实施例中，上述业务请求的API例如可以是http://xxxx.com/business，图5a根据本申请实施例示出了一种集群微服务调用方法的实施流程示意图，在此，开发人员可以基于业务请求API启动请求流程。该请求流程为从客户端300发起业务请求，在容器集群400中顺序调用微服务A、微服务B和微服务C，其中，微服务B为本地微服务，微服务A和微服务C运行于容器集群400中，原本在容器集群400中本可以存在一个微服务B,当需要集群协同本地联测时，可以在终端100本地启动一个微服务B，在本地开发模式下，检测到存在对本地微服务的调用参数时，会优先调用终端100上的微服务B。

接上述实施例，当本地开发模式开启了，会检查收到的API请求Header部分是否有本地服务的信息，如果有，则在调用相关服务时优先使用本地服务。假定这个Header为x-local-services，假定Header里值的格式为“ServiceName@IP:port”,多个服务用逗号分割如“ServiceNameA@IP:port,ServiceNameB@IP2:port”。

在此，预设业务API为“http://xxxx.com/business”，“http://xxxx.com/business”是一个API的完整地址路径(path)，包含host和path两部分，但是Header不在这里，包含Header的完整说明借助于通用的curl工具来表述，应该是如下内容：

图5b根据本申请实施例示出了一种集群本地协同调用微服务的方法的实施流程示意图。如业务请求的请求流程为：“客户端->A(API:/business)->B(API:/business2)->C(API:/business3)，此时在业务请求中需要在终端100的本地开发调试微服务B，则在本地再启动-个微服务B，如图5b所示。其中，微服务A的API为business，微服务B的API为bussiness2，微服务C的API为bussiness3。调用微服务B的终端100本地有效IP和端口为“http://192.168.1.100:8080”，则在发起调用位于容器集群400中的微服务A的业务请求时，在该业务请求的头部信息中加入包含微服务B的本地有效IP和端口的调用参数，例如“x-local-services：B@http://192.168.1.100:8080”。此时，当微服务A接收到请求时检查容器集群400配置中心的配置中是否开启了本地开发模式，例如检查当前本地开发模式相关配置文件中配置项的值是否为enable。当开启本地开发模式后，则检查头部信息“x-local-services”中是否包含数据，若有，则在调用下一个微服务时使用头部信息“x-local-services”中的数据更新微服务调用地址，以调用头部信息中指定的微服务地址。

接上述实施例，原先默认微服务A调用微服务B的方式为“http://B/business2”，这里则会替换调用微服务B的地址为“http://192.168.1.100:8080/business2”，以将请求发送到本地启动的微服务中去，实现启动于终端100中的微服务B的调用。

可以理解的是，为了便于后续将请求回转至容器集群400内调用微服务C，在另一些实施例中，可以将微服务C的容器集群有效IP和端口一并加入调用微服务A的业务请求API中，保障了微服务B能够将后续API请求转发到位于容器集群400内的微服务C中，因此Header里传递了B和C的地址信息，这样A转B，B转C的时候就能用得上了。同时本地的微服务B调用下个环节的微服务C时也会依据API请求Header中的信息进行替换,例如在发起调用位于容器集群400中的微服务A的业务请求时，在该业务请求的头部信息中加入包含微服务B和微服务C的本地有效IP和端口的调用参数，例如“x-local-services：B@http://192.168.1.100:8080，C@http://192.168.1.105:8000”，本地的微服务B在调用下一个微服务C的时候，使用“x-local-services”中属于微服务C的IP信息和调用端口对微服务调用请求更新得到“http://192.168.1.105:8000/business3”，此时的网络流向为“客户端200b->A(API:/business)->Local B(HostPort:http://192.168.1.100:8080,API:/business2)->C(API:/business3)”。

可以理解的是，发送至终端100本地的对本地微服务的调用请求的Header中可以传入多个数值。对此，终端100必须检测获取到的所有对本地微服务的调用请求的Header信息中是否包含容器集群400上的调用参数，以保证在后续有调用容器集群400中的微服务时，能够将微服务调用请求转入容器集群400中，防止遗漏对后续运行在容器集群400上的微服务的调用。

通过上述方式，实现了服务调用请求的调用对象从终端100中的本地服务转为调用容器集群400中的服务，同时没有技术栈限制，无需借助外部工具进行二次开发，减少了开发人员工作量，同时Header机制对系统没有侵入性，所有用到的技能都是开发人员熟悉的，没有学习坡度。

图6根据本申请实施例示出了一种服务器200的结构示意图。

可以理解，在本申请实施例中，该服务器200可以是上述提供容器集群环境的服务器200。可以理解，服务器200上可以运行集群本地开发系统300的部分模块，例如服务器200上运行上述图3所示集群本地开发系统300的检测模块302等。

如图6所示，在一些实施例中，服务器200可以包括一个或多个处理器204，与处理器204中的至少一在个连接的系统控制逻辑208，与系统控制逻辑208连接的系统内存212，与系统控制逻辑208连接的非易失性存储器(NVM)212，以及与系统控制逻辑208连接的网络接口220。

在一些实施例中，处理器204可以包括一个或多个单核或多核处理器。在一些实施例中，处理器204可以包括通用处理器和专用处理器(例如，图形处理器，应用处理器，基带处理器等)的任意组合。在服务器200采用eNB(Evolved Node B，增强型基站)101或RAN(Radio Access Network，无线接入网)控制器102的实施例中，处理器204可以被配置为执行各种符合的实施例，例如，如图2至图4所示实施例。

在一些实施例中，系统控制逻辑208可以包括任意合适的接口控制器，以向处理器204中的至少一个和/或与系统控制逻辑208通信的任意合适的设备或组件提供任意合适的接口。

在一些实施例中，系统控制逻辑208可以包括一个或多个存储器控制器，以提供连接到系统内存212的接口。系统内存212可以用于加载以及存储数据和/或指令。在一些实施例中服务器200的内存212可以包括任意合适的易失性存储器，例如合适的动态随机存取存储器(DRAM)。

NVM/存储器212可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性的计算机可读介质。在一些实施例中，NVM/存储器212可以包括闪存等任意合适的非易失性存储器和/或任意合适的非易失性存储设备，例如HDD(Hard Disk Drive，硬盘驱动器)，CD(Compact Disc，光盘)驱动器，DVD(Digital Versatile Disc，数字通用光盘)驱动器中的至少一个。

NVM/存储器212可以包括安装服务器200的装置上的一部分存储资源，或者它可以由设备访问，但不一定是设备的一部分。例如，可以经由网络接口220通过网络访问NVM/存储212。

特别地，系统内存212和NVM/存储器212可以分别包括：指令224的暂时副本和永久副本。指令224可以包括：由处理器204中的至少一个执行时导致服务器200实施如图3-4所示的方法的指令。在一些实施例中，指令224、硬件、固件和/或其软件组件可另外地/替代地置于系统控制逻辑208，网络接口220和/或处理器204中。

网络接口220可以包括收发器，用于为服务器200提供无线电接口，进而通过一个或多个网络与任意其他合适的设备(如前端模块，天线等)进行通信。在一些实施例中，网络接口220可以集成于服务器200的其他组件。例如，网络接口220可以集成于处理器204的，系统内存212，NVM/存储器212，和具有指令的固件设备(未示出)中的至少一种，当处理器204中的至少一个执行指令时，服务器200实现上述图2至图6所示的方法。

网络接口220可以进一步包括任意合适的硬件和/或固件，以提供多输入多输出无线电接口。例如，网络接口220可以是网络适配器，无线网络适配器，电话调制解调器和/或无线调制解调器。

在一个实施例中，处理器204中的至少一个可以与用于系统控制逻辑208的一个或多个控制器的逻辑封装在一起，以形成系统封装(SiP)。在一个实施例中，处理器204中的至少一个可以与用于系统控制逻辑208的一个或多个控制器的逻辑集成在同一管芯上，以形成片上系统(SoC)。

服务器200可以进一步包括：输入/输出(I/O)设备232。I/O设备232可以包括用户界面，使得用户能够与服务器200进行交互；外围组件接口的设计使得外围组件也能够与服务器200交互。在一些实施例中，服务器200还包括传感器，用于确定与服务器200相关的环境条件和位置信息的至少一种。

在一些实施例中，用户界面可包括但不限于显示器(例如，液晶显示器，触摸屏显示器等)，扬声器，麦克风，一个或多个相机(例如，静止图像照相机和/或摄像机)，手电筒(例如，发光二极管闪光灯)和键盘。

在一些实施例中，外围组件接口可以包括但不限于非易失性存储器端口、音频插孔和电源接口。

在一些实施例中，传感器可包括但不限于陀螺仪传感器，加速度计，近程传感器，环境光线传感器和定位单元。定位单元还可以是网络接口220的一部分或与网络接口220交互，以与定位网络的组件(例如，全球定位系统(GPS)卫星)进行通信。

在说明书对“一个实施例”或“实施例”的引用意指结合实施例所描述的具体特征、结构或特性被包括在根据本申请实施例公开的至少一个范例实施方案或技术中。说明书中的各个地方的短语“在一个实施例中”的出现不一定全部指代同一个实施例。

本申请实施例的公开还涉及用于执行文本中的操作装置。该装置可以专门处于所要求的目的而构造或者其可以包括被存储在计算机中的计算机程序选择性地激活或者重新配置的通用计算机。这样的计算机程序可以被存储在计算机可读介质中，诸如，但不限于任何类型的盘，包括软盘、光盘、CD-ROM、磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、EPROM、EEPROM、磁或光卡、专用集成电路(ASIC)或者适于存储电子指令的任何类型的介质，并且每个可以被耦合到计算机系统总线。此外，说明书中所提到的计算机可以包括单个处理器或者可以是采用针对增加的计算能力的多个处理器涉及的架构。

另外，在本说明书所使用的语言已经主要被选择用于可读性和指导性的目的并且可能未被选择为描绘或限制所公开的主题。因此，本申请实施例公开旨在说明而非限制本文所讨论的概念的范围。

Claims (17)

1.一种微服务调用方法，其特征在于，应用于包括服务器和多个终端的系统，所述方法包括：

所述多个终端中的第一终端响应于用户操作，向服务器发送请求多个微服务的业务请求，所述多个微服务包括运行在服务器提供的第一执行环境中的至少一个微服务、以及运行在所述多个终端中的至少一个终端提供的第二执行环境中的第一微服务，所述业务请求包括所述第一微服务的识别信息；

所述服务器基于所述业务请求以及第一微服务的调用参数，生成用于调用所述第一微服务的第一调用请求，其中所述第一微服务的调用参数基于第一微服务的识别信息获取；

所述服务器将生成的所述第一调用请求发送给包括微服务调用模块的第二终端；

所述第二终端基于所述第一调用请求调用所述第一微服务。

2.根据权利要求1所述的方法，其特征在于，所述第一微服务的调用参数包括调用地址和调用端口信息，并且，

所述服务器基于所述业务请求以及第一微服务的调用参数，生成用于调用所述第一微服务的第一调用请求，包括：

使用所述第一微服务的调用地址和调用端口信息，替换所述业务请求中的第一微服务的识别信息，生成所述第一调用请求。

3.根据权利要求1所述的方法，其特征在于，所述业务请求包括第二微服务的识别信息，其中所述第二微服务运行于所述第一执行环境，并且，所述业务请求对所述第一微服务的调用早于对所述第二微服务的调用，

所述服务器基于业务请求以及第一微服务的调用参数，生成用于调用所述第一微服务的第一调用请求，还包括：

所述服务器基于所述业务请求以及所述第一微服务的调用参数，生成第二调用请求；

所述服务器在生成的所述第二调用请求的头部信息中添加所述第二微服务的调用参数，生成所述用于调用所述第一微服务的第一调用请求。

4.根据权利要求3所述的方法，其特征在于，所述第二终端基于所述第一调用请求调用所述第一微服务，包括：

所述第二终端检测到所述第一调用请求的头部信息包括第二微服务的调用参数，基于所述第一调用请求以及所述第二微服务的调用参数，生成用于调用第二微服务的第三调用请求；

所述第二终端将生成的所述第三调用请求发送给所述服务器，以调用运行于所述第一执行环境内运行的第二微服务。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述第一终端包括请求获取模块，并且，

所述第一终端响应于用户操作，向服务器发送请求多个微服务的业务请求，包括：

所述第一终端基于所述请求获取模块响应于用户操作，向服务器发送请求多个微服务的业务请求。

6.根据权利要求4所述的方法，其特征在于，所述服务器包括检测模块和请求生成模块，并且，所述服务器基于业务请求以及第一微服务的调用参数，生成用于调用所述第一微服务的第一调用请求，包括：

所述检测模块检测到业务请求包括所述第一微服务的识别信息，并将检测结果发送给所述请求生成模块；

所述请求生成模块基于接收到的检测结果以及所述业务请求，生成用于调用所述第一微服务的第一调用请求。

7.根据权利要求6所述的方法，其特征在于，所述请求生成模块基于接收到的检测结果以及所述业务请求，生成用于调用所述第一微服务的第一调用请求，包括：

基于所述业务请求以及所述第一微服务的调用参数，生成第二调用请求；

在生成的所述第二调用请求的头部信息中添加所述第二微服务的调用参数，生成所述用于调用所述第一微服务的第一调用请求。

8.根据权利要求7所述的方法，其特征在于，所述基于所述业务请求以及所述第一微服务的调用参数，生成第二调用请求，包括：

使用所述第一微服务的调用参数替换所述业务请求中的第一微服务的识别信息，生成所述第二调用请求。

9.根据权利要求4所述的方法，其特征在于，所述第二终端包括微服务调用模块，并且，所述第二终端基于所述第一调用请求调用所述第一微服务，包括：

所述微服务调用模块基于所述第一调用请求调用所述第二执行环境内的第一微服务。

10.根据权利要求9所述的方法，其特征在于，所述第二终端基于所述第一调用请求调用所述第一微服务，包括：

所述微服务调用模块检测到所述第一调用请求的头部信息包括第二微服务的调用参数，基于所述第一调用请求以及第二微服务的调用参数，生成用于调用第二微服务的第三调用请求；

所述微服务调用模块将生成的所述第三调用请求发送给所述服务器，以调用运行于第一执行环境内运行的第二微服务。

11.根据权利要求10所述的方法，其特征在于，所述微服务调用模块基于所述第一调用请求以及第二微服务的调用参数，生成用于调用第二微服务的第三调用请求，包括：

所述微服务调用模块使用所述第二微服务的调用参数替换所述第一调用请求的头部信息中第一微服务的调用参数，生成所述第三调用请求。

12.根据权利要求1至11中任意一项所述的方法，其特征在于，所述服务器包括对应第一执行环境采用的开发模式预设的配置文件，并且，所述方法包括：

所述服务器基于所述配置文件中对应于是否启动本地开发模式的配置信息，检测业务请求中是否包括第一微服务的识别信息。

13.根据权利要求12所述的方法，其特征在于，所述服务器基于所述配置文件中对应于是否启动本地开发模式的配置信息，检测业务请求中是否包括第一微服务的识别信息，包括：

若所述配置信息指示启动所述本地开发模式，则检测模块检测所述业务请求中是否包括第一微服务的识别；

若所述配置信息指示关闭所述本地开发模式，则检测模块对所述业务请求不进行检测。

14.根据权利要求1至13中任意一项所述的方法，其特征在于，所述第一终端和所述第二终端为同一终端或者不同终端。

15.一种微服务调用系统，其特征在于，所述系统包括多个终端和服务器，其中，

所述多个终端中的第一终端用于响应用户操作，向所述服务器发送请求多个微服务的业务请求，所述多个微服务包括运行在服务器提供的第一执行环境中的至少一个微服务、以及运行在所述多个终端中的至少一个终端提供的第二执行环境中的第一微服务，所述业务请求包括所述第一微服务的识别信息；

所述服务器用于基于所述业务请求以及第一微服务的调用参数，生成用于调用所述第一微服务的第一调用请求，其中所述第一微服务的调用参数基于第一微服务的识别信息获取；

所述服务器用于将生成的所述第一调用请求发送给包括微服务调用模块的第二终端；

所述第二终端用于基于所述第一调用请求调用所述第一微服务。

16.一种电子设备，其特征在于，包括：一个或多个处理器；一个或多个存储器；所述一个或多个存储器存储有一个或多个程序，当一个或者多个程序被所述一个或多个处理器执行时，使得所述设备执行权利要求1至14中任一项所述的微服务调用方法。

17.一种计算机可读存储介质，其特征在于，所述存储介质上存储有指令，所述指令在计算机上执行时，使所述计算机执行权利要求1至14中任一项所述的微服务调用方法。

Images