嵌入式系统可视化编译平台设计

陈凡

（福建星网锐捷网络有限公司 福建省福州市 350002）

在数据通信领域，通信设备使用的嵌入式系统愈来愈大，模块众多且功能复杂，加上生命周期长（可提供7-10 年的软硬件支持）。操作系统使用svn，git 为进行软件版本管理，整个操作系统包含上百个仓库，每个仓库由不同负责人独立维护，如此多模块的持续开发给每天的编译量带来极大挑战。[1]

图形化，可视化单机编译具有简单直接，方便理解，可重复提交等优点。已经在编译中普遍采用。[2]

随着系统集成能力，计算能力要求越来越高。集成编译成为迫切需求，单机编译无法满足新的需求场景。而且单机编译环境均部署于本地。容易出现本地编译压力大，配置环境不同，工程修订没有健全版本跟踪导致编译失败等问题。

为解决这类问题，本文提出嵌入式系统可视化编译平台方案，用户仅通过Web 端提交编译任务，查看编译结果，将编译工作部署到作业集群，由传统的单机低效的编译模式转换成集群高效的编译模式。有效解决单机编译所带来的问题，提高核心代码的安全性。

1 系统设计

1.1 系统架构

编译平台由客户端、Web 服务端、作业集群和数据中心4 个子系统组成。

其中Web服务端提供任务提交页面及接口，展示任务编译进度，历史任务和版本查询等功能。作业集群进行源代码下载与编译操作，响应Web 服务端的编译请求，支持并行编译。数据中心包含非关系型数据库存储编译数据及svn，git 代码库。Web 服务器与客户端之间采用nginx 进行反向代理，达到负载均衡之目的。

客户端通过Web 服务端提交编译任务后，Web 服务端根据调度算法计算作业集群服务器的利用率，提交任务至资源空闲的编译服务器。作业集群根据任务指令启动编译任务，然后返回编译结果。系统架构如图1 所示。

系统架构灵活、可扩展。Web 服务端可增加灾备并部署负载，以加快用户量不断提升的访问速度。作业集群采用并行架构，可根据作业量扩充新的编译服务器。数据中心支持扩展数据节点，适应存储扩容需求。

1.2 风险点及应对策略

编译平台在解决单机编译所带来的问题，可能引入新的风险点。以下针对应用风险进行分析，给出解决方案：

1.2.1 作业集群能否满足大量的并发编译需求

解决方案：

传统编译服务为了提高编译效率直接采用物理机而非虚拟机技术。在物理机直接安装Linux 系统，配置1-2 个编译数进行编译。如此操作无法充分利用服务器硬件资源，在两个编译同时使用的公共资源时，会造成抢占。物理机出现硬件故障，迁移也十分麻烦。

图1：系统结构图

图2：Web 提交任务流程图

因此引入docker 容器，编译采用docker 容器方式。和传统编译方式相比，docker 就相对轻便。其将应用程序与程序依赖，打包在一个文件里面。运行这个文件，就会生成一个虚拟容器。程序在这个虚拟容器里运行，就好像在真实的物理机上运行一样。docker容器没有虚拟硬件，无内核，编译进程运行在宿主机内核，拥有启动快、运行环境一致、资源占用少、迁移方便和轻松的维护扩展特点。

编译环境结合docker 容器的3 个基本元素：编译镜像文件，编译容器和编译仓库进行部署。

配置编译镜像文件系统，包含编译需要的程序资源，配置文件，编译工具等文件。分层存储。编译镜像文件构建后基本不改。

配置编译容器，一台物理服务器创建2 个docker 容器。每个容器根据端口号区分，独立完成编译任务。当作业集群收到客户端的编译请求后，会根据调度算法挑选出最适合的服务器执行编译任务。这样比传统在物理机编译方式更加安全。

配置存储和分发编译镜像的仓库。通过标签来区分，不同架构，不同阶段的镜像文件。

1.2.2 编译任务的稳定性和可靠性

解决方案：

为了提高系统任务调度的稳定性和可靠性，作业集群每台服务器都增加监控进程。对编译服务器进行监控。若出现异常，如程序无响应，CPU 使用率过高或内存使用率过高，git 或svn 代码下载超过30min。则强制结束该任务并邮件通告管理员。

1.2.3 数据中心存储介质损坏或停电时存在风险

解决方案：

总体采用两地三中心方式，实现多机房热备数据。

源码库通过Heartbeat，keeplive 等开源软件来实现主从复制。主机故障或断电时自动切换到从机，主从定期同步。

数据库采用自带的双机热备功能。

2 关键模块的设计实现

2.1 作业集群

为使编译服务器能支持高并发的编译任务，编译集群的调度算法需要能开展高效的弹性管理。能够根据弹性伸缩规则进行配置，在编译高峰期作业集群的编译数合理分配；在编译低谷期，编译资源合理利用。从而促进资源利用率的提高。

弹性集群资源调度算法。针对编译作业集群包括编译运算等，按照以下分配原则配置：

（1）首先对作业集群的节点及容器进行数据统计，规划分析。

（2）设定阈值，通过实际运行情况调整阈值。

（3）将容器实际使用资源与设定的阈值比较，得出更优的性能调度方案。

（4）根据调度方案。需要扩展的编译工程，对应宿主机增加新建容器，需要压缩的编译工程，对应宿主机将容器消除。[3]

近些年，随着国家供给侧结构性改革的不断推进，以及外部宏观形势的改变，国内化肥领域遇到了巨大的困难和挑战。化肥作为农业生产中必不可少的资料，对于作物的生长具有着重要的意义。传统肥料产业方面，因传统肥料肥效期短，且养分容易流失，已经成为制约我国农业发展的主要原因，如今面临着政策和市场的双重挑战，转型升级已经成为产业发展当务之急。而新型肥料具有高效、绿色、环保等优点，是实现农业发展和环境保护的强有力助推，新型肥料也将迎来一个势头强劲的产业风口。

通过上述步骤，就可以进行基于资源使用量的调度操作，资源使用量的相关计算过程介绍如下：

（1）成功编译作业数：L1 = 当前服务器同类任务3 月内成功编译作业数/所有服务器同类任务3 月内成功编译作业数*100%

（2）cpu 占 用 率：L2 = CPU 资 源 占 用 空 间/CPU 总 空 间*100%

（3）内存占用率：L3 = (内存总量 - 剩余内存)/内存总量*100%

（4）作业磁盘使用率：L4 = (作业磁盘总量 – 作业磁盘剩余量)/作业磁盘总量*100%

采用资源分配最均衡算法公式，取V 值：

取V 值最小的服务器作为作业服务器。

当Web 服务端收到客户端的编译请求后，调度服务器会根据上述的资源调度算法挑选出合适的容器进行编译。

2.2 数据中心

编译农场数据库需要：支持高并发读写；编译任务配置文件存储为文本文件，可以索引或全文索引；支持架构集群。

综上需求，数据库采用postgreSQL 作为数据中心基础数据库。

为提高数据库执行效率。postgreSQL 采用Postgres-XL 开源集群方案。将postgreSQL 的SQL 解析层的工作和数据存取层的工作分离到不同的两种节点上，分别称为Coordinator 节点和Datanode节点。[4]

Coordinator 节点维护着数据的存储信息，但不存储数据本身。接收到一条SQL 语句后，Coordinator 解析SQL，制定执行计划，然后分发任务到相关的Datanode 上，Datanode 返回执行结果到Coordinator，Coordinator 整合各个Datanode 返回的结果，最后返回给客户端。

Datanode 节点负责实际存取数据，在分片模式下，一个表的数据按照指定的规则分布在多个数据节点上，这些节点共同保存一份完整的数据。

嵌入式系统源码采用版本控制工具git 或svn 进行管理。编译服务器收到编译指令，从git 服务器获取编译分支代码。

2.3 Web服务端

用户登入Web 页面后根据需求提交编译任务。Web 服务端支持完整编译，组件补丁编译等操作。在填入基础工程及分支信息后，Web 服务端会自动检索给出基线工程及当前版本号，并生成配置文件提交任务。

Web 服务端接收任务后，通过调度算法选择、指定编译服务器。

Web 服务端发送配置文件至指定编译服务器，编译服务器根据传入参数至数据中心下载代码进行编译。

编译成功则输出成功文件及打包文件；编译失败则输出失败log。

编译结果及版本保存数据中心，支持用户通过鉴权后即可查询，调阅。

这个过程全程可视化，用户可跟踪。

以上流程如图2 所示。

3 总结

本文设计并实现了嵌入式系统可视化编译平台。该平台分离了任务和编译数据处理，把编译任务和数据统一交给编译集群和数据中心处理。用户只保留任务提交操作界面。这样大大提高编译效率和源代码安全性。目前已经开始在实际工程中应用，在实践中检验效果。