陳凡

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

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

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

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

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

1 系統(tǒng)設計

1.1 系統(tǒng)架構

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

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

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

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

1.2 風險點及應對策略

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

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

解決方案：

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

圖1：系統(tǒng)結構圖

圖2：Web 提交任務流程圖

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

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

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

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

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

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

解決方案：

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

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

解決方案：

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

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

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

2 關鍵模塊的設計實現(xiàn)

2.1 作業(yè)集群

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

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

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

（2）設定閾值，通過實際運行情況調整閾值。

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

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

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

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

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

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

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

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

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

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

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

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

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

綜上需求，數(shù)據(jù)庫采用postgreSQL 作為數(shù)據(jù)中心基礎數(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ā)任務到相關的Datanode 上，Datanode 返回執(zhí)行結果到Coordinator，Coordinator 整合各個Datanode 返回的結果，最后返回給客戶端。

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

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

2.3 Web服務端

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

Web 服務端接收任務后，通過調度算法選擇、指定編譯服務器。

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

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

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

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

以上流程如圖2 所示。

3 總結

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