CN115225487A - 一种入云业务的开通方法及装置 - Google Patents

Abstract

本申请公开了一种入云业务的开通方法及装置，涉及网络自动化技术领域，用于提高入云业务的开通成功率。该方法包括：接收客户端设备发送的针对入云业务的开通请求后，确定该开通请求对应的资源池，进而在资源池包含的全部处理设备中存在至少一个处理设备可用时，使用可用的至少一个处理设备执行入云业务的开通操作，并在开通成功后向客户端设备返回开通成功的响应消息。该方案中，即使资源池中存在不可用的处理设备，也能通过可用的处理设备为用户开通入云业务，如此可提高用户入云业务的开通成功率，有效提高用户的开通体验。

Description

一种入云业务的开通方法及装置

技术领域

本申请涉及网络自动化技术领域，尤其涉及一种入云业务的开通方法及装置。

背景技术

目前，大部分的云骨干业务管控系统将软件定义网络(software definenetwork，SDN)控制器作为系统核心，接收入云业务的请求，从而实现业务自动化。而处理设备则是云骨干网的核心网元，承载了大量业务流量，具有业务类型多、操作频繁的特点。

然而，在处理入云业务的开通请求时，现有的云骨干业务管控系统在处理流程上存在局限性，导致用户的开通成功率较低，不利于提高用户的开通体验。基于此，目前亟需一种入云业务的开通方法，用以提高用户的开通成功率。

发明内容

本申请提供了一种入云业务的开通方法及装置，用以解决提高用户入云业务的开通成功率。

第一方面，本申请提供了一种入云业务的开通方法，该方法适用于入云业务的开通装置，该装置示例性地可以是云骨干业务管控系统中的控制器，该方法包括：控制器接收客户端设备发送的开通请求，根据开通请求确定对应的资源池，当资源池包含的全部处理设备中存在至少一个处理设备可用时，控制器使用可用的至少一个处理设备执行入云业务的开通操作，若入云业务开通成功，则向客户端设备发送开通成功的响应消息。

上述技术方案中，接收到开通请求并确定对应的资源池后，只要资源池中有一台处理设备可用，就可以处理开通请求，而无需要求资源池中的所有处理设备都可用才能处理开通请求，能有效提高用户入云业务的开通成功率，进而有助于提高用户的开通体验。

一种可能的设计中，当资源池包含的全部处理设备中存在不可用的第一处理设备时，控制器还可以建立第一处理设备对应的数据待恢复操作表，进而在使用可用的至少一个处理设备执行入云业务的开通操作时，将执行入云业务的开通操作所涉及到的业务操作数据添加至数据待恢复操作表，并在确定第一处理设备恢复至可用状态后，根据数据待恢复操作表恢复第一处理设备中的业务数据库。

在上述设计中，在不可用的设备恢复可用状态后，通过对其数据进行同步，能使得资源池中的所有设备数据保持一致，进而该不可用的设备也能使用最新的业务数据处理后续业务，有助于提高业务处理的准确性。

一种可能的设计中，控制器在使用可用的至少一个处理设备执行入云业务的开通操作时，具体可以先使用预设的配置参数配置开通模型，再使用开通模型与可用的至少一个处理设备进行交互，进而在交互失败的情况下，使用开通模型重新与可用的至少一个处理设备进行交互，之后，若交互成功，则可确定入云业务开通成功。

一种可能的设计中，在与至少一个处理设备交互失败后，控制器还可以先将交互失败的设备信息与配置信息添加到修复队列，再调用修复队列中的设备信息与配置信息，修复配置线程，之后基于修复后的配置线程，使用开通模型重新与可用的至少一个处理设备进行交互。

一种可能的设计中，控制器在使用可用的至少一个处理设备执行入云业务的开通操作时，控制器内还可以维护一张以用户身份标示号(identity document,id)+网元管理地址(intellectual property,ip)为主键的配置表。具体可以先使用预设的配置参数配置开通模型，再使用开通模型与可用的至少一个处理设备进行交互，在交互阶段，没下发一批配置均在数据库中记录各配置的关键字和处理设备的状态(成功/失败)，配置恢复阶段会从数据表中读取对应处理设备与用户的配置表。若交互失败，则重新使用开通模型与可用的至少一个处理设备进行交互，若交互成功，则确定开通请求处理成功。通过该设计，避免了控制器因一次交互失败而导致入云业务开通失败的情况。

一种可能的设计中，控制器在确定开通模型与可用的至少一个处理设备交互失败后，记录失败状态后继续进行下一批配置项。当入云业务开通成功后给上层返回配置成功，同时将交互失败的设备信息与配置信息添加到修复队列，调用修复队列中的设备信息与配置信息，自动修复配置线程，进而基于修复后的配置线程，使用开通模型重新与可用的至少一个处理设备进行交互。

其中，本申请提供自动修复配置的次数可以由本领域技术人员按照经验进行设置，比如可以设置为3。若依然配置失败，则将消息加入失败队列，推送给运维人员手动修复。

一种可能的设计中，控制器在确定开通模型与可用的至少一个处理设备交互成功后，当出现用户流量不通时，则由告警系统将故障现象推送给运维人员，由运维人员手动触发恢复功能。

在上述设计中，提供了一种自动对处理设备上基于用户级配置的快速恢复方法，配置恢复的触发方式可分为自动触发和运维人员触发两种。有针对性地修复入云业务开通过程中出现的配置故障现象，而不会影响其他如云业务的开通。系统自动修复取代了原有的人工修复，运维人员不再需要登陆设备通过手动输入命令行进行配置恢复，只需要在调用修复接口即可完成一键恢复业务。如此，将修复故障的时间成本压缩至最低，运维人员可以将更多的精力集中在问题分析层面。

第二方面，本申请提供了一种入云业务的开通装置，该装置包括：

收发单元，用于接收客户端设备发送的针对于入云业务的开通请求；

确定单元，用于确定开通请求对应的资源池；

处理单元，用于当资源池包含的全部处理设备中存在至少一个处理设备可用时，使用可用的至少一个处理设备执行入云业务的开通操作。

收发单元，还用于：

若入云业务开通成功，则向客户端设备发送开通成功的响应消息。

一种可能的设计中，当资源池包含的全部处理设备中存在不可用的第一处理设备时，处理单元还可以建立第一处理设备对应的数据待恢复操作表，进而在使用可用的至少一个处理设备执行入云业务的开通操作时，将执行入云业务开通操作所涉及到的业务操作数据添加至数据待恢复操作表，并在确定第一处理设备恢复至可用状态后，根据数据待恢复操作表恢复第一处理设备中的业务数据库。

一种可能的设计中，处理单元在使用可用的至少一个处理设备执行入云业务的开通操作时，具体可以先使用预设的配置参数配置开通模型，再使用开通模型与可用的至少一个处理设备进行交互，在交互失败的情况下，重新使用开通模型与可用的至少一个处理设备进行交互，若交互成功，则确定开通请求处理成功。

一种可能的设计中，处理单元在与开通模型交互失败后，记录失败状态后继续进行下一批配置项。当入云业务开通成功后给上层返回配置成功，同时可以将交互失败的设备信息与配置信息添加到修复队列，调用修复队列中的设备信息与配置信息，自动修复配置线程，进而基于修复后的配置线程，使用开通模型重新与可用的至少一个处理设备进行交互。

一种可能的设计中，确定单元在确定处理单元在与开通模型交互成功后，当出现用户流量不通的情况时，则由告警系统将故障现象推送给运维人员，由运维人员手动触发恢复功能。

在上述设计中，对于用户而言，将向南配置失败在很大程度上对用户屏蔽，由控制系统内部进行自动修复，多层次的保护用户的入云业务开通过程不中断；对于服务提供商而言，多层次保护增加了系统稳定性，同时自动与手动结合的业务恢复方案使运维自动化程度有了较大的提升。发生故障时，如果是配置失败则可以直接由系统完成自动修复；如果是流量不通则由运维人员调用接口进行一键修复。如此可以将运维的时间成本压缩到最低，相关人员可以集中时间在故障的分析和解决上面。

第三方面，本申请还提供一种计算设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行上述基于入云业务开通的方法。

第四方面，本申请还提供一种计算机可读非易失性存储介质，包括计算机可读指令，当计算机读取并执行所述计算机可读指令时，使得计算机执行上述基于入云业务开通的方法。

第五方面，本申请还提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面的各种可能的设计所述的方法。

本申请的这些实现方式或其他实现方式在以下实施例的描述中会更加简明易懂。

附图说明

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

图1为本申请实施例提供的一种适用的系统架构图；

图2为本申请实施例提供的一种入云业务的开通方法流程图；

图3为本申请实施例提供的一种数据同步方法的流程示意图；

图4为本申请实施例提供的一种入云业务的开通方法的完整流程示意图；

图5为本申请实施例提供的一种适用的管控系统架构图；

图6为本申请实施例提供的一种入云业务的开通装置的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

图1示例性地示出本申请实施例提供的一种适用的系统架构图，如图1所示，该系统架构中可以包括客户端设备110、控制器120和至少一个资源池，例如资源池130和资源池140。其中，客户端设备110示例性地可以是用户的笔记本电脑、手机、台式机等。控制器120可以是具有控制能力的任意器件，诸如可以是微控制器(micro controller unit，MCU)，还可以是可编程控制器(programmable logic device，PLD)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件及其他集成芯片。处理设备可以是具有处理能力的任意设备，诸如服务器。

继续参照图1所示，资源池130中可以包括主处理设备131和备处理设备132。资源池130被配置为主备模式，即默认情况下使用主处理设备131处理业务，在主处理设备131不可用时切换至备处理设备132处理业务。相应地，资源池140中可以包括处理设备141、处理设备142、……、处理设备14N，N为大于或等于2的正整数。其中，资源池140被配置为多活模式，即使用处理设备141、处理设备142、……、处理设备14N处理同一个业务。应理解，资源池所配置的处理模式可以是本领域技术人员根据项目需求与资源池底层网络架构情况预先部署在资源池中的，且每个资源池和处理模式的对应关系可预存储在控制器120中，比如可以是资源池中的处理设备部署成功后由处理设备自动上报给控制器120中的，也可以是本领域技术人员在部署完成后手动添加在控制器120中的，本申请实施例对此不作具体限定。

继续参照图1所示，客户端设备110连接控制器120，控制器120连接任一资源池中的全部处理设备，如资源池130中的主处理设备131和备处理设备132、以及资源池140中的处理设备141、处理设备142、……、和处理设备14N。其中，连接关系可以为有线连接，也可以无线连接，本申请实施例对此不作具体限定。

一种具体的应用场景中，图1所示意的系统具体可以是云骨干业务系统。该情况下，控制器120具体可以为云骨干业务系统中的SDN控制器，上述各个处理设备具体可以是云骨干业务系统中的云网关设备。此外，需要理解的是，图1所示意的系统中除了可以包括上述各个设备外，还可以包括其它设备，比如交换机、处理器等，本申请实施例对此也不作限定。

基于图1所示意的系统架构图，图2示例性示出本申请实施例提供的一种入云业务的开通方法的流程示意图，如图2所示，该方法包括：

步骤201，控制器接收客户端设备发送的入云业务开通请求。

本申请实施例中，用户在想要开通入云业务时，可以在客户端设备110上输入开通请求，进而由客户端设备110基于与控制器120的连接关系，向控制器120转发该开通请求。

步骤202，控制器确定开通请求对应的资源池。

本申请实施例中，开通请求中可以包括客户端设备110的标识和其他一些信息，比如资源池的标识，以便于控制器据此确定该开通请求对应的资源池。举例来说，当资源池以地域命名时，开通请求中可以携带客户端设备110所属的地域名称，例如假设资源池130为上海资源池，资源池140为内蒙古资源池，则控制器110如果接收到上海的用户发送的开通请求，则可以确定其对应上海资源池。

步骤203，控制器判断资源池包含的全部处理设备中是否存在至少一个处理设备可用，若是，则执行步骤204，若否，则执行步骤206。

步骤204，控制器使用可用的至少一个处理设备处理开通请求。

步骤205，控制器确定开通请求处理成功后，向客户端设备发送开通成功的响应消息。

步骤206，控制器向客户端设备发送开通失败的响应消息。

本申请实施例中，针对于相连的任一处理设备，控制器120还可以监控该处理设备的状态，状态包括可用状态和不可用状态。其中，监控方式示例性地可以是：控制器120向处理设备按照预设的计时时间周期发送心跳包，在每个周期内，若预设的计时时间内未接收到处理设备的响应，则确定该处理设备处于不可用状态，反之则确定该处理设备处于可用状态。

进一步地，控制器120在确定请求消息对应的资源池后，可以先确定该资源池中包含的全部处理设备，然后根据监控的内容确定全部处理设备中是否存在处于可用状态的处理设备。当存在至少一个可用状态的处理设备时，则可以按照该资源池所配置的处理模式调用处于可用状态的处理设备执行入云业务的开通操作。当全部的处理设备都不可用时，确定该资源池无法执行入云业务的开通操作，进而控制器120可通过与客户端设备110的交互告知用户开通失败的响应消息。

举例来说，假设资源池130为上海资源池，资源池140为内蒙古资源池：

一个示例中，假设入云业务的开通请求对应的资源池为上海资源池，而上海资源池配置为主备模式，则在主处理设备131的状态为可用的情况下，控制器120调用主处理设备131进行入云业务的开通操作，开通成功后向客户端110发送开通成功的响应消息。若主处理设备131的状态为不可用，即备处理设备132在超时时间内没有收到主处理设备131的VRRP报文，则将入云业务的开通请求切到备处理设备，由备处理设备132执行入云业务的开通操作，待主处理设备131的状态恢复可用时，备处理设备132再将所执行的入云业务的开通操作切回到主处理设备131。其中，备处理设备132可以为一个，也可以为多个。主处理设备131和备处理设备132之间可通过虚拟路由器冗余协议(virtual router redundancyprotocol,VRRP)进行保活，具体地，即将隧道端点(vxlan tuunnel end point,vtep)的ip作为VRRP的虚ip，通过虚ip漂移控制虚拟扩展局域网(virtual extensible local areanetwork,vxlan)隧道的通断，使得正常场景下入云业务的开通流程均经过主处理设备131，一旦主处理设备131的状态不可用(即备处理设备132在超时时间内收不到主处理设备131的VRRP报文)，则使得入云业务的开通流程经过备处理设备132。示例性地，当备处理设备132有多个时，还可根据不同备处理设备的优先级选举出新的主处理设备，进而使得入云业务的开通流程经过新的主处理设备。之后，当主处理设备131的状态恢复至可用时，又会重新成为主处理设备，vtep-ip也会随着主处理设备与备处理设备相关切换进行自动配置与删除。

另一个示例中，假设入云业务的开通请求对应的资源池为内蒙古资源池，而内蒙古资源池配置为多活模式，则控制器120可以将入云业务的开通请求分摊至处理设备141～14N中的每一台可用的处理设备，以实现负载均衡。比如当处理设备141的状态为不可用时，则控制器120可将入云业务的开通请求重新分摊至其余处理设备中(处理设备142、……和处理设备14N)，继续进行入云业务开通。按照上述操作，将几台处理设备虚拟成一个整体进行流量转发，若部分处理设备状态为不可用时，则不会影响业务的正常开通和使用。

进一步示例性地，当存在可用的处理设备时，控制器120可以按照如下方式处理开通请求：首先，控制器120使用预设的配置参数配置开通模型，之后，使用开通模型与可用的处理设备进行交互，若交互成功，则确定开通请求处理成功，进而可以向客户端设备110发送开通成功的响应消息，若交互失败，则可以使用开通模型重新与可用的处理设备进行交互，若在预设的重试次数内交互成功，则也可以确定开通请求处理成功，进而向客户端设备发送开通成功的响应消息，若直至预设的重试次数还未交互成功，则确定开通请求处理失败，进而向客户端设备返回开通失败的响应消息。其中，预设的重试次数可以由本领域技术人员按照经验进行设置，比如可以设置为3，如此，相比于一次失败即向客户端设备反馈开通失败的方式来说，既能够通过多次重试在用户不感知的情况下提高开通的成功率，又不至于重试次数过多而耽误开通。

进一步示例性地，在控制器120与可用的处理设备交互失败的情况下，控制器120可以将交互失败的设备信息与配置信息添加到修复队列，在通过重试的方式继续开通操作时，调用修复队列中的设备信息与配置信息修复配置线程，进而基于修复后的配置线程，使用开通模型重新与可用的至少一个处理设备进行交互。相比于一次失败即回滚删除的方案来说，该方式只需要重新交互，而无需重新配置模型，如此可降低系统与网元的开销，缩短控制器接口的响应时间。此外，修复队列中存储的是设备信息与配置信息的对应关系，而设备信息可以包括客户端设备的信息和交互失败的处理设备的信息，也即使，该修复方式能以用户为粒度进行修复，从而应对更多异常情况下的网络设备故障问题，多层次保护用户业务流量不中断，提升用户可感知的业务开通成功率。

本申请实施例中，控制器120除了可以通过以上述用户粒度恢复配置以外，还可以进行全局恢复配置。具体来说，当全局性的配置混乱，或者系统版本升级后更新配置时，控制器120可以通过重置命令清空处理设备上的配置数据并重启，待处理设备重新可用时，拉取数据库中所有与此处理设备相关的业务数据，进而重新进行业务下发。应理解，该全局配置也可以有运维人员通过操作控制器120实现，本申请实施例对此不作具体限定。

本申请实施例中，当资源池包含的全部处理设备中存在不可用的第一处理设备时，控制器还可以在使用可用的处理设备执行入云业务的开通操作的同时，记录开通操作数据，进而在第一处理设备的状态恢复至可用时更新其入云业务的开通操作数据。为便于理解，图3示出本申请实施例提供的一种数据同步方法的流程示意图，该流程可以由控制器执行，如上述图1中的控制器120。如图3所示，该方法包括：

步骤310，控制器建立第一处理设备对应的数据待恢复操作表。

步骤320，控制器在使用可用的至少一个处理设备执行入云业务的开通操作时，将执行入云业务的开通操作所涉及到的业务操作数据添加至数据待恢复操作表。

本申请实施例中，控制器120中可以维护有一张数据待恢复操作表，当控制器120监听到处理设备的状态为不可用时，将入云业务开通请求的操作(包括但不限于增、改、删)和关键字(诸如业务id、业务参数和操作时间等)作为一条数据更新数据待恢复操作表。

进一步地，在处理设备不可用期间，用户可能会对同一条业务进行不同类型的操作，为避免这一系列操作相互影响出现配置缺失或冗余配置的问题出现，控制器120可以根据操作类型不同，而采用不同的记录策略来更新数据待恢复操作表，举例来说：

更新方式一，当同一个处理设备在不可用期间进行了先增后删的操作，则这两次操作相互抵消，不做记录。

更新方式二，当同一个处理设备在不可用期间对同一条入云业务的同一属性进行了多次更新(比如带宽值)，则数据待恢复操作表中的数据更新至最后一次操作的值。

步骤330，控制器确定第一处理设备恢复至可用状态后，根据数据待恢复操作表恢复第一处理设备中的业务数据库。

本申请实施例中，当控制器120监听到处理设备的状态为可用时，控制器120可以触发预设的配置恢复功能，在该功能下，控制器120会根据处理设备不可用期间数据待恢复操作表中记录的操作时间，按照顺序对处理设备进行重新配置。

下面举一个具体的例子介绍上述数据同步方法。

客户端设备向控制器发送入云业务开通请求，假设控制器监听到第一处理设备的状态为不可用时，则控制器通过检测到的至少一个可用处理设备执行入云业务的开通操作，并将执行入云业务的开通操作数据添加至数据待恢复操作表。在入云业务的开通过程中，具体操作如下：

当某一处信息需要填写的数据为“123”，而客户端设备填写的是“1234”，此时客户端设备需要将“4”删除，此时数据待恢复操作表不做记录；

当某一处信息需要填写“是”，而客户端设备填写的是“否”，此时客户端设备需要将其改为“是”，此时数据待恢复操作表不做记录；

当客户端设备对其业务中的带宽值进行4次更新，那么数据待恢复操作表只记录第4次更新后的带宽值。

按照上述操作，客户端设备在第一处理设备不可用期间的一系列入云业务的操作都会记录在数据待恢复操作表中。之后，当控制器监听到第一处理设备的状态为可用时，控制器将数据待恢复操作表中记录的入云业务的开通数据恢复到第一处理设备中。

基于上述过程，能够保障当第一处理设备不可用时，仍然可以处理入云业务的开通请求，进一步实现了设备高可用，同时还提高了用户入云业务的开通率。

为了便于理解本方案，图4示例性示出本申请实施例提供的一种入云业务开通方法的完整流程示意图。

如图4所示，具体步骤包括：

步骤400，控制器接收客户端设备发送的针对于入云业务的开通请求。

步骤410，控制器确定开通请求对应的资源池。

在上述步骤410中，控制器在确定资源池之前，还可以先对开通请求进行参数校验，即确定开通请求的格式及携带的内容是否满足预设的要求。若是，则确定该开通请求是合法的，进而控制器可以构建针对于入云业务的业务模型，并确定开通请求对应的资源池。若否，则确定该开通请求是非法的，进而控制器可以向客户端设备返回非法入参的提示消息，以便于客户端设备能重新输入正确的开通请求。

步骤420，控制器校验资源池中的全部处理设备。

在上述步骤420中，针对于资源池中的任一处理设备，控制器可以校验该处理设备的状态是否可用，并判断网卡配置是否正确。若处理设备可用且网卡配置正确，则该处理设备校验成功，控制器可继续校验下一处理设备。反之，若处理设备不可用，或者网卡配置不正确，则该处理设备校验失败，控制器可建立该处理设备对应的数据待恢复操作表，后续可使用该表记录业务开通过程中的业务数据，并在处理设备恢复正常后，根据该表恢复处理设备中的业务数据库。待控制器交验完资源池中的全部处理设备后，执行步骤430。

步骤430，控制器通过调用校验成功的处理设备，使用预设的配置参数构建开通模型，若开通模型构建失败，则执行步骤440，若开通模型构建成功，则执行步骤450。

在上述步骤430中，若资源池对应主备模式，则：在主处理设备校验成功的情况下，控制器调用主处理设备构建开通模型，在主处理设备校验失败但备处理设备校验成功的情况下，控制器调用备处理设备构建开通模型。若资源池对应多活模式，则控制器可以调用校验成功的全部处理设备构建开通模型，以便充分利用多个设备并发进行业务拆解操作，提高开通模型的构建效率。

步骤440，控制器接收处理设备返回的开通模型构建失败的提示消息，回滚残留数据，以便基于残留数据重新构建开通模型。

步骤450，控制器使用开通模型与校验成功的处理设备进行交互，若交互失败，则转至步骤460，若成功，则转至步骤470。

在上述步骤450中，若资源池对应主备模式，则：在主处理设备校验成功的情况下，控制器与主处理设备进行交互，在主处理设备校验失败但备处理设备校验成功的情况下，控制器与备处理设备进行交互。若资源池对应多活模式，则控制器可以与校验成功的每个处理设备进行交互，以便充分利用多个设备并发进行设备级的配置操作，提高业务开通的开通效率。

步骤460，控制器修复配置线程，基于修复后的配置线程，重新执行步骤450。

在上述步骤460中，控制器可以将交互失败的设备信息与配置信息添加到修复队列，并调用修复队列中的设备信息与配置信息修复配置线程，进而基于修复后的配置线程，重新使用开通模型与校验成功的处理设备进行交互，若交互成功，则执行步骤470，若仍交互失败，则继续修复配置线程并重新交互，直至交互的次数达到预设次数是，若还未交互成功，则确定业务开通失败，控制器可以向后台告警系统推送告警消息，以便于运维人员排除故障。

步骤470，入云业务开通成功，控制器向客户端设备发送业务开通成功的响应消息。

基于上述过程，本申请提出的一种入云业务的开通方法对于用户而言，将南向配置失败在很大程度上对用户屏蔽，由控制系统内部进行自动修复，多层次的保护用户的入云业务开通过程不中断。对于服务提供商而言，多层次的保护并提高系统的稳定性，同时自动与手动结合的业务恢复方案使运维自动化程度有了较大的提升。发生故障时，如果是配置失败则可以直接由系统完成自动修复，如果是流量不通则由运维人员调用接口进行一键修复，如此可以将运维的时间成本压缩到最低，相关人员可以集中时间在故障的分析和解决上面。

基于图4所示意的流程图，图5进一步示出本申请实施例提供的一种具体的系统架构示意图，如图5所示，该系统中包括：

客户端设备110、控制器120、业务层510、配置层520、协议层530、日志记录540和数据库550。

其中，业务层510中包括三个部分，第一部分包括设备管理511、客户管理512和资源池管理513，第二部分包括入云514、组网515和互联516,第三部分包括离线恢复517、用户业务恢复518和全局业务恢复519。当控制器120接收客户端设备110发送的入云业务的开通请求后，依次将其发送至业务层、配置层和协议层进行一系列入云业务的开通操作。同时将入云业务的开通过程中的操作信息添加至日志记录540中。入云业务的开通过程中是根据数据库550进行的，数据库550可以包括MS SQL 551和Redis 552。

客户端设备110连接控制器120，控制器120连接业务层510，业务层510连接配置层520，配置层520连接协议层530。其中，连接关系可以为有线连接，也可以无线连接，本申请实施例对此不作具体限定。

针对上述方法流程，本申请实施例还提供一种入云业务的开通装置，该装置的具体内容可以参照上述方法实施。

图6示例性的示出了本申请实施例提供的一种入云业务开通装置的结构示意图。

如图6所示，该装置具体包括：

收发单元610，用于接收客户端设备发送的针对入云业务的开通请求；

确定单元620，用于根据开通请求确定对应的资源池；

处理单元630，用于当资源池包含的全部处理设备中存在至少一个处理设备可用时，使用可用的至少一个处理设备执行入云业务的开通操作；

收发单元610，还用于若入云业务开通成功，则向客户端设备发送开通成功的响应消息。

一种可选地实施方式中，处理单元630还可以在第一处理设备状态不可用时，将入云业务开通请求的操作，作为数据添加至数据待恢复操作表中，当第一处理设备状态为可用时，再将数据待恢复操作表中的数据恢复到第一处理设备。

一种可选地实施方式中，处理单元630还可以自动修复入云业务开通过程中存在的故障。

一种可选地实施方式中，处理单元630具体用于：

使用预设的配置参数配置开通模型，再使用开通模型与可用的至少一个处理设备进行交互，若交互失败，则重新使用开通模型与可用的至少一个处理设备进行交互，若交互成功，则确定开通请求处理成功。

一种可选地实施方式中，所述处理单元630在确定交互失败后，使用开通模型重新与可用的至少一个处理设备进行交互之前，还用于：

将交互失败的设备信息与配置信息添加到修复队列，调用修复队列中的所述设备信息与配置信息，自动修复配置线程，基于修复后的配置线程，使用开通模型重新与可用的至少一个处理设备进行交互。

本申请的上述实施例提供了一种入云业务的开通方法，包括：控制器接收客户端设备发送的开通请求，根据开通请求确定对应的资源池，当所述资源池包含的全部处理设备中存在至少一个处理设备可用时，控制器使用所述可用的至少一个处理设备处理所述开通请求，若所述开通请求处理成功，则向所述客户端设备发送开通成功的响应消息。上述技术方案中，接收到开通请求并确定对应的资源池后，只要资源池中有一台处理设备可用，就可以处理开通请求，而无需要求资源池中的所有处理设备都可用才能处理开通请求，能有效提高用户入云业务的开通率，进而有助于提高用户的开通体验。

基于相同的技术构思，本申请实施例还提供了一种计算设备，包括：

存储器，用于存储程序指令；

处理器，用于调用存储器中存储的程序指令，按照获得的程序执行上述入云业务的开通方法。

基于相同的技术构思，本申请实施例还提供了一种计算机可读非易失性存储介质，包括计算机可读指令，当计算机读取并执行计算机可读指令时，使得计算机执行上述入云业务的开通方法。

基于相同的技术构思，本申请实施例还提供了一种计算机程序产品，包括计算机可读指令，当计算机读取并执行计算机可读指令时，使得计算机执行上述入云业务的开通方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种入云业务的开通方法，其特征在于，所述方法包括：

接收客户端设备发送的针对于入云业务的开通请求；

确定所述开通请求对应的资源池；

当所述资源池包含的全部处理设备中存在至少一个处理设备可用时，使用所述可用的至少一个处理设备执行所述入云业务的开通操作；

若所述入云业务开通成功，则向所述客户端设备发送开通成功的响应消息。

2.如权利要求1所述的开通方法，其特征在于，当所述资源池包含的全部处理设备中存在不可用的第一处理设备时，所述方法还包括：

建立所述第一处理设备对应的数据待恢复操作表；

在使用所述可用的至少一个处理设备执行所述入云业务的开通操作时，将执行所述入云业务的开通操作所涉及到的业务操作数据添加至所述数据待恢复操作表；

确定所述第一处理设备恢复至可用状态后，根据所述数据待恢复操作表恢复所述第一处理设备中的业务数据库。

3.如权利要求1或2所述的开通方法，其特征在于，所述使用所述可用的至少一个处理设备执行所述入云业务的开通操作，包括：

使用预设的配置参数配置开通模型；

使用所述开通模型与所述可用的至少一个处理设备进行交互；

在交互失败的情况下，使用所述开通模型重新与所述可用的至少一个处理设备进行交互，若交互成功，则确定所述入云业务开通成功。

4.如权利要求3所述的开通方法，其特征在于，所述交互失败后，使用所述开通模型重新与所述可用的至少一个处理设备进行交互之前，所述方法还包括：

将交互失败的设备信息与配置信息添加到修复队列；

调用所述修复队列中的所述设备信息与配置信息，修复配置线程；

所述使用所述开通模型重新与所述可用的至少一个处理设备进行交互，包括：

基于修复后的所述配置线程，使用所述开通模型重新与所述可用的至少一个处理设备进行交互。

5.一种入云业务的开通装置，其特征在于，所述开通装置包括：

收发单元，用于接收客户端设备发送的针对于入云业务的开通请求；

确定单元，用于确定所述开通请求对应的资源池；

处理单元，用于当所述资源池包含的全部处理设备中存在至少一个处理设备可用时，使用所述可用的至少一个处理设备执行所述入云业务的开通操作；

所述收发单元，还用于若所述入云业务开通成功，则向所述客户端设备发送开通成功的响应消息。

6.如权利要求5所述的开通装置，其特征在于，当所述资源池包含的全部处理设备中存在不可用的第一处理设备时，所述处理单元还用于：

建立所述第一处理设备对应的数据待恢复操作表；

在使用所述可用的至少一个处理设备执行所述入云业务的开通操作时，将执行所述入云业务的开通操作所涉及到的业务操作数据添加至所述数据待恢复操作表；

确定所述第一处理设备恢复至可用状态后，根据所述数据待恢复操作表恢复所述第一处理设备中的业务数据库。

7.如权利要求5所述的开通装置，其特征在于，所述处理单元具体用于：

使用预设的配置参数配置开通模型；

使用所述开通模型与所述可用的至少一个处理设备进行交互；

在交互失败的情况下，使用所述开通模型重新与所述可用的至少一个处理设备进行交互，若交互成功，则确定所述入云业务开通成功。

8.如权利要求7所述的开通装置，其特征在于，所述处理单元在确定交互失败后，使用所述开通模型重新与所述可用的至少一个处理设备进行交互之前，还用于：

将交互失败的设备信息与配置信息添加到修复队列；

调用所述修复队列中的所述设备信息与配置信息，修复配置线程；

所述处理单元具体用于：

基于修复后的所述配置线程，使用所述开通模型重新与所述可用的至少一个处理设备进行交互。

9.计算设备，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行如权利要求1至4中任一项所述的方法。

10.计算机可读非易失性存储介质，其特征在于，包括计算机可读指令，当计算机读取并执行所述计算机可读指令时，使得计算机执行如权利要求1至4中任一项所述的方法。

Images