CN114328156A

CN114328156A - 协议端口的健康检测方法、装置、设备及可读存储介质

Info

Publication number: CN114328156A
Application number: CN202111629880.5A
Authority: CN
Inventors: 顾悦; 黄岗; 周圣强
Original assignee: OP Retail Suzhou Technology Co Ltd
Current assignee: OP Retail Suzhou Technology Co Ltd
Priority date: 2021-12-28
Filing date: 2021-12-28
Publication date: 2022-04-12
Anticipated expiration: 2041-12-28
Also published as: CN114328156B

Abstract

本发明公开了一种协议端口的健康检测方法，包括预先根据每个待检测端口元数据形成对应的检测任务，并设定各个检测任务对应的检测周期以及检测起始时间；对每个待检测端口元数据，按照对应的检测起始时间每间隔对应的检测周期，执行一次对应的检测任务，获得检测结果。本申请中对每个检测任务每间隔一定的检测周期即可执行一次，保证及时发现各个协议端口的不可用状态，以便用户及时采取相应的应对措施，进而保证业务处理的可靠性。本申请还提供了一种协议端口的健康检测装置、设备以及计算机可读存储介质，具有上述有益效果。

Description

协议端口的健康检测方法、装置、设备及可读存储介质

技术领域

本发明涉及协议端口检测技术领域，特别是涉及一种协议端口的健康检测方法、装置、设备以及计算机可读存储介质。

背景技术

随着计算机技术在各行各业的广泛运用，服务器也越来越多样化的完成各种业务处理任务。而业务任务的复杂多样性以及业务系统可用性与构建整个完整系统所需成本，决定了业务系统是以多个经过合理拆分后的微服务的形式存在，各个微服务之间需要数据交互，而微服务的任何状态信息都是极其重要的；尤其是在一些上游服务中，一旦某个上游数据服务进程宕机，其下游的调用者必然会出现不可用等问题，甚至出现更严重的多米诺效应。因此及时的感知服务进程的存活状态便是极其重要的。

此外，对于业务复杂性越高的服务而言，其需要调用其他服务进程的数量也就越多，需要检测感知是否存活的服务进程的数量也就越多，由此如何合理有效的保证大批量的服务进程是否存活，是正常完成业务处理的关键因素之一。

发明内容

本发明的目的是提供一种协议端口的健康检测方法、装置、设备以及计算机可读程度介质，在一定程度上保证了协议端口的健康检测的及时性和有效性。

为解决上述技术问题，本发明提供一种协议端口的健康检测方法，包括：

预先根据每个待检测端口元数据形成对应的检测任务，并设定各个所述检测任务对应的检测周期以及检测起始时间；

对每个所述待检测端口元数据，按照对应的所述检测起始时间每间隔对应的所述检测周期，执行一次对应的所述检测任务，获得检测结果。

可选地，对每个所述待检测端口元数据，按照对应的所述检测起始时间每间隔对应的所述检测周期，执行一次对应的所述检测任务，获得检测结果，包括：

执行各个所述检测任务中当前时刻为检测时间的当前检测任务，获得所述检测结果；

按照所述当前检测任务对应的检测周期设定所述当前检测任务下一次被执行时距离当前时刻的延时时长；其中，所述检测周期的时长等于所述延时时长。

可选地，设定各个所述检测任务对应的检测周期以及检测起始时间，包括：

对各个所述检测任务设定不同的检测周期和不同的检测起始时间，以使同一时刻执行的检测任务的数量不超过预设数量。

如权利要求1所述的协议端口的健康检测方法，其特征在于，执行所述检测任务的过程包括：

向所述检测任务对应的端口地址发起访问；

若请求超时未响应或请求响应结果的状态码为非正常状态码，则所述检测任务对应的端口为不健康。

如权利要求1所述的协议端口的健康检测方法，其特征在于，当接收到元数据变更请求时，对所述元数据变更请求对应的待检测端口元数据进行变更；

对变更后的待检测端口元数据形成新的检测任务，并设定变更后的检测任务的检测周期和检测起始时间。

可选地，在获得检测结果之后，还包括：

通过发布者按照预先注册形成的订阅者列表，将所述检测结果作为检测结果事件发布到预先订阅者列表中的各个订阅者；

其中，预先注册形成所述订阅者列表的过程包括：

获得所述订阅者根据需要订阅的检测结果事件进行订阅注册的注册信息；

根据所述注册信息中的检测结果事件，结合预先确定的每个所述检测结果事件和对应的发布者之间一一对应关系，查找所述订阅者对应的发布者；

将所述订阅者的注册信息发送至对应的所述发布者，以便所述发布者将对应的所述订阅者加入所述发布者的订阅者列表。

可选地，形成所述对应关系的过程包括：

通过hash表将每个所述发布者需发布的检测任务事件作为键，所述发布者作为值形成映射关系，并以所述映射关系作为每个所述检测任务事件和发布者之间的一一对应关系。

可选地，当存在待检测端口元数据发生变更，并基于变更后的待检测端口元数据形成新的检测任务之后，还包括：

根据所述新的检测任务的检测结果事件和对应的发布者，对所述对应关系进行更新；

根据更新后的所述对应关系，对订阅所述新的检测任务的检测结果事件的订阅者重新进行订阅注册。

一种协议端口的健康检测装置，包括：

形成任务模块，用于预先根据每个待检测端口元数据形成对应的检测任务，并设定各个所述检测任务对应的检测周期以及检测起始时间；

执行任务模块，用于对每个所述待检测端口元数据，按照对应的所述检测起始时间每间隔对应的所述检测周期，执行一次对应的所述检测任务，获得检测结果。

一种协议端口的健康检测设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序，以实现如上任一项所述的协议端口的健康检测方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行以实现如上任一项所述的协议端口的健康检测方法的步骤。

本发明所提供的一种协议端口的健康检测方法，包括预先根据每个待检测端口元数据形成对应的检测任务，并设定各个检测任务对应的检测周期以及检测起始时间；对每个待检测端口元数据，按照对应的检测起始时间每间隔对应的检测周期，执行一次对应的检测任务，获得检测结果。

可以理解的是，对各个服务进程的调用本质是需要通过协议端口实现调用数据的交互，为此，本申请中先基于各个协议端口对应的待检测端口元数据形成检测服务进程是否存活的检测任务，为了避免因为检测任务数量过多，导致存在检测任务执行不及时、或存在漏执行的情况，本申请中对每个检测任务设定一个检测周期，进而保证每个检测任务每间隔一定的检测周期即可执行一次，也即是每间隔一个检测周期，对各个协议端口的服务进程是否存活完成一次检测，从而保证及时发现各个协议端口的不可用状态，以便用户及时采取相应的应对措施，进而保证业务处理的高效性。

本申请还提供了一种协议端口的健康检测装置、设备以及计算机可读存储介质，具有上述有益效果。

附图说明

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

图1为本申请实施例提供的协议端口的健康检测方法的流程示意图；

图2为本发明实施例提供的协议端口的健康检测装置的结构框图。

具体实施方式

一般在对数量众多的协议端口进行服务进程是否存活的健康检测时，可以先形成每个协议端口对应的检测任务列表，再以轮询的方式逐个实现各个检测任务。这种检测方式对需要检测的协议端口数量较少的情况，能够保证每个协议端口的检测任务正常执行，但是一段协议端口的数量众多，也就导致排列在前的检测任务可以优先执行，而排列在前的检测任务则会延后执行，这也就导致各个检测任务的执行上存在一定关联性，且排列靠后的检测任务可能因为长时间未被执行导致其对应的协议端口出现故障不可用而未被及时感知，进而影响整个业务的处理运行。

此外，如果某些协议端口发生变更，且变更之后的协议端口对应的检测任务并入在刚刚执行过的检测任务之间，这会导致变更后的协议端口出现漏检或者需要等待更长时间才能够检测，增加了协议端口故障无法感知的风险。

为此，本申请中为了避免部分检测任务长时间未被执行的问题，以及各个检测任务的执行顺序受其他检测任务影响的问题，对每个检测任务设定检测周期，以按照固定检测周期进行各个检测任务代替按照检测任务列表顺序的执行方式，保证了每个检测任务执行的独立性，避免检测任务遗漏未执行或执行不及时的问题。

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，图1为本申请实施例提供的协议端口的健康检测方法的流程示意图，该方法可以包括：

S11：预先根据每个待检测端口元数据形成对应的检测任务，并设定各个检测任务对应的检测周期以及检测起始时间。

本申请中所需要进行健康检测的协议端口，可以是目前较为常用的类似于http协议端口、TCP协议端口等；相应的待检测端口元数据可以包括：内容包含了检查方式(TCP端口探测还是HTTP请求检测)，检测目标的IP，端口，以及URI。

每个待检测端口元数据都对应一个协议端口以及一个检测任务。如果协议端口的数量较多，显然检测任务的数量也相应较多。显然，为了避免执行各个检测任务占用的线程数量过多，影响整个系统的运行性能，应当保证同一时刻执行的检测任务的数量不至于过多。而要达到这一目的，可以通过合理设定各个检测任务的检测周期和检测起始时间来实现。

例如，可以设定各个检测任务的检测周期和检测起始时间各不相同来实现。为了简化各个检测任务的检测周期和检测起始时间的设定过程，可以对各个检测任务进行分批划分，每一批检测任务的检测周期和检测起始时间相同，每批检测任务的数量大体相同，不超出设定数量即可，且保证各批检测任务无论循环执行多少各检测周期，都不会出现两批检测任务的检测时间发生重合即可。

此外，在实际应用中还可以地基于各个检测任务对应的协议端口使用的频率、传输数据的重要性等等设定优先级，并将优先级高的协议接口对应的检测任务对应的检测周期短、检测起始时间早等。还可以有其他设定检测周期和检测起始时间的方式，本申请中不一一列举。

另外，在实际应用中，随着业务的运行，其需要调用的微服务也可能随时发生变化，或者是微服务的某些数据存在变化等等，都可能造成待检测端口元数据的变化。

为此，当接收到元数据变更请求时，就需要对新增加的待检测元数据形成新的检测任务，并设定该检测任务对应的检测周期以及检测起始时间。而对于发生数据变更的待检测元数据而言，可以依据变更后的待检测元数据形成新的检测任务以替代原有的检测任务，并重新基于新的检测任务进行检测周期以及检测起始时间的设定。

S12：对每个待检测端口元数据，按照对应的检测起始时间每间隔对应的检测周期，执行一次对应的检测任务，获得检测结果。

对于不同的协议端口，可以采用不用的方式进行健康状态的检测，例如以http协议端口为例，可以依据待检测端口元数据中包含的端口地址发起访问请求；正常情况下，在一定时间内该访问请求能够被正常响应，则可以确定对应的协议端口处于存活状态，而若是请求超时未响应或者是请求响应结果的状态码为非正常的状态码，也即不是200状态码，则可以认为该检测结果的为不健康的状态。

为了保证每个检测任务能够按照固定的检测周期，周期性的被重复执行，最简单的方式是对该检测任务设定一个类似闹钟的checkPeriod参数，使得该检测任务每间隔固定时间段，即可重新被执行。但这种执行方式需要获知检测任务开始执行的时间存根，一旦该检测任务的时间存根丢失，该检测任务将无限循环执行，无法随时终止，缺乏灵活性。

为此。在本申请的另一可选地实施例中，在执行检测任务时，可以进一步地包括：

执行各个检测任务中当前时刻为检测时间的当前检测任务，获得检测结果；

按照当前检测任务对应的检测周期设定当前检测任务下一次被执行时距离当前时刻的延时时长；其中，检测周期的时长等于延时时长。

在实际应用中，可以按照各个检测任务的先后顺序形成检测任务队列，每到达一个检测执行时间，即可将队列中相应的检测任务进行执行检测，检测完成以后，可以重新对执行完成的检测任务设定一个下次执行的延时时长，并重新将该检测任务按照该延时时长并入到队列中，显然，在经过该延时时长之后，该检测任务可以被重新执行。

相对于设定固定时长间隔的闹钟而言，本实施例中相当于每次对检测任务设定单次执行的闹钟，且在每次执行检测任务之后，重新设定闹钟，这能够在一定程度上避免时间存根丢失的问题。

对于上述实施例可以设定各种软件功能组件的方式实现。具体可以如下组件：

Subscriber：事件订阅接口，是待检测端口元数据的入口，可以发布待检测端口元数据的变动事件及加载事件，负责向下一级Manager传递待检测端口元数据、加载事件、变动事件。加载事件是对于原先设置的待检测端口元数据进行加载(诸如从数据库或者缓存等)；变动事件主要是对待检测端口元数据进行变更，例如检测周期的更新，ip信息更新等。

Manager：待检测端口元数据的管理中心，负责维护检测任务结果和对应的服务实例的状态信息，对于检测任务的构造，以及负责管理对于任务的启动停止的操作。管理中心通过订阅一个Task(检测任务)抛出的检测结果事件，来更新对应的服务进程状态或者集群服务的状态(其中，也维护了一个待检测端口元数据与检测任务的映射关系，以此达到彼此相互管理影响的操作)。

Reactor：Task任务启动器，负责对Manager构造出的检测任务进行启动(其本身是一个延时队列，启动的过程便是将检测任务加入到这个延时队列中，当到达指定的时延之后，这个时间点的检测任务便会被取出执行，执行的过程是调用Task的回调函数，当检测任务被执行调用之后，那这个延迟时间点的任务便会被删除)。

Task，一个具体的检测任务，其核心是一个回调函数，包含了根据待检测端口元数据的配置来判断是应该发送http请求检测还是应该是通过TCP端口探测检测，是检查任务的最小执行单元。Task的检查结果不管是Success还是Fail都会通过Publisher将其发布出去。该检测结果事件根据需要去订阅并对其做处理(如报警等)。

Publisher，发布者，负责发布Task检查结果的事件。Publisher和subscriber可以是一套事件通知机制，二者之间的关联仅仅是通过事件来关联，低耦合。

如上所述，在获得各个检测任务的检测结果后，还需要发布者将检测结果以检测结果事件的形式进行发布，而每个发布者主要是对其预先注册好的订阅者列表中的订阅者发布检测任务的检测结果。

对于发布者的订阅者列表的注册过程可以包括：

获得订阅者根据需要订阅的检测结果事件进行订阅注册的注册信息；

根据注册信息中的检测结果事件，结合预先确定的每个检测结果事件和对应的发布者之间一一对应关系，查找订阅者对应的发布者；

将订阅者的注册信息发送至对应的发布者，以便发布者将对应的订阅者加入发布者的订阅者列表。

常见的事件订阅组件往往都只有订阅者和发布者以及事件三个角色，在使用的时候必须通过发布者去发布事件，并且订阅者必须知道发布者是谁，然后才能将自己注册进发布者内部的订阅者列表。

这种方式虽然实现了事件订阅，但在某种意义上耦合了订阅者与发布者(要求订阅者必须知道这个订阅的事件由谁发布，但对于订阅者本身而言其关注的只是事件本身，但是现在却也要关注发布者)；而对于同一个事件的发布者而言，其往往存在大批量的订阅者，一旦发布者的部分数据信息发生变更，也就涉及到大批量的订阅者相关注册信息的变更，进而在一定程度上增加了事件发布的复杂程度，并形成实际意义上的订阅者与发布者的强耦合。

为此，本实施例中先确定了检测结果事件和发布者之间的一一对应关系。可以引入统一通知中心(UnifiedNotifyCenter)，通过统一通知中心，订阅者会在统一通知中心初始化完毕的时调用其注册方法，统一通知中心通过对订阅者的解读(关心何种事件)，从对应关系中找到合适的发布者，并将实际的注册执行交给发布者去执行。发布者注册订阅者会将订阅者加入到内部维护的订阅者列表中，加入之后注册流程即完成。

事件的发布也可以是通过统一通知中心，通过对应关系找到对应的发布者，发布者则在内部循环订阅者列表，逐个调用订阅者的回调函数，当订阅者的回调函数被调用完成时，检测结果事件的消费也完成了。为了解决订阅者列循环(由于列表过长，列表尾部的回调函数被同步调用不及时)的问题，发布者会使用异步的方式去执行这个回调函数。

此外，对于形成检测结果事件和对应的发布者之间一一对应关系的过程可以包括：

通过hash表将每个发布者需发布的检测任务事件作为键，发布者作为值形成映射关系，并以映射关系作为每个检测任务事件和发布者之间的一一对应关系。

发布者本身需要维护一个自己发布什么检测结果事件的标识，依托于spring容器，可以把所有的发布者都交给spring管理。在spring容器启动的时候，统一通知中心可以通过spring容器找到所有的发布者，并将发布者与发布者本身发布的检测结果事件一一关联起来(通过一个hash表将检测结果事件作为键，发布者作为值)，检测结果事和发布者之间的映射关系以此生成，该映射关系即可作为。

当然，在实际应用中，也并不排除采用其他方式将检测结果事件和发布者进行一一关联的实施例，只要基于检测结果事件可以查询到对应的发布这即可，对此，本申请中不再一一列举。

另外，如前所述，随着业务的运行，待检测端口元数据不可避免的会出现变更的情况，由此当待检测端口元数据出现变更情况，就需要对其检测任务进行更新，显然相应地，也需要对其检测结果事件、检测结果事件和对应发布者之间的对应关系等都进行相应的更新，而订阅该检测结果事件的订阅者列表可以按照上述相同的方式重新进行订阅注册，对此本申请中不再详细赘述。

综上所述，本申请中在对各个协议端口进行健康检测时，对每个协议端口对应的检测任务分别设定了各自的检测周期和检测起始时间，使得各个检测任务能够每间隔设定的检测周期即可自动执行，进而保证各个协议端口之间检测任务执行的独立性和有序性，能够有效避免部分协议端口长时间未被检测甚至被遗漏而未检测的问题，保证了对协议端口判活的及时性和有效性，有利于各种业务处理任务的顺利进行。

下面对本发明实施例提供的协议端口的健康检测装置进行介绍，下文描述的协议端口的健康检测装置与上文描述的协议端口的健康检测方法可相互对应参照。

图2为本发明实施例提供的协议端口的健康检测装置的结构框图，参照图2的协议端口的健康检测装置可以包括：

形成任务模块100，用于预先根据每个待检测端口元数据形成对应的检测任务，并设定各个所述检测任务对应的检测周期以及检测起始时间；

执行任务模块200，用于对每个所述待检测端口元数据，按照对应的所述检测起始时间每间隔对应的所述检测周期，执行一次对应的所述检测任务，获得检测结果。

在本申请的一种可选地实施例中，执行任务模块200具体用于执行各个所述检测任务中当前时刻为检测时间的当前检测任务，获得所述检测结果；按照所述当前检测任务对应的检测周期设定所述当前检测任务下一次被执行时距离当前时刻的延时时长；其中，所述检测周期的时长等于所述延时时长。

在本申请的一种可选地实施例中，形成任务模块100具体用于对各个所述检测任务设定不同的检测周期和不同的检测起始时间，以使同一时刻执行的检测任务的数量不超过预设数量。

在本申请的一种可选地实施例中，执行任务模块200具体用于向所述检测任务对应的端口地址发起访问；若请求超时未响应或请求响应结果的状态码为非正常状态码，则所述检测任务对应的端口为不健康。

在本申请的一种可选地实施例中，执行任务模块200具体用于当接收到元数据变更请求时，对所述元数据变更请求对应的待检测端口元数据进行变更；对变更后的待检测端口元数据形成新的检测任务，并设定变更后的检测任务的检测周期和检测起始时间。

在本申请的一种可选地实施例中，还包括结果发布模块，用于在获得检测结果之后，通过发布者按照预先注册形成的订阅者列表，将所述检测结果作为检测结果事件发布到预先订阅者列表中的各个订阅者；

订阅者注册模块，用于获得所述订阅者根据需要订阅的检测结果事件进行订阅注册的注册信息；根据所述注册信息中的检测结果事件，结合预先确定的每个所述检测结果事件和对应的发布者之间一一对应关系，查找所述订阅者对应的发布者；将所述订阅者的注册信息发送至对应的所述发布者，以便所述发布者将对应的所述订阅者加入所述发布者的订阅者列表。

在本申请的一种可选地实施例中，订阅者注册模块用于通过hash表将每个所述发布者需发布的检测任务事件作为键，所述发布者作为值形成映射关系，并以所述映射关系作为每个所述检测任务事件和发布者之间的一一对应关系。

在本申请的一种可选地实施例中，订阅者注册模块用于当存在待检测端口元数据发生变更，并基于变更后的待检测端口元数据形成新的检测任务之后，根据所述新的检测任务的检测结果事件和对应的发布者，对所述对应关系进行更新；根据更新后的所述对应关系，对订阅所述新的检测任务的检测结果事件的订阅者重新进行订阅注册。

本实施例的协议端口的健康检测装置用于实现前述的协议端口的健康检测方法，因此协议端口的健康检测装置中的具体实施方式可见前文中的协议端口的健康检测方法的实施例部分，在此不再赘述。

本申请中还提供了一种协议端口的健康检测设备的实施例，该设备可以包括：

存储器，用于存储计算机程序；

本实施例中处理器执行的协议端口的健康检测方法的步骤可以包括：

预先根据每个待检测端口元数据形成对应的检测任务，并设定各个检测任务对应的检测周期以及检测起始时间；

对每个待检测端口元数据，按照对应的检测起始时间每间隔对应的检测周期，执行一次对应的检测任务，获得检测结果。

本申请还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行以实现如上任一项所述的协议端口的健康检测方法的步骤。

该计算机可读存储介质可以包括随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。另外，本申请实施例提供的上述技术方案中与现有技术中对应技术方案实现原理一致的部分并未详细说明，以免过多赘述。

本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

Claims

1.一种协议端口的健康检测方法，其特征在于，包括：

2.如权利要求1所述的协议端口的健康检测方法，其特征在于，对每个所述待检测端口元数据，按照对应的所述检测起始时间每间隔对应的所述检测周期，执行一次对应的所述检测任务，获得检测结果，包括：

3.如权利要求1所述的协议端口的健康检测方法，其特征在于，设定各个所述检测任务对应的检测周期以及检测起始时间，包括：

4.如权利要求1所述的协议端口的健康检测方法，其特征在于，执行所述检测任务的过程包括：

向所述检测任务对应的端口地址发起访问；

若请求超时或未响应或请求响应结果的状态码为非正常状态码，则所述检测任务对应的端口为不健康。

5.如权利要求1所述的协议端口的健康检测方法，其特征在于，当接收到元数据变更请求时，对所述元数据变更请求对应的待检测端口元数据进行变更；

6.如权利要求1至5任一项所述的协议端口的健康检测方法，其特征在于，在获得检测结果之后，还包括：

其中，预先注册形成所述订阅者列表的过程包括：

7.如权利要求6所述的协议端口的健康检测方法，其特征在于，形成所述对应关系的过程包括：

8.如权利要求6所述的协议端口的健康检测方法，其特征在于，当存在待检测端口元数据发生变更，并基于变更后的待检测端口元数据形成新的检测任务之后，还包括：

9.一种协议端口的健康检测装置，其特征在于，包括：

10.一种协议端口的健康检测设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序，以实现如权利要求1至8任一项所述的协议端口的健康检测方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行以实现如权利要求1至8任一项所述的协议端口的健康检测方法的步骤。