CN111615066A - 一种基于广播的分布式微服务注册及调用方法 - Google Patents

Abstract

本发明公开了一种基于广播的分布式微服务注册及调用方法，包括：在每一个部署有微服务的主机上分别部署注册中心；在某一个主机上有新的微服务注册时，该主机向网络发送注册广播，通知网络中的其他主机更新其注册中心中的微服务列表；在调用者调用微服务时，调用者向网络发起查询广播；部署有同名微服务的主机向网络发起应答，并提供主机当前的负载情况以及其部署的微服务信息；调用者在接收到应答后，通过负载均衡器根据不同主机当前的负载情况选择合适的主机，并向选中的主机传递请求参数，调用微服务。本发明采用分布式、去中心化的微服务注册机制,使得一个注册节点故障下线后不会影响到其他微服务的注册及调用，从而提高了微服务的可用性。

Description

一种基于广播的分布式微服务注册及调用方法

技术领域

本发明属于信息处理技术领域，具体地说，是涉及一种微服务的注册和调用方法。

背景技术

微服务架构是大型分布式系统的主要架构，微服务架构的形式是通过将功能分解到各个离散的微服务中，以实现对大型单体应用的解耦，其好处在于可以把一个大型单体应用和服务拆分为数个甚至数十个微小的应用组件(微服务)，在应用开发和维护时，可以分别开发应用组件，加速开发进程。

在微服务架构下，需要注册中心来提供微服务的发现功能，即，告诉调用者当前有哪些微服务可供调用。目前，微服务架构下的注册中心主要采用中心化节点的注册机制，即，所有的微服务均在一个注册中心注册。

图1示出了当前微服务的注册、发现及调用过程：

（1）微服务提供者在启动时，向注册中心注册自己提供的微服务，形成一个微服务实例；

（2）微服务调用者在启动时，向注册中心订阅自己所需的微服务；

（3）注册中心返回一个微服务实例的地址给调用者；

（4）微服务调用者根据注册中心提供的地址调用其所需的微服务实例。

在微服务的注册和调用过程中，注册中心作为服务器端Server，提供注册服务和发现功能。各个微服务实例启动后，会在Server中进行注册，注册信息包括主机名称与端口号、服务版本号、通讯协议等。这样Server中的微服务注册表中将会存储所有可用微服务实例的信息。

微服务调用者和微服务提供者都是客户端Client。其中，微服务提供者主要处理微服务的注册，客户端服务通过注册和参数配置的方式，嵌入在客户端应用程序的代码中。在应用程序启动时，客户端向微服务注册中心注册自身提供的微服务，并周期性地发送心跳来更新其微服务租约。同时，客户端Client也能从服务器端Server (注册中心)查询当前注册的微服务信息（以微服务清单的形式呈现），并将所述微服务信息缓存到本地并周期性地刷新微服务的状态。

微服务调用者在获取微服务清单后，根据微服务名称可以获取具体的微服务实例以及该实例的属性信息。因为有这些微服务实例的详细信息，所以客户端Client可以根据自己的需要决定具体调用哪个实例。

现有的这种采用中心化节点的微服务注册与调用机制，其面临的主要问题是：一旦作为中心节点的注册中心出现故障，将导致与中心节点相连的所有微服务不可用，因此，整个系统的稳定性和可靠性都不高。

为了解决上述问题，目前业内提出的主要解决方案有：

其一，使用自复制多个注册中心的机制。即，在微服务架构中，部署多个注册中心，多个注册中心之间通过复制的方式完成微服务注册列表的同步，实现微服务的高可用性。但是，这种多个注册中心自复制的设计，会造成注册中心的数据容错性低、一致性无法保证等问题。

其二，使用主节点选举的多个注册中心的机制。即，在微服务架构中，部署多个注册中心，当作为主节点的注册中心宕机时，重新选举其他注册中心作为主节点来响应用户操作，继而实现微服务的高可用性。但是，这种主节点选举机制，在主节点宕机重新选举的期间，会造成微服务短时不可用，且系统的容错性不高。

发明内容

本发明为了解决现有技术存在的上述问题，提出了一种基于广播的分布式微服务注册及调用方法，通过采用分布式、去中心化的微服务注册机制,使得一个注册节点故障下线后不会影响到其他微服务的注册及调用，从而提高了微服务的可用性。

为解决上述技术问题，本发明采用以下技术方案予以实现：

一种基于广播的分布式微服务注册及调用方法，包括：在每一个部署有微服务的主机上分别部署注册中心；在某一个主机上有新的微服务注册时，该主机向网络发送注册广播，通知网络中的其他主机更新其注册中心中的微服务列表；在调用者调用微服务时，调用者在所述网络中发起查询广播，并在广播中发布所需调用的微服务名称；部署有同名微服务的主机向网络发起应答，并提供主机当前的负载情况以及其部署的微服务信息；调用者在接收到应答后，通过负载均衡器根据不同主机当前的负载情况选择合适的主机，并向选中的主机传递请求参数，调用选中主机上的同名微服务。

进一步的，在微服务注册过程中，注册广播中包含有新注册微服务的信息，所述信息包括：微服务的名称、微服务的功能描述、微服务所在主机的IP地址和访问端口、加入时间、响应状态等。

优选的，在所述微服务注册过程中，所述网络中的其他主机在接收到注册广播后，若自身部署有同名微服务，则更新其同名微服务列表；否则，根据接收到的新注册微服务的信息更新其非同名微服务列表。

优选的，在微服务调用过程中，对于所述选中的主机，优选设计其根据自身状况判断是否转发微服务的调用；若无需转发，则直接执行自身部署的同名微服务，并将执行结果返回给调用者；若需转发，则根据同名微服务列表选择其他主机，转发微服务的调用至其他主机，并传递请求参数。

其中，所述主机当前的负载情况包括主机的连接数、访问量、CPU使用率、磁盘使用率和网络使用率等；所述调用者通过负载均衡器根据不同主机当前的负载情况，选择剩余资源多的主机进行微服务调用。

为了实现对系统的监控和维护，所述部署在主机上的所有微服务定时地在网络中广播自身的心跳包，网络中的所有主机在接收到来自不同微服务的心跳包时，自动更新自身微服务列表中与该微服务相关的状态信息；若在设定时间内未接收到某个微服务返回的心跳包，且心跳包未返回的次数超过设定阈值，则从微服务列表中删除该多次未返回心跳包的微服务。

进一步的，所述主机根据微服务名称确定微服务列表中的同名微服务集，主机定时在网络中广播自身的同名微服务集，网络中的其他主机在接收到此广播后，查看此广播中同名微服务集中各微服务状态的更新时间，若更新时间晚于自身微服务列表中该微服务状态的更新时间，则更新自身微服务列表中与该微服务相关的状态信息；若自身微服务列表中不存在该微服务，则在自身微服务列表中注册该微服务。由此可以使每一个主机中的微服务列表的信息保持一致。

又进一步的，所述主机在检测到其同名微服务集的更新时间与当前时间的差值超过更新阈值，则主机向网络发送广播，要求同名微服务广播其自身的心跳包，以更新同名微服务集中与时间相关的状态信息。

为了提高负载均衡策略的精准度，在每一个所述主机上均部署有负载均衡器，所述负载均衡器向网络广播自身主机当前的负载情况；对于调用者选中调用微服务的主机，若该主机上部署有多个同名的微服务实例，则该主机通过自身的负载均衡器从所述多个同名的微服务实例中选择一个合适的微服务实例调用；一种情况：若该主机上的同名微服务实例的负载情况类似（例如同名的微服务实例都有相同的访问数、cpu占用情况类似（10%的上下浮动），内存占用情况类似（10%的上下浮动），则认为具有相同的负载情况），则优选使用当前调用的微服务实例；另一种情况：若该主机上的同名微服务实例的负载情况不同，且当前调用的微服务实例的负载超出规定的负载能力（例如访问数规定不能超过500，但实际情况已超过500），或者其他微服务实例的负载相对当前调用的微服务实例的负载较轻，则优选将调用者的请求转发到该主机上部署的其他同名的微服务实例中。

优选的，所述负载均衡器优选采用的判断策略包括但不限于：轮询、最少连接、最短响应时间或源地址哈希等策略，所述负载均衡器可以采用上述任一种判断策略从所述多个同名的微服务实例中选择一个合适的微服务实例调用。

与现有技术相比，本发明的优点和积极效果是：

（1）本发明采用分布式的注册中心来解决节点中心化的问题，将注册中心跟随微服务布设在不同的主机上，各主机之间采用在网络中广播消息的机制来进行微服务的自注册和自发现，从而实现了注册中心数据的一致性、冗余性和容错性。注册中心采用分布式部署、去中心化的注册机制，在一个注册节点故障下线后不会影响到其他微服务的注册及调用，从而实现了微服务的高可用性。

（2）本发明在注册中心分布式部署的机制下，结合各主机的实际负载情况确定负载均衡策略，使得调用者能够选择出处于最佳状态的微服务实例进行调用，由此可以提高系统中微服务的业务处理能力，提升整个系统的工作效能。

结合附图阅读本发明实施方式的详细描述后，本发明的其他特点和优点将变得更加清楚。

附图说明

图1是现有的中心化节点的注册机制下的微服务注册和调用流程图；

图2是本发明所提出的分布式注册机制下的微服务注册流程图；

图3是分布式注册机制下的微服务监控和维护流程图；

图4是分布式注册机制下的微服务调用流程图；

图5是分布式注册机制下的负载均衡策略流程图。

具体实施方式

下面结合附图对本发明的具体实施方式进行详细地描述。

本实施例对注册中心采用分布式部署，在部署有微服务的所有主机上分别部署注册中心和负载均衡器，使每一个主机既是服务器端server，又是客户端client。配置各主机在网络中使用基于UDP的消息广播机制广播微服务的注册和调用信息，以实现微服务在各注册中心上的自注册和自发现。

在本实施例中，所述主机可以是容器、虚拟机、实体主机等。

下面结合图2-图5，详细阐述本实施例的基于广播的分布式微服务注册及调用方法的具体工作流程。

（一）微服务的广播式注册

如图2所示，当微服务提供者在某一个主机的注册中心上注册其微服务时，此主机首先将该微服务的相关信息录入此主机自身的注册中心，更新注册中心的微服务列表，该微服务在此主机上形成一个微服务实例。然后，此主机向整个网络发送注册广播，以通知网络中的其他主机有新的微服务注册。网络中的其他主机在接收到注册广播后，更新自身注册中心的微服务列表，实现微服务在各注册中心上的自注册。

主机在网络中发送注册广播时，在注册广播中广播新注册微服务的相关信息，所述信息包括但不限于：

微服务的名称，微服务对外显示的名称；

微服务的属性，微服务的功能描述；

IP地址和访问端口，微服务所在主机的IP地址和访问端口；

加入时间，微服务加入注册中心的微服务列表时间；

响应状态，微服务是否能响应请求。

在微服务注册成功后，此微服务及其所在主机的注册中心定时向网络发送此微服务的心跳包，以表明此微服务是否存活。

由于每一个主机既是服务器端server，又是客户端client，因此，每一个主机上的注册中心对接收到的微服务可以有不同的处理策略。对于某些主机上已部署有同名微服务的情况，这些主机可以将接收到的注册广播中的微服务信息进行缓存，然后更新自身的同名微服务列表。对于未部署有同名微服务的主机，可以将接收到的注册广播中的微服务信息进行缓存，然后写入自身的非同名微服务列表。

（二）微服务的监控与维护

由于网络不可达或微服务自身负载等原因，某些分布式运行的微服务可能在一定程度上无法使用或无法响应调用者，无法响应调用者的微服务应从注册中心删除，等微服务重新上线后再次注册，以提高微服务调用的时效性。

为此，本实施例优选从以下三方面对微服务列表中的各注册的微服务进行监控和维护，结合图3所示，包括：

其一，所有微服务实例采用UDP广播的方式向网络发送自身的心跳包，已通知网络中的各个主机更新其微服务列表中相应微服务的状态信息。当某一微服务实例在设定时间内无心跳包返回，且心跳包未返回的次数超过设定阈值时，可以认为此微服务实例不再存活，各注册中心从自身的微服务列表中移除多次未返回心跳包的微服务。

其二，由于每一个注册中心在其微服务列表中均记录有各微服务实例的名称、加入列表的时间、微服务广播发送时间、同名微服务集（具有相同名称的微服务实例构成的集合）的更新时间等与时间相关的信息，因此可以设定更新阈值，当主机在检测到其同名微服务集的更新时间与当前时间的差值超过更新阈值时，可以向网络发送广播，要求同名微服务实例广播其自身的心跳包，以更新同名微服务集中与时间相关的状态信息。若某一微服务广播发送时间或同名微服务集的更新时间超过一定时限或与当前时间的差值超出删除阈值，即，在删除阈值对应的时间内，注册中心未接收到相关微服务实例的心跳包，则应将所述相关微服务实例从微服务列表中删除。

其三，配置注册中心定时在网络中广播自身的同名微服务集。网络中的其他注册中心在接收到此广播后，查看此广播中同名微服务集中的各微服务实例的状态更新时间，若更新时间晚于自身微服务列表中相关微服务实例的状态更新时间，则更新自身微服务列表中所述相关微服务实例的状态。若自身微服务列表中不存在此微服务实例，则在自身注册中心中注册此微服务实例。若注册中心发生了更新或注册，则注册中心将要求更新或注册的微服务实例发送心跳包广播，再根据心跳包更新微服务列表中此微服务实例的状态信息。

（三）微服务的查询或调用

如图4所示，当微服务调用者需要查询或调用某一微服务时，调用者在网络中发起查询广播，广播时优选使用微服务列表中的微服务名称（例如MS1）进行查询，以获取微服务的位置。

网络中的各主机在接收到查询广播后，由部署有同名微服务的主机向网络发起应答，应答返回的内容包括其部署的微服务信息以及主机当前的负载情况等。其中，其部署的微服务信息包括但不限于：微服务名称、微服务所在主机的IP地址和访问端口、响应状态等。主机当前的负载情况包括但不限于：主机的连接数、访问量、CPU使用率、磁盘使用率、网络使用率等。

在本实施例中，配置部署在每一个主机上的负载均衡器向网络广播自身主机当前的负载情况。

调用者在接收到应答后，开始执行微服务的调用过程，具体包括：

调用者通过负载均衡器根据不同主机当前的负载情况选择合适的主机；

调用者向选中的主机（例如docker1）传递请求参数，请求调用其上部署的同名微服务（例如MS1）；

对于选中的主机而言，优选设计其根据自身状况（例如：主机的连接数、访问量、CPU使用率、磁盘使用率、网络使用率、本机注册的同名微服务的广播的负载情况等），来判断是否需要转发微服务的调用；

若无需转发，则该主机（例如docker1）可以直接调用自身部署的同名微服务实例（例如MS1）并加以执行，然后，将执行结果返回给调用者；

若需转发，则该主机（例如docker1）可以根据同名微服务列表，在充分考虑权重或响应速度等因素的情况下，合理地筛选出另一主机（例如docker2），向其转发此微服务的调用，并向重新选择的主机（例如docker2）传递调用者发送的请求参数；重新选择的主机（例如docker2）根据自身状况判断是否转发此微服务的调用，直到此微服务（例如MS1）在某一个主机上成功调用并执行。

在微服务架构中，由于微服务是分布式的，对于任意一个微服务，原则上存在多个微服务的提供者，即，在同一个微服务名称下对应有多个微服务实例。但是，调用者在调用微服务时，只需调用一个微服务实例，因此需要通过负载均衡器来筛选出最合适的微服务实例。

传统的负载均衡策略没有考虑到主机的剩余计算能力，仅根据各微服务实例的连接数进行负载分配，从而无法高效地利用主机的硬件资源。由于各主机的配置不同、使用时间不同、网络带宽不同，其所拥有的剩余资源是完全不同的。若存在两个主机，一个主机的连接数少，但是已无多少剩余资源供主机使用；另一主机的连接数大，但是剩余大量计算资源未使用。当进行大量耗时的微服务操作时，若选择连接数少的主机，然而此主机虽然连接数少，但是其拥有的计算资源并不多，将微服务的调用操作放入此主机处理，将会造成服务降级。

本实施例在每一个主机上部署负载均衡器，如图5所示，利用负载均衡器收集并汇总自身主机当前的负载量，所述负载量可以由主机的访问次数、CPU使用情况、磁盘使用情况、网络使用情况等信息组成，并负责在网络中进行广播。调用者可以根据主机返回的负载量，选择剩余资源多的主机进行微服务调用，以对微服务进行负载均衡分配。

若在响应微服务调用请求的主机上部署有多个同名的微服务实例，则该主机可以利用其自身部署的负载均衡器，采用以下均衡策略中的任一种筛选出一个合适的微服务实例加以调用：

①round_robin(轮询)：周而复始地依次选择微服务实例进行调用，确保每个微服务实例都会被调用到，也可按权重轮询；

②least_connection(最少连接)：根据客户端与服务器端建立的连接数量，选择连接数量最少的微服务实例；

③least_respone_time(最短响应时间)：根据服务器端从客户端请求的响应时间长短, 选择响应最快的微服务实例；

④source_hash(源地址哈希)：根据客户端的IP地址计算哈希值，然后使用哈希值进行路由, 这可确保即使面对断开的连接，来自同一客户端的请求也始终会转到同一服务器端。

当该主机通过自身的负载均衡器从其多个同名的微服务实例中选择出一个合适的微服务实例后，可能会出现以下两种情况：

一种情况是，若该主机上的同名微服务实例的负载情况类似，例如同名的微服务实例都有相同的访问数、cpu占用情况类似（10%的上下浮动），内存占用情况类似（10%的上下浮动），则认为具有相同的负载情况；此时，应优选使用负载均衡器当前调用的微服务实例；

另一种情况是，若该主机上的同名微服务实例的负载情况不同，且负载均衡器当前调用的微服务实例的负载超出规定的负载能力（例如访问数规定不能超过500，但实际情况已超过500），或者其他微服务实例的负载相对于当前调用的微服务实例的负载较轻，则优选将调用者的请求转发到该主机上部署的其他同名的微服务实例中。

执行最终选中的微服务实例，并向调用者返回结果。

本实施例采用分布式的注册中心，结合各主机的实际负载情况确定负载均衡策略，由此提高了负载均衡分配的精准性，使得调用者可以选择处于最佳状态的微服务实例加以调用和执行，极大提高了系统的微服务业务处理能力，提升了系统的整体工作效能。

当然，以上所述仅是本发明的一种优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种基于广播的分布式微服务注册及调用方法，其特征在于，包括：

在每一个部署有微服务的主机上分别部署注册中心；

在某一个主机上有新的微服务注册时，该主机向网络发送注册广播，通知网络中的其他主机更新其注册中心中的微服务列表；

在调用者调用微服务时，调用者在所述网络中发起查询广播，并在广播中发布所需调用的微服务名称；

部署有同名微服务的主机向网络发起应答，并提供主机当前的负载情况以及其部署的微服务信息；

调用者在接收到应答后，通过负载均衡器根据不同主机当前的负载情况选择合适的主机，并向选中的主机传递请求参数，调用选中主机上的同名微服务。

2.根据权利要求1所述的基于广播的分布式微服务注册及调用方法，其特征在于，在微服务注册过程中，注册广播中包含有新注册微服务的信息，所述信息至少包括：微服务的名称、微服务的功能描述、微服务所在主机的IP地址和访问端口、加入时间、响应状态。

3.根据权利要求2所述的基于广播的分布式微服务注册及调用方法，其特征在于，在所述微服务注册过程中，所述网络中的其他主机在接收到注册广播后，若自身部署有同名微服务，则更新其同名微服务列表；否则，根据接收到的新注册微服务的信息更新其非同名微服务列表。

4.根据权利要求1所述的基于广播的分布式微服务注册及调用方法，其特征在于，在微服务调用过程中，所述选中的主机根据自身状况判断是否转发微服务的调用；若无需转发，则直接执行自身部署的同名微服务，并将执行结果返回给调用者；若需转发，则根据同名微服务列表选择其他主机，转发微服务的调用至其他主机，并传递请求参数。

5.根据权利要求1所述的基于广播的分布式微服务注册及调用方法，其特征在于，所述主机当前的负载情况包括主机的连接数、访问量、CPU使用率、磁盘使用率和网络使用率；所述调用者通过负载均衡器根据不同主机当前的负载情况，选择剩余资源多的主机进行微服务调用。

6.根据权利要求1至5中任一项所述的基于广播的分布式微服务注册及调用方法，其特征在于，所述部署在主机上的所有微服务定时地在网络中广播自身的心跳包，网络中的所有主机在接收到来自不同微服务的心跳包时，自动更新自身微服务列表中与该微服务相关的状态信息；若在设定时间内未接收到某个微服务返回的心跳包，且心跳包未返回的次数超过设定阈值，则从微服务列表中删除该多次未返回心跳包的微服务。

7.根据权利要求6所述的基于广播的分布式微服务注册及调用方法，其特征在于，所述主机根据微服务名称确定微服务列表中的同名微服务集，主机定时在网络中广播自身的同名微服务集，网络中的其他主机在接收到此广播后，查看此广播中同名微服务集中各微服务状态的更新时间，若更新时间晚于自身微服务列表中该微服务状态的更新时间，则更新自身微服务列表中与该微服务相关的状态信息；若自身微服务列表中不存在该微服务，则在自身微服务列表中注册该微服务。

8.根据权利要求7所述的基于广播的分布式微服务注册及调用方法，其特征在于，所述主机在检测到其同名微服务集的更新时间与当前时间的差值超过更新阈值，则主机向网络发送广播，要求同名微服务广播其自身的心跳包，以更新同名微服务集中与时间相关的状态信息。

9.根据权利要求1至5中任一项所述的基于广播的分布式微服务注册及调用方法，其特征在于，

在每一个所述主机上均部署有负载均衡器，所述负载均衡器向网络广播自身主机当前的负载情况；

对于调用者选中调用微服务的主机，若该主机上部署有多个同名的微服务实例，则该主机通过自身的负载均衡器从所述多个同名的微服务实例中选择一个合适的微服务实例调用；

若该主机上的同名微服务实例的负载情况类似，则使用当前调用的微服务实例；

若该主机上的同名微服务实例的负载情况不同，且当前调用的微服务实例的负载超出规定的负载能力，或者其他微服务实例的负载相对当前调用的微服务实例的负载较轻，则将调用者的请求转发到该主机上部署的其他同名的微服务实例中。

10.根据权利要求9所述的基于广播的分布式微服务注册及调用方法，其特征在于，所述负载均衡器采用轮询、最少连接、最短响应时间或源地址哈希策略，从所述多个同名的微服务实例中选择一个合适的微服务实例调用。

Images