聊聊微前端的那些事兒~

語言: CN / TW / HK

這是我參與11月更文挑戰的第26天,活動詳情檢視:2021最後一次更文挑戰

現在 微前端 這個概念在前端圈越來越火熱,在2021年,如果你還沒聽過這個詞,那就真的out了

本篇文章準備對微前端這個概念做下科普,通過閱讀這篇文章,可以讓你知道微前端是啥以及有啥作用,廢話不多說,開搞!

ppx2.jpg

什麼是微前端

其實微前端是借鑑了 微服務 的理念創造出來的,那微服務是啥呢?它是將一個大的應用服務切分為多個子服務,從而解耦各個子服務,提升整體服務的健壯以及可維護性。微前端其實也是差不多的,傳統方式開發出的web應用是一個 巨石應用,所有的功能、資源都繫結在一起,而微前端可以將這些巨石應用切分成許多 子應用,從而解耦各個功能模組,它跟微服務是異曲同工的

666.jpg

微前端架構下會分為父應用(基座)和子應用,父應用用來展示 公共部分,如header、footer,以及管理各個子應用,子應用是用來承載不同的業務功能

實現微前端的方案

目前實現微前端的方案還是很多的,列舉如下

  • 通過類似 nginx伺服器 的轉發,對不同的url返回對應的服務頁面,這本質上是伺服器利用路由轉發的功能來實現的
  • 通過 package 整合,具體方式如下
  • 將巨石應用劃分為 容器應用子應用
  • 將子應用作為容器應用的 依賴項

這種方式的缺點是每次對某一個子應用的更改,都需要重新編譯打包所有應用,因此不推薦此類方式

  • 通過 iframe 實現,由於iframe原生支援隔離,因此可以作為方案之一,但它的優點也是它的缺點,因為隔離太嚴格,導致路由、歷史記錄、深層連結、樣式、應用之間的通訊處理上變得較為複雜
  • 使用 js 來構建微前端架構,由於該方式靈活和較為可控,因此這種方式是目前的主流。每個子應用獨立構建和部署,執行時由父應用來進行路由管理,應用載入,啟動,解除安裝,以及通訊。但凡事沒有完美,這種方式同樣會有如下缺陷
  • js全域性變數汙染與衝突,由於子應用與父應用跑在一個頁面上,那麼如果不做好隔離,就很容易產生汙染與衝突的問題,解決方案的話通常是使用沙箱機制,具體方式是採用 with() + new Function(code) + Proxy 來實現
  • css樣式衝突,眾所周知,css不存在模組系統,所有的css都是作用於全域性的,因此如果很容易產生衝突。對於css隔離,一般使用BEM、cssModule、css in js、shadow dom來解決
  • 使用 webComponents 來構建,但由於目前存在瀏覽器相容以及瀏覽器實現上的一些bug,因此不推薦使用

微前端帶來的好處

由於微前端可以將巨石應用切分為多個子應用,因此靈活性大大提高,具體可以帶來如下好處

  • 由於子應用之間的解耦,可以大大降低系統複雜度,提升系統穩定性
  • 子應用之間的開發、測試、釋出流程完全獨立,可以由不同的團隊進行負責
  • 由於子應用之間的完全獨立,因此可以使用不同的技術棧
  • 程式碼庫也會被切分為許多小的子庫,更加便於維護與管理
  • 可以較為平滑地遷入老專案

微前端帶來的壞處

任何事情有舍就有得,微前端並不是完美的,它同樣存在以下問題

  • 重複依賴項較多
  • 開發環境較難實現與生產環境一致,因為當微應用越來越多,在本地開發時肯定無法把所有微應用和對應的後端都啟動起來,那麼你就不得不在本地進行環境的簡化
  • 由於劃分出了很多團隊,那麼對不同團隊之間的協作提出了更高的要求

推薦的微前端框架

目前市面上已經有成熟的微前端框架供我們使用,列舉如下:

  • Mooa:基於Angular的微前端服務框架
  • Single-Spa:最早的微前端框架,相容多種前端技術棧
  • Qiankun:基於Single-Spa,阿里系開源微前端框架,也是目前我唯一使用過的
  • Icestark:阿里飛冰微前端框架,相容多種前端技術棧
  • Ara Framework:由服務端渲染延伸出的微前端框架

結語

微前端的應用越來越廣泛,未來越是前端技術發展的趨勢,因此一定要掌握它,才能在未來的技術浪潮站穩腳跟,因此,加油吧,騷年!