一种灾难区域中业务切换策略管理方法、装置及设备

摘要

本文提供了一种灾难区域中业务切换策略管理方法、装置及设备，所述方法包括：响应业务切换指令，以确定灾难区域和目标区域，所述灾难区域和所述目标区域共用至少一个应用的至少一个业务；确定所述灾难区域和所述目标区域共用的至少一个目标应用的至少一个目标业务；获取所述灾难区域中全部目标业务需求容量和所述目标区域中的剩余容量；根据所述需求容量和所述剩余容量，按照预设的切换策略进行业务切换，以使所述目标区域接管所述灾难区域的全部目标业务，本文能实现对灾难区域共用业务快速灵活的接管，提高了对区域级灾难的业务切换管理效率。

说明书

技术领域

本文属于通信领域，具体涉及一种灾难区域中业务切换策略管理方法、装置及设备。

背景技术

随着客户对于互联网金融业务连续性要求日益增高，为降低各类故障发生带来的业务影响，应用架构的高可用部署尤为重要。然而，在此基础上通过科学合理的配置监控指标等判断条件以及不同的业务场景、重点交易划分，合理、高效的完成各类环境切换、降级的需求更为紧迫。然而目前针对区域级灾难发生，单区域需全量接管灾难区域交易场景，但是由于单个区域容量有限，很难接管灾难区域的全部业务场景，而且目前生产值班人员很难对区域内所有应用群组做到全部了解，很难得到灾难区域的真实的需求容量，从而很难给出精准的业务切换，因此如何提高对灾难区域业务切换的管理效率成为目前亟需解决的技术问题。

发明内容

针对现有技术的上述问题，本文的目的在于，提供一种灾难区域中业务切换策略管理方法、装置及设备，能够提高区域级灾难的业务切换管理效率。

为了解决上述技术问题，本文的具体技术方案如下：

一方面，本文提供一种灾难区域中业务切换策略管理方法，所述方法包括：

响应业务切换指令，以确定灾难区域和目标区域，所述灾难区域和所述目标区域共用至少一个应用的至少一个业务；

确定所述灾难区域和所述目标区域共用的至少一个目标应用的至少一个目标业务；

获取所述灾难区域中全部目标业务需求容量和所述目标区域中的剩余容量；

根据所述需求容量和所述剩余容量，按照预设的切换策略进行业务切换，以使所述目标区域接管所述灾难区域的全部目标业务。

进一步地，所述目标业务通过以下步骤确定：

获取所述灾难区域和所述目标区域共用应用中业务的等级序列；

按照预设等级阈值，确定所述灾难区域和所述目标区域共用的至少一个目标应用的至少一个目标业务。

进一步地，所述获取所述灾难区域中全部目标业务需求容量包括：

针对每个所述目标业务，对所述目标业务上的每个预设节点群组进行压测处理，以得到全部预设节点群组的最大交易性能，并将全部预设节点群组中最大交易性能最低的节点群组标记为瓶颈节点群组，其余节点群组标记为关键节点群组；

获取所述关键节点群组的历史交易处理量和所述瓶颈节点群组的历史交易处理量，并根据所述历史交易处理量，计算得到所述关键节点群组相对所述瓶颈节点群组需求容量的需求比例；

根据所述瓶颈节点群组的交易需求容量和所述需求比例，计算得到每个所述关键节点群组的交易需求容量，其中所述瓶颈节点群组的交易需求容量是通过所述瓶颈节点群组在目标区域中的最大交易性能和当前使用量确定的；

根据所述瓶颈节点群组和所述关键节点群组的交易需求容量，计算得到每个所述目标业务的需求容量，从而得到所述灾难区域中全部目标业务需求容量。

进一步地，所述根据所述瓶颈节点群组和所述关键节点群组的交易需求容量，计算得到每个所述目标业务的需求容量，包括：

针对所述目标业务中的任一节点群组A；

当该节点群组A在全部目标业务中至少一次被标记为瓶颈节点群组时，则将该节点群组A在目标区域中的最大交易性能与当前使用量的差值作为该节点群组A的交易需求容量；当该节点群组A在全部目标业务中全部被标记为关键群组时，确定该节点群组A在全部目标业务中的交易需求容量的最大值，并将该最大值和该节点群组A在目标区域中的最大交易性能与当前使用量的差值进行比较，其中较小值作为该节点群组A的交易需求容量；

将所述目标业务上的节点群组的交易需求容量之和作为所述目标业务的需求容量。

进一步地，所述根据所述需求容量和所述剩余容量，按照预设的切换策略进行业务切换，包括：

判断所述剩余容量是否小于所述需求容量；

若所述剩余容量不小于所述需求容量，则控制所述目标区域接管所述灾难区域中的全部目标应用中的全部目标业务；

若所述剩余容量小于所述需求容量，则对所述目标区域现有应用进行缩容处理得到缩容后的剩余容量，直到所述缩容后的剩余容量不小于所述需求容量，则控制所述目标区域接管所述灾难区域中的全部目标应用中的全部目标业务。

进一步地，所述对所述目标区域进行缩容处理得到缩容后的剩余容量，包括：

确定所述目标区域的缩容对象，所述缩容对象为所述目标区域中的非目标应用和/或非目标业务；

获取所述缩容对象的缩容系数，所述缩容系数是根据所述缩容对象的预设等级确定的；

根据所述缩容系数，对所述缩容对象进行缩容处理，得到缩容量；

根据所述剩余容量和所述缩容量，计算得到缩容后的剩余容量。

作为可选地，所述若所述剩余容量小于所述需求容量，则对所述目标区域进行缩容处理得到缩容后的剩余容量，直到所述缩容后的剩余容量不小于所述需求容量，则控制所述目标区域接管所述灾难区域中的全部目标应用中的全部目标业务，包括：

若缩容后的剩余容量不小于所述需求容量，则控制所述目标区域接管所述灾难区域中的全部目标应用中的全部目标业务；

若缩容后的剩余容量小于所述需求容量，则对所述灾难区域中的全部目标业务进行降级处理得到降级后的需求容量，以使缩容后的剩余容量不小于降级后的需求容量，从而控制所述目标区域接管所述灾难区域中的全部目标应用中的全部目标业务。

进一步地，所述对所述灾难区域中的全部目标业务进行降级处理得到降级后的需求容量，包括：

根据所述缩容后的剩余容量和所述需求容量，计算得到所述全部目标业务的降级系数；

根据所述降级系数，对所述全部目标业务的需求容量进行降级处理，以获得降级后的需求容量。

另一方面，本文还提供一种灾难区域中业务切换策略管理装置，所述装置包括：

切换指令响应模块，用于响应业务切换指令，以确定灾难区域和目标区域，所述灾难区域和所述目标区域共用至少一个应用的至少一个业务；

目标业务确定模块，用于确定所述灾难区域和所述目标区域共用的至少一个目标应用的至少一个目标业务；

计算模块，用于获取所述灾难区域中全部目标业务需求容量和所述目标区域中的剩余容量；

策略执行模块，用于根据所述需求容量和所述剩余容量，按照预设的切换策略进行业务切换，以使所述目标区域接管所述灾难区域的全部目标业务。

另一方面，本文还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述所述的方法步骤。

最后，本文还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述所述的方法步骤。

采用上述技术方案，本文所述的一种灾难区域中业务切换策略管理方法、装置及设备，通过确定存在业务共用关系的区域，在其中一个区域发生灾难时，另一区域完成对灾难区域共用业务的接管，从而保证共用业务的正常运行，进一步地，通过对灾难区域共用业务的需求容量和接管区域的剩余容量之间的比较，结合预设的切换策略从而实现对灾难区域共用业务快速灵活的接管，提高了对区域级灾难的业务切换管理效率。

为让本文的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

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

图1示出了本文实施例提供方法的实施环境示意图；

图2示出了本文实施例中存在共用关系的区域关系示意图；

图3示出了本文实施例提供的灾难区域中业务切换策略管理方法步骤示意图；

图4示出了本文实施例中目标业务确定步骤示意图；

图5示出了本文实施例中需求容量确定步骤示意图；

图6示出了本文实施例中对灾难区域接管步骤示意图；

图7示出了本文实施例中目标区域缩容处理示意图；

图8示出了本文实施例中灾难区域降级处理示意图；

图9示出了本文一个实施例中灾难区域中业务切换策略管理方法流程图；

图10示出了本文实施例提供的灾难区域中业务切换策略管理装置示意图；

图11示出了本文实施例中提供的计算机设备的结构示意图。

附图符号说明：

10、控制单元；

20、数据采集单元；

30、参数配置单元；

40、服务器；

100、切换指令响应模块；

200、目标业务确定模块；

300、计算模块；

400、策略执行模块；

1102、计算机设备；

1104、处理器；

1106、存储器；

1108、驱动机构；

1110、输入/输出模块；

1112、输入设备；

1114、输出设备；

1116、呈现设备；

1118、图形用户接口；

1120、网络接口；

1122、通信链路；

1124、通信总线。

具体实施方式

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

需要说明的是，本文的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本文的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

现有技术中，为了保证业务进行的连续性，降低业务发生故障等灾难事件造成的业务影响，通常会在应用架构上设置高可用部署，一般场景中，会采用冷备的解决方案，但是这种占用资源较多，备用系统很长时间不会用上，造成资源的浪费，因此还可以采用双活高可用方案，特别是区域级灾难发生时，通过单区域接管灾难区域的交易场景，从而避免灾难区域部分核心业务中断，造成较大的影响，进而可以大大提高业务资源的利用率，但是由于单个区域容量有限，很难接管灾难区域的全部业务场景，而且目前生产值班人员很难对区域内所有应用群组做到全部了解，很难得到灾难区域的真实的需求容量，从而很难给出精准的业务切换。

为了解决上述问题，本说明书实施例提供一种灾难区域中业务切换策略管理方法，如图1所示，为所述方法的实施环境示意图，a区和b区为两个存在业务共用关系的区域，通过数据采集单元20实时采集a区和b区的运行参数和业务资源，并将采集到的数据保存到服务器40中，参数配置单元30用于配置a区或b区发生灾难时的切换策略，并将所述切换策略保存到服务器40中，控制单元10用于根据具体的数据信息实现相应的切换指令，比如，当a区发生灾难时，控制单元10接收到a区(灾难区域)发生灾难需要切换业务的指令，快速确定b区(目标区域)为接管区域，进一步确定所述灾难区域和所述目标区域共用的至少一个目标应用的至少一个目标业务；然后根据服务器中的数据信息获取所述灾难区域中全部目标业务需求容量和所述目标区域中的剩余容量；根据所述需求容量和所述剩余容量，按照预设的切换策略进行业务切换，以使所述目标区域接管所述灾难区域的全部目标业务。本文能够根据灾难区域和目标区域的实际情况，调整切换策略，提高了对区域级灾难的业务切换管理效率。

具体地，本文实施例提供了灾难区域中业务切换策略管理方法，能够对区域级灾难的业务切换管理效率。图3是本文实施例提供的一种灾难区域中业务切换策略管理方法的步骤示意图，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。具体的如图3所示，所述方法可以包括：

S101：响应业务切换指令，以确定灾难区域和目标区域，所述灾难区域和所述目标区域共用至少一个应用的至少一个业务；

S102：确定所述灾难区域和所述目标区域共用的至少一个目标应用的至少一个目标业务；

S103：获取所述灾难区域中全部目标业务需求容量和所述目标区域中的剩余容量；

S104：根据所述需求容量和所述剩余容量，按照预设的切换策略进行业务切换，以使所述目标区域接管所述灾难区域的全部目标业务。

本说明书实施例，通过在发生区域级灾难时，快速确定存在应用工作关系的灾难区域(被接管区域)和目标区域(接管区域)，然后进一步确定需要接管的至少一个目标应用的至少一个目标业务，并根据计算得到的灾难区域中全部目标业务的需求容量和目标业务的剩余容量之间的关系，结合预设的切换策略实现目标业务的快速接管，本文能够根据实际业务情况调整切换策略，提高区域级灾难业务的处理效率。

可以理解为，当发生区域级灾难时，由于单个区域的全量交易流量很大，很难被接管区域完全接收，为了保证灾难区域的核心业务能正常连续运行，因此可以通过接管灾难区域的部分业务来实现，确保灾难区域的核心权益不受到损害，其中所述灾难区域和所述目标区域为应用共用关系，这样在灾难区域发生灾难时应用不能连续运行时，可以通过所述目标区域接管所述灾难区域，由于共用的关系，所述目标区域中已经部署了共用应用的架构，因此可以实现所述目标区域的快速接管，提高接管的效率和成功率。

需要说明的是，在实际应用中，一个应用可能存在多个区域共用的关系，因此在其中一个区域发生灾难时，可以根据预设的配置信息确定接管区域，比如可以根据各个区域距离灾难区域的远近接管，或者预设的接管顺序接管，在一些其他实施例中，也可以根据其他区域的剩余容量的多少来确定接管顺序，具体的接管规则在本说明书不做限定。

所述目标应用可以为所述灾难区域和所述目标区域共用的应用中重要应用，所述目标业务可以为所述目标应用中的重点业务，这样可以在无法全量接管全部灾难区域的情况下，确保灾难区域的核心业务得到接管，挺高了应对风险的能力，进一步提高了灾难区域的恢复效率。

如图4所示，其中所述目标业务可以通过如下步骤确定：

S201：获取所述灾难区域和所述目标区域共用应用中业务的等级序列；

S202：按照预设等级阈值，确定所述灾难区域和所述目标区域共用的至少一个目标应用的至少一个目标业务。

可以理解为，所述等级序列可以表示业务的重要程度，将所有共用应用中的业务进行重要程度的排序，在发生灾难时，根据该排序从高到低确定相应的业务即为目标业务，这样所述目标业务所在的应用即为目标应用，所述预设等级阈值可以为提前配置的信息，在一些其他实施例中，也可以根据不同的目标区域设置不同的阈值，这样可以根据不同目标区域的特征选择合适数量的目标业务，从而保证业务切换的合理和效率。

在一些其他实施例中，还可以确定应用以及每个应用中业务的重要程度，在业务配置过程中可以提前设置，在具体实施中，可以先确定不同应用中的等级，然后在确定每个应用中的不同业务的等级，在确定目标业务时，可以根据不同应用的等级确定分配比例，得到不同的应用中业务的数量，进而根据每个应用中不同业务的等级确定出目标应用，因此所述目标业务的确定方式在本说明书不做限定。

在本说明书实施例中，如图5所示，所述获取所述灾难区域中全部目标业务需求容量包括：

S301：针对每个所述目标业务，对所述目标业务上的每个预设节点群组进行压测处理，以得到全部预设节点群组的最大交易性能，并将全部预设节点群组中最大交易性能最低的节点群组标记为瓶颈节点群组，其余节点群组标记为关键节点群组；

S302：获取所述关键节点群组的历史交易处理量和所述瓶颈节点群组的历史交易处理量，并根据所述历史交易处理量，计算得到所述关键节点群组相对所述瓶颈节点群组的需求容量需求比例；

S303：根据所述瓶颈节点群组的交易需求容量和所述需求容量需求比例，计算得到每个所述关键节点群组的交易需求容量，其中所述瓶颈节点群组的交易需求容量是通过所述瓶颈节点群组在目标区域中的最大交易性能和当前使用量确定的；

S304：根据所述瓶颈节点群组和所述关键节点群组的交易需求容量，计算得到每个所述目标业务的需求容量，从而得到所述灾难区域中全部目标业务需求容量。

其中，所述节点群组可以为处理每个业务中所涉及的每个微服务，所有微服务按照一定的顺序执行从而实现相应的业务。通过对单一业务场景进行全链路压测，记录各节点群组的交易处理能力TPS。在实际测试中，可以对单一节点群组进行压测，也可以将全链路所有节点群组一起压测，当链路中节点群组变多之后，就会出现不是所有群组都能达到最大性能使用。例如，围成水桶的板子长短不一，而水桶能盛水的最多量取决于最短的板子，而这个板子就是瓶颈。

示例性地，如图2所示，由于a区和b区存在并行共用关系，因此可以对a区或b区任意一个进行预测即可得到两个区共用业务中节点群组的性能，同时结合每个节点群组在业务处理链路上的功能，对其中的节点群组进行标记，比如关键节点群组、瓶颈节点群组和非关键节点群组，在本说明书实施例中，其中预设节点群组可以为关键节点群组和瓶颈节点群组，需要说明的是，上述标记只是针对单一目标业务进行标记。

所述预设节点群组可以为单个业务场景中的主链路节点群组，可以根据实际情况提前配置，这样可以避免将其他非关键节点群组进行接管，从而保证更多的重点应用被接管。

在每个目标业务中，确定了瓶颈节点群组后，相应地，需要确定在目标区域中该瓶颈节点群组还可以扩容的最大值，即为所述瓶颈节点群组的交易需求容量，这样通过该交易需求容量和计算得到的需求比例就可以得到目标区域中其他关键节点群组理论上需要的扩容量，也就是灾难区域中关键节点群组的交易需求容量，最后将目标业务交易链路上的瓶颈节点群组和关键节点群组的交易需求容量之和作为目标业务的需求容量，本文具体到节点群组上计算实际的需求量，从而计算得到准确的扩容需求容量，避免了多余容量的计算。

其中，所述瓶颈节点群组的交易需求容量(在确定的目标业务中的瓶颈节点群组)可以通过如下公式得到：

其中，R

详细的说，任一节点群组的最大交易性能可以通过其后台可承受交易量与日常交易处理能力的比值得到，然后将该最大交易性能与现有该节点群组的占用容量之差作为该节点群组的理论上最大的交易需求容量，由于节点群组在不同群组的交易处理能力不同，因此同一节点群组在不同业务场景(目标业务)中得到的最大的交易需求容量也不同。

示例地，每单一业务场景中关键节点群组的需求比例将通过历史数据进行取模，该业务场景中已知瓶颈节点群组C和任一关键节点群组A：

瓶颈节点群组C单位时间交易总量：T

关键节点群组A单位时间交易总量：T

此业务场景中关键节点群组A需求容量的需求比例：X

如下公式(2)，通过获取N个单位时间关键节点群组A与瓶颈节点群组C的交易比例均值得出A节点群组在此业务场景中需求比例X

其中，X

进一步地，在上述业务场景中关键节点群组A的交易需求容量应为关键节点群组A需求比例乘瓶颈节点群组C的交易需求容量(R

R

R

其中，R

在实际工作中，同一个节点群组可能存在不用的业务场景运行链路上，因此在计算单个节点群组的交易需求容量时，需要考虑不同场景下该节点群组对应的交易需求容量，作为可选地，所述根据所述瓶颈节点群组和所述关键节点群组的交易需求容量，计算得到每个所述目标业务的需求容量，包括：

针对所述目标业务中的任一节点群组A；

当该节点群组A在全部目标业务中至少一次被标记为瓶颈节点群组时，则将该节点群组A在目标区域中的最大交易性能与当前使用量的差值作为该节点群组A的交易需求容量；当该节点群组A在全部目标业务中全部被标记为关键群组时，确定该节点群组A在全部目标业务中的交易需求容量的最大值，并将该最大值和该节点群组A在目标区域中的最大交易性能与当前使用量的差值进行比较，其中较小值作为该节点群组A的交易需求容量；

将所述目标业务上的节点群组的交易需求容量之和作为所述目标业务的需求容量。

可以理解为，所述标记信息可以为关键节点群组或瓶颈节点群组，那么对一个节点群组，可以在不同目标业务的运行链路上，因此只需确定一个交易需求容量即可，这样便于对每个目标业务需求容量的计算，而且该确定的交易需求容量能够完全负荷全部目标业务的需求，同时又不能超过其自身的最大交易性能，避免了满足不了其中较大交易需求的业务。

示例地，可以将任一节点群组A在全部业务场景下确定的唯一交易需求容量为实际需求容量Q

当A存在瓶颈节点群组时：Q

当A全部为关键节点群组时：Q

其中R

因此通过上述步骤，就可以得到全部目标业务中节点群组对应的唯一的交易需求容量(实际交易需求容量)，然后针对每个目标业务，将每个目标业务上的节点群组对应的实际交易需求容量相加得到目标业务的需求容量。

其中需求容量的计算公式可以为：

其中，Y

比如：灾难区域中确定三个目标业务，则每个目标业务的需求容量可以为：

目标业务1需求容量：Y

目标业务2需求容量：Y

目标业务3需求容量：Y

则最后灾难区域的总得需求容量为：Y

需要说明的是，在得到全部目标业务的需求容量过程中，由于单个节点群组可能在多个目标业务的运行链路上，因此可能会对单个节点群组的实际交易需求容量多次叠加，为了进一步减少灾难区域的需求容量，还可以确定全部目标业务中的节点群组数，然后将全部节点群组的实际交易需求容量想加，即可得到全部目标业务的需求容量，这样避免同一节点群组在计算最终的需求容量时多次叠加，从而在保证目标应用中目标业务在接管后能正常运行的基础上，减少了需要接管的需求容量，进而降低了接管的难度。

在本说明书实施例中，所述目标区域中的剩余容量可以通过如下公式得到：

P

其中P

通过上述步骤获得灾难区域需求容量和所述目标区域中的剩余容量，并根据所述需求容量和所述剩余容量关系，按照预设的切换策略实现快速准确的业务切换，作为可选地，如图6所示，可以包括如下步骤：

S401：判断所述剩余容量是否小于所述需求容量；

S402：若所述剩余容量不小于所述需求容量，则控制所述目标区域接管所述灾难区域中的全部目标应用中的全部目标业务；

S403：若所述剩余容量小于所述需求容量，则对所述目标区域现有应用进行缩容处理得到缩容后的剩余容量，直到所述缩容后的剩余容量不小于所述需求容量，则控制所述目标区域接管所述灾难区域中的全部目标应用中的全部目标业务。

可以理解为，当所述剩余容量不小于(即大于等于)所述需求容量时，则说明目标区域可以全部接管所述灾难区域中的全部目标业务，这样就可以控制所述目标区域完成对所述灾难区域的接管，提高其应对风险，快速反应的能力。

而当所述剩余容量小于所述需求容量时，为了保证所述灾难区域中的全部目标业务被接收，还可以对目标区域进行缩容处理，所述缩容处理可以为对目标区域当前占用(现有应用)资源进行缩容，从而可以得到更多的可用容量，作为可选地，如图7所示，所述对所述目标区域进行缩容处理得到缩容后的剩余容量，包括：

S501：确定所述目标区域的缩容对象，所述缩容对象为所述目标区域中的非目标应用和/或非目标业务；

S502：获取所述缩容对象的缩容系数，所述缩容系数是根据所述缩容对象的预设等级确定的；

S503：根据所述缩容系数，对所述缩容对象进行缩容处理，得到缩容量；

S504：根据所述剩余容量和所述缩容量，计算得到缩容后的剩余容量。

其中，所述缩容系数可以根据不同的应用提前设置，在存在资源紧张时，为了保证其他重点应用的正常运行，因此可以对非重点应用(和/或非重点业务)按照缩容系数进行一定程度的缩容处理，不同的应用或业务对应不同的缩容系数，具体地，可以提前设置不同应用或业务的预设等级，该预设等级可以表示应用或业务的重要程度，那么在确定目标应用或目标业务时，就可以对呈现等级分布的非目标应用或业务进行缩容处理，从而增加目标区域的可用容量。

按照缩容系数对缩容对象进行缩容后得到缩容量，所述缩容量可以表示目标区域额外得到的剩余容量，从而结合初始计算得到的剩余容量即可得到缩容后的剩余容量。

需要说明的是，在对缩容对象进行缩容处理后，还应该保证缩容对象的正常运行，这样可以保证目标区域自身业务的正常运行，因此所述缩容系数的设置根据每个缩容对象自身特征设置，比如在该缩容对象进行初始配置时，应用架构人员或开发人员会提前配置一定的缩容系数(比如50％)，然后保存每个应用和缩容系数的映射关系，这样在确定缩容对象(即非目标应用)时，就可以根据每个应用提取相对应的缩容系数，然后进行缩容处理释放容量。

示例性地，获取目标区域中的非目标应用，根据所述非目标应用获得其占用容量以及相应的缩容系数，根据其占用容量和缩容系数就可以计算每个非目标应用的缩容量，进而得到全部非目标应用的缩容量，其中缩容量可以通过如下公式得到：

其中，U

相应地，缩容后的剩余容量即为P

在本说明书实施例中，在目标区域中非目标应用通过缩容系数释放出全部的占用容量(理论上的最大值)时，若缩容后的剩余容量不小于所述灾难区域的需求容量，即可以控制目标区域对灾难区域中全部业务进行接管，但是当缩容后的剩余容量还是小于所述灾难区域的需求容量时，则目标区域还是不能实现对目标业务的全量接管，如图8所示，因此还进一步需要如下步骤：

S601：若缩容后的剩余容量不小于所述需求容量，则控制所述目标区域接管所述灾难区域中的全部目标应用中的全部目标业务；

S602：若缩容后的剩余容量小于所述需求容量，则对所述灾难区域中的全部目标业务进行降级处理得到降级后的需求容量，以使缩容后的剩余容量不小于降级后的需求容量，从而控制所述目标区域接管所述灾难区域中的全部目标应用中的全部目标业务。

可以理解为，由于目标区域无法接受灾难区域中目标业务的全部交易量，而且其自身以没有更多的资源释放，因此可以按照资源可提供的百分比来接管对应百分比的交易量，所述降级处理可以理解为对灾难区域中的目标业务进行“缩容”处理，从而进一步的减少需要接管的容量需求。比如通过计算灾难区域的需求容量是2000个容器，但是目标区域中剩余容量只能达到1000个，那么就需要将服务按照一半进行降级。

因此，所述对所述灾难区域中的全部目标业务进行降级处理得到降级后的需求容量，包括：

根据所述缩容后的剩余容量和所述需求容量，计算得到所述全部目标业务的降级系数；

根据所述降级系数，对所述全部目标业务的需求容量进行降级处理，以获得降级后的需求容量。

通过设置降级系数可以实现对灾难区域中全部目标业务均实现“缩容”处理，从而可以保证全部的目标业务均能被最终接管，提高了灾难切换策略的灵活性和便捷性。

在一些其他实施例中，还可以对呈一定等级顺序的目标业务设置不同的降级系数，会这样可以进一步的保证更重要的业务保留更多的资源，从而保证了灾难区域中更多的核心权益，不同的降级系数的设置在本说明书不做限定，只要能保证降级完成得到的目标业务能全量被目标区域接收即可。

示例性地，所述降级系数可以通过如下公式得到：

其中，V

在得到降级系数后，则最后降级后的需求容量可以为：Y

在本说明书实施例中，还提供一种灾难区域中业务切换策略管理方法，涉及a园区(灾难区域)和b园区(目标区域)，如图9所示，所述方法可以包括如下步骤：

S701：当a园区发生灾难事故，触发园区级切换指令，并确定b园区接管a园区；

S702：计算获得a园区全部目标业务的需求容量Y

S703：判断Y

S704：若Y

S705：若Y

S706：判断Y

S707：若Y

本说明书实施例，在a园区和b园区存在并行共用关系时，在a园区灾难故障时选择不同的切换策略实现b园区的顺利接管，具体为，通过计算a园区中重点业务的需求容量和b园区中剩余容量的比较关系，结合相应地缩容和降级的规则实现了在发生园区级灾难时快速决策和切换，在快速迭代、业务场景逻辑复杂大环境下，参数灵活配置有效提高应对风险、自动调整和快速反应的能力，同时可根据缩容系数和降级系数有效评估业务影响，本文能显著提高了运维自动化效率和水平。

在上述提供的方法基础上，如图10所示，本说明书实施例提供一种灾难区域中业务切换策略管理装置，所述装置包括：

切换指令响应模块100，用于响应业务切换指令，以确定灾难区域和目标区域，所述灾难区域和所述目标区域共用至少一个应用的至少一个业务；

目标业务确定模块200，用于确定所述灾难区域和所述目标区域共用的至少一个目标应用的至少一个目标业务；

计算模块300，用于获取所述灾难区域中全部目标业务需求容量和所述目标区域中的剩余容量；

策略执行模块400，用于根据所述需求容量和所述剩余容量，按照预设的切换策略进行业务切换，以使所述目标区域接管所述灾难区域的全部目标业务。

通过上述装置可以取得的有益效果和上述方法取得的有益效果一致，本说明书不做赘述。

如图11所示，为本文实施例提供的一种计算机设备，所述计算机设备1102可以包括一个或多个处理器1104，诸如一个或多个中央处理单元(CPU)，每个处理单元可以实现一个或多个硬件线程。计算机设备1102还可以包括任何存储器1106，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器1106可以包括以下任一项或多种组合：任何类型的RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备1102的固定或可移除部件。在一种情况下，当处理器1104执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备1102可以执行相关联指令的任一操作。计算机设备1102还包括用于与任何存储器交互的一个或多个驱动机构1108，诸如硬盘驱动机构、光盘驱动机构等。

计算机设备1102还可以包括输入/输出模块1110(I/O)，其用于接收各种输入(经由输入设备1112)和用于提供各种输出(经由输出设备1114))。一个具体输出机构可以包括呈现设备1116和相关联的图形用户接口(GUI)1118。在其他实施例中，还可以不包括输入/输出模块1110(I/O)、输入设备1112以及输出设备1114，仅作为网络中的一台计算机设备。计算机设备1102还可以包括一个或多个网络接口1120，其用于经由一个或多个通信链路1122与其他设备交换数据。一个或多个通信总线1124将上文所描述的部件耦合在一起。

通信链路1122可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路1122可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。

对应于图3-图9中的方法，本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。

本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图3至图9所示的方法。

应理解，在本文的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本文实施例的实施过程构成任何限定。

还应理解，在本文实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本文所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的目的。

另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本文中应用了具体实施例对本文的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本文的方法及其核心思想；同时，对于本领域的一般技术人员，依据本文的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本文的限制。