金融行业 DevOps 解决方案，第 3 部分支持异构平台及多语言的统一构建平台

最新推荐文章于 2025-06-23 10:59:16 发布

先知摩西

最新推荐文章于 2025-06-23 10:59:16 发布

阅读量929

点赞数

分类专栏： DevOps 文章标签： DevOps

DevOps 专栏收录该内容

6 篇文章

订阅专栏

针对国内金融行业在软件版本自动化构建中遇到的挑战，本文介绍了一种基于BuildForge的统一构建解决方案，支持异构平台及多开发语言，实现构建过程自动化、标准化。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

国内金融业软件开发组织在版本自动化构建上通常面临的挑战

在整个 DevOps 流水线工具平台中，软件版本构建作为其中非常关键的一个技术环节，起着连接开发、测试和运维三个部门的中心连接节点作用，通过版本构建后生成的构建包，开发部门会将其部署到测试环境进行测试，而运维部门则会将其发布到生产环境供实际用户使用。根据本文作者多年的现场实施经验，即便对于这么关键的环节，对国内金融行业的很多 IT 组织来说，仍然会面临如下的挑战。

对不同开发平台、不同开发语言的统一构建支持
对一个大型金融企业来说，其显然不会只使用一种开发平台，按照应用性质和类型的不同，往往会采用多种不同的开发平台，比如主机 As400、Windows、Aix、Linux 等等，而由于开发语言的多样化，即便对于同一平台，也往往会采用多种不同的语言，如 Java、C++、C# 等，不同的平台、不同的语言，往往其涉及的技术和构建方式等都会不同。从组织级的角度来说，如果对不同的平台、不同的语言采用不同的构建管理平台和操作方式，虽然技术上可行，但是显然，这必定会加大自动化构建的实施难度和复杂度。因此，如何通过统一的自动化构建平台支持不同开发平台、不同开发语言的自动化构建就成了大型金融企业版本自动化构建所面临的挑战。
从组织级别层面对不同环境自动化构建的统一支持管控
对于大型金融企业来说，为了保证输出到生产环境构建包的质量，往往需要从组织层面对各个环境的自动化构建进行统一规范，而从实际执行层面来看，只有项目团队才是构建的真正执行者，也只有他们才能够知道如何进行构建。对于目前大部分的大型金融企业，在组织级层面上往往都缺乏有效的管控手段去保证规范的落地以及执行过程的跟踪，故而常常会引起类似如下问题：
1. 大多数编译构建都是由人工手工执行；一旦构建出现问题，构建过程很可能无法重现；
2. 对于目标码没有正确的版本管理，只是将构建包存放在 ftp 或者本地文件系统，导致日久历史目标码找不到或者很难找到。
3. 不同测试阶段（比如集成测试和系统测试）的构建环境没有统一管理，从而容易出现由于构建环境不同而产生的构建失败或者构建包错误等问题 ;
4. 生产上线包由开发团队自己构建，格式难以统一，质量难以保证，也很难做到对上线包的管控。

以上问题的存在，会导致 DevOps 流水线工具平台中的目标码构建包管理混乱，效率低下，从而阻碍整个流水线的流动。针对这些客户痛点，我们设计并实现了基于 Build Forge 的支持异构平台及多开发语言的统一构建解决方案，从而消除了流水线流动的障碍。

基于 Build Forge 的支持异构平台及多开发语言的统一构建平台

在构建包的构建过程中，为了保证构建包的质量，同时也为了不受其他环境的污染，一般情况下，编译人员都会要求编译环境必须是纯净的，也就是说一个 JAVA 的编译机器上面，不能同时是 Delphi 或者是 .Net 等其他语言的编译环境；同理，.Net 的编译机器也不允许上面有其他语言的编译环境。而对于一个项目来说，其往往会涉及到多种开发语言，甚至多个开发平台，这种情况下，基于其项目开发流所打出的快照中也往往会包含多种语言的源代码。因此，在具体编译时，就需要把这个快照分别下载到各个不同类型的编译机器上去一一执行对应的构建。对于编译的这个具体过程，不管对于什么平台，什么开发语言，实际上都只需要提供三个要素即可执行，即：需要编译什么？如何编译？去哪个环境编译？本文的方案正是基于对这三个要素的获取进行设计的，其落地实施是通过集成 RTC 和 Build Forge 进行的。

根据 RTC 组件的概念，本文假定（实际上也是）RTC 每一个组件自身的开发语言类型和编译方式都是固定的，基于此，提出组件编译引擎的概念，每一个组件都可以有一个固定的编译引擎；同时，由于每个组件自身的编译方式也是固定的，那么我们可以通过某种方式记录每一个组件的编译方式（即执行编译的指令）以便可以循环复用。在这个实际方案中，我们采用了 Excel 表格，我们称之为“编译申请表”。我们正是采用这样的表格来记录上面提到的编译三要素，并且把参数变量固化下来，为异构平台多开发语言的统一构建提供基础。该申请表的格式如表 1 所示，其中，项目区域是用于指定 RTC 里快照所在的项目区域；RTC 流则用于指定快照所在的流名；快照编号用于指定参与构建的快照名；组件名称用于指定参与编译的组件；构建引擎用于指定组件编译引擎；编译脚本则用于告诉编译引擎如何执行具体编译。

表 1. 编译申请表格式

项目区域	RTC 流	快照编号	组件名称	构建引擎	编译脚本
演示项目	Demo_SIT_02	SIT_02_160620_01	WEB	SIT_14.36	mvn deploy
演示项目	Demo_SIT_02	SIT_02_160620_01	ODP	SIT_14.37	ant build.xml
演示项目	Demo_SIT_02	SIT_02_160620_01	CoreService	SIT_14.37

统一构建平台的方案的运作流程是：

组织级编译人员基于开发团队不同程序语言及编译环境需求，创建各种类型的编译环境，并将该编译环境注册到 Build Forge 作为服务器，同时在 RTC 里面创建同名的构建引擎（如图 1 所示），并公布编译引擎列表给各个产品开发团队。
图 1. RTC 服务器上实际构建引擎示例
各开发团队维护一个全量的编译申请表，这个申请表里面登记了所有组件的编译引擎和编译方式。
开发团队在提交编译的时候，只需要在 Excel 申请表里面写明本次编译的源码所在的项目区域 / 流 / 快照 / 组件，并将该申请表上传到某个预先制定的目录下，然后在 RTC 发起对应构建定义的构建请求。这样就完成了一个请求构建的过程。
统一构建平台接收到 RTC 构建定义发起的请求，在 Build Forge 控制台实例化一个 BF 作业。
BF 作业主要包含 6 个步骤：
1. 读取 excel 表格，获取关键数据，依据 RTC 里面设定的通用构建定义模板，按照“项目区域 - 快照 - 构建引擎”分组并生成临时构建定义；
2. 获取在预处理发现有问题的快照信息，后续不予处理；
3. 多线程发起这些本次生成的临时构建定义。执行机器可能是多台，根据不同的构建引擎分布在不同的机器上执行代码下载和编译指令，并将构建结果回写到 excel 申请表；
4. 在各个编译引擎上执行收集编译结果的命令，将编译结果上传到文件服务器；
5. 在文件服务器上，将本次编译结果按照快照编号分组，按组打包，格式为 zip 文件；
6. Build Forge 将本次编译结果反馈给 RTC，用户在 RTC 界面即可查看构建结果。

该统一构建平台的优势在于，把原本需要人工进行的编译转化为系统自动化，在提高编译效率的同时也减少了人工执行导致的编译出错，也促使开发团队的编译进一步规范化。该平台构建不需要区分编译语言类型，平台只关注业务，所有语言采用统一的编译规范，使得平台可以达到支撑异构语言多平台构建的目标。

基于 Build Forge 的自动化构建平台高可用架构

对于统一构建平台来说，其日常运行中最主要的问题就是如何保证构建平台的负载均衡、高可用，以及如何支持多个服务器同时在线，并且它们能共享同一份构建业务数据和构建配置数据，从而保证当一个服务器不可用时，能够自动切换到其他服务器。这其实是 Build Forge 产品本身的优势之一，也是目前比较流行的开源工具 Jenkins 无法实现的。而 RTC 与 Build Forge 的集成则天然具有自动轮询分配作业 / 分配作业给在线 Build Forge 服务器的功能。具体实现包括两个部分： Build Forge 控制台服务器的高可用和构建引擎的高可用。

Build Forge 控制台服务器的高可用方案

图 2. Build Forge 多节点同时在线高可用架构

Build Forge 多节点同时在线高可用架构

在本文的实施方案中，如图 2 所示，我们部署了两套 Build Forge 服务器，并同时让它们连接到同一个数据库，在 RTC 里面创建两个 Build Forge 的构建引擎，并将这两个构建引擎分配给同一个构建定义。通过这种优化方案，对于同一个构建定义所发起的请求，就会被轮流发送到两个 Build Forge 构建引擎上，如果有一个构建引擎掉线了（可能这台 Build Forge 服务器宕机了），那么所有构建请求的作业会流向唯一在线的那个 Build Forge 服务器。

构建引擎的高可用方案

这里主要用到构建引擎服务器池的思路，通过建立 Build Forge 的选择器和收集器，将多个构建机器（包括物理主机／虚拟机／云平台主机）注册为 Build Forge 服务器，并让它们关联到同一个 Build Forge 收集器。然后配置选择器关联该收集器，就可以实现智能选择有空闲资源的编译机器来处理构建作业，配置过程如以下 4 步所示。

新建收集器。管理员登录 Build Forge 服务器，在左边菜单找到“服务器”--> “收集器” --> “添加收集器”，如图 3 所示，然后设置需要被收集的操作系统参数，如图 4 所示。
图 3. 添加收集器

图 4. 设置操作系统参数
新建选择器。在左边菜单找到“服务器”--> “选择器” --> “添加选择器”，添加各种选择参数，可以设置与收集器对应的参数。
图 5. 新建选择器
新建服务器并为其添加收集器。在左边菜单找到“服务器”--> “添加服务器”。
关联选择器到 Build Forge 项目。在左边菜单找到“项目”，找到对应的项目，选择编辑项目，为项目添加运行时的选择器。