背景

通常個(gè)人在開發(fā)項(xiàng)目的時(shí)，都是在本地編寫構(gòu)建腳本對(duì)項(xiàng)目進(jìn)行構(gòu)建，這個(gè)腳本可能是 Gulp，可能是 Grunt， 可能是 webpack，也可能是其他的一些腳本，每次代碼發(fā)布之前，都要對(duì)代碼進(jìn)行構(gòu)建，代碼倉庫里面包含構(gòu)建腳本和構(gòu)建之后的代碼。對(duì)于個(gè)人開發(fā)，這樣做是沒有問題的，但是涉及到多人開發(fā)或者團(tuán)隊(duì)開發(fā)就會(huì)有一定的問題。說是問題也不是問題只不過是會(huì)導(dǎo)致開發(fā)效率降低，構(gòu)建錯(cuò)誤的情況越來越多。

在本地對(duì)項(xiàng)目進(jìn)行構(gòu)建，通過腳手架工具來分發(fā)構(gòu)建腳本對(duì)于團(tuán)隊(duì)開發(fā)來說有很多問題：

構(gòu)建腳本的開發(fā)維護(hù)者很難去持續(xù)優(yōu)化，更新構(gòu)建腳本
構(gòu)建腳本使用者對(duì)構(gòu)建腳本的修改，改良不可復(fù)用
每次發(fā)布之前都需要對(duì)項(xiàng)目進(jìn)行構(gòu)建，如果忘記構(gòu)建將會(huì)導(dǎo)致發(fā)布失敗
同一個(gè)項(xiàng)目的開發(fā)者可能會(huì)有不同的構(gòu)建腳本，極有可能會(huì)導(dǎo)致構(gòu)建出錯(cuò)
我們把構(gòu)建腳本從應(yīng)用里面提煉出來，包裝成單獨(dú) npm 模塊，這樣構(gòu)建腳本（下文統(tǒng)稱為構(gòu)建器）就有了模塊的一些特性：

可分享： 任何人可以很方便發(fā)布一個(gè)構(gòu)建腳本模塊給任何人使用
可修改： 如果你有更好的主意，可以 fork，加上自己想要的功能，并發(fā)布到 npm 平臺(tái)上
易維護(hù)： 模塊可以由專人維護(hù)與更新
使用云構(gòu)建后，本地不需要安裝任何構(gòu)建環(huán)境，這個(gè)對(duì)于一些新技術(shù)的推廣是有好處的， 比如大家都知道，在 Windows 下， 安裝 compass 不是一件輕松的事。而且對(duì)于構(gòu)建腳本的更新也是很友好的，只需要更新云構(gòu)建平臺(tái)上的構(gòu)建腳本即可。

使用云構(gòu)建后倉庫里面就不需要保存構(gòu)建后的代碼，這樣有助于保持代碼整潔，同時(shí)，在多人開發(fā)的時(shí)候，再也不會(huì)出現(xiàn)構(gòu)建腳本沖突的情況。把云構(gòu)建接入發(fā)布流程，每次提交發(fā)布時(shí)執(zhí)行構(gòu)建，這樣就再也不會(huì)在發(fā)布之前忘了構(gòu)建。而且服務(wù)器的性能更強(qiáng)大，對(duì)于比較大的項(xiàng)目能夠更快執(zhí)行構(gòu)建，節(jié)省構(gòu)建的時(shí)間。一線開發(fā)人員不需要去關(guān)心構(gòu)建的問題，能夠把更多的時(shí)間放到業(yè)務(wù)上，提高工作效率并。

歷史和現(xiàn)狀

Grunt、Gulp 等前端構(gòu)建的概念是近幾年才火起來的，其實(shí)淘寶前端團(tuán)隊(duì)早在 2011 左右就開始大規(guī)模對(duì)前端代碼進(jìn)行構(gòu)建了（Git 也是在這個(gè)時(shí)候引入到團(tuán)隊(duì)內(nèi)作為版本管理工具）。最初使用的構(gòu)建引擎是 ant，基于 XML 描述構(gòu)建規(guī)則，后來將 ant 的 build 任務(wù)放到了服務(wù)器端執(zhí)行，再后來由于 ant 的擴(kuò)展性和維護(hù)性太低直接改成了 shell 腳本（那個(gè)時(shí)候壓縮代碼還是用 YUICompress 和 Google Closure Compiler）。

再后來 Node.js 開始流行，基于 Node.js 的前端生產(chǎn)力工具開始如雨后春筍般涌現(xiàn)。團(tuán)隊(duì)內(nèi)部開始使用 Grunt 構(gòu)建前端代碼（后續(xù)慢慢被 Gulp 和 webpack 替代），但依舊是在本機(jī)電腦執(zhí)行構(gòu)建，然后將構(gòu)建后代碼提交到倉庫進(jìn)行發(fā)布上線。14 年底開始構(gòu)思并上線了第一版云端構(gòu)建平臺(tái)，開始逐步將前端代碼的共建工作再次遷移到云端執(zhí)行。

經(jīng)過一年多時(shí)間的完善，云構(gòu)建平臺(tái)已經(jīng)完全支撐起了團(tuán)隊(duì)內(nèi)部乃至整個(gè)集團(tuán)的前端代碼構(gòu)建任務(wù)，日構(gòu)建任務(wù)量已達(dá) 1000+。并且構(gòu)建服務(wù)還集成到了代碼發(fā)布流程中和本地開發(fā)工具中，使前端開發(fā)前所未有的高效和輕松。

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

云構(gòu)建系統(tǒng)由五部分組成：

1.客戶端（client）
client 負(fù)責(zé)向云構(gòu)建發(fā)起一個(gè)構(gòu)建請(qǐng)求并獲取構(gòu)建后內(nèi)容。
client 官方提供了一個(gè)已經(jīng)封裝好邏輯的 npm 模塊，如果是基于 Node.js 的系統(tǒng)，可以直接使用。
client 支持將需要構(gòu)建的代碼直接上傳給構(gòu)架服務(wù)器或者僅提供一個(gè) URL，由構(gòu)建服務(wù)器自己從 URL 下載代碼，官方更推薦后者。
2.構(gòu)建器（builder）
builder 是構(gòu)建任務(wù)的最終執(zhí)行者，包含詳細(xì)的構(gòu)建業(yè)務(wù)邏輯
builder 是一個(gè)標(biāo)準(zhǔn)的 npm 模塊
3.構(gòu)建服務(wù)器（workers）
workers 是一組高性能服務(wù)器，每臺(tái)服務(wù)器可以并發(fā)運(yùn) 32 個(gè)構(gòu)建任務(wù)。
workers 可以動(dòng)態(tài)擴(kuò)容；上線和下線
4.構(gòu)建路由（router）
router 負(fù)責(zé)分發(fā)構(gòu)建任務(wù)給 worker。
router 集成了 worker 負(fù)載監(jiān)控功能，可以保證所有 worker 平均負(fù)載。
5.數(shù)據(jù)展示和管理平臺(tái)（web）
web 展示所有構(gòu)建過程中產(chǎn)生的數(shù)據(jù)
web 管理構(gòu)建器和構(gòu)建服務(wù)器
架構(gòu)圖：

運(yùn)行一次構(gòu)建任務(wù)的大概過程如下：

app（需要調(diào)用云構(gòu)建的各種系統(tǒng)）集成 client，并使用 client 提供的接口發(fā)起構(gòu)建請(qǐng)求
client 從 router 獲取一個(gè) worker 地址
client 與 worker 建立 socket 連接，并向這個(gè) worker 發(fā)起構(gòu)建任務(wù)
worker 實(shí)時(shí)輸出構(gòu)建日志信息給 client
worker 完成構(gòu)建后將構(gòu)建結(jié)果返回給 client
client 將構(gòu)建結(jié)果返回給 app
為了減輕構(gòu)建服務(wù)器的負(fù)載，整個(gè)構(gòu)建過程中涉及到的文件上傳下載服務(wù)都是通過文件中轉(zhuǎn)服務(wù)來完成的。

abc.json

除了上面的五個(gè)部分，還有一個(gè)配置文件也是必不可少的：abc.json（a build config）。這個(gè)文件一般跟需要構(gòu)建的內(nèi)容放在一起發(fā)送給 worker。是一個(gè)標(biāo)準(zhǔn)的 JSON 文件，指定需要調(diào)用的 builder 和一些配置信息。

構(gòu)建器（builder）

abc.json 和 builder 是整個(gè)云構(gòu)建平臺(tái)唯一可定制部分。

builder 是一個(gè)標(biāo)準(zhǔn)的 npm 模塊，入口文件可以是一個(gè) Grunfile.js 或者 gulpfile.js，當(dāng)然也可以是你自己的 xx.js。如果是 Gulp 或者 Grunt 腳本，worker 會(huì)幫你運(yùn)行這個(gè)腳本，如果是普通的 npm 包，wroker 會(huì)運(yùn)行由 package.json 文件中指定的入口文件。

構(gòu)建器編寫注意事項(xiàng)

1，項(xiàng)目本身需要依賴一些外部的模塊，例如 lodash，需要構(gòu)建開始前需要自己安裝相應(yīng)的依賴，可以通過一個(gè) Gulp 的 task 去執(zhí)行，沒有依賴則忽略。

3，針對(duì)特定項(xiàng)目的配置信息，可以在項(xiàng)目的配置文件（abc.json）中添加，然后在構(gòu)建時(shí)通過讀取配置文件獲取。

4，云構(gòu)建和本地構(gòu)建有一定的區(qū)別。本地構(gòu)建時(shí)，源碼目錄和構(gòu)建好的代碼的存放目錄構(gòu)建者都是明確的。而云端構(gòu)建，構(gòu)建腳本是由云構(gòu)建平臺(tái)來控制的，云構(gòu)建也需要收集構(gòu)建好的文件返回給客戶端，因此待構(gòu)建源碼的目錄（src）和構(gòu)建好的代碼的存放目錄（dist）都是需要有云構(gòu)建平臺(tái)來指定，worker 在執(zhí)行 builder 的時(shí)候會(huì)傳遞相關(guān)參數(shù)。

5，如果構(gòu)建器本身需要安裝依賴，package.json 的依賴需要是 dependencies，不能是 devDependencies。

構(gòu)建器測(cè)試

構(gòu)建器編寫本身也需要一定的成本，而且在本地?zé)o法測(cè)試，如果構(gòu)建器編寫出錯(cuò)，而且已經(jīng)發(fā)布，將會(huì)造成很大的問題，因此需要一個(gè)構(gòu)建器的測(cè)試平臺(tái)。

通過刪除構(gòu)建系統(tǒng)的大部分特性，而只保留最核心的功能，同時(shí)去除原系統(tǒng)的一些限制使構(gòu)建器能夠在上面正常運(yùn)行。同時(shí)編寫相應(yīng)的測(cè)試命令行工具，形成整個(gè)構(gòu)建器測(cè)試平臺(tái)。

線上構(gòu)建系統(tǒng)對(duì)構(gòu)建器做了嚴(yán)格的限制，構(gòu)建器必須要審核通過才能夠發(fā)布上線。測(cè)試平臺(tái)沒有這些限制，方便構(gòu)建器開發(fā)者更新測(cè)試。

遇到的問題和解決方法

1，HTTP 連接

最開始的時(shí)候 client 與 worker 都是通過 HTTP 進(jìn)行通信，這樣實(shí)現(xiàn)起來的確是很簡單，系統(tǒng)也能正常運(yùn)行。而且對(duì)于絕大多數(shù)構(gòu)建任務(wù)來說是沒有問題的。但是遇到一些比較大的項(xiàng)目，構(gòu)建時(shí)間比較長的項(xiàng)目，問題就暴露出來了。由于構(gòu)建時(shí)間比較長 HTTP 連接經(jīng)?？赡軙?huì)被重置，既有可能因?yàn)?nginx 代理的問題導(dǎo)致，也有可能因?yàn)榫W(wǎng)絡(luò)問題導(dǎo)致。

隨著云構(gòu)建系統(tǒng)越來越復(fù)雜，服務(wù)器的返回值，需要經(jīng)過多層嵌套才能夠返回給客戶端，這對(duì)于系統(tǒng)的調(diào)試和錯(cuò)誤處理帶來了很多的不變，而且大大降低了代碼的可讀性。錯(cuò)誤處理變得很復(fù)雜，可能會(huì)存在沒有發(fā)現(xiàn)的 bug。

為了徹底解決這個(gè)問題，我們使用了 socket 來代替 HTTP，使用了 socket 的特性，構(gòu)建時(shí)間即使再久也不會(huì)發(fā)生構(gòu)建過程中通信中斷的問題。而且只要構(gòu)建發(fā)生錯(cuò)誤，通過 socket 的事件機(jī)制立馬就能夠通知客戶端。

2，文件上傳

在最初的系統(tǒng)中，項(xiàng)目文件的上傳是通過 client 直接把項(xiàng)目文件壓縮打包上傳到 worker，項(xiàng)目文件很大打包壓縮上傳的時(shí)間需要很久，而且文件過大，nginx 會(huì)返回 413 錯(cuò)誤。當(dāng)并發(fā)任務(wù)數(shù)量過多的時(shí)候，worker 負(fù)載過大，經(jīng)常會(huì)因?yàn)樯蟼飨螺d占用過多的資源影響構(gòu)建服務(wù)的正常進(jìn)行。

通過把文件上傳服務(wù)獨(dú)立出來，建立單獨(dú)文件中轉(zhuǎn)服務(wù)，worker 只需要關(guān)注構(gòu)建相關(guān)的問題，不再接收處理上傳的文件，client 傳遞給 worker 的只是一個(gè) URL 地址。構(gòu)建完成后，worker 把構(gòu)建好的代碼打包壓縮上傳到文件中轉(zhuǎn)服務(wù)，然后返回相應(yīng)的地址給 client，client 通過地址拿到構(gòu)建好的內(nèi)容。所有文件處理都通過第三方去處理，文件部分的處理和構(gòu)建過程完全獨(dú)立。減少了系統(tǒng)的耦合程度。

3，負(fù)載均衡

隨著云構(gòu)建系統(tǒng)被使用的越來越多，構(gòu)建任務(wù)經(jīng)常需要等待，為了避免構(gòu)建等待，加快構(gòu)建速度，我們?cè)黾恿藰?gòu)建服務(wù)器的數(shù)量。

多臺(tái)構(gòu)建服務(wù)器就需要有相應(yīng)的任務(wù)分發(fā)機(jī)制，對(duì)任務(wù)進(jìn)行分發(fā)保證構(gòu)建任務(wù)不需要等待。因此增加了云構(gòu)建路由服務(wù)（router）。云構(gòu)建路由對(duì)任務(wù)進(jìn)行分發(fā)，構(gòu)建服務(wù)器有多臺(tái)，在分發(fā)的時(shí)候要根據(jù)構(gòu)建服務(wù)器上面正在運(yùn)行任務(wù)的數(shù)量進(jìn)行分發(fā)，確保任務(wù)能夠以最快的速度運(yùn)行。

同時(shí)還需要設(shè)定心跳機(jī)制，定時(shí)去檢測(cè)構(gòu)建服務(wù)器的情況，如果構(gòu)建服務(wù)器出現(xiàn)異常能夠及時(shí)報(bào)警，同時(shí)自動(dòng)下線相應(yīng)的構(gòu)建服務(wù)器。最大程度的保證構(gòu)建能夠正常的運(yùn)行，不會(huì)因?yàn)橐慌_(tái)構(gòu)建服務(wù)器出現(xiàn)故障而影響整個(gè)構(gòu)建系統(tǒng)的正常運(yùn)行。

展望

1，為了提高測(cè)試平臺(tái)的穩(wěn)定性和安全性，我們?cè)O(shè)想為每個(gè)構(gòu)建器提供單獨(dú)的沙盒運(yùn)行環(huán)境，使用 docker 技術(shù)把構(gòu)建器的運(yùn)行環(huán)境和構(gòu)建系統(tǒng)本身隔離開來，保證構(gòu)建器運(yùn)行過程的問題不會(huì)影響構(gòu)建系統(tǒng)本身，使兩者獨(dú)立起來。這樣做對(duì)于系統(tǒng)的安全性也會(huì)有很大的提高，限制了構(gòu)建器本身的運(yùn)行環(huán)境，即使構(gòu)建器中存在一些危害構(gòu)建系統(tǒng)的行為也不會(huì)影響到構(gòu)建系統(tǒng)，這樣極大的提高了安全性和穩(wěn)定性。

2，目前云構(gòu)建還只是擁有對(duì)代碼進(jìn)行構(gòu)建的能力，完全可以把云構(gòu)建平臺(tái)進(jìn)行通用化，成為一個(gè)通用 Node.js 任務(wù)運(yùn)行平臺(tái)，目前我們正在做這方面的嘗試。

最新評(píng)論