CN108696551A - ***进程间请求寻址的方法和装置 - Google Patents

Abstract

本发明公开了一种***进程间请求寻址的方法和装置，该方法包括：服务消费者主机接收针对预定服务的服务信息查询请求；服务消费者主机根据服务信息查询请求通过预定协议向服务注册中心请求获取预定服务的服务信息，其中，服务信息查询请求包括：服务名称和服务版本号；服务信息包括：服务IP地址；服务消费者主机接收服务注册中心返回的服务信息，并存储在本地缓存中；服务消费者主机根据服务信息向预定服务对应的服务提供者主机发送服务获取请求，以获取预定服务。本发明过程调用时间较短，过程较为简单，解决了如下问题：无论是客户端发现模式还是服务端发现模式，分布式架构中的进程间请求寻址方式的服务调用时间较长、***性能较低。

Description

***进程间请求寻址的方法和装置

技术领域

本发明涉及通讯领域，特别是涉及一种***进程间请求寻址的方法和装置。

背景技术

目前，在分布式架构中，进程间请求寻址有两种方式：

第一种方式为客户端发现模式，如图1所示，客户端负责决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端从一个服务注册服务中查询，其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择出一个，然后发出请求。

该方式需要针对客户端所采用的开发语言，订制专门的客户端的SDK(软件开发工具包)，增加了客户端代码与进程间请求寻址代码的耦合，增加了维护和开发的成本；并且由于服务消费者需要向服务注册中心查询注册信息，该过程通过网络查询，会影响请求发送效率；同时会导致服务注册中心服务访问压力过大。

第二种方式为服务端发现模式，如图2所示，客户端通过负载均衡器(位于服务网关内)向某个服务网关提出请求，再向服务注册中心发出请求，最后将每个请求转发往可用的服务实例。

该方式由于每次客户端的请求对会经过负载均衡器，这样负载均衡器将是一个单点，如果负载均衡器出现问题，将导致这个***不可用；并且，由于需要经过一次负载均衡器的转发，将会增加服务调用的耗时，影响***的性能。

因此，无论是客户端发现模式还是服务端发现模式，分布式架构中的进程间请求寻址方式都存在服务调用时间较长、***性能较低等问题。

发明内容

本发明提供一种***进程间请求寻址的方法和装置，用以解决现有技术的如下问题：无论是客户端发现模式还是服务端发现模式，分布式架构中的进程间请求寻址方式的服务调用时间较长、***性能较低。

为解决上述技术问题，一方面，本发明提供一种***进程间请求寻址的方法，包括：服务消费者主机接收针对预定服务的服务信息查询请求；所述服务消费者主机根据所述服务信息查询请求通过预定协议向服务注册中心请求获取所述预定服务的服务信息，其中，所述服务信息查询请求包括：服务名称和服务版本号；所述服务信息包括：服务IP地址；所述服务消费者主机接收所述服务注册中心返回的所述服务信息，并存储在本地缓存中；所述服务消费者主机根据所述服务信息向所述预定服务对应的服务提供者主机发送服务获取请求，以获取所述预定服务。

可选的，服务消费者主机接收针对预定服务的服务信息查询请求之后，还包括：所述服务消费者主机检测所述本地缓存中是否存在所述服务信息查询请求对应的服务信息；如果是，则所述服务消费者主机获取所述本地缓存中的服务信息；如果不是，则所述服务消费者主机根据所述服务信息查询请求通过预定协议向服务注册中心请求获取所述预定服务的服务信息。

可选的，所述服务消费者主机接收所述服务注册中心返回的所述服务信息并存储在本地缓存中之后，包括：所述服务消费者主机将DNS协议中的生存时间TTL属性由第一时长修改为第二时长，其中，所述第二时长小于所述第一时长。

可选的，所述服务消费者主机根据所述服务信息查询请求通过预定协议向服务注册中心请求获取所述预定服务的服务信息之后，还包括：所述服务消费者主机向所述服务注册中心发送服务监听请求，其中，所述服务监听请求用于请求接收服务信息变更信息；所述方法还包括：在所述服务注册中心的服务信息与所述服务消费者主机的服务信息不相同时，所述服务消费者主机接收所述服务注册中心发送的新的服务信息。

另一方面，本发明还提供一种***进程间请求寻址的方法，包括：服务提供者主机在本地文件中写入预定服务的服务信息，其中，所述服务信息包括：服务名称、服务版本号和服务IP地址；所述服务提供者主机读取所述本地文件中存储的服务信息，并将所述服务信息发送至服务注册中心，以在所述服务注册中心存储服务消费者主机通过预定协议查询的服务信息。

可选的，还包括：所述服务提供者主机按照预定时间间隔判断所述本地文件中存储的所述服务信息是否发生变化；在发生变化的情况下，所述服务提供者主机再次读取所述本地文件中的服务信息。

另一方面，本发明还提供一种***进程间请求寻址的装置，设置在服务消费者主机侧，包括：第一接收模块，用于接收针对预定服务的服务信息查询请求；获取模块，用于根据所述服务信息查询请求通过预定协议向服务注册中心请求获取所述预定服务的服务信息，其中，所述服务信息查询请求包括：服务名称和服务版本号；所述服务信息包括：服务IP地址；第二接收模块，用于接收所述服务注册中心返回的所述服务信息，并存储在本地缓存中；发送模块，用于根据所述服务信息向所述预定服务对应的服务提供者主机发送服务获取请求，以获取所述预定服务。

可选的，还包括：检测模块，用于检测所述本地缓存中是否存在所述服务信息查询请求对应的服务信息；所述获取模块，还用于在存在所述服务信息查询请求对应的服务信息的情况下，获取所述本地缓存中的服务信息；在不存在所述服务信息查询请求对应的服务信息的情况下，根据所述服务信息查询请求通过预定协议向服务注册中心请求获取所述预定服务的服务信息。

可选的，还包括：设置模块，用于在将所述服务信息存储在本地缓存中之后，将DNS协议中的生存时间TTL属性由第一时长修改为第二时长，其中，所述第二时长小于所述第一时长。

可选的，还包括：请求监听模块，在通过预定协议向服务注册中心请求获取所述预定服务的服务信息之后，向所述服务注册中心发送服务监听请求，其中，所述服务监听请求用于请求接收服务信息变更信息；所述第二接收模块，还用于在所述服务注册中心的服务信息与所述服务消费者主机的服务信息不相同时，接收所述服务注册中心发送的新的服务信息。

另一方面，本发明还提供一种***进程间请求寻址的装置，设置在服务提供者主机侧，包括：写入模块，用于在本地文件中写入预定服务的服务信息，其中，所述服务信息包括：服务名称、服务版本号和服务IP地址；执行模块，用于读取所述本地文件中存储的服务信息，并将所述服务信息发送至服务注册中心，以在所述服务注册中心存储服务消费者主机通过预定协议查询的服务信息。

可选的，还包括：判断模块，用于按照预定时间间隔判断所述本地文件中存储的所述服务信息是否发生变化；所述执行模块，还用于在发生变化的情况下，再次读取所述本地文件中的服务信息。

本发明服务消费者主机接收消费者发出的针对预定服务的服务信息查询请求，随后，针对该请求，通过预定协议向服务注册中心请求服务信息，再根据服务注册中心返回的服务信息来获取预定服务，由于本地缓存中也存储了预定服务对应的服务信息，当服务消费者主机再次使用该预定服务时，直接从本地缓存中获取即可，整个过程调用时间较短，过程较为简单，***性能较好，解决了现有技术的如下问题：无论是客户端发现模式还是服务端发现模式，分布式架构中的进程间请求寻址方式的服务调用时间较长、***性能较低。

附图说明

图1是现有技术中客户端发现模式架构图；

图2是现有技术中服务端发现模式架构图；

图3是本发明第一实施例中***进程间请求寻址的方法的流程图；

图4是本发明第二实施例中***进程间请求寻址的方法的流程图；

图5是本发明第三实施例中***进程间请求寻址的装置的结构示意图；

图6是本发明第四实施例中***进程间请求寻址的装置的结构示意图；

图7是本发明第五实施例中各组件设置示意图；

图8是本发明实施例中服务注册组件收集服务提供方所提供的服务信息的时序图；

图9是本发明实施例中服务消费者使用DNS协议查询服务提供方信息的时序图；

图10是本发明实施例中服务注册信息变化时通知服务消费者的时序图。

具体实施方式

为了解决现有技术的如下问题：无论是客户端发现模式还是服务端发现模式，分布式架构中的进程间请求寻址方式的服务调用时间较长、***性能较低；本发明提供了一种***进程间请求寻址的方法和装置，以下结合附图以及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。

本发明第一实施例提供了一种***进程间请求寻址的方法，该方法应用在服务消费者主机，其流程如图3所示，包括步骤S302至S308：

S302，服务消费者主机接收针对预定服务的服务信息查询请求；

S304，服务消费者主机根据服务信息查询请求通过预定协议向服务注册中心请求获取预定服务的服务信息，其中，服务信息查询请求包括：服务名称和服务版本号；所述服务信息包括：服务IP地址；

S306，服务消费者主机接收服务注册中心返回的服务信息，并存储在本地缓存中；

S308，服务消费者主机根据服务信息向预定服务对应的服务提供者主机发送服务获取请求，以获取预定服务。

本发明实施例服务消费者主机接收消费者发出的针对预定服务的服务信息查询请求，随后，针对该请求，通过预定协议向服务注册中心请求服务信息，再根据服务注册中心返回的服务信息来获取预定服务，由于本地缓存中也存储了预定服务对应的服务信息，当服务消费者主机再次使用该预定服务时，直接从本地缓存中获取即可，整个过程调用时间较短，过程较为简单，***性能较好，解决了现有技术的如下问题：无论是客户端发现模式还是服务端发现模式，分布式架构中的进程间请求寻址方式的服务调用时间较长、***性能较低。

由于上述S306将获取到的预定服务对应的服务信息缓存在了本地，因此，当服务消费者主机再次针对预定服务的服务信息查询请求时，其请求的预定服务对应的服务信息极有可能存在本地缓存中，因此，在服务消费者主机接收针对预定服务的服务信息查询请求之后，服务消费者主机还可以检测本地缓存中是否存在服务信息查询请求对应的服务信息。

如果存在，则服务消费者主机获取本地缓存中的服务信息，并直接根据该服务信息执行S308的过程即可，如果不存在，则服务消费者主机执行步骤S306，即根据服务信息查询请求通过预定协议向服务注册中心请求获取预定服务的服务信息。实现时，该预定协议可以是DNS协议。

在本地缓存中保存了预定服务的服务信息时，如果服务注册中心对该预定服务的服务信息进行了更新，而服务消费者主机的缓存中却还是原来的服务信息，则就会导致服务消费者主机会使用过期的服务信息来获取预定服务。

因此，本发明实施例在服务消费者主机接收服务注册中心返回的服务信息并存储在本地缓存中之后，服务消费者主机会将DNS协议中的TTL属性由第一时长修改为小于第一时长第二时长，这样，当第二时长设置的较为小时，就能够及时从服务注册中心获取到最新的服务信息，从而避免了服务消费者主机使用过期的服务信息来获取预定服务，用户体验较好。

为了进一步确定预定服务的服务信息在本地缓存中是最新的版本，因此，在服务消费者主机根据服务信息查询请求通过预定协议向服务注册中心请求获取预定服务的服务信息之后，可以向服务注册中心发送服务监听请求，以通过服务监听请求来监测服务信息的变更信息。在这种情况下，当服务注册中心发现其内部的服务信息版本与其之间发送给服务消费者主机的服务信息不相同时，就向服务消费者主机发送新的新的服务信息，以保证服务消费者主机本地缓存中的服务信息是最新版本的，进一步优化***性能。

本发明第二实施例提供了一种***进程间请求寻址的方法，该方法应用在服务提供者主机，其流程如图4所示，包括步骤S402至S404：

S402，服务提供者主机在本地文件中写入预定服务的服务信息，其中，服务信息包括：服务名称、服务版本号和服务IP地址；

S404，服务提供者主机读取本地文件中存储的服务信息，并将服务信息发送至服务注册中心，以在服务注册中心存储服务消费者主机通过预定协议查询的服务信息。

对于服务注册中心，其想当是不同服务的集群，在服务注册中心保存着各种可能被服务消费者主机调用的服务。

本发明实施例服务提供者主机将原有将预定服务直接注册到服务注册中心的流程进行了改变，将预定服务写到本地文件中，并写入其对应的服务信息，再将写入的预定服务对应的服务信息发送到服务注册中心，这样，就完成在在服务注册中心的注册，且服务注册中心还保存了预定服务的服务信息，以供后续消费者服务主机通过预定协议获取预定服务时使用，其中，该预定协议可以是DNS协议。

由于服务提供者主机会对提供的预定服务进行更新，因此，服务提供者主机要按照预定时间间隔判断本地文件中存储的服务信息是否发生变化。在设置时，预定时间间隔尽量设置的短一些，这样更容易发现服务信息的变化。

在预定服务的服务信息发生变化的情况下，服务提供者主机再次读取本地文件中的服务信息，并将更新的服务信息发送至服务注册中心。

本发明第三实施例提供了一种***进程间请求寻址的装置，其设置在服务消费者主机侧，该装置的结构示意如图5所示，包括：

第一接收模块10，用于接收针对预定服务的服务信息查询请求；获取模块11，与第一接收模块10耦合，用于根据服务信息查询请求通过预定协议向服务注册中心请求获取预定服务的服务信息，其中，服务信息查询请求包括：服务名称和服务版本号；所述服务信息包括：服务IP地址；第二接收模块12，与获取模块11耦合，用于接收服务注册中心返回的服务信息，并存储在本地缓存中；发送模块13，与第二接收模块12耦合，用于根据服务信息向预定服务对应的服务提供者主机发送服务获取请求，以获取预定服务。

本发明实施例的上述装置在设置时，可以以一个软件或组件的形式存在在服务消费者主机中，当消费者在主机界面申请预定服务时，通过预定协议来发出请求，后台的上述装置就根据预定协议来查询预定服务的服务信息，该过程中，第一接收模块10和获取模块11工作。

在第二接收模块12接收到服务信息时，将该服务信息保存在本地缓存中，以为下次服务消费者申请同样的预定服务做准备。随后，发送模块13工作，根据得到的服务信息来获取对应的预定服务。

上述装置还可以包括：检测模块，与第一接收模块和获取模块耦合，用于检测本地缓存中是否存在服务信息查询请求对应的服务信息；获取模块，还用于在存在服务信息查询请求对应的服务信息的情况下，获取本地缓存中的服务信息；在不存在服务信息查询请求对应的服务信息的情况下，根据服务信息查询请求通过预定协议向服务注册中心请求获取预定服务的服务信息。

在本地缓存中保存了预定服务的服务信息时，如果服务注册中心对该预定服务的服务信息进行了更新，而服务消费者主机的缓存中却还是原来的服务信息，则就会导致服务消费者主机会使用过期的服务信息来获取预定服务。

因此，本发明实施例的上述装置还可以包括：设置模块，与第二接收模块耦合，用于在将服务信息存储在本地缓存中之后，将DNS协议中的生存时间TTL属性由第一时长修改为第二时长，其中，第二时长小于第一时长。

为了进一步确定预定服务的服务信息在本地缓存中是最新的版本，本发明实施例的上述装置还可以包括：请求监听模块，与获取模块和第二接收模块耦合，在通过预定协议向服务注册中心请求获取预定服务的服务信息之后，向服务注册中心发送服务监听请求，其中，服务监听请求用于请求接收服务信息变更信息；第二接收模块，还用于在服务注册中心的服务信息与服务消费者主机的服务信息不相同时，接收服务注册中心发送的新的服务信息。

本发明第四实施例提供了一种***进程间请求寻址的装置，设置在服务提供者主机侧，该装置的结构示意如图6所示，包括：

写入模块20，用于在本地文件中写入预定服务的服务信息，其中，服务信息包括：服务名称、服务版本号和服务IP地址；执行模块21，与写入模块20耦合，用于读取本地文件中存储的服务信息，并将服务信息发送至服务注册中心，以在服务注册中心存储服务消费者主机通过预定协议查询的服务信息。

本发明实施例的上述装置在设置时，可以以一个软件或组件的形式存在在服务提供者主机中，当服务提供者要为服务消费者提供服务时，则将其想要提供的服务通过写入模块20写入本地文件中，并标明其服务信息。当写入后，再通过执行模块21来读取写好的服务信息，并将其注册到服务注册中心，这样，就完成在在服务注册中心的注册，且服务注册中心还保存了预定服务的服务信息，以供后续消费者服务主机通过预定协议获取预定服务时使用。

由于服务提供者主机会对提供的预定服务进行更新，因此，本发明实施例上述装置还可以包括：判断模块，与写入模块和执行模块耦合，用于按照预定时间间隔判断本地文件中存储的服务信息是否发生变化；执行模块，还用于在发生变化的情况下，再次读取本地文件中的服务信息。

本发明第五实施例提供了一种在分布式***进程间请求寻址的方法，该方法利用DNS协议寻找目标进程IP地址，并且克服由于DNS缓存所造成的服务信息更新不及时和DNS单点查询的压力的问题，尤其涉及在PAAS(平台即服务)平台上；当采用微服务架构时，解决微服务进程之间如何相互协作的问题。

DNS(域名***，Domain Name System)是一种组织成域层次结构的计算机和网络服务命名***，它用于TCP(传输控制协议，Transmission Control Protocol)/IP(网络之间互连的协议，Internet Protocol)网络，它所提供的服务是用来将主机名和域名转换为IP地址的工作。

DNS查询以各种不同的方式进行解析。客户机有时也可通过使用从以前查询获得的缓存信息就地应答查询，则DNS服务器可使用其自身的资源记录信息缓存来应答查询，也可代表请求客户机来查询或联系其他DNS服务器，以完全解析该名称，并随后将应答返回至客户机，这个过程称为递归。

但是由于DNS协议在制定时，为了降低对DNS服务器的访问压力，会将DNS条目在客户端进行缓存，然而在分布式环境中，特别是PAAS的环境中，提供服务的目标进程的IP地址一般会随着服务进程的重启而发生变化。

现有阶段，在各种主流的操作***中都已经默认实现了DNS协议栈，主流的开发语言也都支持通过DNS查询的方式，来获取目标服务的IP地址信息；而在分布式***中，由于会存在使用各种开发语言开发的进程，所以采用DNS协议来完成目标服务地址的查询，具有很强的适用性。

因此，在本实施例中将针对这个问题提供一种既能使服务调用者快速感知服务提供者IP的变化，又能保证不会发生高频率的访问DNS服务器查询信息，而对整个DNS查询***造成冲击，导致其运行不稳定的情况发生。

在分布式架构中，如果服务提供者所在的进程在新的主机上重启，其IP地址会发生变化，而本发明实施例的目的是：解决在服务IP地址变化后，服务调用者能快速感知到这个变化，并且保证进程间通信的高效，***运行的稳定，而且能尽量支持各种开发语言开发的程序，都能使用此方法来进行服务寻址。因此，本发明实施例的分布式***进程间请求寻址的方法如下，该方法通过三个组件实现，即服务注册组件、服务信息注册中心组件和服务查询组件，其设置示意如图7所示，下面分别对其进行说明。

(1)服务注册组件，设置在服务提供者主机侧。

服务注册组件运行在服务提供方所在主机，监听服务提供者进程所提供的服务，服务注册组件要求服务提供者进程在发布服务时，将服务的信息写到一个本地文件中，这样服务注册组件就能通过文件内容的变化，感知到服务提供进程所提供的服务信息。

此组件能产生的效果如下：采用单独进程运行，不会影响到服务提供者运行，可以实现故障隔离；使用文件进行注册信息的交互，不需要使用单独的SDK，具有很强的使用性，可以支持各种开发语言开发的程序。

(2)服务信息注册中心组件，设置在服务注册中心。

服务信息注册中心组件是用于集中存储服务信息的组件，采用集群模式，服务注册组件在收集到所监控进程提供的服务的信息后，会将信息发送到服务信息注册中心进行保存。

此组件能产生的效果如下：减小消费者端存储全部信息的压力；能快速更新服务状态，并能实现将变更及时通知到消费者端的功能。

(3)服务查询组件，设置在服务消费者主机侧。

服务查询组件和服务调用者(即服务消费者)在相同主机，服务调用者可以通过DNS协议与服务查询组件交互，获取服务提供者所注册的服务信息。为了与操作***和开发语言默认的DNS协议交互，这些只会采用DNS A记录(只支持通过域名获取IP地址)，因为在微服务架构中，微服务进程重启时，一般微服务所在主机(虚拟机)的IP地址会改变，但其服务端口基本是改变的，所以使用DNS A记录的格式就能满足需求，并且有最大的适应性。

此组件能产生的效果如下：使用DNS协议与服务消费者交互，不需要使用单独的SDK，具有很强的使用性，可以支持各种开发语言开发的程序；与服务消费者部署在相同主机上，查询请求不通过网络传输，查询性能高；使用自身缓存的信息，应答相关请求，能减少与服务信息注册中心组件的交互频率，利于保证服务信息注册中心组件的稳定运行；只缓存本服务消费者所需要的服务信息，消耗***资源少。

上述方法的大体步骤如下：

第一步：服务注册组件收集服务提供方所提供的服务信息。

第二步：服务消费者使用DNS协议查询服务提供方信息。

第三步：服务信息改变后，变更信息通知到服务使用者。

下面，针对每一个大步骤细化其实现流程。

第一步又可以包括：

(1)：服务注册组件作为一个后台进程启动，开始监听一个指定的本地文件内容是否有变化。

(2)：服务提供者进程启动完成后，将其所能提供的服务信息(服务名和服务版本号)写入到服务注册组件监听的文件中，并且会周期性的写入，更新相关的时间戳，起到心跳的作用。

(3)：服务注册组件在感知到文件的内容发生变化后，会上报服务信息到服务注册中心。

第二步又可以包括：

(1)：服务消费者所在主机的DNS服务器地址配置为127.0.0.1，本领域技术人员知晓，该地址为与DNS服务器交互的地址。

(2)：服务消费者使用服务名和端口创建网络连接，由于使用的是服务名作为域名，会触发服务消费者进程使用DNS协议，向服务查询组件查询对应的IP地址。

(3)：如果是第一次查询，服务查询组件则会向服务注册中心查询服务的相关信息，查询到服务对应的IP地址后，返回给服务消费者，并且在服务注册中心注册监听，如果此服务提供信息发生变化，主动通知服务查询组件。

(4)：如果不是第一次查询，则服务查询组件已经缓存了服务提供者的IP信息，则直接返回给服务消费者。

(5)：如果查询不到信息服务的IP地址，则返回错误。

(6)：在返回给服务消息者信息时，会将DNS的TTL属性设置为1秒，这样服务消费者进程就不会长时间的持有服务信息的缓存条目，就可以让服务消息者快速感知服务提供者的变化。

第三步又可以包括：

(1)：服务注册组件收集到新的服务注册信息后，将注册信息上报到服务注册中心。

(2)：服务注册中心根据服务的注册名，获取对这个服务信息关注的服务查询组件的列表。

(3)：按照上步获取的列表，将新的服务注册信息下发到服务查询组件。

采用本发明实施例提供的上述方法，与现有技术相比，有以下的好处：

对服务提供方和服务消费方所采用的开发语言没有限制；服务消费者通过本机服务查询组件，使用DNS协议查询服务信息，由于没有网络传输的步骤，效率很高；DNS的TTL设置为1秒，能保证消费者能快速感知到服务提供者的信息的变化；每个服务消费者从本机服务查询组件查询信息，查询压力分散在各个主机上，不会导致服务注册中心的查询压力过高。

本发明的关键点在与通过DNS来作为服务查询协议，同时将查询压力分担到了多个主机上，避免了过多的查询压力，导致服务注册中心宕机，同时也减少了在查询服务信息时的耗时，提高了***的性能。下面，结合附图对上述过程继续进行说明。

图8为服务注册组件收集服务提供方所提供的服务信息的时序图，其包括如下步骤：

步骤801，服务注册组件作为后台进程启动，并且周期性的查询一个共享文件的内容变化。

步骤802，服务提供者启动完成后，向共享文件中写入服务提供者的信息。

步骤803，服务注册组件读取文件中的内容。

步骤804，服务注册组件获取到文件中新写入的服务的信息。

步骤805，服务注册组件将新的服务信息注册到服务注册中心。

图9是服务消费者使用DNS协议查询服务提供方信息的时序图，其包括如下步骤：

步骤901，服务消费者使用DNS协议，向服务查询组件查询服务提供者的信息。

步骤902，服务服务查询组件缓存中暂无相关服务的信息，则向服务注册中心查询相关服务信息，并且在服务中心订阅此服务信息变化的通知。

步骤903，服务注册中心返回相关服务提供者信息到服务查询组件。

步骤904，服务查询组件在缓存此服务提供者信息。

步骤905，服务查询组件通过DNS协议将服务提供者信息返回给服务消费者。

步骤906，服务消费者使用服务提供者信息，访问服务提供者。

步骤907，服务提供者将结果返回给服务消费者。

步骤908，服务消费者再次通过DNS协议，向服务查询组件查询服务提供者的信息。

步骤909，服务查询组件检查缓存，发现已经有服务提供者的信息。

步骤910，服务查询组件直接将缓存中的服务提供者信息返回给服务消费者。

步骤911，服务消费者使用服务提供者信息，访问服务提供者。

步骤912，服务提供者将结果返回给服务消费者。

图10是服务注册信息变化时通知服务消费者的时序图，其包括如下步骤：

步骤1001，服务提供者写入新的服务信息到共享文件中。

步骤1002，服务注册组件周期性的读取文件中的内容。

步骤1003，服务注册组件获取新的服务提供者的信息。

步骤1004，服务注册组件将新的服务提供者信息注册到服务注册中心。

步骤1005，服务注册中心查询对这个服务者提供信息有监听的服务查询组件。

步骤1006，将服务提供者信息通知到服务查询组件。

步骤1007，服务查询组件更新缓存中的服务提供者信息。

尽管为示例目的，已经公开了本发明的优选实施例，本领域的技术人员将意识到各种改进、增加和取代也是可能的，因此，本发明的范围应当不限于上述实施例。

Claims (12)

1.一种***进程间请求寻址的方法，其特征在于，包括：

服务消费者主机接收针对预定服务的服务信息查询请求；

所述服务消费者主机根据所述服务信息查询请求通过预定协议向服务注册中心请求获取所述预定服务的服务信息，其中，所述服务信息查询请求包括：服务名称和服务版本号；所述服务信息包括：服务IP地址；

所述服务消费者主机接收所述服务注册中心返回的所述服务信息，并存储在本地缓存中；

所述服务消费者主机根据所述服务信息向所述预定服务对应的服务提供者主机发送服务获取请求，以获取所述预定服务。

2.如权利要求1所述的方法，其特征在于，服务消费者主机接收针对预定服务的服务信息查询请求之后，还包括：

检测所述本地缓存中是否存在所述服务信息查询请求对应的服务信息；

如果是，则获取所述本地缓存中的服务信息；

如果不是，则根据所述服务信息查询请求通过预定协议向服务注册中心请求获取所述预定服务的服务信息。

3.如权利要求1所述的方法，其特征在于，所述服务消费者主机接收所述服务注册中心返回的所述服务信息并存储在本地缓存中之后，包括：

将DNS协议中的生存时间TTL属性由第一时长修改为第二时长，其中，所述第二时长小于所述第一时长。

4.如权利要求1至3中任一项所述的方法，其特征在于，所述服务消费者主机根据所述服务信息查询请求通过预定协议向服务注册中心请求获取所述预定服务的服务信息之后，还包括：

向所述服务注册中心发送服务监听请求，其中，所述服务监听请求用于请求接收服务信息变更信息；

所述方法还包括：

在所述服务注册中心的服务信息与所述服务消费者主机的服务信息不相同时，接收所述服务注册中心发送的新的服务信息。

5.一种***进程间请求寻址的方法，其特征在于，包括：

服务提供者主机在本地文件中写入预定服务的服务信息，其中，所述服务信息包括：服务名称、服务版本号和服务IP地址；

所述服务提供者主机读取所述本地文件中存储的服务信息，并将所述服务信息发送至服务注册中心，以在所述服务注册中心存储服务消费者主机通过预定协议查询的服务信息。

6.如权利要求5所述的方法，其特征在于，还包括：

按照预定时间间隔判断所述本地文件中存储的所述服务信息是否发生变化；

在发生变化的情况下，再次读取所述本地文件中的服务信息。

7.一种***进程间请求寻址的装置，设置在服务消费者主机侧，其特征在于，包括：

第一接收模块，用于接收针对预定服务的服务信息查询请求；

获取模块，用于根据所述服务信息查询请求通过预定协议向服务注册中心请求获取所述预定服务的服务信息，其中，所述服务信息查询请求包括：服务名称和服务版本号；所述服务信息包括：服务IP地址；

第二接收模块，用于接收所述服务注册中心返回的所述服务信息，并存储在本地缓存中；

发送模块，用于根据所述服务信息向所述预定服务对应的服务提供者主机发送服务获取请求，以获取所述预定服务。

8.如权利要求7所述的装置，其特征在于，还包括：

检测模块，用于检测所述本地缓存中是否存在所述服务信息查询请求对应的服务信息；

所述获取模块，还用于在存在所述服务信息查询请求对应的服务信息的情况下，获取所述本地缓存中的服务信息；在不存在所述服务信息查询请求对应的服务信息的情况下，根据所述服务信息查询请求通过预定协议向服务注册中心请求获取所述预定服务的服务信息。

9.如权利要求7所述的装置，其特征在于，还包括：

设置模块，用于在将所述服务信息存储在本地缓存中之后，将DNS协议中的生存时间TTL属性由第一时长修改为第二时长，其中，所述第二时长小于所述第一时长。

10.如权利要求7至9中任一项所述的装置，其特征在于，还包括：

请求监听模块，在通过预定协议向服务注册中心请求获取所述预定服务的服务信息之后，向所述服务注册中心发送服务监听请求，其中，所述服务监听请求用于请求接收服务信息变更信息；

所述第二接收模块，还用于在所述服务注册中心的服务信息与所述服务消费者主机的服务信息不相同时，接收所述服务注册中心发送的新的服务信息。

11.一种***进程间请求寻址的装置，设置在服务提供者主机侧，其特征在于，包括：

写入模块，用于在本地文件中写入预定服务的服务信息，其中，所述服务信息包括：服务名称、服务版本号和服务IP地址；

执行模块，用于读取所述本地文件中存储的服务信息，并将所述服务信息发送至服务注册中心，以在所述服务注册中心存储服务消费者主机通过预定协议查询的服务信息。

12.如权利要求11所述的装置，其特征在于，还包括：

判断模块，用于按照预定时间间隔判断所述本地文件中存储的所述服务信息是否发生变化；

所述执行模块，还用于在发生变化的情况下，再次读取所述本地文件中的服务信息。