CN116260874A - 一种服务调用方法及装置 - Google Patents

Abstract

本申请公开了一种服务调用方法及装置，由服务调用方服务器执行，该方法包括：从服务注册中心中读取服务元数据，服务元数据中包含若干个服务提供方的信息；将服务元数据存储到内存和本地磁盘文件中；根据服务注册中心、内存及本地磁盘文件中的服务元数据，确定待使用的服务元数据；根据待使用的服务元数据生成服务调用请求以进行服务调用。本申请解决了在服务注册中心发生故障以及故障后服务调用方重启应用导致无法获取到服务提供方的信息的问题，通过将服务提供方的信息进行本地持久化存储，使得服务提供方在服务注册中心故障等情况下仍能获取到服务提供方的信息，进而实现服务调用，提高了服务调用的效率，保障了系统的高可用性。

Description

一种服务调用方法及装置

技术领域

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

背景技术

随着业务的不断扩展，单体架构使得系统慢慢变得庞大臃肿，难以维护，微服务架构为解决此问题应运而生。为实现微服务架构，现有技术中提出了不同的技术框架，如Zookeeper，Dubbo和Springcloud等，这些框架普遍使用服务注册与发现中心，来实现服务的注册与发现，以达到服务提供方和服务调用方解耦的目的。

Zookeeper是目前较为成熟的注册中心实现方案之一，根据CAP(Consistency-Availability-Partition tolerance，一致性-可用性-分区容错性)理论，Zookeeper是一致性和分区容错性的一种实现，因此对于Zookeeper来说，其存在着高可用问题，即当Zookeeper出现一致性问题或处于故障期间时，Zookeeper将处于一种不可用状态。

当Zookeeper处于不可用状态时，服务调用方将无法获取到服务提供方的信息，进而导致无法正确的进行服务调用。然而现有的服务调用方法很难有效解决这种情况，导致Zookeeper的高可用性级别不高。

发明内容

本申请实施例提供了一种服务调用方法及装置，以提高服务调用效率。

本申请实施例采用下述技术方案：

第一方面，本申请实施例提供一种服务调用方法，由服务调用方服务器执行，其中，所述方法包括：

从服务注册中心中读取服务元数据，其中，所述服务元数据中包含若干个服务提供方的信息；

将所述服务元数据存储到内存和本地磁盘文件中；

根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据；

根据所述待使用的服务元数据生成服务调用请求以进行服务调用。

可选地，所述根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据包括：

确定待调用的目标服务；

确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据；

若从所述服务注册中心和所述内存中均不能读取到所述目标服务对应的服务元数据，则从所述本地磁盘文件中读取所述目标服务对应的服务元数据，作为所述待使用的服务元数据。

可选地，所述确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据包括：

确定是否能够从所述服务注册中心中读取到所述服务元数据；

若能，则将所述服务注册中心中的服务元数据读取到所述内存中，以根据所述内存中的服务元数据生成服务调用请求。

可选地，所述确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据包括：

若不能从所述服务注册中心中读取到所述服务元数据，则确定是否能够从所述内存中读取到所述服务元数据；

若能，则直接根据所述内存中的服务元数据生成服务调用请求。

可选地，所述若从所述服务注册中心和所述内存中均不能读取到所述目标服务对应的服务元数据，则从所述本地磁盘文件中读取所述目标服务对应的服务元数据包括：

将所述本地磁盘文件中的服务元数据读取到所述内存中，以根据所述内存中的服务元数据生成服务调用请求。

可选地，所述服务元数据包括服务提供方列表，所述根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据包括：

在所述服务提供方列表中确定出目标服务提供方；

检查所述目标服务提供方的服务状态；

若所述目标服务提供方的服务状态为可用状态，则确定将所述服务调用请求发送至所述目标服务提供方；

若所述目标服务提供方的服务状态为不可用状态，则在所述服务提供方列表中重新确定目标服务提供方。

可选地，所述服务元数据中包括服务提供方的服务状态标识和服务权重，所述方法还包括：

若所述目标服务提供方的服务状态为不可用状态，则将所述目标服务提供方的服务状态标识更新为不可用状态，和/或，调整所述目标服务提供方的服务权重。

可选地，所述服务元数据中包括服务提供方的服务状态标识和服务权重，在确定将所述服务调用请求发送至所述目标服务提供方之后，所述方法还包括：

接收对所述目标服务提供方的服务调用结果；

若服务调用结果为调用失败，则执行重试机制；

若重试后调用失败的次数超过预设次数阈值，则将所述目标服务提供方的服务状态标识更新为不可用状态，和/或，调整所述目标服务提供方的服务权重。

可选地，在将所述服务元数据存储到内存和本地磁盘文件中之后，所述方法还包括：

检查所述内存中的服务元数据与所述本地磁盘文件中的服务元数据是否一致；

若不一致，则根据所述内存中的服务元数据，更新所述本地磁盘文件中的服务元数据。

第二方面，本申请实施例还提供一种服务调用装置，应用于服务调用方服务器，其中，所述装置用于实现前述之任一所述方法。

第三方面，本申请实施例还提供一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行前述之任一所述方法。

第四方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行前述之任一所述方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：本申请实施例的服务调用方法可以由服务调用方服务器执行，在服务发现环节，先从服务注册中心中读取服务元数据，服务元数据中包含若干个服务提供方的信息，然后将读取到的服务元数据存储到内存和本地磁盘文件中。在进行服务调用时，根据服务注册中心、所述内存以及本地磁盘文件中的服务元数据，确定待使用的服务元数据；最后根据待使用的服务元数据生成服务调用请求以进行服务调用。本申请实施例的服务调用方法解决了在服务注册中心发生故障以及故障后服务调用方重启应用导致无法获取到服务提供方的信息的问题，通过将服务提供方的信息进行本地持久化存储，使得服务提供方在服务注册中心故障等情况下仍能获取到服务提供方的信息，进而实现服务调用，提高了服务调用的效率，保障了系统的高可用性。

附图说明

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

图1为现有技术中一种服务注册中心、服务调用方及服务提供方三者之间的关系示意图；

图2为一种服务调用方法的流程示意图；

图3为本申请实施例一种服务调用方法的流程示意图；

图4为本申请实施例一种服务调用流程示意图；

图5为本申请实施例一种服务调用装置的结构示意图；

图6为本申请实施例中一种电子设备的结构示意图。

具体实施方式

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

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

为了便于对本申请各实施例的理解，如图1所示，提供了现有技术中一种服务注册中心、服务调用方及服务提供方三者之间的关系示意图。在服务注册环节，服务提供方作为服务的提供者将自身的服务信息注册到服务注册中心中，这里的服务信息具体可以包括提供的服务隶属于哪个系统、服务的IP地址、端口和服务请求的URL等信息。服务注册中心主要提供所有服务注册信息的中心存储，同时负责将服务注册信息的更新通知实时的推送给服务调用方，以Zookeeper为例，该功能主要是通过Zookeeper的监听机制来实现。在服务发现环节，服务调用方在启动时会从服务注册中心获取需要的服务注册信息，并根据此服务注册信息构建服务调用请求并转发，进而实现对服务提供方的服务调用。

当服务注册中心发生故障时，服务调用方将无法获取到服务提供方的信息，导致无法正确的进行服务调用。针对此问题，如图2所示，提供了一种服务调用方法的流程示意图，在服务发现环节，服务调用方在从服务注册中心拉取到服务提供方的信息后，会将服务提供方的信息做内存级别的缓存，当出现Zookeeper不可用等异常情况时，服务调用方通过读取内存中缓存的服务提供方的信息来实现服务调用。

然而，该解决方案由于仅仅是在内存中缓存服务提供方的信息，在Zookeeper不可用时，服务调用方不可以重启应用，否则内存中缓存的数据将会因为重启而丢失。但实际业务场景中，在Zookeeper故障的情况下很难保证应用不被重启，例如以下两个场景：

1)由于服务为不同模块独立部署，Zookeeper故障时，服务调用方并不知晓，需要依赖Zookeeper的维护人员通知，而如果通知机制缺失或延迟，服务调用方很有可能会在不知道Zookeeper不可用的情况下重启应用；

2)服务调用方得知Zookeeper故障且无法短时间内恢复，但是却有紧急重启应用的需求，如系统出现重大故障，需要紧急上线修复或回滚到历史版本等情况。

一旦在Zookeeper故障的情况下重启应用，Zookeeper和内存中均无法提供服务提供方的信息，进而导致服务提供方因无法完成服务调用而出现系统不可用的问题。

基于此，本申请实施例提供了一种服务调用方法，由服务调用方服务器执行，如图3所示，提供了本申请实施例一种服务调用方法的流程示意图，所述方法至少包括如下的步骤S310至步骤S340：

步骤S310，从服务注册中心中读取服务元数据，其中，所述服务元数据中包含若干个服务提供方的信息。

本申请实施例的服务调用方法可以由服务调用方所在的服务器来实现，在服务调用方启动时，可以先从服务注册中心中读取服务元数据，这里的元数据可以理解为是标识不同的服务提供方基本信息的数据，例如可以包括服务提供方提供的服务隶属于哪个系统、服务的IP地址、端口和服务请求的URL等信息。

步骤S320，将所述服务元数据存储到内存和本地磁盘文件中。

在读取到服务元数据后，除了将从服务注册中心读取到的服务元数据缓存到内存中以外，还需要进一步将其缓存到本地磁盘文件中，具体可以将服务元数据写入到系统文件的特定目录下，进行持久化存储，此过程可以保障即使服务调用方在服务注册中心故障的情况下重启应用，缓存在本地磁盘文件中的服务元数据也不会丢失。

步骤S330，根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据。

在将服务元数据存储到内存和本地磁盘文件中后，这样在服务注册中心、内存和本地磁盘文件中均保存了服务元数据，为后续的服务调用过程提供了更加稳定、可靠的数据来源。

在服务调用方需要进行服务调用时，可以根据服务注册中心、内存和本地磁盘文件中的服务元数据的存储情况，获取待使用的服务元数据。

步骤S340，根据所述待使用的服务元数据生成服务调用请求以进行服务调用。

在确定出待使用的服务元数据后，可以根据待使用的服务元数据生成服务调用请求，从而将服务调用请求发送给相应的服务提供方，以实现对服务提供方的服务调用。

本申请实施例的服务调用方法解决了在服务注册中心发生故障以及故障后服务调用方重启应用导致无法获取到服务提供方的信息的问题，通过将服务提供方的信息进行本地持久化存储，使得服务提供方在服务注册中心故障等情况下仍能获取到服务提供方的信息，进而实现服务调用，提高了服务调用的效率，保障了系统的高可用性。

在本申请的一个实施例中，所述根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据包括：确定待调用的目标服务；确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据；若从所述服务注册中心和所述内存中均不能读取到所述目标服务对应的服务元数据，则从所述本地磁盘文件中读取所述目标服务对应的服务元数据，作为所述待使用的服务元数据。

实际业务场景下，注册在服务注册中心中的服务是很多的，因此服务调用方在进行服务调用时，可以先确定要调用的目标服务。在服务注册中心正常运行且服务调用方未重启应用的情况下，可以先从服务注册中心或者内存中直接读取目标服务对应的服务元数据，如果服务注册中心和内存中均读取失败，说明可能是服务注册中心出现了故障，或者服务调用方重启了应用导致内存中缓存的服务元数据丢失了，这时就可以从本地磁盘文件中读取目标服务对应的服务元数据，进而保证后续对目标服务的正常调用。

在本申请的一个实施例中，所述确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据包括：确定是否能够从所述服务注册中心中读取到所述服务元数据；若能，则将所述服务注册中心中的服务元数据读取到所述内存中，以根据所述内存中的服务元数据生成服务调用请求。

如前所述，服务注册中心负责提供所有服务注册信息的中心存储，同时负责实时监听服务提供方的服务注册信息的变更，因此相比于服务调用方来说，服务注册中心能够更快地感知到服务元数据的变化，并进行同步更新，也即服务注册中心中记录的服务元数据往往是最新的。

基于此，为了保证后续服务调用的正确性和服务调用成功的概率，可以先从服务注册中心中拉取最新的服务元数据，如果服务注册中心还在正常运行，则可以从服务注册中心中成功拉取到服务元数据，为了后续服务调用过程的实现，具体可以将服务元数据拉取到服务调用方的内存中，进而可以根据内存中的服务元数据生成服务调用请求。

在本申请的一个实施例中，所述确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据包括：若不能从所述服务注册中心中读取到所述服务元数据，则确定是否能够从所述内存中读取到所述服务元数据；若能，则直接根据所述内存中的服务元数据生成服务调用请求。

如果不能从服务注册中心中读取到服务元数据，说明此时服务注册中心可能发生了故障，这时可以直接从内存中读取服务元数据，如果能够读取成功，说明服务调用方在服务注册中心故障期间没有重启应用，因此可以直接根据内存中缓存的服务元数据生成服务调用请求。

在本申请的一个实施例中，所述若从所述服务注册中心和所述内存中均不能读取到所述目标服务对应的服务元数据，则从所述本地磁盘文件中读取所述目标服务对应的服务元数据包括：将所述本地磁盘文件中的服务元数据读取到所述内存中，以根据所述内存中的服务元数据生成服务调用请求。

无论是从服务注册中心拉取服务元数据还是从本地磁盘文件中拉取服务元数据，最终都要将服务元数据拉取到内存中以构建服务调用请求。因此本申请实施例在无法从服务注册中心以及内存中读取到服务元数据的情况下，可以从本地磁盘文件中读取服务元数据，并将其读取到内存中，进而可以根据内存中的服务元数据生成服务调用请求。

针对上述实施例需要说明的是，正常情况下，服务注册中心、服务调用方的内存和本地磁盘文件中都存储有服务提供方的信息，但相比于服务调用方的内存和本地磁盘文件中存储的服务提供方的信息，服务注册中心中记录的服务提供方的信息往往是最新的，因此为了保证后续服务调用的正确性和服务调用成功的概率，可以考虑优先从服务注册中心获取服务提供方的信息。

而在服务注册中心出现故障无法获取服务提供方的信息的情况下，可以从内存缓存或者本地磁盘文件中获取服务提供方的信息，但由于从本地磁盘文件中获取的信息最终也要拉取到内存中生成服务调用请求，因此从服务调用的效率的角度考虑，可以优先从内存中获取服务提供方的信息。

如果服务注册中心和服务调用方的内存中均无法获取到服务提供方的信息，则可以从服务调用方的本地磁盘文件中获取服务提供方的信息，以保证系统的高可用性。

上述实施例对于服务提供方的信息获取流程既保证了后续服务调用的正确性和服务调用成功的概率，也保证了服务调用的效率和系统的高可用性。

在本申请的一个实施例中，所述服务元数据包括服务提供方列表，所述根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据包括：在所述服务提供方列表中确定出目标服务提供方；检查所述目标服务提供方的服务状态；根据所述目标服务提供方的服务状态，确定是否将所述服务调用请求发送至所述目标服务提供方。

本申请实施例中的服务元数据可以以服务提供方列表的形式提供给服务调用方，针对同一个服务，列表中可能有多个服务提供方同时能够提供该服务，例如服务提供方A、服务提供方B和服务提供方C，因此可以先从服务提供方列表中确定出由哪一个服务提供方提供服务，即确定目标服务提供方。当然，具体如何确定目标服务提供方，本领域技术人员可根据实际需求灵活设置，例如可以采用负载均衡策略或者轮询策略来确定，在此不作具体限定。

为了提高服务调用成功的概率，在确定出目标服务提供方后，可以先检查目标服务提供方的服务状态，例如可以先向目标服务提供方发送通信连接请求，根据目标服务提供方对通信连接请求的响应结果来确定目标服务提供方的服务状态是否正常，进而确定是否将服务调用请求发送至该目标服务提供方。

在本申请的一个实施例中，所述根据所述目标服务提供方的服务状态，确定是否将所述服务调用请求发送至所述目标服务提供方包括：若所述目标服务提供方的服务状态为可用状态，则确定将所述服务调用请求发送至所述目标服务提供方；若所述目标服务提供方的服务状态为不可用状态，则在所述服务提供方列表中重新确定目标服务提供方。

如果检查出目标服务提供方的服务状态为可用状态，例如目标服务提供方对通信连接请求的响应结果为连接成功，则说明该目标服务提供方当前能够正常提供服务，因此可以将服务调用请求发送至该目标服务提供方。如果检查出目标服务提供方的服务状态为不可用状态，例如目标服务提供方对通信连接请求的响应结果为连接失败，则说明该目标服务提供方可能发生了故障，如果继续向该目标服务提供方发送服务调用请求，也不会调用成功，因此本申请实施例在检查到目标服务提供方的服务状态为不可用状态的情况时，可以从服务提供方列表中重新确定出目标服务提供方，以提高后续服务调用成功的概率。

在本申请的一个实施例中，所述服务元数据中包括服务提供方的服务状态标识和服务权重，所述方法还包括：若所述目标服务提供方的服务状态为不可用状态，则将所述目标服务提供方的服务状态标识更新为不可用状态，和/或，调整所述目标服务提供方的服务权重。

本申请实施例的服务元数据中还可以包括服务提供方的服务状态标识和服务权重等信息，服务状态标识用于表征服务提供方当前是否能够提供服务，即是否可用，服务权重用于表征服务提供方被调用的可能性，权重越高，则被调用的可能性越大。

当检查发现目标服务提供方的服务状态为不可用状态时，说明目标服务提供方可能出现了故障，无法正常提供服务，为了避免后续再次调用到该目标服务提供方或者降低后续再次调用到该目标服务提供方的概率，可以采用两种方式来实现，一种是将目标服务提供方的服务状态标识修改为不可用状态，或者也可以降低目标服务提供方的服务权重，这样后续在通过负载均衡、轮询或者其他策略确定目标服务提供方时，就可以尽可能避免再次调用到可能已经发生故障的服务提供方，进而提高服务调用成功的概率。

在本申请的一个实施例中，所述服务元数据中包括服务提供方的服务状态标识和服务权重，在确定将所述服务调用请求发送至所述目标服务提供方之后，所述方法还包括：接收对所述目标服务提供方的服务调用结果；若服务调用结果为调用失败，则执行重试机制；若重试后调用失败的次数超过预设次数阈值，则将所述目标服务提供方的服务状态标识更新为不可用状态，和/或，调整所述目标服务提供方的服务权重。

除了上述实施例在发送服务调用请求之前检查目标服务提供方的服务状态外，也可以在向目标服务提供方发送服务调用请求之后再确定目标服务提供方的服务状态。

具体地，可以先接收目标服务提供方返回的服务调用结果，如果服务调用结果为调用成功，说明目标服务提供方的服务状态正常。如果服务调用结果为调用失败，则说明可能是由于目标服务提供方自身的故障导致调用失败，也可能是由于网络异常等原因导致调用失败，这时可以采用重试机制重新发送几次服务调用请求，如果重新发送的几次服务调用请求仍然调用失败，则可以确定是目标服务提供方出现了故障，这时可以直接将目标服务提供方的服务状态标识修改为不可用标识，或者也可以降低目标服务提供方的服务权重，以尽可能避免后续再次调用到该目标服务提供方。

需要说明的是，上述重试机制的重试次数，本领域技术人员可根据实际需求灵活设置，在此不作具体限定。

为了尽可能避免再次调用到服务状态为不可用的服务提供方，除了可以采用上述实施例中的修改服务状态标识或者降低服务权重的方式，也可以直接将服务提供方的信息从服务提供方列表中删除。

在本申请的一个实施例中，在将所述服务元数据存储到内存和本地磁盘文件中之后，所述方法还包括：检查所述内存中的服务元数据与所述本地磁盘文件中的服务元数据是否一致；若不一致，则根据所述内存中的服务元数据，更新所述本地磁盘文件中的服务元数据。

正常情况下，服务调用方会将从服务注册中心拉取到的最新的服务元数据同时存储到内存和本地磁盘文件中。存储到内存中的操作基本上都会存储成功，因此只要服务注册中心没有故障且服务调用方没有重启应用，内存中就会保留有最新的服务元数据，而在将数据写入本地磁盘文件中时，可能会由于服务调用方出现了硬盘等硬件层面的故障而出现写入失败等情况，这时本地磁盘文件中存储的服务元数据将不再是最新的元数据。

考虑到上述情况，本申请实施例在将服务元数据存储到内存和本地磁盘文件中后，可以定时或者不定时地检查内存中的服务元数据与本地磁盘文件中的服务元数据是否一致，如果不一致，则说明可能出现了上述写入失败的情况，此时可以以内存中存储的服务元数据为基准来更新本地磁盘文件中存储的服务元数据，以确保后续服务调用的正确性。

如图4所示，提供了本申请实施例一种服务调用流程示意图。在服务注册环节，服务提供方会将自身的服务信息注册到服务注册中心中，在服务发现环节，服务调用方会从服务注册中心拉取服务提供方的信息，并将服务提供方的信息同时缓存到内存和本地磁盘文件中。

在服务调用环节，服务调用方可以先确定待调用的目标服务，然后从服务注册中心中拉取目标服务对应的服务调用方的信息，如果拉取成功，则直接以此生成服务调用请求，并发送给服务提供方进行服务调用，如果拉取失败，则从服务调用方的内存中拉取目标服务对应的服务调用方的信息，如果拉取成功，则直接以此生成服务调用请求，并发送给服务提供方进行服务调用，如果拉取失败，则从本地磁盘文件中拉取目标服务对应的服务调用方的信息，如果拉取成功，则直接以此生成服务调用请求，并发送给服务提供方进行服务调用，如果拉取失败，则此次服务调用失败。

本申请实施例还提供了一种服务调用装置500，应用于服务调用方服务器，如图5所示，提供了本申请实施例一种服务调用装置的结构示意图，所述装置500包括：读取单元510、存储单元520、生成单元530和发送单元540，其中：

读取单元510，用于从服务注册中心中读取服务元数据，其中，所述服务元数据中包含若干个服务提供方的信息；

存储单元520，用于将所述服务元数据存储到内存和本地磁盘文件中；

生成单元530，用于根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据；

发送单元540，用于根据所述待使用的服务元数据生成服务调用请求以进行服务调用。

在本申请的一个实施例中，所述生成单元530具体用于：确定待调用的目标服务；确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据；若从所述服务注册中心和所述内存中均不能读取到所述目标服务对应的服务元数据，则从所述本地磁盘文件中读取所述目标服务对应的服务元数据，作为所述待使用的服务元数据。

在本申请的一个实施例中，所述生成单元530具体用于：确定是否能够从所述服务注册中心中读取到所述服务元数据；若能，则将所述服务注册中心中的服务元数据读取到所述内存中，以根据所述内存中的服务元数据生成服务调用请求。

在本申请的一个实施例中，所述生成单元530具体用于：若不能从所述服务注册中心中读取到所述服务元数据，则确定是否能够从所述内存中读取到所述服务元数据；若能，则直接根据所述内存中的服务元数据生成服务调用请求。

在本申请的一个实施例中，所述生成单元530具体用于：将所述本地磁盘文件中的服务元数据读取到所述内存中，以根据所述内存中的服务元数据生成服务调用请求。

在本申请的一个实施例中，所述服务元数据包括服务提供方列表，所述生成单元530具体用于：在所述服务提供方列表中确定出目标服务提供方；检查所述目标服务提供方的服务状态；若所述目标服务提供方的服务状态为可用状态，则确定将所述服务调用请求发送至所述目标服务提供方；若所述目标服务提供方的服务状态为不可用状态，则在所述服务提供方列表中重新确定目标服务提供方。

在本申请的一个实施例中，所述服务元数据中包括服务提供方的服务状态标识和服务权重，所述装置还包括：第一更新单元，用于若所述目标服务提供方的服务状态为不可用状态，则将所述目标服务提供方的服务状态标识更新为不可用状态，和/或，第一调整单元，用于调整所述目标服务提供方的服务权重。

在本申请的一个实施例中，所述服务元数据中包括服务提供方的服务状态标识和服务权重，所述装置还包括：接收单元，用于接收对所述目标服务提供方的服务调用结果；重试单元，用于若服务调用结果为调用失败，则执行重试机制；第一更新单元，用于若重试后调用失败的次数超过预设次数阈值，则将所述目标服务提供方的服务状态标识更新为不可用状态，和/或，第二调整单元，用于调整所述目标服务提供方的服务权重。

在本申请的一个实施例中，所述装置还包括：检查单元，用于检查所述内存中的服务元数据与所述本地磁盘文件中的服务元数据是否一致；第三更新单元，用于若不一致，则根据所述内存中的服务元数据，更新所述本地磁盘文件中的服务元数据。

能够理解，上述服务调用装置，能够实现前述实施例中提供的由服务调用方服务器执行的服务调用方法的各个步骤，关于服务调用方法的相关阐释均适用于服务调用装置，此处不再赘述。

图6是本申请的一个实施例电子设备的结构示意图。请参考图6，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成服务调用装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

从服务注册中心中读取服务元数据，其中，所述服务元数据中包含若干个服务提供方的信息；

将所述服务元数据存储到内存和本地磁盘文件中；

根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据；

根据所述待使用的服务元数据生成服务调用请求以进行服务调用。

上述如本申请图5所示实施例揭示的服务调用装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图5中服务调用装置执行的方法，并实现服务调用装置在图5所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图5所示实施例中服务调用装置执行的方法，并具体用于执行：

从服务注册中心中读取服务元数据，其中，所述服务元数据中包含若干个服务提供方的信息；

将所述服务元数据存储到内存和本地磁盘文件中；

根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据；

根据所述待使用的服务元数据生成服务调用请求以进行服务调用。

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

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

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

Claims (10)

1.一种服务调用方法，由服务调用方服务器执行，其中，所述方法包括：

从服务注册中心中读取服务元数据，其中，所述服务元数据中包含若干个服务提供方的信息；

将所述服务元数据存储到内存和本地磁盘文件中；

根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据；

根据所述待使用的服务元数据生成服务调用请求以进行服务调用。

2.如权利要求1所述方法，其中，所述根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据包括：

确定待调用的目标服务；

确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据；

若从所述服务注册中心和所述内存中均不能读取到所述目标服务对应的服务元数据，则从所述本地磁盘文件中读取所述目标服务对应的服务元数据，作为所述待使用的服务元数据。

3.如权利要求2所述方法，其中，所述确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据包括：

确定是否能够从所述服务注册中心中读取到所述服务元数据；

若能，则将所述服务注册中心中的服务元数据读取到所述内存中，以根据所述内存中的服务元数据生成服务调用请求。

4.如权利要求3所述方法，其中，所述确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据包括：

若不能从所述服务注册中心中读取到所述服务元数据，则确定是否能够从所述内存中读取到所述服务元数据；

若能，则直接根据所述内存中的服务元数据生成服务调用请求。

5.如权利要求2所述方法，其中，所述若从所述服务注册中心和所述内存中均不能读取到所述目标服务对应的服务元数据，则从所述本地磁盘文件中读取所述目标服务对应的服务元数据包括：

将所述本地磁盘文件中的服务元数据读取到所述内存中，以根据所述内存中的服务元数据生成服务调用请求。

6.如权利要求1所述方法，其中，所述服务元数据包括服务提供方列表，所述根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据，确定待使用的服务元数据包括：

在所述服务提供方列表中确定出目标服务提供方；

检查所述目标服务提供方的服务状态；

若所述目标服务提供方的服务状态为可用状态，则确定将所述服务调用请求发送至所述目标服务提供方；

若所述目标服务提供方的服务状态为不可用状态，则在所述服务提供方列表中重新确定目标服务提供方。

7.如权利要求6所述方法，其中，所述服务元数据中包括服务提供方的服务状态标识和服务权重，所述方法还包括：

若所述目标服务提供方的服务状态为不可用状态，则将所述目标服务提供方的服务状态标识更新为不可用状态，和/或，调整所述目标服务提供方的服务权重。

8.如权利要求6所述方法，其中，所述服务元数据中包括服务提供方的服务状态标识和服务权重，在确定将所述服务调用请求发送至所述目标服务提供方之后，所述方法还包括：

接收对所述目标服务提供方的服务调用结果；

若服务调用结果为调用失败，则执行重试机制；

若重试后调用失败的次数超过预设次数阈值，则将所述目标服务提供方的服务状态标识更新为不可用状态，和/或，调整所述目标服务提供方的服务权重。

9.如权利要求1所述方法，其中，在将所述服务元数据存储到内存和本地磁盘文件中之后，所述方法还包括：

检查所述内存中的服务元数据与所述本地磁盘文件中的服务元数据是否一致；

若不一致，则根据所述内存中的服务元数据，更新所述本地磁盘文件中的服务元数据。

10.一种服务调用装置，应用于服务调用方服务器，其中，所述装置用于实现权利要求1～9之任一所述方法。

Images