服务调用方法及装置

技术领域

本申请涉及云计算技术领域，尤其涉及一种服务调用方法及装置。

背景技术

微服务架构是一种云原生架构。基于微服务架构，应用可由许多松散耦合且可独立部署的较小组件(通常称为微服务)组成，每个组件都有各自的责任领域。在处理用户请求时，基于微服务的应用会调用多个内部微服务来共同生成其响应。

在微服务架构中，进行服务调用时，服务发现数据的加载通常基于以挎斗(sidecar)方式实现的网络代理。在该方式下，sidecar需要单独占用一个容器的进程，资源消耗较大，而且由于sidecar与其挂载的服务属于不同的容器，两者间的跨进程通信会带来时延，影响服务调用时的处理效率，从而影响服务性能。

发明内容

有鉴于此，提出了一种服务调用方法及装置。

第一方面，本申请的实施例提供了一种服务调用方法，应用于第一服务，所述第一服务为运行在服务网格中的微服务，所述方法包括：在所述第一服务调用第二服务时，判断所述第一服务的缓存中是否存在所述第二服务的服务发现数据；在所述缓存中不存在所述第二服务的服务发现数据时，拦截所述第一服务发出的调用请求；从所述服务网格的控制面获取所述第二服务的服务发现数据，并将所述第二服务的服务发现数据存储到所述缓存中；基于所述第二服务的服务发现数据，执行所述第一服务对所述第二服务的调用。

本申请的实施例的服务调用方法，在第一服务调用第二服务时，首先判断第一服务的缓存中是否存在第二服务的服务发现数据，在缓存中不存在第二服务的服务发现数据时，拦截第一服务发出的调用请求，然后从服务网格的控制面获取第二服务的服务发现数据，并将第二服务的服务发现数据存储到第一服务的缓存中，之后基于第二服务的服务发现数据，执行第一服务对第二服务的调用。

通过这种方式，能够在第一服务调用第二服务时，在第一服务的缓存中不存在第二服务的服务发现数据时，拦截调用请求并直接从服务网格的控制面获取第二服务的服务发现数据，不仅能够实现服务发现数据的懒加载，降低服务发现数据加载时的资源消耗，而且能够在加载服务发现数据时，无需使用sidecar作为网络代理，避免了跨进程通信，从而能够降低服务调用时的资源消耗，以及提高服务调用时的处理效率，进而提高服务性能。

根据第一方面，在所述服务调用方法的第一种可能的实现方式中，所述方法还包括：在所述缓存中存在所述第二服务的服务发现数据时，根据所述缓存中的所述第二服务的服务发现数据，调用所述第二服务。

本实施例中，在第一服务的缓存中存在第二服务的服务发现数据时，第一服务能够根据第一服务的缓存中的第二服务的服务发现数据，直接调用第二服务，从而能够提高服务调用时的处理效率。

根据第一方面的第一种可能的实现方式，在所述服务调用方法的第二种可能的实现方式中，所述服务发现数据包括服务的实例的IP地址及负载信息，所述根据所述缓存中的所述第二服务的服务发现数据，调用所述第二服务，包括：根据预设的负载均衡规则及所述第二服务的实例的负载信息，从所述第二服务的实例中，选取目标实例；根据所述目标实例的IP地址，调用所述目标实例。

在本实施例中，在根据缓存中的第二服务的服务发现数据调用第二服务时，可首先根据预设的负载均衡规则及第二服务的实例的负载信息，从第二服务的实例中，选取目标实例；然后根据目标实例的IP地址，调用目标实例，从而实现第一服务对第二服务的调用。通过这种方式，能够提高服务调用时的处理效率。

根据第一方面或第一方面的第一种可能的实现方式或第一方面的第二种可能的实现方式，在所述服务调用方法的第三种可能的实现方式中，所述方法还包括：在所述第一服务运行过程中，通过所述服务网格中的链路追踪服务，记录所述第一服务的链路信息。

在本实施例中，在第一服务运行过程中，通过服务网格中的链路追踪服务，记录第一服务的链路信息，以便之后在第一服务重启时，根据第一服务的历史链路信息，对服务发现数据进行预加载。

根据第一方面的第三种可能的实现方式，在所述服务调用方法的第四种可能的实现方式中，所述方法还包括：在所述第一服务重新启动过程中，通过调用所述链路追踪服务，获取所述第一服务的历史调用信息，所述历史调用信息包括所述链路追踪服务根据历史链路信息确定的所述第一服务调用过的服务的标识；在所述第一服务启动后，从所述服务网格的控制面，获取所述历史调用信息包括的各个服务的服务发现数据；将获取的服务发现数据存储到所述缓存中。

在本实施例中，能够在第一服务重新启动过程中，通过调用链路追踪服务，获取第一服务的历史调用信息，并在第一服务启动后，从服务网格的控制面，获取历史调用信息包括的各个服务的服务发现数据，以及将获取的服务发现数据存储到缓存中。通过这种方式，能够在第一服务启动时，实现服务发现数据的预加载，从而能够减少首次获取服务发现数据的时间成本，提高服务调用时的处理效率，进而提高服务性能。

根据第一方面的第三种可能的实现方式，在所述服务调用方法的第五种可能的实现方式中，所述方法还包括：在所述第一服务运行过程中，通过周期调用所述链路追踪服务，对所述缓存中的服务发现数据进行周期更新。

本实施例中，能够在第一服务运行过程中，通过周期调用链路追踪服务，对缓存中的服务发现数据进行周期更新，从而能够实现服务发现数据的动态懒加载。

根据第一方面或者第一方面的第一种可能的实现方式至第一方面的第五种可能的实现方式中的任意一种，在所述服务调用方法的第六种可能的实现方式中，所述方法还包括：向所述服务网格的控制面订阅所述缓存中的服务发现数据，以使所述服务网格的控制面在所述服务发现数据更新时，向所述第一服务推送更新后的服务发现数据。

在本实施例中，能够向服务网格的控制面订阅第一服务的缓存中的服务发现数据，以使服务网格的控制面在服务发现数据更新时，向第一服务推送更新后的服务发现数据，从而能够使得第一服务的缓存中的服务发现数据保持动态更新，提高第一服务的缓存中的服务发现数据的准确性。

根据第一方面或者第一方面的第一种可能的实现方式至第一方面的第六种可能的实现方式中的任意一种，在所述服务调用方法的第七种可能的实现方式中，所述方法基于Java代理以插件方式实现，所述插件挂载到所述第一服务。

在本实施例中，基于Java代理以插件方式实现，并将插件挂载到第一服务，不仅能够在无侵入的前提下将实现本申请实施例的插件动态加载到第一服务，而且插件与第一服务同属一个进程，减少了跨进程通信，从而能够在服务调用时，使用Java插件替换现有的服务网格中的sidecar，使得服务的资源消耗更少，性能更优。

第二方面，本申请的实施例提供了一种服务调用装置，应用于第一服务，所述第一服务为运行在服务网格中的微服务，所述装置包括：判断模块，用于在所述第一服务调用第二服务时，判断所述第一服务的缓存中是否存在所述第二服务的服务发现数据；拦截模块，用于在所述缓存中不存在所述第二服务的服务发现数据时，拦截所述第一服务发出的调用请求；第一获取模块，用于从所述服务网格的控制面获取所述第二服务的服务发现数据，并将所述第二服务的服务发现数据存储到所述缓存中；第一调用模块，基于所述第二服务的服务发现数据，执行所述第一服务对所述第二服务的调用。

本申请的实施例的服务调用装置，在第一服务调用第二服务时，首先判断第一服务的缓存中是否存在第二服务的服务发现数据，在缓存中不存在第二服务的服务发现数据时，拦截第一服务发出的调用请求，然后从服务网格的控制面获取第二服务的服务发现数据，并将第二服务的服务发现数据存储到第一服务的缓存中，之后基于第二服务的服务发现数据，执行第一服务对第二服务的调用。

通过这种方式，能够在第一服务调用第二服务时，在第一服务的缓存中不存在第二服务的服务发现数据时，拦截调用请求并直接从服务网格的控制面获取第二服务的服务发现数据，不仅能够实现服务发现数据的懒加载，降低服务发现数据加载时的资源消耗，而且能够在加载服务发现数据时，无需使用sidecar作为网络代理，避免了跨进程通信，从而能够降低服务调用时的资源消耗，以及提高服务调用时的处理效率，进而提高服务性能。

根据第二方面，在所述服务调用装置的第一种可能的实现方式中，所述装置还包括：第二调用模块，在所述缓存中存在所述第二服务的服务发现数据时，根据所述缓存中的所述第二服务的服务发现数据，调用所述第二服务。

本实施例中，在第一服务的缓存中存在第二服务的服务发现数据时，第一服务能够根据第一服务的缓存中的第二服务的服务发现数据，直接调用第二服务，从而能够提高服务调用时的处理效率。

根据第二方面的第一种可能的实现方式，在所述服务调用装置的第二种可能的实现方式中，所述服务发现数据包括服务的实例的IP地址及负载信息，所述第二调用模块，包括：目标实例选取子模块，用于根据预设的负载均衡规则及所述第二服务的实例的负载信息，从所述第二服务的实例中，选取目标实例；目标实例调用子模块，用于根据所述目标实例的IP地址，调用所述目标实例。

在本实施例中，在根据缓存中的第二服务的服务发现数据调用第二服务时，可首先根据预设的负载均衡规则及第二服务的实例的负载信息，从第二服务的实例中，选取目标实例；然后根据目标实例的IP地址，调用目标实例，从而实现第一服务对第二服务的调用。通过这种方式，能够提高服务调用时的处理效率。

根据第二方面或第二方面的第一种可能的实现方式或第二方面的第二种可能的实现方式，在所述服务调用装置的第三种可能的实现方式中，所述装置还包括：链路信息记录模块，用于在所述第一服务运行过程中，通过所述服务网格中的链路追踪服务，记录所述第一服务的链路信息。

在本实施例中，在第一服务运行过程中，通过服务网格中的链路追踪服务，记录第一服务的链路信息，以便之后在第一服务重启时，根据第一服务的历史链路信息，对服务发现数据进行预加载。

根据第二方面的第三种可能的实现方式，在所述服务调用装置的第四种可能的实现方式中，所述装置还包括：历史调用信息获取模块，用于在所述第一服务重新启动过程中，通过调用所述链路追踪服务，获取所述第一服务的历史调用信息，所述历史调用信息包括所述链路追踪服务根据历史链路信息确定的所述第一服务调用过的服务的标识；第二获取模块，用于在所述第一服务启动后，从所述服务网格的控制面，获取所述历史调用信息包括的各个服务的服务发现数据；存储模块，用于将获取的服务发现数据存储到所述缓存中。

在本实施例中，能够在第一服务重新启动过程中，通过调用链路追踪服务，获取第一服务的历史调用信息，并在第一服务启动后，从服务网格的控制面，获取历史调用信息包括的各个服务的服务发现数据，以及将获取的服务发现数据存储到缓存中。通过这种方式，能够在第一服务启动时，实现服务发现数据的预加载，从而能够减少首次获取服务发现数据的时间成本，提高服务调用时的处理效率，进而提高服务性能。

根据第二方面的第三种可能的实现方式，在所述服务调用装置的第五种可能的实现方式中，所述装置还包括：更新模块，用于在所述第一服务运行过程中，通过周期调用所述链路追踪服务，对所述缓存中的服务发现数据进行周期更新。

本实施例中，能够在第一服务运行过程中，通过周期调用链路追踪服务，对缓存中的服务发现数据进行周期更新，从而能够实现服务发现数据的动态懒加载。

根据第二方面或第二方面的第一种可能的实现方式至第二方面的第五种可能的实现方式中的任意一种，在所述服务调用装置的第六种可能的实现方式中，所述装置还包括：订阅模块，用于向所述服务网格的控制面订阅所述缓存中的服务发现数据，以使所述服务网格的控制面在所述服务发现数据更新时，向所述第一服务推送更新后的服务发现数据。

在本实施例中，能够向服务网格的控制面订阅第一服务的缓存中的服务发现数据，以使服务网格的控制面在服务发现数据更新时，向第一服务推送更新后的服务发现数据，从而能够使得第一服务的缓存中的服务发现数据保持动态更新，提高第一服务的缓存中的服务发现数据的准确性。

根据第二方面或第二方面的第一种可能的实现方式至第二方面的第六种可能的实现方式中的任意一种，在所述服务调用装置的第七种可能的实现方式中，所述装置基于Java代理以插件方式实现，所述插件挂载到所述第一服务。

在本实施例中，基于Java代理以插件方式实现，并将插件挂载到第一服务，不仅能够在无侵入的前提下将实现本申请实施例的插件动态加载到第一服务，而且插件与第一服务同属一个进程，减少了跨进程通信，从而能够在服务调用时，使用Java插件替换现有的服务网格中的sidecar，使得服务的资源消耗更少，性能更优。

第三方面，本申请的实施例提供了一种计算设备集群，包括至少一个计算设备，每个计算设备包括处理器和存储器；所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令，以使得所述计算设备集群执行上述第一方面或者第一方面的多种可能的实现方式中的一种或几种的服务调用方法。

第四方面，本申请的实施例提供了一种包含指令的计算机程序产品，当所述指令被计算设备集群运行时，使得所述计算设备集群执行上述第一方面或者第一方面的多种可能的实现方式中的一种或几种的服务调用方法。

第五方面，本申请的实施例提供了一种计算机可读存储介质，包括计算机程序指令，当所述计算机程序指令由计算设备集群执行时，所述计算设备集群执行上述第一方面或者第一方面的多种可能的实现方式中的一种或几种的服务调用方法。

本申请的这些和其他方面在以下(多个)实施例的描述中会更加简明易懂。

附图说明

包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了本申请的示例性实施例、特征和方面，并且用于解释本申请的原理。

图1示出根据本申请一实施例的服务调用方法的应用场景的示意图。

图2示出根据本申请一实施例的服务调用方法的流程图。

图3示出根据本申请一实施例的服务调用方法的处理过程的示意图。

图4示出根据本申请一实施例的服务调用方法的处理过程的示意图。

图5示出根据本申请一实施例的服务调用方法的处理过程的示意图。

图6示出根据本申请一实施例的服务调用方法的处理过程的示意图。

图7示出根据本申请一实施例的服务调用装置的框图。

具体实施方式

以下将参考附图详细说明本申请的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。

在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。

另外，为了更好的说明本申请，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本申请同样可以实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本申请的主旨。

为了便于理解，首先对本申请的实施例涉及的相关术语进行说明：

服务治理：对微服务进行管理和治理，例如服务注册、服务发现、负载均衡、应用路由等。

服务发现：是指微服务架构中作为客户端的服务自动发现服务地址列表的能力。服务发现的过程可以看作是作为客户端的服务自动加载服务发现数据的过程。借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置及IP地址的情况下实现通信。

服务网格：即service mesh，是微服务架构中处理服务之间的通信的基础设施层，其支持云原生应用的网络请求在复杂的拓扑环境中可靠地传递。服务网格与应用部署在一起，但对应用透明。服务网格通常包括数据面(data plane)和控制面(control plane)。

服务可见性：是指当前服务可从服务网格的控制面获得其调用的服务的服务发现数据。

下面以开源服务网格Istio为例，对服务网格进行示例性地说明。

开源服务网格Istio包括数据面和控制面。Istio的数据面是指Envoy代理(Envoyproxy)这一层。Istio将Envoy代理作为一个sidecar容器注入到服务容器旁边，然后Envoy代理拦截该服务的所有入站和出站流量。Istio的控制面是指Istiod组件这一层，其提供服务发现(discovery)、配置(configuration)及证书管理(certificates)等功能。

在Istio中，控制面基于服务发现(x discovery service，xDS)协议向数据面传递服务信息和治理规则；数据面将xDS协议作为其应用编程接口(application programminginterface，API)，并基于xDS协议与控制面进行通信。

其中，xDS协议中的x表示xDS协议不是指具体的某个协议，而是一组基于不同数据源的服务发现协议的总称，包括监听器发现服务(listener discovery service，LDS)、集群发现服务(cluster discovery service，CDS)、集群成员发现服务(endpoint discoveryservice，EDS)、路由发现服务(route discovery service，RDS)、聚合发现服务(aggregated discovery service，ADS)、健康度发现服务(health discovery service，HDS)、密钥发现服务(secret discovery service，SDS)、指标发现服务(metric service，MS)、限流发现服务(rate limit service，RLS)等。

在微服务架构中，进行服务调用时，服务发现数据的加载通常基于以sidecar方式实现的网络代理。例如，开源服务网格Istio中，每个服务容器旁边均有用于实现Envoy代理的sidecar容器，进行服务调用时，服务发现数据的加载均通过sidecar容器。然而，sidecar需要单独占用一个容器的进程，资源消耗较大，而且sidecar与其挂载的服务属于不同的容器，两者间的跨进程通信会带来时延，影响服务调用时的处理效率，从而影响服务性能。

此外，基于sidecar(即基于以sidecar方式实现的网络代理)的服务发现数据的加载，还存在不适用于大规模场景、部署及运维复杂等问题。在一个示例中，Istio下发服务发现数据采用全量下发策略，即服务网格中的所有sidecar进程都持有整个网格内所有的服务发现数据，但是，大部分服务发现数据对工作负载来说是无用的，且在大规模场景下，服务发现数据的全量下发会导致严重的资源消耗，即服务发现数据的全量下发策略并不适用于大规模场景。

在另一个示例中，服务发现数据的加载采用按需加载策略。例如，提前预配置服务间的依赖关系，在服务调用过程中，根据预配置的服务间的依赖关系，加载服务发现数据，但是，该方式通常需要手动配置，不适用于大规模场景且维护困难。再例如，可在Istio中部署专门的中间网关服务及控制器服务，来实现服务发现数据的按需加载，但是，该方式需要在服务网格中启动额外的中间网关服务及控制器服务，不仅会带来资源消耗，而且使得服务的部署及运维变得更为复杂。

为了解决上述技术问题，本申请的实施例提供了一种服务调用方法，应用于第一服务，所述第一服务为运行在服务网格中的微服务，所述方法包括：在所述第一服务调用第二服务时，判断所述第一服务的缓存中是否存在所述第二服务的服务发现数据；在所述缓存中不存在所述第二服务的服务发现数据时，拦截所述第一服务发出的调用请求；从所述服务网格的控制面获取所述第二服务的服务发现数据，并将所述第二服务的服务发现数据存储到所述缓存中；基于所述第二服务的服务发现数据，执行所述第一服务对所述第二服务的调用。

本申请实施例的服务调用方法，在第一服务调用第二服务时，首先判断第一服务的缓存中是否存在第二服务的服务发现数据，在缓存中不存在第二服务的服务发现数据时，拦截第一服务发出的调用请求，然后从服务网格的控制面获取第二服务的服务发现数据，并将第二服务的服务发现数据存储到第一服务的缓存中，之后基于第二服务的服务发现数据，执行第一服务对第二服务的调用。

通过这种方式，能够在第一服务调用第二服务时，在第一服务的缓存中不存在第二服务的服务发现数据时，拦截调用请求并直接从服务网格的控制面获取第二服务的服务发现数据，不仅能够实现服务发现数据的懒加载，降低服务发现数据加载时的资源消耗，而且能够在加载服务发现数据时，无需使用sidecar作为网络代理，避免了跨进程通信，从而能够降低服务调用时的资源消耗，以及提高服务调用时的处理效率，进而提高服务性能。

其中，懒加载即延迟加载，是一种非必要资源不预先加载且仅在需要时加载它们的策略。懒加载是一种按需加载，能够降低资源占用。

本申请实施例的服务调用方法可应用于微服务架构中的服务治理场景。在实际应用场景的服务网格中，通常会部署十万以上甚至上百万个服务的实例，在这种大规模场景下，通过本申请实施例的服务调用方法进行服务调用，能够在服务调用时，实现无需基于sidecar的服务发现数据的懒加载，不仅能够降低服务调用时的资源消耗，而且能够提高服务调用时的处理效率，从而提升服务性能。

图1示出根据本申请一实施例的服务调用方法的应用场景的示意图。如图1所示，终端设备130通过网络(例如有线网络、无线网络等)与云计算中心110连接，云计算中心110包括服务器集群120，服务器集群120基于微服务架构，为终端设备130上的应用提供服务。其中，终端设备130可以是智能手机、上网本、平板电脑、笔记本电脑、可穿戴电子设备(如智能手环、智能手表等)、TV、虚拟现实设备、音响、电子墨水，等等。本申请对终端设备的具体类型不作限制。

用户在终端设备130上使用某一应用时，服务器集群120会调用多个内部微服务来共同生成该应用的响应。其中，服务器集群120在调用多个内部微服务时，会存在微服务之间的调用，例如一个微服务对另一个微服务的调用，该情况下，可使用本申请实施例的服务调用方法来实现一个微服务对另一个微服务的调用。

图2示出根据本申请一实施例的服务调用方法的流程图。本申请实施例的服务调用方法可应用于第一服务，第一服务为运行在服务网格中的微服务。例如，服务网格运行在图1所示的服务器集群120上，第一服务为运行在该服务网格中的作为调用发起方的微服务。

如图2所示，本申请实施例的服务调用方法包括：

步骤S210，在所述第一服务调用第二服务时，判断所述第一服务的缓存中是否存在所述第二服务的服务发现数据。

其中，第一服务与第二服务均为运行在服务网格中的微服务。第一服务及第二服务均有对应的缓存(例如cache)。可将第一服务加载的服务发现数据存储在第一服务的缓存中，将第二服务加载的服务发现数据存储在第二服务的缓存中。

在第一服务调用第二服务的场景中，可将第二服务看作服务提供方，将第一服务看作服务消费方或客户方。在第一服务调用第二服务时，可首先判断第一服务的缓存中是否存在第二服务的服务发现数据。例如，假设第一服务通过第二服务的标识(例如可以唯一标识第二服务的ID、名称等)来调用第二服务，判断第一服务的缓存中是否存在第二服务的服务发现数据时，可根据第二服务的标识，通过查找、比对等方式，确定第一服务的缓存中是否存在第二服务的服务发现数据。

在一种可能的实现方式中，可在第一服务的缓存中设置第一服务的服务可见性列表。第一服务的服务可见性列表可用于存储第一服务的缓存中存储的服务发现数据所属的服务的标识。例如，假设第一服务S0的缓存中存储了服务S1、服务S2、服务S3、服务S4及服务S5的服务发现数据，则可将服务S1、服务S2、服务S3、服务S4及服务S5的标识，存储到第一服务S0的服务可见性列表中。

在判断第一服务的缓存中是否存在第二服务的服务发现数据时，可判断第一服务的服务可见性列表中是否存在第二服务的标识。如果第一服务的服务可见性列表中存在第二服务的标识，则可认为第一服务的缓存中存在第二服务的服务发现数据。如果第一服务的服务可见性列表中不存在第二服务的标识，则可认为第一服务的缓存中不存在第二服务的服务发现数据。

需要说明的是，本领域技术人员还可通过其他方式来判断第一服务的缓存中是否存在第二服务的服务发现数据，本申请对此不作限制。

步骤S220，在所述缓存中不存在所述第二服务的服务发现数据时，拦截所述第一服务发出的调用请求。

在第一服务的缓存中不存在第二服务的服务发现数据时，可拦截第一服务发出的调用请求，以便从服务网格的控制面获取第二服务的服务发现数据。

步骤S230，从所述服务网格的控制面获取所述第二服务的服务发现数据，并将所述第二服务的服务发现数据存储到所述缓存中。

拦截第一服务发出的调用请求后，可根据第二服务的标识，从服务网格的控制面获取第二服务的服务发现数据。第二服务的服务发现数据可包括第二服务的标识(例如可以唯一标识第二服务的ID、名称等)、第二服务的实例的数量以及各个实例的标识(例如可以唯一标识各个实例的ID、名称等)、IP地址、负载信息等。需要说明的是，第二服务的服务发现数据还可包括其他信息，本领域技术人员可根据实际情况对服务发现数据包括的具体内容进行设置，本申请对此不作限制。

从服务网格的控制面获取到第二服务的服务发现数据后，可将获取的第二服务的服务发现数据存储到第一服务的缓存中。

在一种可能的实现方式中，在第一服务的缓存中设置第一服务的服务可见性列表的情况下，可将第二服务的标识，存储到第一服务的服务可见性列表中。

在一种可能的实现方式中，在从服务网格的控制面获取第二服务的服务发现数据的同时，还可向服务网格的控制面订阅第二服务的服务发现数据。在向服务网格的控制面订阅第二服务的服务发现数据后，在服务网格的控制面发现第二服务的服务发现数据更新时，服务网格的控制面会向第一服务推送第二服务的更新后的服务发现数据。第一服务在接收到服务网格的控制面推送的第二服务的更新后的服务发现数据(即新的服务发现数据)时，使用第二服务的更新后的服务发现数据(即新的服务发现数据)，替换缓存中的第二服务的服务发现数据(即旧的服务发现数据)。通过这种方式，能够使得第一服务的缓存中的第二服务的服务发现数据保持动态更新，从而提高缓存中的第二服务的服务发现数据的准确性。

步骤S240，基于所述第二服务的服务发现数据，执行所述第一服务对所述第二服务的调用。

在将第二服务的服务发现数据存储到第一服务的缓存中后，可根据第一服务的缓存中的第二服务的服务发现数据，执行第一服务对第二服务的调用。具体可例如，可从第一服务的缓存中获取第二服务的服务发现数据，并从该服务发现数据中，获取第二服务的实例的负载信息；然后根据预设的负载均衡规则(例如负载最低优先等)及第二服务的实例的负载信息，从第二服务的实例中，选取目标实例；之后可从第二服务的服务发现数据中，获取目标实例的IP地址，并根据目标实例的IP地址，调用目标实例，从而实现第一服务对第二服务的调用。

需要说明的是，第二服务的实例可以为多个，本申请对第二服务的实例的具体数量不作限制。

在一种可能的实现方式中，第一服务调用第二服务时，在第一服务的缓存中存在第二服务的服务发现数据时，可根据第一服务的缓存中的第二服务的服务发现数据，直接调用第二服务，从而能够提高服务调用时的处理效率。

在一种可能的实现方式中，根据第一服务的缓存中的第二服务的服务发现数据，调用第二服务时，可从第一服务的缓存中获取第二服务的服务发现数据，并从该服务发现数据中，获取第二服务的实例的负载信息；然后根据预设的负载均衡规则(例如负载最低优先等)及第二服务的实例的负载信息，从第二服务的实例中，选取目标实例；之后可从第二服务的服务发现数据中，获取目标实例的IP地址，并根据目标实例的IP地址，调用目标实例，从而实现第一服务对第二服务的调用。

图3示出根据本申请一实施例的服务调用方法的处理过程的示意图。如图3所示，第一服务310的缓存311中存储了第二服务320(service320)的服务发现数据，示例如下：

xds{

cds[service320]

eds[service320]

……

}

在第一服务310调用第二服务320时，首先判断缓存311中是否存在第二服务320的服务发现数据。经判断，缓存311中存在第二服务320的服务发现数据，该情况下，第一服务310可从缓存311中获取第二服务320的服务发现数据，并根据获取的第二服务320的服务发现数据，直接调用第二服务320。

图4示出根据本申请一实施例的服务调用方法的处理过程的示意图。如图4所示，第一服务410的缓存411中存储了服务F(serviceF)的服务发现数据，示例如下：

xds{

cds[serviceF]

eds[serviceF]

……

}

在第一服务410运行过程中，由于热更新等行为，第一服务410对第二服务420产生了依赖关系。在第一服务410调用第二服务420时，首先判断缓存411中是否存在第二服务420(service420)的服务发现数据。经判断，缓存411中不存在第二服务420的服务发现数据，该情况下，可拦截第一服务410发出的调用请求，然后从服务网格的控制面430中获取第二服务420的服务发现数据，并将获取的第二服务420的服务发现数据存储到缓存411中，在该过程中，还可向服务网格的控制面430订阅第二服务420的服务发现数据，以获取第二服务420的服务发现数据的更新。

将第二服务420的服务发现数据存储到缓存411中后，缓存411中的服务发现数据可示例如下：

xds{

cds[serviceF]

eds[serviceF]

……

cds[service420]

eds[service420]

……

}

之后，可继续执行第一服务410对第二服务420的调用，具体为：第一服务410从缓存411中获取第二服务420的服务发现数据，并根据获取的第二服务420的服务发现数据，调用第二服务420。

在一种可能的实现方式中，在第一服务运行过程中，还可通过服务网格中的链路追踪服务，记录第一服务的链路信息。其中，链路信息可包括服务依赖信息(例如第一服务调用的服务的信息)。在一些示例中，链路信息还可包括调用链路、调用请求量等其他信息，本申请对此不作限制。链路追踪服务可提供调用链路还原、调用请求量统计、链路拓扑、依赖分析等功能。

在第一服务运行过程中，通过服务网格中的链路追踪服务，追踪并记录第一服务的链路信息，以便之后在第一服务重启时，根据第一服务的历史链路信息，对服务的服务发现数据进行预加载。

在一种可能的实现方式中，在第一服务重新启动过程中，可通过调用服务网格中的链路追踪服务，获取第一服务的历史调用信息。其中，历史调用信息可包括链路追踪服务根据第一服务的历史链路信息确定的第一服务调用过的服务的标识。在第一服务启动后，可从服务网格的控制面，获取历史调用信息包括的第一服务调用过的各个服务的服务发现数据，并将获取的服务发现数据存储到第一服务的缓存中。

例如，假设在第一服务S6启动过程中，可通过调用服务网格中的链路追踪服务，获得第一服务S6的历史调用信息，该历史调用信息包括第一服务S6在当前时刻之前的预设时长内调用过的服务的标识：服务S7、服务S8及服务S9的标识；在第一服务S6启动后，可分别根据服务S7、服务S8及服务S9的标识，从服务网格的控制面获取服务S7、服务S8及服务S9的服务发现数据，并将获取的服务S7、服务S8及服务S9的服务发现数据存储到第一服务S6的缓存中。

通过这种方式，能够在第一服务重新启动时，通过链路追踪服务获取第一服务的历史调用信息，并根据第一服务的历史调用信息，实现服务发现数据的预加载，从而减少首次获取服务发现数据的时间成本，提高服务调用时的处理效率，进而提高服务性能。

在一种可能的实现方式中，在第一服务的缓存中设置第一服务的服务可见性列表的情况下，可将历史调用信息包括的第一服务调用过的各个服务的标识，存储到第一服务的服务可见性列表中。

在一种可能的实现方式中，在从服务网格的控制面获取历史调用信息包括的第一服务调用过的各个服务(这里称为第三服务)的服务发现数据的同时，还可向服务网格的控制面订阅各个第三服务的服务发现数据。

在向服务网格的控制面订阅各个第三服务的服务发现数据后，对于任一第三服务，在服务网格的控制面发现所述第三服务的服务发现数据更新时，服务网格的控制面会向第一服务推送所述第三服务的更新后的服务发现数据。第一服务在接收到服务网格的控制面推送的所述第三服务的更新后的服务发现数据(即新的服务发现数据)时，使用所述第三服务的更新后的服务发现数据(即新的服务发现数据)，替换缓存中的所述第三服务的服务发现数据(即旧的服务发现数据)。通过这种方式，能够使得第一服务的缓存中的第三服务的服务发现数据保持动态更新，从而提高缓存中的第三服务的服务发现数据的准确性。

图5示出根据本申请一实施例的服务调用方法的处理过程的示意图。如图5所示，在第一服务510重新启动过程中，可通过调用链路追踪服务520，获取第一服务510的历史调用信息。在第一服务510启动后，可从服务网格的控制面530，获取第一服务510的历史调用信息包括的各个服务的服务发现数据，并将获取的服务发现数据存储到缓存511中；在该过程中，还可向服务网格的控制面530订阅第一服务510的历史调用信息包括的各个服务的服务发现数据，以获取该服务发现数据的更新。

在一种可能的实现方式中，在第一服务运行过程中，还可通过周期调用服务网格中的链路追踪服务，对缓存中的服务发现数据进行周期更新。具体地，在第一服务运行过程中，可按照预设周期，调用服务网格中的链路追踪服务，获取第一服务在最近一个周期内的历史调用信息，然后根据最近一个周期内的历史调用信息，对第一服务的缓存中的服务发现数据进行更新。

例如，假设第一服务D1的缓存中的服务发现数据为服务D2、服务D3、服务D4的服务发现数据，在第一服务D1的运行过程中，按照预设周期，调用服务网格中的链路追踪服务，获取的第一服务D1在最近一个周期内的历史调用信息包括：服务D2、服务D3、服务D5、服务D6的标识，那么，可根据第一服务D1在最近一个周期内的历史调用信息，对第一服务D1的缓存中的服务发现数据进行更新，具体如下：

从第一服务D1的缓存中删除服务D4的服务发现数据；

从服务网格的控制面获取服务D5的服务发现数据，并将获取的服务D5的服务发现数据存储到第一服务D1的缓存中；

从服务网格的控制面获取服务D6的服务发现数据，并将获取的服务D6的服务发现数据存储到第一服务D1的缓存中。

通过这种方式，能够在第一服务运行过程中，通过周期调用链路追踪服务，对缓存中的服务发现数据进行周期更新，从而实现服务发现数据的动态懒加载。

在一种可能的实现方式中，在第一服务的缓存中设置第一服务的服务可见性列表的情况下，还可根据最近一个周期内的历史调用信息，对第一服务的服务可见性列表进行更新，以提高第一服务的服务可见性列表的准确性。

在一种可能的实现方式中，本申请实施例的服务调用方法可基于Java代理(JavaAgent)以插件方式实现，该插件挂载到第一服务。启动时加载Java Agent是Java开发工具包(Java Development Kit，JDK)1.5之后引入的新特性，该特性为用户提供了在Java虚拟机(Java virtual machine，JVM)将字节码文件读入内存之后，JVM使用对应的字节流在Java堆中生成一个Class对象之前，用户可以对其字节码进行修改的能力，从而JVM也将会使用用户修改过之后的字节码进行Class对象的创建，达到动态增强程序逻辑的目的。

本申请实施例的服务调用方法，基于Java代理以插件方式实现，并将插件挂载到第一服务，不仅能够在无侵入的前提下将实现本申请实施例的插件动态加载到第一服务，而且插件与第一服务同属一个进程，减少了跨进程通信，从而能够在服务调用时，使用Java插件替换现有的服务网格中的sidecar，使得服务的资源消耗更少，性能更优。

在一种可能的实现方式中，在本申请实施例的服务调用方法基于Java代理(JavaAgent)以插件方式实现时，插件可包括服务发现数据订阅模块及服务调用拦截模块。服务发现数据订阅模块主要用于与服务网格的控制面建立连接，获取并订阅服务发现数据。服务发现数据订阅模块还可用于实现负载均衡、流量控制、限流降级等服务治理功能。在第一服务重新启动过程中，服务发现数据订阅模块可调用服务网格中的链路追踪模块，实现服务发现数据的预加载。在第一服务运行过程中，服务发现数据订阅模块还可周期调用服务网格中的链路追踪服务，对缓存中的服务发现数据进行周期更新。服务调用拦截模块可在第一服务调用第二服务且第一服务的缓存中不存在第二服务的服务发现数据时，拦截第一服务的调用请求，并通知服务调用拦截模块获取第二服务的服务发现数据。

图6示出根据本申请一实施例的服务调用方法的处理过程的示意图。如图6所示，在服务A启动过程中，通过调用链路追踪服务，获取服务A的历史调用信息，具体为：服务A调用过服务B；在服务A启动后，从服务网格的控制面获取服务B的服务发现数据，并将服务B的服务发现数据存储到服务A的缓存中，实现服务发现数据的预加载。在从服务网格的控制面获取服务B的服务发现数据的同时，还可向服务网格的控制面订阅服务B的服务发现数据，以及时获得服务B的服务发现数据的更新。

在服务A运行过程中，在服务A调用服务B时，可判断服务A的缓存中是否存在服务B的服务发现数据。经判断，服务A的缓存中存在服务B的服务发现数据，则服务A可根据缓存中的服务B的服务发现数据，直接调用服务B。

在服务A运行过程中，在服务A调用服务C时，可判断服务A的缓存中是否存在服务C的服务发现数据。经判断，服务A的缓存中不存在服务C的服务发现数据，该情况下，可拦截服务A发出的调用请求，然后从服务网格的控制面获取服务C的服务发现数据，并将服务C的服务发现数据存储到服务A的缓存中，实现服务发现数据的懒加载。之后可根据服务A的缓存中的服务C的服务发现数据，执行服务A对服务C的调用。此外，在从服务网格的控制面获取服务C的服务发现数据的同时，还可向服务网格的控制面订阅服务C的服务发现数据，以及时获得服务C的服务发现数据的更新。

在服务A运行过程中，可通过调用链路追踪服务，记录服务A的链路信息。在服务A运行过程中，还可通过周期调用链路追踪服务，对服务A的缓存中的服务发现数据进行周期更新。

本申请实施例的服务调用方法，基于Java Agent以插件方式实现，并挂载到宿主服务(即第一服务)中，替换sidecar与服务网格的控制面进行数据交互，避免了频繁的跨进程通信，有效提高了高并发、大规模等场景下的服务性能。

本申请实施例的服务调用方法，实现了服务发现数据在服务启动阶段的预加载以及在服务运行阶段的懒加载，在不影响宿主服务自身业务的前提下，实现了最小化的服务可见性配置，显著降低了资源消耗。

与相关技术相比，本申请实施例的服务调用方法，能够使用依赖分析和订阅推送机制替换sidecar来实现与服务网格的控制面之间的通信和数据交互，以及能够采用链路追踪服务来进行启动阶段的服务发现数据的预加载以及在服务运行阶段进行服务发现数据的懒加载。

图7示出本申请一实施例的服务调用装置的框图。所述服务调用装置应用于第一服务，所述第一服务为运行在服务网格中的微服务。

如图7所示，所述服务调用装置包括：

判断模块710，用于在所述第一服务调用第二服务时，判断所述第一服务的缓存中是否存在所述第二服务的服务发现数据；

拦截模块720，用于在所述缓存中不存在所述第二服务的服务发现数据时，拦截所述第一服务发出的调用请求；

第一获取模块730，用于从所述服务网格的控制面获取所述第二服务的服务发现数据，并将所述第二服务的服务发现数据存储到所述缓存中；

第一调用模块740，基于所述第二服务的服务发现数据，执行所述第一服务对所述第二服务的调用。

在一种可能的实现方式中，所述装置还包括：第二调用模块，在所述缓存中存在所述第二服务的服务发现数据时，根据所述缓存中的所述第二服务的服务发现数据，调用所述第二服务。

在一种可能的实现方式中，所述服务发现数据包括服务的实例的IP地址及负载信息，所述第二调用模块，包括：目标实例选取子模块，用于根据预设的负载均衡规则及所述第二服务的实例的负载信息，从所述第二服务的实例中，选取目标实例；目标实例调用子模块，用于根据所述目标实例的IP地址，调用所述目标实例。

在一种可能的实现方式中，所述装置还包括：链路信息记录模块，用于在所述第一服务运行过程中，通过所述服务网格中的链路追踪服务，记录所述第一服务的链路信息。

在一种可能的实现方式中，所述装置还包括：历史调用信息获取模块，用于在所述第一服务重新启动过程中，通过调用所述链路追踪服务，获取所述第一服务的历史调用信息，所述历史调用信息包括所述链路追踪服务根据历史链路信息确定的所述第一服务调用过的服务的标识；第二获取模块，用于在所述第一服务启动后，从所述服务网格的控制面，获取所述历史调用信息包括的各个服务的服务发现数据；存储模块，用于将获取的服务发现数据存储到所述缓存中。

在一种可能的实现方式中，所述装置还包括：更新模块，用于在所述第一服务运行过程中，通过周期调用所述链路追踪服务，对所述缓存中的服务发现数据进行周期更新。

在一种可能的实现方式中，所述装置还包括：订阅模块，用于向所述服务网格的控制面订阅所述缓存中的服务发现数据，以使所述服务网格的控制面在所述服务发现数据更新时，向所述第一服务推送更新后的服务发现数据。

在一种可能的实现方式中，所述装置基于Java代理以插件方式实现，所述插件挂载到所述第一服务。

本申请的实施例提供了一种计算设备集群，包括至少一个计算设备，每个计算设备包括处理器和存储器；所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令，以使得所述计算设备集群执行上述方法。

本申请的实施例提供了一种包含指令的计算机程序产品，当所述指令被计算设备集群运行时，使得所述计算设备集群执行上述方法。

本申请的实施例提供了一种计算机可读存储介质，包括计算机程序指令，当所述计算机程序指令由计算设备集群执行时，所述计算设备集群执行上述方法。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RandomAccess Memory，RAM)、只读存储器(Read Only Memory，ROM)、可擦式可编程只读存储器(Electrically Programmable Read-Only-Memory，EPROM或闪存)、静态随机存取存储器(Static Random-Access Memory，SRAM)、便携式压缩盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、数字多功能盘(Digital Video Disc，DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。

这里所描述的计算机可读程序指令或代码可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本申请操作的计算机程序指令可以是汇编指令、指令集架构(Instruction Set Architecture，ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(Local Area Network，LAN)或广域网(WideArea Network，WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(Field-ProgrammableGate Array，FPGA)或可编程逻辑阵列(Programmable Logic Array，PLA)，该电子电路可以执行计算机可读程序指令，从而实现本申请的各个方面。

这里参照根据本申请实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本申请的多个实施例的装置、系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。

也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行相应的功能或动作的硬件(例如电路或ASIC(Application SpecificIntegrated Circuit，专用集成电路))来实现，或者可以用硬件和软件的组合，如固件等来实现。

尽管在此结合各实施例对本发明进行了描述，然而，在实施所要求保护的本发明过程中，本领域技术人员通过查看所述附图、公开内容、以及所附权利要求书，可理解并实现所述公开实施例的其它变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其它单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。