微前端的原理及實現

1、簡介

只聽過「微服務」,「微前端」又是什麼硬核技術?html

它正是借鑑微服務的概念來應用在前端上,將一個巨大的前端工程拆分紅一個的小工程,這些小工程具有獨立的開發和運行能力,而整個系統就由這些小工程協同合做。前端

微前端是一種相似於微服務的架構,它將微服務的理念應用於瀏覽器端,即將單頁面前端應用由單一的單體應用轉變爲多個小型前端應用聚合爲一的應用。各個前端應用還能夠獨立開發、獨立部署。同時,它們也能夠在共享組件的同時進行並行開發——這些組件能夠經過 NPM 或者 Git來管理。

能夠跟微服務這麼對比着去理解:bootstrap

微服務 微前端
一個微服務就是由一組接口構成,接口地址通常是 URL。當微服務收到一個接口的請求時,會進行路由找到相應的邏輯,輸出響應內容。 一個微前端則是由一組頁面構成,頁面地址也是 URL。當微前端收到一個頁面 URL 的請求時,會進行路由找到相應的組件,渲染頁面內容。
後端微服務會有一個網關,做爲單一入口接收全部的客戶端接口請求,根據接口 URL 與服務的匹配關係,路由到對應的服務。 微前端則會有一個加載器,做爲單一入口接收全部頁面 URL 的訪問,根據頁面 URL 與微前端的匹配關係,選擇加載對應的微前端,由該微前端進行進行路由響應 URL。

2、 爲何須要微前端

在 toB 的前端開發工做中,咱們每每就會遇到以下困境:後端

  1. 工程愈來愈大,打包愈來愈慢
  2. 團隊人員多,產品功能複雜,代碼衝突頻繁、影響面大
  3. 心裏想作 SaaS 產品,但客戶老是要作定製化

微前端的實現,意味着對前端應用的拆分。拆分應用的目的,並不僅是爲了架構上好看,還爲了提高開發效率。瀏覽器

微前端帶來這麼一系列的好處:前端框架

  1. 應用自治。只須要遵循統一的接口規範或者框架,以便於系統集成到一塊兒,相互之間是不存在依賴關係的。
  2. 單一職責。每一個前端應用能夠只關注於本身所須要完成的功能。
  3. 技術棧無關。你可使用 Angular 的同時,又可使用 React 和 Vue。

除此,它也有一系列的缺點:服務器

  1. 應用的拆分基礎依賴於基礎設施的構建,一旦大量應用依賴於同一基礎設施,那麼維護變成了一個挑戰。
  2. 拆分的粒度越小,便意味着架構變得複雜、維護成本變高。
  3. 技術棧一旦多樣化,便意味着技術棧混亂。

3、如何設計微前端架構

就當前而言,要設計出一個微前端應用不是一件容易的事——尚未最佳實踐。在不一樣的落地案例裏,使用的都是不一樣的方案。出現這種狀況的主要緣由是,每一個項目所面臨的狀況、所使用的技術都不盡相同。爲此,咱們須要瞭解一些基礎的微前端模式。架構

1. 架構模式

微前端應用間的關係來看,分爲兩種:基座模式(管理式)、自組織式。分別也對應了二者不一樣的架構模式:框架

基座模式。經過一個主應用,來管理其它應用。設計難度小,方便實踐,可是通用度低。
自組織模式。應用之間是平等的,不存在相互管理的模式。設計難度大,不方便實施,可是通用度高。ide

就當前而言,基座模式實施起來比較方便,方案上便也是蠻多的。

而不論種方式,都須要提供一個查找應用的機制,在微前端中稱爲服務的註冊表模式。和微服務架構類似,不管是哪一種微前端方式,也都須要有一個應用註冊表的服務,它能夠是一個固定值的配置文件,如 JSON 文件,又或者是一個可動態更新的配置,又或者是一種動態的服務。它主要作這麼一些內容:

應用發現。讓主應用能夠尋找到其它應用。應用註冊。即提供新的微前端應用,嚮應用註冊表註冊的功能。第三方應用註冊。即讓第三方應用,能夠接入到系統中。訪問權限等相關配置。

應用在部署的時候,即可以在註冊表服務中註冊。若是是基於註冊表來管理應用,那麼使用基座模式來開發比較方便。

2. 設計理念

在筆者實踐微前端的過程當中,發現瞭如下幾點是咱們在設計的過程當中,須要關注的內容:

中心化:應用註冊表。這個應用註冊表擁有每一個應用及對應的入口。在前端領域裏,入口的直接表現形式能夠是路由,又或者對應的應用映射。
標識化應用: 咱們須要一個標識符來標識不一樣的應用,以便於在安裝、卸載的時候,能尋找到指定的應用。一個簡單的模式,就是經過康威定律來命名應用。應用生命週期管理。高內聚,低耦合。

3. 生命週期

前端微架構與後端微架構的最大不一樣之處,也在於此——生命週期。微前端應用做爲一個客戶端應用,每一個應用都擁有本身的生命週期:

Load,決定加載哪一個應用,並綁定生命週期
bootstrap,獲取靜態資源
Mount,安裝應用,如建立 DOM 節點
Unload,刪除應用的生命週期
Unmount,卸載應用,如刪除 DOM 節點、取消事件綁定.

這部分的內容事實上,也就是微前端的一個難點所在,如何以合適的方式來加載應用——畢竟每一個前端框架都各自不一樣,其所須要的加載方式也是不一樣的。當咱們決定支持多個框架的時候,便須要在這一部分進入更細緻的研究。
隨後,咱們要面臨的一個挑戰是:如何去拆分應用。

4. 技術方式

從技術實踐上,微前端架構能夠採用如下的幾種方式進行:

  1. 路由分發式。經過 HTTP 服務器的反向代理功能,來將請求路由到對應的應用上。
  2. 前端微服務化。在不一樣的框架之上設計通信、加載機制,以在一個頁面內加載對應的應用。
  3. 微應用。經過軟件工程的方式,在部署構建環境中,組合多個獨立應用成一個單體應用。
  4. 微件化。開發一個新的構建系統,將部分業務功能構建成一個獨立的 chunk 代碼,使用時只須要遠程加載便可。
  5. 前端容器化。經過將 iFrame 做爲容器,來容納其它前端應用。
  6. 應用組件化。藉助於 Web Components 技術,來構建跨框架的前端應用。

實施的方式雖然多,可是都是依據場景而採用的。有些場景下,可能沒有合適的方式;有些場景下,則能夠同時使用多種方案。

https://alili.tech/archive/11...

https://qiankun.umijs.org/zh/...

https://baijiahao.baidu.com/s...

https://www.cnblogs.com/scdis...

相關文章
相關標籤/搜索