前言
今日前端早讀課由歡聚時代@吉古力授權分享。
正文從這開始~~
大家好，今天我們將帶來EMP微前端解決方案。看到這個名字，大家腦海裡是否會想起這些問題：EMP是個什麼？微前端又是什麼？微前端有什麼用？EMP微前端的價值點在哪裡？
帶著這些問題，我們來一起學習。
首先，介紹一下我們團隊成員。EMP微前端解決方案是一個生態，是由我們團隊成員一起開發和維護以及迭代的。而今天將由我們三個講師，來講述EMP微前端解決方案的一些原理性知識和具體的實戰情況。
聽完這次分享，大家可以學到什麼呢？
可以學到EMP微前端解決方案的腳手架以及生態的設計，給予你借鑑。
通過這套生態的打造，EMP微前端解決方案實際應用了多個大型項目，有顯著的收益，具體的實戰項目可以看以下列表：
接下來，我們將講述的內容目錄如下：
業務背景我們目前的業務是中臺業務，需要開發面向公司內部配置的toB產品，這種管理後臺系統。當需要開發越來越多的管理系統，我們會發現，很多系統直接可以有些復用的東西，比如：通用的用戶數據、UI架構風格、相似的業務邏輯等。
於是，我們要解決的問題就是：如何多個應用項目直接，共享一些資源。
按照以往，我們可能會選擇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-cli腳手架、格式規範插件、ts輔助插件等，後面完善了更多的場景demo和插件，推薦可以上emp庫的demo例子學習：
https://github.com/efoxTeam/emp/tree/main/projects
基於這些腳手架生態，上層的使用設計也有一定的技巧。比較推薦的使用方式是，可以搭建一個應用基站，基站內部可以放置多個項目的共享資源（組件、模塊、方法等），這些共享資源放在基站，可以讓專門的幾個人維護，確保穩定性和可靠性。其他的業務項目，比如圖中的APP1和APP2，可以使用基站資源。
另外，其實APP1和APP2項目直接，也是可以進行資源共享的。
下面是EMP生態的主要腳手架工具和插件列表：（後面不止了）
看過源碼的朋友，可以看到efoxTeam/emp庫中的emp-cli腳手架，是使用了lerna進行管理的，這種管理方式比較清晰明了，可以在project中並行執行多個項目。
@efox/emp-cli腳手架是其中比較重要的一部分，可以從上圖看到，目前emp是基於webpack5執行的，利用了webpack的chain特性，從全局項目的emp.config.js文件中讀取配置，來執行dev、build等命令。可以看到命令中有emp tsc這種更新遠程d.ts聲明文件的命令，這也是下面要提到的ts規範：
使用ts其實可以帶來上圖比較多的好處，對於一個團隊的規範來說，是友好的。所以emp是推薦大家使用ts的。
像上圖使用ts後，在業務項目中，只要執行了emp 的同步遠程的聲明文件（ emp tsc）的命令，就可以在引入組件的時候，知道組件需要傳什麼參數，返回什麼參數了。
通過emp腳手架命令，還有emp-yune-dts-plugin插件的輔助，就可以將多項目之間的聲明文件彼此同步，提升團隊協作的規範性。
使用體驗首先，我們可以來一個簡單的demo體驗。我們以react項目為demo，分別執行命令emp init創建兩個項目：react-base和react-project。
我們可以看到，react-base和react-project兩個項目下，都有一個配置文件：emp-config.js。
我們細看emp-config.js配置文件裡面的內容，其中在webpack chain中，使用了mf插件，主要的欄位如圖所示。
同時在在webpack chain中，使用了html插件，便於引入其他應用資源入口。
整理了一系列的emp教程文章，可以看wiki列表：https://github.com/efoxTeam/emp/wiki
值得期待的是，為了降低使用門檻和便於管理，我們現在正在開發GUI可視化工具。
這是GUI的項目列表圖。
GUI新建項目，會調用emp init命令去創建對應模板。
這是項目儀錶盤，便於管理單個項目。
單個項目可能引入多個基站，可以引入基站、查看基站列表和詳細信息：
GUI很快就可以和大家見面啦，敬請期待！！！
EMP實戰項目EMP在我司內部其實應用了挺多的業務項目和中臺項目，其中拿四個項目來講解一下具體的實戰過程：
PK條項目PK條是包含了業務邏輯的組件，用於顯示多人之間的pk進度，主要用到PC客戶端的內嵌頁面web項目和移動端APP的內嵌頁面web項目中。所以，我們要解決的是，pc web項目和移動端web項目之間如何共享這個組件資源。
有三種方案，一種是簡單的複製粘貼，我們就不考慮了。第二種是npm包方式，如果使用的話，需要維護一個UI庫，基於前面說到的npm包方式的痛點，也句不採用了。第三種就是我們說的EMP微前端方案。
使用EMP微前端改造的前後對比，可以將PK條這一業務邏輯組件放在遠程組件基站維護，然後暴露出來，供應用項目使用。
這是最終實現的產品效果圖，PC web項目引入該資源組件，可以傳參數自定化和修改樣式。
後面的維護，只要在遠程基站中，更新迭代PK條組件的功能，就可以同步更新到這些應用項目中，提升了更新速度，維護起來也比較方便。
cocosd遊戲項目目前cocos2d遊戲最主要的開發方式是通過官方提供的GUI圖形界面工具——creator，通過 creator 開發者無需關注構建本身，只需通過界面操作即可對遊戲代碼進行構建打包。但是這樣也存在著以下幾個問題：
構建閉源，導致開發者對項目構建無法定製化，假如編譯出來的代碼存在兼容性問題，那只能進入 creator 安裝目錄尋找對應的某個配置文件進行修改，這種侵入性的修改很有可能會引發不穩定性。無法使用其他構建工具進行打包，意味著項目無法使用新的技術方案，只能局限於 creator 設定的框架之中 遊戲組件在不同項目之間難以復用，組件通常包含了 prefab、sprite 等資源，如何發布託管並在其他項目復用組件，簡單地通過 creator 是無法做到的。發版流程繁瑣，因為開發多個cocos2d遊戲可能會復用一些資源，如果使用npm包方式抽離的話，發布流程會比較麻煩。
我們要做的第一步是，接入webpack模型，為後面微前端改造做準備。
首先看看單一 creator 的開發過程，它會在本地服務開啟 7456 的埠服務，整個本地開發流程如上圖。
接入 webpack 和 emp 後的開發過程，首先 webpack 會通過 axios 抓去 creator服務生成出來的 index.html文件作為 template，並開啟一個新的服務，並通過 devServer 將資源請求轉發回 creator的埠服務，確保資源訪問正常，開發流程圖如上圖。
於是我們成功解決了兩個痛點。
第二步，正式接入EMP微前端。
上圖是具體接入過程說明。
這是使用資源的代碼圖。
需要注意一點，cc全局變量。
通過接入EMP微前端，成功解決了剩下的兩個痛點。
這是我們的效果圖。
四. YY PC客戶端YY語音是歡聚時代旗下一款知名的集娛樂，交友，遊戲，教育等於一身，並包含移動端、web端，PC端三端的國內聊天直播軟體。
為了能夠讓用戶在產品中得到更好的體驗，同時摒棄過時技術，保持對前沿技術的探索，與時俱進，公司決定對YY PC客戶端（以下簡稱PC端）現有一些主要模板進行web改造。
改造之前，我們存在以上三點痛點。
這是改造的主要經歷，一共有三段。
第一段，改造現有項目為EMP微前端。開始改造新頻道模板的時候，用create-react-app搭建了一個普通項目進行開發和部署。但後面要繼續接新模板的時候，想要每個模板都抽離成一個個獨立部署的應用，方便專門的人維護（一個模板的邏輯很複雜很多，可以抽離成一個項目了）。於是，這時候對新頻道模板的項目進行了微前端改造，花了半天的時間。
第二段，用emp腳手架新建應用項目。在改造了新頻道模板的項目為微前端後，我們將需要用到的功能資源，全部都整和到了基站管理，然後emp init項目之後，可以直接使用基站資源，起一個新項目很是迅速。
第三段，一鍵更新多個項目，同時維護多個項目。後面，有越來越多的模板改造成一個個不同的應用項目，這時候就體驗到一鍵更新的好處了。如果多個模板的應用項目使用的共享資源需要更新，只需要更新基站，就可以很好達到我們的目的了。
這是產品效果圖。
這是我們前前後後使用EMP微前端後帶來的收益。
更詳細的YY PC客戶端實戰內容，可以看：EMP微前端實戰之YY語音PC客戶端模板重構
五. 歡聚變色龍在開發過程中，經常會遇到不同的業務方需要快速上線一些諸如協議頁、圖文介紹頁、引導頁等的靜態頁面和榜單、抽獎等動態頁面來支撐線上業務，但是無論是靜態還是動態頁面，這樣的研發和上線成本無疑是巨大的，這樣一個能夠提供讓不同業務方的產品和運營能夠快速配置活動上線的平臺的需求就油然而生了，下面列舉一些痛點：
活動上線成本
支持多語言
不同業務之間的活動組件無法復用
組件無法實現動態更新
這是效果圖。
中途有代碼展示，可以看錄屏。
更詳細關於歡聚變色龍項目實戰，可以看：歡聚變色龍落地EMP微前端
Github：https://github.com/efoxTeam/emp
關於本文作者：@吉古力原文：https://juejin.cn/post/6906683896361353230，https://juejin.cn/post/6907036258350923784，https://mp.weixin.qq.com/s/_9OzjJF9Bq43oInguLJwOQ
為你推薦
【第2078期】iframe 接班人-微前端框架 qiankun 在中後臺系統實踐
【第1929期】目標是最完善的微前端解決方案 - qiankun 2.0
點擊查看更多微前端
歡迎自薦投稿，前端早讀課等你來