CN115002114B - 节点处理方法、装置、电子设备、存储介质及服务器 - Google Patents

Abstract

本公开提供了节点处理方法、装置、电子设备、存储介质及服务器，涉及互联网领域，尤其涉及服务热点处理等领域。实现方案为：上游节点在基于与第j个下游节点之间的通信结果，确定第j个下游节点处于通信异常状态的情况下，确定第j个下游节点为服务热点，并确定第j个下游节点的服务热点类型；服务热点类型为N种候选节点类型中之一，且不同候选节点类型对应不同处理方式，N为大于等于2的整数；基于服务热点类型对应的处理方式，对第j个下游节点进行处理。本公开实施例能够提高服务热点发现效率，并对不同类型服务热点执行不同的处理方式，保证服务的稳定运行。

Description

节点处理方法、装置、电子设备、存储介质及服务器

技术领域

本公开涉及互联网技术领域，尤其涉及互联网服务中的服务热点处理技术领域。

背景技术

对于高并发、大流量的互联网服务多采用集群化架构，一个功能服务可能由成百上千个服务器提供支持，这些服务器包括上游节点和下游节点。如图1所示，为一种集群化架构的结构示意图。在图1中，包括注册中心、上游节点和下游节点。上游节点通过注册中心获知下游节点，然后通过负载均衡策略选择一个下游节点与之通信。然而，这上述集群化架构中，如何能够准确及时的发现服务热点就成为需要解决的问题。

发明内容

本公开提供了一种节点处理方法、装置、电子设备、存储介质及服务器。

根据本公开的第一方面，提供了一种节点处理方法，包括：

在基于与第j个下游节点之间的通信结果，确定所述第j个下游节点处于通信异常状态的情况下，确定所述第j个下游节点为服务热点，并确定所述第j个下游节点的服务热点类型；所述服务热点类型为N种候选节点类型中之一，且不同候选节点类型对应不同处理方式，N为大于等于2的整数；

基于所述服务热点类型对应的处理方式，对所述第j个下游节点进行处理。

根据本公开的第二方面，提供了一种节点处理装置，包括：

热点发现模块，用于在基于与第j个下游节点之间的通信结果，确定所述第j个下游节点处于通信异常状态的情况下，确定所述第j个下游节点为服务热点，并确定所述第j个下游节点的服务热点类型；所述服务热点类型为N种候选节点类型中之一，且不同候选节点类型对应不同处理方式，N为大于等于2的整数；

热点处理模块，用于基于所述服务热点类型对应的处理方式，对所述第j个下游节点进行处理。

根据本公开的第三方面，提供了一种电子设备，包括：

至少一个处理器；以及

与该至少一个处理器通信连接的存储器；其中，

该存储器存储有可被该至少一个处理器执行的指令，该指令被该至少一个处理器执行，以使该至少一个处理器能够执行前述第一方面的方法。

根据本公开的第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使计算机执行前述第一方面的方法。

根据本公开的第五方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序在被处理器执行时实现前述第一方面的方法。

根据本公开的第六方面，提供了一种服务器，该服务器包括前述第三方面的电子设备。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

本实施例提供的方案，上游节点在和下游节点的通信过程中，由上游节点基于通信结果来发现服务热点。因此，服务热点的发现并不依赖于注册中心，即使注册中心和下游节点之间通信异常，也不影响发现服务热点。此外，由于集群式架构中多上游节点和多下游节点的架构设计，多个上游节点可以并发发现同一服务热点，因此一个服务热点的发现，并不依赖于某一个上游节点，相较于现有技术中完全依赖注册中心发现服务热点的方案，本实施例能够提高服务热点发现的及时性，进而降低服务热点对上游节点的稳定性的影响。此外，依赖上游节点发现服务热点，实现了从下游节点的使用者角度来发现服务热点，相比现有技术也能够提高服务热点发现的准确性。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是集群化架构示意图；

图2是根据本公开一实施例的节点处理方法的流程示意图；

图3是根据本公开另一实施例的节点处理方法的另一流程示意图；

图4是根据本公开一实施例的节点处理装置的一种组成结构示意图；

图5是根据本公开另一实施例的节点处理装置的另一种组成结构示意图；

图6是用来实现本公开实施例的节点处理方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

集群式架构中存在多个上游节点和多个下游节点，图1中仅以一个上游节点进行举例说明。集群式架构中上游节点和下游节点是多对多的关系，即一个上游节点可以对应多个下游节点，一个下游节点可以对应多个上游节点。

基于图1所示的集群式结构，本公开第一方面提供一种节点处理方法，该方法适用于多个上游节点中的任意一个上游节点。如图2所示，包括：

S201：在基于与第j个下游节点之间的通信结果，确定所述第j个下游节点处于通信异常状态的情况下，确定所述第j个下游节点为服务热点，并确定所述第j个下游节点的服务热点类型；所述服务热点类型为N种候选节点类型中之一，且不同候选节点类型对应不同处理方式，N为大于等于2的整数。

本公开实施例中，第j个下游节点为全量下游节点中的任意一个下游节点。任一下游节点可采用唯一标识来表示。该唯一标识可以为该下游节点的IP(Internet Protocol，网络之间互联的协议)地址+port(端口号)。

S202：基于所述服务热点类型对应的处理方式，对所述第j个下游节点进行处理。

由此可见，上游节点在和下游节点的通信过程中，由上游节点基于通信结果来发现服务热点。因此，服务热点的发现并不依赖于注册中心，即使注册中心和下游节点之间通信异常，也不影响发现服务热点。此外，由于集群式架构中多上游节点和多下游节点的架构设计，多个上游节点可以并发发现同一服务热点，因此一个服务热点的发现，并不依赖于某一个上游节点，相较于现有技术中完全依赖注册中心发现服务热点的方案，本实施例不仅能够提高服务热点发现的及时性、还提高了服务热点被发现的可能性，进而降低服务热点对上游节点的稳定性的影响。此外，依赖上游节点发现服务热点，实现了从下游节点的使用者角度来发现服务热点，相比现有技术也能够提高服务热点发现的准确性。由此，本实施例实现了对注册中心的去中心化，无中心化风险。

进一步的，本实施例中不仅能够发现服务热点，还能够识别服务热点类型。然后对不同类型的服务热点采用不同的处理方式进行处理，使得对服务热点的处理方式更加多样化更加灵活，由此提高集群运行的稳定性。

在一些实施方式中，N种候选节点类型包括连接失败类节点和服务超时类节点。在此基础上还可以根据连接失败的原因将连接失败类节点划分成不同的子节点类型。类似的，还可以根据服务超时的时长不同，将服务超时类节点划分成超时程度不同的子节点类型。为了简化类型，便于管理，本公开中采用连接失败类节点和服务超时类节点两种类型进行举例说明。

其中，连接失败类节点属于无法通信的情况，其对应的处理方式为屏蔽处理，以便于在连接失败类节点恢复正常之前，都避免采用该类下游节点进行业务操作。服务超时类节点属于服务响应超时的情况，可能还会成功返回处理结果，为了能够便于探测该类节点是否恢复正常，该类节点对应的处理方式为限流处理。限流处理即屏蔽针对服务超时类节点的大部分流量，从而采用较小的流量去探测该类节点是否恢复正常通信状态。针对前文所述的第j个下游节点而言，在第j个下游节点的服务热点类型为所述连接失败类节点的情况下，基于所述连接失败类节点对应的屏蔽处理方式，停止与所述第j个下游节点之间的通信(即实现屏蔽处理)；在所述服务热点类型为服务超时类节点的情况下，基于所述服务超时类节点对应的限流处理方式，将针对所述第j个下游节点的网络请求的数量由第一数量减少至第二数量(即实现限流处理)。

接续前文，在服务热点是否恢复正常通信状态这一层面，不同类型的服务热点可具有不同的探测方式。例如，一种可能的实施方式中，针对连接失败类节点，可尝试与其建立连接，若成功建立连接则确定该服务热点恢复正常通信状态。其中，探测的方式可采用拨号连接。拨号连接即采用用户账号和密码连接服务热点，若连接成功则说明该服务热点恢复正常通信状态。针对服务超时类节点，可发送网络请求给该类节点，若接收到针对该网络请求的探测结果，则说明节点恢复正常通信状态。

针对第j个下游节点而言，在第j个下游节点为服务超时类节点的情况下，为了实现小流量探测是否恢复正常通信状态，本实施例中可从针对所述第j个下游节点的多个网络请求中筛选出探测请求；然后发送所述探测请求给所述第j个下游节点，在获取到所述第j个下游节点针对所述探测请求返回的探测结果的情况下，确定所述第j个下游节点恢复为所述正常通信状态。

由此，本实施例中从多个网络请求中筛选出探测请求，实现了对第j个下游节点的流量限制，采用了少量的网络请求可探测出第j个下游节点是否从服务超时状态恢复到正常通信状态，避免对第j个下游节点大流量的访问造成不必要的资源消耗。

此外，本实施例中，为了保证探测的准确性，可筛选出第一指定数量的网络请求作为探测请求，当探测到有第二指定数量(其小于第一指定数量)的网络请求得到探测结果时确定恢复正常通信状态，采用此方式可提高第j个下游节点恢复正常通信状态的可信度。

在一些实施方式中，针对第j个下游节点的多个网络请求、从中去掉探测请求之后，得到剩余网络请求。为了合理利用资源，可将剩余访问请求中的部分或全部请求发送给其他下游节点，并基于其他下游节点的通信结果判断其他下游节点是否为服务热点。由此，针对第j个下游节点的一个大流量的网络请求，被分割为小流量的探测请求去探测第j个下游节点是否恢复正常，而其余网络请求可探测正常的下游节点(即其他下游节点)是否为服务热点。由此实现对大流量网络请求的合理利用。

例如，对于服务超时类节点，在并发场景中，上游节点请求下游节点时，上游节点a以100次/s的频率请求服务超时类下游节点b。做小流量探测时，100个请求中可以使用5个网络请求探测下游节点b是否恢复正常通信状态，另外95个网络请求用于扫描其他正常的下游节点。实施时，可采用令牌桶算法进行热点流量的限流，并开放令牌桶个数配置。此时，针对前述100个网络请求构成热点流量，这100个网络请求可竞争令牌桶，获取到令牌桶的网络请求才会尝试访问服务热点。例如，设置令牌桶个数为5，设置的超时热点退场阈值是80％，那么5个网络请求中有至少4个网络请求返回成功则该认为该服务热点已恢复正常通信状态，执行热点退场逻辑，即将该服务热点重新确定为正常的下游节点。

需要说明的是，本实施例中的其他下游节点可以是有别于第j下游节点的一个下游节点，也可以是有别于第j个下游节点的多个下游节点。

针对第j个下游节点，无论该节点是连接失败类节点还是服务超时类节点，只要该节点恢复正常通信状态，则确定该第j个下游节点为正常节点，并恢复与第j个下游节点之间的正常通信。由此，可保证恢复正常的下游节点能够及时提供服务，提高集群运行的稳定性和效率。

本公开中为了便于管理不同类型的服务热点，设置了不同的节点集合。例如，连接失败类节点对应连接失败类节点集合，服务超时类节点对应服务超时类节点集合。针对第j个下游节点，在确定第j个下游节点的服务热点类型之后，可以确定第j个下游节点的服务节点类型对应的目标节点集合。这里，若服务热点类型为连接失败类节点，目标节点集合为连接失败类节点集合，若服务热点类型为服务超时类节点，目标节点集合为服务超时类节点集合。在确定了第j个下游节点的目标节点集合之后，可以在目标节点集合中对第j个下游节点进行查重，在目标节点集合中并不包含第j个下游节点的历史记录的情况下，将第j个下游节点添加到目标节点集合中。有了相应类型的目标节点集合，可以方便的对重复发现的服务热点进行排重，后面针对服务热点的处理方式也可基于不同的集合来实施。例如，统一对连接失败类节点进行屏蔽处理，统一对服务超时类节点进行限流处理。以限流为例，限流的时候可以查询网络请求的目的节点是否在服务超时类节点集合中，若包含在服务超时类节点集合中则对该节点的网络请求进行限流处理。否则，若未包含在服务超时类节点集合中则无需限流。再例如，针对连接超时类节点集合，在基于负载均衡策略筛选出待通信下游节点时，可以先从全量的下游节点中过滤掉连接失败类节点集合中的服务热点，然后从剩余的下游节点中，基于负载均衡策略选出待通信下游节点进行通信。

由于不同上游节点可并发的发现同一下游节点为服务热点，故此需要对重复发现的服务热点进行排重。本实施例中可采用list(列表)结构存储各类型的服务热点，list结构中可存储服务热点的唯一标识以及添加时间。

由于List结构中允许包含大量重复元素，每次发现服务热点都需要对该服务热点进行一次遍历去重，由此会导致热点入场(即加入目标节点集合)的性能下降。为解决热点入场去重的性能问题，本实施例中可采用map(表)结构来实现连接失败类节点集合和服务超时类节点集合。map结构中采用key-value(键值对)存储服务热点。每个服务热点具有对应的key-value。服务热点的key可定义为服务热点的唯一标识(如IP+port))，value值为服务热点的添加时间。如表1所示，为一种map结构示例，该map结构可适用于连接失败类节点集合和服务超时类节点集合。

表1

key	value
		服务热点1	添加时间T1
服务热点2	添加时间T2
		……	……

由此，将第j个下游节点添加到相应的目标节点集合，可实施为：

在目标节点集合中查找所述第j个下游节点的键；

若未查找到所述第j个下游节点的键，则将所述第j个下游节点的键值对存储到所述目标节点集合中，其中，所述键值对中的键为所述第j个下游节点的唯一标识，所述键值对中的值为所述第j个下游节点作为服务热点的添加时间；

若查找到所述第j个下游节点的键，则更新所述目标节点集合中记录的所述第j个下游节点的添加时间。

基于map结构可实现基于key的自动去重，提高去重效率。在查重时，若发现已记录的服务热点只需更新该服务热点的添加时间即可。由此对于目标节点集合的维护简单便捷，而且采用添加时间可了解各服务热点出现问题的时间，以便于实现基于添加时间的应用需求。例如，可以基于添加时间实现对服务热点的过期淘汰策略。由于添加时间较早的服务热点被恢复的概率极大，故此该过期淘汰策略可以为将添加时间较早的服务热点从目标节点集合中删除。

在一些实施方式中，为了准确高效的识别第j个下游节点的服务热点类型，本实施例中可以通过第j个下游节点的通信结果所反映的错误类型来识别服务热点类型。具体的，可预先设置有连接失败类错误类型以及超时类错误类型。例如通信结果“connectionrefused”对应连接失败、通信结果“i/o timeout”对应连接超时，这两类通信结果的错误类型均为连接失败类错误类型。连接失败类错误类型映射到连接失败类节点，相应的服务热点加入连接失败类节点集合。通信结果“Client.Timeout exceeded while awaitingheaders”对应服务数据返回超时，错误类型为超时类错误类型，映射为服务超时类节点，相应的服务热点加入服务超时类节点集合。

本实施例中通过通信结果的错误类型，能够高效准确的识别出不同服务热点类型。

在另一些实施方式中，对服务热点进行屏蔽和限流可统称为服务热点管控，在服务热点管控的风险控制层面，服务热点如果存在误识别将会导致下游节点不可用。为了控制这类风险，本实施例设置了服务热点的数量上限。也即每种服务热点类型的目标节点集合中不会无上限的存储服务热点。当目标节点集合存储的服务热点总数达到数量上限之后，若发现新的服务热点，则基于最早发现的服务热点恢复正常的可能性最大的原则，将添加时间最早的服务热点从目标节点集合中删除，以便于被删除的服务热点继续提供服务。而新发现的服务热点可加入到目标节点集合中。基于此，本实施例中在将所述第j个下游节点添加到目标节点集合之前，还可以获取所述目标节点集合中包含的服务热点的数量：在所述服务热点的数量达到数量上限的情况下，基于所述服务热点的历史记录，确定添加时间最早的待处理服务热点，将所述待处理服务热点从所述目标节点集合中删除。

由此，在目标节点集合已经满员的情况下，可以删除掉添加时间最早的服务热点，让大概率已恢复正常的下游节点继续提供服务。即使该下游节点仍未恢复正常，也可以通过本实施例提供的节点处理方法重新将其加入到目标节点集合中。而对于新发现的服务热点能够及时地添加到目标节点集合中以便于对其进行处理，还可以进行根因分析来进行解决问题。该根因分析可以是提醒运维人员对该新发现的服务热点的产生原因进行分析，并解决问题以使该服务热点恢复正常。根因分析可总结为检测网络问题或硬件问题。在识别出第j个下游节点的服务热点类型之后，对服务超时类节点，可能是负载较高，可考虑通过优化服务接口性能耗时，或增加吞吐量等方式解决该类节点的问题。对连接失败类节点，如宕机的服务热点可具体查一下宕机原因，然后解决问题，以便于使得服务热点早日恢复正常。

在目标节点集合的数量上限设置层面，数量上限可以是根据经验值设置的值，也可以是根据仿真实验设置的值。

此外，本实施例中为了更好的进行风险管控，可以采用固定上限阈值和上限比例双保险的方式确定数量上限。可实施为：所述数量上限为第一参数和第二参数中的最小值，所述第一参数为预设的数量上限值、所述第二参数是基于预设热点比例计算得到的。例如，可以设置服务热点的最大屏蔽个数10个(即第一参数)，最大屏蔽上限比例20％(由此可计算出第二参数)，如当全量的下游节点数为100个时，第二参数为20％*100＝20个。最终生效的最大屏蔽数量为min(10,0.2*100)＝10(即数量上限)。通过双保险的方式确定服务热点的数量上限，能够确保即使服务热点识别有误，屏蔽的热点数量不会超过数量上限，由此保证有充足的下游节点能够提供服务。

在固定上限阈值和上限比例设置方面，可以基于经验值设置。为了能够准确方便的确定数量上限，本实施例提供了一种量化运行效果的实施方式，并可基于该运行效果来确定数量上限。可实施为基于目标节点集合中所述服务热点的数量和所述数量上限确定健康分数；然后，基于所述健康分数以及健康分数阈值，调整所述数量上限。

一种可能的实施方式为，先初始化固定上限阈值和上限比例均为一个较小的值，然后确定一健康分数，所述健康分数与所述目标节点集合中的服务热点的数量正相关，并与所述数量上限负相关；健康分数的确定方式可如公式(1)所示：

健康分数＝目标节点集合中的服务热点的总量/数量上限(1)

若所述健康分数小于或等于健康分数阈值，则保持所述数量上限不变；若所述健康分数大于所述健康分数阈值，则提高所述数量上限。提高数量上限的方式可通过调整固定上限阈值和上限比例来实现。例如提高固定上限阈值和/或上限比例，从而提高数量上限。

一种可能的实施方式中，健康分数阈值可设置为1。健康分数小于或等于1说明数量上限设置较为合理，健康状态良好，可不调整数量上限；若健康分数大于1说明服务热点较多，需要提高数量上限。

由此，通过健康分数实现对运行效果的量化，并能够合理的设置数量上限。

需要说明的是，不同业务的数量上限可以单独设置。例如下游节点b提供的业务服务包括b1、b2和b3，则b1、b2和b3可分别对应各自的数量上限。由此实现不同业务根据需求的自适应上限配置。

此外，本实施例中还可以抽样检查连接失败类节点集合和服务超时类节点集合，进而评估服务热点识别的准确率。例如，从20个服务热点中对5个服务热点进行人工检查，由此确定服务热点发现机制的准确性。

上游节点选择下游节点进行通信时，先获取全量的下游节点；然后，从所述全量的下游节点中剔除掉连接失败类节点，得到候选下游节点；之后，采用负载均衡策略从所述候选下游节点中筛选出下游节点作为所述第j个下游节点执行本公开的方案。

由于全量的下游节点也可能产生变化，故此全量的下游节点并非一成不变，为了确保目标节点集合的准确性，本公开实施例中在将第j个下游节点添加到目标节点集合之后还可以执行以下操作：

探测所述第j个下游节点是否在全量的下游节点中，

若所述第j个下游节点未包含在所述全量的下游节点中，则将所述第j个下游节点从所述目标节点集合中删除。

由此，当全量的下游节点中删除掉下游节点时，若该下游节点是服务热点，则能够适应性更新目标节点集合，进而保证目标节点集合的准确性。进而减少对不必要服务热点的探测以节约处理资源。

为便于理解本公开实施例提供的节点处理方法，下面结合图3对该方法进行系统性的说明。如图3所示：

在初始化阶段，上游节点的服务启动后，在步骤S301中，执行初始化以及加载配置，以便于完成初始化配置，该初始化配置包括基础配置和下游节点实例配置。基础配置例如包括超时时间配置、连接失败后重试次数的配置等，该下游节点实例配置即获取配置的全量的下游节点(包括各下游节点的IP+port)并存储至全部下游实例池中。

然后，在步骤S302中，异步协程下游服务发现用于定时更新全部下游实例池，以便于实现对全量的下游节点的更新。该定时更新例如可每5s执行一次。

此外，服务启动后，在步骤S303中，完成对以下4项的配置，包括：

1)连接超时时间，该连接超时时间用于探测连接失败类节点是否恢复正常通信状态。

2)上限比例的配置，即用于确定服务热点的数量上限的第二参数；

3)固定上限阈值的配置，即用于确定服务热点的数量上限的第一参数；

4)定时健康检查时间和重置令牌桶的时间。其中，健康检查时间用于定时确定健康分数，以便于评估运行效果，动态调整服务热点的数量上限。重置令牌桶的时间用于定时重置令牌桶。例如每5s执行一次健康检查和重置令牌桶以便于和步骤S302中对全部下游实例池的更新节奏一致。

以上4项配置可用于在步骤S311中执行相应操作。此外，在步骤S311中配合智能负载均衡策略时，可从全部下游实例池中滤除连接失败类节点，得到候选下游节点，由此实现对连接失败类节点的完全屏蔽。

在步骤S304中，异步协程定时执行以下任务，包括：

1)探测连接失败类节点集合和服务超时类节点集合内的服务热点是否恢复正常通信状态。若恢复正常通信状态则将服务热点从相应的目标节点集合中删除。

2)检查服务热点是否已从全部下游实例池中摘除，若是，该服务热点也将从相应的目标节点集合中移除。

3)重置令牌桶以便于对服务超时类节点进行限流处理

在步骤S305中，上游节点的发起一次网络请求，则在步骤S306中，获取初始化阶段的基础配置。然后在步骤S307中，根据基础配置选择相应的负载均衡策略，并基于负载均衡策略选择一个下游节点。其中，可供选择的负载均衡策略包括随机策略、轮询策略、哈希策略以及智能负载均衡策略。

随机策略、轮询策略、哈希策略会从全部下游实例池中选择一个下游节点，无法实现对服务热点的屏蔽。智能负载均衡策略可实获取连接失败类节点，然后从全部下游实例池中过滤掉连接失败类节点，得到候选下游节点，然后从候选下游节点中依据随机策略、轮询策略、哈希策略中的一种负载均衡策略筛选出一个下游节点进行通信。

在步骤S308中，筛选出下游节点后，连接该下游节点，并获取通信结果。在步骤S309中根据通信结果判断下游节点是否通信异常，若正常，则在步骤S310中获取下游节点返回的内容并解析后返回结果，至此一次网络请求结束。

若下游节点通信异常，则基于通信结果的错误类型确定下游节点的服务热点类型，并将该下游节点作为服务热点添加到相应的目标节点集合中。若服务热点为连接失败类节点则添加到连接失败类节点集合中，服务热点为服务超时类节点则添加到服务超时类节点集合中。无论连接失败类节点集合还是服务超时类节点集合均采用map结构存储，存储的内容是服务热点的唯一标识和添加时间这一键值对。对于新发现的服务热点，若对应的目标节点集合中的服务热点的数量已达到数量上限，则删除添加时间最早的服务热点后，将新发现的服务热点存储到该目标节点集合中。

对于连接失败类节点采用拨号连接的方式探测是否恢复正常通信状态，对于服务超时类节点则采用小流量的探测方式探测该服务热点是否恢复正常通信状态。此外，服务热点若从全部下游实例池中摘除，则该服务热点也会从相应的目标节点集合中移除。

本公开第二方面实施例提供一种节点处理装置，如图4所示，包括：

热点发现模块401，用于在基于与第j个下游节点之间的通信结果，确定所述第j个下游节点处于通信异常状态的情况下，确定所述第j个下游节点为服务热点，并确定所述第j个下游节点的服务热点类型；所述服务热点类型为N种候选节点类型中之一，且不同候选节点类型对应不同处理方式，N为大于等于2的整数；

热点处理模块402，用于基于所述服务热点类型对应的处理方式，对所述第j个下游节点进行处理。

其中，所述N种候选节点类型包括：连接失败类节点和服务超时类节点；

所述热点处理模块402用于：

在所述服务热点类型为所述连接失败类节点的情况下，基于所述连接失败类节点对应的屏蔽处理方式，停止与所述第j个下游节点之间的通信；

在所述服务热点类型为所述服务超时类节点的情况下，基于所述服务超时类节点对应的限流处理方式，将针对所述第j个下游节点的网络请求的数量由第一数量减少至第二数量。

所述热点处理模块402还用于：

在确定所述第j个下游节点恢复为正常通信状态的情况下，确定所述第j个下游节点为正常节点，并恢复与所述第j个下游节点之间的正常通信。

所述热点处理模块402还用于：

在所述服务热点类型为所述服务超时类节点的情况下，从针对所述第j个下游节点的多个网络请求中筛选出探测请求；

发送所述探测请求给所述第j个下游节点，在获取到所述第j个下游节点针对所述探测请求返回的探测结果的情况下，确定所述第j个下游节点恢复为所述正常通信状态。

所述热点处理模块402还用于：

在所述确定所述第j个下游节点的服务热点类型之后，确定所述服务热点类型对应的目标节点集合，在所述目标节点集合中不包含所述第j个下游节点的历史记录的情况下，将所述第j个下游节点添加至所述目标节点集合。

所述热点处理模块402还用于：

获取所述目标节点集合中包含的服务热点的数量；

在所述服务热点的数量达到数量上限的情况下，基于所述服务热点的历史记录，确定添加时间最早的待处理服务热点，将所述待处理服务热点从所述目标节点集合中删除；其中，所述数量上限为第一参数和第二参数中的最小值，所述第一参数为预设的数量上限值、所述第二参数是基于预设热点比例计算得到的。

在图4的基础上，本公开还提供一种节点处理装置，如图5所示所述装置还包括：

数量上限更新模块403，用于基于所述服务热点的数量和所述数量上限确定健康分数；

基于所述健康分数以及健康分数阈值，调整所述数量上限。

本实施例提供的方案，上游节点在和下游节点的通信过程中，由上游节点基于通信结果来发现服务热点。因此，服务热点的发现并不依赖于注册中心，即使注册中心和下游节点之间通信异常，也不影响发现服务热点。此外，由于集群式架构中多上游节点和多下游节点的架构设计，多个上游节点可以并发发现同一服务热点，因此一个服务热点的发现，并不依赖于某一个上游节点，相较于现有技术中完全依赖注册中心发现服务热点的方案，本实施例不仅能够提高服务热点发现的及时性、还提高了服务热点被发现的可能性，进而降低服务热点对上游节点的稳定性的影响。此外，依赖上游节点发现服务热点，实现了从下游节点的使用者角度来发现服务热点，相比现有技术也能够提高服务热点发现的准确性。由此，本实施例实现了对注册中心的去中心化，无中心化风险。

进一步的，本实施例中不仅能够发现服务热点，还能够识别服务热点类型。然后对不同类型的服务热点采用不同的处理方式进行处理，使得对服务热点的处理方式更加多样化更加灵活，由此能够提高集群运行的稳定性。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图6示出了可以用来实施本公开的实施例的示例电子设备600的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图6所示，电子设备600包括计算单元601，其可以根据存储在只读存储器(ROM)602中的计算机程序或者从存储单元608加载到随机访问存储器(RAM)603中的计算机程序，来执行各种适当的动作和处理。在RAM 603中，还可存储电子设备600操作所需的各种程序和数据。计算单元601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

电子设备600中的多个部件连接至I/O接口605，包括：输入单元606，例如键盘、鼠标等；输出单元607，例如各种类型的显示器、扬声器等；存储单元608，例如磁盘、光盘等；以及通信单元609，例如网卡、调制解调器、无线通信收发机等。通信单元609允许电子设备600通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元601可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元601的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元601执行上文所描述的各个方法和处理。例如，在一些实施例中，上文所描述的各个方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元608。在一些实施例中，计算机程序的部分或者全部可以经由ROM 602和/或通信单元609而被载入和/或安装到电子设备600上。当计算机程序加载到RAM603并由计算单元601执行时，可以执行上文所描述的各个方法的一个或多个步骤。备选地，在其他实施例中，计算单元601可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行上文所描述的各个方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入、或者触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (11)

1.一种节点处理方法，应用于多个上游节点中任一所述上游节点，所述方法包括：

在基于与第j个下游节点之间的通信结果，确定所述第j个下游节点处于通信异常状态的情况下，确定所述第j个下游节点为服务热点，并确定所述第j个下游节点的服务热点类型；所述服务热点类型为N种候选节点类型中之一，且不同候选节点类型对应不同处理方式，N为大于等于2的整数；

确定所述服务热点类型对应的目标节点集合；

在所述目标节点集合中不包含所述第j个下游节点的历史记录的情况下，获取所述目标节点集合中包含的服务热点的数量；

在所述服务热点的数量达到数量上限的情况下，基于所述服务热点的历史记录，确定添加时间最早的待处理服务热点，将所述待处理服务热点从所述目标节点集合中删除，并将所述第j个下游节点添加至所述目标节点集合；其中，所述数量上限的初始值为第一参数和第二参数中的最小值，所述第一参数为预设的数量上限值、所述第二参数是基于预设热点比例计算得到的；

基于所述服务热点类型对应的处理方式，对所述第j个下游节点进行处理；

基于所述服务热点的数量和所述数量上限确定健康分数；

基于所述健康分数以及健康分数阈值，调整所述数量上限。

2.根据权利要求1所述的方法，其中，所述N种候选节点类型包括：连接失败类节点和服务超时类节点；

所述基于所述服务热点类型对应的处理方式，对所述第j个下游节点进行处理，包括：

在所述服务热点类型为所述连接失败类节点的情况下，基于所述连接失败类节点对应的屏蔽处理方式，停止与所述第j个下游节点之间的通信；

在所述服务热点类型为所述服务超时类节点的情况下，基于所述服务超时类节点对应的限流处理方式，将针对所述第j个下游节点的网络请求的数量由第一数量减少至第二数量。

3.根据权利要求2所述的方法，所述方法还包括：

在确定所述第j个下游节点恢复为正常通信状态的情况下，确定所述第j个下游节点为正常节点，并恢复与所述第j个下游节点之间的正常通信。

4.根据权利要求3所述的方法，所述方法还包括：

在所述服务热点类型为所述服务超时类节点的情况下，从针对所述第j个下游节点的多个网络请求中筛选出探测请求；

发送所述探测请求给所述第j个下游节点，在获取到所述第j个下游节点针对所述探测请求返回的探测结果的情况下，确定所述第j个下游节点恢复为所述正常通信状态。

5.一种节点处理装置，应用于多个上游节点中任一所述上游节点，所述装置包括：

热点发现模块，用于在基于与第j个下游节点之间的通信结果，确定所述第j个下游节点处于通信异常状态的情况下，确定所述第j个下游节点为服务热点，并确定所述第j个下游节点的服务热点类型；所述服务热点类型为N种候选节点类型中之一，且不同候选节点类型对应不同处理方式，N为大于等于2的整数；

热点处理模块，用于基于所述服务热点类型对应的处理方式，对所述第j个下游节点进行处理；

所述热点处理模块，还用于：

确定所述服务热点类型对应的目标节点集合；

在所述目标节点集合中不包含所述第j个下游节点的历史记录的情况下，获取所述目标节点集合中包含的服务热点的数量；

在所述服务热点的数量达到数量上限的情况下，基于所述服务热点的历史记录，确定添加时间最早的待处理服务热点，将所述待处理服务热点从所述目标节点集合中删除，并将所述第j个下游节点添加至所述目标节点集合；其中，所述数量上限的初始值为第一参数和第二参数中的最小值，所述第一参数为预设的数量上限值、所述第二参数是基于预设热点比例计算得到的；

以及所述装置还包括：

数量上限更新模块，用于基于所述服务热点的数量和所述数量上限确定健康分数；

基于所述健康分数以及健康分数阈值，调整所述数量上限。

6.根据权利要求5所述的装置，其中，所述N种候选节点类型包括：连接失败类节点和服务超时类节点；

所述热点处理模块用于：

在所述服务热点类型为所述连接失败类节点的情况下，基于所述连接失败类节点对应的屏蔽处理方式，停止与所述第j个下游节点之间的通信；

在所述服务热点类型为所述服务超时类节点的情况下，基于所述服务超时类节点对应的限流处理方式，将针对所述第j个下游节点的网络请求的数量由第一数量减少至第二数量。

7.根据权利要求6所述的装置，所述热点处理模块还用于：

在确定所述第j个下游节点恢复为正常通信状态的情况下，确定所述第j个下游节点为正常节点，并恢复与所述第j个下游节点之间的正常通信。

8.根据权利要求7所述的装置，所述热点处理模块还用于：

在所述服务热点类型为所述服务超时类节点的情况下，从针对所述第j个下游节点的多个网络请求中筛选出探测请求；

发送所述探测请求给所述第j个下游节点，在获取到所述第j个下游节点针对所述探测请求返回的探测结果的情况下，确定所述第j个下游节点恢复为所述正常通信状态。

9.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-4中任一项所述的方法。

10.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使计算机执行权利要求1-4中任一项所述的方法。

11.一种服务器，包括如权利要求9所述的电子设备。