在2020年12月05號的一個美好下午，咱們團隊在早早聊的B站直播間分享了EMP微前端---團隊半年以來的技術果實。內容比較豐富，分爲三篇文章闡述，懇請你們給EMP庫一個寶貴的star支持一下吧，感謝！！！前端
前言
你們好，今天咱們將帶來EMP微前端解決方案。看到這個名字，你們腦海裏是否會想起這些問題：EMP是個什麼？微前端又是什麼？微前端有什麼用？EMP微前端的價值點在哪裏？vue
帶着這些問題，咱們來一塊兒學習。react
首先，介紹一下咱們團隊成員。EMP微前端解決方案是一個生態，是由咱們團隊成員一塊兒開發和維護以及迭代的。而今天將由咱們三個講師，來說述EMP微前端解決方案的一些原理性知識和具體的實戰狀況。webpack
聽完此次分享，你們能夠學到什麼呢？git
能夠學到EMP微前端解決方案的腳手架以及生態的設計，給予你借鑑。github
經過這套生態的打造，EMP微前端解決方案實際應用了多個大型項目，有顯著的收益，具體的實戰項目能夠看如下列表：web
接下來，咱們將講述的內容目錄以下：npm
業務背景
咱們目前的業務是中臺業務，須要開發面向公司內部配置的toB產品，這種管理後臺系統。當須要開發愈來愈多的管理系統，咱們會發現，不少系統直接能夠有些複用的東西，好比：通用的用戶數據、UI架構風格、類似的業務邏輯等。antd
因而，咱們要解決的問題就是：如何多個應用項目直接，共享一些資源。架構
按照以往，咱們可能會選擇npm包形式，將要共享的資源抽離封裝成npm包，再給須要使用的項目引入npm包使用。可是，現在咱們有另外的一種選擇，那就是：微前端！
什麼是微前端
從Micro Frontends 官網能夠了解到，微前端概念是從微服務概念擴展而來的，摒棄大型單體方式，將前端總體分解爲小而簡單的塊，這些塊能夠獨立開發、測試和部署，同時仍然聚合爲一個產品出如今客戶面前。能夠理解微前端是一種將多個可獨立交付的小型前端應用聚合爲一個總體的架構風格。
值得留意的幾個點：
- 微前端不是一門具體的技術，而是整合了技術、策略和方法，可能會以腳手架、輔助插件和規範約束這種生態圈形式展現出來，是一種宏觀上的架構。這種架構目前有多種方案，都有利弊之處，但只要適用當前業務場景的就是好方案。
- 微前端並沒有技術棧的約束。每一套微前端方案的設計，都是基於實際需求出發。若是是多團隊統一使用了react技術棧，可能對微前端方案的跨技術棧使用並無要求；若是是多團隊同時使用了react和vue技術棧，可能就對微前端的跨技術棧要求比較高。
簡單理解，微前端改變了一種開發方式。相比於之前的每一個開發者都須要本身維護應用，共享的資源抽離成包引入，到如今使用微前端，能夠將共享的資源放在一個基站應用管理，而後其餘的開發人員在開發某業務應用的時候，能夠快速以另外一種優雅姿態從基站應用中，引入須要的資源。
具體概念學習能夠看： 什麼是微前端，能夠帶來什麼價值
微前端能夠解決什麼問題
不少人會問的一個問題就是：用npm方式不香嗎？搞不懂爲什麼要用微前端？
那麼，看完npm方式和微前端的對比以後，大概您對微前端會有比較好的認知了。
先從業務場景來講起，可能你們會接觸到上面幾種業務場景，這裏大概說一下哈。
第一種，零散的活動頁面。像這種，其實也要看狀況，好比像咱們公司內部運營須要快速的更新活動頁面，因而內部就會本身開發一套活動頁面配置系統，供運營使用，像咱們後面會說到的歡聚變色龍，就是這樣的案例，但咱們的歡聚變色龍接入了微前端，具體有什麼效益，能夠看後面分享。
第二種，外包項目。其實像外包項目前期可能會比較小型，也許前期會看不到微前端帶來的收益，可是隨時項目越作越大，其實微前端的急迫度會愈來愈大。像咱們後面分享的實戰中， YY PC客戶端項目，其實就是一個大型項目改造接入微前端的過程，從過程當中咱們能夠看到一開始接入微前端可能看不出比較大的效果，但後面隨着業務迭代，微前端帶來的效益能夠說是指數式得增加，對後面維護也是很是友好的一種方式。
第三種，中臺項目，以及第四種，大型產品項目。這兩種更不用說了，這時使用微前端的效益是會比較明顯的，帶來的收益也是可觀的。若是參與過這兩類項目的童鞋，可能對如下npm帶來的痛點有比較深入的感同身受。
接下來，咱們來經過npm方式和微前端的對比，來闡述爲何咱們要使用微前端。
第一痛點，也是很是重要的痛點，就是使用npm包的更新流程繁瑣複雜。
好比，開發三個管理後臺應用項目，將相同的業務子模塊抽離成npm包方式，這時候，若是要更新該業務子模塊的邏輯時，那麼須要作如下的流程操做：
- 更新npm包版本
- 更新A管理系統應用的npm包版本
- 發佈部署A管理系統應用
- 對B和C管理系統應用循環2和3步驟
咱們能夠看到，該業務子模塊，隨着被使用的管理應用系統的增長，更新流程會疊加式得複雜起來。
而微前端一個閃亮點，就是能夠作到一鍵更新。
具體理解就是，咱們能夠把複用的業務子模塊，放在同一個基站應用之中，來管理和維護，而且暴露出去能夠給多個管理系統應用使用。若是業務子模塊須要更新邏輯的話，只須要發佈部署基站應用，其餘管理系統應用並不須要作什麼操做，只須要訪問時刷新，就能夠當即拿到最新的業務子模塊邏輯了。想一想這種效果，是否是很棒？
npm包方式帶來的第二個痛點，就是構建速度慢。
假如一個大型管理應用系統，引入了n個可複用的業務子模塊，在構建層面來講，至關於將n個可複用的業務子模塊的代碼「複製」到了項目中，構建的時候也須要同步去構建這些業務子模塊，這樣一來，要構建的體積就大大增長了，構建時長也所以延長，開發體驗會愈來愈不友好，發佈效率也會隨之下降。
而微前端能夠很好得解決這個問題。微前端，能夠提高整個應用的構建速度，由於像某一管理應用項目，能夠在線使用其餘管理系統應用的子模塊（或者是用基站應用維護的形式），並不須要本地構建這些子模塊的代碼，從而減少了構建體積，提升了開發效率。
從另外一個角度，比較好的微前端方案，應該是會解決不重複引入第三方依賴包的問題。好比上圖左側，兩個應用可能會引入多個第三方包：react、antd等。但好的微前端方案，能夠作到右側引入第三方包的時候，只引入一個包版本。從這個角度來講，減小重複引入第三方依賴包，也能夠提高速度。
上圖是咱們對舊項目改造使用了EMP微前端方案後帶來的速度提高數據。
npm方式的第三的痛點，體如今這樣一個場景中。好比咱們多個後臺管理配置系統，使用了一些相同的資源，好比：統一的UI風格、移動端適配功能、通用狀態。
這時候，若是使用了npm包方式，可能給抽離成template模板，而後執行命令或者手動去複製一個應用項目模板使用。但這種有個弊端是，若是咱們對應用模板的內容更新了，須要同步到實際已經使用的項目的時候，就須要每一個實際項目都去代碼複製，甚至須要解決衝突之類的。這樣一來，不便於咱們後續的應用迭代。
而若是採用微前端共享資源方式，也就是將相同的資源所有都放在一個基站應用中，而後直接把基站應用分享出去（至少EMP微前端解決方案能夠作到分享應用），管理系統項目再直接在分享出來的應用上進行迭代開發具體業務功能。這樣一來，因爲微前端一鍵更新的優點，大大簡化了咱們後續管理系統的迭代維護，甚至一開始建立的時候，也只須要簡單的步驟。
微前端有哪些方案
在一開始，咱們調研了業界可能比較出名的single spa和基於此搭建完善生態的乾坤，但會發現幾個不足之處：
- 狀態方面*。qiankun 所作的微前端不能把基站項目和子項目過分隔離致使上下文不一致，共享狀態等等須要經過總線方式傳遞，十分麻煩。
- 跨框架調用實現qiankun 經過 dom 隔離的方式，使得跨框架實現十分容易，可是不能互相調用，粒度只能渲染在規定的 dom 區域。
- 體積方面。qiankun 由於是經過 dom 隔離方式實現，因此依賴共享並不完善，須要依賴於 systemjs，並且共享不方便，致使依賴可能會出現重複，使得出現體積變大。
咱們在調研的時候，學習到了webpack5 Module Federation，具體的原理學習能夠參考：webpack5 Module Federation原理
具體基於single spa以及乾坤，和EMP的對好比下：
像single spa是以來一個基座存活的，但EMP雖然提倡使用基站應用管理共享資源，但其實，每一個應用之間都是能夠共享資源的。
狀態方面。像qiankun 所作的微前端不能把基站項目和子項目過分隔離致使上下文不一致，共享狀態等等須要經過總線方式傳遞，十分麻煩。而 EMP 經過把調用遠程的狀態管理使得狀態共享十分方便。
像基於single spa的乾坤在調研之時並不能使用SSR，但基於webpack5 Module Federation的EMP是能夠支持SSR的。
另外補充：
- 跨框架調用實現。qiankun 經過 dom 隔離的方式，使得跨框架實現十分容易，可是不能互相調用，粒度只能渲染在規定的 dom 區域。EMP 實現的跨框架調用粒度到了 function ，並且使用十分方便。
- 體積方面。qiankun 由於是經過 dom 隔離方式實現，因此依賴共享並不完善，須要依賴於 systemjs，並且共享不方便，致使依賴可能會出現重複，使得出現體積變大。EMP 經過 module federation 實現依賴共享，使得依賴不會從新重複（依賴變成全局變量，相同依賴只會留下一個），因此體積會相對 qiankun 更小。
更新續文：
EMP微前端分享內容回顧（中）
EMP微前端分享內容回顧（下）