編者按：本文源自阿里云云效團隊出品的《阿里巴巴DevOps實踐指南》，掃描上方二維碼或前往：http://developer.aliyun.com/topic/devops，下載完整版電子書，瞭解阿里十年DevOps實踐經驗。

構建是將原始碼變成製品的過程。構建包括編譯，但不等同於編譯。即使對於不需要編譯的解釋型語言，也要構建成一個壓縮包或 Docker 映象再去部署。無論是在開發階段還是 CICD 階段，都離不開構建過程，構建的質量和效率對持續交付影響很大。影響構建效率的因素，包括原始碼以及構建的依賴。

背景

在阿里巴巴，Java 是被最多人使用的程式語言。在 Java 的構建工具中，由於遷移成本，生態等原因，Maven 一直是服務端應用的最主要構建工具。

Maven 構建效能問題主要有二方面原因。一是外因，從應用角度看，一些 Java 應用歷史悠久，依賴不斷增加，並因為清理有風險導致累積太多，典型應用有 3000 個 Jar 包依賴，而且這些應用研發人員多，且是跨團隊的，導致依賴管理成本高，依賴變得複雜混亂。二是內因，從 Maven 本身來看，它對複雜依賴的處理考慮欠妥。

對於外因，需要業務團隊建立依賴梳理管理機制。針對內因，我們對 Maven 進行了重新實現，推出了 AMaven。

另一方面，阿里巴巴有 15%的 C/C++應用。C/C++應用與 Java 的最大區別是：Java 應用構建次數頻繁，但每次構建時間短；C/C++應用構建次數少，但一次構建時間長。如某些軟體的構建長達 10 多個小時。所以C/C++開發同學的痛點，除了構建慢外，最不能忍受的還是等了 10 多個小時，最後幾分鐘居然構建失敗了。

那為什麼 C/C++構建慢且容易失敗呢?

原因主要有兩個：

1. 現有框架無法保證 C/C++編譯和連結的嚴謹性，導致編譯結果不確定，執行時也不穩定。舉個例子，在編譯階段，同名的標頭檔案在不同時間或不同機器上會可能內容不同，所以編譯容易失敗。
2. 公司內編譯框架眾多，有 scons，cmake 等，造成團隊之間業務轉接成本高，編譯問題排查成本高。從平臺角度看，也無法觸達使用者真正的編譯邏輯，無法統一效能調優，更進一步無法統一升級底層編譯器 gcc，即無法享受新技術紅利。所以構建慢。

相比 AMaven 是重新實現底層構建工具的 Maven，在 C/C++領域我們主要是建設上層的編譯框架，推出了 Alimake，因為底層的 make 已經很優秀了。

接下來，我們具體來看看 AMaven 和 Alimake。

方案

AMaven

Maven 構建帶來的效能問題，會嚴重影響持續交付的效率。主要體現在以下幾點：

1. 在 idea 中同步時間長，如典型應用需要 10 分鐘左右。
2. 單次編譯時間長，如典型應用也需要 10 分鐘左右。
3. 構建步驟多，在一次交付過程中，不同環境都要構建。
4. 在同一環境中往往會構建多次。

同時，構建效能問題也影響了開發同學的成就感。只寫了幾行程式碼，但一重新整理工程，一本地編譯，就一個上午過去了。一天下來，寫程式碼的時間沒等編譯的時間多。

構建問題影響軟體交付效率

一線研發同學，他的研發工作遠不止體現在研發協同平臺上的操作，在一個分支能進入整合前，有大部分研發工作都是線上下本地完成的。所以線下本地的提效也很重要。從新的 Java 構建工具 AMaven 開始，我們也將提效的視角範圍從線上研發協同平臺延伸到了一線研發本地。

基於 Maven 協議，遵循快取，增量等思想，重新實現了一個工具：AMaven。同時在使用 AMaven 過程中，為保證它構建結果的準確性，在後臺也會使用 Apache Maven 進行構建，並比較二者編譯結果。同時又是基於 Maven 協議，對使用者透明 ，從而做到"無成本，無風險"。

無成本，無風險

 

結果對比，保證無風險

AMaven 對症下藥，主要通過建立依賴樹，快取依賴樹，共享依賴樹來解決依賴複雜問題。一個依賴樹快取是否有效，除了與原始碼中的 pom 檔案有關，還與依賴的 snapshot 變化等有關。當 snapshot 變化時，依賴樹快取就會失效，而需要重新生成依賴樹。為提高依賴樹的生成效率，AMaven 還通過依賴遍歷演算法對依賴樹生成進行了優化，並開放了遍歷深度引數讓使用者來微調。

這些依賴樹資訊同時也會儲存為製品的重要元資料，在"製品元資料"章節中會有詳述。

依賴快取與共享

除了利用快取，增量等思想，AMaven 還做了 C/S 化。即將部分計算能力移到 server 端。使用 AMaven後，一次構建的流程變成如下圖所示:

 

一次典型的 AMaven 構建

AMaven 還增加了迴圈依賴檢測，動態執行外掛等能力，雖不能直接提升構建速度，但加快了研發同學對依賴等構建問題的排查速度。

我們再來看看 AMaven 給使用者帶來的收益與效果。從線上 CICD 平臺數據來看：AMaven 實現了 Java秒級構建，阿里巴巴的 Java 構建中有 44%在 30 秒內完成。其次，從依賴龐大的典型應用來看，提效可達 10 倍。

從線下研發本地資料來看：AMaven 無論是在命令列還是在 IDEA 中使用，都能將構建耗時降至 50%。特別是在 IDEA 中切換分支後重新整理工程時，最快能在 10 秒內完成。

Alimake

Alimake 主要從兩方面入手。

1. 從"規範"入手。首先，建立全新的嚴格的配置檔案 target，所有編譯入參必須嚴格清晰的定義，它會被翻譯成嚴謹的 makefile，它也同時在一定程度上培養了工程師嚴謹自律的文化。接著，建立了一個全新的倉庫 alicpp，它統一存放了原本在編譯機器上的依賴，從而保證編譯的環境無關性，保障編譯結果的強一致性。
2. 從"效率"入手。它不但集成了業界優秀技術 ccache 和 distcc，而且還自研了分散式連結等技術。因為 Alimake 統一了入口，所以它不但能讓專家經驗規模化，統一調優編譯引數，而且還能將升級編譯器 gcc 機制化，讓我們可以隨心所欲，一直跟上編譯器的進步。

Alimake 的架構思想與 AMaven 類似，也是將部分計算能力移到 server 端。利用 server 端一來能減輕client 端的資源消耗，解決 client 端由於硬體及配置帶來的效能瓶頸，二來也能實現資源共享，如依賴快取，中間產物快取。

Alimake 架構

Alimake 覆蓋阿里巴巴多個產品，包括：釘釘、阿里雲端儲存、OSS、盤古、伏羲、螞蟻人工智慧等，平均提升構建效率 30%，最優情況下可以提效 70%。

小結

為提高構建效率，我們從空間（產物大小），及時間（通過工具來提升構建速度）二方面進行了優化。除此之外，還利用構建過程中產生的原生資料（如依賴關係），賦能於持續交付與安全生產等方面，以實現高效的可信的釋出。

---

【關於雲效】

雲效，雲原生時代一站式BizDevOps平臺，支援公共雲、專有云和混合雲多種部署形態，通過雲原生新技術和研發新模式，助力創新創業和數字化轉型企業快速實現研發敏捷和組織敏捷，打造“雙敏”組織，實現 10 倍效能提升。

立即體驗