在网络设备软件功能越来越复杂的今天，软件架构的可靠性占有非常重要的地位。没有一个可靠的软件架构，设备的可靠性将无从谈起。本文以H3CComware V7软件平台为例，介绍其采用的软件架构可靠性设计方法。
　　故障隔离和自愈
　　软件和Bug是一对伴生的兄弟。在一个庞大的软件系统中，即使是经验再丰富的程序员也无法保证没有任何Bug。硬件设备工作再稳定，如果不幸遇到软件Bug，也会引起异常，设备将无法正常工作。因此，故障隔离和自愈是软件设计中必须要考虑的问题。
　　故障隔离
　　故障隔离指在软件发生故障的时候，把故障造成的危害限制在最小范围内。为了达到此目标，Comware V7系统采用了Linux操作系统架构，绝大部分程序都是用户态程序。在Linux系统中，每个用户态程序拥有独立的进程空间，这样，一旦某个程序崩溃，并不会对其他的程序产生影响。我们称这种进程空间独立的架构设计为真正的模块化设计。
　　举例来说，路由协议中，OSPF是一个独立的用户态程序，IS-IS也是一个独立的用户态程序。运行期间，在某个极其特殊的情况下，OSPF走入某个代码异常分支处理流程，而在这里有一个Bug，运行到这就会引起整个OSPF进程崩溃。但IS-IS作为一个独立的路由协议，拥有独立的进程空间，它的运行不受任何影响，还可以正常运行。
　　故障自愈
　　故障自愈是让系统从故障中恢复到正常的工作状态。想要做到自愈，首先要发现错误。Comware
V7系统有一套完整的进程运行状态监控机制，可以及时发现某个用户态程序“异常”。其基本工作原理如下：
　　1. 所有的用户态程序都是系统初始化进程SCM(Service Control Manager)的子进程，SCM可以感知所有子进程的状态，一旦发现某个用户态程序崩溃，会主动回收它的资源，然后重新启动一个相同的用户态程序，接替崩溃的程序继续工作。
　　2. 有时一个用户态程序出了问题，无法正常工作，但还没有达到崩溃的地步，这时Comware系统中另外一套主动检测机制则起作用，过程如图1所示。
 
　　图1 进程故障发现与自愈过程
　　这个特殊的监控程序——Monitor，会周期性的检查各个用户态程序，主动向其他的用户态程序发送查询消息。其他的用户态程序在收到Monitor发来的这个消息后，会进行自检，并将自身的情况回应给Monitor，Monitor根据回复的消息得知某个用户态程序异常。在更为严重的异常情况下，用户态程序无法处理Monitor发来的消息，无法应答，Monitor在一段时间内没有收到应答，则判断这个用户态程序“异常”。
　　一旦监控进程发现某个用户态程序异常，就会通知SCM，SCM重复步骤一：回收它的资源，然后重新启动一个相同的用户态程序，接替崩溃的程序继续工作。
　　以上是对故障隔离与自愈机制的简单描述，Comware V7实际的工作方式要复杂的多。因为作为一个通信系统，各个独立的用户态程序之间并不是真正完全“孤立”的，它们之间会进行各种通信，协作完成网络设备的各种功能。所以，想要让重新运行的用户态程序真正的正常工作，还需要记录大量的程序正常工作时的状态信息，以便在重启以后，使其恢复到故障之前的正常状态。
　　同时，Comware V7拥有EEM(Embedded Event Manager)系统，系统管理员可以编写脚本，在异常发生时通过EEM触发这个脚本。这样，除上述所提到的中止异常程序重新运行的动作外，还能够按照脚本做更为复杂的动作，进行异常的远程上报、进一步的异常诊断分析，或者其他任何可以通过脚本触发的动作。这样，软件系统的可维护性也大大提升。
[#page_进程级备份#]
　　进程级备份
　　故障隔离与自愈功能，仅仅是单硬件系统上的行为。单硬件系统是指只有一个硬件主板的集中式系统(大部分盒式产品都属于这种情况)，或者是分布式设备上的IO板，没有另外一块单板作为备份(如分布式设备的大部分接口板、业务板)。
　　在硬件有冗余备份的情况下，则需要进程级备份功能，也称为进程级HA。所谓进程级备份，是相对于单板级HA而言的，主要是指参与备份和倒换的实体不再是整个单板，而是单板上的一个个用户态进程。具体过程如图2所示。