嵌入式系統(tǒng)可視化編譯平臺設(shè)計

陳凡

（福建星網(wǎng)銳捷網(wǎng)絡(luò)有限公司 福建省福州市 350002）

在數(shù)據(jù)通信領(lǐng)域，通信設(shè)備使用的嵌入式系統(tǒng)愈來愈大，模塊眾多且功能復(fù)雜，加上生命周期長（可提供7-10 年的軟硬件支持）。操作系統(tǒng)使用svn，git 為進行軟件版本管理，整個操作系統(tǒng)包含上百個倉庫，每個倉庫由不同負責人獨立維護，如此多模塊的持續(xù)開發(fā)給每天的編譯量帶來極大挑戰(zhàn)。[1]

圖形化，可視化單機編譯具有簡單直接，方便理解，可重復(fù)提交等優(yōu)點。已經(jīng)在編譯中普遍采用。[2]

隨著系統(tǒng)集成能力，計算能力要求越來越高。集成編譯成為迫切需求，單機編譯無法滿足新的需求場景。而且單機編譯環(huán)境均部署于本地。容易出現(xiàn)本地編譯壓力大，配置環(huán)境不同，工程修訂沒有健全版本跟蹤導(dǎo)致編譯失敗等問題。

為解決這類問題，本文提出嵌入式系統(tǒng)可視化編譯平臺方案，用戶僅通過Web 端提交編譯任務(wù)，查看編譯結(jié)果，將編譯工作部署到作業(yè)集群，由傳統(tǒng)的單機低效的編譯模式轉(zhuǎn)換成集群高效的編譯模式。有效解決單機編譯所帶來的問題，提高核心代碼的安全性。

1 系統(tǒng)設(shè)計

1.1 系統(tǒng)架構(gòu)

編譯平臺由客戶端、Web 服務(wù)端、作業(yè)集群和數(shù)據(jù)中心4 個子系統(tǒng)組成。

其中Web服務(wù)端提供任務(wù)提交頁面及接口，展示任務(wù)編譯進度，歷史任務(wù)和版本查詢等功能。作業(yè)集群進行源代碼下載與編譯操作，響應(yīng)Web 服務(wù)端的編譯請求，支持并行編譯。數(shù)據(jù)中心包含非關(guān)系型數(shù)據(jù)庫存儲編譯數(shù)據(jù)及svn，git 代碼庫。Web 服務(wù)器與客戶端之間采用nginx 進行反向代理，達到負載均衡之目的。

客戶端通過Web 服務(wù)端提交編譯任務(wù)后，Web 服務(wù)端根據(jù)調(diào)度算法計算作業(yè)集群服務(wù)器的利用率，提交任務(wù)至資源空閑的編譯服務(wù)器。作業(yè)集群根據(jù)任務(wù)指令啟動編譯任務(wù)，然后返回編譯結(jié)果。系統(tǒng)架構(gòu)如圖1 所示。

系統(tǒng)架構(gòu)靈活、可擴展。Web 服務(wù)端可增加災(zāi)備并部署負載，以加快用戶量不斷提升的訪問速度。作業(yè)集群采用并行架構(gòu)，可根據(jù)作業(yè)量擴充新的編譯服務(wù)器。數(shù)據(jù)中心支持擴展數(shù)據(jù)節(jié)點，適應(yīng)存儲擴容需求。

1.2 風險點及應(yīng)對策略

編譯平臺在解決單機編譯所帶來的問題，可能引入新的風險點。以下針對應(yīng)用風險進行分析，給出解決方案：

1.2.1 作業(yè)集群能否滿足大量的并發(fā)編譯需求

解決方案：

傳統(tǒng)編譯服務(wù)為了提高編譯效率直接采用物理機而非虛擬機技術(shù)。在物理機直接安裝Linux 系統(tǒng)，配置1-2 個編譯數(shù)進行編譯。如此操作無法充分利用服務(wù)器硬件資源，在兩個編譯同時使用的公共資源時，會造成搶占。物理機出現(xiàn)硬件故障，遷移也十分麻煩。

圖1：系統(tǒng)結(jié)構(gòu)圖

圖2：Web 提交任務(wù)流程圖

因此引入docker 容器，編譯采用docker 容器方式。和傳統(tǒng)編譯方式相比，docker 就相對輕便。其將應(yīng)用程序與程序依賴，打包在一個文件里面。運行這個文件，就會生成一個虛擬容器。程序在這個虛擬容器里運行，就好像在真實的物理機上運行一樣。docker容器沒有虛擬硬件，無內(nèi)核，編譯進程運行在宿主機內(nèi)核，擁有啟動快、運行環(huán)境一致、資源占用少、遷移方便和輕松的維護擴展特點。

編譯環(huán)境結(jié)合docker 容器的3 個基本元素：編譯鏡像文件，編譯容器和編譯倉庫進行部署。

配置編譯鏡像文件系統(tǒng)，包含編譯需要的程序資源，配置文件，編譯工具等文件。分層存儲。編譯鏡像文件構(gòu)建后基本不改。

配置編譯容器，一臺物理服務(wù)器創(chuàng)建2 個docker 容器。每個容器根據(jù)端口號區(qū)分，獨立完成編譯任務(wù)。當作業(yè)集群收到客戶端的編譯請求后，會根據(jù)調(diào)度算法挑選出最適合的服務(wù)器執(zhí)行編譯任務(wù)。這樣比傳統(tǒng)在物理機編譯方式更加安全。

配置存儲和分發(fā)編譯鏡像的倉庫。通過標簽來區(qū)分，不同架構(gòu)，不同階段的鏡像文件。

1.2.2 編譯任務(wù)的穩(wěn)定性和可靠性

解決方案：

為了提高系統(tǒng)任務(wù)調(diào)度的穩(wěn)定性和可靠性，作業(yè)集群每臺服務(wù)器都增加監(jiān)控進程。對編譯服務(wù)器進行監(jiān)控。若出現(xiàn)異常，如程序無響應(yīng)，CPU 使用率過高或內(nèi)存使用率過高，git 或svn 代碼下載超過30min。則強制結(jié)束該任務(wù)并郵件通告管理員。

1.2.3 數(shù)據(jù)中心存儲介質(zhì)損壞或停電時存在風險

解決方案：

總體采用兩地三中心方式，實現(xiàn)多機房熱備數(shù)據(jù)。

源碼庫通過Heartbeat，keeplive 等開源軟件來實現(xiàn)主從復(fù)制。主機故障或斷電時自動切換到從機，主從定期同步。

數(shù)據(jù)庫采用自帶的雙機熱備功能。

2 關(guān)鍵模塊的設(shè)計實現(xiàn)

2.1 作業(yè)集群

為使編譯服務(wù)器能支持高并發(fā)的編譯任務(wù)，編譯集群的調(diào)度算法需要能開展高效的彈性管理。能夠根據(jù)彈性伸縮規(guī)則進行配置，在編譯高峰期作業(yè)集群的編譯數(shù)合理分配；在編譯低谷期，編譯資源合理利用。從而促進資源利用率的提高。

彈性集群資源調(diào)度算法。針對編譯作業(yè)集群包括編譯運算等，按照以下分配原則配置：

（1）首先對作業(yè)集群的節(jié)點及容器進行數(shù)據(jù)統(tǒng)計，規(guī)劃分析。

（2）設(shè)定閾值，通過實際運行情況調(diào)整閾值。

（3）將容器實際使用資源與設(shè)定的閾值比較，得出更優(yōu)的性能調(diào)度方案。

（4）根據(jù)調(diào)度方案。需要擴展的編譯工程，對應(yīng)宿主機增加新建容器，需要壓縮的編譯工程，對應(yīng)宿主機將容器消除。[3]

近些年，隨著國家供給側(cè)結(jié)構(gòu)性改革的不斷推進，以及外部宏觀形勢的改變，國內(nèi)化肥領(lǐng)域遇到了巨大的困難和挑戰(zhàn)?；首鳛檗r(nóng)業(yè)生產(chǎn)中必不可少的資料，對于作物的生長具有著重要的意義。傳統(tǒng)肥料產(chǎn)業(yè)方面，因傳統(tǒng)肥料肥效期短，且養(yǎng)分容易流失，已經(jīng)成為制約我國農(nóng)業(yè)發(fā)展的主要原因，如今面臨著政策和市場的雙重挑戰(zhàn)，轉(zhuǎn)型升級已經(jīng)成為產(chǎn)業(yè)發(fā)展當務(wù)之急。而新型肥料具有高效、綠色、環(huán)保等優(yōu)點，是實現(xiàn)農(nóng)業(yè)發(fā)展和環(huán)境保護的強有力助推，新型肥料也將迎來一個勢頭強勁的產(chǎn)業(yè)風口。

通過上述步驟，就可以進行基于資源使用量的調(diào)度操作，資源使用量的相關(guān)計算過程介紹如下：

（1）成功編譯作業(yè)數(shù)：L1 = 當前服務(wù)器同類任務(wù)3 月內(nèi)成功編譯作業(yè)數(shù)/所有服務(wù)器同類任務(wù)3 月內(nèi)成功編譯作業(yè)數(shù)*100%

（2）cpu 占 用 率：L2 = CPU 資 源 占 用 空 間/CPU 總 空 間*100%

（3）內(nèi)存占用率：L3 = (內(nèi)存總量 - 剩余內(nèi)存)/內(nèi)存總量*100%

（4）作業(yè)磁盤使用率：L4 = (作業(yè)磁盤總量 – 作業(yè)磁盤剩余量)/作業(yè)磁盤總量*100%

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

取V 值最小的服務(wù)器作為作業(yè)服務(wù)器。

當Web 服務(wù)端收到客戶端的編譯請求后，調(diào)度服務(wù)器會根據(jù)上述的資源調(diào)度算法挑選出合適的容器進行編譯。

2.2 數(shù)據(jù)中心

編譯農(nóng)場數(shù)據(jù)庫需要：支持高并發(fā)讀寫；編譯任務(wù)配置文件存儲為文本文件，可以索引或全文索引；支持架構(gòu)集群。

綜上需求，數(shù)據(jù)庫采用postgreSQL 作為數(shù)據(jù)中心基礎(chǔ)數(shù)據(jù)庫。

為提高數(shù)據(jù)庫執(zhí)行效率。postgreSQL 采用Postgres-XL 開源集群方案。將postgreSQL 的SQL 解析層的工作和數(shù)據(jù)存取層的工作分離到不同的兩種節(jié)點上，分別稱為Coordinator 節(jié)點和Datanode節(jié)點。[4]

Coordinator 節(jié)點維護著數(shù)據(jù)的存儲信息，但不存儲數(shù)據(jù)本身。接收到一條SQL 語句后，Coordinator 解析SQL，制定執(zhí)行計劃，然后分發(fā)任務(wù)到相關(guān)的Datanode 上，Datanode 返回執(zhí)行結(jié)果到Coordinator，Coordinator 整合各個Datanode 返回的結(jié)果，最后返回給客戶端。

Datanode 節(jié)點負責實際存取數(shù)據(jù)，在分片模式下，一個表的數(shù)據(jù)按照指定的規(guī)則分布在多個數(shù)據(jù)節(jié)點上，這些節(jié)點共同保存一份完整的數(shù)據(jù)。

嵌入式系統(tǒng)源碼采用版本控制工具git 或svn 進行管理。編譯服務(wù)器收到編譯指令，從git 服務(wù)器獲取編譯分支代碼。

2.3 Web服務(wù)端

用戶登入Web 頁面后根據(jù)需求提交編譯任務(wù)。Web 服務(wù)端支持完整編譯，組件補丁編譯等操作。在填入基礎(chǔ)工程及分支信息后，Web 服務(wù)端會自動檢索給出基線工程及當前版本號，并生成配置文件提交任務(wù)。

Web 服務(wù)端接收任務(wù)后，通過調(diào)度算法選擇、指定編譯服務(wù)器。

Web 服務(wù)端發(fā)送配置文件至指定編譯服務(wù)器，編譯服務(wù)器根據(jù)傳入?yún)?shù)至數(shù)據(jù)中心下載代碼進行編譯。

編譯成功則輸出成功文件及打包文件；編譯失敗則輸出失敗log。

編譯結(jié)果及版本保存數(shù)據(jù)中心，支持用戶通過鑒權(quán)后即可查詢，調(diào)閱。

這個過程全程可視化，用戶可跟蹤。

以上流程如圖2 所示。

3 總結(jié)

本文設(shè)計并實現(xiàn)了嵌入式系統(tǒng)可視化編譯平臺。該平臺分離了任務(wù)和編譯數(shù)據(jù)處理，把編譯任務(wù)和數(shù)據(jù)統(tǒng)一交給編譯集群和數(shù)據(jù)中心處理。用戶只保留任務(wù)提交操作界面。這樣大大提高編譯效率和源代碼安全性。目前已經(jīng)開始在實際工程中應(yīng)用，在實踐中檢驗效果。