背景
通常個人在開發(fā)項目的時，都是在本地編寫構(gòu)建腳本對項目進行構(gòu)建，這個腳本可能是 Gulp，可能是 Grunt， 可能是 webpack，也可能是其他的一些腳本，每次代碼發(fā)布之前，都要對代碼進行構(gòu)建，代碼倉庫里面包含構(gòu)建腳本和構(gòu)建之后的代碼。對于個人開發(fā)，這樣做是沒有問題的，但是涉及到多人開發(fā)或者團隊開發(fā)就會有一定的問題。說是問題也不是問題只不過是會導(dǎo)致開發(fā)效率降低，構(gòu)建錯誤的情況越來越多。
在本地對項目進行構(gòu)建，通過腳手架工具來分發(fā)構(gòu)建腳本對于團隊開發(fā)來說有很多問題：
構(gòu)建腳本的開發(fā)維護者很難去持續(xù)優(yōu)化，更新構(gòu)建腳本
構(gòu)建腳本使用者對構(gòu)建腳本的修改，改良不可復(fù)用
每次發(fā)布之前都需要對項目進行構(gòu)建，如果忘記構(gòu)建將會導(dǎo)致發(fā)布失敗
同一個項目的開發(fā)者可能會有不同的構(gòu)建腳本，極有可能會導(dǎo)致構(gòu)建出錯
我們把構(gòu)建腳本從應(yīng)用里面提煉出來，包裝成單獨 npm 模塊，這樣構(gòu)建腳本（下文統(tǒng)稱為構(gòu)建器）就有了模塊的一些特性：
可分享： 任何人可以很方便發(fā)布一個構(gòu)建腳本模塊給任何人使用
可修改： 如果你有更好的主意，可以 fork，加上自己想要的功能，并發(fā)布到 npm 平臺上
易維護： 模塊可以由專人維護與更新
使用云構(gòu)建后，本地不需要安裝任何構(gòu)建環(huán)境，這個對于一些新技術(shù)的推廣是有好處的， 比如大家都知道，在 Windows 下， 安裝 compass 不是一件輕松的事。而且對于構(gòu)建腳本的更新也是很友好的，只需要更新云構(gòu)建平臺上的構(gòu)建腳本即可。
使用云構(gòu)建后倉庫里面就不需要保存構(gòu)建后的代碼，這樣有助于保持代碼整潔，同時，在多人開發(fā)的時候，再也不會出現(xiàn)構(gòu)建腳本沖突的情況。把云構(gòu)建接入發(fā)布流程，每次提交發(fā)布時執(zhí)行構(gòu)建，這樣就再也不會在發(fā)布之前忘了構(gòu)建。而且服務(wù)器的性能更強大，對于比較大的項目能夠更快執(zhí)行構(gòu)建，節(jié)省構(gòu)建的時間。一線開發(fā)人員不需要去關(guān)心構(gòu)建的問題，能夠把更多的時間放到業(yè)務(wù)上，提高工作效率并。
歷史和現(xiàn)狀
Grunt、Gulp 等前端構(gòu)建的概念是近幾年才火起來的，其實淘寶前端團隊早在 2011 左右就開始大規(guī)模對前端代碼進行構(gòu)建了（Git 也是在這個時候引入到團隊內(nèi)作為版本管理工具）。最初使用的構(gòu)建引擎是 ant，基于 XML 描述構(gòu)建規(guī)則，后來將 ant 的 build 任務(wù)放到了服務(wù)器端執(zhí)行，再后來由于 ant 的擴展性和維護性太低直接改成了 shell 腳本（那個時候壓縮代碼還是用 YUICompress 和 Google Closure Compiler）。
再后來 Node.js 開始流行，基于 Node.js 的前端生產(chǎn)力工具開始如雨后春筍般涌現(xiàn)。團隊內(nèi)部開始使用 Grunt 構(gòu)建前端代碼（后續(xù)慢慢被 Gulp 和 webpack 替代），但依舊是在本機電腦執(zhí)行構(gòu)建，然后將構(gòu)建后代碼提交到倉庫進行發(fā)布上線。14 年底開始構(gòu)思并上線了第一版云端構(gòu)建平臺，開始逐步將前端代碼的共建工作再次遷移到云端執(zhí)行。
經(jīng)過一年多時間的完善，云構(gòu)建平臺已經(jīng)完全支撐起了團隊內(nèi)部乃至整個集團的前端代碼構(gòu)建任務(wù)，日構(gòu)建任務(wù)量已達 1000+。并且構(gòu)建服務(wù)還集成到了代碼發(fā)布流程中和本地開發(fā)工具中，使前端開發(fā)前所未有的高效和輕松。
系統(tǒng)架構(gòu)
云構(gòu)建系統(tǒng)由五部分組成：
1.客戶端（client）
client 負責(zé)向云構(gòu)建發(fā)起一個構(gòu)建請求并獲取構(gòu)建后內(nèi)容。
client 官方提供了一個已經(jīng)封裝好邏輯的 npm 模塊，如果是基于 Node.js 的系統(tǒng)，可以直接使用。
client 支持將需要構(gòu)建的代碼直接上傳給構(gòu)架服務(wù)器或者僅提供一個 URL，由構(gòu)建服務(wù)器自己從 URL 下載代碼，官方更推薦后者。
2.構(gòu)建器（builder）
builder 是構(gòu)建任務(wù)的最終執(zhí)行者，包含詳細的構(gòu)建業(yè)務(wù)邏輯
builder 是一個標準的 npm 模塊
3.構(gòu)建服務(wù)器（workers）
workers 是一組高性能服務(wù)器，每臺服務(wù)器可以并發(fā)運 32 個構(gòu)建任務(wù)。
workers 可以動態(tài)擴容；上線和下線
4.構(gòu)建路由（router）
router 負責(zé)分發(fā)構(gòu)建任務(wù)給 worker。
router 集成了 worker 負載監(jiān)控功能，可以保證所有 worker 平均負載。
5.數(shù)據(jù)展示和管理平臺（web）
web 展示所有構(gòu)建過程中產(chǎn)生的數(shù)據(jù)
web 管理構(gòu)建器和構(gòu)建服務(wù)器
架構(gòu)圖：
運行一次構(gòu)建任務(wù)的大概過程如下：
app（需要調(diào)用云構(gòu)建的各種系統(tǒng)）集成 client，并使用 client 提供的接口發(fā)起構(gòu)建請求
client 從 router 獲取一個 worker 地址
client 與 worker 建立 socket 連接，并向這個 worker 發(fā)起構(gòu)建任務(wù)
worker 實時輸出構(gòu)建日志信息給 client
worker 完成構(gòu)建后將構(gòu)建結(jié)果返回給 client
client 將構(gòu)建結(jié)果返回給 app
為了減輕構(gòu)建服務(wù)器的負載，整個構(gòu)建過程中涉及到的文件上傳下載服務(wù)都是通過文件中轉(zhuǎn)服務(wù)來完成的。
abc.json
除了上面的五個部分，還有一個配置文件也是必不可少的：abc.json（a build config）。這個文件一般跟需要構(gòu)建的內(nèi)容放在一起發(fā)送給 worker。是一個標準的 JSON 文件，指定需要調(diào)用的 builder 和一些配置信息。
構(gòu)建器（builder）
abc.json 和 builder 是整個云構(gòu)建平臺唯一可定制部分。
builder 是一個標準的 npm 模塊，入口文件可以是一個 Grunfile.js 或者 gulpfile.js，當(dāng)然也可以是你自己的 xx.js。如果是 Gulp 或者 Grunt 腳本，worker 會幫你運行這個腳本，如果是普通的 npm 包，wroker 會運行由 package.json 文件中指定的入口文件。
構(gòu)建器編寫注意事項
1，項目本身需要依賴一些外部的模塊，例如 lodash，需要構(gòu)建開始前需要自己安裝相應(yīng)的依賴，可以通過一個 Gulp 的 task 去執(zhí)行，沒有依賴則忽略。
3，針對特定項目的配置信息，可以在項目的配置文件（abc.json）中添加，然后在構(gòu)建時通過讀取配置文件獲取。
4，云構(gòu)建和本地構(gòu)建有一定的區(qū)別。本地構(gòu)建時，源碼目錄和構(gòu)建好的代碼的存放目錄構(gòu)建者都是明確的。而云端構(gòu)建，構(gòu)建腳本是由云構(gòu)建平臺來控制的，云構(gòu)建也需要收集構(gòu)建好的文件返回給客戶端，因此待構(gòu)建源碼的目錄（src）和構(gòu)建好的代碼的存放目錄（dist）都是需要有云構(gòu)建平臺來指定，worker 在執(zhí)行 builder 的時候會傳遞相關(guān)參數(shù)。
5，如果構(gòu)建器本身需要安裝依賴，package.json 的依賴需要是 dependencies，不能是 devDependencies。
構(gòu)建器測試
構(gòu)建器編寫本身也需要一定的成本，而且在本地?zé)o法測試，如果構(gòu)建器編寫出錯，而且已經(jīng)發(fā)布，將會造成很大的問題，因此需要一個構(gòu)建器的測試平臺。
通過刪除構(gòu)建系統(tǒng)的大部分特性，而只保留最核心的功能，同時去除原系統(tǒng)的一些限制使構(gòu)建器能夠在上面正常運行。同時編寫相應(yīng)的測試命令行工具，形成整個構(gòu)建器測試平臺。
線上構(gòu)建系統(tǒng)對構(gòu)建器做了嚴格的限制，構(gòu)建器必須要審核通過才能夠發(fā)布上線。測試平臺沒有這些限制，方便構(gòu)建器開發(fā)者更新測試。
遇到的問題和解決方法
1，HTTP 連接
最開始的時候 client 與 worker 都是通過 HTTP 進行通信，這樣實現(xiàn)起來的確是很簡單，系統(tǒng)也能正常運行。而且對于絕大多數(shù)構(gòu)建任務(wù)來說是沒有問題的。但是遇到一些比較大的項目，構(gòu)建時間比較長的項目，問題就暴露出來了。由于構(gòu)建時間比較長 HTTP 連接經(jīng)?？赡軙恢刂茫扔锌赡芤驗?nginx 代理的問題導(dǎo)致，也有可能因為網(wǎng)絡(luò)問題導(dǎo)致。
隨著云構(gòu)建系統(tǒng)越來越復(fù)雜，服務(wù)器的返回值，需要經(jīng)過多層嵌套才能夠返回給客戶端，這對于系統(tǒng)的調(diào)試和錯誤處理帶來了很多的不變，而且大大降低了代碼的可讀性。錯誤處理變得很復(fù)雜，可能會存在沒有發(fā)現(xiàn)的 bug。
為了徹底解決這個問題，我們使用了 socket 來代替 HTTP，使用了 socket 的特性，構(gòu)建時間即使再久也不會發(fā)生構(gòu)建過程中通信中斷的問題。而且只要構(gòu)建發(fā)生錯誤，通過 socket 的事件機制立馬就能夠通知客戶端。
2，文件上傳
在最初的系統(tǒng)中，項目文件的上傳是通過 client 直接把項目文件壓縮打包上傳到 worker，項目文件很大打包壓縮上傳的時間需要很久，而且文件過大，nginx 會返回 413 錯誤。當(dāng)并發(fā)任務(wù)數(shù)量過多的時候，worker 負載過大，經(jīng)常會因為上傳下載占用過多的資源影響構(gòu)建服務(wù)的正常進行。
通過把文件上傳服務(wù)獨立出來，建立單獨文件中轉(zhuǎn)服務(wù)，worker 只需要關(guān)注構(gòu)建相關(guān)的問題，不再接收處理上傳的文件，client 傳遞給 worker 的只是一個 URL 地址。構(gòu)建完成后，worker 把構(gòu)建好的代碼打包壓縮上傳到文件中轉(zhuǎn)服務(wù)，然后返回相應(yīng)的地址給 client，client 通過地址拿到構(gòu)建好的內(nèi)容。所有文件處理都通過第三方去處理，文件部分的處理和構(gòu)建過程完全獨立。減少了系統(tǒng)的耦合程度。
3，負載均衡
隨著云構(gòu)建系統(tǒng)被使用的越來越多，構(gòu)建任務(wù)經(jīng)常需要等待，為了避免構(gòu)建等待，加快構(gòu)建速度，我們增加了構(gòu)建服務(wù)器的數(shù)量。
多臺構(gòu)建服務(wù)器就需要有相應(yīng)的任務(wù)分發(fā)機制，對任務(wù)進行分發(fā)保證構(gòu)建任務(wù)不需要等待。因此增加了云構(gòu)建路由服務(wù)（router）。云構(gòu)建路由對任務(wù)進行分發(fā)，構(gòu)建服務(wù)器有多臺，在分發(fā)的時候要根據(jù)構(gòu)建服務(wù)器上面正在運行任務(wù)的數(shù)量進行分發(fā)，確保任務(wù)能夠以最快的速度運行。
同時還需要設(shè)定心跳機制，定時去檢測構(gòu)建服務(wù)器的情況，如果構(gòu)建服務(wù)器出現(xiàn)異常能夠及時報警，同時自動下線相應(yīng)的構(gòu)建服務(wù)器。最大程度的保證構(gòu)建能夠正常的運行，不會因為一臺構(gòu)建服務(wù)器出現(xiàn)故障而影響整個構(gòu)建系統(tǒng)的正常運行。
展望
1，為了提高測試平臺的穩(wěn)定性和安全性，我們設(shè)想為每個構(gòu)建器提供單獨的沙盒運行環(huán)境，使用 docker 技術(shù)把構(gòu)建器的運行環(huán)境和構(gòu)建系統(tǒng)本身隔離開來，保證構(gòu)建器運行過程的問題不會影響構(gòu)建系統(tǒng)本身，使兩者獨立起來。這樣做對于系統(tǒng)的安全性也會有很大的提高，限制了構(gòu)建器本身的運行環(huán)境，即使構(gòu)建器中存在一些危害構(gòu)建系統(tǒng)的行為也不會影響到構(gòu)建系統(tǒng)，這樣極大的提高了安全性和穩(wěn)定性。
2，目前云構(gòu)建還只是擁有對代碼進行構(gòu)建的能力，完全可以把云構(gòu)建平臺進行通用化，成為一個通用 Node.js 任務(wù)運行平臺，目前我們正在做這方面的嘗試。
