螞蟻構建服務演進史

簡介：自動化構建和CI/CD往往是相輔相成的，可以理解為，自動化構建是溫飽問題，解決了溫飽就會有更多的提高生產力的訴求，也就是對應的CI平台，CI/CD本篇文章不做擴展。

作者 | 琉克
來源 | 阿里技術公眾號

一構建平台的由來

只要是軟件開發就離不開構建，構建無處不在，構建是源代碼和用戶呈現之間的橋梁。

這里要澄清一點，構建 != 編譯，構建的本質是把源代碼翻譯成運行環境能識別的產物（源代碼可能是Java代碼，也可能是配置文件、資源文件等，運行環境可能是物理機，也可能是虛擬機，也可能是mobile phone）。

所以工程師每天每時每刻都在構建，不構建就沒法驗證。隨着規划的擴大，把構建自動化掉，提供一個“打包平台”也就是一個自然而然的事情，畢竟提高生產力是第一訴求嗎，這也就是構建平台最開始的由來，把每天干的事情自動化掉，搬上平台。

自動化構建和CI/CD往往是相輔相成的，可以理解為，自動化構建是溫飽問題，解決了溫飽就會有更多的提高生產力的訴求，也就是對應的CI平台，CI/CD本篇文章不做擴展。

二理解構建

構建 != 編譯，構建本身是一個很復雜的編排過程。舉兩個例子：

1 Android APK的構建過程

上圖中綠色部分為工具，淺藍色部門為源代碼+中間產物。可以看到是一系列的工具+輸入的編排，最終生成運行環境可識別的產物。上訴構建過程生成的產物(APK)可被Android手機識別並運行。

2 Java Jar包的構建過程

可以看到jar包的構建過程和上面APK的差異非常大，相對來說也是更簡單。

3 構建工具

上面兩個case可以看出來，構建本身很復雜，要最終構建出一個可以運行的產物需要做很多事情，我們完全可以手動javac copy jar等等一系列操作實現構建過程。但當工程越來越大，文件越來越多，這個事情就不是那么地令人開心了。這些命令往往都是很機械的操作。所以我們可以把這些機械的操作交給機器去做。對應的構建工具也應運而生，畢竟提高生產力是第一訴求。

拿Java舉例：

Ant

上面的示例中，Ant定義了五個任務：init、compile、build、test和clean。

每個任務做什么都定義清楚了。在打包之前要先編譯，所以通過depends來指定依賴的路徑。

如果在命令行里執行ant build，那就會先執行compile，而compile又依賴於init，所以就會先執行init。

執行命令：

ant test

通過命令就可以執行編程，打包，測試。為開發者帶來了很大的便利，提供了工作效率。

但是Ant有一個很致命的缺陷，那就是沒辦法管理依賴。

我們一個工程，要使用很多第三方工具，不同的工具，不同的版本。

每次打包都要自己手動去把正確的版本拷到lib下面去，不用說，這個工作既枯燥還特別容易出錯。為了解決這個問題，Maven如約而至。

Maven

Ant僅是一個構建工具，它並未對項目的中的工程依賴以及項目本身進行管理，並且Ant作為構建工具未能消除軟件構建的重復性，因為不同的項目需要編寫對應的Ant任務。
Maven作為后來者，繼承了Ant的項目構建功能，並且提供了依賴關系，插件機制，項目管理的功能，因此它是一個項目管理和綜合工具，其核心的依賴管理，項目信息管理，中央倉庫，Maven的核心理念是約定大於配置。每一種類型都有固定的構建生命周期。

和ant的build.xml相對的，maven項目的核心是pom.xml，java開發同學肯定都很熟。

Gradle

Gradle已經拋棄了Ant、Maven中Xml配置的形式，取而代之的是Gradle采用了領域特定語言Groovy的配置。Gradle繼承了Maven中倉庫，坐標，依賴這些核心概念。文件的布局也和Maven相同。但同時，又繼承了Ant中target的概念，我們又可以重新定義自己的任務(在Gradle中叫做task)。

相比maven會更簡潔，比如在maven中要引入依賴：

轉換成gradle腳本：

dependencies { compile('org.springframework:spring-core:2.5.6') compile('org.springframework:spring-beans:2.5.6') compile('org.springframework:spring-context:2.5.6') compile('com.google.code.kaptcha:kaptcha:2.3:jdk15') testCompile('junit:junit:4.7') }

配置從原來的28行縮減至7行！效果驚人。

同時gradle在構建性能上也碾壓maven，gradle在maven的基礎上額外增加了增量構建、build cache、daemon等特性，大大提升構建時間。

類似的構建工具其實還有很多，基本屬於百花齊放，比如facebook的BUCK，Google的bazel等，國內也有一些廠商自己的構建工具，比如騰訊的blade。不同的工具都會有自己的優勢和劣勢。

三構建平台的演進

1 原始時代

其實最開始的訴求非常簡單，構建工具基本都是現成的，人少，功能簡單。所有構建基本都是手動。

移動端：支付寶一個應用，一個倉庫，誰發版直接在個人電腦上拉取最新代碼執行編譯，發布app store。
服務端：一台物理機，一套構建腳本，誰要發布，直接登錄，輸入倉庫/分支信息，執行構建，然后發版。

2 自動化

顯然，隨着人員的增長，規模的擴大，原始時代根本無法支撐進一步發展，主要的矛盾：

多人協作困難。
多人搶占。
個人機器構建的不穩定性，成功率極低。

這一階段最大的訴求：項目管理/多人協作/自動化構建。應運而生兩個平台：CP SCM。

CP主要負責項目管理，多人協作。
SCM主要負責代碼管理，構建任務調度，構建機器管理運維（SCM慢慢演變成一個大雜燴，jar包上傳管理，客戶端簽名，各種）。

大概長下面這個樣子：

初級階段

這里構建比較大的難點還是在機器的管理和調度，其實做了很多事情：

機器管理，增刪機器。
機器保活，可用性監控。
機器環境一致性的保障。
機器構建負載均衡。
構建腳本的統一升級維護。

上面框架運行了一段時間后還是發生了很多問題，構建成功率越來越低，主要有幾個問題：

ssh通道是有連接數限制的，抽風性的ssh連接異常。
負載均衡控制困難，機器之間負載經常不一致，構建時快時慢。
機器配置管理難度大。

進階階段

其實這一塊，開源有非常成熟的方案 -- jenkins。我們干的很多的事情jenkins都已經幫我們干了。也能很好的解決我們遇到的痛點：

C/S架構，無ssh通道限制。
自動控制負載均衡，機器監控。
靈活的構建和任務配置。
強大的開放能力和豐富的API。

改造完大概長這樣：

黑科技（填坑）

這里要拋出一個新的概念「制品庫」。

Java開發中，大家對maven、gradle這些工具肯定不能再熟悉了。前面講構建工具的時候講過，Java構建工具有幾代演進：Ant，Maven，Gradle。Maven之前的上古工具，用的人應該非常少了。

在Maven之前，是不存在版本管理，依賴管理這種概念的，所有的東西都在你的倉庫。你的工程里面用到了gson，spring，log等開源框架和功能時，是需要去手動下載對應的jar包，然后放在代碼庫中。如果需要更新，需要不停去項目對應官網，下載最新發布的包。

Maven之后的工具，提供了強大的依賴管理功能，只要在pom.xml寫上你要使用的依賴，maven會自動下載依賴，修改和升級只需要修改GAV坐標（groupid，artifactid，version），依賴的所有jar包都存儲在「制品庫」中。

此時的構建大概長這個樣子：

物理機緩存使用overlay文件系統，每次構建緩存獨立，防止公共緩存被刷入。
監控制品庫的覆蓋記錄，生產delete task，快速通知物理機刪除公共緩存。
記錄overlay文件系統upper層的增加記錄，記錄add task，定時刷入物理機公共緩存。

存在的問題

環境一致性保證，環境升級。
復雜的腳本邏輯。

理解下這兩個問題，隨着業務的迅速發展，接入的系統越來越多，APP越來越多，構建的環境越來越“胖”。

比如：App除了支付寶，還有口碑，財富，香港錢包等，各個產品有自己的構建邏輯，也有自己的工具，比如支付寶用gradle4，口碑用gradle2。

其它的技術棧也越來越多，Java，GO，C++等，需要不同的JDK版本，GO環境等。

所有環境都塞進一台物理機，這里存在兩個比較嚴重的問題：

頻繁增加新的工具，如何確保不影響既有的環境和構建。
環境不可復制，新的構建機器，初始化困難，很難保證和舊有環境的一致性。

歷史發生過的問題

新加的物理機編碼異常，導致構建產物異常，運行時出現亂碼。
升級IOT的AndroidSDK，影響支付寶，部分手機計步功能失效。
環境升級操作不當導致的各種構建失敗。

3 容器化

構建是一件非常值得敬畏的事情，需要保證構建的絕對正確，一旦構建異常了，后果不堪設想。

最好的保證構建正確性的方式，就是什么都不要改，不要加機器，不要改環境，什么都不要動。

但是現實是總是有越來越多新的場景冒出了，今天要支持這個，明天要支持那個，這里是一個比較矛盾的點。

在容器技術出來之前，大家都是用的是虛擬機技術，我們可以模擬出來一台乃至多台電腦，但是太笨重了，也不好維護。2013年Docker開源，它輕量，高性能(秒級啟動)，隔離性，讓他迅速成為焦點。

構建也嘗試探索，docker技術非常適合在構建時使用，可以很好的解決上面的問題。改造后長下面這樣：

之后升級環境再也不是痛，各種場景容器隔離，升級互不影響，物理機秒級擴容。運維人員基本只要維護Dockerfile就行。

當然也會帶來新的問題：

Mac構建沒法虛擬化，仍然是傳統物理機構建 + Ansible運維。
容器化之后緩存失效，構建時間暴增。
鏡像本身的管理，物理機磁盤空間管理。

4 鏡像化

前面講的都是軟件的構建過程和構建服務，這里其實還存在一個問題，除了構建的一致性，軟件的運行環境一致性也至關重要。經常會發生，一個軟件，在我的電腦可以，在別人的環境卻跑不起來。

隨着容器技術越來越火，serverless技術和應用微服務架構的演進。容器正迅速成為企業應用打包和部署的基本單位，可以真正的實現build once & run everywhere。
在螞蟻的歷史中也是如此，越來越多的場景開始鏡像化部署，所以鏡像構建本身也變得越來越重要，鏡像構建的效率，穩定性，安全性等至關重要。

鏡像構建也經過兩次演進：

docker build

docker build是比較簡單的，我們在之前的架構之上新增了一種鏡像構建類型，主要存在下面幾個弊端。

（1）對於multi-stage 的Dockerfile 構建無法實現並行編譯

（2）docker build 緩存利用效率低，改變Dockerfile 前面的一層，后面所有的層都需
要重新構建而無法使用緩存，這要求用戶不得不認真控制寫好自己的Dockerfile以確保鏡像緩存復用。

buildkit + K8S

buildkit是從docker build分離出來的單獨項目，目前buildkit已經集成到Docker 18.06之后的版本之中，核心特性：

可擴展的前端格式：buildkit使用前后端分離的架構設計，除了Dockerfile也支持其他類型的前端格式。
並行構建執行：對於multistage類型Dockerfile， buildkit可以實現不同stage之間的並行執行。
支持構建緩存的多種處理方式：buildkit處理本地緩存snapshot，同時還提供了將構建緩存導入/導出到本地或者遠程registry。
多種輸出格式：buildkit支持導出成tar包或者oci格式的鏡像格式。
引入Dockerfile新語法RUN --mount支持構建時掛載。

這里不進行擴展，有興趣的同學可以查看buildkit的官方項目（螞蟻目前每天運行着上萬數量的高可用鏡像構建服務）。

5 擁抱雲原生

隨着螞蟻越來越多的業務serverless化，雲原生慢慢成為了趨勢。伴隨着的是對K8s之上的構建和資源的使用訴求。

而K8s本身使用門檻又極高，同時也缺乏靈活的任務編排能力。相應的構建團隊也開始調研和投入雲原生的構建和調度解決方案。

背景

2019年3月份持續交付基金會（CDF）正式成立，它致力於使企業在多個 CI / CD 平台上更輕松地構建和復用 DevOps 管道。

第一批進入CDF項目的主要有四個：

Tekton 作為谷歌捐贈的 CDF 重要項目，是一組用於構建 CI/CD 系統的共享開源組件，與 Kubernetes 緊密相連，其重要性不言而喻。

並且jenkinsX底層也選擇了tekton作為執行引擎。

Jenkins X is committing fully to Tekton as its pipeline execution engine. We are convinced that this is the right choice for Jenkins X, as a cloud-native CI/CD platform on Kubernetes, and for our users.

內部落地

綜合權衡，采用tekton是一個比較合理的解決方案（站在巨人的肩膀，不重復造輪子）。

經過一段時間的探索和演進，逐步落地了雲原生的資源調度和構建解決方案——ironman。服務內部每天幾萬的構建、代碼掃描、CI任務等場景。

詳細細節可以參考下面幾篇文章：

tektoncd github
持續交付基金會

下一步計划

tekton相比K8s，復雜度大大降低，並且提供了足夠靈活的編排和調度能力，但是仍然有缺陷：

概念復雜，偏厚重，整體調度相比直接使用POD會更慢
使用上仍然有一些成本，對一線用戶的接入使用不友好

目前正在投入POD預熱等極簡模式，解決上訴痛點。當然還有很多未解的難題，就不一一贅述。

6 構建中台

經歷了自動化，容器化，鏡像化等場景，發現用戶的需求實在是千奇百怪，越來越多（只能說螞蟻的業務發展太快）。

我們有越來越多的業務場景（IOT，小程序，大數據，...），構建的需求差異性也非常大。有Mac構建，Linux構建，Windows構建。應付還是有點吃力。尤其是在Mac和Windows兩種無法虛擬化的場景，大量的機器分組，有點維護不動。現狀大概長這樣：

由於構建邏輯基本都是在構建團隊維護，SCM和構建腳本中的代碼邏輯也處於一個非常混亂的狀態，基本就是大量的if else，偽代碼大概長這樣：

if (framework == "sofa") { buildCmd = "mvn clean package" if (app == "special") { buildCmd = "mvn clean package -Ptest=true" } } else if (framework == "android") { buildCmd = "gradle clean assembleRelease" } else if (framework == "jar") { buildCmd = "mvn clean install && mvn deploy" } else if (xxx) { buildCmd = "xxx" }

這個階段在面對一些個性化的構建需求其實有點力不從心，需求千奇百怪：“我要加個額外的參數”，“我要更多的CPU”，“我需要用Mac來跑構建”，“我需要用某某軟件的某某版本”。

當前階段是沒法繼續支撐螞蟻未來的業務發展的，在加上當前底下已經有非常多的資源（linux，windows，Mac，K8S）管理困難。

所以未來的構建平台，至少是可以做到下面兩點：

構建可描述，邏輯回歸業務方。
構建資源(機器)動態插拔，任意切換。

構建可描述

所有的構建邏輯是透明的，可配置化，可代碼化，可描述內容包括：

構建機器類型
構建所需資源大小
構建所需環境軟件
構建執行邏輯
構建結果產物

構建資源動態插拔，任意切換

這里最關鍵的點是去掉大量分組維護帶來的難點，讓資源之間可以共用，互相流動。同時可以實現資源之間的任意切換，降級，保障構建服務的高可用（比如K8s資源降低到物理機構建）。

新的框架大概長下面這樣：

業務使用方只要定義好buildspec.yaml文件，就可以實現任何個性化的構建需求。
底下執行構建的資源可以是K8S，可以是jenkins，可以是物理機，whatever，構建資源描述好自己支持的類型入場即可。

buildspec.yaml大概長下面這樣：

name: android-aar-build
params: - name: productLine default: alipay - name: sprintId default: ${SPRINT_ID} resources: - name: code-repo type: git url: https://code.alipay.com/xxxxx ref: master environment: type: LINUX_CONTAINER image: reg.docker.alibaba-inc.com/alipay/aarbuild:latest buildTasks: - name: Download config image: python:3 commands: - python --version - name: Install Dependency image: ruby:2.6 commands: - echo "-------2 in ruby:2.6" ruby -v artifacts: - name: pod-for-alipay type: iot-sign path: xxxx.zip

四構建的挑戰

1 統一構建中台

目前還在持續的開發和演進中，作為服務螞蟻全棧的構建服務，其穩定性，高可用，靈活性至關重要。尤其是極限生存能力。

2 雲原生調度基礎設施

面向K8s的CI/CD，讓K8s的資源使用簡單優雅。tekton的優雅升級，極簡的調度方案，友好的接入成本。

3 極致的構建效率和體驗

深度定制構建工具

Java研發：Maven，Gradle，並發構建，緩存構建，增量構建，甚至秒級構建。
終端研發：秒級構建，快速本地部署驗證。
鏡像構建：目前仍然需要30+s的構建時間，需要持續做下去，緩存的命中率，鏡像加速，remote cache，除了構建提效，還可以幫助部署提效。

制品庫升級

顛覆現有不合理模式，比如因為Jar release覆蓋導致的“黑科技”，提升研發體驗和研發效率。
軟件制品身份追蹤，深入可信研發。

原文鏈接

本文為阿里雲原創內容，未經允許不得轉載。