一个典型的采集服务器体系结构设计.pdfVIP

一个典型的采集服务器体系结构设计 一个基于大量可复用模块的系统架构 作者：成晓旭 /cxxsoft (声明：版权保留，欢迎转载、请保证文章完整性) 1、整个系统简介 假设系统是一个常见的监控、数据采集系统的实例缩影：系统的最底层是硬件采集设备，硬件设备完成整 个系统与外界环境或者设备的交互；上层的软件系统完成与自己硬件设备的交互，并且对采集的数据进行分析、 处理、存储、展现。 2 、 问题 在我工作的软件项目中，类似的应用存在于多个软件系统中，虽然这些系统在子系统设计及职责划分 方面也如上图一般进行了明确的分层及模块化，但在核心的“通信采集子系统”的设计及实现上存在诸多通病， 导致整个子系统的可理解性、可维护性、可测试性、对需求变动的适应性极差。集中表现在： A 、整个系统被设计成一个“非常庞大”的“业务调度控制类”：此类中包括几乎所有的通信业务管 理、通信中转、界面显示驱动、显示数据生成等。 B 、在通信方式实现类（比如：串口通信类、语音卡控制类、TCP/IP 通信类）中完成所有业务处理功 能：通信任务管理、下行命令队列管理、通信数据的收发、通信协议的解析、业务数据的分析甚至存储，甚至 有些系统中还包括显示数据的生成及界面显示驱动。 C、对于多任务并发，多个设备上、下行同时通信的管理非常复杂：在通信处理类中引入非常、非常多 的数组来处理多任务并发，增加非常多的控制标志来标识记录具体某个设备当前所处的通信状态。由于没有进 行单独的业务抽象，当系统测试或上线运行之后，系统中实际的运行状态管理和运行标志判断，对调试人员或 者系统维护人员来说，简单是一场噩梦！“整个系统就跟森林似的！”，已经是很多同事不约而同的感慨。 D 、对于需求变化的适应性非常差：如果通信方式变了，对不起，你必须重新实现通信处理类；当然， 所有的通信控制逻辑、协议解析、数据分析及存储、并行控制及管理、队列管理等功能你也必须重新开发了。 如果通信协议变了、数据分析逻辑变了，你必须小心翼翼、如履薄冰地在“通信处理类”的那成千上万行代码 里找寻找你关心的蛛丝马迹。 E 、几乎没有可复用性了：那个家伙熬更守夜花两周研究的语音卡控制代码，你想尊重一下那位大侠的 劳动成果，直接拿过来用几乎是不可能的，因为那稀少的语音卡代码，早已淹没在茫茫的业务处理代码中了。 如果新签订的合同需要更换新的通信采集方式，那成千上万行业务控制代码你想将就用用也是难上加难的。 3、采集服务器设计 采集服务器是整个系统的核心，实现与硬件终端的通信、下行命令的执行、上行数据的接收、协议解 析，并且完成业务数据的分析、存储以及显示驱动。它既是系统的通信枢纽，也是业务核心。 下图是本人2004 年设计的一个采集子系统体系结构的缩影。 A 、通信采集子系统设计简介 本系统设计主要参考了大量的实时系统设计模式，并分析、总结了以前多个系统的设计与实现的经验与教训。 采集子系统的“外部系统接口类”，设计成Façade 模式：在整个系统中，其它子系统需要执行什么 控制命令、或者需要得到什么数据，只需通过“外部系统接口类”向采集子系统发出简单的命令请求，具 体的实现细节不用操心，采集子系统完成命令之后，将结果再通过“外部系统接口类”反馈给命令发起者。 甚至命令的处理逻辑已经完全不同了，发起者仍然可以一如既往地执行相同的命令，得到其期望的反馈信 息。 采集子系统借鉴“微内核”的实时设计模式：核心的通信、控制处理逻辑被严格封装在“采集控制 器”中，“采集控制器”设计为一个抽象的“采集业务状态机”，也是一个自管理的可运行单元（比如： 实现为一个线程、或者独立的服务进程），对外界实现一个通用的类似于计算机CPU 一样的通信处理器， 通过对其外围增加“命令队列”、“采集业务类”、“通信适配器”等“外围器件”实现一个针对具体功 能应用的“主板”。 建立整个子系统的业务对象关联的是一个Mediator 模式：用以最大可能地解耦各个功能组件，彻底