CN111147605B - 服务注册方法、装置和设备 - Google Patents

Abstract

本申请提供了一种服务注册方法、装置和设备，其中，该方法包括：在目标系统初始化时，在预设的注册目录中创建多个模块节点；在所述多个模块节点中的目标模块节点下创建目标节点；将归属于目标URL的多个服务提供者的访问地址写入所述目标节点中；在所述目标模块节点下生成所述多个服务提供者对应的服务节点。在本申请实施例中，采用上述目录结构进行服务注册，无需在每个服务节点下均进行服务提供者URL的注册，可以在模块节点下以URL为单位对服务提供者及其对应的服务节点进行划分集成从而进行服务注册，无需按照服务的粒度进行服务注册，从而有效提高了服务注册的效率。

Description

服务注册方法、装置和设备

技术领域

本申请涉及数据处理技术领域，特别涉及一种服务注册方法、装置和设备。

背景技术

为了适应业务的快速增长和系统的迭代更新，系统逐渐从集中的架构转向分布式的微服务架构，微服务架构有效解决了集中式架构中的性能扩展、敏捷迭代升级等问题。但是由于大型国有商业银行企业的系统规模往往很大，所有产品系统的交易数有时会多达几万个，如果将所有交易接口全部服务化，注册中心的服务接口配置规模将会相当大，使得系统在启动时初始化时间很长。

现有技术中通常采用分布式服务框架来实现服务注册，而分布式服务框架中是按照服务的粒度注册动态URL节点，即每个服务都要注册自己的URL，因此，每次初始化重启时，系统均需要注册大量的URL，从而导致系统的服务注册效率较低。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种服务注册方法、装置和设备，以解决现有技术中系统的服务注册效率较低的问题。

本申请实施例提供了一种服务注册方法，包括：在目标系统初始化时，在预设的注册目录中创建多个模块节点；在所述多个模块节点中的目标模块节点下创建目标节点；将归属于目标URL的多个服务提供者的访问地址写入所述目标节点中；在所述目标模块节点下生成所述多个服务提供者对应的服务节点。

在一个实施例中，所述服务节点为持久化节点，所述目标节点为临时节点。

在一个实施例中，在所述目标模块节点下生成所述多个服务提供者对应的服务节点，包括：获取所述目标系统的注册信息；根据所述注册信息，确定归属于目标URL的多个服务提供者对应的服务节点是否已在所述目标模块节点下注册过；在确定注册过的情况下，在所述目标模块节点下生成已注册过的服务节点。

在一个实施例中，在确定归属于目标URL的多个服务提供者对应的服务节点是否已在所述目标系统中注册过之后，还包括：在确定没有注册过的情况下，获取归属于目标URL的多个服务提供者对应的服务节点的注册信息；根据所述注册信息，在所述目标模块节点下注册归属于目标URL的多个服务提供者对应的服务节点。

在一个实施例中，在所述目标模块节点下生成所述多个服务提供者对应的服务节点之后，还包括：目标服务消费者订阅所述目标节点下服务提供者的访问地址；在所述目标服务提供者对应的服务节点下写入所述目标服务消费者的访问地址。

在一个实施例中，在所述目标模块节点下生成所述多个服务提供者对应的服务节点之后，还包括：确定所述模块节点是否出现异常状态，其中，所述异常状态包括以下至少之一：重启、宕机、节点新增或删除；在确定所述模块节点出现异常状态的情况下，重新注册目标节点。

本申请实施例还提供了一种服务注册装置，包括：第一创建模块，用于在目标系统初始化时，在预设的注册目录中创建多个模块节点；第二创建模块，用于在所述多个模块节点中的目标模块节点下创建目标节点；写入模块，用于将归属于目标URL的多个服务提供者的访问地址写入所述目标节点中；生成模块，用于在所述目标模块节点下生成所述多个服务提供者对应的服务节点。

在一个实施例中，所述生成模块，包括：第一获取单元，用于获取所述目标系统的注册信息；确定单元，用于根据所述注册信息，确定归属于目标URL的多个服务提供者对应的服务节点是否已在所述目标模块节点下注册过；处理单元，用于在确定注册过的情况下，在所述目标模块节点下生成已注册过的服务节点。

在一个实施例中，还包括：第二获取单元，用于在确定没有注册过的情况下，获取归属于目标URL的多个服务提供者对应的服务节点的注册信息；注册单元，用于根据所述注册信息，在所述目标模块节点下注册归属于目标URL的多个服务提供者对应的服务节点。

本申请实施例还提供了一种服务注册设备，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现所述服务注册方法的步骤。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现所述服务注册方法的步骤。

本申请实施例提供了一种服务注册方法，可以通过在目标系统初始化时，在预设的注册目录中创建多个模块节点。并在多个模块节点中的目标模块节点下创建目标节点，将归属于目标URL的多个服务提供者的访问地址写入目标节点中，从而可以在模块节点下以URL为单位对服务提供者及其对应的服务节点进行划分集成从而进行服务注册，无需按照服务的粒度进行服务注册，从而有效减少了数据处理。进一步的，可以在目标模块节点下生成多个服务提供者对应的服务节点，由此可见，采用上述目录结构进行服务注册，无需在每个服务节点下均进行服务提供者URL的注册，有效提高了服务注册的效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，并不构成对本申请的限定。在附图中：

图1是根据本申请实施例提供的现有技术中服务注册的目录结构图；

图2是根据本申请实施例提供的服务注册方法的步骤示意图；

图3是根据本申请实施例提供的目录结构的示意图；

图4是根据本申请实施例提供的服务注册的基本流程的示意图；

图5是根据本申请实施例提供的服务注册装置的结构示意图；

图6是根据本申请实施例提供的服务注册设备的结构示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本申请的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。相反，提供这些实施方式是为了使本申请公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域的技术人员知道，本申请的实施方式可以实现为一种系统、装置设备、方法或计算机程序产品。因此，本申请公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

虽然下文描述流程包括以特定顺序出现的多个操作，但是应该清楚了解，这些过程可以包括更多或更少的操作，这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。

现有技术中通常采用分布式服务框架来实现服务注册，而分布式服务框架中是按照服务的粒度注册动态URL节点，即每个服务都要注册自己的URL。其中，上述URL(UniformResource Locator，统一资源定位符)，又叫做网页地址，是IP地址和端口的简称，是互联网上标准的资源的地址，互联网上的每个文件都有一个唯一的URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它。具体的，现有技术中服务注册的目录结构图可以如图1中所示，所有的服务节点下都有自己的服务提供者、消费者的URL，即每次初始化重启的时候每个服务都需要重新注册各自节点下的服务提供者、消费者的URL(IP和端口)，系统需要注册大量的URL，从而导致系统的服务注册效率较低。

基于以上问题，本发明实施例提供了一种服务注册方法，如图2所示，可以包括以下步骤：

S202：在目标系统初始化时，在预设的注册目录中创建多个模块节点。

在系统宕机重启或者关机重启等情况下，均需要对目标系统进行初始化。在对目标系统进行初始化时需要根据实际情况进行参数的设置或注册，并录入基础档案与初始数据。因此，在目标系统初始化时需要给定一个预设的注册目录，上述预设注册目标可以用于表征目标系统初始化时相关数据的存储路径，例如：E:\boc。

在一个实施例中，在目标系统初始化时，可以在预设的注册目录中创建多个模块节点，其中，不同的模块节点中包括的是不同的URL可提供的服务、服务提供者的URL以及服务消费者的URL。其中，不同的URL对应不同的计算机设备。

对应上述预设的注册目录的存储路径，本申请中模块节点的存储路径可以为：E:\boc\corebank。因此，在本实施例中可以以模块节点为单位对服务提供者及其对应的服务节点进行划分集成从而进行服务注册，无需按照服务的粒度注册URL节点。

S204：在多个模块节点中的目标模块节点下创建目标节点。

为了能在模块节点下区分服务提供者和服务消费者，在一个实施例中，可以在多个模块节点中的目标模块节点下创建目标节点，上述目标节点可以用于写入服务提供者的URL，即不需要每个服务节点都注册服务提供者的URL，而仅需要在目标节点中注册服务提供者的URL。优选的目标模块节点下的目标节点可以为一个，当然在一些情况下可以设置更多的目标节点，具体的可以根据实际情况确定，本申请对此不作限定。

由于目标节点下的服务提供者URL存在动态变化的情况，因此，在一个实施例中可以将上述目标节点设置为临时节点。其中，临时节点的生命周期依赖于会话，一旦会话结束，这个节点就会被删除。对应上述模块节点的存储路径，上述目标节点的存储路径可以为：E:\boc\corebank\providers。

S206：将归属于目标URL的多个服务提供者的访问地址写入目标节点中。

在创建得到目标节点之后可以根据URL对服务提供者进行划分，即可以将归属于同一个IP地址和端口(计算机设备)的服务提供者划分为一类，可以理解的是，归属于同一个URL的服务提供者的访问地址可以是相同的，相较于现有技术中为每一个服务提供者注册一个访问地址的方式，可以有效减少系统在初始化时的数据处理量。进一步的，可以将归属于目标URL的多个服务提供者的访问地址写入目标节点中，从而完成服务提供者URL节点的注册。

在一个实施例中，可以采用分布式方式进行服务注册，具体的可以采用：Eureka、ZooKeeper等方式来实现微服务的集群管理与服务注册。其中，上述Eureka是用于实现服务注册和发现的工具；上述ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和HBase的重要组件，它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。上述微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块为基础，利用模组化的方式组合出复杂的大型应用程序。

S208：在目标模块节点下生成多个服务提供者对应的服务节点。

在一个实施例中，可以在上述目标节点下生产多个服务提供者对应的服务节点，每个服务提供者都可以对应提供一个服务，可以采用服务节点来供服务消费者订阅该服务，即不同的服务节点可以提供不同类型的服务，例如：余额查询、存款、转账、历史交易查询等服务。其中，上述服务节点用于写入服务消费者的URL。

由于系统中可提供的服务一般是固定不变的，即使发生变化也是比较小范围的变化，可以直接通过脚本实现节点的删除或者增加。因此，在一个实施例中可以将上述服务节点设置为持久化节点，其中，持久化节点生命周期不依赖于会话，只有通过delete命令显示操作时，才会删除。即持久化节点是一次注册永久使用，无需每次初始化时都注册服务节点，有效提高了服务注册的效率。对应上述模块节点的存储路径，上述服务节点的存储路径可以为：E:\boc\corebank\com.bocsoft.accountService。

因此，在一个实施例中可以先获取目标系统中的注册信息，并根据注册信息确定归属于目标URL的多个服务提供者对应的服务节点是否已在目标模块节点下注册过，在确定已注册过的情况下，可以直接根据注册信息在目标模块节点下生成已注册的服务节点，无需再进行注册。

在一些情况下，如果目标系统中新增服务或者首次对目标系统进行初始化时，可以获取归属于目标URL的多个服务提供者对应的服务节点的注册信息，其中，上述注册信息可以包括：服务的基本信息和配置信息。进一步的，可以根据注册信息，在目标模块节点下注册归属于目标URL的多个服务提供者对应的服务节点。在生成多个服务提供者对应的服务节点之后，可以结束服务注册流程。在一个具体的实施例中，服务注册的目录结构图可以如图3中所示。

可以理解的上述过程虽然是以目标模块节点为示例阐述的，但是其它模块节点的初始化过程与目标模块节点是相同的，具体的可参见目标模块节点的初始化过程，本申请实施例对此不再赘述。

在一个实施例中，可以监测上述模块节点是否出现异常状态，其中，上述异常状态可以包括但不限于以下至少之一：重启、宕机、节点新增或删除，在出现异常状态的情况下，可以重新注册上述目标节点。

在一个实施例中，在生成多个服务提供者对应的服务节点之后，目标服务消费者可以订阅上述目标节点下的服务提供者的访问地址，并在目标服务提供者对应的服务节点下写入上述目标服务消费者的访问地址。

在采用ZooKeeper来实现微服务的集群管理与服务注册时，服务注册的基本流程可以如图4中所示，具体的，注册中心在完成对目标节点的注册后可以返回服务地址提供者列表给服务消费者，如果模块节点有变更(模块节点重启，或是异常宕机、增加删除模块节点等)，注册中心将基于长连接推送变更数据给服务消费者(遍历目标模块节点下所有服务节点中的服务消费者URL节点)。服务消费者可以从提供者地址列表中，基于负载均衡算法选一个服务提供者URL调用，如果调用失败再选另一个调用。

从以上的描述中，可以看出，本申请实施例实现了如下技术效果：可以通过在目标系统初始化时，在预设的注册目录中创建多个模块节点。并在多个模块节点中的目标模块节点下创建目标节点，将归属于目标URL的多个服务提供者的访问地址写入目标节点中，从而可以在模块节点下以URL为单位对服务提供者及其对应的服务节点进行划分集成从而进行服务注册，无需按照服务的粒度进行服务注册，从而有效减少了数据处理。进一步的，可以在目标模块节点下生成多个服务提供者对应的服务节点，由此可见，采用上述目录结构进行服务注册，无需在每个服务节点下均进行服务提供者URL的注册，有效提高了服务注册的效率。

基于同一发明构思，本申请实施例中还提供了一种服务注册装置，如下面的实施例。由于服务注册装置解决问题的原理与服务注册方法相似，因此服务注册装置的实施可以参见服务注册方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图5是本申请实施例的服务注册装置的一种结构框图，如图5所示，可以包括：第一创建模块501、第二创建模块502、写入模块503、生成模块504，下面对该结构进行说明。

第一创建模块501，可以用于在目标系统初始化时，在预设的注册目录中创建多个模块节点。

第二创建模块502，可以用于在多个模块节点中的目标模块节点下创建目标节点。

写入模块503，可以用于将归属于目标URL的多个服务提供者的访问地址写入目标节点中。

生成模块504，可以用于在目标模块节点下生成多个服务提供者对应的服务节点。

在一个实施例中，上述生成模块可以包括：第一获取单元，用于获取目标系统的注册信息；确定单元，用于根据注册信息，确定归属于目标URL的多个服务提供者对应的服务节点是否已在目标模块节点下注册过；处理单元，用于在确定注册过的情况下，在目标模块节点下生成已注册过的服务节点。

在一个实施例中，上述服务注册装置还可以包括：第二获取单元，用于在确定没有注册过的情况下，获取归属于目标URL的多个服务提供者对应的服务节点的注册信息；注册单元，用于根据注册信息，在目标模块节点下注册归属于目标URL的多个服务提供者对应的服务节点。

本申请实施方式还提供了一种电子设备，具体可以参阅图6所示的基于本申请实施例提供的服务注册方法的电子设备组成结构示意图，电子设备具体可以包括输入设备61、处理器62、存储器63。其中，输入设备61具体可以用于输入预设的注册目录。处理器62具体可以用于在目标系统初始化时，在预设的注册目录中创建多个模块节点；在多个模块节点中的目标模块节点下创建目标节点；将归属于目标URL的多个服务提供者的访问地址写入目标节点中；在目标模块节点下生成多个服务提供者对应的服务节点。存储器63具体可以用于存储多个服务提供者的访问地址、服务节点等参数。

在本实施方式中，输入设备具体可以是用户和计算机系统之间进行信息交换的主要装置之一。输入设备可以包括键盘、鼠标、摄像头、扫描仪、光笔、手写输入板、语音输入装置等；输入设备用于把原始数据和处理这些数的程序输入到计算机中。输入设备还可以获取接收其他模块、单元、设备传输过来的数据。处理器可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(ApplicationSpecific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式等等。存储器具体可以是现代信息技术中用于保存信息的记忆设备。存储器可以包括多个层次，在数字系统中，只要能保存二进制数据的都可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也叫存储器，如RAM、FIFO等；在系统中，具有实物形式的存储设备也叫存储器，如内存条、TF卡等。

在本实施方式中，该电子设备具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

本申请实施方式中还提供了一种基于服务注册方法的计算机存储介质，计算机存储介质存储有计算机程序指令，在计算机程序指令被执行时可以实现：在目标系统初始化时，在预设的注册目录中创建多个模块节点；在多个模块节点中的目标模块节点下创建目标节点；将归属于目标URL的多个服务提供者的访问地址写入目标节点中；在目标模块节点下生成多个服务提供者对应的服务节点。

在本实施方式中，上述存储介质包括但不限于随机存取存储器(Random AccessMemory,RAM)、只读存储器(Read-Only Memory,ROM)、缓存(Cache)、硬盘(Hard DiskDrive,HDD)或者存储卡(Memory Card)。存储器可以用于存储计算机程序指令。网络通信单元可以是依照通信协议规定的标准设置的，用于进行网络连接通信的接口。

在本实施方式中，该计算机存储介质存储的程序指令具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

虽然本申请提供了如上述实施例或流程图的方法操作步骤，但基于常规或者无需创造性的劳动在方法中可以包括更多或者更少的操作步骤。在逻辑性上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。的方法的在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

应该理解，以上描述是为了进行图示说明而不是为了进行限制。通过阅读上述描述，在所提供的示例之外的许多实施方式和许多应用对本领域技术人员来说都将是显而易见的。因此，本申请的范围不应该参照上述描述来确定，而是应该参照前述权利要求以及这些权利要求所拥有的等价物的全部范围来确定。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请实施例可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (11)

1.一种服务注册方法，其特征在于，包括：

在目标系统初始化时，在预设的注册目录中创建多个模块节点；

在所述多个模块节点中的目标模块节点下创建目标节点；

将归属于目标URL的多个服务提供者的访问地址写入所述目标节点中；其中，所述归属于目标URL的多个服务提供者的访问地址均与所述目标URL相同；

在所述目标模块节点下生成所述多个服务提供者对应的服务节点，所述服务节点是用于进行注册的URL节点。

2.根据权利要求1所述的方法，其特征在于，所述服务节点为持久化节点，所述目标节点为临时节点。

3.根据权利要求1所述的方法，其特征在于，在所述目标模块节点下生成所述多个服务提供者对应的服务节点，包括：

获取所述目标系统的注册信息；

根据所述注册信息，确定归属于目标URL的多个服务提供者对应的服务节点是否已在所述目标模块节点下注册过；

在确定注册过的情况下，在所述目标模块节点下生成已注册过的服务节点。

4.根据权利要求3所述的方法，其特征在于，在确定归属于目标URL的多个服务提供者对应的服务节点是否已在所述目标系统中注册过之后，还包括：

在确定没有注册过的情况下，获取归属于目标URL的多个服务提供者对应的服务节点的注册信息；

根据所述注册信息，在所述目标模块节点下注册归属于目标URL的多个服务提供者对应的服务节点。

5.根据权利要求1所述的方法，其特征在于，在所述目标模块节点下生成所述多个服务提供者对应的服务节点之后，还包括：

目标服务消费者订阅所述目标节点下服务提供者的访问地址；

在所述目标服务提供者对应的服务节点下写入所述目标服务消费者的访问地址。

6.根据权利要求1所述的方法，其特征在于，在所述目标模块节点下生成所述多个服务提供者对应的服务节点之后，还包括：

确定所述模块节点是否出现异常状态，其中，所述异常状态包括以下至少之一：重启、宕机、节点新增或删除；

在确定所述模块节点出现异常状态的情况下，重新注册目标节点。

7.一种服务注册装置，其特征在于，包括：

第一创建模块，用于在目标系统初始化时，在预设的注册目录中创建多个模块节点；

第二创建模块，用于在所述多个模块节点中的目标模块节点下创建目标节点；

写入模块，用于将归属于目标URL的多个服务提供者的访问地址写入所述目标节点中；其中，所述归属于目标URL的多个服务提供者的访问地址均与所述目标URL相同；

生成模块，用于在所述目标模块节点下生成所述多个服务提供者对应的服务节点，所述服务节点是用于进行注册的URL节点。

8.根据权利要求7所述的装置，其特征在于，所述生成模块，包括：

第一获取单元，用于获取所述目标系统的注册信息；

确定单元，用于根据所述注册信息，确定归属于目标URL的多个服务提供者对应的服务节点是否已在所述目标模块节点下注册过；

处理单元，用于在确定注册过的情况下，在所述目标模块节点下生成已注册过的服务节点。

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

第二获取单元，用于在确定没有注册过的情况下，获取归属于目标URL的多个服务提供者对应的服务节点的注册信息；

注册单元，用于根据所述注册信息，在所述目标模块节点下注册归属于目标URL的多个服务提供者对应的服务节点。

10.一种服务注册设备，其特征在于，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现权利要求1至6中任一项所述方法的步骤。

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

Images