微前端自檢清單(分析全面)

最近在做公司微前端，整理了一份微前端搭建清單，如果你正在考慮是否要做微前端，不妨做個參考。

• 需求分析
• 技術方案分析
• 拆分方案分析
• 部署流程分析

需求分析

第一步，我們需要進行需求分析，以便真正清楚我們需要解決的問題是什么。

例如：

• 產(chǎn)品要新增一個業(yè)務模塊
• 產(chǎn)品要修改項目樣式
• 產(chǎn)品反饋項目啟動太慢了
• 產(chǎn)品反饋頁面跳轉刷新很不友好

前兩個需求是典型的業(yè)務需求，它的核心在于解決公司的業(yè)務問題，對于這一類需求，通常技術難度都不大，開發(fā)者只需要按照原型圖，編寫出對應的頁面就可以了。

后兩個需求是典型的技術需求，它的核心在于解決技術問題。通常來說，技術需求和用戶體驗有關，但不會影響項目功能，所以一般產(chǎn)品很少會提技術需求，都是由開發(fā)同學主導。

目前很多公司都不太重視技術需求，主要是因為和公司業(yè)務無關，不能帶來真實可見的收益。其實不然，一些技術需求往往能產(chǎn)生巨大的成本收益，所以我們在做技術需求時，「首先需要得到公司的支持」。

為什么選擇微前端

解決一個技術需求，有很多種方法，為什么選微前端？

我們看過微前端的發(fā)展史就會明白，它并不是憑空出現(xiàn)的，而是項目在不斷發(fā)展過程中形成的，解決項目臃腫的技術方案。

一個項目在剛成立時，體量很小，但隨著項目不斷做大，可能會出現(xiàn)以下問題：

• 工程膨脹
• 分支混亂
• 代碼沖突
• 打包麻煩
• 維護困難

對于這些問題，很難找到一個完美的解決方案，于是就誕生了微前端。

有了微前端之后，我們能將一個大項目拆分成多個小項目，這樣一來，每一個小項目就非常好優(yōu)化了。在優(yōu)化了所有的小項目后，我們再將這些小項目組合起來，就能形成一個完美的大項目了。

在實際項目中，如果遇到以下問題，可以考慮使用微前端：

• 項目太大，成為了典型的巨石應用，打包很慢。

• 項目開發(fā)者太多，多個同學開發(fā)同一套代碼，經(jīng)常出現(xiàn)代碼沖突、或修改公共組件引發(fā)的 Bug。

• 項目太老，存在遺留模塊，為了兼容它，限制了整個項目的發(fā)展。

• 項目技術棧不統(tǒng)一，使用了多種不同框架，每一種框架又有多個版本共存的情況。

• 項目由多個團隊協(xié)同開發(fā)，一個功能需要等其他團隊開發(fā)好之后，才能接著開發(fā)。

• 項目每次發(fā)布都是全量發(fā)布，即使是上線一個小模塊，也可能導致整個項目掛掉。

• 項目由多個系統(tǒng)組成，完成一個功能需要不斷地跳轉多個系統(tǒng)頁。

• 項目開發(fā)人員流動大，存在一些祖?zhèn)鞔a難以維護，一般人都不好改。

• 項目需要一些試驗田方案，即需要在某些模塊做一些新技術嘗試、框架升級等。

• ...

除此之外，還有很多實際情況沒有列舉完畢，不過沒關系，只要我們明白了微前端的特點，就能判斷任何情況。

微前端特點

微前端的核心是解決巨石應用，它都有這些特點：

• 簡單、松耦合的代碼庫

  • 微前端架構傾向于編寫和維護更小、更簡單、更容易開發(fā)的項目。
  • 技術棧無關，各項目可以使用不同的技術棧。

• 增量升級

  • 支持漸進式重構，先讓新舊代碼和諧共存，再逐步轉化舊代碼，直到整個重構完成。

• 獨立部署

  • 每一個子應用都具備獨立開發(fā)，持續(xù)部署，獨立運行的能力。

• 團隊自治

  • 各子項目之間不存在依賴關系，保持隔離。
  • 單一職責，每個子項目只做和自己相關的業(yè)務工作。

?

除此之外，微前端提供了一套新的生態(tài)系統(tǒng)。它通過拆分小項目，產(chǎn)生了大量的微應用。試想一下，如果大家都將微應用上傳到云，那么就會構建一個非常強大的微應用云生態(tài)。我們在以后做需求時，也許就是選擇各種適合的微應用，然后拼接起來，就完事了。

對此保持期待。

?

微前端的缺點

當然，微前端也不是萬能的，它也存在以下問題：

• 拆分的粒度越小，便意味著架構變得復雜、維護成本變高。
• 技術棧一旦多樣化，便意味著技術?；靵y。
• 管理版本復雜、依賴復雜。
• 開發(fā)體驗不太友好，開發(fā)時可能需要同時啟動多個項目。

這些問題大多是因為項目拆分成多個項目之后，引發(fā)的溝通協(xié)作問題。

技術方案調(diào)研

第二步，我們需要確定具體的微前端實現(xiàn)方式。

實現(xiàn)微前端有很多種方式：

• 路由分發(fā)式
  • 通過 http 服務器的反向代理功能，來將請求路由到對應的應用上。
  • 這種方式只是在路由層面看起來是一個項目，但實際上只是通過 a 標簽連接了多個項目。
• 前端容器化
  • 使用 iframe 作為容器。
  • seo 不友好。
  • 需要考慮同源策略 cookie 管理。
  • 需要自建一套應用管理、應用通信機制。
  • 彈窗不友好。
  • 瀏覽器后退按鈕不友好。
• 前端微服務化
  • 在不同的框架之上設計通訊、加載機制，以在一個頁面內(nèi)加載對應的應用。
  • 常用的框架：qiankun，single-spa 都是這樣做的。
  • 最常用的方案，適合于快速上手。
• 微件化
  • 打包出可以直接嵌入在頁面上運行的代碼，可能是一段 js，使用時直接引入即可。
  • 需要實現(xiàn)一套微件管理機制，成本太高。
• 微應用化
  • 通過軟件工程的方式，在部署構建環(huán)境中通過 webpack 打包，組合多個獨立應用成一個單體應用。
  • 需要將多個項目打包成一個，所以技術棧需要保持統(tǒng)一。
• 應用組件化
  • 將子項目都打包成 webComponent，在主項目中組合。
  • 需要考慮 webComponent 兼容性。

下圖是各種方案的優(yōu)缺點：

這么多方案，各有利弊，我們應該如何選擇呢？

• 如果只是想簡單快速的做分離，不考慮 seo，可以用 iframe。

• 如果想做分離的同時，保持良好的單頁體驗，可以考慮 single-spa、qiankun 框架。

• 如果公司有很強的技術能力，再考慮自研或其他方案。

有了技術方案之后，微前端這條路就可以走通了，除此之外，還需考慮過渡方案。

過渡方案

過渡方案指的是如何讓微前端平滑上線。試想一下，如果在微前端改造時，項目來了新需求，這時應該怎么辦？

對于這個問題，建議在做微前端改造時，最好快速上線：

1. 首先將整個原項目當成一個大的子項目，進行微前端改造。
2. 主項目快速搭建好路由、子應用管理，然后立即上線。
   1. 路由管理在處理子項目時，如果是原頁面，先通過 a 標簽跳轉，如果是新頁面，則使用前端 router 控制跳轉。
   2. 后續(xù)逐漸拆分子項目，如果有新的子項目拆分完畢，只需要將 a 標簽跳轉改為前端 router 控制即可。
3. 做完前兩步之后，我們的架構就已經(jīng)變成了微前端架構。

拆分方案調(diào)研

第三步，我們需要想想，我們要怎么拆分我們的項目呢？

常見的拆分方案如下：

• 按照業(yè)務拆分
  • 如：一個電商后臺，包括商品管理、商家管理、物流管理等。
  • 獨立出每個業(yè)務項目，可以讓整個項目結構清晰。
• 按照權限拆分
  • 如：一個運營后臺，管理員和普通運營看到的頁面是不一樣的。
  • 獨立出不同的權限項目，可以突出每個項目的使用范圍。
• 按照變更的頻率拆分
  • 如：一個項目中，包含很少改動的祖?zhèn)黜椖亢徒?jīng)常改動的業(yè)務項目。
  • 獨立出變更頻繁的項目，可以避免頻繁更新可能導致整體項目掛掉的風險。
  • 獨立出很少改動的項目，可以讓我們在核心業(yè)務上大展拳腳。
• 按照組織結構拆分
  • 如：一個功能復雜的項目后臺，由多個團隊共同開發(fā)而成。
  • 獨立出不同團隊的項目，可以避免開發(fā)沖突，部署沖突等問題。
• 跟隨后端微服務拆分
  • 如：后端已經(jīng)做了不同模塊的微服務劃分，前端可以直接按照后端來就行了。
  • 這種方式有利于前后端保持統(tǒng)一。

到了這里，我們已經(jīng)完成了微前端的拆分，但并不是拆完了就結束了，我們還考慮一些拆分后的問題。

例如：

• 主項目和子項目的樣式是否需要復用？
• 項目權限，是分開還是在統(tǒng)一管理？
• 應用之間如何進行通信？

這些問題往往和業(yè)務相關，我們在改造時自行判斷即可。

部署流程檢查

最后一步，我們需要考慮部署流程。

當微前端開發(fā)完成之后，我們的項目由 1 個變成了 1 + n(子項目) 個，部署方式勢必會發(fā)生變化。

傳統(tǒng)的部署方式如下：

微前端項目部署方式如下：

可以看到，項目最終的結構已經(jīng)完全不同了，開發(fā)，測試，部署的流程也都需要進行變化。

• 開發(fā)環(huán)境的部署
• 測試環(huán)境的部署
• 線上環(huán)境的部署

開發(fā)環(huán)境的部署

開發(fā)環(huán)境其實不需要部署，通常是前端啟動一個 localhost 頁面，去調(diào)后端的接口進行開發(fā)。

需要注意的是：

• 子項目需支持獨立啟動，而不是在開發(fā)時啟動所有項目，只需啟動與業(yè)務相關的子項目即可。
• 子項目需支持獨立部署，開發(fā)完成之后，只需要部署與業(yè)務相關的子項目即可。

測試環(huán)境的部署

測試環(huán)境部署變化挺大的，而且涉及到了跨部門溝通，所以應該謹慎對待。

以前測試部署流程是：前端只需要提供一個打包文件，測試將文件解壓后，放入指定的靜態(tài)資源目錄即可。

微前端之后的部署流程：前端需要提供主項目和相關子項目的打包文件，測試需要分別發(fā)布多個項目，才能進行測試。

這樣改動之后，測試的工作量變大了，對于手動部署的測試來說，確實有很大的影響。為了減少測試的工作量，我們可以協(xié)助測試來搭建一套自動化部署工具。

很多大廠都有自己內(nèi)部的云服務平臺，就像阿里云的 k8s 控制臺一樣，測試可以在控制臺上選擇需要部署的前端、后端的分支，然后點擊一鍵部署，就搞定了。

上線環(huán)境部署

對于線上環(huán)境來說，運行的是 1 個主項目和 n 個子項目，每個項目都是獨立部署且相互獨立的，非常適合容器化部署，即：每一個項目都被部署到一個 docker 中，彼此通過主項目進行關聯(lián)。

如圖，所有的子項目都交由主項目管理。

如果公司內(nèi)部做了持續(xù)部署，部署就會更加簡單。

思考與總結

本文從需求分析開始，一步一步理清了微前端需要注意的各種問題，以及一些解決方案，希望能對微前端感興趣的你有所收獲。

其實，微前端沒有想象中的那么難，如果是用 qiankun、single-spa 等現(xiàn)成框架，學習成本都非常低，關鍵是要真正動手去做，只要開了頭，后面的問題也就不是什么問題了。

最后，如果你對此有任何想法，歡迎一起評論！

為了方便大家更好的交流與學習，我們決定創(chuàng)建一個「前端Node交流群」，這里有 Node進階，微前端實踐等等，為大家提供一個更好的技術交流渠道！在我其他群的小伙伴就不要進了。一起加油鴨！

“在看轉發(fā)”是最大的支持