一种无线通讯配置系统的架构设计

摘 要业界移动通讯配置部署、运维管理系统对工程师的技术要求高，工作低效，容易出错，需要支持较大的数据量。为了解决这些痛点，我司进行4+1需求模型分析明确需求，采用正交软件架构、进程容器平台组件架构、数据工厂模式，并将管道过滤器、解释器、MAP-REDUCE风格应用于数据比较，从而实现了一种低内存，高性能，自动化高，应用简单，易扩展的集中配置系统。

【关键词F4+1模型 正交设计 进程容器 平台组件 工厂模式 管道过滤 MAP-REDUCE 集中配置

无线通讯系统比较复杂，包括不同产品、制式和各种服务。现有技术中，配置系统通过配置界面操作配置各网元对象，操作复杂，难度较高，不仅容易出错，而且工程繁杂低效；随着系统演进，其资源需求越来越大，处理效率越来越低，系统甚至存在不可用问题。为了解决目前配置系统遇到的问题，同时适应一些新需求，诸如批量开站、快速下載激活等，首先进行4+1需求模型分析，明确需求，确定软件系统的实现，提出了正交软件架构、进程容器平台组件架构；接着，结合系统的物理部署论述了工厂模式的数据设置系统；之后论述了如何将管道过滤器、解释器、MAP-REDUCE三者风格混合应用于数据比较的架构设计及实现中，最后总结评价了该系统。

1 4+1软件架构建模

当前配置系统通常是通过配置界面操作逐一配置各个对象元素，这种配置操作对于少量配置数据没有问题，但对于技术不断演进、业务不断扩张的通讯系统显得捉襟见肘，用户普遍反应需要一种简单高效的配置系统。

如何让配置简单高效？何谓简单，其实就是希望尽量少做，甚至不做事情，统一由程序软件代替用户完成。可选的架构风格是批处理序列、管道过滤数据流风格，让用户提交一个作业即可完成配置；同时，管道过滤批处理架构适用于并发，从而也可以提高效率。

该架构风格如何适应各种通讯系统产品呢？通讯系统存在2G、3G、4G，甚至还有规划中的5G产品；并且，配置对象存在多种类别划分，有地面配置对象和无线配置对象，而无线配置对象还细分为多个小类。可谓多而杂，经过分析，我们发现这些产品对象存在相同或者相似之处，将这些相同或者相似的地方进行抽象，可以将它们抽象为一个个产品模型，然后可以基于这些模型选型进行批量配置处理。进一步分析，引入模型选型，需要模型管理，从而需要模型管理子系统。这属于4+1视图模型中的开发视图，根据该开发视图，开发人员可用于软件开发管理。

新旧配置系统完全不一样，需要考虑系统的演进模式，处理好新旧系统的关系。可以用新系统适配继承旧系统，也可以抛弃旧系统完全重头开发。如果完全从头开发，工作量大，风险大，所以，优先选择适配继承方案，同时也可行。该方案对于模型管理更简单，模型可以直接由旧系统产生，再由新系统实时拉取；新配置系统在旧配置系统的基础上运行，可以将新系统和旧系统定义为上下两层，下层是运行时配置系统，上层是离线集中配置系统；如果新系统存在不足，可以利用旧系统补短。这是新旧系统的物理部署形式，即4+1视图模型的物理视图，系统工程人员利用该视图可以进行系统拓扑、安装和通信。

从4+1模型视图的应用场景分析配置系统。其主要应用场景有版本升级更新配置系统（系统也可能存在运行时自我调优需求），业务扩张开设新站点，大数据基于主题的配置。版本升级需要基于现有配置进行配置，需要将新增的配置下发到下级，将不同的配置下发到下级配置系统，可以称之为差异下发。如何产生差异？需要比较。在升级前保存快照，然后基于快照和配置好的配置产生增量差异数据，进而可以将差异数据下发到下级配置系统。于是需要一个比较模块智能分析数据产生增量数据，这样可以满足版本升级需求。对于业务扩张，其本质大同小异，只是条件不完全一样，需要调整版本升级实现的前置条件，即可满足业务扩展，开设站点。至于大数据基于主题的应用，比如某种场景对无线通讯系统的调优，可以采用数据仓库风格架构方案来解决。

从上面的需求分析看，4+1视图的逻辑视图最终用户的功能需求已逐渐明晰，该新系统基于模型配置，需要导出导入进行配置，基于数据比较产生增量数据做下发。

最后从4+1模型视图的进程视图分析该新配置系统。该新系统可以配置各个模型产品，具有可伸缩性，可能运行多个相同或者不同的进程实例，需要多进程管理，所以需要引入进程容器，该进程容器中需要一个主进程、业务进程、产品进程以及一些诸如监控日志等扩展性进程。其次，从可移植性以及集群考虑，该新配置系统需要可以作为一个独立的组件或者进程组以插件方式安装到其他系统中去运行。

这些是4+1软件架构模型中主要关注的架构元素，包括结构模型、框架模型、动态模型、过程模型、功能模型。

2 正交软件系统架构

正交软件架构由组织层和线索的构件组成。层是由一组具有相同抽象级别的构件构成，线索是子系统的特例，是由完成不同层次功能的构件组成（通过相互调用来关联），每一条线索完成整个系统中相对独立的一部分功能。每一条线索的实现与其他线索的实现无关或者关联很少，在同一层中的构件之间是不存在相互调用，或者尽量少存在。

从上述正交软件架构的特征可以看出正交软件架构具有如下优点：

（1）结构清晰，易于理解，因为线索功能相互独立，不进行互相调用，结构简单、清晰；构件在结构图中的位置已经说明它所实现的是哪一级抽象，担负的是什么职责；

（2）易于修改，可维护性强，因为线索之间相互独立，对一个线索的修改不会影响到其他线索；

（3）可移植性强，重用粒度大，因为正交结构可以为一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现体系结构级的重用。

根据软件需求，该新配置系统比较适合采用正交软件系统架构。从4+1模型视图分析，该新配置系统有较多的功能点和几个独立类似的模块，这些功能模块可以并行开发；其次，我司从事多年软件项目研发，具有相当丰富的技术沉淀可以复用。endprint

通过进程容器平台组件架构，我们可以在该框架中增加层次和线索，从而可以比较快的实现一个新系统。基于平台进程容器开发可以复用公司既有软件构件；通过多条线索可以进行并行开发。如图1正交软件架构示意图，根据此正交架构，开发人员可以并行开发数据导出、数据导入、数据比较、数据下发、产品n，因为这几个模块相对独立，互不影响，所以，可以彼此独立地进行开发，从而可以提高开发效率；对于公共API、平台和进程容器各个模块可以复用，从架构上减少重复度；通过进程容器，可以根据实际情况动态弹性伸缩，动态弹出产品n实例，退出产品n实例，并加载卸载产品n模型。

3 数据工厂模式架构

图2是数据工厂模式架构的体系结构图。从4+1模型软件架构建模分析，为了配置简单，配置数据分为在线数据、离线数据和配置数据，进一步明确抽象为设备数据区、设备镜像区和设备设置区。以数据工厂模式架构，该系统形成数据工厂系统、设置管理系统和设备系统，而数据工厂系统包括设备镜像区和设备设置区。对于设备设置区，虽然设备镜像区基本不变，但是由于设备可能会由于多用户操作，以及设备的自我调優，存在着变化，所以一般把设备设置区进行读写分离，分为基准区和规划区，基准区用来读，规划区用来写；然后基于数据比较产生下发数据。这种根据读写分离分区的产生下发数据的方案冲突性较少，效率比较高，只是，其数据存在着重复性，存在数据重复复制的开销。第二种方案是直接只记录增删改的最终记录，如果镜像区不发生变化，这种方案效率应该最好；如果有变化需要解决冲突，进行差异合并，还需要查询镜像区，既读又写，如果对象间有级联关系呢？感觉复杂度上升了很多，效率应该也降不少；另外，这种方案对多用户并发支持不是很好。第三种方案是记录下全部操作日志，最后统一批量处理，这种方式延后处理，势必导致用户感觉操作效率低下，不是可选方案（本文后续以第一种方案来讨论这种配置系统的架构设计及实现）。

数据工厂集中配置工作过程。设置中心根据业务需求创删设置，利用设备设置区继承数据镜像区所有对象信息，直接在数据中心批量处理，并且分组分片分区最优多流水线作业处理，在设备设置区存贮删除设置实例的目标数据和源数据。基于比较智能分析设备设置区内的目标数据和源数据，进行正确性检查，生成设置脚本。设置脚本的生成按照已经定义好的规则协议生成设置脚本。产生设置脚本前，对第一比对结果和第二比对结果进行比对校验冲突性，如果有冲突进行冲突解决和差异合并；产生设置脚本前根据预先设置保存在规则知识库中的规则对增量进行合法性检查，保证设备在配置前后不存在冲突，是合法配置，从而保证产生的脚本的正确性。最后，将设置脚本下发激活到设备系统。

4 管道过滤、解释器模式、MAP-REDUCE混合架构

数据工厂模式架构风格的集中配置系统的体系结构、工作过程及实现方案已经做了相关阐述，其中基于比较的差异数据的产生是一项比较具有挑战性的工作。

比较的挑战在于需要将关键字对齐后才能比较。对齐意味着需要排序，排序最简单的方式是先把配置数据全部拉取出来后排序，再依次比对产生差异结果，但这意味着内存累积，内存冲高，如果数据量大，系统会内存溢出退服；结构体数组扩展，如果处理不好会出现同样的问题，导致内存冲高，服务最后变得不可用；比较不仅用于产生差异数据，还用于冲突检查和合法性检查，如果效率不高，会影响用户的体验，所以如何提升效率也是一个重中之重；再次，如何将比较应用于各种产品，使其兼容各种产品，也是该配置系统项目关注的重点。目前通讯系统发展迅速，其系统配置数据量越来越大，减少内存资源使用势在必行，需要优先考虑。通过分析决策，对该配置系统采用管道过滤流式架构风格，其内存资源使用只占用基本内存，不会冲高，运行起来稳定。

管道过滤模式由构件和连接件组成，构件有输入和输出，读取输出流，经过内部处理，产生输出流，可以称之为过滤器；连接件将一个过滤器的输出传到另一个过滤器的输入，就像数据传输的管道一样。本配置系统中，构件包括数据中心、应用层差异拉取件、应用层脚本生成件、应用层合法性检查件和应用层冲突检查件。应用层构件和数据中心构件通过JDBC的流式组件实现管道传输，应用层件间通过队列传输数据，构件间形成生产者消费者模式。

为了兼容各种产品，比较基于模型采用解释器架构开发。对于每个对象，基于模型解析对象信息，由软件智能生成比较脚本，然后提交数据中心，由数据中心编译后或者直接执行。在数据中心，关键字信息对齐后，流式比较记录产生流式结果，输出到管道中，同时由应用层拉取。在效率上，动态执行由于额外的解析等因素，一般慢于静态执行，但是动态执行兼容性和适配性更好；而静态执行虽然效率高，但是适配性差，代码脚本重复性高。本系统脚本生成结合了动态脚本和静态脚本的优势，在整体上采用动态脚本，在局部上部分采用静态脚本，比如定义一些特殊类型等。

管道过滤流式模式解决了内存资源问题，下面讨论MAP-REDUCE如何解决效率问题。MAP-REDUCE模式其实是分而治之的典型应用，包括将待处理对象分组并行执行，将业务流程分阶段以生产者消费者以管道过滤模式并行执行。本配置系统在处理上，将配置对象分成不同级别的Master-Work组，以生产者消费者模式分阶段并行执行，比如，数据中心产生差异结果为第一阶段，应用层拉取差异结果为第二阶段，生成下发脚本、合法性检查、冲突检查为第三阶段，下载激活为第四阶段。分阶段执行，阶段间需要传递关键信息，以处理比如有严格顺序要求的配置命令生成需求。

采用profile比较机制，采取解释器模式，根据配置模型的描述信息生成比较脚本，然后执行该脚本，得到差异对象信息。具体地，上述脚本生成子单元具体用于根据预置模型对象中预置的分组信息和对象描述信息，对应于每一分组生成一用于比较该分组中对象的比较脚本。由于命令生成采用管道过滤器模式，其占用的内存基本可以忽略。通常来说，管道过滤器模式不适合关联复杂的数据处理，但是本实例实施采用MAP-REDUCE模式，可以处理有严格顺序要求的配置命令生成；内存消耗低，可以采用高并发方式提高效率；同时，其并发参数可以热配，从而伸缩性很好。

5 结论

该系统采用进程容器、平台组件、正交软件架构，使系统具有可伸缩性、可移植性、易扩展性；在实现中使用了推拉机制、冲突解决机制、差异合并机制、合法性检查机制，确保了数据高效正确下发；创建设置利用设备设置区继承数据镜像区所有对象信息，直接在数据中心批量处理，并且分组分片分区最优多流水线作业处理，具有高效性、安全性和扩展性；根据设置主题引导用户进行主题设置，用户使用更加简单快捷；检查设置基于模型在数据中心高速缓存中归集，以管道方式比对，效率高，内存低，性能稳定；脚本生成智能分析设备数据并生成设置脚本，虽然实现比较复杂，但应用简单，自动化高。总而言之，该集中配置系统智能、简单、高效、安全。

参考文献

[1]张友生.软件体系结构原理、方法与实践（第2版）[M].北京：清华大学出版社，2014：70-71.

[2]王友亮，王志鹏，汪星，吴振宇.集中配置方法及装置：中国，CN201410721006.8[P].2014-12-03.

作者单位

上海中兴软件有限责任公司 上海市 201203endprint