125、新技术之微前端
目錄
一、微前端是什么？
二、微前端的實現(xiàn)
2.1?iframe
2.2?Web Components
2.3?ESM 即?ES Module
2.4?qiankun
2.5 EMP
2.6 總結(jié)?
三、微前端和npm的區(qū)別
3.1 非常重要的痛點，使用npm包的更新流程繁瑣復雜。
3.2?npm包方式構(gòu)建速度慢
3.3 npm方式 應用迭代麻煩
一、微前端是什么？
（1）微服務
為了解決龐大的一整塊后端服務帶來的變更與擴展方面的限制，出現(xiàn)了微服務架構(gòu)（Microservices）：
微服務是面向服務架構(gòu)（SOA）的一種變體，把應用程序設(shè)計成一系列松耦合的細粒度服務，并通過輕量級的通信協(xié)議組織起來
具體地，將應用構(gòu)建成一組小型服務。這些服務都能夠獨立部署、獨立擴展，每個服務都具有穩(wěn)固的模塊邊界，甚至允許使用不同的編程語言來編寫不同服務，也可以由不同的團隊來管理
（2）微前端
越來越重的前端工程也面臨同樣的問題，自然地想到了將微服務思想應用（照搬）到前端，于是有了「微前端（micro-frontends）」的概念：
即，一種由獨立交付的多個前端應用組成整體的架構(gòu)風格。具體的，將前端應用分解成一些更小、更簡單的能夠獨立開發(fā)、測試、部署的小塊，而在用戶看來仍然是內(nèi)聚的單個產(chǎn)品。
微前端的概念由ThoughtWorks于2016年提出，此后很快被業(yè)界所接受，并在各互聯(lián)網(wǎng)大廠中得到推廣和應用。
注意：
- 微前端不是一門具體的技術(shù)，而是整合了技術(shù)、策略和方法，可能會以腳手架、輔助插件和規(guī)范約束這種生態(tài)圈形式展示出來，是一種宏觀上的架構(gòu)。
- 微前端并沒有技術(shù)棧的約束。如果是多團隊同時使用了react和vue技術(shù)棧，可能就對微前端的跨技術(shù)棧要求比較高。
（3）微服務與微前端的相似之處
- 都是希望將某個單一的單體應用，轉(zhuǎn)化為多個可以獨立運行、獨立開發(fā)、獨立部署、獨立維護的服務或者應用的聚合，從而滿足業(yè)務快速變化及分布式多團隊并行開發(fā)的需求。
- 微服務與微前端不僅僅是技術(shù)架構(gòu)的變化，還包含了組織方式、溝通方式的變化。微服務與微前端原理和軟件工程，面向?qū)ο笤O(shè)計中的原理同樣相通，都是遵循單一職責、關(guān)注分離、模塊化與分而治之等基本的原則。
二、微前端的實現(xiàn)
2.1?iframe
眾所周知，iframe是html提供的標簽，能加載其他web應用的內(nèi)容，并且它能兼容所有的瀏覽器，因此，你可以用它來加載任何你想要加載的web應用。
iframe最大的特性就是提供了瀏覽器原生的硬隔離方案，不論是樣式隔離、js 隔離這類問題統(tǒng)統(tǒng)都能被完美解決。
但是iframe的最大問題也在于他的隔離性無法被突破，導致應用間上下文無法被共享，隨之帶來開發(fā)體驗、產(chǎn)品體驗的問題。
iframe沒能作為官方微前端方案的原因：
2.2?Web Components
Web Components由google推出的瀏覽器的原生組件。
作為開發(fā)者，我們都知道盡可能多的重用代碼是一個好主意。這對于自定義標記結(jié)構(gòu)來說通常不是那么容易 — 想想復雜的HTML（以及相關(guān)的樣式和腳本），有時您不得不寫代碼來呈現(xiàn)自定義UI控件，并且如果您不小心的話，多次使用它們會使您的頁面變得一團糟。
Web Components由三項主要技術(shù)組成，允許創(chuàng)建可重用的定制元素（它們的功能封裝在您的代碼之外），可以在你喜歡的任何地方重用，不必擔心代碼沖突。
它的三項主要技術(shù)是指：
- Custom elements（自定義元素）：一組JavaScript API，允許您定義custom elements及其行為，然后可以在您的用戶界面中按照需要使用它們。
- Shadow DOM（影子DOM）：一組JavaScript API，用于將封裝的“影子”DOM樹附加到元素（與主文檔DOM分開呈現(xiàn)）并控制其關(guān)聯(lián)的功能。通過這種方式，您可以保持元素的功能私有，這樣它們就可以被腳本化和樣式化，而不用擔心與文檔的其他部分發(fā)生沖突。
- HTML templates（HTML模板）： <template> 和 <slot> 元素使您可以編寫不在呈現(xiàn)頁面中顯示的標記模板。然后它們可以作為自定義元素結(jié)構(gòu)的基礎(chǔ)被多次重用。
通過以上描述，再結(jié)合微前端的概念，我們來看看Web Components是如何做到微前端：
綜上所述，Web Components是有能力以組件加載的方式將微應用整合在一起作為微前端的一種手段，但不幸的是，Web Components是瀏覽器的新特性，所以它的兼容性不是很好，如果有兼容性要求的項目還是無法使用。
補充：Shadow DOM（影子DOM）
最常見的shadow DOM就是video/audio標簽。一個video標簽可以描述那么復雜的界面(有暫停、進度條等)，它就屬于shadow DOM。但是我們打開調(diào)試工具，查看video標簽，并沒有發(fā)現(xiàn)什么元素，因為shadow DOM默認不可見。
像 input, audio, video等這些元素是以組件的形式存在的，這些組件內(nèi)部是由一些HTML標簽組成的。當我們訪問網(wǎng)頁DOM結(jié)構(gòu)的時候，這些子樹都會暴露出來。如果DOM的類名和該子樹的類名相同的話，會和子樹的樣式產(chǎn)生沖突，并且我們使用控件的時候，我們并不關(guān)心控件的內(nèi)部結(jié)構(gòu)，只關(guān)心控件本身，因此我們需要將控件的內(nèi)部信息封裝起來。因此 W3C提出了 ShadowDOM的概念，ShadowDOM可以使一些DOM節(jié)點在特定范圍內(nèi)可見，在網(wǎng)頁中是不可見的。但是在頁面渲染的時候也會渲染該ShadowDOM。可以保持元素的功能私有，這樣它們就可以被腳本化和樣式化，而不用擔心與文檔的其他部分發(fā)生沖突。
總結(jié)：
- shadow DOM一般情況下使用肉眼看不到的、無法直接控制操縱的DOM結(jié)構(gòu)；
- 瀏覽器正是通過Shadow DOM，將一些內(nèi)容封裝起來作為一個完整的整體來實現(xiàn)某一個功能，，不用擔心與文檔的其他部分發(fā)生沖突。
2.3?ESM 即?ES Module
ES Module的縮寫，是ECMA?script 2015中提出的一種前端模塊化手段。如何做到微前端的：
- 無技術(shù)棧限制：ESM加載的只是js內(nèi)容，無論哪個框架，最終都要編譯成js，因此，無論哪種框架，ESM都能加載。
- 應用單獨開發(fā)： ESM只是js的一種規(guī)范，不會影響應用的開發(fā)模式。
- 多應用整合： 只要將微應用以ESM的方式暴露出來，就能正常加載。
- 遠程加載模塊: ESM能夠直接請求cdn資源，這是它與生俱來的能力。
但是ESM存在著兼容性問題，大部分老版的瀏覽器仍然無法直接使用。這也是babel等編譯工具出現(xiàn)的原因，它可以通過webpack、rollup、esbuild、snowpack等編譯工具成為兼容性的代碼。
2.4?qiankun
在微前端界，qiankun算得上是最早成型且知名度最廣的框架了，它是真正意義上的單頁微前端框架，qiankun的特點：
- 基于single-spa封裝，提供了更加開箱即用的 API
- 技術(shù)棧無關(guān)，任意技術(shù)棧的應用均可 使用/接入，不論是 React/Vue/Angular/JQuery 還是其他等框架
- HTML Entry 接入方式，讓你接入微應用像使用 iframe 一樣簡單
- 樣式隔離，確保微應用之間樣式互相不干擾
- JS 沙箱，確保微應用之間 全局變量/事件 不沖突
- 資源預加載，在瀏覽器空閑時間預加載未打開的微應用資源，加速微應用打開速度
- umi 插件，提供了 @umijs/plugin-qiankun 供 umi 應用一鍵切換成微前端架構(gòu)系統(tǒng)
除了最后一點拓展以外，微前端想要達到的效果都已經(jīng)達到。
補充：
single-spa是一個很好的微前端基礎(chǔ)框架，qiankun框架就是基于single-spa來實現(xiàn)的，在single-spa的基礎(chǔ)上做了一層封裝，也解決了single-spa的一些缺陷。
single-spa是一個可以讓使用多個使用javascript語言框架的構(gòu)建的應用集成在一起的框架, 使用signle-spa架構(gòu)可以帶來一下好處：
- 在同一個頁面下使用多個框架可以實現(xiàn)無刷新（react/vue/angluar/ember或其他）
- 單個前端應用獨立部署
- 使用新框架無需重寫現(xiàn)有的應用
- 懶加載
2.5 EMP
?EMP是由歡聚時代業(yè)務中臺自主研發(fā)的最年輕的單頁微前端解決方案。特性為：
- 基于Webpack5的新特性Module Federation實現(xiàn)，達到第三方依賴共享，減少不必要的代碼引入的目的，什么是Module Federation這里就不再贅述。
- 每個微應用獨立部署運行，并通過cdn的方式引入主程序中，因此只需要部署一次，便可以提供給任何基于Module Federation的應用使用。并且此部分代碼是遠程引入，無需參與應用的打包。
- 動態(tài)更新微應用：EMP是通過cdn加載微應用，因此每個微應用中的代碼有變動時，無需重新打包發(fā)布新的整合應用便能加載到最新的微應用。
- 去中心化，每個微應用間都可以引入其他的微應用，無中心應用的概念。
- 跨技術(shù)棧組件式調(diào)用，提供了在主應用框架中可以調(diào)用其他框架組件的能力（目前已支持互相調(diào)用的框架及使用方式請參閱官方文檔）。
- 按需加載，開發(fā)者可以選擇只加載微應用中需要的部分，而不是強制只能將整個應用全部加載。
- 應用間通信，每一個應用都可以進行狀態(tài)共享，就像在使用npm模塊進行開發(fā)一樣便捷。
- 生成對應技術(shù)棧模板，它能像create-react-app一樣，也能像create-vue-app一樣，通過指令一鍵搭建好開發(fā)環(huán)境，減少開發(fā)者的負擔。
- 遠程拉取ts聲明文件，emp-cli中內(nèi)置了拉取遠程應用中代碼聲明文件的能力，讓使用ts開發(fā)的開發(fā)者不再為代碼報錯而煩惱。
EMP除了具備微前端的能力外，還實現(xiàn)了跨應用狀態(tài)共享、跨框架組件調(diào)用的能力，這是現(xiàn)有框架所不具備的優(yōu)秀特性！
2.6 總結(jié)?
?1）現(xiàn)有微前端解決方案：
- iframe
- Web Components
- ESM
- qiankun
- EMP
?2）各解決方案的利弊：
-
iframe可以直接加載其他應用，但無法做到單頁導致許多功能無法正常在主應用中展示。
-
web Components及ESM是瀏覽器提供給開發(fā)者的能力，能在單頁中實現(xiàn)微前端，不過后者需要做好代碼隔離，并且他們都是瀏覽器的新特性，都存在兼容性問題，微前端方面的探索也不成熟，只能作為面向未來的微前端手段。
-
qiankun基本上可以稱為單頁版的iframe，具有沙箱隔離及資源預加載的特點，幾乎無可挑剔。但可能存在以下幾點不足：
- 對于React 深度定制項目來說，無法做到狀態(tài)管理很好的傳遞
- 對于非標準的AMD、UMD、SystemJS 等加載方式的庫會存在依賴問題(需要針對性改造)
- 多框架實現(xiàn)體積過大以及存在一定的調(diào)試成本
-
EMP作為最年輕微前端解決方案，也是吸收了許多web優(yōu)秀特性才誕生的，它在實現(xiàn)微前端的基礎(chǔ)上，擴充了跨應用狀態(tài)共享、跨框架組件調(diào)用、遠程拉取ts聲明文件、動態(tài)更新微應用等能力。同時，細心的小伙伴應該已經(jīng)發(fā)現(xiàn)，EMP能做到第三方依賴的共享，使代碼盡可能地重復利用，減少加載的內(nèi)容。
三、微前端和npm的區(qū)別
很多人會問的一個問題就是：用npm方式不香嗎？搞不懂為何要用微前端？
3.1 非常重要的痛點，使用npm包的更新流程繁瑣復雜。
第一痛點，也是非常重要的痛點，就是使用npm包的更新流程繁瑣復雜。
比如，開發(fā)三個管理后臺應用項目，將相同的業(yè)務子模塊抽離成npm包方式，這時候，如果要更新該業(yè)務子模塊的邏輯時，那么需要做以下的流程操作：
我們可以看到，該業(yè)務子模塊，隨著被使用的管理應用系統(tǒng)的增加，更新流程會疊加式得復雜起來。
而微前端可以做到一鍵更新。
具體理解就是，我們可以把復用的業(yè)務子模塊，放在同一個基站應用之中，來管理和維護，并且暴露出去可以給多個管理系統(tǒng)應用使用。如果業(yè)務子模塊需要更新邏輯的話，只需要發(fā)布部署基站應用，其他管理系統(tǒng)應用并不需要做什么操作，只需要訪問時刷新，就可以立即拿到最新的業(yè)務子模塊邏輯了。
3.2?npm包方式構(gòu)建速度慢
假如一個大型管理應用系統(tǒng)，引入了n個可復用的業(yè)務子模塊，在構(gòu)建層面來說，相當于將n個可復用的業(yè)務子模塊的代碼“復制”到了項目中，構(gòu)建的時候也需要同步去構(gòu)建這些業(yè)務子模塊，這樣一來，要構(gòu)建的體積就大大增加了，構(gòu)建時長也因此延長，開發(fā)體驗會越來越不友好，發(fā)布效率也會隨之降低。
而微前端，可以提升整個應用的構(gòu)建速度，可以在線使用其他管理系統(tǒng)應用的子模塊（或者是用基站應用維護的形式），并不需要本地構(gòu)建這些子模塊的代碼，從而減小了構(gòu)建體積，提高了開發(fā)效率。
從另一個角度，比較好的微前端方案，會解決不重復引入第三方依賴包的問題。比如上圖左側(cè)，兩個應用可能會引入多個第三方包：react、antd等。但好的微前端方案，可以做到右側(cè)引入第三方包的時候，只引入一個包版本。從這個角度來說，減少重復引入第三方依賴包，也可以提升速度。
3.3 npm方式 應用迭代麻煩
npm方式。比如我們多個后臺管理配置系統(tǒng)，使用了一些相同的資源，比如：統(tǒng)一的UI風格、移動端適配功能、通用狀態(tài)。
這時候，如果使用了npm包方式，可能給抽離成template模板，然后執(zhí)行命令或者手動去復制一個應用項目模板使用。但這種有個弊端是，如果我們對應用模板的內(nèi)容更新了，需要同步到實際已經(jīng)使用的項目的時候，就需要每個實際項目都去代碼復制，甚至需要解決沖突之類的。這樣一來，不便于我們后續(xù)的應用迭代。
而如果采用微前端共享資源方式，也就是將相同的資源全部都放在一個基站應用中，然后直接把基站應用分享出去（至少EMP微前端解決方案可以做到分享應用），管理系統(tǒng)項目再直接在分享出來的應用上進行迭代開發(fā)具體業(yè)務功能。這樣一來，由于微前端一鍵更新的優(yōu)勢，大大簡化了我們后續(xù)管理系統(tǒng)的迭代維護，甚至一開始創(chuàng)建的時候，也只需要簡單的步驟。
參考：
微前端簡介 - 簡書https://juejin.cn/post/6911496724938752007
掘金
掘金
總結(jié)
以上是生活随笔為你收集整理的125、新技术之微前端的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Raptor-水仙花数
- 下一篇： 2017年html5行业报告,云适配发布