本发明涉及网络通信技术领域，尤其涉及一种软件升级方法及装置。
背景技术
在运营商和数据中心等关键业务使用场景的网络中，要求网络设备具备极高的业务不间断服务能力，具有高可靠性。
目前，网络设备的软件复杂度越来越高，运维中解决软件bug(漏洞)和增加新功能，都需要对软件进行升级。软件升级过程往往导致业务中断，给运营商和数据中心基础设施提供商，以及最终用户带来体验下降和直接经济损失。
issu(inservicesoftwareupgrade，不间断软件升级)技术是一种在线升级软件并保证业务不断的关键手段。
目前，当网络设备通过issu技术进行软件升级时，在软件升级过程中，网络设备的转发平面保持不变，但控制平面需要进行重启，该重启过程最快也是分钟级别，将导致控制平面长时间不可用，进而可能引起业务震荡。
技术实现要素：
本发明提供一种软件升级方法及装置，以解决网络设备通过issu技术进行软件升级时会出现控制平面长时间不可用的问题。
根据本发明实施例的第一方面，提供一种软件升级方法，应用于网络设备，所述网络设备上搭建有至少一个第一类型容器，所述第一类型容器用于业务运行，该方法包括：
接收针对目标第一类型容器中的目标应用的不间断软件升级指令；
创建对应所述目标第一类型容器的目标第二类型容器，并控制所述目标第一类型容器与所述目标第二类型容器进行配置和状态数据同步；其中，所述目标第二类型容器与所述目标第一类型容器运行有相同的应用，且所述目的第二类型容器中运行的所述目标应用的软件版本为升级后的版本，所述目标第二类型容器的初始状态为备用状态，备用状态的容器不进行转发层面控制；
当确定配置和状态数据同步完成时，控制所述目标第一类型容器切换为备用状态，以及所述目标第二类型容器切换为活跃状态。
根据本发明实施例的第二方面，提供一种软件升级装置，应用于网络设备，所述网络设备上搭建有至少一个第一类型容器，所述第一类型容器用于业务运行，其特征在于，该装置包括：
接收单元，用于接收针对目标第一类型容器中的目标应用的不间断软件升级指令；
创建单元，用于创建对应所述目标第一类型容器的目标第二类型容器；其中，所述目标第二类型容器与所述目标第一类型容器运行有相同的应用，且所述目的第二类型容器中运行的所述目标应用的软件版本为升级后的版本，所述目标第二类型容器的初始状态为备用状态，备用状态的容器不进行转发层面控制；
控制单元，用于控制所述目标第一类型容器与所述目标第二类型容器进行配置和状态数据同步；
所述控制单元，还用于当确定配置和状态数据同步完成时，控制所述目标第一类型容器切换为备用状态，以及所述目标第二类型容器切换为活跃状态。
根据本发明实施例的第三方面，提供一种软件升级装置，包括处理器和机器可读存储介质，所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令，所述处理器被所述机器可执行指令促使执行上述软件升级方法。
根据本发明实施例的第四方面，提供一种机器可读存储介质，存储有机器可执行指令，在被处理器调用和执行时，所述机器可执行指令促使所述处理器执行上述软件升级方法。
应用本发明实施例，通过将业务进程装入容器，当容器中的应用需要进行issu升级时，创建与该容器运行有相同应用，且应用的软件版本为升级后的版本的备用状态的容器，并控制该容器与其对应的备用状态的容器进行配置和状态数据同步，进而，当配置和状态数据同步完成时，控制该容器与其对应的备用状态的容器进行控制层管理通道切换，由该备用状态的容器替代该容器进行转发层面的控制，与现有issu过程中控制层面会出现分钟级别的不可用时间相比，本发明实施例提供的软件升级方案控制层面不可用的时间降低至毫秒级别，避免了控制层面长时间不可用导致的业务震荡，提高了网络设备的可靠性和可维护性。
附图说明
图1是本发明实施例提供的一种软件升级方法的流程示意图；
图2是本发明实施例提供的一种应用场景的示意图；
图3是本发明实施例提供的一种软件升级方法的流程示意图；
图4a～4d是本发明实施例提供的软件升级实现的示意图；
图5是本发明实施例提供的一种软件升级装置的结构示意图；
图6是本发明实施例提供的另一种软件升级装置的结构示意图；
图7是本发明实施例提供的另一种软件升级装置的结构示意图；
图8是本发明实施例提供的一种软件升级装置的硬件结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明实施例中的技术方案，并使本发明实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本发明实施例中技术方案作进一步详细的说明。
请参见图1，为本发明实施例提供的一种软件升级方法的流程示意图，其中，该软件升级方法可以应用于网络设备，该网络设备上搭建有至少一个用于业务运行的容器(本文中称为第一类型容器，也可以称为业务容器)，如图1所示，该软件升级方法可以包括以下步骤：
步骤101、接收针对目标第一类型容器的目标应用的不间断软件升级指令。
本发明实施例中，目标第一类型容器并不特指某一固定的容器，而是可以指代网络设备上搭建的至少一个第一类型容器中的任一第一类型容器。
同理，目标应用并不特指某一固定应用，而是可以指代目标第一类型容器中运行的任一应用，本发明实施例后续不再复述。
本发明实施例中，为了避免网络设备业务中断，当网络设备需要进行软件升级时，可以通过不间断软件升级(即issu)技术进行软件升级。
相应地，当需要对目标第一类型容器中的目标应用进行软件升级时，可以向网络设备下发针对目标第一类型容器中的目标应用的不间断软件升级指令(下文中简称为issu升级指令)。
步骤102、创建对应目标第一类型容器的目标第二类型容器，并控制目标第一类型容器与目标第二类型容器进行配置和状态数据同步。
本发明实施例中，考虑到现有issu升级方案中控制平面仍然会出现分钟级别的不可用，进而会引起业务震荡，降低网络设备的可靠性，因此，为了提高网络设备的可靠性，当网络设备确定第一类型容器的应用需要进行软件升级时，网络设备可以不在该第一类型容器中对该应用进行升级，而是直接在本地创建一个与该第一类型容器运行有相同应用，且应用的软件版本为升级后的版本的容器(本文中称为第二类型容器)，并在第一类型容器与第二类型容器完成配置和状态数据的同步后，控制第一类型容器与第二类型容器进行控制层管理通道切换，由该第二类型容器接替该第一类型容器进行转发层面控制，在实现件升级的同时，大大降低控制平面不可用的时间。
相应地，在本发明实施例中，当网络设备接收到针对目标第一类型容器中的目标应用的issu升级指令时，网络设备可以创建对应该目标第一类型容器的第二类型容器(本文中称为目标第二类型容器)；其中，该目标第二类型容器与目标第一类型容器运行有相同的应用，且目标第二类型容器中运行的目标应用的软件版本为升级后的版本(目标应用升级后的版本可以携带在issu升级指令中)。
其中，目标第二类型容器的初始状态为备用(standby)状态，备用状态的容器不进行转发层面控制，即此时仍由活跃(active)状态的目标第一类型容器进行转发层面控制。
本发明实施例中，网络设备创建了目标第二类型容器之后，可以控制目标第一类型容器和目标第二类型容器进行配置和状态数据的同步，以便保证目标第一类型容器和目标第二类型容器中相同的应用具有相同的配置和状态数据。
步骤103、当确定配置和状态数据同步完成时，控制目标第一类型容器切换为备用状态，以及目标第二类型容器切换为活跃状态。
本发明实施例中，当网络设备确定目标第一类型容器和目标第二类型容器完成配置和状态数据同步时，网络设备可以控制目标第一类型容器和目标第二类型容器进行控制层管理通道切换，即控制目标第一类型容器切换为备用状态(由活跃状态切换为备用状态)，并控制目标第二类型容器切换为活跃状态(由备用状态切换为活跃状态)，也即由目标第二类型容器接替目标第一类型容器进行转发层面控制。
由于目标第二类型容器和目标第一类型容器具有相同的配置和状态数据，因此，目标第二类型容器和目标第一类型容器完成状态切换后，并不会影响业务的正常运行，此外，由于目标第二类型容器中运行的为软件版本升级后的应用，即不需要再在目标第一类型容器或目标第二类型容器中进行专门的软件升级流程即可实现软件升级。
可见，在图1所示方法流程中，通过在需要对目标第一类型容器中的目标应用进行issu升级时，创建运行有相同应用，且应用的软件版本为软件升级后的版本的目标第二类型容器，并在目标第一类型容器和目标第二容器完成配置和状态数据同步之后，控制目标第一类型容器和目标第二类型容器进行状态切换，切换前由目标第一类型容器进行转发层面控制，切换后由目标第二类型容器进行转发层面控制，即软件升级过程中仅在状态切换过程(毫秒级别)中控制平面不可用的情况，在实现软件升级的同时，大大降低了控制平面不可用的时间，提高了网络设备的可靠性和可维护性。
进一步地，在本发明实施例中，考虑到当目标第一类型容器中配置和状态数据较多时，目标第一类型容器和目标第二类型容器进行配置和状态数据同步的过程中可能会产生配置和状态数据的变化，此时，需要对发生变化的配置和状态数据再次进行同步，即可以按照全量同步+增量同步的方式实现配置和状态数据同步。
相应地，在本发明其中一个实施例中，上述创建对应目标第一类型容器的目标第二类型容器，并控制目标第一类型容器与目标第二类型容器进行配置和状态数据同步，可以包括：
向目标第一类型容器发送第一消息，该第一消息用于通知目标第一类型容器将第一时刻的配置和状态数据存储到指定存储空间；其中，第一时刻为目标第一类型容器接收到第一消息的时刻；
创建目标第二类型容器，以使目标第二类型容器从指定存储空间中获取第一时刻的配置和状态数据；
当接收到目标第二类型容器发送的第二消息时，向目标第二类型容器发送目标第一类型容器的增量配置和状态数据；其中，第二消息由目标第二容器在完成第一时刻的配置和状态数据的获取时发送，增量配置和状态数据为第一时刻到第二时刻之间的配置和状态数据变化，第二时刻为接收到第二消息的时刻。
在该实施例中，当网络设备接收到issu升级指令时，网络设备一方面可以向目标第一类型容器发送第一消息；目标第一类型容器接收到该第一消息时，可以将第一时刻(即接收到该第一消息的时刻)的配置和状态数据(该配置和状态数据可以称为全量配置和状态数据)存储到指定存储空间。
另一方面，网络设备可以创建目标第二类型容器；目标第二类型容器启动后可以从上述指定存储空间中获取目标第一类型容器在第一时刻的配置和状态数据。
目标第二类型容器获取到目标第一类型容器在第一时刻的配置和状态数据(即完后全量配置和状态数据同步)时，可以向网络设备发送第二消息。
在该实施例中，考虑到上述全量配置和状态数据同步期间，目标第一类型容器中的配置和状态数据可能会发生变化，因此，网络设备向目标第一类型容器发送第一消息时，还可以监控目标第一类型容器的配置和状态数据，记录目标第一类型容器的配置和状态数据。
当网络设备接收到目标第二类型容器发送的第二消息时，网络设备还可以将目标第一类型容器在第一时刻到第二时刻(即接收到第二消息的时刻)之间的配置和状态数据变化(本文中可以称为增量配置和状态数据)通过第三消息发送给目标第二类型容器；目标第二类型容器接收到第三消息时，可以根据其中携带的配置和状态数据变化更新本地的配置和状态数据。
由于上述增量配置和状态数据一般数据量会比较小，因此，增量配置和状态数据的同步的时间也会很短，在该过程中，目标第一类型容器中再次发生配置和状态数据变化的概率会很低，进而，可以通过上述全量同步+增量同步的方式保证目标第一类型容器和目标第二类型容器的配置和状态数据的同步。
进一步地，在该实施例中，考虑到网络设备向目标第二类型容器进行增量配置和状态数据同步时，目标第一类型容器中可能会存在应用正在处理能够引起配置和状态数据发生变化的事件(本文中称为目标事件)，此时进行增量同步时，无法保证将该应用对应的配置和状态数据变化全部同步给目标第二类型容器。
相应地，在该实施例的一种实施方式中，上述当接收到所述目标第二类型容器发送的第二消息时，向目标第二类型容器发送目标第一类型容器的增量配置和状态数据，可以包括：
当接收到目标第二类型容器发送的第二消息时，确定目标第一类型容器中是否存在正在处理目标事件的第一应用；
若存在，则向目标第二类型容器发送未在处理目标事件的第二应用对应的增量配置和状态数据；
当第一应用完成目标事件处理时，向目标第二类型发送所述第一应用对应的增量配置和状态数据；其中，第一应用对应的增量配置和状态数据为第一应用对应的第一时刻到第三时刻之间的配置和状态数据变化，第三时刻为第一应用完成目标事件处理的时刻。
在该实施方式中，当网络设备接收到第二消息时，网络设备可以确定目标第一类型容器中是否存在正在处理目标事件的应用(本文中称为第一应用)；若存在，则网络设备可以先不对该第一应用对应的增量配置和状态数据进行同步，此时，网络设备可以先将未在处理目标事件的应用(本文中称为第二应用)对应的增量配置和状态数据(即第二应用对应的第一时刻到第二时刻之间的配置和状态数据变化)同步给目标第二类型容器。
当第一应用完成目标事件处理时，网络设备可以将第一应用对应的增量配置和状态数据(第一应用对应的第一时刻到第三时刻(第一应用完成目标事件处理的时刻)之间的配置和状态数据变化)同步给目标第二类型容器。
进一步地，考虑到第二应用对应的增量配置和状态数据同步完成之后，第一应用对应的增量配置和状态数据同步完成之前，可能会存在第二应用也开始处理目标事件，此时，网络设备可以在目标第二类型容器中模拟目标第一类型容器中在第二时刻之后发生的目标事件，即网络设备检测到目标第一类型容器中(在第二时刻之后)存在第二应用发生目标事件时，在目标第二类型容器中模拟该目标事件，以保证目标第一类型容器和目标第二类型容器中对应该第二应用的配置和状态数据的一致。
需要说明的是，当目标第二类型容器为备用状态时，目标第二类型容器中的应用处理目标事件时不执行硬件上的决策或配置等动作，即不对转发层面进行控制。
进一步地，在本发明实施例中，为了节省系统资源，目标第一类型容器切换为备用状态之后，网络设备可以对目标第一类型容器进行资源回收，即通知目标第一类型容器退出，并释放资源。
为了使本领域技术人员更好地理解本发明实施例提供的技术方案，下面结合具体应用场景对本发明实施例提供的技术方案进行说明。
请参见图2，为本发明实施例提供的一种应用场景的示意图，如图2所示，网络设备200上搭建有业务容器210，其中，业务容器210中运行有应用app1、app2和app3。
需要说明的是，在该实施例中，当网络设备200正常运行时，业务容器210处于active状态；其中，active状态的业务容器可以对转发层面进行控制。
基于图2所示的应用场景，本发明实施例提供的软件升级方案实现如下：
在该实施例中，假设app1需要进行软件升级(软件版本由版本a升级为版本b)，网络设备200通过issu对app1进行软件升级(简称为issu升级)，其软件升级实现流程如图3所示，可以包括以下步骤：
步骤301、网络设备200接收针对app1的issu升级指令，启动issu管理模块201。
在该实施例中，当需要对网络设备200上的app1进行issu升级时，可以向网络设备200下发针对app1的issu升级指令。
网络设备200接收到针对app1的issu升级指令时，可以在启动issu管理模块201，该issu管理模块201可以用于负责整个issu过程的管理、容器状态跟踪以及相关过程事件的通告等。
步骤302、issu管理模块201向业务容器210发送消息m100，该消息m100用于通知业务容器210开始issu过程。
在该实施例中，假设issu管理模块201向业务容器210发送消息m100与业务容器210接收到消息m100为同一时刻(假设为t1)。
步骤303、业务容器210获取t1时刻的配置和状态数据，并将获取到的配置和状态数据保存至存储单元220。
在该实施例中，业务容器210接收到issu管理模块201发送的消息m100时，可以获取t1时刻的配置和状态数据，并将获取到的配置和状态数据(本文中称为data_t1)保存至存储单元220(过程p100)，其示意图可以如图4a所示。
举例来说，假设app1为ospf(openshortestpathfirst，开放式最短路径优先)管理单元，且网络设备在t1时刻存在100条路由，则业务容器210可以将该100条路由保存至存储单元。
步骤304、issu管理模块201创建业务容器230，该业务容器230运行有应用app1、app2和app3；其中，业务容器230处于standby状态，且业务容器230中app1的软件版本为版本b。
在该实施例中，issu管理模块201启动后，一方面可以按照上述步骤302通知业务容器210将t1时刻的配置和状态数据保存至存储单元220；另一方面，issu管理模块201可以启动另一个业务容器(业务容器230)，业务容器230与业务容器210运行有相同的应用(均运行有app1、app2和app3)，二者区别在于，业务容器210中运行的应用为软件升级前的版本，而业务容器230中运行的应用为软件升级后的版本，即在该实施例中，业务容器210中的app1的软件版本为版本a，业务容器230中app1的软件版本为版本b。
其中，业务容器230创建时处于standby状态(standby状态的业务容器不进行转发层面控制)。
步骤305、业务容器230从存储单元220中读取data_t1。
在该实施例中，业务容器230启动后，可以从存储单元220中读取业务容器210在t1时刻的配置和状态数据(即data_t1)(过程p200)，从而，业务容器230可以具备业务容器210在t1时刻的全部配置和状态，其示意图可以如图4b所示。
其中，业务容器230完成data_t1读取之后，可以向issu管理模块201发送消息m200，该消息m200用于通知issu管理模块201完成data_t1读取。
假设业务容器230向issu管理模块201发送消息m200与issu管理模块201接收到消息m200为同一时刻(假设为t2时刻)。
步骤306、issu管理模块201通过消息m300，将业务容器210在t1时刻到t2时刻的配置和状态数据变化同步给业务容器230。
在该实施例中，issu管理模块201向业务容器210发送消息m100之后，可以对业务容器210的配置和状态数据进行监控(过程p300)，记录业务容器210的配置和状态数据的变化(本文中称为data_t1-t2)。
当issu管理模块201接收到业务容器230发送的消息m200时，issu管理模块201可以向业务容器230发送消息m300，该消息m300中携带有data_t1-t2。
举例来说，仍以ospf路由协议为例，假设app1为ospf管理单元，t1时刻到t2时刻，网络设备发布了3条新路由，撤销了5条路由，此时，这8条路由的变化由issu管理模块201记录，并在t2时刻通过消息m300同步给业务容器230，其示意图可以如图4c所示。
步骤307、业务容器230根据接收到的消息m300中携带的data_t1-t2进行配置和状态数据更新。
此时，业务容器230具有了业务容器210在t2时刻的全部配置和状态数据。
需要说明的是，在该实施例中，步骤301～307中任一步骤出现异常，均可终止软件升级，并继续由业务容器210进行转发层面控制。
步骤308、业务容器230向issu管理模块201发送消息m400，该消息m400用于通知issu管理模块201完成配置和状态数据更新。
步骤309、issu管理模块201向业务容器210发送消息m500，该消息m500用于通知业务容器210进行控制层管理通道切换。
在该实施例中，业务容器230完成配置和状态数据更新时，可以向issu管理模块201发送消息m400，以通知issu管理模块201配置和状态数据更新已完成。
issu管理模块201接收到消息m400时，可以向业务容器210发送消息m500，以通知业务容器210进行控制层管理通道切换。
业务容器210接收到消息m500时，将自身由active状态切换为standby状态，并通知业务容器230由standby状态切换为active状态，完成控制层管理通道切换(过程p400)，其示意图可以如图4d所示。
至此，业务容器230中的app1的软件版本由版本a升级为版本b，在该过程中，转发层面一直正常工作，控制层面仅在控制层管理通道切换过程中停止工作(该过程为ms级(约为50ms)，不会引起业务震荡)，从而保证了app1进行issu升级时的业务稳定性，进而提高了网络设备的可靠性和可维护性。
需要说明的是，在该实施例中，若步骤306中issu管理模块201接收到消息m200时(即t2时刻)，issu管理模块201监测到业务容器210中存在部分应用正在处理可能会使该应用对应的配置和状态数据发生变化的事件(即目标事件)，则issu管理模块201可以先不对该部分应用的配置和状态数据的变化进行同步。
举例来说，假设步骤306中issu管理模块201在t2时刻监测到app2正在处理目标事件，则issu管理模块201可以先将app1和app3对应的t1时刻到t2时刻的配置和状态数据的变化同步给业务容器230(通过消息m300)，并当app2处理完成目标事件时(假设为t3时刻)，将t1时刻到t3时刻app2对应的配置和状态数据的变化同步给业务容器230(通过消息m300)。
其中，考虑到t2时刻到t3时刻期间，app1或/和app3也可能会出现配置和状态数据发生变化的情况，在t2时刻到t3时刻期间，对于可能导致app1或/和app3的配置和状态数据发生变化的目标事件(如流量或/和配置信息等)，issu管理模块201可以在业务容器230中进行模拟。
例如，在t2时刻到t3时刻期间，发送给业务容器210中的app3的流量可以复制一份发送给业务容器230中的app3，以保证业务容器210和业务容器230中的app3的配置和状态数据一致。
值得注意的是，在本申请实施例中，standby状态的业务容器中的应用不执行硬件上的决策或配置等动作，即不对转发层面进行控制。
进一步地，在该实施例中，为了提高资源利用率，当控制层管理通道切换完成之后，issu管理模块201可以通知业务容器210退出，并释放资源。
通过以上描述可以看出，在本发明实施例提供的技术方案中，通过将业务进程装入容器，当容器中的应用需要进行issu升级时，创建与该容器运行有相同应用，且应用的软件版本为升级后的版本的备用状态的容器，并控制该容器与其对应的备用状态的容器进行配置和状态数据同步，进而，当配置和状态数据同步完成时，控制该容器与其对应的备用状态的容器进行控制层管理通道切换，由该备用状态的容器替代该容器进行转发层面的控制，与现有issu过程中控制层面会出现分钟级别的不可用时间相比，本发明实施例提供的软件升级方案控制层面不可用的时间降低至毫秒级别，避免了控制层面长时间不可用导致的业务震荡，提高了网络设备的可靠性和可维护性。
请参见图5，为本发明实施例提供的一种软件升级装置的结构示意图，其中，该软件升级装置可以应用于上述方法实施例中的网络设备，如图5所示，该软件升级装置可以包括：
接收单元510，用于接收针对目标第一类型容器中的目标应用的不间断软件升级指令；
创建单元520，用于创建对应目标第一类型容器的目标第二类型容器；其中，目标第二类型容器与目标第一类型容器运行有相同的应用，且目的第二类型容器中运行的目标应用的软件版本为升级后的版本，目标第二类型容器的初始状态为备用状态，备用状态的容器不进行转发层面控制；
控制单元530，用于控制目标第一类型容器与目标第二类型容器进行配置和状态数据同步；
控制单元530，还用于当确定配置和状态数据同步完成时，控制目标第一类型容器切换为备用状态，以及目标第二类型容器切换为活跃状态。
在可选实施例中，控制单元530，具体用于向目标第一类型容器发送第一消息，第一消息用于通知目标第一类型容器将第一时刻的配置和状态数据存储到指定存储空间；其中，第一时刻为目标第一类型容器接收到第一消息的时刻；
创建单元520，具体用于创建目标第二类型容器，以使目标第二类型容器从指定存储空间中获取第一时刻的配置和状态数据；
控制单元530，还具体用于当接收单元510接收到目标第二类型容器发送的第二消息时，向目标第二类型容器发送目标第一类型容器的增量配置和状态数据；其中，第二消息由目标第二容器在完成第一时刻的配置和状态数据的获取时发送，增量配置和状态数据为第一时刻到第二时刻之间的配置和状态数据变化，第二时刻为接收到第二消息的时刻。
请一并参见图6，为本发明实施例提供的另一种软件升级装置的结构示意图，如图6所示，在图5所示软件升级装置的基础上，图6所示软件升级装置还包括：
确定单元540，用于当接收单元510接收到目标第二类型容器发送的第二消息时，确定目标第一类型容器中是否存在正在处理目标事件的第一应用；其中，目标事件包括能够引起配置和状态数据发生变化的事件；
控制单元530，具体用于若存在，则向目标第二类型容器发送未在处理目标事件的第二应用对应的增量配置和状态数据；
控制单元530，还具体用于当第一应用完成目标事件处理时，向目标第二类型发送第一应用对应的增量配置和状态数据；其中，第一应用对应的增量配置和状态数据为第一应用对应的第一时刻到第三时刻之间的配置和状态数据变化，第三时刻为第一应用完成目标事件处理的时刻。
在可选实施例中，控制单元530，还用于在向目标第二类型容器发送第二应用对应的增量配置和状态数据之后，向目标第二类型发送第一应用对应的增量配置和状态数据之前，当检测到目标第一类型容器中存在第二应用发生目标事件时，在目标第二类型容器中模拟该目标事件。
请一并参见图7，为本发明实施例提供的另一种软件升级装置的结构示意图，如图7所示，在图5所示软件升级装置的基础上，图7所示软件升级装置还包括：
资源回收单元550，用于在控制单元530控制目标第一类型容器切换为备用状态，以及目标第二类型容器切换为活跃状态之后，对目标第一类型容器进行资源回收。
请参见图8，为本发明实施例提供的一种软件升级装置的硬件结构示意图。所述软件升级装置至少包括处理器801、存储有机器可执行指令的机器可读存储介质802。处理器801与机器可读存储介质802可经由系统总线803通信。并且，通过读取并执行机器可读存储介质802中与软件升级逻辑对应的机器可执行指令，处理器801可执行上文描述的软件升级方法。
本文中提到的机器可读存储介质802可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：ram(radomaccessmemory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。
本发明实施例还提供了一种包括机器可执行指令的机器可读存储介质，例如图8中的机器可读存储介质802，所述机器可执行指令可由软件升级装置中的处理器801执行以实现以上描述的软件升级方法。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本发明方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
由上述实施例可见，通过将业务进程装入容器，当容器中的应用需要进行issu升级时，创建与该容器运行有相同应用，且应用的软件版本为升级后的版本的备用状态的容器，并控制该容器与其对应的备用状态的容器进行配置和状态数据同步，进而，当配置和状态数据同步完成时，控制该容器与其对应的备用状态的容器进行控制层管理通道切换，由该备用状态的容器替代该容器进行转发层面的控制，与现有issu过程中控制层面会出现分钟级别的不可用时间相比，本发明实施例提供的软件升级方案控制层面不可用的时间降低至毫秒级别，避免了控制层面长时间不可用导致的业务震荡，提高了网络设备的可靠性和可维护性。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。
应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。