自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

一文帶你進入微前端世界

開發(fā) 前端
微前端架構(gòu)旨在解決單體應(yīng)用在一個相對長的時間跨度下,由于參與的人員、團隊的增多、變遷,從一個普通應(yīng)用演變成一個巨石應(yīng)用(Frontend Monolith)后,隨之而來的應(yīng)用不可維護的問題。

什么是微前端

微前端(Micro-Frontends)是一種類似于微服務(wù)的架構(gòu),它將微服務(wù)的理念應(yīng)用于瀏覽器端,即將 Web 應(yīng)用由單一的單體應(yīng)用轉(zhuǎn)變?yōu)槎鄠€小型前端應(yīng)用聚合為一的應(yīng)用。微前端(micro-frontends)術(shù)語在 2016 年在 TECHNOLOGY RADAR[1] 中被提及。

微前端架構(gòu)具備以下的特點:

  • 技術(shù)棧無關(guān)。主框架不限制接入應(yīng)用的技術(shù)棧,微應(yīng)用具備完全自主權(quán)
  • 獨立開發(fā)、獨立部署。微應(yīng)用倉庫獨立,前后端可獨立開發(fā),部署完成后主框架自動完成同步更新
  • 增量升級。在面對各種復雜場景時,我們通常很難對一個已經(jīng)存在的系統(tǒng)做全量的技術(shù)棧升級或重構(gòu),而微前端是一種非常好的實施漸進式重構(gòu)的手段和策略
  • 獨立運行時。每個微應(yīng)用之間狀態(tài)隔離,運行時狀態(tài)不共享

微前端解決了什么問題?

微前端架構(gòu)旨在解決單體應(yīng)用在一個相對長的時間跨度下,由于參與的人員、團隊的增多、變遷,從一個普通應(yīng)用演變成一個巨石應(yīng)用(Frontend Monolith)后,隨之而來的應(yīng)用不可維護的問題。比如:

  • 原本一個團隊管理的項目,后面多個團隊進行管理
  • 隨著項目的體積變大,編譯的速度變長,研發(fā)效率降低
  • 項目變大,系統(tǒng)的復雜度也會隨之變大,可維護性越來越低,重構(gòu)成本越來越大
  • ...

通過微前端拆分成一個容器應(yīng)用和多個子應(yīng)用之后,各個應(yīng)用能夠獨立部署,相互之間隔離,從而做到:

  • 研發(fā)效率提升:多業(yè)務(wù)線并行開發(fā),團隊自治,獨立迭代
  • 運維風險降級:變更范圍縮小
  • 技術(shù)選擇增多:各個應(yīng)用可以選擇更加適合自身的技術(shù)棧
  • 重構(gòu)風險降低:低風險局部替換,漸進式完成大規(guī)模重構(gòu)
  • ...

微前端實現(xiàn)方案

對比Nginx路由轉(zhuǎn)發(fā)

通過Nginx配置反向代理來實現(xiàn)不同路徑映射到不同應(yīng)用,例如www.abc.com/app1對應(yīng)app1,www.abc.com/app2對應(yīng)app2,這種方案本身并不屬于前端層面的改造,更多的是運維的配置。

優(yōu)點:

  1. 簡單,快速,易配置

缺點:

  1. 在切換應(yīng)用時會觸發(fā)瀏覽器刷新,影響體驗

iframe嵌套

父應(yīng)用單獨是一個頁面,每個子應(yīng)用嵌套一個iframe,父子通信可采用postMessage或者contentWindow方式。

優(yōu)點:

  • 實現(xiàn)簡單,子應(yīng)用之間自帶沙箱,天然隔離,互不影響

缺點:

  • url 不同步。瀏覽器刷新 iframe url 狀態(tài)丟失、后退前進按鈕無法使用。
  • UI 不同步,DOM 結(jié)構(gòu)不共享。想象一下屏幕右下角 1/4 的 iframe 里來一個帶遮罩層的彈框,同時我們要求這個彈框要瀏覽器居中顯示,還要瀏覽器 resize 時自動居中..
  • 全局上下文完全隔離,內(nèi)存變量不共享。iframe 內(nèi)外系統(tǒng)的通信、數(shù)據(jù)同步等需求,主應(yīng)用的 cookie 要透傳到根域名都不同的子應(yīng)用中實現(xiàn)免登效果。
  • 慢。每次子應(yīng)用進入都是一次瀏覽器上下文重建、資源重新加載的過程。

Web Components

每個子應(yīng)用需要采用純Web Components技術(shù)編寫組件,是一套全新的開發(fā)模式

優(yōu)點:

  • 每個子應(yīng)用擁有獨立的script和css,也可單獨部署

缺點:

  • 對于歷史系統(tǒng)改造成本高,子應(yīng)用通信較為復雜易踩坑

webpack5 的 Module Federation

使用 Module Federation,我們可以在一個應(yīng)用中動態(tài)加載并執(zhí)行另一個應(yīng)用的代碼,且與技術(shù)棧無關(guān),并且能夠共享模塊,從而減小編譯時間以及降低包體積。

優(yōu)點:

  • 能夠共享模塊,減小編譯時間以及降低包體積

缺點:

  • 需要升級 webpack5,構(gòu)建工具受限

組合式應(yīng)用路由分發(fā)

每個子應(yīng)用獨立構(gòu)建和部署,運行時由父應(yīng)用來進行路由管理,應(yīng)用加載,啟動,卸載,以及通信機制。

優(yōu)點:

  • 純前端改造,體驗良好,可無感知切換,子應(yīng)用相互隔離

缺點:

  • 需要設(shè)計和開發(fā),由于父子應(yīng)用處于同一頁面運行,需要解決子應(yīng)用的樣式?jīng)_突,變量對象污染,通信機制等技術(shù)點

組合式應(yīng)用路由分發(fā)是目前業(yè)內(nèi)普遍使用的一種方案,并且能夠滿足大部分需求,接下來我們詳細來看看這種實現(xiàn)方式。

組合式應(yīng)用路由分發(fā)的微前端實現(xiàn)思路

該方案使用的是基座模式,通過一個主應(yīng)用(基座應(yīng)用-Main APP),來管理其它應(yīng)用(子應(yīng)用-MicroAPP)。基座應(yīng)用大多數(shù)是一個前端 SPA 項目,主要負責應(yīng)用注冊,路由映射,消息下發(fā)等,而微應(yīng)用是獨立前端項目,這些項目不限于采用 React,Vue,Angular 或者 JQuery 開發(fā),每個微應(yīng)用注冊到基座應(yīng)用中,由基座進行管理,但是如果脫離基座也是可以單獨訪問。

圖片

當整個微前端框架運行之后,給用戶的體驗就是類似下圖所示:

圖片

簡單描述下就是基座應(yīng)用中有一些菜單項,點擊每個菜單項可以展示對應(yīng)的微應(yīng)用,這些應(yīng)用的切換是純前端無感知的

上面的實現(xiàn)過程主要如下:

  • 獲取注冊表和進行初始化,這些都是在基座應(yīng)用中進行的。
  • 路由分發(fā)。在瀏覽器路徑發(fā)生變化后,基座應(yīng)用會監(jiān)聽 hashchange 或者 popstate 事件,從而獲取到路由切換的時機。通過查詢注冊信息可以獲取到轉(zhuǎn)發(fā)到那個微應(yīng)用,經(jīng)過一些邏輯處理后,采用修改hash方法或者pushState方法來路由信息推送給微應(yīng)用的路由,微應(yīng)用可以是手動監(jiān)聽hashchange或者popstate事件接收,或者采用React-router,vue-router接管路由,后面的邏輯就由微應(yīng)用自己控制。
  • 遠程拉取資源,加載應(yīng)用。這里一般有通過 JavaScript Entry 或者 HTML Entry 作為渲染入口。

注意:子應(yīng)用也可以將包打成多個,然后利用 webpack 的 webpack-manifest-plugin 插件打包出 manifest.json
文件,生成一份資源清單,然后主應(yīng)用的 loadApp 遠程讀取每個子應(yīng)用的清單文件,依次加載文件里面的資源;不過該方案也沒辦法享受子應(yīng)用的按需加載能力。

  • HTML Entry。則更加靈活,直接將子應(yīng)用打出來 HTML 作為入口,主框架可以通過 fetch html 的方式獲取子應(yīng)用的靜態(tài)資源,同時將 HTML document 作為子節(jié)點塞到主框架的容器中。這樣不僅可以極大的減少主應(yīng)用的接入成本,子應(yīng)用的開發(fā)方式及打包方式基本上也不需要調(diào)整,而且可以天然的解決子應(yīng)用之間樣式隔離的問題(后面提到)。這種方案可以通過 。
  • JavaScript Entry。通常是子應(yīng)用將資源打成一個 entry script。但這個方案的限制也頗多,如要求子應(yīng)用的所有資源打包到一個 js bundle 里,包括 css、圖片等資源。除了打出來的包可能體積龐大之外的問題之外,資源的并行加載等特性也無法利用上。

微前端的應(yīng)用隔離

CSS 隔離

當主應(yīng)用和微應(yīng)用同屏渲染時,就可能會有一些樣式會相互污染,可以采取以下兩種方案:

  • CSS Module
  • 命名空間,通過 webpack 的 postcss 插件,在打包時添加特定的前綴,即各個子應(yīng)用使用特定的前綴來命名 class。但對于一些插入到 body 中的樣式,比如 element UI 的 Popover 彈出框,這種就特殊處理。

而對于微應(yīng)用與微應(yīng)用之間的CSS隔離就非常簡單,在每次應(yīng)用加載時,將該應(yīng)用所有的link和style 內(nèi)容進行標記。在應(yīng)用卸載后,同步卸載頁面上對應(yīng)的link和style即可。

JavaScript 隔離

每當微應(yīng)用的 JavaScript 被加載并運行時,它的核心實際上是對全局對象 Window 的修改以及一些全局事件的改變,例如 jQuery 這個 js 運行后,會在 Window 上掛載一個 window.$ 對象,對于其他庫 React,Vue 也不例外。為此,需要在加載和卸載每個微應(yīng)用的同時,盡可能消除這種沖突和影響,最普遍的做法是采用沙箱機制(SandBox)。

沙箱機制的核心是讓局部的 JavaScript 運行時,對外部對象的訪問和修改處在可控的范圍內(nèi),即無論內(nèi)部怎么運行,都不會影響外部的對象。通常在 Node.js 端可以采用 vm 模塊,而對于瀏覽器,則需要結(jié)合 with 關(guān)鍵字和 window.Proxy 對象來實現(xiàn)瀏覽器端的沙箱。

微前端的消息通信

微前端通常不會限制應(yīng)用采用的框架,如何在不同的應(yīng)用,框架之間進行通信是一個需要仔細考量的決定。應(yīng)用間通信有很多種方式,當然,要讓多個分離的微應(yīng)用之間要做到通信,本質(zhì)上仍離不開中間媒介或者說全局對象。

自定義事件

通過事件[3]進行通信應(yīng)該是最簡單、通用的方案了。

// 監(jiān)聽事件
window.addEventListener('message', (event) => {
// 處理事件
});

// 觸發(fā)事件
window.dispatchEvent(new CustomEvent('message', { detail: input.value }))

發(fā)布-訂閱

消息訂閱(pub/sub)模式的通信機制是非常適用的,在基座應(yīng)用中會定義事件中心Event,每個微應(yīng)用分別來注冊事件,當被觸發(fā)事件時再有事件中心統(tǒng)一分發(fā),這就構(gòu)成了基本的通信機制。

import { Observable } from 'windowed-observable';

const observable = new Observable('konoha');
observable.subscribe((ninja) => {
console.log(ninja)
})

observable.publish('Uchiha Shisui');

Web Workers

通過 Web Workers 進行事件通信。

import Worky from 'worky'
const worker = new Worky("some-worker.js");

worker.on("eventName", function (some, data) {
// 處理
});
worker.emit("someEvent", and, some, data);

共享狀態(tài)

主應(yīng)用創(chuàng)建 state store,共享給子應(yīng)用使用,適用于主、子應(yīng)用技術(shù)棧相同的場景。

總結(jié)

微前端是一種將單個巨型應(yīng)用轉(zhuǎn)變?yōu)槎鄠€微型應(yīng)用聚合為一的應(yīng)用,能夠解決“巨石應(yīng)用”的維護性問題。實現(xiàn)微前端的方式有很多種,每種方案都需要考慮應(yīng)用隔離和應(yīng)用通信的問題,目前較為普遍使用的是組合式路由分發(fā)的方式。

參考

  • 微前端(一)- 理念篇[4]
  • 微前端-最容易看懂的微前端知識[5]
  • 微前端在解決什么問題?[6]
  • 微前端如何落地[7]
  • 微前端解決方案[8]
  • HTML Entry 源碼分析[9]

參考資料

[1]TECHNOLOGY RADAR:
https://www.thoughtworks.com/zh-cn/radar/techniques/micro-frontends

[2]import-html-entry:
https://www.npmjs.com/package/import-html-entry

[3]事件:
https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent

[4]微前端(一)- 理念篇:
https://www.lumin.tech/blog/micro-frontends-1-concept/

[5]微前端-最容易看懂的微前端知識:
https://juejin.cn/post/6844904162509979662

[6]微前端在解決什么問題?:
https://cloud.tencent.com/developer/article/1546556

[7]微前端如何落地:
https://www.infoq.cn/article/xm_aaiotxmlppgwvx9y9

[8]微前端解決方案:
https://segmentfault.com/a/1190000040275586

[9]HTML Entry 源碼分析:
https://juejin.cn/post/6885212507837825038#heading-6

責任編輯:武曉燕 來源: 前端雜貨鋪
相關(guān)推薦

2021-10-13 21:43:18

JVMRPC框架

2022-12-20 07:39:46

2023-11-20 08:18:49

Netty服務(wù)器

2023-12-21 17:11:21

Containerd管理工具命令行

2023-11-06 08:16:19

APM系統(tǒng)運維

2021-05-29 10:11:00

Kafa數(shù)據(jù)業(yè)務(wù)

2023-07-31 08:18:50

Docker參數(shù)容器

2022-11-11 19:09:13

架構(gòu)

2023-11-03 15:05:41

2025-03-17 08:15:00

AI技術(shù)模型

2022-02-24 07:34:10

SSL協(xié)議加密

2023-11-08 08:15:48

服務(wù)監(jiān)控Zipkin

2023-10-27 08:15:45

2024-05-22 09:45:49

2021-09-13 22:34:56

區(qū)塊鏈新基建數(shù)字化轉(zhuǎn)型

2022-05-16 10:49:28

網(wǎng)絡(luò)協(xié)議數(shù)據(jù)

2023-03-06 21:29:41

mmap技術(shù)操作系統(tǒng)

2019-06-13 21:31:19

AI

2020-11-27 09:40:53

Rollup前端代碼

2022-04-08 09:01:14

CSS自定義屬性前端
點贊
收藏

51CTO技術(shù)棧公眾號