Nginx 按業(yè)務(wù)拆分項目

將現(xiàn)有復(fù)雜的、大型的、包含多個業(yè)務(wù)線的單體項目，按照不同的業(yè)務(wù)線拆分為單獨的項目。

前端會有單獨的 Nginx，按照業(yè)務(wù)線配置不同的 location 來實現(xiàn)對多個項目的映射。

基本架構(gòu)圖如下：

關(guān)于更多詳細(xì)的 Nginx 拆分多項目的內(nèi)容，會有單獨的一篇來介紹。

基于以上的架構(gòu)，團隊按照業(yè)務(wù)線從原來的大型單體項目中拆分出了多個單頁應(yīng)用的項目。

但是此時還會面臨一個問題：拆分出來的每個單頁應(yīng)用也會隨著單條業(yè)務(wù)線的需求不斷迭代變得復(fù)雜臃腫。于是，一種將前端應(yīng)用拆分成更小、更易于管理的小應(yīng)用的趨勢——微前端，也就應(yīng)運而生。

微前端

什么是微前端？簡單來說就是一種將多個可獨立交付的小型前端應(yīng)用聚合為一個整體的架構(gòu)風(fēng)格。

微前端的優(yōu)點：

增量升級

每當(dāng)需要新增一個模塊或者升級某些模塊的時候，只需要修改對應(yīng)的微前端應(yīng)用。

簡單、解耦的代碼庫

每個單獨的微前端應(yīng)用代碼量相對來說較少，只需要維護每個應(yīng)用的業(yè)務(wù)邏輯。

獨立部署

每個微前端應(yīng)用都可以獨立部署，互不影響，最終聚合在容器應(yīng)用內(nèi)。

自主的團隊

可以更好地按照業(yè)務(wù)線來劃分團隊，而不是依據(jù)技術(shù)棧來劃分。每個團隊負(fù)責(zé)對應(yīng)的業(yè)務(wù)線內(nèi)容，使得每個人對自己負(fù)責(zé)的業(yè)務(wù)線有深入的了解，增加團隊的凝聚力。

微前端的實踐

基于微前端的思想，團隊目前按照功能模塊來拆分項目，將不同的功能模塊拆分為單個獨立的微前端應(yīng)用，然后在容器應(yīng)用程序 main.js 中動態(tài)載入。

如圖：

上面的代碼其實是做了以下幾件事：

1、通過請求 /kw/adam/ad/detail/micro-module-router 接口，獲取到微前端應(yīng)用的路由配置對象。

2、依次請求路由信息中對應(yīng)模塊（微前端應(yīng)用）的 depend.map.json，獲取模塊所有的依賴項。

關(guān)于 depend.map.json 是什么，也會有單獨的內(nèi)容來介紹。

3、動態(tài)創(chuàng)建 script 標(biāo)簽，將每個模塊的依賴項通過 script 標(biāo)簽來引入。

4、js文件加載完畢后，將模塊對象掛載到全局 window 對象上。

5、最終將處理得到的 subRouter 數(shù)組合并到容器應(yīng)用的路由列表中。

通過 script 的標(biāo)簽動態(tài)引入的好處就是方便、靈活。當(dāng) js 文件加載完畢的時候，全局動態(tài)導(dǎo)出了對應(yīng)的模塊，而容器應(yīng)用只需要確定要加載哪個模塊的時候才會去真正加載對應(yīng)的模塊。

總結(jié)

通過 Nginx 按照業(yè)務(wù)線拆分多項目和單項目按照功能模塊拆分獨立的模塊應(yīng)用，真正解決了團隊目前面臨的痛點，將團隊從之前的項目部署需要花長時間等待、維護復(fù)雜耦合的代碼邏輯、項目依賴繁雜、團隊缺少標(biāo)準(zhǔn)規(guī)范的窘境中解脫了出來，使得大家能更好地為業(yè)務(wù)賦能。

推薦閱讀：

不小心將 Webpack 升級后我搞定了微前端。

H5 活動頁面快速生成神器——Mocha

數(shù)據(jù)流管理方案 | Redux 和 MobX 哪個更好？

從理解 React 框架開始，開啟金三銀四面試之旅。

前端典型面試題：為什么 React 選擇使用 JSX ？

尤雨溪 3 天 10 更的 Vite 究竟有什么魔力？

我對 Webpack 5 真香了。

點個“在看”和“贊”吧，

畢竟我是要成為前端網(wǎng)紅的人。