服务调用方法和装置、电子设备和计算机可读存储介质与流程

1.本公开涉及大数据技术领域，更具体地，涉及一种服务调用方法及装置、电子设备、计算机可读存储介质和计算机程序产品。


背景技术：

2.基于分布式框架下，生产者通过api服务集群向注册中心发起服务注册，消费方通过从注册中心订阅服务，实现服务调用。
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示意性示出了可以应用本公开的服务调用方法及装置的示例性系统架构；
40.图2示意性示出了应用相关技术中的服务调用方法的系统架构；
41.图3示意性示出了根据本公开实施例的服务调用方法的流程图；
42.图4示意性示出了根据本公开实施例的加载每个当前服务节点各自对外提供的预订业务服务种类配置信息的流程图；
43.图5示意性示出了根据本公开实施例的服务调用装置的框图；以及
44.图6示意性示出了根据本公开实施例的用于实现服务调用方法的电子设备的框图。
具体实施方式
45.以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性
的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。
46.在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
47.在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
48.在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。在使用类似于“a、b或c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b或c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。
49.在对本公开的实施例进行详细阐述之前，先对本公开实施例提供的方法所涉及的系统结构以及应用场景进行如下介绍。
50.图1示意性示出了可以应用本公开的服务调用方法及装置的示例性系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。
51.如图1所示，根据该实施例的系统架构100可以包括服务提供方101、注册中心102、和服务消费方103。服务提供方101、注册中心102、和服务消费方103彼此之间可通过网络进行通信，网络可以包括各种连接类型，例如有线和/或无线通信链路等等。
52.注册中心102可用于记录服务和服务地址的映射关系。在分布式架构中，服务提供方101的服务会注册到注册中心102，当服务消费方103需要调用服务时，会通过注册中心102获取到服务的信息，进行调用。
53.注册中心102可以是基于zookeeper搭建的系统，zookeeper提供统一命名服务、配置管理、分布式锁等基础服务，基于这些基础服务，可以实现集群管理、软负载、发布/订阅、命名服务等功能。
54.服务提供方101和服务消费方103通过注册中心102提供的客户端与过注册中心102建立连接(如zookeeper的长连接)，服务提供方101将发布的服务地址信息和相关访问信息写到注册中心，服务消费方103根据调用的服务名称等信息从注册中心102获取调用列表并在本地缓存。
55.在本公开实施例的应用场景下，服务提供方101通过业务服务集群对外提供全量预订服务，其中，服务提供方101的业务服务集群可包括多个业务子集群，其中不同业务子集群各自对外提供的预订业务服务种类不同，同一业务子集群中各服务节点各自对外提供
的预订业务服务种类相同，且业务子集群各自对外提供的预订业务服务种类汇总后为业务服务集群对外提供的全量预订服务的种类。
56.服务提供方101需将其对外提供的服务(即每个当前服务节点各自对外提供的预订业务服务种类配置信息)注册在注册中心102，之后，当服务消费方103需要调用相关预订业务服务时，会从注册中心102获取调用列表并在本地缓存，并根据预订业务服务种类和服务消费方预先存储的服务注册信息，分别调用服务提供方的各个业务子集群的各个预订业务服务。
57.应该理解，图1中的子集群数量、服务器的数量仅仅是示意性的。根据实现需要，可以具有任意数目的子集群、服务器。
58.需要说明的是，本公开服务调用方法和装置可用于大数据技术领域，也可用于金融技术领域，也可用于除大数据技术领域和金融技术领域之外的任意领域，本公开对上述服务调用方法和装置的应用领域不做限定。
59.在本公开的技术方案中，所涉及的用户个人信息的获取，存储和应用等，均符合相关法律法规的规定，采取了必要保密措施，且不违背公序良俗。
60.相关技术中，服务提供方作为生产者，基于分布式框架，通过api服务集群向注册中心发起服务注册，注册中心保存已注册的各服务的存根、服务版本号、服务提供节点ip等信息，服务消费方通过从注册中心订阅服务，实现服务调用。消费方在服务器启动时，将订阅的服务列表、服务存根、服务提供者信息缓存在消费方内存，服务调用时候，从内存中获知服务提供者信息，并借助分布式框架，实现rpc调用。
61.在实现本公开的过程中发现，因分布式框架基础是注册中心会将服务提供方的信息在消费方向注册中心订阅时候，告知消费方，在消费方服务器内存中开辟空间存储服务相关信息。随着订阅服务量增加，造成了消费方内存占用过多的问题。
62.图2示意性示出了应用相关技术中的服务调用方法的系统架构。在图2所示的应用场景下，系统架构可以包括服务提供方201、注册中心202、和服务消费方203。服务提供方201和服务消费方203通过注册中心202提供的客户端与注册中心202建立连接(如zookeeper的长连接)，服务提供方201将发布的服务地址信息和相关访问信息写到注册中心，服务消费方203根据调用的服务名称等信息从注册中心202获取调用列表并在本地缓存。其中，服务提供方201通过业务服务集群对外提供全量预订服务，其中，服务提供方201的业务服务集群可包括多个业务子集群，其中不同业务子集群各自对外提供的预订业务服务种类相同，均向外提供全量预订服务。
63.以单位服务占用内存容量，即消费方订阅一个服务占用消费方内存为c计算，服务消费方占用的内存等于订阅的服务数*服务节点提供数*c，随着消费方业务量上涨，订阅服务量增加，或者服务提供方因业务激增扩容服务节点数量，都会造成消费方内存占用的潜在风险。当消费方因服务订阅的内存占用超过阈值时候，消费方本身其他业务流程在内存资源争用时候可能出现不足，从而引起jvm频繁的垃圾回收，进而影响消费方业务正常执行。
64.随着服务提供方提供的服务数越来越多，消费方订阅服务后占用的内存也越来越大。为避免业务量激增服务数增长给消费方带来的潜在内存增加导致的频繁垃圾回收，服务提供方需要通过缩减提供的服务数量或者降低服务提供节点数来规避风险。例如可按照
缩减服务数量的构思，将多个服务合并为一个服务多个方法对外暴露，此方法尽管可以降低消费方订阅服务的内存占用，但也要求各消费方同步配合改造，对消费方的影响较大。因此，较佳地，可以按降低服务提供节点数的构思，通过将原来服务提供节点即将整体的api服务集群从物理上拆分成多个业务群组的api服务集群，将原来api集群上的全量服务按照业务领域及高低频服务拆分为多个业务群组的服务，全量业务群组的服务组合即为原api服务集群的全量服务。
65.有鉴于此，本公开提供了一种服务调用方法，以解决上述技术问题。在本公开实施例的应用场景下，服务提供方通过业务服务集群对外提供全量预订服务，其中，服务提供方的业务服务集群可包括多个业务子集群，与相关技术中不同的是，其中不同业务子集群各自对外提供的预订业务服务种类不同，同一业务子集群中各服务节点各自对外提供的预订业务服务种类相同，且业务子集群各自对外提供的预订业务服务种类汇总后为业务服务集群对外提供的全量预订服务的种类。
66.图3示意性示出了根据本公开实施例的服务调用方法的流程图。
67.如图3所示，该方法包括操作s301～s303。
68.在操作s301，服务消费方从注册中心获取服务注册信息，其中，服务注册信息包括各个业务子集群中各服务节点各自对外提供的预订业务服务种类配置信息，各个业务子集群属于服务提供方的业务服务集群，其中不同业务子集群各自对外提供的预订业务服务种类不同，同一业务子集群中各服务节点各自对外提供的预订业务服务种类相同，且业务子集群各自对外提供的预订业务服务种类汇总后为业务服务集群对外提供的全量预订服务的种类。
69.根据本公开的实施例，服务注册信息可包括各服务节点各自对外提供的预订业务服务种类配置信息，还可包括各预订业务服务的服务存根配置、服务消费配置、服务监控配置、服务集群信息及服务归属应用信息等。
70.根据本公开的实施例，各服务节点各自对外提供的预订业务服务种类配置信息中，例如可包括各服务节点各自对外提供的预订业务服务的种类、以及各预订业务服务和提供相关预订业务服务的各服务节点地址的映射关系等。
71.在操作s302，将服务注册信息存储在服务消费方。
72.在操作s303，服务消费方根据预订业务服务种类和服务消费方预先存储的服务注册信息，分别调用服务提供方的各个业务子集群的各个预订业务服务。根据本公开的实施例，服务消费方在服务器启动时，将订阅的服务注册信息缓存在消费方内存，服务调用时候，从内存中获知服务提供方的服务注册信息，并依据这些服务注册信息，借助分布式框架，实现服务调用，例如可通过rpc(remote procedure call)调用远程过程调用的方式实现服务调用，也可通过其他通信方式(如http)实现调用。
73.根据本公开的实施例，服务消费方从注册中心获取服务注册信息后需将服务注册信息存储在服务消费方内存，服务注册信息的容量大小决定了服务消费方占用内存的大小。因服务注册信息的容量大小与服务提供方各服务节点对外提供的服务种类的数量有关，通过服务提供方的集群拆分，并设置不同业务子集群各自对外提供的预订业务服务种类不同，使得同一业务子集群中各服务节点对外提供的服务种类的数量得以降低，因此，可降低服务注册信息的容量大小。在此服务模式下，服务消费方在服务调用过程中，对服务提
供方的服务注册信息进行存储时，减少了服务消费方内存占用，降低了消费方内存占用的潜在风险保证了消费方业务正常执行。且业务子集群各自对外提供的预订业务服务种类汇总后为业务服务集群对外提供的全量预订服务的种类，保证了服务提供方对外整体提供的服务种类不变，做到了对消费方无感知的服务订阅体验。
74.根据本公开的实施例，其中，对服务注册信息进行存储后，所占用服务消费方的内存容量为：
75.总服务数量与单位服务占用内存容量的乘积；其中，总服务数量为各分量服务数量的和，其中分量服务数量为，业务子集群的服务节点数量与业务子集群对外提供的预订业务服务的种类数量的乘积。
76.根据本公开的实施例，为了进一步说明采用本公开实施例所述方法可有效降低服务消费方内存占用的技术效果。以下示例性对比分析采用本公开实施例所述方法所占用的服务消费方内存、与采用相关技术所占用的服务消费方内存的计算结果。
77.例如，服务提供方通过业务服务集群对外提供m个全量预订服务，其中，服务提供方的业务服务集群可包括n个业务子集群，业务服务集群共有x个服务节点，x个服务节点被拆分为n个业务子集群，每个业务子集群的服务节点数分别为x1，x2...x
n
，满足x1 x2 x3
……
x
n
＝x。假设消费方订阅了全量服务，以单位服务占用内存容量，即消费方订阅一个服务占用消费方内存为c计算：
78.(1)采用相关技术(如图2所示的服务框架下)的服务调用方法，因不同业务子集群各自对外提供的预订业务服务种类相同，均向外提供全量预订服务，因此：
79.占用服务消费方内存
80.＝总服务数量*单位服务占用内存容量c
81.＝x*m*c＝(x1 x2 x3
……
x
n
)*m*c
ꢀꢀꢀ
公式(一)
82.(2)采用本公开实施例所述服务调用方法，不同业务子集群各自对外提供的预订业务服务种类不同，同一业务子集群中各服务节点各自对外提供的预订业务服务种类相同，且业务子集群各自对外提供的预订业务服务种类汇总后为业务服务集群对外提供的全量预订服务的种类。m个全量预订服务分别通过n个业务子集群提供，每个业务子集群对外提供的预订业务服务的种类数量分别为m1、m2、m3
……
，且满足m1 m2 m3 m4 m5
……
＝m。总服务数量为各分量服务数量的和，其中分量服务数量为，业务子集群的服务节点数量与业务子集群对外提供的预订业务服务的种类数量的乘积。
83.占用服务消费方内存
84.＝总服务数量*单位服务占用内存容量c
85.＝x1*m1*c x2*m2*c x3*m3*c
……ꢀꢀꢀ
公式(二)
86.比较公式(一)和公式(二)，可以看出，采用本公开实施例所述方法所占用的服务消费方内存，小于采用相关技术所占用的服务消费方内存。可见，采用本公开实施例所述方法，服务消费方在服务调用过程中，对服务提供方的服务注册信息进行存储时，减少了服务消费方内存占用。
87.根据本公开的实施例，上述方法还包括，从注册中心获取服务注册信息前：
88.利用服务提供方加载每个当前服务节点各自对外提供的预订业务服务种类配置信息，以生成服务注册信息后，将服务注册信息发送至注册中心。
89.根据本公开的实施例，其中，加载每个当前服务节点各自对外提供的预订业务服务种类配置信息包括：
90.首先，确定每个当前服务节点所归属的当前业务子集群。
91.其次，确定当前业务子集群的当前预设加载路径，其中当前预设加载路径为：当前业务子集群对外提供的预订业务服务种类配置信息，在服务提供方的存放路径。根据本公开的实施例，服务提供方在向注册中心发起服务注册时候，依赖一系列配置文件，即服务注册信息，可包括各服务节点各自对外提供的预订业务服务种类配置信息，还可包括各预订业务服务的服务存根配置、服务提供配置、服务监控配置、服务集群信息及服务归属应用信息等，可以为预设加载类路径下的配置文件。服务提供方在做集群拆分时，将业务服务集群按照业务领域以及同一业务领域内按照高低频调用拆分为多个业务子集群，每个业务子集群的服务都放在一个provider文件下，每个provider文件代表一个业务子集群对外提供的服务清单，这些provider文件分布放在不同的文件目录下，即为当前预设加载路径，每个文件目录代表一个业务子集群的初始化加载配置。
92.然后，按照当前预设加载路径，加载每个当前服务节点各自对外提供的预订业务服务种类配置信息。
93.图4示意性示出了根据本公开实施例的加载每个当前服务节点各自对外提供的预订业务服务种类配置信息的流程图。以下结合图4对本公开实施例的上述方法进行说明。
94.服务提供方的每台服务器启动时候，按照图4所示流程图判断当前服务器应该加载哪个路径下的配置，从而实现不同服务节点在注册中心注册不同预订业务服务的目的。
95.如图4所示(图4中以共有4服务节点为例进行说明)：
96.根据本公开的实施例，注册中心使用分布式架构的系统，可采用dubbo分布式框架。
97.首先，在服务器初始化启动dubbo时候，通过设置环境变量，启动前先判断当前服务器是哪个业务子集群的服务节点，即确定每个当前服务节点所归属的当前业务子集群。
98.其次，在本地查询确定当前业务子集群的当前预设加载路径，即当前业务子集群对外提供的预订业务服务种类配置信息在服务提供方的存放路径。
99.然后，根据判断结果设置启动参数配置dubbo加载的配置文件路径为相应业务子集群的当前预设加载路径，使每个业务子集群仅向注册中心注册此业务子集群的相关服务，即，按照当前预设加载路径，加载每个当前服务节点各自对外提供的预订业务服务种类配置信息。
100.根据本公开的实施例，通过上述加载方法，使每个业务子集群仅向注册中心注册此业务子集群的相关服务，从而在保证对外暴露的服务接口和服务方法不变的情况下，完成对服务消费方无感的服务拆分，在版本不解耦的前提下实现了运行解耦。
101.根据本公开的实施例，其中，根据预订业务服务种类和服务消费方预先存储的服务注册信息，分别调用服务提供方的各个业务子集群的各个预订业务服务包括：
102.根据预订业务服务种类和服务注册信息确定与各个预订业务服务匹配的业务子集群中的各服务节点；以及基于负载均衡选择服务节点中的目标服务节点，以便通过访问各个目标服务节点，调用服务提供方的各个业务子集群的各个预订业务服务。
103.根据本公开的实施例，其中，根据预订业务服务种类和服务消费方预先存储的服
务注册信息，分别调用服务提供方的各个业务子集群的各个预订业务服务包括：
104.根据预订业务服务种类和服务注册信息，分别通过rpc(remote procedure call)远程过程调用的方式调用服务提供方的各个业务子集群的各个预订业务服务。根据本公开的实施例，服务消费方在服务器启动时，将订阅的服务注册信息缓存在消费方内存，服务调用时候，从内存中获知服务提供方的服务注册信息，并依据这些服务注册信息，借助分布式框架，通过rpc的方式实现服务调用。
105.根据本公开的实施例，通过rpc的调用方式，实现像调用本地的函数一样去调远程函数，使得服务消费方在调用服务提供发的服务时，服务之间的调用像本地调用一样简单。
106.图5示意性示出了根据本公开实施例的服务调用装置的框图。
107.该服务调用装置500可以用来实现参考图3所示的方法。
108.如图5所示，服务调用装置500包括：获取模块510、存储模块520和调用模块530。
109.其中，获取模块510，用于从注册中心获取服务注册信息，其中，服务注册信息包括各个业务子集群中各服务节点各自对外提供的预订业务服务种类配置信息，各个业务子集群属于服务提供方的业务服务集群，其中不同业务子集群各自对外提供的预订业务服务种类不同，同一业务子集群中各服务节点各自对外提供的预订业务服务种类相同，且业务子集群各自对外提供的预订业务服务种类汇总后为业务服务集群对外提供的全量预订服务的种类。
110.存储模块520，用于将服务注册信息存储在服务消费方。
111.调用模块530，用于根据预订业务服务种类和服务消费方预先存储的服务注册信息，分别调用服务提供方的各个业务子集群的各个预订业务服务。
112.公开的实施例，通过获取模块510、存储模块520，服务消费方从注册中心获取服务注册信息后需将服务注册信息存储在服务消费方内存，服务注册信息的容量大小决定了服务消费方占用内存的大小。因服务注册信息的容量大小与服务提供方各服务节点对外提供的服务种类的数量有关，通过服务提供方的集群拆分，设置不同业务子集群各自对外提供的预订业务服务种类不同，使得同一业务子集群中各服务节点对外提供的服务种类的数量得以降低，因此，可降低服务注册信息的容量大小。在此服务模式下，通过调用模块530，服务消费方在服务调用过程中，对服务提供方的服务注册信息进行存储时，减少了服务消费方内存占用，降低了消费方内存占用的潜在风险保证了消费方业务正常执行。且业务子集群各自对外提供的预订业务服务种类汇总后为业务服务集群对外提供的全量预订服务的种类，保证了服务提供方对外整体提供的服务种类不变，做到了对消费方无感知的服务订阅体验。
113.根据本公开的实施例，其中，对服务注册信息进行存储后，所占用服务消费方的内存容量为：总服务数量与单位服务占用内存容量的乘积；其中，总服务数量为各分量服务数量的和，其中分量服务数量为，业务子集群的服务节点数量与业务子集群对外提供的预订业务服务的种类数量的乘积。
114.根据本公开的实施例，上述装置还包括加载模块，用于从注册中心获取服务注册信息前，利用服务提供方加载每个当前服务节点各自对外提供的预订业务服务种类配置信息，以生成服务注册信息后，将服务注册信息发送至注册中心。
115.根据本公开的实施例，其中，加载模块包括第一确定单元、第二确定单元、加载单
元。
116.其中，第一确定单元，用于确定每个当前服务节点所归属的当前业务子集群；第二确定单元，用于确定当前业务子集群的当前预设加载路径，其中当前预设加载路径为：当前业务子集群对外提供的预订业务服务种类配置信息，在服务提供方的存放路径；加载单元，用于按照当前预设加载路径，加载每个当前服务节点各自对外提供的预订业务服务种类配置信息。
117.根据本公开的实施例，其中，调用模块530包括第三确定单元、第一调用单元。
118.其中，第三确定单元，用于根据预订业务服务种类和服务注册信息确定与各个预订业务服务匹配的业务子集群中的各服务节点；第一调用单元，用于基于负载均衡选择服务节点中的目标服务节点，以便通过访问各个目标服务节点，调用服务提供方的各个业务子集群的各个预订业务服务。
119.根据本公开的实施例，其中，调用模块530包括：第二调用单元，用于根据预订业务服务种类和服务注册信息，分别通过远程过程调用的方式调用服务提供方的各个业务子集群的各个预订业务服务。
120.根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
121.例如，获取模块510、存储模块520和调用模块530中的任意多个可以合并在一个模块/单元/子单元中实现，或者其中的任意一个模块/单元/子单元可以被拆分成多个模块/单元/子单元。或者，这些模块/单元/子单元中的一个或多个模块/单元/子单元的至少部分功能可以与其他模块/单元/子单元的至少部分功能相结合，并在一个模块/单元/子单元中实现。根据本公开的实施例，获取模块510、存储模块520和调用模块530中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，获取模块510、存储模块520和调用模块530中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
122.图6示意性示出了根据本公开实施例的用于实现服务调用方法的电子设备的框图。图6示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
123.如图6所示，根据本公开实施例的电子设备600包括处理器601，其可以根据存储在只读存储器(rom)602中的程序或者从存储部分608加载到随机访问存储器(ram)603中的程
序而执行各种适当的动作和处理。处理器601例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))，等等。处理器601还可以包括用于缓存用途的板载存储器。处理器601可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
124.在ram 603中，存储有电子设备600操作所需的各种程序和数据。处理器601、rom 602以及ram 603通过总线604彼此相连。处理器601通过执行rom 602和/或ram 603中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除rom 602和ram 603以外的一个或多个存储器中。处理器601也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
125.根据本公开的实施例，电子设备600还可以包括输入/输出(i/o)接口605，输入/输出(i/o)接口605也连接至总线604。系统600还可以包括连接至i/o接口605的以下部件中的一项或多项：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至i/o接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。
126.根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。在该计算机程序被处理器601执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
127.本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
128.根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质。例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
129.例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom 602和/或ram 603和/或rom 602和ram 603以外的一个或多个存储器。
130.本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序包含用于执行本公开实施例所提供的方法的程序代码，当计算机程序产品在电子设备上运行时，该程序代码用于使电子设备实现本公开实施例所提供的服务调用方法。
131.在该计算机程序被处理器601执行时，执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。
132.在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分609被下载和安装，和/或从可拆卸介质611被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
133.根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如java，c ，python，“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
134.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。
135.以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。