CN111698266A - 服务节点调用方法、装置、设备及可读存储介质 - Google Patents

Abstract

本申请涉及云技术技术领域，公开了一种微服务架构的服务节点调用方法，包括：接收调用方的调用请求，并获取预先所存储的节点健康列表，其中所述节点健康列表存储于区块链的节点中；获取所述节点健康列表对应的节点调用信息，以确定所述节点健康列表所包含的服务节点的调用顺序以及调用进度；根据所述调用顺序以及调用进度，在所述节点健康列表中确定第一服务节点；确定所述第一服务节点是否满足预设的节点调用条件；若确定所述第一服务节点满足所述节点调用条件，则控制所述第一服务节点响应所述调用请求。本申请还提供一种装置、计算机设备和存储介质。实现提高服务节点调用效率和运行效率。

Description

服务节点调用方法、装置、设备及可读存储介质

技术领域

本申请涉及云技术技术领域，尤其涉及一种微服务架构的服务节点调用方法、微服务架构的服务节点调用装置、计算机设备及计算机可读存储介质。

背景技术

在微服务架构中，是将原有的一个服务单位拆分多个子服务单位，即服务节点，通过控制不同的子服务单位执行不同的服务来满足不同的业务需求，而在实际使用过程中，业务人员只需要在前端进行一次请求，便使得后端的不同子服务单位之间会产生相应的上下游调用，即服务节点的调用。

而在服务节点的调用过程中，会因为服务节点的自身状态而影响整个的调用，比如服务节点可能会被关闭，或者会被开启，使得在服务节点的调用过程中，会存在调用失败的情况，此时会影响整体的运行效率。

因此，现在亟需一种提高服务节点调用效率和运行效率的服务节点调用方法。

发明内容

本申请提供了一种微服务架构的服务节点调用方法、装置、计算机设备及存储介质，以提高服务节点调用效率和运行效率。

第一方面，本申请提供了一种微服务架构的服务节点调用方法，所述方法包括：

接收调用方的调用请求，并获取预先所存储的节点健康列表；

获取所述节点健康列表对应的节点调用信息，以确定所述节点健康列表所包含的服务节点的调用顺序以及调用进度；

根据所述调用顺序以及调用进度，在所述节点健康列表中确定第一服务节点；

确定所述第一服务节点是否满足预设的节点调用条件；

若确定所述第一服务节点满足所述节点调用条件，则控制所述第一服务节点响应所述调用请求。

第二方面，本申请还提供了一种微服务架构的服务节点调用装置，所述装置包括：

请求接收模块，用于接收调用方的调用请求，并获取预先所存储的节点健康列表；

信息确定模块，用于获取所述节点健康列表对应的节点调用信息，以确定所述节点健康列表所包含的服务节点的调用顺序以及调用进度；

节点选择模块，用于根据所述调用顺序以及调用进度，在所述节点健康列表中确定第一服务节点；

条件判断模块，用于确定所述第一服务节点是否满足预设的节点调用条件；

节点调用模块，用于若确定所述第一服务节点满足所述节点调用条件，则控制所述第一服务节点响应所述调用请求。

第三方面，本申请还提供了一种计算机设备，所述计算机设备包括存储器和处理器；所述存储器用于存储计算机程序；所述处理器，用于执行所述计算机程序并在执行所述计算机程序时实现如上述的微服务架构的服务节点调用方法。

第四方面，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时使所述处理器实现如上述的微服务架构的服务节点调用方法。

本申请公开了一种微服务架构的服务节点调用方法、装置、计算机设备及存储介质，在接收到调用方的调用请求时，确定需要选择合适的服务节点来响应调用请求，此时将获取所存储的节点健康列表，以得到所记录的服务节点的调用顺序以及调用进度，然后根据所得到的调用顺序和调用进度确定对应的第一服务节点，然后根据第一服务节点自身的服务状态确定是否可以用于被调用，以在满足节点调用条件时调用第一服务节点来响应所接收到的调用请求。实现了在服务节点的调用过程中，提高服务节点调用效率以及系统的运行效率。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一个实施例中一种微服务架构的服务节点调用方法的流程示意图；

图2为本申请一个实施例中服务节点开启的步骤的流程示意图；

图3为本申请一个实施例中服务节点关闭的步骤的流程示意图；

图4为本申请另一个实施例中一种微服务架构的服务节点调用方法的流程示意图；

图5为本申请一个实施例中一种微服务架构的服务节点调用装置的示意性框图；

图6为本申请一个实施例中计算机设备的结构示意性框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

附图中所示的流程图仅是示例说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解、组合或部分合并，因此实际执行的顺序有可能根据实际情况改变。

应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

请参阅图1，图1为本申请一个实施例中一种微服务架构的服务节点调用方法的流程示意图。

如图1所示，该微服务架构的服务节点调用方法包括步骤S101至步骤S105。

步骤S101、接收调用方的调用请求，并获取预先所存储的节点健康列表。

微服务架构中存在有服务调用方和服务提供方，其中，提供方与调用方可为微服务架构中的不同服务节点，而在实际使用过程中，服务调用方与服务提供方可以相互置换。

在服务器接收到调用方所发送的调用请求时，将会调用相应的服务节点对调用请求进行响应，在确定对调用指令进行相应的服务节点之前，将首先获取预先所存储的节点健康列表，其中节点健康列表存储于区块链的某一/某些节点中，进而在所得到的节点健康列表选择和确定当前用于响应所接收到的调用请求的服务节点。其中，节点健康列表用于记录当前可以以及正在进行服务提供的服务节点，也就是存在于节点健康列表中的服务节点可以被调用方所调用，或者正在被调用。

由于节点健康列表中记录有当前可以用于执行服务提供的服务节点，因此对于节点健康列表而言，是处于一个实时变化的状态的，根据微服务架构中各服务节点的实际状态实时对节点健康列表进行更新。

另外，在节点健康列表中包含若干可以用于被调用或者正在被使用的服务节点，通常情况下，一个节点是可以被频繁调用的，即使此时被调用的节点已经被调用很多次，但是为了提高服务器的响应速率，通常不会控制一个服务节点频繁响应所接收到的调用请求，而是通过相应的方式使得每个服务节点都会被调用来响应所接收到的调用请求。比如，按照一定的顺序实现服务节点的被调用。

步骤S102、获取所述节点健康列表对应的节点调用信息，以确定所述节点健康列表所包含的服务节点的调用顺序以及调用进度。

在接收到调用方发送的服务节点的调用请求之后，将会在节点健康列表中选择相应的服务节点来响应此调用请求，在实际确定当前可以用来响应调用请求的服务节点时，通过获取节点健康列表对应的节点调用信息，以确定所有的服务节点的调用进度以及各服务节点的调用顺序，实现对用于响应调用请求的服务节点的确定，其中节点调用信息中便记录有节点健康列表中的相关使用信息，比如已经被调用的服务节点的信息以及实际的预先所得到的调用顺序信息。

为了保证服务响应的速率和降低服务器的运行负载，需要避免出现频繁的对一个服务节点的调用，以及几乎不对一个服务节点进行调用的情况，因此对于节点健康列表中所记录的服务节点而言，设置有一定的调用规则，比如调用顺序，以实现对服务节点的均衡调用。其中，调用进度用于确定相邻前一次用于响应调用请求的服务节点，即调用进度记录着相邻前一次响应调用请求的服务节点，但是调用节点还可以用来记录当前可以用于响应调用请求的服务节点，调用顺序为节点健康列表中对服务节点的调用顺序，需要说明的是，调用顺序并不是随机决定的，是根据服务节点自身的调用权重所决定的，调用权重为服务节点的调用频率或者概率。

在实际应用中，为了提高服务节点被调用的均衡性，可以设置一个节点调用的常规顺序，然后利用每个服务节点的调用权重确定每一次在响应调用请求时控制哪一个服务节点进行响应。

比如，服务器中可以进行服务提供的节点数量为3，若每一个的权重均为0.33333...(1/3)，也就是在一次调用循环中，每个节点只被调用一次，那么可以设置被调用顺序为“节点1、节点2、节点3”，在完成此次循环之后，再次控制顺序中的第一个节点来响应调用请求。再比如，3个节点的调用权重分别为0.2、0.4、0.4，根据权重可以确定，在一次调用循环中，“节点1”只会被调用一次，而“节点2”和“节点3”会被调用两次，那么此时一个循环可以为“节点2、节点3、节点1、节点2、节点3”，然后再完成一次循环调用之后，将会控制“节点2”来响应调用请求。

在一实施例中，调用顺序实际上是会被各节点的调用权重所影响，如上述所描述的例子可以知道。因此，在确定节点健康列表中服务节点的调用顺序时，包括：获取节点健康列表中所包含的服务节点，并确定所包含的服务节点所对应的调用权重；以所述节点健康列表所包含的一服务节点为初始服务节点，根据调用权重确定所述节点健康列表中所包含的服务节点的调用顺序。

一般情况下，没有特殊的设定，每个服务节点的调用权重是相同的，因此在一次调用循环中，每个服务节点均会被调用一次。但是也会存在一些特殊的设定，使得某一个或者某一些服务节点的调用权重与其他的服务节点的调用权重不相同，比如可以多次调用或者减少调用次数等，因此需要根据实际的调用权重确定当前对应的调用顺序。

在一实施例中，除了用户进行特殊设定的服务节点之外，刚开启的服务节点也属于一种特殊的服务节点，由于服务节点的刚开启，使得服务节点此时不应该立刻承担正常状态下的全部流量，而是在运行一段时间之后，随着时间的推移直至接收全部流量，这里的流量指的是调用方所发送的请求，也就是在服务节点刚开启时，随着时间的推移逐渐增加所开启的服务节点的被调用权重，直至调用权重变为正常预设权重。因此，如图2所示，在对服务节点进行开启时，该方法还包括步骤S201至步骤S203。

步骤S201、当接收到节点开启指令时，确定执行所述节点开启指令的第四服务节点；

步骤S202、当所述第四服务节点的启动状态满足第二条件时，对所述第四服务节点进行注册；

步骤S203、当所述第四服务节点注册完成时，将所述第四服务节点记录在所述节点健康列表中，并记录所述第四服务节点的注册时间。

在接收到服务节点开启指令时，首先确定需要执行节点开启指令的第四服务节点，通过识别节点开启指令中所包含的相关信息，如节点标识信息，确定所要开启的第四服务节点，然后对第四服务节点进行开启和启动，并在第四服务节点的启动状态满足预设的第二条件时，对第四服务节点进行注册，最后在第四服务节点完成注册时将第四服务节点记录在节点健康列表中，同时还将记录第四服务节点的注册时间。

在对服务节点开启以及注册时，由于不同服务节点所对应的业务特征的不同，使得需要在注册之前启动与所要开启的服务节点相关联的子系统，比如，服务节点1需要加载模块1、模块2、模块3之后，才能向调用方正常的提供服务，服务节点2需要加载模块4、模块5之后，才能向调用方正常的提供服务，那么在注册服务节点1时，首先需要启动和加载模块1、模块2以及模块3，同样的，在注册服务节点2时，首先需要启动和加载模块4和模块5。

通过设定第二条件，确定是否可以完成第四服务节点的注册，其中第二条件为与第四服务节点相关联的子系统(如模块)是否加载完成，在满足第二条件，即与第四服务节点关联的子系统加载完成时，对第四服务节点进行注册，以在完成第四服务节点的注册的时候，对节点健康列表进行更新，以将第四服务节点记录在节点健康列表中。在实际注册时，可以采用延时注册，也即是在完成加载的一定时间之后进行注册，如在加载完1分钟后再注册。

另外，服务节点的开启和注册是用来进行相应的服务提供的，因此除了将第四服务节点记录在节点健康列表中之外，还需要确定第四服务节点的实际被调用的状态，比如合适可以被调用以及调用频率是怎样，因此在第四服务节点完成注册时，将记录第四服务节点的注册时间，以根据注册时间确定第四服务节点的调用权重以及是否可以被调用。

在一些实施例中，在步骤S203之后还包括：

步骤S204、获取当前时间信息，并根据所述当前时间信息以及所述注册时间确定所述第四服务节点的调用权重；

步骤S205、根据所述调用权重，确定记录所述第四服务节点的节点健康列表所对应的调用顺序。

第四服务节点的注册是用于进行服务提供，因此在完成第四服务节点的注册之后，根据注册时间确定第四服务节点在不同时间的调用权重，因为不同的调用权重会影响调用顺序，因此会对调用顺序进行更新，直至第四服务节点的调用权重恢复至默认的权重值，比如用户所设定的调用权重或者系统默认的调用权重。

在确定第四服务节点在不同时间的调用权重时，获取当前时间信息，然后根据当前时间信息以及所记录的注册时间确定第四服务节点的调用权重，同时为了避免调用权重的频繁变动，可以设定相应的时间范围对应某一调用权重。比如，在第四服务节点启动和注册完成后，用户设定想要在100秒后第四服务节点回复到正常的运行状态，也就是调用权重恢复到所设定的权重值A，此时通过计算时间差值(当前时间与注册时间的时间差值)，然后通过所得到的时间差值确定对应的调用权重，若所得到的时间差值为30秒，那么此时第四服务节点对应的调用权重为(30/100)*A＝0.3A。而为了避免权重的频繁变动，可以将时间差值设定为5个区间，分别为0-20、21-40、41-60、61-80以及91-100，此时可以设定不同区间对应的权重为0.1A、0.3A、0.5A、0.7A以及0.9A，当时间差值大于100秒时，此时的调用权重将会变为A。

比如，在开启第四服务节点之前，记录在节点健康列表中的服务节点有两个，分别为节点1(权重0.5)和节点2(权重0.5)，在将第四服务节点开启和注册之后，若此时得到时间差值为41-60秒，如所设定的A为0.5，第四服务节点的调用权重为0.5A＝0.25，此时可以得到各节点之间的相对权重，那么此时的一个调用周期内，节点1和节点2均被调用两次，而第四服务节点被调用一次，此时所得到的调用顺序可以是：节点1、节点2、第四服务节点、节点1、节点2、节点1、节点2、第四服务节点、节点1、节点2、....，依次类推。

步骤S103、根据所述调用进度以及所述调用顺序，在所述节点健康列表中确定第一服务节点，其中，所述第一服务节点为当前预调用服务节点。

在得到节点健康列表中所包含的服务节点的调用顺序以及调用进度之后，将会根据调用顺序和调用进度确定当前用于响应所接收到的调用请求的第一服务节点，以控制第一服务节点来响应调用请求，其中，第一服务节点为当前预调用服务节点，也就是第一服务节点为当前获取确定可以用来进行调用的服务节点，但需要进行进一步的确定是否可以真实的调用第一服务节点。

由上述描述可知，调用顺序中记录着所有服务节点的响应顺序，比如调用顺序为：节点1、节点2、节点3、节点1、节点2、节点3...，调用进度记录着当前的调用位置，比如调用进度为“节点2”时，那么此时在确定用于响应调用请求的服务节点时，确定服务节点为“节点3”。

因此，在得到调用进度和调用顺序之后，可以在节点健康列表中确定当前用来响应调用请求的第一服务节点。

步骤S104、确定所述第一服务节点是否满足预设的节点调用条件。

在确定当前用来响应调用请求的第一服务节点时，确定第一服务节点是否满足预设的节点调用条件，其中节点调用条件用于确定服务节点是否可以用于响应调用请求。

在实际应用中，由于服务节点自身状态的限定，使得并不是所有存在于节点健康列表中的服务节点都可以用来响应调用请求，比如，在服务节点工作异常时则不能用来响应调用请求，再比如被限制调用的服务节点也是不能用来响应调用请求的，因此在得到第一服务节点之后，将确定第一服务节点是否满足预设的节点调用条件，并在第一服务节点满足节点调用条件时实现对第一服务节点的调用以及控制第一服务节点对调用请求的响应，否则将不会控制第一服务节点来响应所接收到的调用请求。

在一实施例中，在确定第一服务节点是否满足预设的节点调用条件时，具体包括：

步骤a、识别所述第一服务节点对应的第一服务状态，并根据所述第一服务状态确定所述第一服务节点是否满足预设的节点调用条件；

步骤b、若所述第一服务状态为关闭进行中，则确定所述第一服务节点不满足所述节点调用条件；

步骤c、若所述第一服务状态为正常使用中，则确定所述第一服务节点满足所述节点调用条件。

在确定第一服务节点是否满足预设的节点调用条件时，利用第一服务节点所对应的服务状态来确定，比如根据第一服务节点的服务状态确定可以进行调用时，将调用第一服务节点来响应所接收到的调用请求。

具体地，在确定第一服务节点时，识别第一服务节点所对应的第一服务状态，其中，服务状态可以根据实际的工作状态分为：关闭进行中以及正常使用中，然后根据所得到的第一服务状态来确定第一服务节点是否可以被调用来响应调用请求，其中，若第一服务状态为关闭进行中，则确定第一服务节点不满足节点调用条件，也就是不可以用来被调用来响应调用请求，若第一服务状态为正常使用中，则确定第一服务节点满足节点调用条件，也就是可以用来被调用以响应调用请求。

需要说明的时，对于服务节点的服务状态来说，上述描述仅针对于服务节点没有出现异常且在正常工作的情况下。因为能够被确定的服务节点是存在于节点健康列表中的，因此在确定服务节点服务异常时，将会将服务异常的服务节点从节点健康列表中删除，也就是节点健康列表中不会记录有服务异常的服务节点。因此，对于所有的服务节点而言，在运行过程中，通过监控服务节点对调用请求的响应状态来确定服务节点是否运行异常，比如在一个服务节点对一个请求的响应时间过长，则确定该服务节点处于服务异常的情况，那么此时将会将该服务节点从节点健康列表中进行删除，同时会对该服务节点执行关闭操作。

在一实施例中，在确定当前被选择的服务节点是否可以用来响应调用请求时，是根据服务节点的服务状态来确定的，因此需要预先对服务节点的服务状态进行标记和存储。比如在服务节点被开启时，会将服务节点的服务状态标记为正常使用中，在服务节点被关闭时，将会将服务节点的服务状态标记为关闭进行中。

如图3所示，在服务节点被关闭时，该方法还包括步骤S301至步骤S303。

步骤S301、当接收到节点关闭指令时，确定执行所述节点关闭指令的第三服务节点；

步骤S301、将所述第三服务节点的服务状态标记为关闭进行中，并监控所述第三服务节点的请求处理状态；

步骤S303、当所述请求处理状态满足第一条件时，关闭所述第三服务节点，并将所述节点健康列表中将所述第三服务节点删除。

在接收到服务节点关闭指令时，首先确定需要执行节点关闭指令的第三服务节点，通过识别节点关闭指令中所包含的相关信息，如节点标识信息，确定所要关闭的第三服务节点，然后对第三服务节点的服务状态进行更新，由于第三服务节点需要进行关闭，因此服务状态将会由正常使用中变为关闭进行中，同时会对第三服务节点的请求处理状态进行监控，其中请求处理状态为服务节点对所响应的调用请求的响应情况，并在所监控到的请求处理状态满足第一条件时关闭第三服务节点，并将第三服务节点从节点健康列表中进行删除。

在对服务节点进行关闭时，由于服务节点中可能还存在正在进行响应的调用请求或者还未响应的调用请求，因此在接收到节点关闭指令时，并不能第一时间将对应的服务节点进行关闭，而是只有在需要关闭的服务节点中已经不存在任何请求时才能进行关闭，避免不合理的关闭导致服务器的运行异常。

通过在对第三服务节点进行关闭时，将第三服务节点的服务状态进行更新和变更，以将服务状态标记为关闭进行中，使得即使第三服务节点在服务节点选择中被选中以确定是否可以用来响应调用请求，根据实时的服务状态来实现进一步的确定，如第三服务节点的服务状态为关闭进行中时，则在第三节点被选中时也不会用来响应调用请求。

在对第三服务节点的请求处理状态进行监控时，主要是通过监控第三服务节点中在接收到节点关闭指令之前所接收到的调用请求是否全部响应和处理来确定。如果在关闭第三服务节点的时候，第三服务节点在关闭指令之前所接收到的所有请求没有完成，就会导致所接收到的请求中某些请求还未被正常响应，以使得对应的导致调用方调用失败。因此通过监控第三服务节点的请求处理状态，确定何时对第三服务节点进行关闭。如，通过设置一个计数器来记录服务节点中未完成响应的请求的数量，在计数器的计数数值为零时，确定此时服务节点中不存在正在或者需要被响应的请求，即可以对服务节点进行关闭。

另外，为了避免某些请求长时间没处理完成导致服务节点关闭无限期等待，此时可以加上超时机制，也就是设定一个时间，当服务节点的关闭等待时间超出所设定的时间时，将会强制性关闭该服务节点。

同时，在关闭服务节点之后，将会在预先所存储的节点健康列表中将对应所关闭的服务节点进行删除。需要说明的是，节点健康列表中记录的可以被选择的服务节点的节点标识，如编号或者字母等，那么在进行服务节点的删除时，是将服务节点对应的节点标识在节点健康列表中进行删除。

步骤S105、若确定所述第一服务节点满足所述节点调用条件，则控制所述第一服务节点响应所述调用请求。

通过对第一服务节点所对应的第一服务状态的获取和对比，在确定第一服务节点满足节点调用条件时，控制第一服务节点响应所接收到的调用请求，如在确定第一服务节点处于正常使用中时控制第一服务节点响应调用请求。另外，在控制第一服务节点响应调用请求时，可以向调用方发送相应的调用成功的反馈信息，以使得调用方知道此次调用成功。

在一实施例中，根据第一服务节点的第一服务状态可以确定第一服务节点是否满足节点调用条件，所得到的结果包括：第一服务节点满足节点调用条件和第一服务节点不满足节点调用条件，对于第一服务节点满足节点调用条件的情况，将控制第一服务节点响应调用请求。

而当第一服务节点不满足节点调用条件时，第一服务节点不能作为用于响应调用请求的服务节点，那么此时需要再次选择合适的服务节点来响应调用请求，如图4所示，步骤S104之后还包括步骤S401至步骤S403。

步骤S401、若确定所述第一服务节点不满足所述节点调用条件，则根据所述第一服务节点生成第一反馈信息。

在确定第一服务节点不满足节点调用条件时，第一服务节点将不可以被调用来响应调用请求，因此此时需要再次进行选择合适的服务节点，以响应调用请求，同时还会根据第一服务节点生成相应的第一反馈信息。

第一反馈信息是用于告知调用方此次调用失败，需要重新进行调用。在实际应用中，调用成功将会直接控制第一服务节点来响应调用请求，而在调用失败时，将会生成相应的第一反馈信息以对调用方进行反馈。在实际应用中，反馈信息可以是系统或服务器中所生成的错误码，其中错误码还可以记录有当前被选择的服务节点的节点信息，且错误码的生成方式可以预先设定好，比如调用成功时的错误码是000000，而调用失败，即数据库操作失败时的错误码是000001/000002/000003...，如此时调用失败所生成的错误码可以是000981，使得调用方在接收到错误码，便知道调用失败以及为什么调用失败等。

步骤S402、将所述第一反馈信息发送至所述调用方，并将所述第一服务节点从所述节点健康列表中删除，以对所述节点健康列表进行更新。

在生成得到第一反馈信息之后，将第一反馈信息发送至调用方，以使得调用方知道调用失败，需要进行再次选择和调用。另外，在确定第一服务节点调用失败时，说明第一服务节点将不可以被调用来响应调用请求，此时将会在节点健康列表中将第一服务节点进行删除，以实现对节点健康列表的更新。

在实际应用中，第一服务节点的调用失败，说明此时第一服务节点正处于关闭进行中，也就是第一服务节点在完成已经响应的调用请求之后将会进行关闭，因此为了避免再次选择第一服务节点来响应调用请求，将会将第一服务节点从节点健康列表中进行删除，以对节点健康列表进行更新。

比如节点健康列表中所记录的服务节点包括：节点1、节点2、节点3、节点4以及节点5，若此时在进行节点调用的选择时，确定节点2的服务状态为关闭进行中，也就是完成自身的请求响应之后将会进行关闭，那么此时将会将节点2进行删除，也就是此时节点健康列表中所记录的服务节点包括：节点1、节点3、节点4以及节点5。

另外，在删除第一服务节点时，也会在节点健康列表所对应的节点调用顺序中将服役服务节点进行删除，比如调用顺序为：节点1、节点2、节点3、节点1、节点2、节点3...，且将节点2删除，那么此时的调用顺序为：节点1、节点3、节点1、节点3、节点1、节点3...，也就是可以直接在节点调用顺序中将顺序位置中将节点2删除掉，以形成新的调用顺序。

步骤S403、当确定所述节点健康列表更新完成时，在更新后的节点健康列表中选择第二服务节点，并在确定所述第二服务节点满足所述节点调用条件时，控制所述第二服务节点响应所述调用请求。

在完成对节点健康列表的更新之后，由于第一服务节点的调用失败，将会再次进行服务节点的选择和确定，以选择合适服务节点对调用请求进行响应。确定合适的服务节点来响应调用请求时，需要节点健康列表更新完成，因此在确定节点健康列表更新完成时，将会在更新后的节点健康列表中选择第二服务节点，并在确定第二服务节点满足节点调用条件时控制第二服务节点响应所接收到的调用请求。

在完成对节点健康列表的更新之后，更新后的节点健康列表所对应的调用顺序会有所改变，由于仅仅是将第一服务节点进行删除，因此各服务节点之间的相对权重没有发生改变，因此各节点之间的在调用顺序中的相对位置在删除第一服务节点之后没有变化，如，更新之前的节点健康列表中所记录的3个节点的调用权重分别为0.2、0.4、0.4，那么其所对应的调用顺序可以为：节点2、节点3、节点1、节点2、节点3、...，若是将节点1删除，此时节点2与节点3的调用权重分别变为0.5和0.5，而两者之间的相对权重0.5/0.5＝1，依旧与原始相对权重0.4/0.4＝1相同，此时所对应的调用顺序为：节点2、节点3、节点2、节点3、...，若是将节点2删除，那么此时节点1和节点3的调用权重变为1/3与2/3，可以得到相对权重没有变化，且此时的调用顺序为：节点3、节点1、节点3、节点3、节点1、节点3、...。

在更新后的节点健康列表中选择第二服务节点时，具体过程与步骤S102至步骤S103所描述的过程相同，仅仅是将节点健康列表替换为更新后的节点健康列表，其所对应的调用顺序和调用权重会随着节点健康列表的更新而发生相应的改变。因此在选择第二服务节点时可以依据步骤S102至步骤S103中所描述的具体实施方式来选择。故在此省略选择第二服务节点的实施例描述。

另外，在确定所得到的第二服务节点是否满足节点调用条件时，判断确定过程与步骤a至步骤c中所表述的过程和实施例相同。因此对于确定第二服务节点是否满足节点调用条件的过程省略，可参照步骤a至步骤c中所描述的实施例。

在一实施例中，选择用来响应调用请求的服务节点的过程是一个循环的过程，在确定了服务节点之后，只有在确定所得到的服务节点满足节点调用条件时才会控制所得到的服务节点来响应调用请求，而在所得到的服务节点不满足节点调用请求时，将会再次进行选择和确定，但是对于循环选择和确定的过程并不是没有限制的，在实际应用中，若服务器对一个调用请求的响应时间过程，显然不满足用户的需求以及服务器运行的策略，因此可以设定一个循环次数的限定(比如设定为5次，具体可根据服务器的实际状态来确定，如服务节点数量多，可以设定高一点，服务节点数量少，可以设定低一点，具体不做限制)，当循环选择的次数超过所设定的次数时，将不再进行循环选择，此时将直接向调用方进行反馈，以告知调用方此时不存在可以被调用的服务节点。

在上述描述的微服务架构的服务节点调用方法中，在接收到调用方的调用请求时，确定需要选择合适的服务节点来响应调用请求，此时将获取所存储的节点健康列表，以得到所记录的服务节点的调用顺序以及调用进度，然后根据所得到的调用顺序和调用进度确定对应的第一服务节点，然后根据第一服务节点自身的服务状态确定是否可以用于被调用，以在满足节点调用条件时调用第一服务节点来响应所接收到的调用请求。实现了在服务节点的调用过程中，保证了节点调用的有效性，提高服务节点调用效率以及系统的运行效率。

请参阅图5，图5为本申请一个实施例中一种微服务架构的服务节点调用装置的示意性框图，该装置用于执行前述的微服务架构的服务节点调用方法。

如图5所示，该微服务架构的服务节点调用装置500包括：

请求接收模块501，用于接收调用方的调用请求，并获取预先所存储的节点健康列表；

信息确定模块502，用于获取所述节点健康列表对应的节点调用信息，以确定所述节点健康列表所包含的服务节点的调用顺序以及调用进度；

节点选择模块503，用于根据所述调用顺序以及调用进度，在所述节点健康列表中确定第一服务节点；

条件判断模块504，用于确定所述第一服务节点是否满足预设的节点调用条件；

节点调用模块505，用于若确定所述第一服务节点满足所述节点调用条件，则控制所述第一服务节点响应所述调用请求。

进一步地，在一个实施例中，所述微服务架构的服务节点调用装置500具体还用于：

获取节点健康列表中所包含的服务节点，并确定所包含的服务节点所对应的调用权重；

以所述节点健康列表所包含的一服务节点为初始服务节点，根据所述调用权重确定所述节点健康列表中所包含的服务节点的调用顺序。

进一步地，在一个实施例中，所述条件判断模块504具体还用于：

识别所述第一服务节点对应的第一服务状态，并根据所述第一服务状态确定所述第一服务节点是否满足预设的节点调用条件；若所述第一服务状态为关闭进行中，则确定所述第一服务节点不满足所述节点调用条件；若所述第一服务状态为正常使用中，则确定所述第一服务节点满足所述节点调用条件。

进一步地，在一个实施例中，所述微服务架构的服务节点调用装置500具体还用于：

若确定所述第一服务节点不满足所述节点调用条件，则根据所述第一服务节点生成第一反馈信息；将所述第一反馈信息发送至所述调用方，并将所述第一服务节点从所述节点健康列表中删除，以对所述节点健康列表进行更新；当确定所述节点健康列表更新完成时，在更新后的节点健康列表中选择第二服务节点，并在确定所述第二服务节点满足所述节点调用条件时，控制所述第二服务节点响应所述调用请求。

进一步地，在一个实施例中，所述微服务架构的服务节点调用装置300具体还用于：

当接收到节点关闭指令时，确定执行所述节点关闭指令的第三服务节点；将所述第三服务节点的服务状态标记为关闭进行中，并监控所述第三服务节点的请求处理状态；当所述请求处理状态满足第一条件时，关闭所述第三服务节点，并将所述节点健康列表中将所述第三服务节点删除。

进一步地，在一个实施例中，所述微服务架构的服务节点调用装置300具体还用于：

当接收到节点开启指令时，确定执行所述节点开启指令的第四服务节点；当所述第四服务节点的启动状态满足第二条件时，对所述第四服务节点进行注册；当所述第四服务节点注册完成时，将所述第四服务节点记录在所述节点健康列表中，并记录所述第四服务节点的注册时间。

进一步地，在一个实施例中，所述微服务架构的服务节点调用装置300具体还用于：

获取当前时间信息，并根据所述当前时间信息以及所述注册时间确定所述第四服务节点的调用权重；根据所述调用权重，确定记录所述第四服务节点的节点健康列表所对应的调用顺序。

需要说明的是，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和各模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

上述的装置可以实现为一种计算机程序的形式，该计算机程序可以在如图6所示的计算机设备上运行。

请参阅图6，图6为本申请一个实施例中计算机设备的结构示意性框图。该计算机设备可以是服务器。

参阅图6，该计算机设备包括通过系统总线连接的处理器、存储器和网络接口，其中，存储器可以包括非易失性存储介质和内存储器。

非易失性存储介质可存储操作系统和计算机程序。该计算机程序包括程序指令，该程序指令被执行时，可使得处理器执行任意一种风险预警的事件图谱构建方法。

处理器用于提供计算和控制能力，支撑整个计算机设备的运行。

内存储器为非易失性存储介质中的计算机程序的运行提供环境，该计算机程序被处理器执行时，可使得处理器执行任意一种微服务架构的服务节点调用方法。

该网络接口用于进行网络通信，如发送分配的任务等。本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

应当理解的是，处理器可以是中央处理单元(Central Processing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

其中，在一个实施例中，所述处理器用于运行存储在存储器中的计算机程序，以实现如下步骤：

接收调用方的调用请求，并获取预先所存储的节点健康列表；获取所述节点健康列表对应的节点调用信息，以确定所述节点健康列表所包含的服务节点的调用顺序以及调用进度；根据所述调用顺序以及调用进度，在所述节点健康列表中确定第一服务节点；确定所述第一服务节点是否满足预设的节点调用条件；

若确定所述第一服务节点满足所述节点调用条件，则控制所述第一服务节点响应所述调用请求。

在一个实施例中，所述处理器在实现所述计算机程序时，还用于实现：

获取节点健康列表中所包含的服务节点，并确定所包含的服务节点所对应的调用权重；以所述节点健康列表所包含的一服务节点为初始服务节点，根据所述调用权重确定所述节点健康列表中所包含的服务节点的调用顺序。

在一个实施例中，所述处理器在实现所述确定所述第一服务节点是否满足预设的节点调用条件时，还用于实现：

识别所述第一服务节点对应的第一服务状态，并根据所述第一服务状态确定所述第一服务节点是否满足预设的节点调用条件；若所述第一服务状态为关闭进行中，则确定所述第一服务节点不满足所述节点调用条件；若所述第一服务状态为正常使用中，则确定所述第一服务节点满足所述节点调用条件。

在一个实施例中，所述处理器在实现确定所述第一服务节点是否满足预设的节点调用条件之后，还用于实现：

若确定所述第一服务节点不满足所述节点调用条件，则根据所述第一服务节点生成第一反馈信息；将所述第一反馈信息发送至所述调用方，并将所述第一服务节点从所述节点健康列表中删除，以对所述节点健康列表进行更新，其中所述节点健康列表；当确定所述节点健康列表更新完成时，在更新后的节点健康列表中选择第二服务节点，并在确定所述第二服务节点满足所述节点调用条件时，控制所述第二服务节点响应所述调用请求。

在一个实施例中，所述处理器在实现所述计算机程序时，还用于实现：

当接收到节点关闭指令时，确定执行所述节点关闭指令的第三服务节点；将所述第三服务节点的服务状态标记为关闭进行中，并监控所述第三服务节点的请求处理状态；当所述请求处理状态满足第一条件时，关闭所述第三服务节点，并将所述节点健康列表中将所述第三服务节点删除。

在一个实施例中，所述处理器在实现所述计算机程序时，还用于实现：

当接收到节点开启指令时，确定执行所述节点开启指令的第四服务节点；当所述第四服务节点的启动状态满足第二条件时，对所述第四服务节点进行注册；当所述第四服务节点注册完成时，将所述第四服务节点记录在所述节点健康列表中，并记录所述第四服务节点的注册时间。

在一个实施例中，所述处理器在实现所述当所述第四服务节点注册完成时，将所述第四服务节点记录在所述节点健康列表中之后，还用于实现：

获取当前时间信息，并根据所述当前时间信息以及所述注册时间确定所述第四服务节点的调用权重；根据所述调用权重，确定记录所述第四服务节点的节点健康列表所对应的调用顺序。

本申请的实施例中还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序中包括程序指令，所述处理器执行所述程序指令，实现本申请实施例提供的任一项微服务架构的服务节点调用方法。

其中，所述计算机可读存储介质可以是前述实施例所述的计算机设备的内部存储单元，例如所述计算机设备的硬盘或内存。所述计算机可读存储介质也可以是所述计算机设备的外部存储设备，例如所述计算机设备上配备的插接式硬盘，智能存储卡(SmartMedia Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。

进一步地，所述计算机可读存储介质可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据区块链节点的使用所创建的数据等。

另外，本申请所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种微服务架构的服务节点调用方法，其特征在于，所述方法包括：

接收调用方的调用请求，并获取预先所存储的节点健康列表；

获取所述节点健康列表对应的节点调用信息，以确定所述节点健康列表所包含的服务节点的调用顺序以及调用进度；

根据所述调用顺序以及调用进度，在所述节点健康列表中确定第一服务节点，其中，所述第一服务节点为当前预调用服务节点；

确定所述第一服务节点是否满足预设的节点调用条件；

若确定所述第一服务节点满足所述节点调用条件，则控制所述第一服务节点响应所述调用请求。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取节点健康列表中所包含的服务节点，并确定所包含的服务节点所对应的调用权重；

以所述节点健康列表所包含的一服务节点为初始服务节点，根据所述调用权重确定所述节点健康列表中所包含的服务节点的调用顺序。

3.根据权利要求2所述的方法，其特征在于，所述确定所述第一服务节点是否满足预设的节点调用条件，包括：

识别所述第一服务节点对应的第一服务状态，并根据所述第一服务状态确定所述第一服务节点是否满足预设的节点调用条件；

若所述第一服务状态为关闭进行中，则确定所述第一服务节点不满足所述节点调用条件；

若所述第一服务状态为正常使用中，则确定所述第一服务节点满足所述节点调用条件。

4.根据权利要求1所述的方法，其特征在于，所述确定所述第一服务节点是否满足预设的节点调用条件之后，还包括：

若确定所述第一服务节点不满足所述节点调用条件，则根据所述第一服务节点生成第一反馈信息；

将所述第一反馈信息发送至所述调用方，并将所述第一服务节点从所述节点健康列表中删除，以对所述节点健康列表进行更新，其中所述节点健康列表存储于区块链的节点中；

当确定所述节点健康列表更新完成时，在更新后的节点健康列表中选择第二服务节点，并在确定所述第二服务节点满足所述节点调用条件时，控制所述第二服务节点响应所述调用请求。

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

当接收到节点关闭指令时，确定执行所述节点关闭指令的第三服务节点；

将所述第三服务节点的服务状态标记为关闭进行中，并监控所述第三服务节点的请求处理状态；

当所述请求处理状态满足第一条件时，关闭所述第三服务节点，并将所述节点健康列表中将所述第三服务节点删除。

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

当接收到节点开启指令时，确定执行所述节点开启指令的第四服务节点；

当所述第四服务节点的启动状态满足第二条件时，对所述第四服务节点进行注册；

当所述第四服务节点注册完成时，将所述第四服务节点记录在所述节点健康列表中，并记录所述第四服务节点的注册时间。

7.根据权利要求6所述的方法，其特征在于，所述当所述第四服务节点注册完成时，将所述第四服务节点记录在所述节点健康列表中之后，还包括：

获取当前时间信息，并根据所述当前时间信息以及所述注册时间确定所述第四服务节点的调用权重；

根据所述调用权重，确定记录所述第四服务节点的节点健康列表所对应的调用顺序。

8.一种微服务架构的服务节点调用装置，其特征在于，所述装置包括：

请求接收模块，用于接收调用方的调用请求，并获取预先所存储的节点健康列表；

信息确定模块，用于获取所述节点健康列表对应的节点调用信息，以确定所述节点健康列表所包含的服务节点的调用顺序以及调用进度；

节点选择模块，用于根据所述调用顺序以及调用进度，在所述节点健康列表中确定第一服务节点；

条件判断模块，用于确定所述第一服务节点是否满足预设的节点调用条件；

节点调用模块，用于若确定所述第一服务节点满足所述节点调用条件，则控制所述第一服务节点响应所述调用请求。

9.一种计算机设备，其特征在于，包括存储器和处理器：

所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行如权利要求1至7中任一项所述的微服务架构的服务节点调用方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机可读指令被所述处理器执行时，使得一个或多个处理器执行如权利要求1至7中任一项所述的微服务架构的服务节点调用方法的步骤。

Images