陈显炉，李建文，于凯

深圳云天励飞技术股份有限公司，广东深圳，518000

0 引言

软件版本管理是软件研发过程中重要的环节，是指对软件开发过程中产生的代码和文档进行版本控制，以保证开发的代码、文档能够正确发布、分发和维护。近年来，国内外很多研究人员和企业都在尝试基于软件版本管理系统实现分布式版本管理，虽然基于开源项目开发的分布式软件版本管理系统具有低成本、易维护和可扩展等优点，但这些系统仍然存在一些问题，例如系统部署的调整、系统功能和性能的升级等，严重影响系统运行的稳定性[1]。因此，系统组件的软件版本的维护操作在实际的系统中是一个不可避免的情况，甚至是经常出现的情况。设计实现适用于分布式集群系统中的软件版本分发管理系统，对于系统的可维护性、稳定性、运行的可靠性等指标具有重大的意义和价值。

1 现有分发管理系统版本存在的技术问题

1.1 版本的协同性差

常见的版本分发系统在使用中存在协同性差的问题，升级测试比较难协调统一进行，在出现问题后，也比较难协调统一地进行版本的回退或其他能暂时规避问题的操作等，例如在版本发布后，如果遇到某些问题，需要回退到上一个版本进行测试，又或者是新版本发布后遇到问题，需要回退到上一个版本进行解决。这些功能在传统的分发系统中并不存在，因此在实际工作中往往需要手动进行相关操作，既降低了工作效率，也增加了错误率[2]。

1.2 版本兼容性不足

常见的分发系统的功能模块基本是针对单个产品进行开发的，对其他产品不一定都能够支持。软件产品的版本越来越丰富，但由于不同平台、不同开发语言等原因，不同用户在使用同一款产品时会遇到各种各样的问题，这就导致软件产品难以适应各种用户场景[3]。因为不同软件产品的特性不同，在功能上有可能存在较大差异，这样就可能会出现版本兼容的问题。并且现有的版本分发系统都是以本地为中心的，所以存在一个问题，就是当本地版本发生变更时，无法在各个渠道中及时同步。

1.3 缺少可回溯性信息

历史可回溯性信息是软件产品版本管理系统的重要组成部分，通过历史可回溯性信息可以帮助我们发现问题、定位问题，并及时进行修复。但目前的常见分发系统中，历史可回溯性信息并不完善，甚至没有。一方面是因为版本分发系统的历史数据都存储在本地服务器上，如果需要查看历史数据就需要访问本地服务器，如果本地服务器没有历史数据，就无法查看；另一方面是因为版本分发系统大多都是采用单机架构设计的，不具备分布式能力。因此在后续的版本管理中，需要在分发系统中增加历史可回溯性信息，以便查看各个分支版本之间的关系[4]。

2 无中心化的分布式软件版本分发管理系统设计

2.1 分层次的版本的存储规范

2.1.1 版本元信息存储

对软件版本元信息进行存储，一方面可以为软件版本管理提供有效的数据支持，另一方面也是对版本元信息进行有效存储和管理的必要手段。通过对软件版本元信息进行存储，可以保证不同用户对版本信息的访问需求，同时也可以减少对版本管理系统的维护工作。基于这一思路，本文设计了如图1所示的版本元信息的存储结构，在该结构设计中，实现了分层的元信息存储。其中版本分为大版本和组件版本，大版本由组件版本构成。大版本的元信息存储组件的版本的元信息的链接，以保持数据的一致性和节省存储空间。每个大版本与小版本之间存在网状映射关系，具体而言，同一个组件版本可由多个大版本共享，每个大版本中的组件版本可来自批次版本。大版本与组件版本之间，通过元数据映射组成灵活的版本组合[5]。

图1 分层次的版本元信息的存储和映射结构

2.1.2 版本文件数据存储

数据存储是软件版本分发管理系统的核心，也是整个系统的核心功能。通过对已有版本数据存储模式的分析，本文提出了如图2所示的版本文件数据存储结构，主要是指版本元信息的格式与数据映射关系。组件版本的元信息包括组件版本号，这是随着组件的迭代发布依次递增的版本号，包括构建的日期及构建功能版本等信息，可以判断出两个版本之间的更新关系。版本的唯一标识号由唯一标识生成算法生成，如UUID生成算法。版本的存储路径可能是本地文件系统，也可能是网络地址。

图2 版本的元信息格式和数据的存储

2.1.3 版本的统一结构规范

版本的统一结构规范规定不管是组件版本还是大版本的格式标准，为了能够按统一的框架和流程来执行版本的部署、升级，统一规定所有组件版本必须按如下格式构成，如图3所示[6]。

2.1.4 版本的兼容性检测用例库

兼容性检测用例库的作用是实现自动化的版本兼容性检查，以实现自动化的版本升级/回溯的验证等。为此，它需要管理各个版本的功能关系对验证这些关系所对应的用例。为了实现以上这些需求，本文提出兼容性检测用例库的结构。一个兼容性检测用例涉及以下三个元素：调用发起组件、调用接收组件、调用的输入/输出。针对以上三个验证要求，本文提出了一种有向多重图的存储结构用于存储兼容性用例。多重有向图存储的方式如下：图中的每一个节点为系统中的一个组件类型，每一个组件类型在这个多重有向图中都存在一个节点。

2.1.5 版本的回溯信息数据库

版本的回溯信息数据库的目标是当某个组件需要进行版本回溯回退的时候，可以快速得到关联组件的回溯信息，即关联的组件的版本是否需要进行回溯及回溯到哪个版本。回溯信息库由两级Map结构构成。第一级Map，其键值为组件的识别符号对，假设在系统中，某两个组件的标识号为ID(x)、ID(y)，则在第一级Map中存在键值为Key(ID(x)，ID(y))的Map项。如果不存在，则创建。第二级Map为某两个组件的两两之间的兼容性检测结果。

2.2 版本元信息的传播机制

版本元信息的传播机制的目标是在网络传递版本元数据信息，其网络中的每一个节点都掌握当前最新版本信息，其包含如下过程。

第一，由版本发布者发布新的版本的元信息及其相关的数据文件和其他必要的信息内容，设这些被注入版本信息的节点为Node(update)。

第二，在开发阶段，为了节约带宽，Node(update)仅抽取版本信息中的版本号信息向外广播传递过程。

第三，Node(update)为源节点，它在自己的所有网络接口上广播新的版本号消息。版本号消息包括如图4所示的内容。

图4 版本元信息传播格式

中间节点收到此消息时，进行以下判断：①如果曾经收到过此类消息（组件号和版本号相同），直接结束；②如果没有收到过，首先会在自己的版本元信息存储库中进行记录；③把消息体中的TTL减1，如果结果为0，则不转发，直接结束；④如果TTL不为0，则中间节点向这条消息进入的网络接口以外的网络接口进行转发。

消息按此机制在网络传播，直到所有节点都收到或消息的TTL减为0为止。当以上过程完全结束后，网络中的每个节点都知道集群中每个软件的组件的最新版本是什么，及节点自己是否有这些版本的本地拷贝。同时，以比较低的频度，每个节点会向网络中广播自己掌握的所有组件的版本号信息，消息的传输过程与新注入的版本信息的传输过程基本一致。

2.3 版本的数据文件传输机制

第一，每个节点根据自己掌握的分层次的版本的存储部分所描述的信息，决定向网络中发起某组件某版本的数据传输请求，设置传输请求所对应的数据为Data(Model(x)Version(y))。

第二，网络中，只有少数节点拥有Da t a(Model(x)Version(y))的本地版本，所以大部分节点都会发起传输的请求操作。

第三，所有节点按统一约定的规则（如按固定大小切块），对Data(Model(x)Version(y))进行切块，设得到的块数为(1,m), 并将(1,m)进行批次划分，设为（1,n），则每批次为m/n块数据。

第四，对于每一个网络中的节点，按批次发起传输，一次把当前批次的m/n块同时向外发送请求，请求有这些数据块的节点回应它的请求。发起请求前，根据分层次的版本的存储中掌握的信息，根据一次的时间退避。

第五，每个节点独立重复进行3和4步骤中所述的机制，直到版本中的所有数据都传输完成为止。

2.4 版本的升级/回溯机制

第一，检测当前节点所有组件的待升级的版本，确定当前批次升级所涉及的组件版本及具体的版本号。

第二，维护版本的元数据信息，创建一个新的大版本号，生成大版本号的一个唯一的标识号，根据待升级组件的版本号、不升级组件的版本号等信息，维护当前版本号的组件版本映射信息。

第三，进行备份部署，将待升级的版本通过版本中的config/update/deloy等标准化脚本部署为一个与当前运行的版本并行运行的一个复制运行实例。

第四，在这个复制的运行实例上执行兼容性测试用例库。

第五，如果通过兼容性测试，则进行版本的实际切换，使当前的版本实际上线。同时在回溯信息数据库中记录已经完成的兼容性测试信息。

第六，如果没有通过兼容性测试，则终止此次升级，并清除复制兼容性测试环境的所有组件实例，并进行相关的记录和报错。

3 结论

综上所述，本文所描述的分布式软件版本分发管理系统，将软件版本管理过程从集中式的中心化系统迁移到分布式的无中心化系统，减少了中心化系统对数据安全和效率的影响，提高了数据和操作的安全性。