CN112328413B - 应用服务的调用方法、装置及系统 - Google Patents

Abstract

本发明公开了一种应用服务的调用方法、装置及系统，可应用于金融领域，其中，该方法包括：获取服务提供方的应用名称；将应用名称发送至服务注册端，以获取存储在服务注册端的与应用服务相应的服务地址信息；将获取的服务地址信息发送至服务提供方，以获取存储在该服务提供方本地的与应用服务相应的接口信息；根据服务地址信息和接口信息生成访问位置信息(URL)，并根据URL向服务提供方发起应用服务的调用请求。通过本发明，可以降低服务注册端的数据存储和网络推送的压力。

Description

应用服务的调用方法、装置及系统

技术领域

本发明涉及分布式技术领域，可应用于金融领域，具体涉及一种应用服务的调用方法、装置及系统。

背景技术

随着互联网的普及，应用服务化规模迅速增长，分布式服务框架面临较大的压力，分布式注册中心作为未来服务流量分配核心，其性能容量及高可用能力亟待提升。

目前，业界运用比较广泛的分布式服务框架是以接口作为服务注册及寻址单位，其数据存储与推送压力直接和接口个数、应用部署规模成正比，存在大量冗余数据。在接口级服务注册机制下，注册中心数据包含寻址数据、治理数据、配置数据等，这些数据耦合性大，职责分配不清晰。并且，目前的接口级服务注册模型下的分布式体系无法与业界标准的云原生模型直接兼容。

发明内容

有鉴于此，本发明提供一种应用服务的调用方法、装置及系统，以解决上述提及的至少一个问题。

根据本发明的第一方面，提供一种应用服务的调用方法，所述方法包括：

获取服务提供方的应用名称；

将所述应用名称发送至服务注册端，以获取存储在所述服务注册端的与所述应用服务相应的服务地址信息；

将获取的服务地址信息发送至所述服务提供方，以获取存储在该服务提供方本地的与所述应用服务相应的接口信息；

根据所述服务地址信息和所述接口信息生成访问位置信息(URL)，并根据所述URL向所述服务提供方发起应用服务的调用请求。

根据本发明的第二方面，提供一种应用服务的调用装置，所述装置包括：

应用名称获取单元，用于获取服务提供方的应用名称；

应用名称发送单元，用于将所述应用名称发送至服务注册端，以获取存储在所述服务注册端的与所述应用服务相应的服务地址信息；

第一服务地址信息发送单元，用于将获取的服务地址信息发送至所述服务提供方，以获取存储在该服务提供方本地的与所述应用服务相应的接口信息；

访问位置信息生成单元，用于根据所述服务地址信息和所述接口信息生成URL；

调用请求单元，用于根据所述URL向所述服务提供方发起应用服务的调用请求。

根据本发明的第三方面，提供一种应用服务的调用系统，所述系统包括：上述的应用服务的调用装置、服务提供方和服务注册端，所述应用服务的调用装置位于服务消费方，所述服务提供方存储与应用服务相应的接口信息，所述服务注册端存储与所述应用服务相应的服务地址信息。

根据本发明的第四方面，提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法的步骤。

根据本发明的第五方面，提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

由上述技术方案可知，通过将获取的服务提供方的应用名称发送至服务注册端，获取存储在所述服务注册端的与所述应用服务相应的服务地址信息，并将获取的服务地址信息发送至服务提供方，获取存储在该服务提供方本地的与所述应用服务相应的接口信息，之后根据服务地址信息和接口信息生成URL，并根据所述URL向所述服务提供方发起应用服务的调用请求，相比于现有技术，由于本发明实施例的服务注册端仅存储应用服务的服务地址信息，因而可以降低服务注册端的数据存储和网络推送的压力。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本发明实施例的应用服务调用系统的结构框图；

图2是根据本发明实施例的应用服务调用装置10的结构框图；

图3是根据本发明实施例的服务提供方20的结构框图；

图4是根据本发明实施例的服务注册端30的结构框图；

图5是根据本发明实施例的示例系统的结构框图；

图6是根据本发明实施例的服务提供者服务注册装置1的结构框图；

图7是根据本发明实施例的服务消费者服务订阅装置4的结构框图；

图8是基于图5所示的示例系统的RPC调用流程示意图；

图9是根据本发明实施例的应用服务调用方法的流程图；

图10为本发明实施例的电子设备600的系统构成的示意框图。

具体实施方式

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

由于目前的基于接口的分布式服务框架在注册中心存在大量冗余数据，并且这些数据耦合性大、职责分配不清晰，造成了注册中心数据存储和网络推送压力较大的问题。基于此，本发明实施例提供一种应用服务的调用方案，该方案可以从根本上降低注册中心的数据存储、网络推送压力，且能兼容业界标准云原生模型，同时保持RPC(Remote Procedurecall，远程过程调用)调用寻址过程的自动化。以下结合附图来详细描述本发明实施例。

图1是根据本发明实施例的应用服务调用系统的结构框图，如图1所示，该系统包括：位于服务消费方端的应用服务调用装置10、服务提供方20和服务注册端30(即，上述的注册中心)，其中，服务提供方存储有与应用服务相应的接口信息，存储格式可以是应用名称-服务地址-接口信息；所述服务注册端存储有与所述应用服务相应的服务地址信息，存储格式可以是应用名称-服务地址。

以下分别详细描述各部分。

图2是上述应用服务调用装置10的结构框图，如图2所示，该应用服务调用装置10包括：应用名称获取单元101、应用名称发送单元102、第一服务地址信息发送单元103、访问位置信息生成单元104和调用请求单元105，其中：

应用名称获取单元101，用于获取服务提供方的应用名称；

应用名称发送单元102，用于将所述应用名称发送至服务注册端，以获取存储在所述服务注册端的与所述应用服务相应的服务地址信息；

第一服务地址信息发送单元103，用于将获取的服务地址信息发送至所述服务提供方，以获取存储在该服务提供方本地的与所述应用服务相应的接口信息；

访问位置信息生成单元104，用于根据所述服务地址信息和所述接口信息生成访问位置信息(URL)；

调用请求单元105，用于根据所述URL向所述服务提供方发起应用服务的调用请求。

通过应用名称发送单元102将应用名称获取单元101获取的服务提供方的应用名称发送至服务注册端，获取存储在所述服务注册端的与所述应用服务相应的服务地址信息，第一服务地址信息发送单元103将获取的服务地址信息发送至服务提供方，获取存储在该服务提供方本地的与所述应用服务相应的接口信息，之后访问位置信息生成单元104根据服务地址信息和接口信息生成URL，调用请求单元105根据所述URL向所述服务提供方发起应用服务的调用请求，相比于现有技术，由于本发明实施例的服务注册端仅存储应用服务的服务地址信息，因而可以降低服务注册端的数据存储和网络推送压力。

在实际操作中，上述访问位置信息生成单元104具体包括：聚合模块和访问位置信息生成模块，其中：聚合模块，用于将所述服务地址信息和所述接口信息进行聚合操作；访问位置信息生成模块，用于根据聚合操作后的结果生成所述URL。

在一个实施例中，上述应用服务调用装置10还包括：更新通知接收单元，用于响应于所述服务地址信息的更新操作，接收来自所述服务注册端的服务地址信息更新通知。

具体地，当应用名称发送单元102将应用名称发送至服务注册端，服务注册端将存储的与应用名称相应的服务地址信息返回时，此时，可以认为服务消费方在服务注册端已注册成功。之后，当服务注册端存储的服务地址信息有更新时，会将服务地址信息更新通知发送给更新通知接收单元，以便于服务消费端获知。

图3是服务提供方20的结构框图，如图3所示，该服务提供方20包括：第二服务地址信息发送单元201、接口信息发送单元202和调用服务单元203，其中：

第二服务地址信息发送单元201，用于将与所述应用服务相应的服务地址信息发送至所述服务注册端，以便于所述服务注册端存储该服务地址信息；

接口信息发送单元202，用于根据接收的来自应用服务调用装置的服务地址信息将相应的接口信息返回至该应用服务调用装置；

调用服务单元203，用于接收来自所述应用服务调用装置的调用请求，并根据该调用请求提供相应的调用服务。

图4是服务注册端30的结构框图，如图4所示，该服务注册端30包括：服务地址信息接收单元301、第三服务地址信息发送单元302和更新通知发送单元303，其中：

服务地址信息接收单元301，用于接收来自所述服务提供方的与应用服务相应的服务地址信息，以便于存储。

在一个实施例中，可以以“应用名称-服务地址”的映射关系存储。

第三服务地址信息发送单元302，用于根据接收的来自应用服务调用装置的应用名称，将与该应用名称相应的服务地址信息返回至该应用服务调用装置。

更新通知发送单元303，用于响应于所述服务地址信息的更新操作，将服务地址信息更新通知发送给所述应用服务调用装置。

为了更好地理解本发明，以下给出一具体实施例。

在该实施例中，分布式服务体系具体包括三种角色：服务提供者(Provider，对应于上述的服务提供者)、服务消费者(Consumer，对应于上述的服务消费者)和注册中心(Registry，对应于上述的服务注册端)。不同服务注册与订阅机制最主要的区别体现在注册中心数据的组织：地址如何组织、以什么粒度组织、除地址外还同步哪些数据、如何管理接口级的RPC信息。在本实施例中，对提供者、消费者内置的服务框架进行了改造，对注册中心数据进行了重新组织，提供了一种新的服务注册与订阅机制。

图5是根据本发明实施例的示例系统的结构框图，如图5所示，该系统包括：服务提供者服务注册装置1、注册中心数据存储装置2、注册中心数据推送装置3、服务消费者服务订阅装置4。以下详细描述各装置。

(1)服务提供者服务注册装置1

图6是服务提供者服务注册装置1的结构框图，如图6所示，该服务提供者服务注册装置1包括注册服务单元11，该注册服务单元具体包括：元数据查询内置服务模块111、服务提供者普通服务模块112，其中：

注册服务单元11，用于将服务提供方应用实例信息上报到注册中心，数据格式为“应用名称-实例列表”，该数据以树状存储，实例列表包括多个实例地址，例如，应用名称可以是demo-provider，实例列表中的一个地址可以是192.168.0.102.28080，实例地址包含的值可以是一个JSON(JavaScript Object Notation，JS对象简谱)串，该JSON串可以包括：服务提供方应用名称(name)、服务提供方地址(address)、服务注册时间戳(registrationTimeUTC)等信息。

元数据查询内置服务模块111，用于实现元数据查询服务，当消费方请求查询元数据(即，上述的接口信息)时，元数据查询内置服务模块111会返回服务提供方所有接口的详细信息，包括：接口名称、方法名、自定义参数、版本号等，还可以包括从注册中心查询到的服务提供方地址(即，上述的服务地址信息)。

在一个实例中，当应用对应三个接口时，在消费方请求查询元数据时，元数据查询内置服务模块111会返回如下所示的三个接口的元数据信息：

[

"dubbo://192.168.0.102:20880/org.apache.dubbo.demo.DemoService？anyhost＝tru e&application＝demo-provider&deprecated＝false&dubbo＝2.0.2&dynamic＝true&generi c＝false&interface＝org.apache.dubbo.demo.DemoService&methods＝sayHello&pid＝9585&release＝2.7.5&side＝provider×tamp＝1583469714314",

"dubbo://192.168.0.102:20880/org.apache.dubbo.demo.HelloService？anyhost＝true&application＝demo-provider&deprecated＝false&dubbo＝2.0.2&dynamic＝true&generic＝false&interface＝org.apache.dubbo.demo.DemoService&methods＝sayHello&pid＝9585&release＝2.7.5&side＝provider×tamp＝1583469714314",

"dubbo://192.168.0.102:20880/org.apache.dubbo.demo.WorldService？anyhost＝tru e&application＝demo-provider&deprecated＝false&dubbo＝2.0.2&dynamic＝true&generi c＝false&interface＝org.apache.dubbo.demo.DemoService&methods＝sayHello&pid＝9585&release＝2.7.5&side＝provider×tamp＝1583469714314"

]

服务提供者普通服务模块112，是服务提供方提供给消费方调用的服务，在系统启动后，这些服务的接口信息会被加载到服务提供者的本地内存，作为元数据查询内置服务模块的数据源。

(2)注册中心数据存储装置2

注册中心数据存储装置2，主要用于存放服务提供者节点级的信息，存储“实例名-实例地址”的映射关系，该实例地址即是服务提供方的地址信息等。该地址信息可以包括：服务提供方应用名称(name)、服务提供方地址(address)、服务注册时间戳(registrationTimeUTC)等信息。

(3)注册中心数据推送装置3

注册中心数据推送装置3，主要用于向服务消费者推送数据更新通知等。

(4)服务消费者服务订阅装置4

图7是服务消费者服务订阅装置4的结构框图，如图7所示，该服务消费者服务订阅装置4包括：服务订阅单元41、元数据详细信息查询服务单元42、服务调用单元43，其中：

服务订阅单元41，在服务消费方启动后，通过配置文件获取应用服务对应的应用名称，并通过该应用名称向注册中心获取实例地址。

具体而言，当消费方启动后，根据配置文件获知需要调用哪些服务以及这些服务对应的应用名称。然后，根据这些应用名称，在注册中心获取服务提供方的地址。在一个实例中，配置文件如下所示，其中，“interface”为接口，“provided-by”为应用名称：

<dubbo:registry address＝"zookeeper://127.0.0.1:2181？registry-type＝service"/>

<dubbo:reference id＝"demoService"check＝"false"

interface＝"org.apache.dubbo.demo.DemoService"

provided-by＝"demo-provider"/>

另外，服务订阅单元41还在注册中心注册监听器，注册监听器后如果服务提供方地址发生变化，注册中心会自动通知消费方。

元数据详细信息查询服务单元42，用于通过根据服务订阅单元41获取的应用实例地址，调用内建的元数据信息查询服务，获取应用服务的详细信息(即，接口元数据信息)。

服务调用单元43，根据元数据详细信息查询服务单元42的查询结果，在内存中进行聚合，生成服务调用所需要的URL，发起调用。

图8是基于图5所示的示例系统的RPC调用流程示意图，如图8所示，该流程包括：

步骤801，服务提供者启动时，加载服务提供者的配置文件，解析应用定义的“普通服务”并依次注册为RPC服务，之后注册内建的元数据详细信息查询服务，最后打开TCP监听端口，该监听端口用于接收消费方的调用消息。

在一个实施例中，配置文件的格式可以是如下所示，这样服务提供方就注册了一个叫com.icbc.dsf.demo.springboot.tracing.itf.DemoService的接口：

<dubbo:service

interface＝"com.icbc.dsf.demo.springboot.tracing.itf.DemoService"

ref＝"demoService"version＝"15.0"/>

步骤802，提供方启动完成后，将实例信息注册到注册中心(仅限IP、port等实例地址相关数据)，之后提供者启动完成。

步骤803，服务消费者启动，加载服务消费方自己的配置文件，获取其要“消费的提供方的应用名称”、并到注册中心查询地址列表，完成订阅，以实现后续地址变更自动通知。

步骤804，消费方获取地址列表后，调用元数据查询服务，查询返回结果中包含了所有应用定义的“普通服务”及其相关配置信息。

步骤805，消费方根据步骤804获取的查询结果，生成URL，即，http请求，之后根据URL对服务提供方发起RPC调用。

本发明实施例通过基于应用维度的服务注册与订阅机制，降低了注册中心数据存储、网络推送压力，提升了分布式体系的性能容量，为互联网的迅速发展提供了稳定可靠的基础技术支撑。

在实际操作中，上述各单元、各模块可以组合设置、也可以单一设置，本发明不限于此。

基于相似的发明构思，本发明实施例还提供一种应用服务的调用方法，优选地，该方法可应用于上述应用服务调用装置。

图9是该应用服务调用方法的流程图，如图9所示，该方法包括：

步骤901，获取服务提供方的应用名称。

步骤902，将所述应用名称发送至服务注册端，以获取存储在所述服务注册端的与所述应用服务相应的服务地址信息。

步骤903，将获取的服务地址信息发送至所述服务提供方，以获取存储在该服务提供方本地的与所述应用服务相应的接口信息。

步骤904，根据所述服务地址信息和所述接口信息生成URL，并根据所述URL向所述服务提供方发起应用服务的调用请求。

具体地，可以先将所述服务地址信息和所述接口信息进行聚合操作；之后，根据聚合操作后的结果生成所述URL。

通过将获取的服务提供方的应用名称发送至服务注册端，获取存储在所述服务注册端的与所述应用服务相应的服务地址信息，并将获取的服务地址信息发送至服务提供方，获取存储在该服务提供方本地的与所述应用服务相应的接口信息，之后根据服务地址信息和接口信息生成URL，并根据所述URL向所述服务提供方发起应用服务的调用请求，相比于现有技术，由于本发明实施例的服务注册端仅存储应用服务的服务地址信息，因而可以降低服务注册端的数据存储和网络推送的压力。

在实际操作中，在获取存储在所述服务注册端的与所述应用服务相应的服务地址信息之后，当服务注册端的服务地址信息更新时，会发送服务地址信息更新通知，此时，就会接收到来自服务注册端的服务地址信息更新通知。

具体地，上述各步骤的详细流程可以参见上述装置实施例中的描述，此处不再赘述。

本实施例还提供一种电子设备，该电子设备可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该电子设备可以参照上述方法实施例进行实施及应用服务的调用装置/系统的实施例进行实施，其内容被合并于此，重复之处不再赘述。

图10为本发明实施例的电子设备600的系统构成的示意框图。如图10所示，该电子设备600可以包括中央处理器100和存储器140；存储器140耦合到中央处理器100。值得注意的是，该图是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

一实施例中，应用服务的调用功能可以被集成到中央处理器100中。其中，中央处理器100可以被配置为进行如下控制：

获取服务提供方的应用名称；

将所述应用名称发送至服务注册端，以获取存储在所述服务注册端的与所述应用服务相应的服务地址信息；

将获取的服务地址信息发送至所述服务提供方，以获取存储在该服务提供方本地的与所述应用服务相应的接口信息；

根据所述服务地址信息和所述接口信息生成URL，并根据所述URL向所述服务提供方发起应用服务的调用请求。

从上述描述可知，本申请实施例提供的电子设备，通过将获取的服务提供方的应用名称发送至服务注册端，获取存储在所述服务注册端的与所述应用服务相应的服务地址信息，并将获取的服务地址信息发送至服务提供方，获取存储在该服务提供方本地的与所述应用服务相应的接口信息，之后根据服务地址信息和接口信息生成URL，并根据所述URL向所述服务提供方发起应用服务的调用请求，相比于现有技术，由于本发明实施例的服务注册端仅存储应用服务的服务地址信息，因而可以降低服务注册端的数据存储和网络推送的压力。

在另一个实施方式中，应用服务的调用装置/系统可以与中央处理器100分开配置，例如可以将应用服务的调用装置/系统配置为与中央处理器100连接的芯片，通过中央处理器的控制来实现应用服务的调用功能。

如图10所示，该电子设备600还可以包括：通信模块110、输入单元120、音频处理器130、显示器160、电源170。值得注意的是，电子设备600也并不是必须要包括图10中所示的所有部件；此外，电子设备600还可以包括图10中没有示出的部件，可以参考现有技术。

如图10所示，中央处理器100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器100接收输入并控制电子设备600的各个部件的操作。

其中，存储器140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器100可执行该存储器140存储的该程序，以实现信息存储或处理等。

输入单元120向中央处理器100提供输入。该输入单元120例如为按键或触摸输入装置。电源170用于向电子设备600提供电力。显示器160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器140还可以是某种其它类型的装置。存储器140包括缓冲存储器141(有时被称为缓冲器)。存储器140可以包括应用/功能存储部142，该应用/功能存储部142用于存储应用程序和功能程序或用于通过中央处理器100执行电子设备600的操作的流程。

存储器140还可以包括数据存储部143，该数据存储部143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器140的驱动程序存储部144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块110即为经由天线111发送和接收信号的发送机/接收机110。通信模块(发送机/接收机)110耦合到中央处理器100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)110还经由音频处理器130耦合到扬声器131和麦克风132，以经由扬声器131提供音频输出，并接收来自麦克风132的音频输入，从而实现通常的电信功能。音频处理器130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器130还耦合到中央处理器100，从而使得可以通过麦克风132能够在本机上录音，且使得可以通过扬声器131来播放本机上存储的声音。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时以实现上述应用服务的调用方法的步骤。

综上所述，为了降低注册中心数据存储、网络推送压力，提升分布式体系的性能容量，为互联网的迅速发展提供稳定可靠的基础技术支撑，本发明实施例提供了一种新的服务注册与订阅机制，通过对注册中心数据进行拆分，实现了注册中心数据的精简，接口相关信息迁移到服务提供方本地进行本地化存储，从而降低了注册中心的数据存储、网络推送压力。具体地，本发明实施例具有如下优点：

1、注册中心传递的URL一拆为二：一部分和实例相关的数据继续保留在注册中心，如ip、port、机器标识等；另一部分和RPC方法相关的数据从注册中心移除，转而通过元数据信息查询服务暴露给消费端，很大程度上减少了注册中心的存储压力。

2、原注册中心的URL被拆解成实例信息，用于消费方服务调用寻址，实现了注册中心注册数据和治理数据的解耦，保证注册中心职责清晰。

3、实现了基于应用维度的服务注册与订阅，在分布式服务框架对接标准云原生体系的道路上迈出了重要一步。

以上参照附图描述了本发明的优选实施方式。这些实施方式的许多特征和优点根据该详细的说明书是清楚的，因此权利要求旨在覆盖这些实施方式的落入其真实精神和范围内的所有这些特征和优点。此外，由于本领域的技术人员容易想到很多修改和改变，因此不是要将本发明的实施方式限于所例示和描述的精确结构和操作，而是可以涵盖落入其范围内的所有合适修改和等同物。

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

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

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

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

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (11)

1.一种应用服务的调用方法，其特征在于，所述方法包括：

获取服务提供方的应用名称；

将所述应用名称发送至服务注册端，以获取存储在所述服务注册端的与所述应用服务相应的服务地址信息；

将获取的服务地址信息发送至所述服务提供方，以获取存储在该服务提供方本地的与所述应用服务相应的接口信息；

根据所述服务地址信息和所述接口信息生成访问位置信息URL，并根据所述URL向所述服务提供方发起应用服务的调用请求。

2.根据权利要求1所述的方法，其特征在于，根据所述服务地址信息和所述接口信息生成访问位置信息URL包括：

将所述服务地址信息和所述接口信息进行聚合操作；

根据聚合操作后的结果生成所述URL。

3.根据权利要求1所述的方法，其特征在于，获取存储在所述服务注册端的与所述应用服务相应的服务地址信息之后，所述方法还包括：

响应于所述服务地址信息的更新操作，接收来自所述服务注册端的服务地址信息更新通知。

4.一种应用服务的调用装置，其特征在于，所述装置包括：

应用名称获取单元，用于获取服务提供方的应用名称；

应用名称发送单元，用于将所述应用名称发送至服务注册端，以获取存储在所述服务注册端的与所述应用服务相应的服务地址信息；

第一服务地址信息发送单元，用于将获取的服务地址信息发送至所述服务提供方，以获取存储在该服务提供方本地的与所述应用服务相应的接口信息；

访问位置信息生成单元，用于根据所述服务地址信息和所述接口信息生成访问位置信息URL；

调用请求单元，用于根据所述URL向所述服务提供方发起应用服务的调用请求。

5.根据权利要求4所述的装置，其特征在于，所述访问位置信息生成单元包括：

聚合模块，用于将所述服务地址信息和所述接口信息进行聚合操作；

访问位置信息生成模块，用于根据聚合操作后的结果生成所述URL。

6.根据权利要求4所述的装置，其特征在于，所述装置还包括：

更新通知接收单元，用于响应于所述服务地址信息的更新操作，接收来自所述服务注册端的服务地址信息更新通知。

7.一种应用服务的调用系统，其特征在于，所述系统包括：如权利要求4-6中任一项所述的应用服务的调用装置、服务提供方和服务注册端，所述应用服务的调用装置位于服务消费方，所述服务提供方存储与应用服务相应的接口信息，所述服务注册端存储与所述应用服务相应的服务地址信息。

8.根据权利要求7所述的系统，其特征在于，所述服务提供方包括：

第二服务地址信息发送单元，用于将与所述应用服务相应的服务地址信息发送至所述服务注册端，以便于所述服务注册端存储该服务地址信息；

接口信息发送单元，用于根据接收的来自应用服务调用装置的服务地址信息将相应的接口信息返回至该应用服务调用装置；

调用服务单元，用于接收来自所述应用服务调用装置的调用请求，并根据该调用请求提供相应的调用服务。

9.根据权利要求7所述的系统，其特征在于，所述服务注册端包括：

服务地址信息接收单元，用于接收来自所述服务提供方的与应用服务相应的服务地址信息，以便于存储；

第三服务地址信息发送单元，用于根据接收的来自应用服务调用装置的应用名称，将与该应用名称相应的服务地址信息返回至该应用服务调用装置；

更新通知发送单元，用于响应于所述服务地址信息的更新操作，将服务地址信息更新通知发送给所述应用服务调用装置。

10.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至3中任一项所述方法的步骤。

11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至3中任一项所述方法的步骤。