CN115297156A - 一种微服务注册系统以及微服务注册方法 - Google Patents

Abstract

本发明公开一种微服务注册系统以及微服务注册方法。其中一实施例的微服务注册系统，包括服务提供端、服务注册端以及与用户终端连接的服务消费端，服务提供端用于向所述服务注册端发出注册请求，服务提供端包括发出具有标记的第一注册请求的第一提供端和发出不具有标记的第二注册请求的第二提供端，所述服务注册端用于根据接收的所述第一注册请求和所述第二注册请求生成注册信息，所述服务消费端用于拉取所述注册信息，并对用户终端的业务请求进行区分，将区分后的所述业务请求输出至与所述业务请求对应的所述注册信息中的所述第一提供端或所述第二提供端。本发明实施例的系统能够实现测试子模块新功能的同时，保证注册系统的平稳运行。

Description

一种微服务注册系统以及微服务注册方法

技术领域

本发明涉及微服务注册领域。更具体地，涉及一种微服务注册系统以及微服务注册方法。

背景技术

目前，许多企业都有服务器集群，服务器集群由大量业务服务器组成，为用户提供服务。在微服务架构中，服务注册中心是服务发现中不可缺少的一部分，作为一个存储网络实例的网络地址和数据库，服务注册中心应该是高可用的、且数据保持最新状态。目前，Netflix Eureka是服务注册中心的一个很好的实例，Eureka是Netflix开发的服务发现框架，本身是一个基于REST 的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。

然而随着业务的发展，系统建设不断增加，系统功能和复杂度也不断增大，传统的单体架构难以满足多业务的发展需求，因此需要将原来的单体服务拆分为多个微服务，以适用于多业务，一旦某个服务发生故障，则必然会影响整个系统的运行稳定性。

并且，例如，需要更新某个微服务中的子模块的业务，但由于该子模块在该微服务中无法分离，难以避免的会部署全部微服务，导致为了更新小功能不得不更新其所在微服务的全部功能，易造成部署风险，

因此，需要一种既能够让微服务运行稳定，又方便维护微服务的微服务注册系统。

发明内容

本发明的目的在于提供一种微服务注册系统以及微服务注册方法，以解决现有技术存在的问题中的至少一个。

为达到上述目的，本发明采用下述技术方案：

本发明第一方面提供了一种微服务注册系统，包括服务提供端、服务注册端以及与用户终端连接的服务消费端，其中，

所述服务提供端用于向所述服务注册端发出注册请求，所述服务提供端包括发出具有标记的第一注册请求的第一提供端和发出不具有标记的第二注册请求的第二提供端，

所述服务注册端用于根据接收的所述第一注册请求和所述第二注册请求生成注册信息，

所述服务消费端用于拉取所述注册信息，并根据用户终端的业务请求进行区分，将区分后的所述业务请求输出至与所述业务请求对应的所述注册信息中的所述第一提供端或所述第二提供端。

进一步的，所述服务消费端包括：

业务请求判断模块，用于判断所述用户终端的业务请求是具有标记的第一业务请求或者是不具有标记的第二业务请求，

第一业务请求输出端，用于将所述第一业务请求输出至所述注册信息中的所述第一提供端；以及

第二业务请求输出端，用于将所述第二业务请求输出至所述注册信息中的所述第二提供端。

进一步的，所述第一注册请求为基于灰度发布生成的，所述第一业务请求为基于灰度发布生成的。

进一步的，所述服务注册端包括多个服务注册模块，两个所述服务注册模块之间相互连接同步所有的注册信息，

所述服务注册模块包括第一内存和第二内存，其中，

所述第一内存用于存储各个所述服务提供端更新的注册信息，

所述第二内存用于存储未更新的注册信息；

进一步的，所述服务注册端还包括注册信息数据库，用于以异步存储的方式存储所述第一内存的注册信息和所述第二内存的注册信息。

进一步的，所述服务消费端还包括第三内存和第四内存，其中，

所述第三内存用于存储从所述服务提供端拉取的更新的所述注册信息，

所述第四内存用于存储从所述服务提供端拉取的未更新的注册信息。

进一步的，所述第一业务请求输出端还用于以预设的权重策略从所述注册信息中选择所述第一提供端，并向所选择的所述第一提供端输出所述第一业务请求，

所述权重策略为根据每一所述第一提供端的资源配置确定的；

所述第一提供端的资源配置包括CPU的品牌、CPU型号、内存、网络速度；

或者

所述第一提供端为多个时，第一业务请求输出端还用于通过轮询的方式从所述注册信息中选择所述第一提供端，并向所选择的所述第一提供端输出所述第一业务请求。

进一步的，所述服务提供端还用于根据接收的所述区分后的业务请求反馈熔断信息至所述服务消费端，

所述服务消费端还用于根据所述熔断信息连接另一所述服务提供端。

进一步的，所述服务注册端还用于以预设频率监控所述服务提供端的工作状态，若其中一所述服务提供端处于异常工作状态，则所述服务注册端在该监控时段删除该服务提供端的注册信息，

其中，若所述第一提供端在所述注册信息中的数量满足预设阈值，则所述服务注册端不再删除剩余的所述第一提供端的注册信息，若所述第二提供端在所述注册信息中的数量满足预设阈值，则所述服务注册端不再删除剩余的所述第二提供端的注册信息。

本发明第二方面提供了一种应用于本发明第一方面的系统的微服务注册方法，所述方法包括：

所述服务提供端向所述服务注册端发出注册请求，包括由所述第一提供端发出的第一注册请求和由所述第二提供端发出的第二注册请求，所述第一注册请求为基于灰度发布生成的，所述第二业务请求为基于灰度发布生成的；

服务注册端根据接收的所述第一注册请求和所述第二注册请求生成注册信息；以及

服务消费端拉取所述注册信息，并根据所述用户终端的业务请求进行区分，将区分后的所述业务请求输出至与所述业务请求对应的所述注册信息中的所述第一提供端或所述第二提供端。

本发明的有益效果如下：

本发明所述技术方案，对服务提供端进行设计，使得服务提供端能够提供不同的注册请求，并且还对服务消费端进行设计，使得服务消费端能够输出不同的业务请求，服务注册端根据不同的注册请求生成注册信息，供服务消费端根据不同的业务请求向对应于该业务请求的服务消费端建立连接，根据该设置，本发明实施例能够实现测试子模块新功能的同时，保证注册系统的平稳运行，降低注册服务系统的维护成本，提高运行稳定性，具有广泛的应用前景。

附图说明

下面结合附图对本发明的具体实施方式作进一步详细的说明。

图1示出本发明一个实施例的微服务注册系统的架构示意图；

图2示出本发明实施例的微服务注册系统与用户终端进行交互时的甬道图；

图3示出本发明实施例的服务消费端与用户终端进行交互时的框架示意图；

图4示出本发明实施例以第一业务请求为具体示例的与用户终端进行交互时的流程示意图；

图5示出本发明一个具体示例的服务消费端和服务提供端的框架示意图；

图6示出本发明实施例的服务注册端的框架示意图；

图7示出本发明另一个实施例的微服务注册的流程示意图；

图8示出本发明实施例的步骤S702的流程示意图；

图9示出本发明实施例的步骤S705的流程示意图；

图10示出本发明另一个实施例的微服务注册的流程示意图。

具体实施方式

为了更清楚地说明本发明，下面结合实施例和附图对本发明做进一步的说明。附图中相似的部件以相同的附图标记进行表示。本领域技术人员应当理解，下面所具体描述的内容是说明性的而非限制性的，不应以此限制本发明的保护范围。

如图1、图2以及图7所示，本发明第一个实施例提出一种微服务注册系统，该系统包括：服务提供端、服务注册端以及与用户终端连接的服务消费端，其中，

所述服务提供端用于向所述服务注册端发出注册请求，所述服务提供端包括发出具有标记的第一注册请求的第一提供端和发出不具有标记的第二注册请求的第二提供端，

所述服务注册端用于根据接收的所述第一注册请求和所述第二注册请求生成注册信息，

所述服务消费端用于拉取所述注册信息，并根据用户终端的业务请求进行区分，将区分后的所述业务请求输出至与所述业务请求对应的所述注册信息中的所述第一提供端或所述第二提供端。

本实施例中，对服务提供端进行设计，使得服务提供端能够提供不同的注册请求，并且还对服务消费端进行设计，使得服务消费端能够输出不同的业务请求，服务注册端根据不同的注册请求生成注册信息，供服务消费端根据不同的业务请求向对应于该业务请求的服务消费端建立连接，根据该设置，本发明实施例能够实现测试子模块新功能的同时，保证注册系统的平稳运行，降低注册服务系统的维护成本，提高运行稳定性，具有广泛的应用前景。

在一个具体示例中，本实施例的微服务注册系统可应用于对微服务的新功能测试阶段，例如，需要更新某个微服务中的子模块的业务单元，或者新增某个微服务的业务时，为了实现服务更新和保证其他功能正常使用，例如，让服务消费端能够正常使用该子模块，同时对该子模块的功能进行升级，利用本发明实施例的微服务注册系统则能够实现两个功能的兼顾。

本实施例中，服务提供端用于提供服务，在启动时，根据服务发布文件中的配置的信息，向服务注册端注册自身服务。本实施例的服务提供端包括第一提供端和第二提供端，两个提供端的区别在于所发出的注册请求是否具有标记。

示例性的，第二提供端所提供的功能是根据身份证号查询身份信息，是当前的微服务注册系统已经验证好能够正常使用的。在第二提供端的原有功能的基础上，第一提供端需要新增的功能是根据身份证号查询手机账号，是当前的微服务注册系统还没有正式使用的，需要进行测试的功能。第一提供端和第二提供端均能够正常发出注册请求，因此，本发明实施例通过将第一提供端和第二提供端以是否标记的方式进行区别，使得传输到服务注册端的注册请求不会会产生混淆。

在一个可选的实施例中，所述第一注册请求为基于灰度发布生成的。灰度发布又名金丝雀发布，是实现应用服务滚动发布的一种手段，在应用服务的功能没有得到充分验证的情况下，可以缩小客户影响的范围，确保在服务得到充分的验证、改进意见反馈后使应用服务功能得到充分的优化后再推广到全部客户。

本实施例基于Spring Cloud Eureka的注册中心的微服务注册系统，在第一提供端输出注册请求时，能够通过扩展源数据(META-DATA)信息 CANARYA作为灰度发布标识，即，标记该注册请求为具有金丝雀标记(CANARYA标识)的第一注册请求，从而实现第一注册请求和第二注册请求的区分，保证用于测试的第一注册请求和应用该系统的第二注册请求均能够输出至服务注册端进行注册，兼顾新功能开发和正常使用的稳定运行。

本实施例中，服务注册端用于根据接收的所述第一注册请求和所述第二注册请求生成注册信息并存储。示例性的，服务注册端所接收的注册信息包括根据前述的用于测试的第一注册请求生成的第一注册信息，以及根据前述的用于正常使用的第二注册请求生成的第二注册信息。示例性的，注册信息以服务列表的方式输出至服务消费端和缓存。

服务消费端用于从服务注册端拉取全部的注册信息并调用服务，在启动时，根据服务引用文件中配置的信息，向服务注册端输出订阅服务请求，把服务注册端返回的注册信息缓存在本地内存中，并与注册信息中的服务提供端建立连接。在一个具体示例中，服务消费端以非jason语句或者Key-Value 的格式进行注册信息的数据调用。

在一个可选的实施例中，如图3和图9所示，所述服务消费端包括：

业务请求判断模块，用于判断所述用户终端的业务请求是具有标记的第一业务请求或者是不具有标记的第二业务请求，

第一业务请求输出端，用于将所述第一业务请求输出至所述注册信息中的所述第一提供端；以及

第二业务请求输出端，用于将所述第二业务请求输出至所述注册信息中的所述第二提供端。

本实施例的两个业务请求输出端的区别在于所发出的注册请求是否具有标记。

示例性的，如图3和图9所示，第二业务请求输出端接收的业务请求是来自正常使用的用户终端，例如，购买当前微服务产品的消费者。第一业务请求输出端接收的业务请求是来自用于进行测试的用户终端，例如，对当前更新功能进行测试的开发者。第一业务请求输出端和第二业务请求输出端均能够发出业务请求，因此，本发明实施例通过将第一业务请求输出端和第二业务请求输出端以是否标记的方式进行区别，利用业务请求判断模块判断所述用户终端的业务请求是具有标记的第一业务请求或者是不具有标记的第二业务请求，使得与服务注册端以及与服务提供端进行交互时不会产生混淆。

进一步的，在一个可选的实施例中，所述第一业务请求为基于灰度发布生成的。也就是说，正常使用的用户终端输出的业务请求经业务请求判断模块判断后，会识别为不具有标记的第二业务请求，由第二业务请求输出端将该第二业务请求输出到第二提供端进行调用。而用于测试的用户端输出的业务请求经业务请求判断模块判断后，则会识别为具有标记的第一业务请求，由第一业务请求输出端将该第一业务请求输出到第一提供端进行调用。

本实施例中，由于所述第一注册请求和所述第一业务请求均为基于灰度发布生成的，因此，第一业务请求输出端能够准确地选择同样具有灰度发布的第一提供端进行调用，即在应用服务提供端和服务消费端交互的过程中，用于测试的第一业务请求输出端所输出的第一业务请求中设置CANARYA标识，标记该请求为测试请求，并将该测试请求转发到带有CANARYA标识的第一提供端中，由带有CANARYA标识的第一提供端完成业务处理。本实施例中，微服务注册系统下，基于灰度发布的CANARYA标记会随请求传递，保证测试客户的业务处理在金丝雀服务的第一提供端间完成，从而兼顾新功能开发和正常使用的稳定运行。

值得说明的是，本实施例的第一业务请求以及第一注册请求包括但不限于测试环境，例如，还能应用于对体验客户和购买客户等客户类型的区分等等，从而实现根据用户端的不同进行区别以及实现对应于每一类用户端的单独的微服务交互通道，从而实现多种功能以及系统的运行稳定性的兼顾。

示例性的，当服务提供端的状态发生变更时，例如，其中一个提供端无法提供原有的功能，服务注册端会同步变更，服务客户端会根据更新的注册信息选择另一个服务提供端发起调用。

在一个可选的实施例中，如图2和图8所示，所述服务注册端还用于以预设频率监控所述服务提供端的工作状态，所述服务提供端根据所述服务注册端的监控指令反馈存活状态。

示例性的，所述服务注册端以30s为周期向服务提供端发送监控指令，确认各个服务提供端的状态，若服务提供端的功能正常，则服务提供端会发送心跳续约自己的“租期”，即在下一监控指令到来前，服务注册端的注册信息不会发生变化。

在一个可选的实施例中，若其中一所述服务提供端处于异常工作状态，则所述服务注册端在该监控时段删除该服务提供端的注册信息。示例性的，若存在出现异常的服务提供端，例如，多个第一提供端中的一个或几个出现异常，则注册服务端在该监控周期内不会接收到异常的第一提供端的心跳，注册服务端将会从注册信息列表中把异常的第一提供端该移除。在一个具体示例中，注册服务端移除同一异常状态的服务提供端的间隔设置为90秒，即 90秒以后，注册服务端可以将该注册服务端的注册信息重新添加，重新监控。

在一个可选的实施例中，如图8所示，以第一提供端为例，若所述第一提供端在所述注册信息中的数量满足预设阈值，则所述服务注册端不再删除剩余的所述第一提供端的注册信息，若所述第一提供端在所述注册信息中的数量不满足预设阈值，则所述服务注册端在该监控时段继续删除所述第一提供端的注册信息。

在一个另可选的实施例中，若所述第二提供端在所述注册信息中的数量满足预设阈值，则所述服务注册端不再删除剩余的所述第二提供端的注册信息，若所述第二提供端在所述注册信息中的数量不满足预设阈值，则所述服务注册端在该监控时段继续删除所述第二提供端的注册信息。

示例性的，以预设阈值为1为例，对于第二提供端，如果较多的第二提供端在当前的监控周期中均处于异常状态，服务注册端将其注册信息进行删除，如果删除到只剩一个第二提供端的注册信息，则当前的第二提供端的注册信息不会被删除，通过该保护机制，确保微服务注册系统的正常运行。

该预设阈值由本领域技术人员根据实际应用进行设计，在此不再赘述。值得说明的是，第一提供端的注册信息和第二提供端的注册信息的保护机制同理，在此不再赘述。

在一个可选的实施例中，如图4和图9所示，所述第一业务请求输出端还用于以预设的权重策略从所述注册信息中选择所述第一提供端，并向所选择的所述第一提供端输出所述第一业务请求，所述权重策略为根据每一所述第一提供端的资源配置确定的。

本实施例通过设置权重策略，在实现第一业务请求端和第一提供端的定向调用的基础上，能够进一步考虑到第一提供端的服务能力，在实现系统稳定运行的基础上，进一步提高了资源利用率。

在一个具体示例中，如图5所示，当第一提供端和第一业务请求输出端均有多个时，经业务请求判断模块判定后为第一业务请求的，从第一业务请求输出端输出，示例性的，如图4所示，业务请求判断模块同样用于以预设的权重策略选择所述第一业务请求输出端，例如，第一业务请求输出端包括 A1、A2以及A3，根据各个第一业务请求输出端的资源配置得到的各第一业务请求输出端的权重为：A1为30％，A2为40％以及A3为30％，根据该权重策略选择对应的第一业务请求输出端进行第一业务请求的输出。

示例性的，由第一业务请求输出端A2输出第一业务请求为例，第一提供端包括B1、B2以及B3，根据各个第一提供端的资源配置得到的各第一提供端的权重为：B1为40％，B2为40％以及B3为20％，根据该权重策略选择对应的第一提供端进行第一业务请求的服务调用。

在一个可选的实施例中，所述第一提供端的资源配置包括CPU的品牌、 CPU型号、内存或网络速度中的一种或几种。也就是说，本实施例能够根据各个第一提供端自身的服务性能进行第一业务请求分配上的优化，如图5所示，三个第一提供端包括B1、B2以及B3中，B2的权重最高，则表示第一提供端B2性能相对于其他的第一提供端性能较好，单位时间内处理速度较快，接收的第一请求数量较多。

在另一个实施例中，第一业务请求端的资源配置包括CPU的品牌、CPU 型号、内存或网络速度中的一种或几种。同样的，该设置能够根据各个第一业务请求端自身的服务性能进行第一业务请求分配上的优化，从而实现微服务注册系统的高资源利用率。

在另一个可选的实施例中，所述第一提供端为多个时，第一业务请求输出端还用于通过轮询的方式从所述注册信息中选择所述第一提供端，并向所选择的所述第一提供端输出所述第一业务请求。示例性的，仍以图5所示的三个第一提供端B1、B2以及B3为例，则，第一业务请求输出端调用第一提供端的轮询顺序可为B1、B2以及B3，又例如，B1、B3以及B2。

示例性的，在另一个可选的实施例中，所述第一业务请求输出端为多个时，业务请求判断模块还用于通过轮询的方式选择所述第一业务请求输出端。示例性的，仍以图5所示的三个第一业务请求输出端A1、A2以及A3为例，则，第一业务请求输出的轮询顺序可为A1、A2以及A3，又例如，A1、A3 以及A2。

在另一个可选的实施例中，所述业务请求判断模块以预设权重策略以及预设轮询顺序选择输出第一业务请求的第一业务请求输出端，所述业务请求判断模块以预设权重策略以及预设轮询顺序选择第一提供端进行调用。

示例性的，仍以图5所示的三个第一业务请求输出端A1、A2以及A3，各第一业务请求输出端的权重为：A1为30％，A2为40％以及A3为30％，第一提供端包括B1、B2以及B3，根据各个第一提供端的资源配置得到的各第一提供端的权重为：B1为40％，B2为40％以及B3为20％为例。若在一定时间内，经业务请求判断单元判断后的第一业务请求为10次，那么根据A1、A2以及A3的轮询顺序，分配A1输出第一业务请求3次后，分配A2输出第一业务请求4次，再分配A3输出第一业务请求3次从而完成一个周期的轮询，再按照新的周期重新开始轮询分配第一业务请求。

第一提供端的选择同理，示例性的，根据B1、B2以及B3的轮询顺序，选择第一提供端B1进行调用4次后，再选择第一提供端B2进行调用4次后，然后选择第一提供端B3进行调用2次后从而完成一个周期的轮询调用，再按照新的周期重新开始轮询调用。

值得说明的是，本实施例的图5所示的第一业务请求输出端的数量以及第一提供端的数量仅为示例性说明，在此不再赘述。

基于上述实施例，业务请求判断模块采用不同的方式将判断后的第一业务请求选择第一业务请求输出端输出，第一业务请求输出端也可以采用不同的方式选择第一提供端进行调用，提高微服务注册系统的运行速度。

基于上述实施例，在一个可选的实施例中，第二业务请求输出端还用于以预设的权重策略从所述注册信息中选择所述第二提供端，并向所选择的所述第二提供端输出所述第二业务请求，所述权重策略为根据每一所述第二提供端的资源配置确定的。在一个可选的实施例中，所述第二提供端的资源配置包括CPU的品牌、CPU型号、内存、网络速度。

在另一个可选的实施例中，所述第二提供端为多个时，第二业务请求输出端还用于通过轮询的方式从所述注册信息中选择所述第二提供端，并向所选择的所述第二提供端输出所述第二业务请求。

在另一个可选的实施例中，所述业务请求判断模块以预设权重策略以及预设轮询顺序选择输出第二业务请求的第二业务请求输出端，所述业务请求判断模块以预设权重策略以及预设轮询顺序选择第二提供端进行调用。

如图5所示，当第二提供端包括B4、B5以及B6时，示例性的，各第二提供端的权重策略为B4为40％、B5为40％以及B6为20％。当第一业务请求输出端包括A4、A5以及A6时，示例性的，各第二提供端的权重策略为 A4为30％、A5为40％以及A6为30％。同前述可知，若在一定时间内，经业务请求判断单元判断后的第二业务请求为10次，那么根据A4、A5以及 A6的轮询顺序，分配A4输出第二业务请求3次后，分配A5输出第二业务请求4次，再分配A6输出第二业务请求3次从而完成一个周期的轮询，再按照新的周期重新开始轮询分配第二业务请求。

第二提供端的选择同理，示例性的，根据B4、B5以及B6的轮询顺序，选择第二提供端B4进行调用4次后，再选择第一提供端B5进行调用4次后，然后选择第一提供端B6进行调用2次后从而完成一个周期的轮询调用，再按照新的周期重新开始轮询调用。值得说明的是，关于第二业务请求端的选择以及关于第二提供端的调用可参照上述实施例的第一业务请求端的选择以及第一提供端的调用方式，相关流程以及原理在此不再赘述。

在一个可选的实施例中，所述服务提供端还用于根据接收的所述区分后的业务请求反馈熔断信息至所述服务消费端，所述服务消费端还用于根据所述熔断信息连接另一所述服务提供端。

本实施例中，如图4所示，以第一提供端为例，在一定时间内，其所接收的第一业务请求数量有限，因此，当该第一提供端的负载量已经满足最大的处理能力后，该第一提供端无法再处理多余的第一业务请求，此时，第一提供端向输出第一业务请求的第一业务请求输出端发出熔断信息，“告知”第一业务请求输出端当前调用的第一提供端无法进行服务，在一个可选的实施例中，所述服务消费端还用于将所述熔断信息反馈至所述用户终端，即图4 所示的第一业务请求输出端将所述熔断信息输出至用户终端，暂停当前用户终端的服务调用。在另一个可选的实施例中，所述服务消费端还用于根据所述熔断信息连接另一所述服务提供端，示例性的，当其他的第一提供端还具有额外的处理能力时，第一业务请求输出端将重新选择其他的第一提供端进行调用服务，实现对用户中断的业务请求的快速响应。第二提供端的熔断反馈原理和流程与第一提供端类似，在此不再赘述。

在一个可选的实施例中，如图6所示，所述服务注册端包括多个服务注册模块，两个所述服务注册模块之间相互连接同步所有的注册信息，

所述服务注册模块包括第一内存和第二内存，其中，

所述第一内存用于存储各个所述服务提供端更新的注册信息，

所述第二内存用于存储未更新的注册信息。

本实施例中，服务注册模块根据来自第一提供端和第二提供端的注册信息提供注册服务，各个节点启动后，会在服务注册模块中进行注册。在一个具体示例中，服务注册模块以服务注册表的方式存储所有可用的第一提供端和第二提供端的注册信息，示例性的，注册信息可以在显示界面中直观的看到。

本实施例中，注册信息存储在服务注册模块自身的第一内存和第二内存中。两服务注册模块之间通过复制的方式完成数据的同步，如图6所示，服务注册模块1、服务注册模块2以及服务注册模块3构成了一个注册服务模块集群，注册服务模块1和注册服务模块2之间同步数据，注册服务模块1和注册服务模块3之间同步数据，注册服务模块2和注册服务模块3之间同步数据.从而实现每一注册服务模块的数据同步。因此，即使其中一个服务注册模块宕机，其他的服务注册模块能够提供注册服务，确保了系统的高可用性、灵活性和运行稳定性。

进一步的，本实施例中，服务注册模块的注册信息根据是否更新缓存在不同的内存中，通过第一内存和第二内存的分级缓存机制，即将没有发生变化的注册信息存储在第二内存中，将发生变化的注册信息存储在第一内存中，在第一内存中进行临时缓存，避免大量数据更新后导致交互速度变慢，确保注册服务系统的高速稳定运行。

在一个可选的实施例中，如图6所示，所述服务注册端还包括注册信息数据库，用于以异步存储的方式存储所述第一内存的注册信息和所述第二内存的注册信息。

当其中一个服务注册模块中的某一节点发生宕机时，存储在第一内存和第二内存中的注册信息的数据会随之丢失。节点恢复和节点扩容会以增量的方式在微服务注册系统中同步信息，这样会带来瞬间大量的网络交互。为了避免这种瞬间大量的网络交互，本发明通过设置分级缓存机制以及异步数据存储方案辅助解决该问题，实现数据持久化的存储。即在服务提供端提供注册请求时，注册请求对应的注册信息在各级缓存中存储的同时会异步存储到数据库中，既能够保证大量数据存储的稳定性，又能避免系统宕机时数据的丢失。

在一个可选的实施例中，当所述服务注册模块发生恢复和扩容时，所述服务注册模块优先获取存储在所述注册信息数据库中的注册信息，所述服务消费端根据所述注册信息数据库中的注册信息进行服务提供端的调用。也就是说，所述服务注册模块发生恢复和扩容时，服务注册模块可能没有将最新的注册信息进行存储和各个服务注册模块之间的同步，因此，为了实现数据之间的同步以及服务提供端的正确调用，本实施例中，所述服务消费端根据所述注册信息数据库中的注册信息进行服务提供端的调用，即，根据服务注册模块没有发生恢复和扩容之前的注册信息进行服务提供端的调用，确保实现数据同步的一致性以及服务提供端的正确调用。

在一个可选的实施例中，所述服务注册模块在获取存储在所述注册信息数据库中的注册信息后，通过增量更新的方式同步各服务注册模块的数据，通过该设置，能够保持各服务注册模块的数据一致性，并以异步存储的方式存储更新所述注册信息数据库中的注册信息的数据。

在一个可选的实施例中，所述服务消费端还包括第三内存和第四内存，其中，所述第三内存用于存储从所述服务提供端拉取的更新的所述注册信息，所述第四内存用于存储从所述服务提供端拉取的未更新的注册信息。

本实施例中，通过对服务消费端设计注册信息缓存机制，即使所有的服务注册模块都宕机，服务消费端依然可以利用第一内存或第二内存中的注册信息调用服务提供端。进一步的，本实施例对服务消费端的内存同样进行分级缓存设计，本实施例中，注册信息根据是否更新缓存在不同的内存中，通过第三内存和第四内存的分级缓存机制，即将没有发生变化的注册信息存储在第三内存中，将发生变化的注册信息存储在第四内存中，在第三内存中进行临时缓存，避免大量数据更新后导致交互速度变慢，既能够保证大量数据存储的稳定性，又能避免系统宕机时数据的丢失。

基于上述实施例，本发明实施例的微服务注册系统能够根据客户类别以及测试需求实现服务的定向调用，通过异步存储以及分级存储的方式实现数据存储的持久化，通过注册服务模块的交互、灰度发布、定向调用、存储以及交互等方式使得该微服务注册系统具有高可用性、灵活性和可伸缩性。本实施例的基于Eureka的微服务系统能够实现业务应用服务的集成，极大的降低学习成本，有效提高开发效率，减少后期业务应用服务的维护成本，具有广泛的应用前景。

本发明另一个实施例提出一种应用于上述系统的微服务注册方法，如图7 所示，所述方法包括：

S701、所述服务提供端向所述服务注册端发出注册请求，包括由所述第一提供端发出的第一注册请求和由所述第二提供端发出的第二注册请求，所述第一注册请求为基于灰度发布生成的，所述第二业务请求为基于灰度发布生成的；

S703、服务注册端根据接收的所述第一注册请求和所述第二注册请求生成注册信息；以及

S705、服务消费端拉取所述注册信息，并根据所述用户终端的业务请求进行区分，将区分后的所述业务请求输出至与所述业务请求对应的所述注册信息中的所述第一提供端或所述第二提供端。

本实施例中，服务提供端能够提供不同的注册请求，服务消费端能够输出不同的业务请求，服务注册端根据不同的注册请求生成注册信息，供服务消费端根据不同的业务请求向对应于该业务请求的服务消费端建立连接，根据该设置，本发明实施例能够实现测试子模块新功能的同时，保证注册系统的平稳运行，降低注册服务系统的维护成本，提高运行稳定性，具有广泛的应用前景。

需要说明的是，本实施例提供的微服务注册方法的原理及流程与上述的微服务注册系统类似，相关之处可以参照上述说明，在此不再赘述。

在一个可选的实施例中，如图8所示，在步骤S703之前，即在“服务注册端根据接收的所述第一注册请求和所述第二注册请求生成注册信息”之前，所述方法还包括：

S702、所述服务注册端还用于以预设频率监控所述服务提供端的工作状态，若其中一所述服务提供端处于异常工作状态，则所述服务注册端在该监控时段删除该服务提供端的注册信息。

在一个具体示例中，如图8所示，该步骤S702具体包括：

S7021、所述服务注册端以预设频率输出监控指令监控所述服务提供端的工作状态；

S7023、根据所述服务提供端的反馈信息判断所述服务提供端是否处于异常工作状态，若其中一所述服务提供端处于异常工作状态，则所述服务注册端在该监控时段删除该异常的服务提供端的注册信息，若所述服务提供端没有处于异常工作状态，则所述服务注册端在该监控时段不删除该异常的服务提供端的注册信息；

S7025、判断删除后的所述服务提供端在所述注册信息中的数量是否满足预设阈值，若删除后的所述服务提供端在所述注册信息中的数量不满足预设阈值，则所述服务注册端在该监控时段继续删除所述服务提供端的注册信息。

以第一提供端为例，如图8所示，首先判断所述第一提供端在所述注册信息中的数量是否满足预设阈值，若所述第一提供端在所述注册信息中的数量满足预设阈值，则所述服务注册端不再删除剩余的所述第一提供端的注册信息，所述第一提供端在所述注册信息中的数量不满足预设阈值，则所述服务注册端继续删除剩余的所述第一提供端的注册信息，通过该保护机制，确保微服务注册系统的正常运行。

在一个可选的实施例中，如图9所示，步骤S705“服务消费端拉取所述注册信息，并根据所述用户终端的业务请求进行区分，将区分后的所述业务请求输出至与所述业务请求对应的所述注册信息中的所述第一提供端或所述第二提供端”进一步包括：

S7051、判断所述用户终端的业务请求是否具有标记，若是，则识别为具有标记的第一业务请求，若否，则识别为不具有标记的第二业务请求；

S7053、第二业务请求输出端将所述第二业务请求输出至所述注册信息中的所述第二提供端；

S7055、第一业务请求输出端将所述第一业务请求输出至所述注册信息中的所述第一提供端。

该步骤中，通过将第一业务请求输出端和第二业务请求输出端以是否标记的方式进行区别，利用业务请求判断模块判断所述用户终端的业务请求是具有标记的第一业务请求或者是不具有标记的第二业务请求，使得与服务注册端以及与服务提供端进行交互时不会产生混淆。

在一个可选的实施例中，如图10所示，该方法还包括：

S707、所述服务提供端根据接收的所述区分后的业务请求反馈熔断信息至所述服务消费端，

S709、所述服务消费端将所述熔断信息反馈至所述用户终端。

基于上述实施例，本发明实施例的微服务注册方法能够根据客户类别以及测试需求实现服务的定向调用，通过异步存储以及分级存储的方式实现数据存储的持久化，通过注册服务模块的交互、灰度发布、定向调用、存储以及交互等方式使得该微服务注册系统具有高可用性、灵活性和可伸缩性。本实施例的基于Eureka的微服务系统能够实现业务应用服务的集成，极大的降低学习成本，有效提高开发效率，减少后期业务应用服务的维护成本，具有广泛的应用前景。

需要说明的是，本实施例提供的微服务注册方法的原理及流程与上述的微服务注册系统类似，相关之处可以参照上述说明，在此不再赘述。

还需要说明的是，在本发明的描述中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定，对于本领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动，这里无法对所有的实施方式予以穷举，凡是属于本发明的技术方案所引伸出的显而易见的变化或变动仍处于本发明的保护范围之列。

Claims (10)

1.一种微服务注册系统，其特征在于，包括服务提供端、服务注册端以及与用户终端连接的服务消费端，其中，

所述服务提供端用于向所述服务注册端发出注册请求，所述服务提供端包括发出具有标记的第一注册请求的第一提供端和发出不具有标记的第二注册请求的第二提供端，

所述服务注册端用于根据接收的所述第一注册请求和所述第二注册请求生成注册信息，

所述服务消费端用于拉取所述注册信息，并对用户终端的业务请求进行区分，将区分后的所述业务请求输出至与所述业务请求对应的所述注册信息中的所述第一提供端或所述第二提供端。

2.根据权利要求1所述的系统，其特征在于，所述服务消费端包括：

业务请求判断模块，用于判断所述用户终端的业务请求是具有标记的第一业务请求或者是不具有标记的第二业务请求，

第一业务请求输出端，用于将所述第一业务请求输出至所述注册信息中的所述第一提供端；以及

第二业务请求输出端，用于将所述第二业务请求输出至所述注册信息中的所述第二提供端。

3.根据权利要求1所述的系统，其特征在于，所述第一注册请求为基于灰度发布生成的，所述第一业务请求为基于灰度发布生成的。

4.根据权利要求1所述的系统，其特征在于，所述服务注册端包括多个服务注册模块，两个所述服务注册模块之间相互连接同步所有的注册信息，

所述服务注册模块包括第一内存和第二内存，其中，

所述第一内存用于存储各个所述服务提供端更新的注册信息，

所述第二内存用于存储未更新的注册信息。

5.根据权利要求4所述的系统，其特征在于，所述服务注册端还包括注册信息数据库，用于以异步存储的方式存储所述第一内存的注册信息和所述第二内存的注册信息。

6.根据权利要求1所述的系统，其特征在于，所述服务消费端还包括第三内存和第四内存，其中，

所述第三内存用于存储从所述服务提供端拉取的更新的所述注册信息，

所述第四内存用于存储从所述服务提供端拉取的未更新的注册信息。

7.根据权利要求2所述的系统，其特征在于，所述第一业务请求输出端还用于以预设的权重策略从所述注册信息中选择所述第一提供端，并向所选择的所述第一提供端输出所述第一业务请求，

所述权重策略为根据每一所述第一提供端的资源配置确定的；

或者

所述第一提供端为多个时，第一业务请求输出端还用于通过轮询的方式从所述注册信息中选择所述第一提供端，并向所选择的所述第一提供端输出所述第一业务请求。

8.根据权利要求1所述的系统，其特征在于，所述服务提供端还用于根据接收的所述区分后的业务请求反馈熔断信息至所述服务消费端，所述服务消费端还用于将所述熔断信息反馈至所述用户终端。

9.根据权利要求1所述的系统，其特征在于，所述服务注册端还用于以预设频率监控所述服务提供端的工作状态，若其中一所述服务提供端处于异常工作状态，则所述服务注册端在该监控时段删除该服务提供端的注册信息，

其中，若所述第一提供端在所述注册信息中的数量满足预设阈值，则所述服务注册端不再删除剩余的所述第一提供端的注册信息，若所述第二提供端在所述注册信息中的数量满足预设阈值，则所述服务注册端不再删除剩余的所述第二提供端的注册信息。

10.一种应用于权利要求1～9中任一项所述系统的微服务注册方法，其特征在于，所述方法包括：

所述服务提供端向所述服务注册端发出注册请求，包括由所述第一提供端发出的第一注册请求和由所述第二提供端发出的第二注册请求，所述第一注册请求为基于灰度发布生成的，所述第二业务请求为基于灰度发布生成的；

服务注册端根据接收的所述第一注册请求和所述第二注册请求生成注册信息；以及

服务消费端拉取所述注册信息，并对所述用户终端的业务请求进行区分，将区分后的所述业务请求输出至与所述业务请求对应的所述注册信息中的所述第一提供端或所述第二提供端。

Images