CN117950828A - 应用调用方法及装置、电子设备、计算机可读存储介质 - Google Patents

Abstract

本公开提供了应用调用方法及装置、电子设备、计算机可读存储介质，应用于第一网关，该方法包括：接收第一应用发送的调用请求，调用请求是由第一应用基于目标服务信息生成的服务化调用请求；目标服务信息为在第一注册服务器中对第二应用进行代理注册后生成的信息；将调用请求发送至第二网关；接收第二网关发送的响应消息，并将响应消息发送至第一应用。根据本公开的实施例能够方便且稳定地实现应用间的跨机房服务化调用。

Description

应用调用方法及装置、电子设备、计算机可读存储介质

技术领域

本公开涉及计算机技术领域，特别涉及应用调用方法及装置、电子设备、计算机可读存储介质。

背景技术

随着互联网技术的不断发展，往往需要将应用服务部署在不同区域的互联网数据中心(IDC，Internet Data Center)机房中，以通过实现同城或异地等多活机制，满足用户对应用服务的高可用性以及业务连续性等需求。然而，在同城或异地等多活机制下，如何方便且稳定地实现应用间的跨机房服务化调用成为当前亟待解决的问题。

发明内容

本公开提供一种应用调用方法及装置、电子设备、计算机可读存储介质。

第一方面，本公开提供了一种应用调用方法，应用于第一网关，该应用调用方法包括：

接收第一应用发送的调用请求，其中，所述调用请求是由所述第一应用基于目标服务信息生成的服务化调用请求；所述目标服务信息为在第一注册服务器中对第二应用进行代理注册后生成的信息，所述第一网关和所述第一注册服务器位于所述第一应用所处的第一机房内；

将所述调用请求发送至第二网关，其中，所述第二网关位于所述第二应用所处的第二机房内，所述第二网关用于将所述调用请求转发至所述第二应用，以及，接收所述第二应用响应所述调用请求生成的响应消息；

接收所述第二网关发送的所述响应消息，并将所述响应消息发送至所述第一应用。

第二方面，本公开提供了另一种应用调用方法，应用于第一应用，该应用调用方法包括：

从第一注册服务器中获取目标服务信息，其中，所述目标服务信息为第一网关在所述第一注册服务器中对所述第二应用进行代理注册后生成的信息，所述第一网关和所述第一注册服务器位于所述第一应用所处的第一机房内；

根据所述目标服务信息，生成调用请求，并基于所述第一网关将所述调用请求发送至第二网关，其中，所述第二网关位于所述第二应用所处的第二机房内，所述第二网关用于将所述调用请求转发至所述第二应用，接收所述第二应用响应所述调用请求生成的响应消息，以及将所述响应消息发送至所述第一网关；

接收所述第一网关发送的所述响应消息。

第三方面，本公开提供了一种应用调用装置，应用于第一网关，该应用调用装置包括：

第一接收单元，用于接收第一应用发送的调用请求，其中，所述调用请求是由所述第一应用基于目标服务信息生成的服务化调用请求；所述目标服务信息为在第一注册服务器中对第二应用进行代理注册后生成的信息，所述第一网关和所述第一注册服务器位于所述第一应用所处的第一机房内；

发送单元，用于将所述调用请求发送至第二网关，其中，所述第二网关位于所述第二应用所处的第二机房内，所述第二网关用于将所述调用请求转发至所述第二应用，以及，接收所述第二应用响应所述调用请求生成的响应消息；

第二接收单元，用于接收所述第二网关发送的所述响应消息，并将所述响应消息发送至所述第一应用。

第四方面，本公开提供了另一种应用调用装置，应用于第一应用，该应用调用装置包括：

获取单元，用于从第一注册服务器中第二应用的目标服务信息，其中，所述目标服务信息为第一网关在所述第一注册服务器中对所述第二应用进行代理注册后生成的信息，所述第一网关和所述第一注册服务器位于所述第一应用所处的第一机房内；

生成单元，用于根据所述目标服务信息，生成调用请求，并基于所述第一网关将所述调用请求发送至第二网关，其中，所述第二网关位于所述第二应用所处的第二机房内，所述第二网关用于将所述调用请求转发至所述第二应用，接收所述第二应用响应所述调用请求生成的响应消息，以及将所述响应消息发送至所述第一网关；

第三接收单元，用于接收所述第一网关发送的所述响应消息。

第五方面，本公开提供了一种电子设备，该电子设备包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的一个或多个计算机程序，一个或多个所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述第一方面或第二方面的应用调用方法。

第六方面，本公开提供了一种计算机可读存储介质，其上存储有计算机程序，其中，所述计算机程序在被处理器执行时实现上述第一方面或第二方面的应用调用方法。

本公开所提供的实施例，针对与第一应用处于不同机房的第二应用，位于第一应用所处的第一机房内的应用网关，即第一网关在接入第二应用时，可以通过对该第二应用进行代理注册，以将该第二应用的目标服务信息注册到位于该第一机房内的第一注册服务器中，这样，虽然第二应用在自身启动过程中并不会将自身的服务信息注册到第一机房内的第一注册服务器中，但是由于第一网关在接入第二应用时将该目标服务信息注册到了该第一注册服务器中，这就使得第一应用在需要调用该第二应用时，第一应用可以从该第一注册服务器中获取到由第一网关代理注册的该第二应用的目标服务信息，从而基于该目标服务信息以服务化调用方式生成调用请求，并将该调用请求发送至该第一网关，之后，由该第一网关将该调用请求发送至与第二应用所处第二机房对应的第二网关，并通过接收该第二网关发送的、由第二应用生成的响应消息，实现应用间的跨机房服务化调用。

由于只需要第一网关对处于第一机房外的第二应用提供代理注册，以将第二应用的目标服务信息注册到第一注册服务器中，而不需要进行其他耗费硬件资源的额外处理，针对同机房内的应用间的服务化调用，一方面可以由应用在启动过程中自行在同机房内的注册服务器中注册自身的服务信息，而不需要自身所处机房内的网关对其进行代理注册，例如，第一应用可以在启动过程中自行在第一注册服务器中注册自身的服务信息，而不需要第一网关对其进行代理注册；另一方面，针对同机房内的服务化调用，应用之间依然可以通过从同机房内的注册服务器中获取服务信息的方式直接进行应用与应用之间的调用，而不需要依赖于同机房内的网关对其调用请求进行转发，例如，第一应用在需要调用第一机房内的其他应用时，其可以直接从第一注册服务器中获取该其他应用在启动过程中在第一注册服务器中注册的服务信息，从而直接调用该其他应用，而不需要基于第一网关对其调用请求进行转发，因此，基于本公开不需要对第一机房和第二机房内的网关额外增加硬件资源，即可在不影响同机房内应用间的服务化调用的前提下，方便且稳定地实现应用间的跨机房服务化调用。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用来提供对本公开的进一步理解，并且构成说明书的一部分，与本公开的实施例一起用于解释本公开，并不构成对本公开的限制。通过参考附图对详细示例实施例进行描述，以上和其他特征和优点对本领域技术人员将变得更加显而易见，在附图中：

图1为相关技术中的应用调用处理的示意图；

图2为本公开实施例提供的应用调用方法的实施环境的示意图；

图3为本公开实施例提供的一种应用调用方法的流程图；

图4为本公开实施例提供的另一种应用调用方法的流程图；

图5为本公开实施例提供的一种应用调用装置的框图；

图6为本公开实施例提供的另一种应用调用装置的框图；

图7为本公开实施例提供的一种电子设备的框图。

具体实施方式

为使本领域的技术人员更好地理解本公开的技术方案，以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在不冲突的情况下，本公开各实施例及实施例中的各特征可相互组合。

如本文所使用的，术语“和/或”包括一个或多个相关列举条目的任何和所有组合。

本文所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其它特征、整体、步骤、操作、元件、组件和/或其群组。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。

本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。本技术方案用户数据的使用，遵循国家相关法律法规(例如，《信息安全技术个人信息安全规范》等)。如：个人信息访问控制采取相应规定措施；个人信息的展示给予规定限制；个人信息使用目的没有超出直接或合理关联范围；使用个人信息时消除明确身份指向性，避免精确定位到特定个人。

除非另外限定，否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。

为了方便理解，现对以下专业名词进行解释说明，后续不再赘述。

eureka，是一种服务发现框架，其本身是一个基于表述性状态传递(REST，Representational State Transfer)的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。eureka包含eureka server和eurekaclient该两个组件，其中，eureka server提供服务注册服务，各个节点启动后，会在eurekaserver中进行注册，这样eureka server中的服务注册表中将会存储所有可用服务节点的服务列表信息；eureka client是一个java客户端，用于简化与eureka server的交互，客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。

应用负载均衡器(ALB，Application Load Balancer)，也称alb网关，其可以用于将http请求路由到多个后端资源的单个端点。

服务化应用，是指在注册服务器中注册的应用，例如，可以是通过eureka client自行注册到eureka server的应用。

服务化调用，是指基于注册服务器，即微服务注册中心，例如eureka server实现应用和应用之间的直接调用，即，应用之间在进行服务化调用时，所有应用在启动过程中将通过自动上报的方式将自身的服务信息注册到注册服务器中，这样，当处于同一机房内的应用之间需要进行服务化调用时，在被调用应用处于服务可用状态的情况下，调用应用可以从自身机房内的注册服务器中获取到被调用应用的服务信息，并直接调用该被调用应用，而不需要基于网关转发调用请求；而针对跨机房的服务化调用，则往往需要基于网关进行应用之间的间接调用。

zookeeper，是一个分布式协调服务的开源框架。主要作用是为分布式系统提供协调服务，包括但不限于：分布式锁、统一命名服务、配置管理、负载均衡、主控服务器选举以及主从切换等。zookeeper本质上是一个分布式的小文件存储系统，提供类似与文件系统目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储的数据的状态变化，通过监控这些数据状态的变化，实现基于数据的集群管理。

请参看图1，其为相关技术中的应用调用处理的示意图，其中，在图1中，以各机房对应的注册服务器为基于eureka server实现的微服务注册中心，以各机房对应的网关为alb网关为例进行示意说明。

在多IDC数据中心场景下，即，在多机房场景下，不同机房内的应用往往只能将自身服务注册到自身所处机房内的注册服务器中，例如机房A内的应用A在启动过程中只能将自身的服务信息1注册到eureka server1中，而不能将该服务信息1跨机房注册到eurekaserver2中，其中，应用启动过程中在eureka server中注册的服务信息通常由应用的应用标识和ip:port形式的地址信息构成；同理，机房B内的应用B在启动过程中只能将自身的服务信息2注册到eureka server2中，而不能将该服务信息2跨机房注册到eureka server1中。

因此，在该种场景下，当需要进行应用间的跨机房调用时，例如，若应用A需要调用应用B时，由于应用A不能从eureka server1中获取到应用B的服务信息2，或者，获取到的是经由eureka server2同步至eureka server1的服务信息2，由于该服务信息2中应用B的地址信息为ip:port形式，又由于应用B的该ip地址通常为机房B内的内网IP地址，因此，基于应用B的该种形式的地址信息，应用A将不能访问到应用B，从而也无法实现对应用B进行服务化调用。

在相关技术中，为了实现应用间的跨机房服务化调用，一般是对被调用应用进行eureka拦截，即euraka劫持到机房的alb网关中；在该种情况下，与被调用应用对应的、包含被调用应用自身所处机房的所有机房内的alb网关将根据该被调用应用的拦截信息，改写该被调用应用在自身机房内的eureka server中的服务信息，这样，无论是自身机房还是其他机房内的调用应用在需要调用该被调用应用时，由于从自身机房内的eureka server获取到的是改写后的该被调用应用的服务信息，因此，其可以基于该改写的服务信息对被调用应用进行服务化调用，在该种情况下，针对该被调用应用的服务化调用的流量都将通过alb网关进行代理转发，从而达到跨机房服务化调用的目的。

例如，如图1所示，在机房A内的应用A需要跨机房调用机房B内的应用B时，一般先使用eureka client通过服务发现方法函数，即discoveryClient向eureka server1请求获取应用B的服务列表，该服务列表中包括应用B的服务信息；响应于该请求，eureka server1在向集成于应用A中的eureka client返回应用B的服务列表之前会判断zookeeper集群是否有应用B的应用劫持数据；如有，则会根据改写规则，返回应用B的改写后的服务列表；如无，则返回应用B的原始的服务列表，其中，应用B的应用劫持数据可以由运维人员通过管理后台预先对应用B设置eureka拦截，并将其拦截数据写入zookeeper集群中。

具体地，如图1所示，当eureka server1查询zookeeper集群中存在应用B的应用劫持数据之后，则可以将应用B的服务列表中的ip:port形式的地址信息，例如图1所示的原始服务列表{1.1.1.1:8080,2.2.2.2:8080}改写为{1-1-1-1:8080.b.xxxx.lo,2-2-2-2:8080.b.xxxx.lo}，并将改写后的该服务列表返回给应用A中的eureka client，之后，应用A通过泛域名调用应用B，由于应用B的改写后的服务列表中的域名都解析到了业务网关，即，alb网关1，因此，应用A若通过应用B的改写后的服务列表调用应用B，则流量都会转发到alb网关1，并由alb网关1转发该调用至应用B所处机房B内的alb网关2，再由alb网关2将该调用转发至应用B，从而实现应用之间的跨机房服务化调用。

然而，在该种应用调用方法中，无论是其他机房内的应用B以服务化调用方式调用应用B，还是与应用B处于同一机房内的应用C以服务化调用方式调用该应用B，由于该应用B的服务信息都会被alb网关进行改写，这就导致即使是与应用B处于同一机房内的应用C以服务化调用方式调用该应用B，应用C也不能直接调用应用B，由于在该种情况下，应用C从自身机房内的eureka server获取到的也是应用B的改写后的服务信息，因此，应用C针对应用B的服务化调用的流量也将通过alb网关进行代理转发，这将大幅提升alb网关的压力，往往需要耗费成本提升alb网关的硬件资源，以进行容量和稳定性的保障。

例如，当图1所示机房B内的应用C需要调用应用B时，应用C内的eureka client从eureka server2中获取到的也将是应用B的改写后的服务信息{1-1-1-1:8080.b.xxxx.lo,2-2-2-2:8080.b.xxxx.lo}，这就导致应用C也需要通过泛域名调用应用B，而在该种情况下，应用B的改写后的服务列表中的域名将解析到alb网关2，因此，应用C若通过应用B的改写后的服务列表调用应用B，则流量都会转发到alb网关2进行不必要的转发，从而会增大alb网关2的流量，导致需要在alb网关2上投入更多的物理资源以进行容量和稳定性的保障。

由此可知，相关技术中的该种应用调用方法一方面是存在流程复杂的问题，另一方面还需要额外耗费成本提升网关的硬件资源，否则则可能会影响系统稳定性。

为简化应用调用流程并提升系统稳定性，也可以考虑在进行跨机房应用调用时，使用域名式调用方法，即，直接将被调用应用的域名配置在调用应用中，这样，调用应用直接通过域名调用被调用应用。

例如，在图1所示的机房A内的应用A需要调用机房内的应用B时，可以将应用B的域名配置在应用A的配置文件内，应用A读取该配置文件得到应用B的域名，之后通过调用链路1：应用A请求应用B域名→应用B域名被解析到alb网关1，由alb网关1转发请求至alb网关2→alb网关2将请求转发至应用B，这样通过域名式调用的方式虽然可以实现应用之间的跨机房调用，但是，该域名调用方式同样导致同机房内的应用间调用将基于alb网关进行转发。例如，当机房A内的应用A需要调用同机房内的应用D(图中未示出)时，其同样需要从自身的配置文件内读取应用D的域名，之后通过调用链路2：应用A请求应用D域名→应用D域名被解析到alb网关1，由alb网关1转发请求至同机房内的应用D，这就导致同机房内的应用调用的流量同样需要基于alb网关进行转发，因此，其同样存在大幅提升alb网关的压力的问题。

当然，在该种实现方式中，也可以考虑针对跨机房的应用调用，使用域名调用方式进行调用，而针对同机房内调用，依然由应用从机房内的注册服务器中获取被调用应用的服务信息的方式进行服务化调用，然而，该种应用调用方法将大幅提升编码复杂性，不利于进行系统维护。

另外，在基于域名调用方式实现应用之间的跨机房调用时，由于并未采用服务化调用，这就导致被调用应用并不会在自身所处机房内的注册服务器以及调用应用所处机房内的注册服务器中注册自身的服务信息，从而导致调用应用无法方便地确定被调用应用是否处于服务可用状态，在该种情况下，调用应用在需要调用被调用应用时，只能盲目的发出调用请求，而如果被调用应用此处于服务不可用状态，例如，处于未启动或处于异常运行状态，则调用应用只能等待响应超时，因此，域名调用方式相较于服务化调用方式往往还存在不够方便、不利于系统维护等问题。

有鉴于此，在本公开实施例中，针对与第一应用处于不同机房的第二应用，位于第一应用所处的第一机房内的应用网关，即第一网关在接入第二应用时，可以通过对该第二应用进行代理注册，以将该第二应用的目标服务信息注册到位于该第一机房内的第一注册服务器中，这样，虽然第二应用在自身启动过程中并不会将自身的服务信息注册到第一机房内的第一注册服务器中，但是由于第一网关在接入第二应用时将该目标服务信息注册到了该第一注册服务器中，这就使得第一应用在需要调用该第二应用时，第一应用可以从该第一注册服务器中获取到由第一网关代理注册的该第二应用的目标服务信息，从而基于该目标服务信息以服务化调用方式生成调用请求，并将该调用请求发送至该第一网关，之后，由该第一网关将该调用请求发送至与第二应用所处第二机房对应的第二网关，并通过接收该第二网关发送的、由第二应用生成的响应消息，实现应用间的跨机房服务化调用。

由于只需要第一网关对处于第一机房外的第二应用提供代理注册，以将第二应用的目标服务信息注册到第一注册服务器中，不需要进行其他耗费硬件资源的额外处理，而针对同机房内的应用间的服务化调用，一方面可以由应用在启动过程中自行在同机房内的注册服务器中注册自身的服务信息，而不需要自身所处机房内的网关对其进行代理注册，例如，第一应用可以在启动过程中自行在第一注册服务器中注册自身的服务信息，而不需要第一网关对其进行代理注册；另一方面，针对同机房内的服务化调用，应用之间依然可以通过从同机房内的注册服务器中获取服务信息的方式直接进行应用与应用之间的调用，而不需要依赖于同机房内的网关对其调用请求进行转发，例如，第一应用在需要调用第一机房内的其他应用时，其可以直接从第一注册服务器中获取该其他应用在启动过程中在第一注册服务器中注册的服务信息，从而直接调用该其他应用，而不需要基于第一网关对其调用请求进行转发，因此，基于本公开不需要对第一机房和第二机房内的网关额外增加硬件资源，即可在不影响同机房内应用间的服务化调用的前提下，方便且稳定地实现应用间的跨机房服务化调用。

请参看图2，其为本公开实施例提供的应用调用方法的实施环境的示意图。如图2所示，该实施环境可以包括第一机房和第二机房，其中，第一机房内可以包括第一网关101、第一应用102、第一注册服务器103；第二机房内可以包括第二应用104、第二网关105以及第二注册服务器106；另外，该实施环境中还可以包括zookeeper集群107，该zookeeper集群107可以处于第一机房和/或第二机房内，或者也可以处于与部署于第一机房以及第二机房内的该些设备通信连接的其他机房内，此处不做特殊限定。

在本公开实施例中，该第一网关101以及第二网关102可以为alb网关，第一网关101可以用于对第一机房内的应用的请求进行负载均衡处理；该第二网关102可以用于对第二机房内的应用的请求进行负载均衡处理。

第一应用102以及第二应用104，可以为任意的服务化应用，例如，第一应用102可以为呼叫中心系统中用于进行语音识别处理的语音识别服务，该第二应用104可以为该呼叫中心系统中用于预测应答文本的文本应答服务。

可以理解的是，该第一应用102运行于第一机房的服务器中，该第二应用104运行于第二机房的服务器中；另外，如无特殊说明，在本公开实施例中，以第一应用102为调用应用，第二应用104为被调用应用，说明如何基于本公开实施例提供的应用调用方法实现应用间的跨机房服务化调用。

该第一注册服务器103和第二注册服务器106，可以用于分别对第一机房以及第二机房内的应用进行服务注册处理。该第一注册服务器103和该第二注册服务器105例如可以是基于eureka server实现的注册服务器，即服务注册中心。

可以理解的是，第一注册服务器103以及第二注册服务器106中的服务注册信息可以通过异步处理方式进行信息同步。

在本公开实施例中，该zookeeper集群107，可以至少用于存放应用与其所处的机房的信息，即，可以用于存储目标映射数据，该目标映射数据用于反映应用与机房间的对应关系，例如，可以以键值对<应用标识，机房标识>的形式存储应用与其所处机房之间的对应关系，例如，可以存储键值对1：<第一应用的应用标识1，第一机房的机房标识1>存储第一应用102与第一机房之间的所属关系，以及，存储键值对2：<第二应用的应用标识2，第二机房的机房标识2>存储第二应用104与第二机房之间的所属关系。

另外，本公开实施例中所述的服务器可以是物理服务器，例如可以为刀片服务器、机架式服务器等，或者也可以是虚拟服务器，例如可以是部署在云端的服务器集群，在此不做限定。

在本公开实施例中，第一网关101可以用于：接收第一应用102发送的调用请求，其中，该调用请求是由第一应用102基于目标服务信息生成的服务化调用请求；目标服务信息为在第一注册服务器103中对第二应用104进行代理注册后生成的信息，第一网关101和第一注册服务器103位于第一应用102所处的第一机房内；将调用请求发送至第二网关105，其中，第二网关105位于第二应用104所处的第二机房内，第二网关105用于将该调用请求转发至第二应用104，以及，接收第二应用104响应该调用请求生成的响应消息；接收第二网关105发送的响应消息，并将响应消息发送至第一应用102。

另外，在第一应用102为调用应用，第二应用104为被调用应用的情况下，该第一应用102可以用于：从第一注册服务器103中获取目标服务信息，其中，目标服务信息为第一网关101在第一注册服务器103中对第二应用104进行代理注册后生成的信息，第一网关101和第一注册服务器103位于第一应用102所处的第一机房内；根据目标服务信息，生成调用请求，并基于第一网关101将调用请求发送至第二网关105，其中，第二网关105位于第二应用104所处的第二机房内，第二网关105用于将调用请求转发至第二应用104，接收第二应用104响应调用请求生成的响应消息，以及将响应消息发送至第一网关101；接收第一网关101发送的响应消息。

需要说明的是，调用应用与被调用应用之间的关系可以是相对的，即，在第一应用102需要跨机房使用第二应用104提供的服务1的情况下，可以将第一应用102视为调用应用，将第二应用104视为被调用应用；而在第二应用104需要使用第一应用102提供的服务2的情况下，可以将第二应用104视为调用应用，将第一应用102视为被调用应用，在该种情况下，第二应用104可以基于第二网关105将调用请求发送至第一应用102，以及基于第二网关105接收第一应用102发送的响应消息。

可以理解的是，图2所示的实施环境仅是解释性的，并且决不是为了要限制本公开、其应用或用途。例如，尽管图2仅示出了第一机房和第二机房该两个机房，以及，在第一机房以及第二机房内仅示意了一个第一应用102、一个第二应用104、一个第一网关101以及一个第二网关105，但不意味着限制各自的数量，该实施环境中可以包含多个机房，以及每个机房内可以包括多个第一应用102，多个第二应用104以及多个第一网关101和多个第二网关105，此处不做特殊限定。

为了方便且稳定的实现应用间的跨机房服务化调用，本公开实施例提供一种应用调用方法，请参看图3，其为本公开实施例提供的一种应用调用方法的流程图。该方法可以应用于机房内用于对应用的请求进行负载均衡处理的网关中，例如可以应用于图2所示的第一网关101以及第二网关102中，此处不做特殊限定。

如图3所示，本公开实施例提供的该种应用调用方法包括如下步骤S301-S303，以下予以详细说明。

步骤S301，接收第一应用发送的调用请求，其中，调用请求是由第一应用基于目标服务信息生成的服务化调用请求；目标服务信息为在第一注册服务器中对第二应用进行代理注册后生成的信息，第一网关和第一注册服务器位于第一应用所处的第一机房内；

步骤S302，将调用请求发送至第二网关，其中，第二网关位于第二应用所处的第二机房内，第二网关用于将调用请求转发至第二应用，以及，接收第二应用响应调用请求生成的响应消息；

步骤S303，接收第二网关发送的响应消息，并将响应消息发送至第一应用。

在本公开实施例中，目标服务信息，是指处于第一应用所处第一机房内的第一网关在接入第二应用时，将该第二应用代理注册到第一机房内的第一注册服务器后生成的、该第二应用对应的服务列表中的信息，该目标服务信息中包含第二应用的注册地址信息，该注册地址信息可以为该第二应用的目标域名。

即，区别于本机房内的第一应用在自身注册服务器中进行注册时，其服务列表中的注册地址信息为自身IP地址的方式，处于其他机房内的第二应用在被接入第一网关中时，为了能够使得该第一机房内的第一应用可以以服务发现的方式从自身对应的第一注册服务器中获取该第二应用的服务信息，并且，也使得该网关可以基于该服务信息中的注册地址信息将针对该第二应用的调用请求转发至第二应用，本公开由第一网关对接入的第二应用所处的机房进行判断，若第二应用不是自身机房内的应用，则第一网关获取该第二应用的目标域名作为其注册地址信息将其代理注册到自身的第一注册服务器中，这样，一方面是第一网关自身所处第一机房内的第一应用可以通过第一注册服务器得到该第二应用的域名形式而非是ip形式的服务信息，进而可以以服务化调用方式生成调用请求以使用第二应用提供的服务，另一方面，当该调用请求发送至第一网关后，第一网关也可以通过解析调用请求中第二应用的域名，确定该第二应用对应的第二网关，从而通过将该调用请求发送至第二网关，以由该第二网关转发该调用请求至第二应用的方式，使得第二应用可以成功响应该调用请求。

以下以处于第一机房内的第一应用的应用标识为“应用D”，IP地址为“10.x.x.2:8080”，域名为“d.xxx.lo”，第一机房内的第一网关为“网关1”，第一注册服务器为“server1”，处于第二机房内的第二应用的应用标识为“应用F”，IP地址为“10.x.x.4.8080”，域名为“f.xxx.lo”,第二网关为“网关2”，第二注册服务器为“server2”为例，对该应用调用方法进行说明。

首先，可以在第一机房以及第二机房内分别部署应用D和应用F之后，将应用D和应用F的路由规则配置到网关1和网关2中，以将应用D和应用F分别接入网关1和网关2中，其中，应用的路由规则是指应用和应用对应域名以及后端转发地址的对应关系，例如，可以为应用标识、应用对应的IP地址以及域名的对应关系。

其次，针对网关1，当在网关1中配置应用D和应用F的路由规则之后，针对接入的该应用D和应用F，网关1从zookeeper集群中获取应用D和应用F所处机房的信息，判断应用D所处机房与自身所处机房是否一致，由于应用D与网关1所处机房匹配，即，两者一致，因此，网关1不对该应用D进行代理注册，而是由应用D在启动过程中基于自身集成的注册客户端，例如eureka client将自身的服务信息注册到第一机房内基于eureka server实现的第一注册服务器“server1”中，应用D在注册到server1后，其在server1的服务列表信息中的服务信息例如可以为{应用D，10.x.x.2:8080}，即其注册的地址信息为ip:port形式；之后，网关1判断应用F与自身所处机房是否一致，由于应用F处于第二机房内，与网关1所处机房不匹配，即，两者不一致，因此，为了能够方便且稳定地实现应用间的跨机房的服务化调用，本公开实施例中并不使用eureka拦截的方式进行应用调用处理，而是由网关1对该应用F进行代理注册，例如可以由网关1基于应用F的应用标识和域名，在第一注册服务器“server1”中进行注册，在该种方式中，应用F在注册到server1后，其在server1的服务列表信息中的目标服务信息例如可以为{应用F，f.xxx.lo}，或者也可以为{网关1，f.xxx.lo}。

相对应地，在网关2中，当其中配置应用D和应用F的路由规则之后，网关2从zookeeper集群中获取应用D和应用F所处机房的信息，分别判断应用D和应用F所处机房与自身所处机房是否一致，由于应用F与网关2所处机房匹配，应用D与网关2所处机房不匹配，因此，网关2不需要对应用F进行代理注册，而是由应用F在启动过程中将自身的服务信息{应用F，10.x.x.4.8080}注册到server2中，而由网关2对应用D进行代理注册到server2中，应用D在server2的服务列表信息中的服务信息可以为{应用D，d.xxx.lo}或者为{网关2，d.xxx.lo}。

再其次，在网关1以及网关2分别接入应用D和应用F之后，当应用D需要跨机房调用应用F提供的服务1时，应用D首先可以从自身对应的第一注册服务器“server1”中获取应用F的目标服务信息：{应用F，f.xxx.lo}或{网关1，f.xxx.lo}，之后，使用该目标服务信息中应用F对应的地址信息，即应用F的目标域名“f.xxx.lo”生成调用请求，并将该调用请求发送至网关1进行负载均衡处理；网关1接收到该调用请求之后，基于目标域名“f.xxx.lo”，根据其自身配置的应用F的路由规则确定是调用应用F，且应用F处于第二机房内，因此，网关1将该调用请求转发至第二机房内的网关2；网关2在接收到该调用请求之后，判断应用F处于自身所处机房内，因此直接将该调用请求转发至应用2进行响应。

最后，应用2响应于该调用请求，生成响应消息，并将该响应消息发送至网关2，网关2再转发该响应消息至网关1，以由网关1将该响应消息发送给应用D，从而完成应用D与应用F之间的跨机房的服务化调用。

当然，在实际实施时，当应用F需要调用应用D提供的服务2时，也可以通过类似原理实现跨机房的服务化调用，其详细处理此处不再赘述。

可见，基于本公开实施例提供的该种应用调用方法，针对与第一应用所处机房不同的第二应用，并不需要对第二应用设置eureka拦截，从而由各机房对应的网关在其分别对应的注册服务器中对该第二应用的服务列表进行改写处理，以在对该第二应用进行服务化调用时，由各机房对应的网关对拦截得到的针对该第二应用的服务化调用流量进行代理转发，而是通过由第一网关在第一注册服务器中对第二应用进行代理注册，在第一应用需要调用第二应用时，可以通过获取第一网关对该第二应用进行代理注册生成的目标服务信息，并基于该目标服务信息生成调用请求发送至第一网关进行转发处理，即可方便且稳定地实现应用间的跨机房服务化调用。

根据上述说明可知，在一些实施例中，在执行该步骤S301之前，该方法还包括针对第二应用的代理注册处理，在该种实施方式中，所述在第一注册服务器中对第二应用进行代理注册，可以包括：获取第二应用的目标域名，并基于目标域名在第一注册服务器中对第二应用进行代理注册。

即，在本公开实施例中，为了能够方便且稳定的实现应用间的跨机房的服务化调用，可以不需要对第二应用设置拦截，即设置eureka劫持，而是可以对各机房内的网关新增代理注册功能，由网关在接收到其他机房内的应用的接入请求后，基于该应用的目标域名对该应用进行代理注册，以将该应用注册到自身所处机房的注册服务器中，从而使得自身机房内的应用可以以服务发现的方式获取该应用的目标服务信息以对其进行服务化调用，同时，网关在接收到针对该应用的调用请求之后，也可以基于该目标域名，确定该应用所处的机房的机房标识，以将该调用请求转发至相应网关处，使得该应用可以响应该调用请求。而针对同机房内的服务化调用，由于同机房内网关在接入同机房内应用时，在判断该应用与其处于同一机房内的情况下并不会对该应用进行代理注册，而是由该应用在启动过程中自行在机房内的注册服务器中注册器服务信息，因此，基于本公开，同机房内的应用之间在进行服务化调用时，依然可以以服务发现的方式获取同机房内的应用在自身服务器中注册的ip:port形式的地址信息，从而直接进行应用间的调用，而不需要基于网关转发其调用请求，从而可以在不影响同机房内应用间的服务化调用的前提下，提升应用间跨机房的服务化调用的方便性和稳定性。

具体地，根据上述说明可知，在实际实施时，所述获取第二应用的目标域名，并基于目标域名在第一注册服务器中对第二应用进行代理注册，可以包括：接收第二应用的接入请求，其中，接入请求中包括目标域名；响应于接入请求，获取第一机房的第一机房标识，以及，获取第二机房的第二机房标识；在确定第一机房标识与第二机房标识不匹配的情况下，根据目标域名生成目标服务信息；通过在第一注册服务器中注册目标服务信息对第二应用进行代理注册。

在本公开实施例中，可以是从zookeeper集群中获取应用与机房间的对应关系，以确定应用所处机房的机房标识；当然，在实际实施时，也可以通过其他方式获取应用所处的机房的机房标识，此处不做特殊限定。

另外，根据上述说明还可知，在实际实施时，所述根据目标域名生成目标服务信息，可以包括：获取第一网关的第一网关标识；根据第一网关标识以及目标域名生成目标服务信息，目标服务信息包括第二应用在第一注册服务器中的注册标识和注册地址信息，注册标识为第一网关标识，注册地址信息为目标域名。

具体地，在本公开实施例中，为了运维方便，即，为了方便在对注册服务器中各应用的服务信息进行运维管理时，方便的确认应用的服务信息具体是由哪一网关真实注册的，以便于在出现故障的时候，可以对故障网关进行准确定位。在实际实施时，网关在对其他机房内的应用进行代理注册时，在注册服务器中的目标服务信息并不是反映该应用标识与其目标域名之间对应关系的数据，而是用于反映进行该代理注册的网关的网关标识与该应用的目标域名之间对应关系的数据。

例如，在上述说明中，网关1在将应用F代理注册到第一机房的第一注册服务器“server1”中时，其服务信息中的注册标识并不使用应用F的应用标识，而是使用网关1的网关标识作为注册标识，即，网关1对应用F进行代理注册时，应用F在server1中的服务信息为{网关1，f.xxx.lo}。

与上述实施例相对应，本公开实施例还提供另一种应用调用方法，请参看图4，其为本公开实施例提供的另一种应用调用方法的流程图。该方法可以应用于第一应用中，该第一应用例如可以为图2所示的第一应用102，当然，在实际实施时，该方法也可以应用于其他需要进行跨机房进行服务化调用的任意应用中，例如也可以应用于图2所示的第二应用104中，此处不做特殊限定。

如图4所示，本公开实施例提供的该种应用调用方法包括如下步骤S401-S403，以下予以详细说明。

步骤S401，从第一注册服务器中获取目标服务信息，其中，目标服务信息为第一网关在第一注册服务器中对第二应用进行代理注册后生成的信息，第一网关和第一注册服务器位于第一应用所处的第一机房内；

步骤S402，根据目标服务信息，生成调用请求，并基于第一网关将调用请求发送至第二网关，其中，第二网关位于第二应用所处的第二机房内，第二网关用于将调用请求转发至第二应用，接收第二应用响应调用请求生成的响应消息，以及将响应消息发送至第一网关；

步骤S403，接收第一网关发送的响应消息。

在一些实施例中，所述根据目标服务信息，生成调用请求，可以包括：从目标服务信息中，获取第二应用的注册地址信息，其中，注册地址信息为第二应用的目标域名；基于目标域名生成调用请求。

可见，基于本公开实施例提供的该种应用调用方法，在跨机房进行应用间的调用时，由于与第一应用处于不同机房内的第二应用被第一应用对应的第一网关将其目标服务信息代理注册到了第一注册服务器中，因此，第一应用可以基于服务发现的方式，例如，基于自身集成的eureka client中的方法函数DiscoveryClient方便且直接的得到第二应用的目标服务信息，进而可以根据该目标服务信息生成用于调用第二应用的调用请求，通过基于第一网关转发该调用请求至第二应用处进行响应，可以提升应用间跨机房进行服务器调用时的方便性和稳定性。

可以理解，本公开提及的上述各个方法实施例，在不违背原理逻辑的情况下，均可以彼此相互结合形成结合后的实施例，限于篇幅，本公开不再赘述。本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

此外，本公开还提供了应用调用装置、电子设备、计算机可读存储介质，上述均可以来实现本公开提供的任一种应用调用方法，相应技术方案和描述和参见方法部分的相应记载，不再赘述。

图5为本公开实施例提供的一种应用调用装置的框图。

参照图5，本公开实施例提供了一种应用调用装置，可以应用于第一网关中，该第一网关例如可以为图2所示的第一网关101，该应用调用装置500包括：第一接收单元501、发送单元502以及第二接收单元503。

该第一接收单元501，可以用于接收第一应用发送的调用请求，其中，调用请求是由第一应用基于目标服务信息生成的服务化调用请求；目标服务信息为在第一注册服务器中对第二应用进行代理注册后生成的信息，第一网关和第一注册服务器位于第一应用所处的第一机房内；

该发送单元502，可以用于将调用请求发送至第二网关，其中，第二网关位于第二应用所处的第二机房内，第二网关用于将调用请求转发至第二应用，以及，接收第二应用响应调用请求生成的响应消息；

该第二接收单元503，可以用于接收第二网关发送的响应消息，并将响应消息发送至第一应用。

在一些实施例中，该装置500还可以包括代理注册单元，该代理注册单元在第一注册服务器中对第二应用进行代理注册时，可以用于：获取第二应用的目标域名，并基于目标域名在第一注册服务器中对第二应用进行代理注册。

在一些实施例中，该代理注册单元获取第二应用的目标域名，并基于目标域名在第一注册服务器中对第二应用进行代理注册时，可以用于：接收第二应用的接入请求，其中，接入请求中包括目标域名；获取第一机房的第一机房标识，以及，获取第二机房的第二机房标识；在确定第一机房标识与第二机房标识不匹配的情况下，根据目标域名生成目标服务信息；通过在第一注册服务器中注册目标服务信息对第二应用进行代理注册。

在一些实施例中，该代理注册单元根据目标域名生成目标服务信息时，可以用于：获取第一网关的第一网关标识；根据第一网关标识以及目标域名生成目标服务信息，目标服务信息包括第二应用在第一注册服务器中的注册标识和注册地址信息，注册标识为第一网关标识，注册地址信息为目标域名。

可见，基于本公开实施例提供的该种应用调用装置，针对与第一应用处于不同机房的第二应用，位于第一应用所处的第一机房内的应用网关，即第一网关在接入第二应用时，可以通过对该第二应用进行代理注册，以将该第二应用的目标服务信息注册到位于该第一机房内的第一注册服务器中，这样，虽然第二应用在自身启动过程中并不会将自身的服务信息注册到第一机房内的第一注册服务器中，但是由于第一网关在接入第二应用时将该目标服务信息注册到了该第一注册服务器中，这就使得第一应用在需要调用该第二应用时，第一应用可以从该第一注册服务器中获取到由第一网关代理注册的该第二应用的目标服务信息，从而基于该目标服务信息以服务化调用方式生成调用请求，并将该调用请求发送至该第一网关，之后，由该第一网关将该调用请求发送至与第二应用所处第二机房对应的第二网关，并通过接收该第二网关发送的、由第二应用生成的响应消息，实现应用间的跨机房服务化调用，由于只需要第一网关对处于第一机房外的第二应用提供代理注册，以将第二应用的目标服务信息注册到第一注册服务器中，而不需要进行其他耗费硬件资源的额外处理，而针对同机房内的应用间的服务化调用，一方面可以由应用在启动过程中自行在同机房内的注册服务器中注册自身的服务信息，而不需要自身所处机房内的网关对其进行代理注册，例如，第一应用可以在启动过程中自行在第一注册服务器中注册自身的服务信息，而不需要第一网关对其进行代理注册；另一方面，针对同机房内的服务化调用，应用之间依然可以通过从同机房内的注册服务器中获取服务信息的方式直接进行应用与应用之间的调用，而不需要依赖于同机房内的网关对其调用请求进行转发，例如，第一应用在需要调用第一机房内的其他应用时，其可以直接从第一注册服务器中获取该其他应用在启动过程中在第一注册服务器中注册的服务信息，从而直接调用该其他应用，而不需要基于第一网关对其调用请求进行转发，因此，基于本公开不需要对第一机房和第二机房内的网关额外增加硬件资源，即可在不影响同机房内应用间的服务化调用的前提下，方便且稳定地实现应用间的跨机房服务化调用。

图6为本公开实施例提供的另一种应用调用装置的框图。

参照图6，本公开实施例提供了一种应用调用装置，可以应用于第一应用中，该第一应用例如可以为图2所示的第一应用102，该应用调用装置600包括：获取单元601、生成单元602以及第三接收单元603。

该获取单元601，用于从第一注册服务器中获取目标服务信息，其中，目标服务信息为第一网关在第一注册服务器中对第二应用进行代理注册后生成的信息，第一网关和第一注册服务器位于第一应用所处的第一机房内；

该生成单元602，用于根据目标服务信息，生成调用请求，并基于第一网关将调用请求发送至第二网关，其中，第二网关位于第二应用所处的第二机房内，第二网关用于将调用请求转发至第二应用，接收第二应用响应调用请求生成的响应消息，以及将响应消息发送至第一网关；

该第三接收单元603，用于接收第一网关发送的响应消息。

在一些实施例中，该生成单元602在根据目标服务信息，生成调用请求时，可以用于：从目标服务信息中，获取第二应用的注册地址信息，其中，注册地址信息为第二应用的目标域名；基于目标域名生成调用请求。

可见，基于本公开实施例提供的该种应用调用装置，在跨机房进行应用间的调用时，由于与第一应用处于不同机房内的第二应用被第一应用对应的第一网关将其目标服务信息代理注册到了第一注册服务器中，因此，第一应用可以基于服务发现的方式，例如，基于自身集成的eureka client中的方法函数DiscoveryClient方便且直接的得到第二应用的目标服务信息，进而可以根据该目标服务信息生成用于调用第二应用的调用请求，通过基于第一网关转发该调用请求至第二应用处进行响应，可以提升应用间跨机房进行服务器调用时的方便性和稳定性。

图7为本公开实施例提供的一种电子设备的框图。

参照图7，本公开实施例提供了一种电子设备，该电子设备700包括：至少一个处理器701；至少一个存储器702，以及一个或多个I/O接口703，连接在处理器701与存储器702之间；其中，存储器702存储有可被至少一个处理器701执行的一个或多个计算机程序，一个或多个计算机程序被至少一个处理器701执行，以使至少一个处理器701能够执行上述的应用调用方法。

上述电子设备中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

本公开实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，其中，所述计算机程序在被处理器执行时实现上述的应用调用方法。计算机可读存储介质可以是易失性或非易失性计算机可读存储介质。

本公开实施例还提供了一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当计算机可读代码在电子设备的处理器中运行时，电子设备中的处理器执行上述的应用调用方法。

在一些实施例中，该电子设备中的处理器可以用于执行上述的一种应用调用方法，即，可以用于：接收第一应用发送的调用请求，其中，调用请求是由第一应用基于目标服务信息生成的服务化调用请求；目标服务信息为在第一注册服务器中对第二应用进行代理注册后生成的信息，第一网关和第一注册服务器位于第一应用所处的第一机房内；将调用请求发送至第二网关，其中，第二网关位于第二应用所处的第二机房内，第二网关用于将调用请求转发至第二应用，以及，接收第二应用响应调用请求生成的响应消息；接收第二网关发送的响应消息，并将响应消息发送至第一应用。

在一些实施例中，该电子设备中的处理器在第一注册服务器中对第二应用进行代理注册时，可以用于：获取第二应用的目标域名，并基于目标域名在第一注册服务器中对第二应用进行代理注册。

在一些实施例中，该电子设备中的处理器在获取第二应用的目标域名，并基于目标域名在第一注册服务器中对第二应用进行代理注册时，可以用于：接收第二应用的接入请求，其中，接入请求中包括目标域名；响应于接入请求，获取第一机房的第一机房标识，以及，获取第二机房的第二机房标识；在确定第一机房标识与第二机房标识不匹配的情况下，根据目标域名生成目标服务信息；通过在第一注册服务器中注册目标服务信息对第二应用进行代理注册。

在一些实施例中，该电子设备中的处理器在根据目标域名生成目标服务信息时，可以用于：获取第一网关的第一网关标识；根据第一网关标识以及目标域名生成目标服务信息，目标服务信息包括第二应用在第一注册服务器中的注册标识和注册地址信息，注册标识为第一网关标识，注册地址信息为目标域名。

在一些实施例中，该电子设备中的处理器可以用于执行上述的另一种应用调用方法，即，可以用于：从第一注册服务器中获取目标服务信息，其中，目标服务信息为第一网关在第一注册服务器中对第二应用进行代理注册后生成的信息，第一网关和第一注册服务器位于第一应用所处的第一机房内；根据目标服务信息，生成调用请求，并基于第一网关将调用请求发送至第二网关，其中，第二网关位于第二应用所处的第二机房内，第二网关用于将调用请求转发至第二应用，接收第二应用响应调用请求生成的响应消息，以及将响应消息发送至第一网关；接收第一网关发送的响应消息。

在一些实施例中，该电子设备中的处理器在根据目标服务信息，生成调用请求时，可以用于：从目标服务信息中，获取第二应用的注册地址信息，其中，注册地址信息为第二应用的目标域名；基于目标域名生成调用请求。

可见，基于本公开实施例提供的计算机程序产品，使得电子设备中的处理器可以通过第一网关在第一注册服务器中对第二应用进行代理注册，在第一应用需要调用第二应用时，可以通过获取第一网关对该第二应用进行代理注册生成的目标服务信息，并基于该目标服务信息生成调用请求发送至第一网关进行转发处理，即可在不需要增加各网关的硬件资源的前提下方便且稳定地实现应用间的跨机房服务化调用。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读存储介质上，计算机可读存储介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。

如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读程序指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM)、静态随机存取存储器(SRAM)、闪存或其他存储器技术、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读程序指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

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

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

这里所描述的计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software DevelopmentKit，SDK)等等。

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

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

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

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

本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其他实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。

Claims (10)

1.一种应用调用方法，其特征在于，应用于第一网关，所述方法包括：

接收第一应用发送的调用请求，其中，所述调用请求是由所述第一应用基于目标服务信息生成的服务化调用请求；所述目标服务信息为在第一注册服务器中对第二应用进行代理注册后生成的信息，所述第一网关和所述第一注册服务器位于所述第一应用所处的第一机房内；

将所述调用请求发送至第二网关，其中，所述第二网关位于所述第二应用所处的第二机房内，所述第二网关用于将所述调用请求转发至所述第二应用，以及，接收所述第二应用响应所述调用请求生成的响应消息；

接收所述第二网关发送的所述响应消息，并将所述响应消息发送至所述第一应用。

2.根据权利要求1所述的方法，其特征在于，所述在第一注册服务器中对所述第二应用进行代理注册，包括：

获取所述第二应用的目标域名，并基于所述目标域名在所述第一注册服务器中对所述第二应用进行代理注册。

3.根据权利要求2所述的方法，其特征在于，所述获取所述第二应用的目标域名，并基于所述目标域名在所述第一注册服务器中对所述第二应用进行代理注册，包括：

接收所述第二应用的接入请求，其中，所述接入请求中包括所述目标域名；

响应于所述接入请求，获取所述第一机房的第一机房标识，以及，获取所述第二机房的第二机房标识；

在确定所述第一机房标识与所述第二机房标识不匹配的情况下，根据所述目标域名生成所述目标服务信息；

通过在所述第一注册服务器中注册所述目标服务信息对所述第二应用进行代理注册。

4.根据权利要求3所述的方法，其特征在于，所述根据所述目标域名生成所述目标服务信息，包括：

获取所述第一网关的第一网关标识；

根据所述第一网关标识以及所述目标域名生成所述目标服务信息，所述目标服务信息包括所述第二应用在所述第一注册服务器中的注册标识和注册地址信息，所述注册标识为所述第一网关标识，所述注册地址信息为所述目标域名。

5.一种应用调用方法，其特征在于，应用于第一应用，所述方法包括：

从第一注册服务器中获取目标服务信息，其中，所述目标服务信息为第一网关在所述第一注册服务器中对第二应用进行代理注册后生成的信息，所述第一网关和所述第一注册服务器位于所述第一应用所处的第一机房内；

根据所述目标服务信息，生成调用请求，并基于所述第一网关将所述调用请求发送至第二网关，其中，所述第二网关位于所述第二应用所处的第二机房内，所述第二网关用于将所述调用请求转发至所述第二应用，接收所述第二应用响应所述调用请求生成的响应消息，以及将所述响应消息发送至所述第一网关；

接收所述第一网关发送的所述响应消息。

6.根据权利要求5所述的方法，其特征在于，所述根据所述目标服务信息，生成调用请求，包括：

从所述目标服务信息中，获取所述第二应用的注册地址信息，其中，所述注册地址信息为所述第二应用的目标域名；

基于所述目标域名生成所述调用请求。

7.一种应用调用装置，其特征在于，应用于第一网关，所述装置包括：

第一接收单元，用于接收第一应用发送的调用请求，其中，所述调用请求是由所述第一应用基于目标服务信息生成的服务化调用请求；所述目标服务信息为在第一注册服务器中对第二应用进行代理注册后生成的信息，所述第一网关和所述第一注册服务器位于所述第一应用所处的第一机房内；

发送单元，用于将所述调用请求发送至第二网关，其中，所述第二网关位于所述第二应用所处的第二机房内，所述第二网关用于将所述调用请求转发至所述第二应用，以及，接收所述第二应用响应所述调用请求生成的响应消息；

第二接收单元，用于接收所述第二网关发送的所述响应消息，并将所述响应消息发送至所述第一应用。

8.一种应用调用装置，其特征在于，应用于第一应用，所述装置包括：

获取单元，用于从第一注册服务器中获取目标服务信息，其中，所述目标服务信息为第一网关在所述第一注册服务器中对第二应用进行代理注册后生成的信息，所述第一网关和所述第一注册服务器位于所述第一应用所处的第一机房内；

生成单元，用于根据所述目标服务信息，生成调用请求，并基于所述第一网关将所述调用请求发送至第二网关，其中，所述第二网关位于所述第二应用所处的第二机房内，所述第二网关用于将所述调用请求转发至所述第二应用，接收所述第二应用响应所述调用请求生成的响应消息，以及将所述响应消息发送至所述第一网关；

第三接收单元，用于接收所述第一网关发送的所述响应消息。

9.一种电子设备，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的一个或多个计算机程序，一个或多个所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-6中任一项所述的应用调用方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序在被处理器执行时实现如权利要求1-6中任一项所述的应用调用方法。