微前端自檢清單

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

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

需求分析

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

例如：

• 產品要新增一個業務模塊
• 產品要修改項目樣式
• 產品反饋項目啓動太慢了
• 產品反饋頁面跳轉刷新很不友好

前兩個需求是典型的業務需求，它的核心在於解決公司的業務問題，對於這一類需求，一般技術難度都不大，開發者只須要按照原型圖，編寫出對應的頁面就能夠了。

後兩個需求是典型的技術需求，它的核心在於解決技術問題。一般來講，技術需求和用戶體驗有關，但不會影響項目功能，因此通常產品不多會提技術需求，都是由開發同窗主導。

目前不少公司都不過重視技術需求，主要是由於和公司業務無關，不能帶來真實可見的收益。其實否則，一些技術需求每每能產生巨大的成本收益，因此咱們在作技術需求時，首先須要獲得公司的支持。

爲何選擇微前端

解決一個技術需求，有不少種方法，爲何選微前端？

咱們看過微前端的發展史就會明白，它並非憑空出現的，而是項目在不斷髮展過程當中造成的，解決項目臃腫的技術方案。

一個項目在剛成立時，體量很小，但隨着項目不斷作大，可能會出現如下問題：

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

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

有了微前端以後，咱們能將一個大項目拆分紅多個小項目，這樣一來，每個小項目就很是好優化了。在優化了全部的小項目後，咱們再將這些小項目組合起來，就能造成一個完美的大項目了。

在實際項目中，若是遇到如下問題，能夠考慮使用微前端：

• 項目太大，成爲了典型的巨石應用，打包很慢。
• 項目開發者太多，多個同窗開發同一套代碼，常常出現代碼衝突、或修改公共組件引起的 Bug。
• 項目太老，存在遺留模塊，爲了兼容它，限制了整個項目的發展。
• 項目技術棧不統一，使用了多種不一樣框架，每一種框架又有多個版本共存的狀況。
• 項目由多個團隊協同開發，一個功能須要等其餘團隊開發好以後，才能接着開發。
• 項目每次發佈都是全量發佈，即便是上線一個小模塊，也可能致使整個項目掛掉。
• 項目由多個系統組成，完成一個功能須要不斷地跳轉多個系統頁。
• 項目開發人員流動大，存在一些祖傳代碼難以維護，通常人都很差改。
• 項目須要一些試驗田方案，即須要在某些模塊作一些新技術嘗試、框架升級等。
• ...

除此以外，還有不少實際狀況沒有列舉完畢，不過不要緊，只要咱們明白了微前端的特色，就能判斷任何狀況。

微前端特色

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

• 簡單、鬆耦合的代碼庫

  • 微前端架構傾向於編寫和維護更小、更簡單、更容易開發的項目。
  • 技術棧無關，各項目可使用不一樣的技術棧。

• 增量升級

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

• 獨立部署

  • 每個子應用都具有獨立開發，持續部署，獨立運行的能力。

• 團隊自治

  • 各子項目之間不存在依賴關係，保持隔離。
  • 單一職責，每一個子項目只作和本身相關的業務工做。

除此以外，微前端提供了一套新的生態系統。它經過拆分小項目，產生了大量的微應用。試想一下，若是你們都將微應用上傳到雲，那麼就會構建一個很是強大的微應用雲生態。咱們在之後作需求時，也許就是選擇各類適合的微應用，而後拼接起來，就完事了。

對此保持期待。

微前端的缺點

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

• 拆分的粒度越小，便意味着架構變得複雜、維護成本變高。
• 技術棧一旦多樣化，便意味着技術棧混亂。
• 管理版本複雜、依賴複雜。
• 開發體驗不太友好，開發時可能須要同時啓動多個項目。

這些問題大可能是由於項目拆分紅多個項目以後，引起的溝通協做問題。

技術方案調研

第二步，咱們須要肯定具體的微前端實現方式。

實現微前端有不少種方式：

• 路由分發式

  • 經過 http 服務器的反向代理功能，來將請求路由到對應的應用上。
  • 這種方式只是在路由層面看起來是一個項目，但實際上只是經過 a 標籤鏈接了多個項目。

• 前端容器化

  • 使用 iframe 做爲容器。
  • seo 不友好。
  • 須要考慮同源策略 cookie 管理。
  • 須要自建一套應用管理、應用通訊機制。
  • 彈窗不友好。
  • 瀏覽器後退按鈕不友好。

• 前端微服務化

  • 在不一樣的框架之上設計通信、加載機制，以在一個頁面內加載對應的應用。
  • 經常使用的框架：qiankun，single-spa 都是這樣作的。
  • 最經常使用的方案，適合於快速上手。

• 微件化

  • 打包出能夠直接嵌入在頁面上運行的代碼，多是一段 js，使用時直接引入便可。
  • 須要實現一套微件管理機制，成本過高。

• 微應用化

  • 經過軟件工程的方式，在部署構建環境中經過 webpack 打包，組合多個獨立應用成一個單體應用。
  • 須要將多個項目打包成一個，因此技術棧須要保持統一。

• 應用組件化

  • 將子項目都打包成 webComponent，在主項目中組合。
  • 須要考慮 webComponent 兼容性。

下圖是各類方案的優缺點：

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

• 若是隻是想簡單快速的作分離，不考慮 seo，能夠用 iframe。
• 若是想作分離的同時，保持良好的單頁體驗，能夠考慮 single-spa、qiankun 框架。
• 若是公司有很強的技術能力，再考慮自研或其餘方案。

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

過渡方案

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

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

1. 首先將整個原項目當成一個大的子項目，進行微前端改造。

2. 主項目快速搭建好路由、子應用管理，而後當即上線。

   1. 路由管理在處理子項目時，若是是原頁面，先經過 a 標籤跳轉，若是是新頁面，則使用前端 router 控制跳轉。
   2. 後續逐漸拆分子項目，若是有新的子項目拆分完畢，只須要將 a 標籤跳轉改成前端 router 控制便可。
3. 作完前兩步以後，咱們的架構就已經變成了微前端架構。

拆分方案調研

第三步，咱們須要想一想，咱們要怎麼拆分咱們的項目呢？

常見的拆分方案以下：

• 按照業務拆分

  • 如：一個電商後臺，包括商品管理、商家管理、物流管理等。
  • 獨立出每一個業務項目，可讓整個項目結構清晰。

• 按照權限拆分

  • 如：一個運營後臺，管理員和普通運營看到的頁面是不同的。
  • 獨立出不一樣的權限項目，能夠突出每一個項目的使用範圍。

• 按照變動的頻率拆分

  • 如：一個項目中，包含不多改動的祖傳項目和常常改動的業務項目。
  • 獨立出變動頻繁的項目，能夠避免頻繁更新可能致使總體項目掛掉的風險。
  • 獨立出不多改動的項目，可讓咱們在覈心業務上大展拳腳。

• 按照組織結構拆分

  • 如：一個功能複雜的項目後臺，由多個團隊共同開發而成。
  • 獨立出不一樣團隊的項目，能夠避免開發衝突，部署衝突等問題。

• 跟隨後端微服務拆分

  • 如：後端已經作了不一樣模塊的微服務劃分，前端能夠直接按照後端來就好了。
  • 這種方式有利於先後端保持統一。

到了這裏，咱們已經完成了微前端的拆分，但並非拆完了就結束了，咱們還考慮一些拆分後的問題。

例如：

• 主項目和子項目的樣式是否須要複用？
• 項目權限，是分開仍是在統一管理？
• 應用之間如何進行通訊？

這些問題每每和業務相關，咱們在改造時自行判斷便可。

部署流程檢查

最後一步，咱們須要考慮部署流程。

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

傳統的部署方式以下：

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

能夠看到，項目最終的結構已經徹底不一樣了，開發，測試，部署的流程也都須要進行變化。

• 開發環境的部署
• 測試環境的部署
• 線上環境的部署

開發環境的部署

開發環境其實不須要部署，一般是前端啓動一個 localhost 頁面，去調後端的接口進行開發。

須要注意的是：

• 子項目需支持獨立啓動，而不是在開發時啓動全部項目，只需啓動與業務相關的子項目便可。
• 子項目需支持獨立部署，開發完成以後，只須要部署與業務相關的子項目便可。

測試環境的部署

測試環境部署變化挺大的，並且涉及到了跨部門溝通，因此應該謹慎對待。

之前測試部署流程是：前端只須要提供一個打包文件，測試將文件解壓後，放入指定的靜態資源目錄便可。

微前端以後的部署流程：前端須要提供主項目和相關子項目的打包文件，測試須要分別發佈多個項目，才能進行測試。

這樣改動以後，測試的工做量變大了，對於手動部署的測試來講，確實有很大的影響。爲了減小測試的工做量，咱們能夠協助測試來搭建一套自動化部署工具。

不少大廠都有本身內部的雲服務平臺，就像阿里雲的 k8s 控制檯同樣，測試能夠在控制檯上選擇須要部署的前端、後端的分支，而後點擊一鍵部署，就搞定了。

上線環境部署

對於線上環境來講，運行的是 1 個主項目和 n 個子項目，每一個項目都是獨立部署且相互獨立的，很是適合容器化部署，即：每個項目都被部署到一個 docker 中，彼此經過主項目進行關聯。

如圖，全部的子項目都交由主項目管理。

若是公司內部作了持續部署，部署就會更加簡單。

思考與總結

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

其實，微前端沒有想象中的那麼難，若是是用 qiankun、single-spa 等現成框架，學習成本都很是低，關鍵是要真正動手去作，只要開了頭，後面的問題也就不是什麼問題了。

最後，若是你對此有任何想法，歡迎留言評論！