作者：郭洪锋 本文叙述了分布式实时系统中基础服务应用概念，对其持久性实现做了详细的分析。 1、基础服务应用在分布式实时系统中的角色 在许多企业系统中，一般由内部核心局域网系统和以该核心系统为中心的外部广域网客户服务系统（例如Web系统）组成。核心局域网系统负责企业内部数据和事务的处理，同时也为外部系统提供企业可用的共享数据。因此，核心局域网系统的持久性、高可靠性和高可用性对于整个企业系统至关重要。 企业的核心局域网系统为一个分布式的企业应用系统，一般具有实时性的要求。比如电力行业的能量管理系统，作为电力企业的核心应用系统，是一个真正的分布式实时系统，要求系统具有实时反映电力系统状态变化和不间断可靠运行的能力。而在这个分布式应用系统中，基础服务应用的设计又决定了系统的整体性能。 基础服务应用是整个企业核心分布式系统运行的基础平台。它为整个分布式应用系统提供分布式对象管理和提供各类服务的能力，为系统中的各类上层应用提供对象及内容查询、实时资源共享、对象生命周期维护、对象引用分布化等服务。 2、基础服务应用构架 基础服务应用运行于企业系统中的所有节点，类似CORBA系统中的ORB，但是基础服务应用作为一个单独的应用，不仅提供对象定位服务，并且提供各类实时分布式系统所需的基础服务。这样设计的原因不仅基于高速局域网的固有特点，并且主要强化系统的不间断运行的实时性和分布式特点。就基于高速局域网的企业系统而言，基于基础服务应用的系统比之基于类似CORBA的系统更容易提供持久性服务（包括故障自动排除能力）、高可靠性和高可用性服务。 基础服务应用的简化构架如下图所示： 图1： 基础服务应用的简化构架 外部接口API层设计成对上层应用提供服务的标准接口集合。通过这些接口，上层应用可以以本地的方式访问整个分布式实时系统中的分布式对象，可以引用、注册或更新或注销自己的对象引用等。事务处理层负责响应上层应用，以提供各类服务。它可以通过本地对象数据库维护层操作本地记录的系统内的所有分布式对象。分布式管理层则维护系统的分布式实时特征，提供持久性服务、可靠性服务。整个系统内的所有节点均通过分布式管理层达到分布式对象的全局统一性。 基于基础服务应用系统中的任何一个节点的故障均不会影响整个分布式实时系统的整体运行。即不发生故障时，节点是分布式实时系统中一个不可分割的运行实体，而节点发生故障时，节点要平滑的脱离分布式实时系统，并且不会对系统的实时性、分布式和提供的各类服务产生异常的影响，其中不仅自动在分布式系统中注销该节点，并且与该节点有关的所有对象将自动注销或状态转移为非正常状态如冻结、丢失或不可用状态。 3、基础服务应用服务持久性服务的实现 基础服务应用的分布式管理层负责统一所有系统节点的分布式对象引用。并提供整个系统基础服务应用的服务持久性。所有的基础服务应用运行级别是不一样的，其中一个运行级别最高的是系统中的主基础服务应用，将作为其他基础服务应用的对象应用的统一源，分布式管理层维护基础服务应用的运行级别，实时统一系统内的分布式对象引用。 3.1分布式管理层状态转化图 分布式管理层状态转化图如下图所示： 图2：分布式管理层状态转化图 该图实际上只是表达了基础服务应用开始启动时的状态转化图。运行过程中其状态图会变得更复杂。在基础服务应用开始启动时，首先查询系统内有无主服务应用存在，由于基于地域有限的局域网系统，主基础服务应用启动后会启动一个以广播和多播形式的心跳消息驱动器。基础服务应用开始启动后可以很快收到这些消息，然后建立与主基础服务应用的一条可靠的信道。这时由于基础服务应用内部的分布式数据库不能反映实时状态，所以需要复制主基础服务应用的分布式数据库。复制过程中，基础服务应用将调用主基础服务应用的分布式管理层内部的复制服务方法，逐步的将所有的实时的数据复制到本地。在基础服务应用获得实时数据后，转入正常状态，并通知事务处理层本地的基础服务应用可以提供服务，之后激活外部接口API层。如果启动的基础服务应用具有更高的运行级别，则在统一实时数据后，会重新建立分布式管理层之间的信道。 3.2 分布式管理层实现持久性服务 由于企业系统基于高速局域网，系统性能、调度管理、内存管理、数据统一的通信瓶颈和速度已经不是影响应用服务持久性的关键问题。依据企业系统具有操作复杂频繁，系统更新频率高等特点，同时在开发系统过程中也认识到，影响服务持久性的因素主要是节点故障。 基础服务应用在分布式处理上，节点状态变化至关重要，节点状态变化可以有如下几类： 一个新的节点加入分布式实时系统，该节点的服务级别小于运行的主基础服务应用。 一个新的节点加入分布式实时系统，但该节点的服务级别大于运行的主基础服务应用。 一个节点离开分布式实时系统，该节点中的基础服务应用不是主基础服务应用。 一个节点离开分布式实时系统，但该节点中的基础服务应用是主基础服务应用。 一个运行的节点加入分布式实时系统，该节点的服务级别小于运行的主基础服务应用。 一个运行的节点加入分布式实时系统，但该节点的服务级别大于运行的主基础服务应用。 第一类中，新节点中的基础服务应用是图2状态图中右边状态图的反映，对于整个系统不会有状态的影响。 第二类中，新节点中的基础服务应用是图2状态图中左边状态图的反映，这时会重新建立所有节点的基础服务应用中分布式管理层之间的信道，在新节点获得实时数据后，将切断与目前与主基础服务应用的应用。各个基础服务应用分布式管理层的主服务应用决策模块将根据节点的运行级别计算出主基础服务应用，然后重新与主基础服务应用建立信道。这个过程由于不影响实时数据的内容，所以是一个平滑的过程，对于上层应用是透明的。 第三、四类的情况要复杂一些，因为一个节点退出，该节点提供的对象将不再能提供服务。在第三类情况下，主基础服务应用首先收到一个信道切断通知，然后将改变该节点的对象引用的状态，一方面启动通知服务，通知使用该对象引用的各个上层应用，另一方面也把该事件传递给其它节点的基础服务应用。第四类情况下，随着主基础服务应用心跳信息的丢失，分布式管理层自动触发主服务应用决策模块，启动一个新的主基础服务应用。然后启动节点丢失的各个动作。可以看出，这两类情况不会出现实时数据的冲突问题，也基本上是一个平滑的过程。 第五、六类的情况是两种严重的故障。一个运行的节点加入分布式实时系统，意味这系统内瞬间出现两个可能存在差异的实时数据库，因为这时有两个主基础服务应用。产生这种情况的原因可能是一个节点的网络出现短暂故障或长久故障而后网络恢复的结果。也有可能一个系统中连接两个交换机的集连线或路由出现故障，一段时间后又恢复的结果。这种故障下，需要统一实时数据库。统一的过程不是将两个数据库合并的过程，因为它们提供的实时服务可能有冲突。统一的方法依据对象的属性而分别处理，一般对象分为独立对象和冗余对象两类。独立对象由仅一个节点提供，例如节点对象。冗余对象由至少两个应用提供，这些对象作为主备冗余角色存在于系统内。对于独立对象类，完全可以合并。而冗余对象则要根据分隔的两个系统的状态决定如何处理，如果冗余对象只存在于一个分隔的系统中，则可以合并，而如果分隔的系统中均存在冗余对象且被引用，则系统将注销该对象和对象引用，通知用户应用重新创建该对象和引用对象。此种情况下的主基础服务应用状态图如下所示： 图3 多个主基础服务应用冲突时运行状态图 主基础服务应用首先进入冻结状态，此时通知上层的用户应用该状态的变化。分布式管理层的主服务应用决策模块将根据运行级别快速决定出一个主基础服务应用，主基础服务应用接收另一个实时对象库的内容，根据对象的属性分别作出处理，以统一对象数据库。解除冻结状态中，激活API层，以一个reset事件通知对象的创建者应用和对象引用的应用。另一个实时对象数据库的主基础服务应用将建立与主基础服务应用的信道，统一数据库后，转入一般基础服务应用运行状态。 在判断节点故障中，有一个重要的参数，即节点丢失超时时间timeout。该值的大小要根据系统的具体环境决定。如果该值太小，则在信道中那些属于正常范围的数据包丢失和瞬时故障均可能被判断成节点丢失，会频繁引起系统抖动。而如果该值太大，则节点丢失后，会在较长的时间内无法判断节点是否丢失，影响系统的实时要求。因此，该值可以设置为一个略大于瞬时故障周期的值。瞬时故障周期值依赖于操作系统和网络设备的网络恢复timeout、主基础服务应用的心跳周期、实时性的具体要求等。 4 结束语 基础服务应用在企业分布式系统统中可以为用户提供实时的分布式对象引用，实时的向用户应用通知系统的实时软件或硬件故障，以便使得用户应用作出及时的故障处理和报警工作。它的持久性体现了软故障自动处理和硬件故障及时通知用户应用和提醒用户及时处理的实时特征，同时也提供了用户应用自动故障恢复的机制。可以说，基础服务应用为企业的核心实时系统提供了一个较好的运行方案
[1] [2] 下一页
（出处：http://www.sheup.com）