应用自愈处理方法、装置、设备和存储介质与流程

1.本技术涉及应用容器技术领域，尤其涉及一种应用自愈处理方法、装置、设备和存储介质。


背景技术：

2.应用容器技术是将一个应用拆分成多个独立的、具有业务属性的原子应用(也称为原子服务)，每个原子应用运行在独立的进程中，原子应用间通过轻量级的通信机制互相协作，实现了整个应用运行，从而为终端用户提供业务价值。
3.相关技术中，在云原生微服务技术及原始串联批处理应用中，原子应用出现异常时可通过原子应用自身扩容进行应急，但依然存在部分场景无解决方案的情况，导致应用的稳定性较低。


技术实现要素：

4.本技术提供一种应用自愈处理方法、装置、设备和存储介质，用以解决应用的稳定性较低的问题。
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.图1是本技术一实施例提供的应用自愈处理方法的应用场景示意图；
37.图2是本技术一实施例提供的应用自愈处理方法的流程示意图；
38.图3是本技术一实施例提供的原子应用自愈过程的结构示意图；
39.图4是本技术一实施例提供的副本应用自愈过程的结构示意图；
40.图5是本技术一实施例提供的多实例应用调度过程的结构示意图；
41.图6是本技术一实施例提供的单实例应用调度过程的结构示意图；
42.图7是本技术一实施例提供的应用自愈处理装置的结构示意图；
43.图8是本技术一实施例提供的电子设备的结构示意图。
44.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。
具体实施方式
45.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
46.本技术的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、产品或设备固有的其它步骤或单元。
47.相关技术中，随着云原生技术的发展，业务支撑系统在逐步实现微元化，微服务框架的诞生，更加引导着业务支撑系统走向微元化。在实际的生产研发中，业务支撑系统的系统框架中存在大量的原子应用，各个原子应用相互协作，实现了整个业务支撑系统的运行。虽然微服务框架可以实现原子应用的扩容和熔断，但是只是对原子应用进行基础扩容，仅仅实现了量的改变，且扩容占用大量的物理资源，在部分极端场景，扩容解决不了根本问题。
48.另外，现有信息技术(information technology，简称it)框架中对于业务及数据的处理一般遵循应用通配性原则，在此原则下设计的应用一般具备快速处理、自动扩容和应用无状态等特性。但是在实际生产应用过程中，数据的处理，如，数据逻辑处理，往往受限于业务的复杂性，在满足应用通配性的基础上，应用的处理效率及处理能力受到限制。
49.针对上述问题，本技术提供一种应用自愈处理方法，该方法通过监测应用的业务状况，实现对于业务异常应用的自动识别，并在应用发生业务异常时，如，业务处理效率突降，自我复制，生成对应的副本应用，并借助合适的算法(如，调度算法、选举算法和抢占算法等)和业务场景预设，在异常应用健康性不足的情况下，区分不同的业务场景实现异常应用和副本应用的配合调度，即，当异常应用的业务处理能力不足时，可由副本应用进行业务处理，进而实现不同业务场景的异常应用的自愈。通过对应用进行自动监测和应用自愈，避免了因应用发生业务异常造成的时间浪费等，可以提高应用的业务处理效率及业务处理能力，进而提升应用的稳定性。
50.进一步地，应用实现自愈后，可降低相关人员的操作压力，达到了比较满意的效果。
51.图1为本技术一实施例提供的应用自愈处理方法的应用场景示意图，该应用场景可以包括调度场景、抢占场景和选举场景等。如图1所示，在某一具体的应用场景中，主控制器同时控制原子应用a、原子应用b、原子应用c和原子应用d，当主控制器通过心跳信息监测
到原子应用b出现异常时，其中，心跳信息包含序列化的业务类指标，一般为业务量突增和业务处理效率突降等指标，对原子应用b进行复制，生成原子应用b对应的副本应用b。副本应用b可以有两种形态(副本形态和稽核形态)，副本应用的形态可以由相关人员设计。具体地，主控制器可以将心跳信息及心跳信息包含的业务序列化数据同步发送给原子应用b和副本应用b，根据不同的应用场景，主控制器可以根据业务序列化数据选择原子应用b和副本应用b中最优的应用进行业务处理，也可以由副本应用直接抢占进行业务处理等。在副本应用b处理业务的过程中，主控制器可以实时校验副本应用b处理的业务量是否达到业务量阈值，以及，副本应用处理业务的流程是否正确等。当业务量或业务处理效率恢复到正常指标后，原子应用b实现自愈，自愈后的原子应用b可以主动通知副本应用b下线，并启动自愈过程中业务数据稽核。
52.下面结合图1的应用场景，参考图2来描述根据本技术示例性实施方式的应用自愈处理方法。需要注意的是，上述应用场景仅是为了便于理解本技术的精神和原理而示出，本技术的实施方式不受图1所示应用场景的限制。
53.图2为本技术一实施例提供的应用自愈处理方法的流程示意图。如图2所示，本技术实施例中的应用自愈处理方法包括以下步骤：
54.s201：监测目标应用是否发生业务异常，业务异常为故障、业务量突增和业务处理效率突降中的至少一种。
55.在该步骤中，故障是指目标应用不能处理业务，而业务量突增和业务处理效率突降是指目标应用还可以处理业务。
56.一些实施例中，监测目标应用是否发生业务异常，可以进一步包括：获取目标应用的心跳信息，心跳信息包括业务量突增和/或业务处理效率突降；若业务量突增大于或等于业务量突增阈值，则确定目标应用出现业务量突增；若业务处理效率突降大于或等于业务处理效率突降阈值，则确定目标应用出现业务处理效率突降；若获取不到目标应用的心跳信息，则确定目标应用出现故障。其中，心跳信息指目标应用的实时状态，包括序列化的业务类指标，一般为业务量突增和业务处理效率突降等指标。示例地，业务量突增阈值和业务处理效率突降阈值可由相关人员根据业务场景和目标应用(即上文出现的“原子应用”)处理业务的实际情况进行设定。
57.如前所述，主控制器可以获取目标应用的实时状态，即心跳信息，通过监测心跳信息，确定目标应用是否发生业务异常。示例地，当目标应用发生业务异常时，可以是主控制器监测到目标应用的业务量突增，也可以是主控制器监测到目标应用的业务处理效率突降，等等。
58.s202：响应于监测到目标应用发生业务异常，生成目标应用对应的副本应用。
59.该步骤中，生成副本应用的具体实现可参考相关技术，此处不再赘述。本领域技术人员可以理解，目标应用既可以是原子应用，也可以是副本应用，其中，原子应用和副本应用为相对概念，若一原子应用的副本应用也出现业务异常，则生成该副本应用的副本应用。
60.s203：若目标应用发生的业务异常不包括故障，则确定目标应用待处理的业务之间是否存在事务关系。
61.在该步骤中，对于目标应用发生的业务异常不包括故障，可以理解目标应用仍可以处理业务，该情况下，进一步确定目标应用待处理的业务之间是否存在事务关系。
62.其中，事务关系是指一个规定动作，即，只能按照一定的顺序执行的业务处理流程。示例地，若目标应用为打印机，所要处理的业务为打印10份资料，则需要先取尽可能多的打印纸，以满足打印需求；然后将打印纸放置在打印机中；最后点击打印按钮，进行资料打印，得到10份资料。在该实施例中，可以根据所要打印的资料，设置打印机的打印模式，如，封面单面打印，正文内容双面打印等，打印模式可以提前设置，也可以在点击打印按钮前设置，但放置打印纸、点击打印按钮、得到打印资料的顺序是不变的。
63.基于上述示例，可以是一台打印机打印10份资料，也可以是多台打印机同时打印10份资料。
64.一些实施例中，应用自愈处理方法还可以包括：若目标应用发生的业务异常包括故障，则可以确定业务场景为抢占场景；控制副本应用处理目标应用待处理的业务。其中，目标应用发生故障时不能再处理业务，此时，由副本应用进行业务处理。可选地，抢占场景的目标应用发生的故障可以是目标应用卡死或其他异常，当目标应用卡死时，副本应用可直接抢占，处理目标应用待处理的业务。
65.s204：若不存在事务关系，则确定业务场景为调度场景或选举场景或抢占场景。
66.可以理解，业务之间不存在事务关系，即应用无状态，业务之间是相互独立的，可以并行处理，也可以串行处理，具体需根据业务需求设置。此时，可确定业务场景为调度场景或选举场景或抢占场景。
67.一些实施例中，若目标应用待处理的业务之间存在事务关系，则可以确定业务场景为特殊业务场景，可以结合数据分片和/或业务隔离，对业务中存在事务关系的目标业务进行业务处理。
68.可选地，在特殊业务场景中，部分目标应用不能做到应用无状态，则在应用有状态的情况下，需要结合数据分片和/或业务隔离(或，业务逻辑隔离)等对目标业务进行业务处理，以满足特殊业务场景的应用自愈。
69.s205：采用适用于业务场景的设定算法进行副本应用的启动，其中，适用于调度场景的设定算法为根据业务数据对目标应用和副本应用进行有序调度来处理业务；适用于抢占场景的设定算法为由副本应用抢占处理业务；适用于选举场景的设定算法为根据业务数据对目标应用与副本应用进行选举，由选择的应用处理业务。
70.也就是说，在业务之间不存在事务关系时，可以有序调度目标应用和副本应用进行业务处理，也可以在目标应用和副本应用中选取一个应用进行业务处理，或者由副本应用抢占进行业务处理。
71.一些实施例中，可以通过主控制器对目标应用处理业务的全流程进行目标应用的自动复制和目标应用自愈的整体调度。示例地，在复制目标应用生成对应的副本应用的过程中，主控制器可根据不同的业务场景，采用不同的设定算法进行副本应用的启动或调度，其中，调度场景采用调度算法启动副本应用，选举场景采用选举算法启动副本应用，抢占场景采用抢占算法启动副本应用。具体地，在调度场景中，目标应用与副本应用的业务处理逻辑相同，且业务之间不存在事务关系，可由主控制器根据业务序列化数据进行有序调度，目标应用和副本应用均可进行业务处理；在抢占场景中，目标应用与副本应用的业务处理逻辑不同，目标应用可能存在卡死或其他异常的问题，可由副本应用直接抢占，进行业务处理；在选举场景中，目标应用与副本应用均可处理目标应用发生业务异常时的业务，且业务
之间不存在事务关系，可由主控制器根据业务序列化数据进行选举，选择最优的应用进行业务处理。
72.可选地，调度算法、选举算法和抢占算法可以根据业务场景预先设置。如，业务场景是打印机打印100张纸的资料，如果要求最快打印，可以采用调度算法，用两台或更多台打印机同时打印，如果要求打印100张彩印纸的资料，可以采用选举算法选举彩印机进行打印。
73.另外，对于不同的业务场景的具体业务，建议提前根据业务场景进行具体业务的流程制定，可制定业务侧最适用的业务处理流程。
74.在上述实施例的基础上，图3为本技术一实施例提供的原子应用自愈过程的结构示意图。如图3所示，启动一原子应用(即上文出现的“目标应用”)，原子应用在处理业务的过程中发生业务异常，可先进行是否扩容的判断，即，是否对原子应用进行复制，生成对应的副本应用的判断，若否，则重新启动原子应用；若是，则根据不同的业务场景采用不同的扩容方式，即启动副本应用的方式，具体为，调度场景采用调度算法启动副本应用，选举场景采用选举算法启动副本应用，抢占场景采用抢占算法启动副本应用。其中，不同的业务场景采用不同的算法启动副本应用后，与主控制器的交互过程也不相同，在调度场景中，由主控制器控制原子应用和副本应用处理业务；在抢占场景中，是副本应用先处理业务，处理完成后再反馈给主控制器；在选举场景中，是原子应用和副本应用先处理一部分业务，把处理结果反馈给主控制器，主控制器再根据接收到的处理结果，选择最优应用处理剩余业务。示例地，处理结果可以包括业务处理量、业务剩余量和业务处理效率等。
75.与上述实施例对应，图4为本技术一实施例提供的副本应用自愈过程的结构示意图。如图4所示，当副本应用也发生业务异常时，可把副本应用作为新的原子应用进行应用复制，具体的实现原理与图3实施例类似，此处不再赘述。
76.本技术实施例提供的应用自愈处理方法，通过监测目标应用是否故障、业务量突增和业务处理效率突降等，实现对于目标应用发生业务异常的自动识别，并在目标应用发生业务异常时，生成目标应用对应的副本应用，并采用业务场景预设和合适的设定算法，区分不同的业务场景实现目标应用和副本应用的配合调度，由副本应用进行业务处理，或由目标应用和副本应用协同处理业务，进而实现目标应用自愈，避免了因发生业务异常造成的时间浪费等，可以提高业务处理效率及业务处理能力，进而提升应用的稳定性。
77.进一步地，目标应用实现自愈后，可降低相关人员的操作压力和工作量，达到了比较满意的效果。
78.上述实施例中的特殊业务场景，可以结合数据分片和/或业务隔离，对待处理业务中存在事务关系的目标业务进行业务处理。其中，结合数据分片，对业务中存在事务关系的目标业务进行业务处理，可以包括：过滤获取与目标业务相关的目标数据；基于目标数据，对目标业务进行业务处理。
79.进一步地，基于目标数据，对目标业务进行业务处理，可以包括：确定与目标数据相关的应用是否为多个应用；若是，则采用消费者组的方式，控制多个应用消费目标数据。示例地，应用在进行业务处理时，可以按照既定规则进行业务处理，其中，对于既定数据，只能由具体的应用进行处理，对不属于自我范畴的应用和/或数据，进行过滤处理。当有多个应用消费同一组数据时，可以采用消费者组的方式，控制多个应用消费同一组数据。
80.另外，结合业务隔离，采用原子应用和/或副本应用，对业务中存在事务关系的目标业务进行业务处理，其中，业务隔离可使副本应用更具灵活性；任一原子应用均应具备副本应用的灵活性，且各个原子应用应该具备识别业务场景的能力，原子应用在处理业务的时候，多个原子应用可以串联形成关联应用。示例地，可以根据业务场景进行业务隔离，设定一个应用仅处理同一种业务。
81.在上述实施例的基础上，本技术提供的应用自愈处理方法可涵盖原子应用和批处理应用(即多个原子应用的集合)，实现不同业务场景的应用自愈处理。如图5所示，提供一种多个原子应用和多个副本应用相互协作，共同对待处理业务进行业务处理的实施例。图5为本技术一实施例提供的多实例应用调度过程的结构示意图，图5中的奇、偶可以认为是按顺序[1，2，3，4，5，
……
]排列的待处理业务，当原子应用发生业务异常后，对原子应用进行复制，生成对应的副本应用，其中，排列为奇数的待处理业务由原子应用处理，排列为偶数的待处理业务由副本应用处理。图5中有多个原子应用和多个副本应用相互协作，共同对待处理业务进行业务处理。
[0082]
与上述实施例对应，图6为本技术一实施例提供的单实例应用调度过程的结构示意图。与图5类似，图6中的奇、偶也可以认为是按顺序[1，2，3，4，5，
……
]排列的待处理业务，当原子应用发生业务异常后，对原子应用进行复制，生成对应的副本应用，最终由一个原子应用处理待处理业务中排为奇数的待处理业务，由一个副本应用处理待处理业务中排为偶数的待处理业务。
[0083]
一些实施例中，采用适用于业务场景的设定算法进行副本应用的启动之后，还可以包括：校验副本应用是否正确处理业务。可选地，校验副本应用是否正确处理业务，可以包括：校验副本应用处理的业务量是否达到业务量阈值，以及，副本应用处理业务的流程是否正确等；响应于副本应用处理的业务量达到业务量阈值，且副本应用处理业务的流程正确，则确定副本应用正确处理业务，进而保证业务处理和/或数据处理的准确性。示例地，业务量阈值可以根据实际情况由相关人员设定，也可以直接设定为待处理业务的业务量等。
[0084]
在上述实施例的基础上，采用适用于业务场景的设定算法进行副本应用的启动之后，还可以包括：响应于监测到目标应用自愈，将目标应用的心跳信息同步给副本应用，并将副本应用的心跳信息同步给目标应用，以使目标应用和副本应用根据双方的心跳信息确定待下线应用。其中，监测到目标应用自愈，可以包括：获取目标应用的心跳信息；若业务量突增值小于业务量突增阈值，且，业务处理效率突降值小于业务处理效率突降阈值，则确定目标应用自愈。
[0085]
可选地，待下线应用在下线前可以进行数据稽核和临界异常数据清理的预下线处理，并在预下线处理成功后通知主控制器进行下线处理。其中，数据稽核是指实现数据的完整性和一致性检查的完整数据质量管控链条，包括数据采集、预处理、比对、分析、预警、通知和问题修复等，用以提升数据质量；临界异常数据清理(或垃圾处理)是待下线应用在下线前做的一些异常数据处理工作。示例地，当副本应用接收到下线信号时，可以进行自愈过程中的数据稽核及临界异常数据清理，当数据稽核无问题且无异常数据时，副本应用可以通知主控制器进行下线处理。
[0086]
示例地，当主控制器判定应用整体已经恢复时，主控制器将同步心跳信息给原子应用和副本应用，两个应用收到心跳信息后，可以主动进行业务交互，一般情况下，是原子
应用通知副本应用下线，并进行数据稽核过程；也可以存在副本应用执行效率高，处理能力较强，可反向要求原子应用下线，并进行数据稽核过程。
[0087]
可以理解的是，应用自愈的过程需要持续进行优化迭代，在进行部分预想场景化构建后，本技术提供的应用自愈处理方法可以轻松解决多数业务场景的应用业务异常，剩余业务场景的应用业务异常可以通过持续优化，将应用的自愈能力持续提升。
[0088]
综上所述，本技术至少具有以下优势：
[0089]
1、区别于简单的应用扩容，本技术提供的应用自愈处理方法，通过监测目标应用是否故障、业务量突增和业务处理效率突降等，实现对于目标应用发生业务异常的自动识别，并在目标应用发生业务异常时，生成目标应用对应的副本应用，针对不同的业务场景，采用选举算法、调度算法和抢占算法等启动副本应用，通过副本应用实现对于目标应用的补偿或替代，进而实现目标应用自愈。另外，针对特殊业务场景，可以借助业务隔离和数据分片等，实现特殊业务场景的目标应用自愈，进而实现多种业务场景的目标应用自愈。
[0090]
2、目标应用实现自愈后，可以提升目标应用业务处理系统的稳定性和连续性，避免了因目标应用发生业务异常造成的目标应用业务处理系统停工和时间浪费等，可以提高目标应用的业务处理效率及业务处理能力。进一步地，目标应用实现自愈后，可降低相关人员的操作压力、减少运维的复杂度和工作量等，达到了比较满意的效果。
[0091]
3、目标应用实现自愈后，副本应用与目标应用进行心跳信息的交互，根据心跳信息，可选择业务处理能力弱的应用下线，释放临时占用的资源，并进行数据稽核和临界异常数据清理，确保业务处理和/或数据处理的准确性。
[0092]
4、目标应用实现自愈后，若再发现目标应用业务异常后，可随时调度副本应用启动，由副本应用进行业务处理的接管和分担，以应对批量瞬时业务增加的情况等，保障资源利用最大化。
[0093]
下述为本技术装置实施例，可以用于执行本技术方法实施例。对于本技术装置实施例中未披露的细节，请参照本技术方法实施例。
[0094]
图7为本技术一实施例提供的应用自愈处理装置的结构示意图。为了便于说明，仅示出了与本技术实施例相关的部分。如图7所示，该应用自愈处理装置70包括：监测模块71、生成模块72、第一确定模块73、第二确定模块74和处理模块75。其中，
[0095]
监测模块71，用于监测目标应用是否发生业务异常，业务异常为故障、业务量突增和业务处理效率突降中的至少一种；
[0096]
生成模块72，用于响应于监测到目标应用发生业务异常，生成目标应用对应的副本应用；
[0097]
第一确定模块73，用于若目标应用发生的业务异常不包括故障，则确定目标应用待处理的业务之间是否存在事务关系；
[0098]
第二确定模块74，用于若不存在事务关系，则确定业务场景为调度场景或选举场景或抢占场景；
[0099]
处理模块75，用于采用适用于业务场景的设定算法进行副本应用的启动，其中，适用于调度场景的设定算法为根据业务数据对目标应用和副本应用进行有序调度来处理业务；适用于抢占场景的设定算法为由副本应用抢占处理业务；适用于选举场景的设定算法为根据业务数据对目标应用与副本应用进行选举，由选择的应用处理业务。
[0100]
一种可能的实施方式中，第一确定模块73可以具体用于：若目标应用发生的业务异常包括故障，则确定业务场景为抢占场景；控制副本应用处理目标应用待处理的业务；第二确定模块74可以具体用于：若目标应用待处理的业务之间存在事务关系，则确定业务场景为特殊业务场景，并结合数据分片和/或业务隔离，对业务中存在事务关系的目标业务进行业务处理。
[0101]
一种可能的实施方式中，第二确定模块74还可以用于：过滤获取与目标业务相关的目标数据；基于目标数据，对目标业务进行业务处理。
[0102]
一种可能的实施方式中，第二确定模块74还可以用于：确定与目标数据相关的应用是否为多个应用；若是，则采用消费者组的方式，控制多个应用消费目标数据。
[0103]
一种可能的实施方式中，监测模块71可以具体用于：获取目标应用的心跳信息，心跳信息包括业务量突增和/或业务处理效率突降；若业务量突增大于或等于业务量突增阈值，则确定目标应用出现业务量突增；若业务处理效率突降大于或等于业务处理效率突降阈值，则确定目标应用出现业务处理效率突降；若获取不到目标应用的心跳信息，则确定目标应用出现故障。
[0104]
一种可能的实施方式中，处理模块75可以具体用于：校验副本应用是否正确处理业务。
[0105]
一种可能的实施方式中，处理模块75还可以用于：响应于监测到目标应用自愈，将目标应用的心跳信息同步给副本应用，并将副本应用的心跳信息同步给目标应用，以使目标应用和副本应用根据双方的心跳信息确定待下线应用。
[0106]
一种可能的实施方式中，待下线应用在下线前进行数据稽核和临界异常数据清理的预下线处理，并在预下线处理成功后通知主控制器进行下线处理。
[0107]
本技术实施例提供的应用自愈处理装置，其实现原理和技术效果与上述实施例类似，具体可参考上述实施例，此处不再赘述。
[0108]
图8为本技术一实施例提供的电子设备的结构示意图。例如，电子设备可以被提供为一服务器。如图8所示，电子设备80包括：
[0109]
处理器810，其进一步包括一个或多个处理器，以及由存储器820所代表的存储器资源，用于存储可由处理器810执行的指令，例如应用程序。存储器820中存储的应用程序可以包括一个或一个以上的每一个对应于一组处理指令的模块。此外，处理器810被配置为执行指令，以执行上述应用自愈处理方法。
[0110]
电子设备80还可以包括一个电源组件830被配置为执行电子设备80的电源管理，一个有线或无线的网络接口840被配置为将电子设备80连接到网络，和一个输入输出接口850。电子设备80可以操作基于存储在存储器820的操作系统，例如x86、windows servertm、mac os xtm、unixtm、linuxtm、freebsdtm或类似。
[0111]
图8中提到的处理器810包含的处理器可以是通用处理器，包括中央处理器、网络处理器(network processor，简称np)等；数字信号处理器(digital signal processor，简称dsp)、专用集成电路(application specific integrated circuit，简称asic)、现场可编程逻辑门阵列(field programmable gate array，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
[0112]
存储器820可能包含随机存取存储器(random access memory，简称ram)，也可能
还包括静态随机存取存储器(static random access memory，简称sram)，电可擦除可编程只读存储器(electric erasable programmable read-only memory，简称eeprom)，可擦除可编程只读存储器(erasable programmable read-only memory，简称eprom)，可编程只读存储器(programmable read-only memory，简称prom)，只读存储器(read only memory，简称rom)，磁存储器，快闪存储器，磁盘或光盘，例如至少一个磁盘存储器。
[0113]
本领域技术人员可以理解，图8示出的电子设备并不构成对电子设备的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者不同的部件布置。
[0114]
本技术实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当计算机执行指令被执行时，实现如上应用自愈处理方法。
[0115]
本技术实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被执行时实现如上应用自愈处理方法。
[0116]
本技术实施例还提供一种运行指令的芯片，芯片用于执行如上任一方法实施例的应用自愈处理方法。
[0117]
需要说明的是，本技术所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。
[0118]
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由下面的权利要求书指出。
[0119]
应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求书来限制。