本申请涉及微服务,尤其涉及一种服务调用方法及装置。
背景技术:
1、随着业务的不断扩展,单体架构使得系统慢慢变得庞大臃肿,难以维护,微服务架构为解决此问题应运而生。为实现微服务架构,现有技术中提出了不同的技术框架,如zookeeper,dubbo和springcloud等,这些框架普遍使用服务注册与发现中心,来实现服务的注册与发现,以达到服务提供方和服务调用方解耦的目的。
2、zookeeper是目前较为成熟的注册中心实现方案之一,根据cap(consistency-availability-partition tolerance,一致性-可用性-分区容错性)理论,zookeeper是一致性和分区容错性的一种实现,因此对于zookeeper来说,其存在着高可用问题,即当zookeeper出现一致性问题或处于故障期间时,zookeeper将处于一种不可用状态。
3、当zookeeper处于不可用状态时,服务调用方将无法获取到服务提供方的信息,进而导致无法正确的进行服务调用。然而现有的服务调用方法很难有效解决这种情况,导致zookeeper的高可用性级别不高。
技术实现思路
1、本申请实施例提供了一种服务调用方法及装置,以提高服务调用效率。
2、本申请实施例采用下述技术方案:
3、第一方面,本申请实施例提供一种服务调用方法,由服务调用方服务器执行,其中,所述方法包括:
4、从服务注册中心中读取服务元数据,其中,所述服务元数据中包含若干个服务提供方的信息;
5、将所述服务元数据存储到内存和本地磁盘文件中;
6、根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据,确定待使用的服务元数据;
7、根据所述待使用的服务元数据生成服务调用请求以进行服务调用。
8、可选地,所述根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据,确定待使用的服务元数据包括:
9、确定待调用的目标服务;
10、确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据;
11、若从所述服务注册中心和所述内存中均不能读取到所述目标服务对应的服务元数据,则从所述本地磁盘文件中读取所述目标服务对应的服务元数据,作为所述待使用的服务元数据。
12、可选地,所述确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据包括:
13、确定是否能够从所述服务注册中心中读取到所述服务元数据;
14、若能,则将所述服务注册中心中的服务元数据读取到所述内存中,以根据所述内存中的服务元数据生成服务调用请求。
15、可选地,所述确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据包括:
16、若不能从所述服务注册中心中读取到所述服务元数据,则确定是否能够从所述内存中读取到所述服务元数据;
17、若能,则直接根据所述内存中的服务元数据生成服务调用请求。
18、可选地,所述若从所述服务注册中心和所述内存中均不能读取到所述目标服务对应的服务元数据,则从所述本地磁盘文件中读取所述目标服务对应的服务元数据包括:
19、将所述本地磁盘文件中的服务元数据读取到所述内存中,以根据所述内存中的服务元数据生成服务调用请求。
20、可选地,所述服务元数据包括服务提供方列表,所述根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据,确定待使用的服务元数据包括:
21、在所述服务提供方列表中确定出目标服务提供方;
22、检查所述目标服务提供方的服务状态;
23、若所述目标服务提供方的服务状态为可用状态,则确定将所述服务调用请求发送至所述目标服务提供方;
24、若所述目标服务提供方的服务状态为不可用状态,则在所述服务提供方列表中重新确定目标服务提供方。
25、可选地,所述服务元数据中包括服务提供方的服务状态标识和服务权重,所述方法还包括:
26、若所述目标服务提供方的服务状态为不可用状态,则将所述目标服务提供方的服务状态标识更新为不可用状态,和/或,调整所述目标服务提供方的服务权重。
27、可选地,所述服务元数据中包括服务提供方的服务状态标识和服务权重,在确定将所述服务调用请求发送至所述目标服务提供方之后,所述方法还包括:
28、接收对所述目标服务提供方的服务调用结果;
29、若服务调用结果为调用失败,则执行重试机制;
30、若重试后调用失败的次数超过预设次数阈值,则将所述目标服务提供方的服务状态标识更新为不可用状态,和/或,调整所述目标服务提供方的服务权重。
31、可选地,在将所述服务元数据存储到内存和本地磁盘文件中之后,所述方法还包括:
32、检查所述内存中的服务元数据与所述本地磁盘文件中的服务元数据是否一致;
33、若不一致,则根据所述内存中的服务元数据,更新所述本地磁盘文件中的服务元数据。
34、第二方面,本申请实施例还提供一种服务调用装置,应用于服务调用方服务器,其中,所述装置用于实现前述之任一所述方法。
35、第三方面,本申请实施例还提供一种电子设备,包括:
36、处理器;以及
37、被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器执行前述之任一所述方法。
38、第四方面,本申请实施例还提供一种计算机可读存储介质,所述计算机可读存储介质存储一个或多个程序,所述一个或多个程序当被包括多个应用程序的电子设备执行时,使得所述电子设备执行前述之任一所述方法。
39、本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:本申请实施例的服务调用方法可以由服务调用方服务器执行,在服务发现环节,先从服务注册中心中读取服务元数据,服务元数据中包含若干个服务提供方的信息,然后将读取到的服务元数据存储到内存和本地磁盘文件中。在进行服务调用时,根据服务注册中心、所述内存以及本地磁盘文件中的服务元数据,确定待使用的服务元数据;最后根据待使用的服务元数据生成服务调用请求以进行服务调用。本申请实施例的服务调用方法解决了在服务注册中心发生故障以及故障后服务调用方重启应用导致无法获取到服务提供方的信息的问题,通过将服务提供方的信息进行本地持久化存储,使得服务提供方在服务注册中心故障等情况下仍能获取到服务提供方的信息,进而实现服务调用,提高了服务调用的效率,保障了系统的高可用性。
1.一种服务调用方法,由服务调用方服务器执行,其中,所述方法包括:
2.如权利要求1所述方法,其中,所述根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据,确定待使用的服务元数据包括:
3.如权利要求2所述方法,其中,所述确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据包括:
4.如权利要求3所述方法,其中,所述确定是否能够从所述服务注册中心或所述内存中读取到所述目标服务对应的服务元数据包括:
5.如权利要求2所述方法,其中,所述若从所述服务注册中心和所述内存中均不能读取到所述目标服务对应的服务元数据,则从所述本地磁盘文件中读取所述目标服务对应的服务元数据包括:
6.如权利要求1所述方法,其中,所述服务元数据包括服务提供方列表,所述根据所述服务注册中心、所述内存以及所述本地磁盘文件中的服务元数据,确定待使用的服务元数据包括:
7.如权利要求6所述方法,其中,所述服务元数据中包括服务提供方的服务状态标识和服务权重,所述方法还包括:
8.如权利要求6所述方法,其中,所述服务元数据中包括服务提供方的服务状态标识和服务权重,在确定将所述服务调用请求发送至所述目标服务提供方之后,所述方法还包括:
9.如权利要求1所述方法,其中,在将所述服务元数据存储到内存和本地磁盘文件中之后,所述方法还包括:
10.一种服务调用装置,应用于服务调用方服务器,其中,所述装置用于实现权利要求1~9之任一所述方法。