基于微服务单元架构的服务单元下线方法及相关装置

技术领域

本发明实施例涉及计算机领域，尤其涉及一种基于微服务单元架构的服务单元下线方法及相关装置。

背景技术

在微服务单元的分布式架构中，对微服务单元的上线、下线等管理非常重要。

在Kubernetes的原生场景下，虽然系统的最小对象是Pod（微服务单元组），但是Pod的创建与销毁（或称上线与下线）均由Kubernetes系统自行判断的，操作者并无法直接针对每个Pod进行上线与下线的操作，而是利用Eureka等注册中心进行间接管理。

在现有技术中，利用Eureka等注册中心对Pod进行间接管理时，会发生处于待终止（Terminating）状态的Pod被直接从注册中心的注册列表（EndPoint等）剔除，从而造成请求就无法访问到具体的Pod，最终会导致请求断流。

所以，如何防止在服务单元下线时访问服务单元的请求产生断流，就成为本领域技术人员急需解决的技术问题。

发明内容

本发明实施例解决的技术问题是如何防止在服务单元下线时访问服务单元的请求产生断流。

为解决上述问题，本发明实施例提供了一种基于微服务单元架构的服务单元下线方法，包括：

获取服务单元下线指令，所述服务单元下线指令包括待下线服务单元的名称；

当根据所述待下线服务单元的名称确定所述待下线服务单元处于运行状态时，注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元的名称，其中，所述注册服务单元列表中包括可正常运行的各服务单元的名称；

当所述待下线服务单元的下线等待时长满足所述待下线服务单元的等待时长阈值时，下线所述待下线服务单元，其中，所述下线等待时长为从所述注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元的名称的步骤完成后，至进行下线所述待下线服务单元步骤前的时长，所述等待时长阈值大于或等于所述注册服务单元列表的获取间隔时长。

本发明实施例还提供了一种基于微服务单元架构的服务单元下线装置，包括：

服务单元下线指令获取单元，适于获取服务单元下线指令，所述服务单元下线指令包括待下线服务单元的名称；

服务单元注销单元，适于当确定所述待下线服务单元处于运行状态时，注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元，其中，所述注册服务单元列表中包括目前能够在线的服务单元的名称；

服务单元下线单元，适于当所述待下线服务单元的下线等待时长满足所述待下线服务单元的等待时长阈值时，下线所述待下线服务单元，其中，所述等待时长阈值大于或等于所述注册服务单元列表的获取间隔时长。

本发明实施例还提供了一种存储介质，所述存储介质存储有适于下线服务单元的程序，以实现所述基于微服务单元架构的服务单元下线方法。

本发明实施例还提供了一种电子设备，包括至少一个存储器和至少一个处理器；所述存储器存储有程序，所述处理器调用所述程序，以执行所述基于微服务单元架构的服务单元下线方法。

与现有技术相比，本发明实施例的技术方案具有如下优点：

本发明实施例所提供的基于微服务单元架构的服务单元下线方法，首先获取包括待下线服务单元的名称的服务单元下线指令；然后根据所述待下线服务单元的名称确定所述待下线服务单元是否处于运行状态，当根据所述待下线服务单元的名称确定所述待下线服务单元处于运行状态时，注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元的名称，并同时开始计时以获取下线等待时长；当所述待下线服务单元的下线等待时长满足所述待下线服务单元的等待时长阈值时，下线所述待下线服务单元。

在本发明实施例所提供的基于微服务单元架构的服务单元下线方法中，在下线所述待下线服务单元时，先在所述注册服务单元列表中注销所述待下线服务单元的名称，此时注册中心处的所述注册服务单元列表已经不存在所述待下线服务单元的名称，但此时所述服务单元列表仍然可以处理完成目前接受的请求；由于所述注册网关是间隔获取所述注册服务单元列表，在等待一段时间之后，所述注册网关在此获取新的所述注册服务单元列表时，所述注册服务单元网关处的注册服务单元列表已经不再存在所述待下线服务单元的名称，后续的服务单元请求无法访问至所述待下线服务单元，而是会访问至其他可用服务单元；在保证所述注册网关再次获取新的所述注册服务单元列表后，才下线所述待下线服务单元，从而可以保证所述待下线服务单元实现优雅下线，避免请求断流问题，即避免注册服务单元列表中还存在已下线服务单元的名称，但请求无法请求到对应的服务单元的问题。

附图说明

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

图1为本发明实施例所提供的基于微服务单元架构的服务单元下线方法的流程示意图；

图2为本发明实施例所提供的基于微服务单元架构的服务单元下线方法的又一流程示意图；

图3为本发明实施例所提供的基于微服务单元架构的服务单元下线装置的示意图；

图4为本发明实施例所提供的电子设备的示意图。

具体实施方式

由背景技术可知，现有技术中的服务单元下线方法容易导致在服务单元下线时访问服务单元的请求断流。

为解决上述问题，本发明实施例所提供的基于微服务单元架构的服务单元下线方法，首先获取包括待下线服务单元的名称的服务单元下线指令；然后根据所述待下线服务单元的名称确定所述待下线服务单元是否处于运行状态，当根据所述待下线服务单元的名称确定所述待下线服务单元处于运行状态时，注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元的名称，并同时开始计时以获取下线等待时长；当所述待下线服务单元的下线等待时长满足所述待下线服务单元的等待时长阈值时，下线所述待下线服务单元。在本发明实施例所提供的基于微服务单元架构的服务单元下线方法中，在下线所述待下线服务单元时，先在所述注册服务单元列表中注销所述待下线服务单元的名称，此时注册中心处的所述注册服务单元列表已经不存在所述待下线服务单元的名称，但此时所述服务单元列表仍然可以处理完成目前接受的请求；由于所述注册网关是间隔获取所述注册服务单元列表，在等待一段时间之后，所述注册网关在此获取新的所述注册服务单元列表时，所述注册服务单元网关处的注册服务单元列表已经不再存在所述待下线服务单元的名称，后续的服务单元请求无法访问至所述待下线服务单元，而是会访问至其他可用服务单元；在保证所述注册网关再次获取新的所述注册服务单元列表后，才下线所述待下线服务单元，从而可以保证所述待下线服务单元实现优雅下线，避免请求断流问题，即避免注册服务单元列表中还存在已下线服务单元的名称，但请求无法请求到对应的服务单元的问题。

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

请参考图1，图1为本发明实施例所提供的基于微服务单元架构的服务单元下线方法的流程示意图。

本发明实施例所提供的基于微服务单元架构的服务单元下线方法，包括：

步骤S11:获取服务单元下线指令。

其中，所述服务单元下线指令可以包括待下线服务单元的名称，这样后续可以根据所述待下线服务单元的名称寻找进而下线所述待下线服务单元。

服务单元（Pod）中可能包含一个服务，也可能包含多个服务。

在一种具体实施方式中，服务单元下线指令可以根据预定的时间间隔获取，比如：在达到预定下线时间时，获取服务单元下线指令。当然，也可以通过其他的方式获取服务单元下线指令，比如受某个指令的触发。

具体地，可以通过微服务单元架构中的缩容控制单元（CronhpaControl，属于服务单元的一种）获取所述服务单元下线指令。

例如，当到达缩容时间后，所述缩容控制单元获取保存在所述缩容控制单元中的待下线服务单元的名称，实现对于服务单元下线指令的获取。

所述待下线服务单元的名称的结构中可以根据需要设置，在一种具体实施方式中，所述待下线服务单元的名称可以由指令名称（hostname）:注册标识（instanceName）组成的标识表示。

步骤S12:确定所述待下线服务单元是否处于运行状态，如果是，进行步骤S13；如果否，进行步骤S14。

得到待下线服务单元后，进一步确定所述待下线服务单元是否处于运行状态，以确定是否需要进行后续的下线处理，当所述待下线服务单元处于运行状态时，才能进行后续下线操作，当所述待下线服务单元的名称对应的服务单元已经处于下线过程，或者已经下线时，证明所述服务单元下线指令中的所述待下线服务单元的名称可能有误，需要进行更正或取消下线指令。

具体地，通过缩容控制单元，根据所述待下线服务单元的名称访问服务控制单元（Control，属于服务单元的一种），所述服务控制单元根据所述待下线服务单元的名称，确定待下线服务单元是否处于运行状态。

步骤S13：注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元。

其中，所述注册服务单元列表存在于注册中心（Eureka）中，包括可正常运行的服务单元的名称。

在所述待下线服务单元注销前，所述待下线服务单元会存在于所述注册服务单元列表中；在所述待下线服务单元注销后，所述待下线服务单元会被从所述注册服务单元列表中去除，但是注销后，仍然可以保持在线一段时间，以便于处理完成所有请求，防止目前执行的请求断流。

例如，可以由所述缩容控制单元通知所述注册中心，以注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元的名称。

其中，为了提高所述服务单元下线方法的简便程度，可以利用脚本实现所述服务单元下线方法，在一种具体实施方式中，所述步骤S13：注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元可以包括：

首先：生成所述待下线服务单元的服务单元下线脚本。

其中，所述服务单元下线脚本包括所述待下线服务单元的所述等待时长阈值和所述待下线服务单元的注销指令。

例如，可以由所述服务控制单元确定所述待下线服务单元处于运行状态后，生成所述待下线服务单元的服务单元下线脚本，发回所述缩容控制单元。

然后：执行所述服务单元下线脚本，从而注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元。

利用所述服务单元下线脚本，可以将下线操作统一化，便于所述服务单元下线方法的执行。

例如，可以由所述缩容控制单元执行所述服务单元下线脚本，通知所述注册中心，以注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元的名称，进而完成所述待下线服务的下线。

步骤S14：返回所述待下线服务单元不处于运行状态的信息。

当所述待下线服务单元不处于运行状态时，可以返回所述待下线服务单元不处于运行状态的信息，从而可以进行待下线服务单元的名称的核对或纠错等等后续处理。

例如，可以由所述服务控制单元根据所述待下线服务单元的名称，确定待下线服务单元是否处于运行状态。

步骤S15：判断等待时长是否满足所述待下线服务单元的等待时长阈值，如果是，进行步骤S17；如果否，进行步骤S16。

其中，所述等待时长阈值大于或等于所述注册服务单元列表的获取间隔时长，所述注册服务单元列表的获取间隔时长为注册网关相邻两次从注册中心获取所述注册服务单元列表的时刻间隔的最大时长，即在所述获取间隔时长内，所述注册网关至少从所述注册中心获取一次当前所述注册服务单元列表，由于当前的所述注册服务单元列表中的待下线服务单元已经被注销，所以在所述注册网关至少从所述注册中获取一次当前所述注册服务单元列表后，后续的请求不会再传递至所述待下线服务单元，所述待下线服务单元也可以处理完成目前请求之后，后续准备下线。

具体地，可以根据固定时间间隔，进行一次等待时长是否满足所述待下线服务单元的等待时长阈值的判断，等待的时间可以根据需要选择，例如1ms、0.1ms等等；也可以通过计时器进行计时，当从所述注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元的名称开始计时，达到等待时长阈值时，触发执行步骤S17。

本实施例中以固定时间间隔的方式进行说明。

步骤S16:等待，然后重新执行所述步骤S15。

其中，等待的时间可以根据需要选择，例如1ms、0.1ms等等。步骤S17：下线所述待下线服务单元。

当等待时长满足所述待下线服务单元的等待时长阈值后，即可下线所述待下线服务单元，具体的，可以通过修改服务单元部署单元（Deployment）对应的服务单元副本数的数量，完成所述待下线服务单元的下线。

可以看出，本发明实施例所提供的基于微服务单元架构的服务单元下线方法，在保证所述注册网关再次获取新的所述注册服务单元列表后，才线所述待下线服务单元，从而可以保证所述待下线服务单元实现优雅下线，避免请求断流问题，即避免注册服务单元列表中还存在已下线服务单元的名称，但请求无法请求到对应的服务单元的问题。

当然，下线所述待下线服务单元后，还可以从服务单元在线列表中删除所述待下线服务单元。

所以，请继续参考图1，在一种具体实施方式中，所述服务单元下线方法还可以包括：

步骤S18:确定所述待下线服务单元是否处于下线状态，如果是，执行步骤S110；如果否，进行步骤S19。

步骤S19:等待，然后执行所述步骤S18。

其中，等待的时间可以根据需要选择，例如1ms、0.1ms等等。

步骤S110: 注销所述微服务单元架构的服务单元在线列表中的所述待下线服务单元。

其中，所述服务单元在线列表所包括目前在线的服务单元的名称。在所述待下线服务单元注销后，所述待下线服务单元仍然可以保持在线一段时间，从而保持于所述待下线列表中，直至处理完成所有请求后才下线，从而可以防止请求断流，当所述待下线服务单元下线后，才可以从所述服务单元在线列表中去除。

在本发明实施例所提供的基于微服务单元架构的服务单元下线方法中，在下线所述待下线服务单元时，先在所述注册服务单元列表中注销所述待下线服务单元的名称，此时注册中心处的所述注册服务单元列表已经不存在所述待下线服务单元的名称，但此时所述服务单元列表仍然可以处理完成目前接受的请求；由于所述注册网关是间隔获取所述注册服务单元列表，在等待一段时间之后，所述注册网关在此获取新的所述注册服务单元列表时，所述注册服务单元网关处的注册服务单元列表已经不再存在所述待下线服务单元的名称，后续的服务单元请求无法访问至所述待下线服务单元，而是会访问至其他可用服务单元；在保证所述注册网关再次获取新的所述注册服务单元列表后，才下线所述待下线服务单元，从而可以保证所述待下线服务单元实现优雅下线，避免请求断流问题，即避免注册服务单元列表中还存在已下线服务单元的名称，但请求无法请求到对应的服务单元的问题。

当然，由于每一个所述待下线服务下线所需要的下线处理都不同，为了对应各个待下线服务进行下线，请参考图2，图2为本发明实施例所提供的基于微服务单元架构的服务单元下线方法的又一流程示意图，在一种具体实施方式中，所述服务单元下线方法包括：

步骤S21：获取服务单元下线指令，所述服务单元下线指令包括所述待下线服务单元的指令名称。

其中，如上所示，所述待下线服务单元的名称可以由指令名称（hostname）:注册标识（instanceName）组成标识表示，所述待下线服务单元的指令名称为所述待下线服务单元的自身名称，与注册中心的注册服务单元列表中的注册标识不同。

步骤S22:根据所述指令名称从所述注册服务单元列表中获取所述待下线服务单元的注册标识。

注册中心为了便于管理各种服务单元，通常会在注册中心中为所有服务单元标记一个注册标识，所述注册标识一般为统一命名，与所述指令名称不同。

步骤S23:确定所述待下线服务单元是否处于运行状态，如果是，进行步骤S24；如果否，进行步骤S26。

所述步骤S23与所述步骤S12相同，在此不再赘述。

步骤S24：根据所述注册标识生成所述待下线服务单元的服务单元下线脚本。

所述服务单元下线脚本包括所述待下线服务单元的注册标注，及下线指令、断等待时长等信息。

由于所述服务单元下线脚本中包含所述注册标识，因此后续可以根据所述注册标识从所述微服务单元架构的注册服务单元列表中注销所述待下线服务单元。

步骤S25：执行所述服务单元下线脚本，从而注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元。

执行所述服务单元下线脚本，所述服务单元下线脚本中包含所述注册标识，根据所述注册标识下线所述待下线服务单元更加便捷。

例如，可以由所述缩容控制单元通知所述注册中心，以注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元的名称。

步骤S26：返回所述待下线服务单元不处于运行状态的信息。

如果确定所述待下线服务单元不处于运行状态，那么执行步骤S26，所述步骤S26与所述步骤S14相同，在此不再赘述。

步骤S27：判断等待时长是否满足所述待下线服务单元的等待时长阈值。如果是，进行步骤S29，如果否，进行步骤S28。

所述步骤S27与所述步骤S15相同，在此不再赘述。

步骤S28:等待，然后重新执行所述步骤S27。

其中，等待的时间可以根据需要选择，例如1ms、0.1ms等等。

所述步骤S28与所述步骤S16相同，在此不再赘述。

步骤S29：下线所述待下线服务单元。

当等待时长是否满足所述待下线服务单元的等待时长阈值后，即可下线所述待下线服务单元。

由于每一个所述待下线服务单元下线所需要的下线处理都不同，根据所述待下线服务单元的注册标识对应各个待下线服务进行下线处理更加便捷。

下面对本发明实施例提供的基于微服务单元架构的服务单元下线装置进行介绍，下文描述的基于微服务单元架构的服务单元下线装置可以认为是，电子设备（如：PC）为分别实现本发明实施例提供的基于微服务单元架构的服务单元下线方法所需设置的功能模块架构。下文描述的基于微服务单元架构的服务单元下线装置的内容，可分别与上文描述的基于微服务单元架构的服务单元下线方法的内容相互对应参照。

请参考图3，图3为本发明实施例所提供的基于微服务单元架构的服务单元下线装置的示意图。

本发明实施例提供了一种基于微服务单元架构的服务单元下线装置，包括：

服务单元下线指令获取单元11，适于获取服务单元下线指令，所述服务单元下线指令包括待下线服务单元的名称；

其中，所述服务单元下线指令获取单元11的具体指令可以由所述缩容控制单元实现。

服务单元注销单元13，适于当确定所述待下线服务单元处于运行状态时，注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元，其中，所述注册服务单元列表中包括目前能够在线的服务单元的名称；

其中，所述服务单元注销单元13的具体指令可以由所述缩容控制单元、所述服务控制单元和所述注册中心实现。

服务单元下线单元14，适于当所述待下线服务单元的下线等待时长满足所述待下线服务单元的等待时长阈值时，下线所述待下线服务单元，其中，所述等待时长阈值大于或等于所述注册服务单元列表的获取间隔时长。

其中，所述服务单元下线单元14的具体指令可以由所述缩容控制单元和所述服务单元部署单元实现。

在本发明实施例所提供的基于微服务单元架构的服务单元下线装置中，在下线所述待下线服务单元时，先在所述注册服务单元列表中注销所述待下线服务单元的名称，此时注册中心处的所述注册服务单元列表已经不存在所述待下线服务单元的名称，但此时所述服务单元列表仍然可以处理完成目前接受的请求；由于所述注册网关是间隔获取所述注册服务单元列表，在等待一段时间之后，所述注册网关在此获取新的所述注册服务单元列表时，所述注册服务单元网关处的注册服务单元列表已经不再存在所述待下线服务单元的名称，后续的服务单元请求无法访问至所述待下线服务单元，而是会访问至其他可用服务单元；在保证所述注册网关再次获取新的所述注册服务单元列表后，才下线所述待下线服务单元，从而可以保证所述待下线服务单元实现优雅下线，避免请求断流问题，即避免注册服务单元列表中还存在已下线服务单元的名称，但请求无法请求到对应的服务单元的问题。

可选的，所述服务单元注销单元13包括：

服务单元下线脚本生成单元131，适于当确定所述待下线服务单元处于运行状态时，生成所述待下线服务单元的服务单元下线脚本，所述服务单元下线脚本包括所述待下线服务单元的所述等待时长阈值和所述待下线服务单元的注销指令；

其中，所述服务单元下线脚本生成单元131的具体指令可以由所述服务控制单元实现。

服务单元注销执行单元132，适于执行所述服务单元下线脚本，从而注销所述微服务单元架构的注册服务单元列表中的所述待下线服务单元。

其中，所述服务单元注销执行单元132的具体指令可以由所述缩容控制单元实现。

利用所述服务单元下线脚本，可以将下线操作统一化，便于所述服务单元下线方法的执行。

可选的，还包括：

注册标识获取单元12，适于根据所述指令名称从所述注册服务单元列表中获取所述待下线服务单元的注册标识；

其中，所述注册标识获取单元12的具体指令可以由所述缩容控制单元实现。

所述服务单元下线脚本生成单元131，还适于当根据所述注册标识确定所述待下线服务单元处于运行状态时，根据所述注册标识生成所述待下线服务单元的服务单元下线脚本；

所述服务单元注销执行单元132，还根据所述注销指令删除所述微服务单元架构的注册服务单元列表中的所述待下线服务单元的注册标识。

可选的，还包括：

服务单元在线列表注销单元15，适于确定所述待下线服务单元处于下线状态时，注销所述微服务单元架构的服务单元在线列表中的所述待下线服务单元，其中，所述服务单元在线列表包括目前在线的服务单元的名称。

由于每一个所述待下线服务单元下线所需要的下线处理都不同，根据所述待下线服务单元的注册标识对应各个待下线服务进行下线处理更加便捷。

当然，本发明实施例还提供一种电子设备，本发明实施例提供的电子设备可以通过程序形式装载程序模块架构，以实现本发明实施例提供的基于微服务单元架构的服务单元下线方法；该硬件设备可以应用于具体数据处理能力的电子设备，该电子设备可以为：例如终端设备或者服务单元器设备。

所以，请参照图4，图4为本发明实施例所提供的电子设备的示意图。

本发明实施例所提供的设备包括：至少一个存储器21和至少一个处理器22，所述存储器21存储一条或多条计算机可执行指令，所述处理器22调用所述一条或多条计算机可执行指令，以执行所述信基于微服务单元架构的服务单元下线方法。

可以理解的是，所述设备还可以包括至少一个通信接口23和至少一个通信总线24；处理器22和存储器21可以位于同一电子设备，例如处理器22和存储器21可以位于服务单元器设备或者终端设备；处理器22和存储器21也可以位于不同的电子设备。

在本发明实施例中，处理器22、通信接口23、存储器21、通信总线24的数量为至少一个，且处理器22、通信接口23、存储器21通过通信总线24完成相互间的通信；显然，图4所示的处理器22、通信接口23、存储器21和通信总线24的通信连接示意仅是可选的一种方式。

可选的，通信接口23可以为通信模块的接口，如GSM模块的接口；处理器22可能是中央处理器CPU，或者是特定集成电路ASIC，或者是被配置成实施本发明实施例的一个或多个集成电路；存储器21可以包含高速RAM存储器，也可以包括非易失性存储器，例如至少一个磁盘存储器。

需要说明的是，上述的设备还可以包括与本发明实施例公开内容可能并不是必需的其他器件（未示出）；鉴于这些其他器件对于理解本发明实施例公开内容可能并不是必需，本发明实施例对此不进行逐一介绍。

本发明实施例还提供了一种存储介质，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令用于执行所述基于微服务单元架构的服务单元下线方法。

上述本发明的实施方式是本发明的元件和特征的组合。除非另外提及，否则所述元件或特征可被视为选择性的。各个元件或特征可在不与其它元件或特征组合的情况下实践。另外，本发明的实施方式可通过组合部分元件和/或特征来构造。本发明的实施方式中所描述的操作顺序可重新排列。任一实施方式的一些构造可被包括在另一实施方式中，并且可用另一实施方式的对应构造代替。对于本领域技术人员而言明显的是，所附权利要求中彼此没有明确引用关系的权利要求可组合成本发明的实施方式，或者可在提交本申请之后的修改中作为新的权利要求包括。

本发明的实施方式可通过例如硬件、固件、软件或其组合的各种手段来实现。在硬件配置方式中，根据本发明示例性实施方式的方法可通过一个或更多个专用集成电路(ASIC)、数字信号处理器DSP)、数字信号处理器件(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器等来实现。

在固件或软件配置方式中，本发明的实施方式可以模块、过程、功能等形式实现。软件代码可存储在存储器单元中并由处理器执行。存储器单元位于处理器的内部或外部，并可经由各种己知手段向处理器发送数据以及从处理器接收数据。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其他实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是符合与本文所公开的原理和新颖特点相一致的最宽的范围。

虽然本发明实施例披露如上，但本发明实施例并非限定于此。任何本领域技术人员，在不脱离本发明实施例的精神和范围内，均可作各种更动与修改，因此本发明实施例的保护范围应当以权利要求所限定的范围为准。