本申请涉及计算机领域，尤其涉及一种实现服务发现的方法及设备。
背景技术：
服务发现是大部分分布式系统和面向服务架构的核心组件。服务定位问题通常可以划分为两个子问题——服务注册和服务解析，其中，服务解析在某些特定语境下也被称作服务发现。目前，apachezookeeper(开源文件应用程序接口)是一个比较典型的用来做服务发现的系统。它提供的树形znode(节点)结构，比较适合服务发现问题中单个域名与多个服务地址之间的关系。zookeeper(分布式的开放源码的分布式应用程序协调服务)提供针对znode孩子节点列表的订阅，当有新的孩子节点被加入或者已有孩子被删除时，其父节点将会收到类型为child的变更通知。孩子节点本身的值，以及孩子节点的孩子节点，当它们发生变化的时候，不会触发父节点的child变更。zookeeper提供一种称为“临时节点”(ephemeralznode)的机制，临时节点与创建它的会话(session)的生命期绑定，当会话因为心跳停止而超时的时候，临时节点本身也将会一同随着会话的结束而自动删除。会话是靠zookeeper的客户端与服务端之间的心跳维持的。zookeeper主要利用了上述机制实现服务发现。当一个服务进程成功启动后，它会在zookeeper上创建一个临时节点，临时节点的名称或内容被用来存储服务进程的网络地址，临时节点位于某个域名节点之下。客户端应用程序列举该域名下的孩子节点，并订阅该节点的child事件。当某个服务进程注册之后，域名下的child事件被触发，最终通知到所有客户端应用程序，客户端应用程序将重新列举出域名下面的孩子节点列表，并更新它们的缓存。当某已注册服务进程正常退出之前，它会删除之前创建的临时节点，同样会触发child事件，最终会被客户端感知到。
当某个已注册的服务进程意外退出后，虽然它之前注册的临时节点不会被主动删除，但是由于它与zookeeper服务端的心跳不再维持，因此在一段时间之后(会话超时)，临时节点会被zookeeper服务端自动删除，这个行为同样会触发child事件，最终会被客户端感知到。
zookeeper实现服务发现的方法比较直观和简单，很自然地用到了树形结构、临时节点机制、child订阅通知机制等特性。但存在两个问题：第一个是它强依赖与树形目录结构，导致基于普通key/value实现的后端无法直接采用这种方案，限制了这种方案的普适性；第二个是它不能基于被注册的节点做水平伸缩扩展，因为父节点和孩子节点的层次关系决定了它们必须存在同一个zookeeper服务器上，然而一个节点下能创建的孩子节点是有上限的。
申请内容
本申请的一个目的是提供一种实现服务发现的方法及设备，解决目前现有技术中强依赖树形结构，不具有普适性，且不能基于被注册节点做水平伸缩扩展的问题。
根据本申请的一个方面，提供了一种服务端的服务发现方法，该方法包括：
根据服务进程的服务地址创建对应的服务文件；
将所述服务文件的路径写入服务列表文件中；
当所述服务进程发生注销时，删除所述对应的服务文件并将所述服务文件的路径从所述服务列表文件中移除。
进一步地，上述方法中，将所述服务文件的路径写入服务列表文件中，包括：在所述服务列表文件中写入新的服务文件的路径时，先读取所述服务列表文件中的原有的服务文件的路径，再将所述原有的服务文件的路径加上所述新的服务文件的路径作为回写内容，将所述回写内容更新到所述服务列表文件中。
进一步地，上述方法中，将所述服务文件的路径写入服务列表文件中，包括：当有多个新的服务文件的路径写入所述服务列表文件中时，每次在服务列表文件中只写入一个新的服务文件的路径，其中，待上一个新的服务文件的路径写入所述服务列表文件形成新的服务列表文件后，再在所述新的服务列表文件写入下一个新的服务文件的路径。
进一步地，上述方法中，将所述服务文件的路径写入服务列表文件中之后，包括：若所述服务进程发生异常退出，在所述服务进程的会话超时后删除所述服务文件。
更进一步地，上述方法中，所述若所述服务进程发生异常退出，在所述服务进程的会话超时后删除所述服务文件之后，包括：
判断所述服务列表文件中路径所对应的服务文件是否存在，若否，则将所述服务文件的路径从所述服务列表文件中移除。
根据本申请的另一个方面，提供了一种客户端的服务发现方法，该方法包括：
对服务列表文件的变更进行监听，当监听到服务列表文件发生变更时，根据服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径；
对所述增加的服务文件的路径对应的服务文件的变更进行监听，当监听到所述服务文件发生变更时，根据所述服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。
进一步地，上述方法中，所述对服务列表文件的变更进行监听，当监听到服务列表文件发生变更时，根据服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径包括：
当监听到服务列表文件发生变更时，读取所述服务列表文件得到服务文件的路径；
将未发生变更时的服务列表中的路径与发生变更时所述读取的服务列表中的路径进行比较，根据比较结果确定增加的服务文件的路径；
根据所述增加的路径确定对应增加的服务文件。
进一步地，上述方法中，根据服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址，包括：
判断所述服务文件是否存在，若是，则将所述服务文件的网络地址添加到所述本地路由缓存中。
进一步地，上述方法中，根据服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址，包括：
判断所述服务文件是否不存在，若是，则将所述服务文件的网络地址从本地路由缓存中移除，并解除对所述服务文件的变更的监听。
进一步地，上述方法中，当监听到服务列表文件发生变更时，根据服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径，包括：
当监听到服务列表文件先后依次发生多次变更时，根据最新的服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径。
进一步地，上述方法中，当监听到所述服务文件发生变更时，根据服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址，包括：
当监听到所述服务文件先后依次发生多次变更时，根据最新的服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。
根据本申请的又一方面，还提供了一种用于服务发现的服务设备，所述服务设备包括：
创建装置，用于根据服务进程的服务地址创建对应的服务文件；
写入装置，用于将所述服务文件的路径写入服务列表文件中；
修改装置，用于当所述服务进程发生注销时，删除所述对应的服务文件并将所述服务文件的路径从所述服务列表文件中移除。
进一步地，上述服务设备中，所述写入装置用于：
在所述服务列表文件中写入新的服务文件的路径时，先读取所述服务列表文件中的原有的服务文件的路径，再将所述原有的服务文件的路径加上所述新的服务文件的路径作为回写内容，将所述回写内容更新到所述服务列表文件中。
进一步地，上述服务设备中，所述写入装置用于：
当有多个新的服务文件的路径写入所述服务列表文件中时，每次在服务列表文件中只写入一个新的服务文件的路径，其中，待上一个新的服务文件的路径写入所述服务列表文件形成新的服务列表文件后，再在所述新的服务列表文件写入下一个新的服务文件的路径。
进一步地，所述服务设备包括：
删除装置，用于若所述服务进程发生异常退出，在所述服务进程的会话超时后删除所述服务文件。
更进一步地，所述服务设备包括：
识别装置，用于判断所述服务列表文件中路径所对应的服务文件是否存在，若否，则将所述服务文件的路径从所述服务列表文件中移除。
根据本申请的再一方面，还提供了一种用于服务发现的客户设备，所述客户设备包括：
服务列表文件监听装置，用于对服务列表文件的变更进行监听，当监听到服务列表文件发生变更时，根据服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径；
服务文件监听装置，用于对所述增加的服务文件的路径对应的服务文件的变更进行监听，当监听到所述服务文件发生变更时，根据所述服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。
进一步地，上述客户设备中，所述服务列表文件监听装置用于：
当监听到服务列表文件发生变更时，读取所述服务列表文件得到服务文件的路径；
将未发生变更时的服务列表中的路径与发生变更时所述读取的服务列表中的路径进行比较，根据比较结果确定增加的服务文件的路径；
根据所述增加的路径确定对应增加的服务文件。
进一步地，上述客户设备中，所述服务文件监听装置用于：
判断所述服务文件是否存在，若是，则将所述服务文件的网络地址添加到所述本地路由缓存中。
进一步地，上述客户设备中，所述服务文件监听装置用于：
判断所述服务文件是否不存在，若是，则将所述服务文件的网络地址从本地路由缓存中移除，并解除对所述服务文件的变更的监听。
进一步地，上述客户设备中，所述服务列表文件监听装置用于：
当监听到服务列表文件先后依次发生多次变更时，根据最新的服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径。
进一步地，上述客户设备中，所述服务文件监听装置用于：
当监听到所述服务文件先后依次发生多次变更时，根据最新的服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。
根据本申请的另一面，还提供一种基于计算的设备，包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：
根据服务进程的服务地址创建对应的服务文件；将所述服务文件的路径写入服务列表文件中；当所述服务进程发生注销时，删除所述对应的服务文件并将所述服务文件的路径从所述服务列表文件中移除。
根据本申请的另一面，还提供一种基于计算的设备，包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：
对服务列表文件的变更进行监听，当监听到服务列表文件发生变更时，根据服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径；对所述增加的服务文件的路径对应的服务文件的变更进行监听，当监听到所述服务文件发生变更时，根据所述服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。
与现有技术相比，本申请通过在服务端进行以下行为：根据服务进程的服务地址创建对应的服务文件；将所述服务文件的路径写入服务列表文件中；当所述服务进程发生注销时，删除所述对应的服务文件并将所述服务文件的路径从所述服务列表文件中移除。由于服务列表文件中存放已注册服务进程所创建的服务文件，该服务文件的路径或内容存储这个服务进程的网络地址，从而通过维护服务列表文件，完成服务端注册、注销和活跃性维持的功能，与客户端进行交互协议，使得客户端完成服务发现，针对服务文件列表的监听实现对数据节点的分布式订阅，能够支持后端物理存储的水平扩展。
另外，在客户端进行以下行为：对服务列表文件的变更进行监听，当监听到服务列表文件发生变更时，根据服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径；对所述增加的服务文件的路径对应的服务文件的变更进行监听，当监听到所述服务文件发生变更时，根据所述服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。从而通过订阅服务列表文件的变更来发现新创建的服务文件，从而不仅能订阅到确定的文件变更事件，还能获取到预先不确定的文件变更事件的通知，另外，客户端通过订阅每个服务文件的变更，保证通过与每个服务进程关联的服务文件来监控服务进程的活跃性。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：
图1示本申请一个方面的一实施例的服务列表文件与服务文件的关系示意图；
图2示出本申请中一实施例的服务注册流程示意图；
图3示出本申请中一实施例的服务注销流程示意图；
图4示出本申请另一个方面的一实施例的客户端订阅流程示意图；
图5示出本申请另一个方面的一实施例的订阅服务文件流程示意图。
附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
下面结合附图对本申请作进一步详细描述。
在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
根据本申请的一个方面，提供了一种服务端的服务发现方法，该方法包括：步骤s11，根据服务进程的服务地址创建对应的服务文件；步骤s12，将所述服务文件的路径写入服务列表文件中；步骤s13，当所述服务进程发生注销时，删除所述对应的服务文件并将所述服务文件的路径从所述服务列表文件中移除。由于每个服务列表文件是单独被维护的，不存在树形目录结构，服务列表文件中有很多路径组成的文件，也可称作是有很多服务文件的key组成的，在服务端完成服务端注册、注销和活跃性维持的功能，与客户端进行交互协议，使得客户端完成服务发现，针对服务文件列表的监听实现对数据节点的分布式订阅，能够支持基于普通key/value实现的后端，更加具有通用性。
具体地，在步骤s11中，根据服务进程的服务地址创建对应的服务文件；当一个服务进程启动后，它需要在注册中心注册自己完成服务注册，具体做法是，首先根据自己的服务地址创建相应的服务文件(server文件)，server文件为一种临时文件。
在步骤s12中，将所述服务文件的路径写入服务列表文件中；例如，服务进程在注册中心创建相应的服务文件(server文件)成功之后，还需要将这个server文件的路径添加到服务列表文件(serverlist文件)中，完成服务注册。如图1所示，server文件和serverlist文件的关系图，serverlist文件存放已注册服务进程所创建的server文件。需要说明的是，服务注册是指服务进程在注册中心注册自己的位置，通常将自己的网络地址(主机和端口号)注册到一个域名下面，一个域名下面可以注册多个服务进程的网络地址。为了监控服务的状态，注册中心会和服务进程之间维持一个心跳机制来确保服务进程的活跃性。如图2所示，为服务注册流程，步骤s1创建server文件，步骤s2将server文件的路径原子地添加到serverlist文件中。
具体地，步骤s13，当所述服务进程发生注销时，删除所述对应的服务文件并将所述服务文件的路径从所述服务列表文件中移除。当一个已注册的服务进程需要将自己注销掉时，它首先需要将自己先前创建的server文件删除掉，删除成功之后还需要将自己的server路径从serverlist文件中移除。如图3所示的服务注销流程，步骤s1’删除server文件，步骤s2’将server文件的路径原子地从serverlist文件中移除。
优选地，上述方法中，将所述服务文件的路径写入服务列表文件中，包括：在所述服务列表文件中写入新的服务文件的路径时，先读取所述服务列表文件中的原有的服务文件的路径，再将所述原有的服务文件的路径加上所述新的服务文件的路径作为回写内容，将所述回写内容更新到所述服务列表文件中。在一实施例中，假设serverlist文件中已存在{b1，b2，……，b10}10个路径的记录，将新创建的server文件的路径a11新添加至serverlist文件中，需要先读取serverlist文件中原有的server文件的路径，即读取到{b1，b2，……，b10}的10个记录信息，a11将自己的记录写入到serverlist中，然后进行回写，即再将所述原有的服务server文件的路径{b1，b2，……，b10}加上所述新的server文件的路径a11作为回写内容，将所述回写内容更新到所述serverlist文件中，更新后的serverlist文件中的内容为{b1，b2，……，b10，a11}。通过上述的写入机制，保证了向serverlist中写入新的路径时不覆盖serverlist中其他已存在的路径，serverlist文件中的路径的更新为原子性的。
优选地，上述方法中，将所述服务文件的路径写入服务列表文件中，包括：当有多个新的服务文件的路径写入所述服务列表文件中时，每次在服务列表文件中只写入一个新的服务文件的路径，其中，待上一个新的服务文件的路径写入所述服务列表文件形成新的服务列表文件后，再在所述新的服务列表文件写入下一个新的服务文件的路径。在此，为了保证对serverlist文件的原子性地更新，服务进程通过条件更新(conditionalupdate)接口来修改serverlist文件，所述条件更新是基于当前的serverlist文件内容的检查进行判断需要新写入的路径是否满足更新条件，例如，在一具体实施例中，假设serverlist文件中已存在{b1，b2，……，b10}10个路径的记录，当新路径b11和b12都想写入serverlist文件时，因为写入的过程为b11和b12分别先读取serverlist文件中原有的server文件的路径，即读取到{b1，b2，……，b10}的十个记录信息，b11和b12再分别将自己的记录写入到serverlist中，然后进行回写，即再将所述原有的服务server文件的路径{b1，b2，……，b10}加上所述新的server文件的路径作为回写内容，将所述回写内容更新到所述serverlist文件中。这样如果没有条件更新接口，当b11和b12并发写入serverlist文件中时会出现b11写后的结果为{b1，b2，……，b10，b11}这11个路径信息，和b12写后的结果为{b1，b2，……，b10，b12}这11个路径信息，而需要的结果应为{b1，b2，……，b10，b11，b12}这12个路径信息，导致了在并发情况下的数据不一致的问题，因此需要通过条件更新接口实现并发将路径写入serverlist文件时的数据一致性，保证文件的原子性。例如，条件更新为判断文件版本号，更新路径和文件的网络地址，当b11条件更新失败则说明有另一个文件路径(b12)在更新，b11无法执行更新，需要重新读取serverlist文件中的路径信息，当serverlist文件版本为新的版本(路径内容为b1，b2，……，b10，b12)时，b11才可进行写操作，将b11的路径写入serverlist文件中，解决了并发写入路径的情况下server文件路径更新冲突问题，保证了server文件路径的原子性地更新，实现数据一致性。
需要说明的是，在本申请的实施例中，通过条件接口对serverlist文件进行修改主要体现在将新创建的server文件的路径添加到serverlist中，即在所述服务列表文件中写入新的服务文件的路径时的情况，通过条件接口对serverlist文件的修改还包括对文件中原有路径的删除，并发删除serverlist文件中的路径通过条件更新接口也能保证数据的一致性和文件的原子性。
优选地，上述方法中，将所述服务文件的路径写入服务列表文件中之后，包括：若所述服务进程发生异常退出，在所述服务进程的会话超时后删除所述服务文件。在此，由于注册中心提供创建临时文件的api(应用程序接口)，调用临时文件的api创建server文件，server文件是一种临时文件，因此当服务进程没有走服务注销流程，出现意外退出时，因server文件具有临时文件的特性，在被创建时，会在注册中心注册会话，需要服务进程与注册中心维持心跳，当心跳断掉时，会话在一段时间后发生超时，而server文件与会话是相对应的，当会话超时后，server文件会自动被删除。
更优选地，上述方法中，所述若所述服务进程发生异常退出，在所述服务进程的会话超时后删除所述服务文件之后，包括：判断所述服务列表文件中路径所对应的服务文件是否存在，若否，则将所述服务文件的路径从所述服务列表文件中移除。当服务意外退出的时候，它可能来不及主动删除server文件，也可能删除了server文件，但来不及去更新serverlist文件。无论哪种情况，最终server文件因临时文件的特性会被删除，而serverlist中还存在这个server文件的路径，存在的路径将不被更新，此时这样的路径为垃圾路径。由于服务注册的时候始终是先创建server文件，再更新serverlist，因此识别serverlist中的垃圾路径的方法可以为：如果某个路径对应的server文件不存在，则该路径为垃圾路径，可以使用一个后台运行的垃圾回收器进行垃圾路径的清理。垃圾回收期清理路径垃圾的机制为：当判断出的serverlist文件中路径所对应的server文件不存在时，则将该server文件的路径从serverlist文件中移除，这一垃圾回收机制存在一个特殊情况，即当服务进程注销时，先删掉了server文件，在更新serverlist之前，垃圾回收器将其识别为垃圾文件，于是会发起一个目的完全相同的更新serverlist的操作。由于更新serverlist是原子性地操作，所以这两个操作只会有一个成功，失败的那一个只要在重试之前检查一下server路径是否已被清除即可，设置垃圾回收机制节省了注册中心的数据存储空间。
根据本申请的另一个方面，提供了一种客户端的服务发现方法，该方法包括：步骤s21，对服务列表文件的变更进行监听，当监听到服务列表文件发生变更时，根据服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径；步骤s22，对所述增加的服务文件的路径对应的服务文件的变更进行监听，当监听到所述服务文件发生变更时，根据所述服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。通过对服务列表文件的监听和服务文件的监听，实现单文件的订阅，订阅节点分布在不同的服务机器上，而非是必须在同一个机器上，同时每个文件是相互独立的，不需要像现有技术中孩子节点和父节点存在同一个机器上，而一个父节点下能创建的孩子节点是有限的，本申请的单文件订阅脱离了这种父子关系的限制，使得订阅节点在水平伸缩扩展，从而本申请的服务发现的方法能够支持物理存储的水平扩展。
优选地，上述方法中，步骤s21包括：步骤s211，当监听到服务列表文件发生变更时，读取所述服务列表文件得到服务文件的路径；步骤s212，将未发生变更时的服务列表中的路径与发生变更时所述读取的服务列表中的路径进行比较，根据比较结果确定增加的服务文件的路径；步骤s213，根据所述增加的路径确定对应增加的服务文件。客户端应用程序需要获取到所有server文件的网络地址，并且订阅这些server网络地址的变更，在此，订阅server文件为监听server文件。由于单文件的订阅只能订阅到路径预先确定的文件的变更事件，路径预先不确定的文件无法实施订阅，因此需要通过订阅serverlist文件的变更来发现新创建的server文件。但，也不能仅仅订阅serverlist文件因为还需要通过与每个服务进程关联的server(临时)文件来监控服务进程的活跃性。综合上述原因，客户端应用程序必须同时订阅serverlist文件和每个server文件的变更。在一实施例中，如图4所示的客户端应用程序订阅流程，在程序实际应用中，首先需要初始化流程：步骤s21’，记当前的server_list为current_list，初始为空；步骤s22’，服务进程的路由信息存储在router_cache对象中，初始化为空；步骤s23’，订阅server_list文件变更。其中，router_cache为本地路由缓存，客户端向注册中心发起查询请求，在注册中心上找到相应的路由信息，根据路由信息解析网络地址，而在本地维持一个router_cache，客户端在router_cache中查找网络地址，解决了注册中心处理查询请求的压力，降低网络开销。在初始化流程完成之后，开始订阅serverlist文件流程：步骤s24’，监听server_list文件的变更，当发生变更时，读取文件内容并解析为server路径集合，记为new_list；将未发生变更时的服务列表中的路径与发生变更时所述读取的服务列表中的路径进行比较，根据比较结果确定增加的服务文件的路径，步骤s25’，对每个在new_list中不在current_list中的server文件路径：订阅该server文件的变更，其中，new_list中的文件路径为发生变更时所读取的服务列表中的路径，current_list中的文件路径为未发生变更时的服务列表中的路径，两者进行比较，根据比较结果确定增加的服务文件的路径，即发生变更的服务文件路径，根据所述增加的路径确定对应增加的服务文件，订阅该对应增加的服务文件。步骤s26’，更新current_list:＝new_list，是指将发生变更的serverlist文件重新记作为当前的serverlist，方便循环执行上述订阅serverlist文件的方法，使得可以订阅到serverlist文件的每个变更通知。通过订阅serverlist文件进而订阅到发生变更的server文件，基于单文件订阅实现服务发现，提供了针对数据节点本身内容的订阅通知，不再受树形目录结构的限制，从而实现服务发现在后端的水平伸缩扩展。
优选地，步骤s22中，根据服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址，包括：判断所述服务文件是否存在，若是，则将所述服务文件的网络地址添加到所述本地路由缓存中。在此，监听server文件的变更，所述变更包括server文件的创建、修改，当server文件发生创建、修改的变更，此时，server文件已存在，则将新的网络地址添加到本地路由router_cache中。保证了server文件与本地router_cache中内容的一致性，使得客户端在本地准确地查询网络地址。
优选地，步骤s22中，根据服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址，包括：判断所述服务文件是否不存在，若是，则将所述服务文件的网络地址从本地路由缓存中移除，并解除对所述服务文件的变更的监听。在此，监听server文件的变更，所述变更包括server文件的删除，当server文件发生删除的变更，则需要将该server的网络地址从router_cache中移除，并解除对该server文件的监听。由于客户端从本地缓存的router_cache中查询网络地址，当没有server文件时，对应将router_cache中的网络地址删除，从而使得router_cache不会出现server_list中存在垃圾路径的情况。客户端在本地进行查询网络地址时不会查找到垃圾路径，而设置垃圾回收机制清理垃圾路径的目的是为了节省注册中心的数据存储空间的考虑。
综上所述，如图5所示，监听server文件的变更，当发生变更时，如果server文件存在，则将server的网络地址添加到router_cache中；如果server文件不存在，则将server的网络地址从router_cache中移除并解除对该server文件的监听，从而保证了server文件的状态与router_cache中内容的一致性，保证客户端实时查询router_cache中server文件的网络地址的准确性。
优选地，步骤s21中，当监听到服务列表文件发生变更时，根据服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径，包括：当监听到服务列表文件先后依次发生多次变更时，根据最新的服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径。对于serverlist文件的变更事件的通知，中间可能会出现丢失的情况，但如果后续没有任何其他变更了，因此需要根据最新的serverlist文件的变更确定serverlist中增加的server文件的路径，从而保证文件的最终状态一定被通知到，在一优选实施例中，给每个serverlist文件都赋予一个全局递增的文件版本号，则根据文件版本号，可以保证所有事件的通知是有序的，对于变更事件的通知只需满足最终一致性，因此可以将乱序的事件中所有迟到的事件直接丢弃。
优选地，步骤s22中，当监听到所述服务文件发生变更时，根据服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址，包括：当监听到所述服务文件先后依次发生多次变更时，根据最新的服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。对于server文件的变更事件的通知，中间可能会出现丢失的情况，但如果后续没有任何其他变更了，因此需要根据最新的server文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址，从而保证server文件的最终状态一定被通知到，在又一优选实施例中，给每个server文件都赋予一个全局递增的文件版本号，则根据server文件版本号，可以保证所有事件的通知是有序的，对于变更事件的通知只需满足最终一致性，因此可以将乱序的事件中所有迟到的事件直接丢弃。
综上所述，本申请基于单文件的订阅语义，提出了通过服务端的服务注册和服务注销流程，客户端分别监听服务列表文件和服务文件的这种服务发现的方法，通过摒弃树形结构和child订阅机制，解决了现有技术中的服务发现方法中存在的基于普通key/value实现的后端无法直接采用现有技术方案，限制了现有技术方案的普适性问题，以及解决了现有技术不能基于被注册节点做水平伸缩扩展的问题。
根据本申请的另一个方面，提供了一种用于服务发现的服务设备，该服务设备包括：创建装置11，用于根据服务进程的服务地址创建对应的服务文件；写入装置12，用于将所述服务文件的路径写入服务列表文件中；修改装置13，用于当所述服务进程发生注销时，删除所述对应的服务文件并将所述服务文件的路径从所述服务列表文件中移除。由于每个服务列表文件是单独被维护的，不存在树形目录结构，服务列表文件中有很多路径组成的文件，也可称作是有很多服务文件的key组成的，在服务端完成服务端注册、注销和活跃性维持的功能，与客户端进行交互协议，使得客户端完成服务发现，针对服务文件列表的监听实现对数据节点的分布式订阅，能够支持基于普通key/value实现的后端，更加具有通用性。
具体地，创建装置11，用于根据服务进程的服务地址创建对应的服务文件；当一个服务进程启动后，它需要在注册中心注册自己完成服务注册，具体做法是，首先根据自己的服务地址创建相应的服务文件(server文件)，server文件为一种临时文件。
具体地，写入装置12，用于将所述服务文件的路径写入服务列表文件中；例如，服务进程在注册中心创建相应的服务文件(server文件)成功之后，还需要将这个server文件的路径添加到服务列表文件(serverlist文件)中，完成服务注册。如图1所示，server文件和serverlist文件的关系图，serverlist文件存放已注册服务进程所创建的server文件。需要说明的是，服务注册是指服务进程在注册中心注册自己的位置，通常将自己的网络地址(主机和端口号)注册到一个域名下面，一个域名下面可以注册多个服务进程的网络地址。为了监控服务的状态，注册中心会和服务进程之间维持一个心跳机制来确保服务进程的活跃性。如图2所示，为服务注册流程，步骤s1创建server文件，步骤s2将server文件的路径原子地添加到serverlist文件中。
具体地，修改装置13，用于当所述服务进程发生注销时，删除所述对应的服务文件并将所述服务文件的路径从所述服务列表文件中移除。当一个已注册的服务进程需要将自己注销掉时，它首先需要将自己先前创建的server文件删除掉，删除成功之后还需要将自己的server路径从serverlist文件中移除。如图3所示的服务注销流程，步骤s1’删除server文件，步骤s2’将server文件的路径原子地从serverlist文件中移除。
优选地，写入装置12用于在所述服务列表文件中写入新的服务文件的路径时，先读取所述服务列表文件中的原有的服务文件的路径，再将所述原有的服务文件的路径加上所述新的服务文件的路径作为回写内容，将所述回写内容更新到所述服务列表文件中。在一实施例中，假设serverlist文件中已存在{b1，b2，……，b10}10个路径的记录，将新创建的server文件的路径a11新添加至serverlist文件中，需要先读取serverlist文件中原有的server文件的路径，即读取到{b1，b2，……，b10}的10个记录信息，a11将自己的记录写入到serverlist中，然后进行回写，即再将所述原有的服务server文件的路径{b1，b2，……，b10}加上所述新的server文件的路径a11作为回写内容，将所述回写内容更新到所述serverlist文件中，更新后的serverlist文件中的内容为{b1，b2，……，b10，a11}。通过上述的写入机制，保证了向serverlist中写入新的路径时不覆盖serverlist中其他已存在的路径，serverlist文件中的路径的更新为原子性的。
优选地，上述服务设备中，写入装置12，用于当有多个新的服务文件的路径写入所述服务列表文件中时，每次在服务列表文件中只写入一个新的服务文件的路径，其中，待上一个新的服务文件的路径写入所述服务列表文件形成新的服务列表文件后，再在所述新的服务列表文件写入下一个新的服务文件的路径。在此，为了保证对serverlist文件的原子性地更新，服务进程通过条件更新(conditionalupdate)接口来修改serverlist文件，所述条件更新是基于当前的serverlist文件内容的检查进行判断需要新写入的路径是否满足更新条件，例如，在一具体实施例中，假设serverlist文件中已存在{b1，b2，……，b10}10个路径的记录，当新路径b11和b12都想写入serverlist文件时，因为写入的过程为b11和b12分别先读取serverlist文件中原有的server文件的路径，即读取到{b1，b2，……，b10}的十个记录信息，b11和b12再分别将自己的记录写入到serverlist中，然后进行回写，即再将所述原有的服务server文件的路径{b1，b2，……，b10}加上所述新的server文件的路径作为回写内容，将所述回写内容更新到所述serverlist文件中。这样如果没有条件更新接口，当b11和b12并发写入serverlist文件中时会出现b11写后的结果为{b1，b2，……，b10，b11}这11个路径信息，和b12写后的结果为{b1，b2，……，b10，b12}这11个路径信息，而需要的结果应为{b1，b2，……，b10，b11，b12}这12个路径信息，导致了在并发情况下的数据不一致的问题，因此需要通过条件更新接口实现并发将路径写入serverlist文件时的数据一致性，保证文件的原子性。例如，条件更新为判断文件版本号，更新路径和文件的网络地址，当b11条件更新失败则说明有另一个文件路径(b12)在更新，b11无法执行更新，需要重新读取serverlist文件中的路径信息，当serverlist文件版本为新的版本(路径内容为b1，b2，……，b10，b12)时，b11才可进行写操作，将b11的路径写入serverlist文件中，解决了并发写入路径的情况下server文件路径更新冲突问题，保证了server文件路径的原子性地更新，实现数据一致性。
需要说明的是，在本申请的实施例中，通过条件接口对serverlist文件进行修改主要体现在将新创建的server文件的路径添加到serverlist中，即在所述服务列表文件中写入新的服务文件的路径时的情况，通过条件接口对serverlist文件的修改还包括对文件中原有路径的删除，并发删除serverlist文件中的路径通过条件更新接口也能保证数据的一致性和文件的原子性。
优选地，上述服务设备包括：删除装置，用于若所述服务进程发生异常退出，在所述服务进程的会话超时后删除所述服务文件。在此，由于注册中心提供创建临时文件的api(应用程序接口)，调用临时文件的api创建server文件，server文件是一种临时文件，因此当服务进程没有走服务注销流程，出现意外退出时，因server文件具有临时文件的特性，在被创建时，会在注册中心注册会话，需要服务进程与注册中心维持心跳，当心跳断掉时，会话在一段时间后发生超时，而server文件与会话是相对应的，当会话超时后，server文件会自动被删除。
更优选地，上述服务设备包括：识别装置，用于判断所述服务列表文件中路径所对应的服务文件是否存在，若否，则将所述服务文件的路径从所述服务列表文件中移除。当服务意外退出的时候，它可能来不及主动删除server文件，也可能删除了server文件，但来不及去更新serverlist文件。无论哪种情况，最终server文件因临时文件的特性会被删除，而serverlist中还存在这个server文件的路径，存在的路径将不被更新，此时这样的路径为垃圾路径。由于服务注册的时候始终是先创建server文件，再更新serverlist，因此识别serverlist中的垃圾路径的方法可以为：如果某个路径对应的server文件不存在，则该路径为垃圾路径，可以使用一个后台运行的垃圾回收器进行垃圾路径的清理。垃圾回收期清理路径垃圾的机制为：当判断出的serverlist文件中路径所对应的server文件不存在时，则将该server文件的路径从serverlist文件中移除，这一垃圾回收机制存在一个特殊情况，即当服务进程注销时，先删掉了server文件，在更新serverlist之前，垃圾回收器将其识别为垃圾文件，于是会发起一个目的完全相同的更新serverlist的操作。由于更新serverlist是原子性地操作，所以这两个操作只会有一个成功，失败的那一个只要在重试之前检查一下server路径是否已被清除即可，设置垃圾回收机制节省了注册中心的数据存储空间。
根据本申请的另一个方面，提供了一种用于服务发现的客户设备，该客户设备包括：服务列表文件监听装置21，用于对服务列表文件的变更进行监听，当监听到服务列表文件发生变更时，根据服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径；服务文件监听装置22，用于对所述增加的服务文件的路径对应的服务文件的变更进行监听，当监听到所述服务文件发生变更时，根据所述服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。通过对服务列表文件的监听和服务文件的监听，实现单文件的订阅，订阅节点分布在不同的服务机器上，而非是必须在同一个机器上，同时每个文件是相互独立的，不需要像现有技术中孩子节点和父节点存在同一个机器上，而一个父节点下能创建的孩子节点是有限的，本申请的单文件订阅脱离了这种父子关系的限制，使得订阅节点在水平伸缩扩展，从而本申请的服务发现的方法能够支持物理存储的水平扩展。
优选地，服务列表监听装置21用于：当监听到服务列表文件发生变更时，读取所述服务列表文件得到服务文件的路径；将未发生变更时的服务列表中的路径与发生变更时所述读取的服务列表中的路径进行比较，根据比较结果确定增加的服务文件的路径；根据所述增加的路径确定对应增加的服务文件。客户端应用程序需要获取到所有server文件的网络地址，并且订阅这些server网络地址的变更，在此，订阅server文件为监听server文件。由于单文件的订阅只能订阅到路径预先确定的文件的变更事件，路径预先不确定的文件无法实施订阅，因此需要通过订阅serverlist文件的变更来发现新创建的server文件。但，也不能仅仅订阅serverlist文件因为还需要通过与每个服务进程关联的server(临时)文件来监控服务进程的活跃性。综合上述原因，客户端应用程序必须同时订阅serverlist文件和每个server文件的变更。在一实施例中，如图4所示的客户端应用程序订阅流程，在程序实际应用中，首先需要初始化流程：步骤s21’，记当前的server_list为current_list，初始为空；步骤s22’，服务进程的路由信息存储在router_cache对象中，初始化为空；步骤s23’，订阅server_list文件变更。其中，router_cache为本地路由缓存，客户端向注册中心发起查询请求，在注册中心上找到相应的路由信息，根据路由信息解析网络地址，而在本地维持一个router_cache，客户端在router_cache中查找网络地址，解决了注册中心处理查询请求的压力，降低网络开销。在初始化流程完成之后，开始订阅serverlist文件流程：步骤s24’，监听server_list文件的变更，当发生变更时，读取文件内容并解析为server路径集合，记为new_list；将未发生变更时的服务列表中的路径与发生变更时所述读取的服务列表中的路径进行比较，根据比较结果确定增加的服务文件的路径，步骤s25’，对每个在new_list中不在current_list中的server文件路径：订阅该server文件的变更，其中，new_list中的文件路径为发生变更时所读取的服务列表中的路径，current_list中的文件路径为未发生变更时的服务列表中的路径，两者进行比较，根据比较结果确定增加的服务文件的路径，即发生变更的服务文件路径，根据所述增加的路径确定对应增加的服务文件，订阅该对应增加的服务文件。步骤s26’，更新current_list:＝new_list，是指将发生变更的serverlist文件重新记作为当前的serverlist，方便循环执行上述订阅serverlist文件的方法，使得可以订阅到serverlist文件的每个变更通知。通过订阅serverlist文件进而订阅到发生变更的server文件，基于单文件订阅实现服务发现，提供了针对数据节点本身内容的订阅通知，不再受树形目录结构的限制，从而实现服务发现在后端的水平伸缩扩展。
优选地，服务文件监听装置22，用于判断所述服务文件是否存在，若是，则将所述服务文件的网络地址添加到所述本地路由缓存中。在此，监听server文件的变更，所述变更包括server文件的创建、修改，当server文件发生创建、修改的变更，此时，server文件已存在，则将新的网络地址添加到本地路由router_cache中。保证了server文件与本地router_cache中内容的一致性，使得客户端在本地准确地查询网络地址。
优选地，服务文件监听装置，用于判断所述服务文件是否不存在，若是，则将所述服务文件的网络地址从本地路由缓存中移除，并解除对所述服务文件的变更的监听。在此，监听server文件的变更，所述变更包括server文件的删除，当server文件发生删除的变更，则需要将该server的网络地址从router_cache中移除，并解除对该server文件的监听。由于客户端从本地缓存的router_cache中查询网络地址，当没有server文件时，对应将router_cache中的网络地址删除，从而使得router_cache不会出现server_list中存在垃圾路径的情况。客户端在本地进行查询网络地址时不会查找到垃圾路径，而设置垃圾回收机制清理垃圾路径的目的是为了节省注册中心的数据存储空间的考虑。
综上所述，如图5所示，监听server文件的变更，当发生变更时，如果server文件存在，则将server的网络地址添加到router_cache中；如果server文件不存在，则将server的网络地址从router_cache中移除并解除对该server文件的监听，从而保证了server文件的状态与router_cache中内容的一致性，保证客户端实时查询router_cache中server文件的网络地址的准确性。
优选地，服务列表文件监听装置21，用于当监听到服务列表文件先后依次发生多次变更时，根据最新的服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径。对于serverlist文件的变更事件的通知，中间可能会出现丢失的情况，但如果后续没有任何其他变更了，因此需要根据最新的serverlist文件的变更确定serverlist中增加的server文件的路径，从而保证文件的最终状态一定被通知到，在一优选实施例中，给每个serverlist文件都赋予一个全局递增的文件版本号，则根据文件版本号，可以保证所有事件的通知是有序的，对于变更事件的通知只需满足最终一致性，因此可以将乱序的事件中所有迟到的事件直接丢弃。
优选地，服务文件监听装置22，用于当监听到所述服务文件先后依次发生多次变更时，根据最新的服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。对于server文件的变更事件的通知，中间可能会出现丢失的情况，但如果后续没有任何其他变更了，因此需要根据最新的server文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址，从而保证server文件的最终状态一定被通知到，在又一优选实施例中，给每个server文件都赋予一个全局递增的文件版本号，则根据server文件版本号，可以保证所有事件的通知是有序的，对于变更事件的通知只需满足最终一致性，因此可以将乱序的事件中所有迟到的事件直接丢弃。
根据本申请的另一面，还提供一种基于计算的设备，包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：
根据服务进程的服务地址创建对应的服务文件；将所述服务文件的路径写入服务列表文件中；当所述服务进程发生注销时，删除所述对应的服务文件并将所述服务文件的路径从所述服务列表文件中移除。
根据本申请的另一面，还提供一种基于计算的设备，包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：
对服务列表文件的变更进行监听，当监听到服务列表文件发生变更时，根据服务列表文件的变更确定所述服务列表文件中增加的服务文件的路径；对所述增加的服务文件的路径对应的服务文件的变更进行监听，当监听到所述服务文件发生变更时，根据所述服务文件的变更在本地路由缓存中添加或移除所述服务文件的网络地址。
综上所述，本申请基于单文件的订阅语义，提出了用于服务发现的服务设备和客户设备，通过在服务设备的服务注册和服务注销流程，客户设备用于分别监听服务列表文件和服务文件，摒弃了树形结构和child订阅机制，解决了现有技术中的服务发现方法中存在的基于普通key/value实现的后端无法直接采用现有技术方案，限制了现有技术方案的普适性问题，以及解决了现有技术不能基于被注册节点做水平伸缩扩展的问题。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(asic)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，ram存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。
另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。
对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。