作者：楊偉偉
掌門教育效能研發前端工程師
掌?教育?動化構建歷程
在業內前端構建，?般分為三種：
- ?動觸發構建：這個階段?常原始，需要我們??在本地進? git pull/npm install/npm run build 等 等操作，也容易出現問題；
- 虛擬機 Jenkins 集群分布式構建：通過 Master 將任務分配到對應的 Slave 機器上執?構建，能極? 的均衡資源，利?性能，同時解放雙?；
- 容器集群構建：容器構建，鏡像發布，可以進?步的節約資源；
不過掌?教育在 2019 年之前，前端研發更多是在本地進?構建，再通過運維的腳本來進?部署，也容易 導致出現?產故障，所以我們收集反饋，結合實際情況，開發出 v1.0 構建模式，也取得了很好的成果，但 并沒有以此就認為?枕?憂，也對很多痛點進?持續的優化，最后迭代出 v2.0 的?案，在這個程序中，前 端業務壯?，CI 構建經過 400+ 多應?，每周 2000+ 次構建，300+ 次的?產發布的?考，持續的成 ?，
v1.0 ?對的挑戰
v1.0 前端構建狀況，?種是通過 webhook 來觸發流?線構建，第?種是通過在 cd 上新建構建單來觸構 建，如果構建任務?較多，按照單臺機器的是遠遠不夠，在這種情況下就需要借助 Jenkins 的 Master/Slave 的主從模式，來解決服務器的資源壓?，讓 Master 的服務器來進?調度資源，指定空閑 Slave 機器進?構建，當 Slave 機器上構建任務滿了，構建任務繼續在 Master 排隊池中繼續等待，等 Slave 空閑后，再進?分配，
存在的挑戰
v1.0 不是最好的?案，同時暴露出第?次構建慢、錯誤?志反饋不明確等問題，另外?點就是 job 維護困 難，要解決這些問題，就需要重新開始，重新設計，
?先就是 JOB 維護困難，v1.0 的任務模式是多個應?對應 1 個 job，這就導致?個問題，如果 job 發版 導致掛了，影響到全部，假如需要復?該 job，進?定制化開發也?較困難，
其次第?次構建慢的問題，更多在資源調度上和?法復? Workspace，根據之前的資源調度模式，當我們 把任務分配到 A 機器，該任務被執?成功，那么下次的任務也會??到這臺 A 機器，以此觀察，就會發 現?部分任務都會優先去搶占 A 機器，這家就導致了?個問題：
- 資源調度不均衡；
- npm 快取越來越?；
最后是?法復? Workspace 模式，在 v1.0 情況下，不復? Workspace 模式是會帶來以下優勢：保證 node_module ?污染問題，同時也避免了 npm run build 的各種因為 node_module 包污染的問題，導 致的意外錯誤，所以在 v2.0 就需要應對污染的問題，同時也要考慮在復? Workspace 后，如何最?化 的利?其特點，?如，從 node_module 快取、npm install 跳過等，
v2.0 優化?案
資源調度
?先需要對資源調度進?優化，那就需要重新設計，把?組機器分為多個切?組，每個切?組調度順序不 同，當應?觸發構建時，分配對應的 key值：
1 AppNodeKey = AppId%nodes
再根據劃分的 key，尋找對應的機器組，如 [0,1,2,3,4]，構建任務去尋找 0 號機，尋找對應的 AppId 的 Workspace ?錄地址去執?構建任務，假如任務被占?（默認是 2 個任務，這樣可以優化資源不會被? 量任務搶占），會再尋找下?臺機器，這樣機器資源調度就會均衡化，
構建 job 流?線化
我們對不同的?程項?進?了模板化，?如 PC項?、H5 項?、游戲項?、hybrid 項?等等，在模板基 礎上，我們?封裝出來打包流?線模板，這樣的好處是，我們可以??去針對各個型別的?程模板做?些 定向的配置優化，?如說我們的游戲型別項?，我們去做?個構建、打包，我們就可以在對應的開發組件 庫依賴這?塊，做?些對應的快取、通知、報告等等，
流?線同時也帶來了?些好處：
- 第?，我們把構建任務進?了?命周期化，git cone、npm install、npm build，把這些階段全部進?拆 開，讓整個任務流程顆粒化，這樣的好處是，我們可以在每?個顆粒之間找到優化空間，?如是不是可以 不進?npm install，?如上傳制品倉庫的邏輯優化等等，
- 第?，可以指定DSL，我們可以實時監聽打包排隊的情況，在資源調度層?做?些優化，同時可以做?些 埋點進?采集資料，給后續進?深?分析，
- 第三，我們甚?可以在構建、打包程序中，做?些互動的相關操作，?如，我們打包?個 h5 項?，需要測驗同學來進?審核，只有測驗審核通過完之后，才進?到下?流程，下?個流程可能是進? UAT 打包、 ?產打包等等，
- 第四，針對項?依賴拉取，最開始的時候，我們做的是全量的拉取，我們現在可以優化為增量拉取，這 樣，服務器的壓?會減輕很多
錯誤治理
不管是在本地還是 cd 平臺上進?構建，也容易出現各種意想不到的錯誤，?如開發的疏忽，流?線的 git commit 未經過驗證進?提交代碼，都可能在 npm run build、或者 npm install 這兩個階段報出不同的 錯誤，所以就需要對?志提示進?分級集，劃分為兩種型別：
- warning 型別：沒有 package-lock.json 提示，不影響到任務構建；
- error 型別：導致 job 任務退出，?如依賴包未找到等； 4
我們對 npm install、npm run build，及構建的各個階段的觀察，可以把失敗歸納為 4 個觸發 warning 或 error 型別：
- 語法錯誤：代碼沖突…
- 程式例外：記憶體溢位…
- Install 失敗：未找到安裝包…
- 配置錯誤：構建未按照規范輸出…
遵守“觀察?志-沉淀規則-修正反饋準確率”規則，來沉淀?志規則，
npm install 跳過
在復? Workspace 的情況下，已經 install 好的 node_modules，就沒必要進??次重復 npm install， 就需要考慮只有依賴進?變更時，再重新 npm isntall，同時也容易帶來問題，node_modules 污染，我 們采取了多種?式來避免 node_modules 被污染掉，
- cache 定期檢查；
- 切換 node 版本時，執? npm rebuild，重新進?編譯?些需要依賴 gc++ 環境構建的包，如 node- sass；
- CD ??增加?動清理 Workspace 選項；
帶來的收益
?前，我們對?以前的 v1.0 ?案，整體有了 20%+ 構建速度的提升，這對我們團隊來說，也算是?個不 ?的正向激勵，說明我們之前努?的?向是正確的，
遷移程序
在 v1.0 遷移到 v2.0，需要考慮如何進?平滑遷移，我們基于以下來進?遷移：
1：每個應?建?獨? v2.0 Job 任務，?便快速變更及排查問題；
2：??上?持快速回滾到 v1.0；
3：選擇 git commit、node 版本等資訊保持不變，?感；
總結
好的架構不是設計出來?是演進出來，在未來，構建任務可能會越來越多，項?也越來越復雜化，我們就 會考慮容器化?案，根據實際情況去考慮，容器構建，鏡像發布，盡可能的節約資源，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/279360.html
標籤：AI
上一篇：兩年千余篇原創帶來146萬閱讀、近2萬粉絲和......
下一篇：JUC并發編程小總結