一种微服务的故障恢复方法、装置、电子设备及介质与流程

1.本技术涉及微服务技术领域，特别是涉及一种微服务的故障恢复方法、装置、电子设备及介质。


背景技术：

2.在微服务架构中，为了满足微服务之间的接口调用和客户端对微服务的请求，微服务可以被云化部署，每个微服务有至少两个实例对外提供服务。
3.在相关技术中，如图1所示，微服务架构中包括zuul网关、注册中心和每个微服务对应的多个实例。每个微服务启动成功后，自动向注册中心登记，使得注册中心存储每个微服务的服务标识对应的实例列表，同一微服务的多个实例具有唯一的服务标识。zuul网关接收到对微服务的访问请求后，根据访问请求所请求访问的统一资源定位符(uniform resource locator，url)确定服务标识，然后向注册中心提供该服务标识，进而注册中心为网关提供该服务标识对应的实例列表，也就是访问请求所请求访问的微服务对应的实例列表，图1中示例性地示出了实例1、实例2和实例3。zuul网关可以通过预设的负载均衡策略，选择用于处理该访问请求的实例，并将该访问请求发送至选择的实例。
4.然而，由于微服务架构中云化部署的实例数量众多，而硬件平台的资源有限，所以每个实例被分配的资源有限，会导致实例的故障率较高。当某一实例故障后，zuul网关将重新通过负载均衡策略为该故障实例所处理的访问请求选择其他的实例。当故障实例过多时，对于同一个微服务的访问请求将被集中转移到同一实例处理，导致该实例超载运行，长时间的超载运行也会导致该实例出现故障，最终使得整个微服务停止服务，该微服务对应的业务中断。


技术实现要素：

5.本技术实施例的目的在于提供一种微服务的故障恢复方法、装置、电子设备及介质，以降低整个微服务停止服务的可能性。具体技术方案如下：
6.第一方面，本技术实施例提供一种微服务的故障恢复方法，包括：
7.采集微服务实例的性能参数；
8.根据对所述微服务实例的性能参数的采集结果，判断所述微服务实例是否存在故障；
9.若所述微服务实例存在故障，则将该故障作为待恢复故障，确定所述待恢复故障的故障类型；
10.基于预设的故障类型与恢复方式的对应关系，确定所述待恢复故障对应的预设恢复方式；
11.基于所述预设恢复方式对所述微服务实例进行故障恢复处理。
12.在一种可能的实现方式中，所述根据对所述微服务实例的性能参数采集结果，判断所述微服务实例是否存在故障，包括：
13.若采集到的所述微服务实例的性能参数满足预设告警条件，则生成所述微服务实例的第一类告警事件，其中，所述第一类告警事件的告警类型属于性能参数超载类型；或者，
14.若连续第一预设次数未采集到所述微服务实例的性能参数，则生成所述微服务实例的第二类告警事件，其中，所述第二类告警事件的告警类型为宕机类型；
15.对所述第一类告警事件或所述第二类告警事件进行故障分析，判断所述微服务实例是否存在故障。
16.在一种可能的实现方式中，若采集到的所述微服务实例的性能参数满足预设告警条件，则生成所述微服务实例的第一类告警事件，包括：
17.针对所述微服务实例的每项性能参数，根据预设的各告警级别与告警区间之间的对应关系，确定该性能参数所属的告警区间对应的告警级别；
18.若该性能参数对应的告警级别大于等于第一预设级别，且已连续第二预设次数确定该性能参数对应于相同的告警级别，则生成所述微服务实例的第一类告警事件。
19.在一种可能的实现方式中，对所述第一类告警事件或所述第二类告警事件进行故障分析，判断所述微服务实例是否存在故障，包括：
20.对已生成的告警事件进行监听，若监听到所述第一类告警事件，则获取所述第一类告警事件包括的告警源、告警类型和告警级别；若监听到所述第二类告警事件，则获取所述第二类告警事件包括的告警源、告警类型和告警级别，所述告警源为发生告警事件的微服务实例的标识；
21.根据所述第一类告警事件或所述第二类告警事件包括的告警源、告警类型和告警级别生成待定故障编号；
22.若从预设的故障知识库中查找到与所述待定故障编号相同的故障编号，则根据查找到的所述故障编号确定所述微服务实例存在故障。
23.在一种可能的实现方式中，所述确定所述待恢复故障的故障类型，包括：
24.将所述待恢复故障对应的告警事件的告警类型确定为所述待恢复故障的故障类型；
25.所述基于预设的故障类型与恢复方式的对应关系，确定所述待恢复故障对应的恢复方式，包括：
26.若所述待恢复故障的故障类型属于性能参数超载类型，则确定所述待恢复故障对应的恢复方式为服务熔断；
27.若所述待恢复故障的故障类型为宕机类型，则确定所述待恢复故障对应的恢复方式为重启。
28.在一种可能的实现方式中，在基于所述预设恢复方式对所述微服务实例进行故障恢复处理之后，所述方法还包括：
29.实时采集微服务实例的性能参数，并根据对所述微服务实例的性能参数的采集结果，判断所述微服务实例是否存在故障；
30.若进行故障恢复处理的时长达到预设时长，且所述微服务实例仍存在故障，则确定故障恢复处理失败，并输出第一故障提醒消息，所述第一故障提醒消息用于提醒用户对所述待恢复故障进行处理。
31.在一种可能的实现方式中，在确定所述待恢复故障的故障类型之后，基于预设的故障类型与恢复方式的对应关系，确定所述待恢复故障对应的预设恢复方式之前，所述方法还包括：
32.若所述待恢复故障的故障类型属于性能参数超载类型，则确定发生超载的性能项目对应的预设检测对象，所述预设检测对象为占用发生超载的性能项目的性能资源的对象；
33.采集所述微服务实例中所述预设检测对象对发生超载的性能项目的资源占用参数；
34.根据所述资源占用参数确定所述待恢复故障的故障原因；
35.记录所述待恢复故障的故障原因。
36.在一种可能的实现方式中，在基于预设的故障类型与恢复方式的对应关系，确定所述待恢复故障对应的预设恢复方式之前，所述方法还包括：
37.基于预设的故障类型与操作方式之间的对应关系，确定所述待恢复故障对应的预设操作方式；
38.若所述预设操作方式为手动操作，则输出第二故障提醒消息，所述第二故障提醒消息用于提醒用户根据所述故障原因进行故障恢复；
39.若所述预设操作方式为自动操作，则执行基于预设的故障类型与恢复方式的对应关系，确定所述待恢复故障对应的预设恢复方式的步骤。
40.第二方面，本技术实施例提供一种微服务的故障恢复装置，包括：
41.采集模块，用于采集微服务实例的性能参数；
42.判断模块，用于根据对所述微服务实例的性能参数的采集结果，判断所述微服务实例是否存在故障；
43.确定模块，用于若所述判断模块判断所述微服务实例存在故障，则将该故障作为待恢复故障，确定所述待恢复故障的故障类型；
44.所述确定模块，还用于基于预设的故障类型与恢复方式的对应关系，确定所述待恢复故障对应的预设恢复方式；
45.故障恢复处理模块，用于基于所述预设恢复方式对所述微服务实例进行故障恢复处理。
46.在一种可能的实现方式中，所述判断模块，包括生成子模块和判断子模块；
47.所述生成子模块，用于：
48.若采集到的所述微服务实例的性能参数满足预设告警条件，则生成所述微服务实例的第一类告警事件，其中，所述第一类告警事件的告警类型属于性能参数超载类型；或者
49.若连续第一预设次数未采集到所述微服务实例的性能参数，则生成所述微服务实例的第二类告警事件，其中，所述第二类告警事件的告警类型为宕机类型；
50.所述判断子模块，用于对所述生成子模块生成的所述第一类告警事件或所述第二类告警事件进行故障分析，判断所述微服务实例是否存在故障。
51.在一种可能的实现方式中，所述生成子模块，具体用于：
52.针对所述微服务实例的每项性能参数，根据预设的各告警级别与告警区间之间的对应关系，确定该性能参数所属的告警区间对应的告警级别；
53.若该性能参数对应的告警级别大于等于第一预设级别，且已连续第二预设次数确定该性能参数对应于相同的告警级别，则生成所述微服务实例的第一类告警事件。
54.在一种可能的实现方式中，所述判断子模块，具体用于：
55.对已生成的告警事件进行监听，若监听到所述第一类告警事件，则获取所述第一类告警事件包括的告警源、告警类型和告警级别；若监听到所述第二类告警事件，则获取所述第二类告警事件包括的告警源、告警类型和告警级别，所述告警源为发生告警事件的微服务实例的标识；
56.根据所述第一类告警事件或所述第二类告警事件包括的告警源、告警类型和告警级别生成待定故障编号；
57.若从预设的故障知识库中查找到与所述待定故障编号相同的故障编号，则根据查找到的所述故障编号确定所述微服务实例存在故障。
58.在一种可能的实现方式中，所述确定模块，具体用于将所述待恢复故障对应的告警事件的告警类型确定为所述待恢复故障的故障类型；
59.所述确定模块，具体还用于：若所述待恢复故障的故障类型属于性能参数超载类型，则确定所述待恢复故障对应的恢复方式为服务熔断；若所述待恢复故障的故障类型为宕机类型，则确定所述待恢复故障对应的恢复方式为重启。
60.在一种可能的实现方式中，所述装置还包括，第一输出模块；
61.所述采集模块，还用于实时采集微服务实例的性能参数；
62.所述判断模块，还用于根据所述采集模块对所述微服务实例的性能参数的采集结果，判断所述微服务实例是否存在故障；
63.所述确定模块，还用于若所述故障恢复处理模块进行故障恢复处理的时长达到预设时长，且所述微服务实例仍存在故障，则确定故障恢复处理失败，并触发所述第一输出模块输出第一故障提醒消息，所述第一故障提醒消息用于提醒用户对所述待恢复故障进行处理。
64.在一种可能的实现方式中，所述装置还包括：记录模块；
65.所述确定模块，还用于若所述待恢复故障的故障类型属于性能参数超载类型，则确定发生超载的性能项目对应的预设检测对象，所述预设检测对象为占用发生超载的性能项目的性能资源的对象；
66.所述采集模块，还用于采集所述微服务实例中所述预设检测对象对发生超载的性能项目的资源占用参数；
67.所述确定模块，还用于根据所述资源占用参数确定所述待恢复故障的故障原因；
68.所述记录模块，用于记录所述待恢复故障的故障原因。
69.在一种可能的实现方式中，所述装置还包括：第二输出模块；
70.所述确定模块，还用于基于预设的故障类型与操作方式之间的对应关系，确定所述待恢复故障对应的预设操作方式；
71.所述第二输出模块，用于若所述确定模块确定所述预设操作方式为手动操作，则输出第二故障提醒消息，所述第二故障提醒消息用于提醒用户根据所述故障原因进行故障恢复；
72.所述确定模块，还用于若确定所述预设操作方式为自动操作，则触发所述确定模
块基于预设的故障类型与恢复方式的对应关系，确定所述待恢复故障对应的预设恢复方式。
73.第三方面，本发明实施例还提供一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；
74.存储器，用于存放计算机程序；
75.处理器，用于执行存储器上所存放的程序时，实现上述任一所述的微服务的故障恢复方法步骤。
76.第四方面，本技术实施例还提供了一种计算机可读存储介质，该计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现第一方面中所述的微服务的故障恢复方法。
77.第五方面，本技术实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面中所述的微服务的故障恢复方法。
78.本技术实施例有益效果：
79.采用上述技术方案，可以采集微服务实例的性能参数，根据对微服务实例的性能参数的采集结果，判断微服务实例是否存在故障，从而实现了及时发现微服务实例的故障。若微服务实例存在故障，则将该故障作为待恢复故障，确定故障类型，进而可以基于预设的故障类型与恢复方式的对应关系，确定待恢复故障对应的预设恢复方式，并基于预设恢复方式对微服务实例进行故障恢复。可见，采用该方法可以及时发现微服务实例的故障，并及时对微服务实例进行故障恢复，降低了同一微服务对应的多个实例均故障的可能性，进而可以降低微服务对应的业务中断的可能性。
80.当然，实施本技术的任一产品或方法并不一定需要同时达到以上所述的所有优点。
附图说明
81.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
82.图1为背景技术提供的一种微服务架构的示意图；
83.图2为本技术实施例提供的一种微服务的故障恢复方法的流程图；
84.图3为本技术实施例提供的一种判断微服务实例是否发生故障的方法的流程图；
85.图4为本技术实施例提供的一种对微服务实例进行故障恢复处理的方法的流程图；
86.图5为本技术实施例提供的另一种微服务的故障恢复方法的流程图；
87.图6为本技术实施例提供的一种根因分析的方法的流程图；
88.图7为本技术实施例提供的监控系统的结构示意图；
89.图8为本技术实施例提供的监控系统中的告警监控模块的处理流程图；
90.图9为本技术实施例提供的监控系统中的故障分析模块的处理流程图；
91.图10为本技术实施例提供的监控系统中的故障处理模块的处理流程图；
92.图11为本技术实施例提供的监控系统中的故障评估模块的处理流程图；
93.图12为本技术实施例提供的一种微服务的故障恢复装置的结构示意图；
94.图13为本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
95.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
96.现有技术中，每个微服务实例被分配的资源有限，微服务实例的故障率较高，现有技术无法及时发现故障并进行故障恢复，容易出现“雪崩”现象，导致整个微服务停止服务。为了解决该问题，本技术实施例提供了一种微服务的故障恢复方法、装置、电子设备及介质，用以及时发现微服务的故障，并进行故障处理，以降低微服务停止服务的可能性。
97.以下通过具体实施例对本技术实施例提供的微服务的故障恢复方法、装置、电子设备及介质进行描述。
98.本技术实施例提供一种微服务的故障恢复方法，可选地，本技术实施例可以应用于一个用于对图1所示的微服务架构进行监控的监控系统，该监控系统可以部署在一个服务器上，比如与网关部署在同一服务器上，或者该监控系统采用分布式部署，该监控系统可以与网关进行通信，以实现对微服务架构的监控。如图2所示，该方法包括：
99.s201、采集微服务实例的性能参数。
100.其中，微服务实例的性能参数包括微服务实例的内存占用率、cpu占用率、线程数。微服务实例的性能参数还可以为其他用于表示微服务实例的负载情况的参数。
101.s202、根据对微服务实例的性能参数的采集结果，判断微服务实例是否存在故障。
102.s203、若微服务实例存在故障，则将该故障作为待恢复故障，确定待恢复故障的故障类型。
103.s204、基于预设的故障类型与恢复方式的对应关系，确定待恢复故障对应的预设恢复方式。
104.s205、基于预设恢复方式对微服务实例进行故障恢复处理。
105.采用本技术实施例提供的微服的故障恢复方法，可以采集微服务实例的性能参数，根据对微服务实例的性能参数的采集结果，判断微服务实例是否存在故障，从而实现了及时发现微服务实例的故障。若微服务实例存在故障，则将该故障作为待恢复故障，确定故障类型，进而可以基于预设的故障类型与恢复方式的对应关系，确定待恢复故障对应的预设恢复方式，并基于预设恢复方式对微服务实例进行故障恢复。可见，采用该方法可以及时发现微服务实例的故障，并及时对微服务实例进行故障恢复，降低了同一微服务对应的多个实例均故障的可能性，进而可以降低微服务对应的业务中断的可能性。
106.在本技术的一个实施例中，上述s202、根据对微服务实例的性能参数的采集结果，判断微服务实例是否存在故障，具体可以实现为：
107.若采集到微服务实例的性能参数，则基于采集到的性能参数是否符合预设的超载类型故障条件，判断微服务实例是否存在性能参数超载类型故障；
108.若连续第一次数未采集到微服务实例的性能参数，则确定微服务实例存在宕机类型故障。
109.在一种实施方式中，可以根据微服务实例的性能参数生成告警事件，进而根据告警事件判断微服务实例是否发生故障。基于此，上述s202、根据对微服务实例的性能参数的采集结果，判断微服务实例是否存在故障，具体可以实现为：根据采集到的微服务实例的性能参数生成微服务实例的告警事件，然后对已生成的告警事件进行故障分析，判断微服务实例是否存在故障。
110.如图3所示，上述s202中，根据对微服务实例的性能参数的采集结果，判断微服务实例是否存在故障的方法，具体包括如下步骤：
111.s301、判断是否采集到微服务实例的性能参数。
112.若是，则执行s302；若否，则执行s303。
113.s302、若采集到的微服务实例的性能参数满足预设告警条件，则生成微服务实例的第一类告警事件，其中，第一类告警事件的告警类型属于性能参数超载类型。
114.其中，生成微服务实例的第一类告警事件的方法包括：
115.针对微服务实例的每项性能参数，根据预设的各告警级别与告警区间之间的对应关系，确定该性能参数所属的告警区间对应的告警级别；若该性能参数对应的告警级别大于等于第一预设级别，且已连续第二预设次数确定该性能参数对应于相同的告警级别，则生成微服务实例的第一类告警事件，第一类告警事件的告警类型属于性能参数超载类型。
116.其中，本技术实施例中，预先设置了各性能项目的每个告警级别对应的告警区间。性能项目可以为内存、cpu等。告警级别可以包括一级、二级、三级、四级，级别越高，对应的告警事件越严重，或者告警级别也可以表示为严重、主要、次要、警告，本技术实施例不限制告警级别的表示方式。
117.同一性能项目的每个告警级别对应一个告警区间，该告警区间可以通过两个阈值限定。比如，一级对应的告警区间为[阈值1，阈值2)，二级对应的告警区间为[阈值2，阈值3)，三级对应的告警区间为[阈值3，阈值4)，阈值1、阈值2、阈值3、阈值4依次增大。
[0118]
以下结合具体的例子对生成第一类告警事件的方法进行说明，以性能参数为cpu占用率为例，针对cpu占用率，预先存储的告警级别与告警区间之间的对应关系如表1所示，假设上述第一预设级别为严重级别，第二预设次数为5次。
[0119]
表1
[0120][0121]
若采集到的微服务实例的cpu占用率为95％，通过表1可知，若cpu占用率在90％以上，则属于严重级别的告警。若确定已经连续5次采集到的该微服务实例的cpu占用率都超过90％，即连续5次的告警级别均为严重，则生成该微服务实例的第一类告警事件。
[0122]
本技术实施例中，性能参数超载类型可以包括：cpu占用率超载、内存占用率超载等。
[0123]
第一类告警事件中可以包括但不限于：告警编号、告警名称、告警类型、告警源、告
警级别、产生告警事件时的性能参数、该性能参数所属的告警区间中的至少一项或多项。其中，告警源为产生告警事件的故障实例标识。
[0124]
例如，若采集到的微服务实例a的cpu占用率为95％，则告警类型为：cpu占用率超载，产生告警时的性能参数为：cpu占用率为95％，该性能参数所属告警区间为：90％以上。
[0125]
s303、若连续第一预设次数未采集到微服务实例的性能参数，则生成微服务实例的第二类告警事件，其中，第二类告警事件的告警类型为宕机类型。
[0126]
其中，监控系统可以调用spring boot管理平台的restful接口(各微服务实例的健康度检测接口)采集微服务实例的性能参数，若未采集到微服务实例的性能参数，则说明该微服务实例可能已存在断链故障，若连续第一预设次数未采集到微服务实例的性能参数，则确定该微服务实例已宕机，进而生成第二类告警事件。
[0127]
其中，第二类告警事件中可以包括但不限于：告警编号、告警名称、告警类型、告警源、告警级别中的至少一项或多项。因微服务实例宕机代表着该微服务实例无法工作，所以第二类告警事件中包括的告警级别较高，例如可以为严重级别。
[0128]
s304、对已生成的告警事件进行监听，若监听到第一类告警事件，则获取第一类告警事件包括的告警源、告警类型和告警类别；若监听到第二类告警事件，则获取第二类告警事件包括的告警源、告警类型和告警级别。
[0129]
其中，告警源为发生告警事件的微服务实例的标识。
[0130]
s305、根据第一类告警事件或第二类告警事件包括的告警源、告警类型和告警级别生成待定故障编号。
[0131]
在一种实施方式中，待定故障编号＝预留位+告警源+告警类型+告警级别。
[0132]
其中，若监听到第一类告警事件，则根据第第一类告警事件包括的告警源、告警类型和告警级别生成待定故障编号；若监听到第二类告警事件，则根据第二类告警事件包括的告警源、告警类型和告警级别生成待定故障编号。
[0133]
s306、若从预设的故障知识库中查找到与待定故障编号相同的故障编号，则根据查找到的故障编号确定微服务实例存在故障。
[0134]
预设的故障知识库中预先存储有故障编号，该故障编号根据预先定义的告警源、告警类型和告警级别生成。可选的，故障编号的组成部分还包括预留位。预设的故障知识库中的故障编号与s305中的待定故障编号采用相同的方式生成。
[0135]
若根据第一类告警事件或第二类告警事件包括的告警源、告警类型和告警级别生成的待定故障编号存在于预设的故障知识库中，则说明该告警事件已被预先定义为故障，所以确定微服务实例存在故障。
[0136]
在一种实施方式中，若已生成的告警事件为第一类告警事件，不仅需从预设的故障知识库中查找是否存在上述待定故障编号，还需判断该微服务实例是否满足以下两个条件，若满足，则确定该微服务实例存在故障。
[0137]
条件1：该微服务实例连续产生第一类告警事件的次超过第三预设次数；
[0138]
条件2：条件1中连续产生的第一类告警事件的告警级别均大于等于第二预设级别。比如，该第二预设级别为严重级别。
[0139]
采用该方法，由于在预设的故障知识库中存储了故障编号，若基于已生成的告警事件生成的待定故障编号存在于预设的故障知识库中，则可以确定微服务实例存在故障，
相比于现有技术，采用本技术实施例提供的方法有机会提前发现故障，从而可以及时进行故障恢复处理，降低微服务实例彻底故障的可能性。
[0140]
在本技术的一个实施例中，在上述判断微服务实例是否存在故障的过程中，若预设的故障知识库中未保存与待定故障编号相同的故障编号，则生成并记录用于描述故障编号缺失的系统事件，该系统事件可供运维人员查看，以便于运维人员根据该系统事件对预设的故障知识库进行完善。
[0141]
在上述实施例的基础上，如图4所示，对微服务实例进行故障恢复处理的方法可包括以下步骤s401至s405。
[0142]
在确定微服务实例存在故障后，在上述s203中，确定待恢复故障的故障类型，可以实现为s401。
[0143]
s401、将待恢复故障对应的告警事件的告警类型确定为待恢复故障的故障类型。
[0144]
例如，若待恢复故障对应于第一类告警事件，则确定待恢复故障的故障类型为性能参数超载类型故障；若待恢复故障对应于第二类告警事件，则确定待恢复故障的故障类型为宕机类型故障。
[0145]
在确定待恢复故障的故障类型的基础上，上述s204、基于预设的故障类型与恢复方式的对应关系，确定待恢复故障对应的预设恢复方式，可以实现为：判断预设的故障类型与恢复方式的对应关系中，是否存在待恢复故障对应的预设恢复方式，若存在，则将该预设恢复方式确定为待恢复故障对应的恢复方式，即执行s402和s404；若不存在，则生成并记录用于描述恢复方式缺失的系统事件。
[0146]
s402、若待恢复故障的故障类型属于性能参数超载类型，则确定待恢复故障对应的恢复方式为服务熔断。
[0147]
其中，服务熔断是指暂时停止对该微服务实例的调用
[0148]
s403、暂停为该微服务实例分配访问请求。
[0149]
本步骤可通过调整负载均衡比例的方式实现，比如将该微服务实例的负载均衡比例调为0，那么在zuul网关接收到新的访问请求时，则不会将该新的访问请求分配给该微服务实例处理。
[0150]
s404、若待恢复故障的故障类型为宕机类型，则确定待恢复故障对应的恢复方式为重启。
[0151]
s405、对该微服务实例进行热重启。
[0152]
采用该方法，若微服务实例的故障类型属于性能参数超载类型，则暂停为该微服务实例分配访问请求，可以避免该微服务实例的负载进一步增加，使得该微服务处理可以处理已被分配的访问请求，已被分配的访问请求处理完毕后，该微服务实例的负载将会降低。采用服务熔断的方式，实现了在微服务彻底故障之前，自动对微服务进行故障恢复处理，使得微服务实例有机会自愈，降低了该微服务实例所属的微服务停止服务的可能性。另外，若待恢复故障的故障类型为宕机类型，则可对微服务实例进行热重启，以使得微服务实例恢复连接。
[0153]
在本技术另一实施例中，在图2的基础上，在对微服务实例进行故障恢复处理之后，还可通过故障评估流程判断故障恢复处理的恢复结果，如图5所示，在上述s205之后，该方法还包括s206至s207。
[0154]
s206、实时采集微服务实例的性能参数，并根据对微服务实例的性能参数的采集结果，判断微服务实例是否存在故障。
[0155]
其中，本步骤中判断微服务实例是否存在故障的方法与上述实施例描述的判断微服务实例是否存在故障的方法相同，此处不再赘述。
[0156]
若经判断发现微服务实例已不存在故障，则说明对微服务进行故障恢复处理成功。反之，则执行s207。
[0157]
s207、若进行故障恢复处理的时长达到预设时长，且微服务实例仍存在故障，则确定故障恢复处理失败，并输出第一故障提醒消息，第一故障提醒消息用于提醒用户对待恢复故障进行处理。
[0158]
在一种实施方式中，监控系统可以在显示界面中显示该第一故障提醒消息，运维人员通过显示界面查看该故障提醒消息后，可以手动对待恢复故障进行故障恢复处理。
[0159]
在另一种实施方式中，监控系统可以向网管系统发送该第一故障提醒消息，以使得网管系统提醒用户对待恢复故障进行故障恢复处理。
[0160]
采用该方法，在对微服务实例进行故障恢复处理后，还可以监控微服务实例的故障恢复情况，若进行故障恢复处理的时长达到预设时长，且微服务实例仍存在故障，则提醒用户对待恢复故障进行处理，以使得该待恢复故障得到及时的处理，减小了同一微服务对应的多个微服务均故障的可能性。
[0161]
在本技术另一实施例中，还预先了设置了故障类型与操作方式之间的对应关系，操作方式包括手动操作和自动操作，在确定待恢复故障对应的预设恢复方式之前，可以先确定待恢复故障对应的预设操作方式，即在上述s204之前，该方法还包括：
[0162]
基于预设的故障类型与操作方式之间的对应关系，确定待恢复故障对应的预设操作方式；
[0163]
若预设操作方式为手动操作，则输出第二故障提醒消息，第二故障提醒消息用于提醒用户根据故障原因进行故障恢复；
[0164]
若预设操作方式为自动操作，则执行上述s204。
[0165]
其中，在确定待恢复故障的故障类型后，本技术实施例可进行对待恢复故障进行根本原因分析，简称为根因分析，从而确定待恢复故障的故障原因，如图6所示，在上述s203之后且在s204之前，该方法还包括：
[0166]
s601、若待恢复故障的故障类型属于性能参数超载类型，则确定发生超载的性能项目对应的预设检测对象，预设检测对象为占用发生超载的性能项目的性能资源的对象。
[0167]
s602、采集微服务实例中预设检测对象对发生超载的性能项目的资源占用参数。
[0168]
s603、根据资源占用参数确定待恢复故障的故障原因。
[0169]
s604、记录待恢复故障的故障原因。
[0170]
如上文所述，本技术实施例中的性能项目包括cpu、内存等。其中，cpu对应的预设检测对象可以为占用cpu的线程栈，内存对应的预设检测对象可以为占用内存的对象。
[0171]
也就是说，若性能参数超载类型具体为cpu占用率超载，则预设检测对象为占用cpu的线程栈；若性能参数超载类型为内存占用率超载，则预设检测对象为占用内存的对象。
[0172]
以预设检测对象为占用cpu的线程栈为例，其中一种根因分析方法为：
[0173]
实时抓取占用发生故障的微服务实例的cpu的线程栈，并按照线程名称对线程进行分组归类，若具有相同名称的线程的数量不断增加，且已超过指定数量，则可确定待恢复故障的故障原因为线程泄露。可选地，在记录故障原因后还可提供相应地优化建议，比如微服务实例的cpu占用率过高，需要进行人工确认，以使得运维人员可以根据该优化建议对微服务实例进行处理。
[0174]
另一种根因分析方法为：实时抓取占用发生故障的微服务实例的cpu的线程，若确定其中一个线程长时间占用相同的cpu资源，而另一个线程长时间等待占用该cpu资源，则可确定故障原因为线程死锁。线程死锁是指两个或两个以上的线程互相持有对方所需的资源，导致一个线程长期占用一个资源，其他线程一直等待获取该资源。可选地，在记录该故障原因后，还可以提供优化建议，比如记录导致线程死锁的线程名称，以使得运维人员可以及时对微服务实例的故障进行二次确认，并对其进行故障恢复处理。
[0175]
再以预设检测对象为占用内存的对象为例，其中一种根因分析方法为：
[0176]
确定占用内存资源的对象，检测每个对象占用的内存资源量的变化趋势，若存在某一对象占用的内存资源量持续增加，且占用的内存资源量已达到预设的内存资源量阈值，则确定故障原因为内存泄露。可选地，在记录该故障原因之后，还可以记录导致内存泄露的对象的标识，以便于运维人员根据该标识对导致内存泄露的对象进行处理。
[0177]
以上的根因分析方法仅为示例，在实际应用中，可以为多种可预测的故障原因设置不同的根因分析方法，以确定产生待恢复故障的根本原因。
[0178]
本技术上述实施例提供的微服务的故障恢复方法可以应用于如图7所示的监控系统中，该监控系统中可以包括：告警监控模块701、故障分析模块702、故障处理模块703、故障评估模块704。可选地，还可以包括活跃告警库705、故障知识库706、套餐知识库707、故障实例表708以及事件记录模块709。
[0179]
告警监控模块701，包括数据采集器和告警监控器，数据采集器用于实时采集微服务实例的性能参数，并基于对性能参数的采集结果确定是否生成告警事件。告警监控器用于监控数据采集子模块生成的告警事件，并将告警事件存入活跃告警库705，并触发故障分析模块702对告警事件进行故障分析。在生成告警事件以及判断是否将告警事件存入活跃告警库705时需使用次数阈值，该次数阈值可以预先被存储于故障知识库706中，可从故障知识库706中查询次数阈值，比如第一预设次数和第二预设次数。
[0180]
其中，数据采集器和告警监控器为两个相互独立的线程，可以避免数据采集过程对告警监控器功能的干扰，提高处理告警事件的效率。
[0181]
故障分析模块702，用于通过故障知识库706中记录的故障定义信息对告警事件进行故障分析，从而判断微服务实例是否存在故障，若存在待恢复故障，则确定待恢复故障的故障类型，并为该待恢复故障生成故障实例，加入故障实例表。在故障分析后，还需记录故障分析结果。进一步地，在确定微服务实例存在故障后，还可以对微服务实例进行根因分析，并记录通过根因分析得到的故障原因。
[0182]
其中，故障实例包括但不限于：故障实例编号、发生故障的微服务所在的主机的id、发生故障的微服务实例标识、故障描述信息、故障状态中的任意一项或多项。其中，故障描述信息可以包括故障类型、故障级别等用于对待恢复故障进行描述的信息。故障状态可以包括：未处理态、已诊断态、自愈成功、自愈失败。
[0183]
故障分析模块702将故障实例加入故障实例表后，该故障实例的故障状态为未处理态。在完成对该待恢复实例的根因分析后，将该故障实例的故障状态更新为已诊断态。
[0184]
故障知识库706中记录的故障定义信息包括具有对应关系故障编号、故障名称以及套餐编号。套餐编号为该故障编号对应的故障恢复方式的编号。
[0185]
故障分析模块702，还用于在确定待恢复故障后，从故障知识库706中查找故障编号对应的套餐编号，并向故障处理模块703发送故障实例编号及套餐编号。
[0186]
故障处理模块703，用于根据故障分析模块702发送的故障实例编号，对故障实例表中该故障实例编号对应的已诊断态的故障实例进行故障处理。具体的，故障处理模块703可以从套餐知识库707中查找上述套餐编号对应的预设恢复方式，进而根据查找到的预设恢复方式对待恢复故障进行故障恢复处理，并触发故障评估模块704。
[0187]
故障评估模块704，用于在故障处理模块703开始进行故障恢复处理后，评估微服务实例的待恢复故障是否已被恢复。当活跃告警库705中，该待恢复故障对应的告警事件的告警状态变更为清除态时，确定待恢复故障已被恢复，将故障实例中的故障状态更新为自愈成功。反之，若达到超时时长时，该待恢复故障对应的告警事件的告警状态仍为活跃态，则确定故障恢复处理失败，通知用户对该待恢复故障进行故障恢复处理，并将故障实例中的故障状态更新为自愈失败。
[0188]
以下对分别监控系统中各模块执行的流程进行详细描述。
[0189]
告警监控模块的处理流程如图8所示，其中，在s801-s802中，数据采集器启动数据采集任务，实时调用每个微服务实例的健康度检测接口，采集每个微服务实例的性能参数。以下以其中一个微服务实例为例进行说明。
[0190]
在s803-s806中，判断是否采集到性能参数，若未采集到性能参数，则将断链次数加1，并判断断链次数是否大于第一预设次数，若大于，则生成第二类告警事件；若不大于，则返回调用微服务实例的健康度检测接口的步骤，即返回s802。可选地，该第一预设次数可以预先被存储在故障知识库中，告警模块可以从故障知识库中获取该第一预设次数。
[0191]
在s807中，若采集到性能参数，则将断链次数清零，并在s808中判断每项性能参数对应的告警级别是否大于等于第一预设级别，比如，若性能参数包括cpu占用率和内存占用率，则分别判断cpu占用率对应的告警级别是否大于第一预设级别，以及内存占用率对应的告警级别是否大于第一预设级别。确定告警级别的方法可参考上述实施例中的相关描述，此处不再赘述。
[0192]
若性能参数对应的告警级别小于第一预设级别，则返回调用健康度检测接口采集性能参数的步骤，即返回s802。
[0193]
在s809中，若性能参数对应的告警级别大于等于第一预设级别，则判断性能参数对应的告警级别是否发生变更，若根据上次采集到的性能参数确定的告警级别与此次确定的告警级别相同，则确定告警级别发生变更；若根据上次采集到的性能参数确定的告警级别与此次确定的告警级别不同，则确定告警级别未发生变更。具体地，数据采集器分别判断每项性能参数对应的告警级别是否发生变更，针对每项性能参数对应的告警级别，分别执行后续的流程。
[0194]
在s810中，若告警级别发生变更，则将该项性能参数对应的连续告警次数清零，并返回调用微服务实例的健康度检测接口的步骤，即返回s802；
[0195]
在s811-s813中，若告警级别未发生变更，则将该项性能参数对应的连续告警次数加1，然后判断该性能参数对应的连续告警次数是否大于等于第二预设次数。可选地，该第二预设次数可以预先被存储在故障知识库中，告警模块可以从故障知识库中获取该第二预设次数。若大于，则生成第一类告警事件，若小于，则返回调用微服务实例的健康度检测接口的步骤。
[0196]
数据采集器生成告警事件，相应地，告警监听器监听告警事件。
[0197]
告警监听器监听到告警事件后，首先判断该告警事件是否重复，判断方法为：判断活跃告警库中是否存在该告警事件，若存在，则该告警事件重复，若不存在，则确定该告警事件为新的告警事件，进而将该告警事件写入活跃告警库，并将该告警事件的告警状态设置为“活跃态”。当确定该告警事件写入活跃告警库成功时，告警监听器触发故障分析模块进行故障分析。
[0198]
故障分析模块的处理流程如图9所示。在s901中，故障分析模块根据告警事件包括的告警信息生成待定故障编号，在一种实施方式中，待定故障编号＝告警源+告警类型+告警级别。
[0199]
然后在s902-s905中，故障分析模块查找故障知识库中是否存在该待定故障编号，若存在，则为该告警事件生成故障实例，将故障实例添加到故障实例表，并将该故障实例的状态设置为“未处理态”；若不存在，则生成并记录用于描述故障编号缺失的系统事件。该系统事件具体被记录在图7中的事件记录模块，运维人员可以查阅事件记录模块中记录的系统事件，并根据已记录的系统事件优化故障知识库与套餐知识库中的信息。
[0200]
在将故障实例添加到故障实例表中之后，在s906-s908中，故障分析模块还可以对故障实例进行根因分析，以分析微服务实例产生故障的深层次原因，并根据根因分析结果给出优化建议。其中，通过根因分析得到的故障原因和相应的优化建议都可以存储于事件记录模块中。根因分析的线程可以预先设置，故障分析模块可根据故障实例的故障类型调用该故障类型对应的根因分析线程进行根因分析。在故障分析模块完成根因分析后，将该故障实例的状态设置为“已诊断态”。
[0201]
可选地，故障分析模块还可以从故障知识库中查找上述待定故障编号对应的套餐编号，并向故障处理模块发送故障实例编号及套餐编号，从而触发故障处理模块进行故障恢复处理。
[0202]
或者，故障分析模块将故障实例的状态设置为“已诊断态”之后，直接触发故障处理模块，然后故障处理模块从故障实例表中查找“已诊断态”的故障实例，并获取该故障实例的故障编号(即上述待定故障编号)，然后从故障知识库中查找故障编号对应的套餐编号。
[0203]
在上述实施方式中，若未在故障知识库中查找到故障编号对应的套餐编号，则生成用于描述恢复方式缺失的系统事件，将该系统事件记录在事件记录模块中。
[0204]
故障处理模块的处理流程如图10所示，以故障分析模块未向故障处理模块发送故障实例编号及套餐编号的情况为例。在s1001-s1004中，故障处理模块被触发后，可以从故障实例表中查找“已诊断态”的故障实例，然后从故障知识库中查找该故障实例的故障编号对应的套餐编号，再从套餐知识库中查找该套餐编号对应的处理套餐。该处理套餐为上述实施例中描述的故障恢复方式。
[0205]
在s1005中，若套餐知识库中不存在该套餐编号对应的处理套餐，则记录用于描述处理套餐缺失的系统事件；
[0206]
在s1006中，若套餐知识库中存在该套餐编号对应的处理套餐，则判断处理套餐中包括的操作方式是否为手动操作。
[0207]
在s1007中，若处理套餐中包括的操作方式是手动操作，则输出第二故障提醒消息，提醒用户手动进行故障恢复处理。具体地，故障处理模块可向上级网管系统发送第二故障提醒消息，并等待运维人员进行故障恢复处理。
[0208]
在s1008中，若处理套餐中包括的操作方式是自动操作，则获取处理套餐中包括的预设恢复方式。其中，性能参数超载类型的故障对应的预设恢复方式为服务熔断，宕机类型的故障对应的预设恢复方式为重启。
[0209]
相应地，在s1009-s1010中，若故障处理模块获取到的预设恢复方式为服务熔断，则暂停为该微服务实例分配新的访问请求；若故障处理模块获取到的预设恢复方式为重启，则对该微服务实例进行热重启。
[0210]
故障处理模块启动按照预设恢复方式进行故障恢复后，则触发故障评估模块进行故障评估。
[0211]
故障评估模块的处理流程如图11所示。在s1101-s1102中，故障评估模块可以实时获取活跃告警库中该微服务实例的告警事件的告警状态，并判断该告警状态是否为“清除态”。
[0212]
在s1103-s1104中，若该告警事件的告警状态是“清除态”，则将故障实例的状态更新为“自愈成功”，若故障处理模块采用的预设恢复方式为服务熔断，则故障处理模块确定该故障实例的状态更新为“自愈成功”后，将停止服务熔断。
[0213]
在s1105-s1107中，若该告警事件的告警状态不是“清除态”，则判断故障处理是否超时。若未超时，则返回获取活跃告警库中该微服务实例的告警事件的告警状态的步骤；若超时，则将故障实例的状态更新为“自愈失败”，使得故障处理模块停止故障恢复处理。同时，故障分析模块可以输出第一故障提醒消息，提醒用户手动对待恢复故障进行处理。
[0214]
在本技术实施例中，在执行上述实施例之前，可以预先设置故障知识库和套餐知识库。为了兼顾系统内存和处理效率，本技术实施例可以采用“懒加载+自动逐出”的策略维护故障知识库和套餐知识库，以下将故障知识库和套餐知识库统称为知识库，对维护知识库的方法进行说明。
[0215]
在上述监控系统运行前，执行结构化查询语言(structured query language，sql)脚本将已创建的知识库导入数据库，在监控系统运行后，可以人工在线对知识库进行更新，以提高知识库的可维护性。
[0216]
当监控系统首次使用知识库时，可以加载并缓存知识库。进而在后续监控系统使用知识库时，可以从缓存中获取知识库，若缓存中不存在知识库，则从数据库中加载并缓存知识库。若从数据库中加载知识库失败，则上报知识库加载失败的事件，以通知运维人员对知识库进行维护。
[0217]
监控系统缓存知识库后，可实时判断对知识库的使用频率，若指定时长内的使用频率大于等于频率阈值，则将该知识库保留在缓存中；若指定时长内的使用频率小于频率阈值，则将该知识库从缓存中清除。
[0218]
示例性地，若确定10天内未使用故障知识库，则将故障知识库从缓存中清除。若确定30天内未使用套餐知识库，则将套餐知识库从缓存中清除。
[0219]
对应于上述方法实施例，基于相同的发明构思，本技术实施例还提供一种微服务的故障恢复装置，如图12所示，该装置包括：
[0220]
采集模块1201，用于采集微服务实例的性能参数；
[0221]
判断模块1202，用于根据对微服务实例的性能参数的采集结果，判断微服务实例是否存在故障；
[0222]
确定模块1203，用于若判断模块1202判断微服务实例存在故障，则将该故障作为待恢复故障，确定待恢复故障的故障类型；
[0223]
确定模块1203，还用于基于预设的故障类型与恢复方式的对应关系，确定待恢复故障对应的预设恢复方式；
[0224]
故障恢复处理模块1204，用于基于预设恢复方式对微服务实例进行故障恢复处理。
[0225]
判断模块1202，包括生成子模块和判断子模块；
[0226]
生成子模块，用于：
[0227]
若采集到的微服务实例的性能参数满足预设告警条件，则生成微服务实例的第一类告警事件，其中，第一类告警事件的告警类型属于性能参数超载类型；或者
[0228]
若连续第一预设次数未采集到微服务实例的性能参数，则生成微服务实例的第二类告警事件，其中，第二类告警事件的告警类型为宕机类型；
[0229]
判断子模块，用于对生成子模块生成的所述第一类告警事件或所述第二类告警事件进行故障分析，判断微服务实例是否存在故障。
[0230]
可选地，生成子模块，具体用于：
[0231]
针对微服务实例的每项性能参数，根据预设的各告警级别与告警区间之间的对应关系，确定该性能参数所属的告警区间对应的告警级别；
[0232]
若该性能参数对应的告警级别大于等于第一预设级别，且已连续第二预设次数确定该性能参数对应于相同的告警级别，则生成微服务实例的第一类告警事件。
[0233]
可选地，判断子模块，具体用于：
[0234]
对已生成的告警事件进行监听，若监听到第一类告警事件，则获取第一类告警事件包括的告警源、告警类型和告警级别；若监听到第二类告警事件，则获取第二类告警事件包括的告警源、告警类型和告警级别，告警源为发生告警事件的微服务实例的标识；
[0235]
根据第一类告警事件或第二类告警事件包括的告警源、告警类型和告警级别生成待定故障编号；
[0236]
若从预设的故障知识库中查找到与待定故障编号相同的故障编号，则根据查找到的故障编号确定微服务实例存在故障。
[0237]
可选地，确定模块1203，具体用于将待恢复故障对应的告警事件的告警类型确定为待恢复故障的故障类型；
[0238]
确定模块1203，具体还用于：若待恢复故障的故障类型属于性能参数超载类型，则确定待恢复故障对应的恢复方式为服务熔断；若待恢复故障的故障类型为宕机类型，则确定待恢复故障对应的恢复方式为重启。
[0239]
可选地，该装置还包括，第一输出模块；
[0240]
采集模块，还用于实时采集微服务实例的性能参数；
[0241]
判断模块1202，还用于根据采集模块对微服务实例的性能参数的采集结果，判断微服务实例是否存在故障；
[0242]
确定模块1203，还用于若故障恢复处理模块1204进行故障恢复处理的时长达到预设时长，且微服务实例仍存在故障，则确定故障恢复处理失败，并触发第一输出模块输出第一故障提醒消息，第一故障提醒消息用于提醒用户对待恢复故障进行处理。
[0243]
可选地，该装置还包括：记录模块；
[0244]
确定模块1203，还用于若待恢复故障的故障类型属于性能参数超载类型，则确定发生超载的性能项目对应的预设检测对象，预设检测对象为占用发生超载的性能项目的性能资源的对象；
[0245]
采集模块，还用于采集微服务实例中预设检测对象对发生超载的性能项目的资源占用参数；
[0246]
确定模块1203，还用于根据资源占用参数确定待恢复故障的故障原因；
[0247]
记录模块，用于记录待恢复故障的故障原因。
[0248]
可选地，该装置还包括：第二输出模块；
[0249]
确定模块1203，还用于基于预设的故障类型与操作方式之间的对应关系，确定待恢复故障对应的预设操作方式；
[0250]
第二输出模块，用于若确定模块1203确定预设操作方式为手动操作，则输出第二故障提醒消息，第二故障提醒消息用于提醒用户根据故障原因进行故障恢复；
[0251]
确定模块1203，还用于若确定预设操作方式为自动操作，则触发确定模块1203基于预设的故障类型与恢复方式的对应关系，确定待恢复故障对应的预设恢复方式。
[0252]
基于相同的发明构思，本技术实施例还提供了一种电子设备，如图13所示，包括处理器1301、通信接口1302、存储器1303和通信总线1304，其中，处理器1301，通信接口1302，存储器1303通过通信总线1304完成相互间的通信，
[0253]
存储器1303，用于存放计算机程序；
[0254]
处理器1301，用于执行存储器1303上所存放的程序时，实现上述方法实施例中的方法步骤。
[0255]
上述电子设备提到的通信总线可以是外设部件互连标准(peripheral component interconnect，pci)总线或扩展工业标准结构(extended industry standard architecture，eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
[0256]
通信接口用于上述电子设备与其他设备之间的通信。
[0257]
存储器可以包括随机存取存储器(random access memory，ram)，也可以包括非易失性存储器(non-volatile memory，nvm)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
[0258]
上述的处理器可以是通用处理器，包括中央处理器(central processing unit，cpu)、网络处理器(network processor，np)等；还可以是数字信号处理器(digital signal processing，dsp)、专用集成电路(application specific integrated circuit，asic)、现
场可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
[0259]
在本技术提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一微服务的故障恢复方法的步骤。
[0260]
在本技术提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一微服务的故障恢复方法。
[0261]
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本技术实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solid state disk(ssd))等。
[0262]
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0263]
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、电子设备、介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0264]
以上所述仅为本技术的较佳实施例，并非用于限定本技术的保护范围。凡在本技术的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本技术的保护范围内。