咱們團隊在早早聊的B站直播間分享了EMP微前端---團隊半年以來的技術果實。分享的內容全在這裏，會講述微前端的由來，解決的問題，以及EMP微前端方案的不一樣之處，更有四個實戰項目的總結，歡迎你們一塊兒探討EMP微前端的將來。html
前言
你們好，今天咱們將帶來EMP微前端解決方案。看到這個名字，你們腦海裏是否會想起這些問題：EMP是個什麼？微前端又是什麼？微前端有什麼用？EMP微前端的價值點在哪裏？前端
帶着這些問題，咱們來一塊兒學習。vue
首先，介紹一下咱們團隊成員。EMP微前端解決方案是一個生態，是由咱們團隊成員一塊兒開發和維護以及迭代的。而今天將由咱們三個講師，來說述EMP微前端解決方案的一些原理性知識和具體的實戰狀況。react
聽完此次分享，你們能夠學到什麼呢？webpack
能夠學到EMP微前端解決方案的腳手架以及生態的設計，給予你借鑑。ios
經過這套生態的打造，EMP微前端解決方案實際應用了多個大型項目，有顯著的收益，具體的實戰項目能夠看如下列表：git
接下來，咱們將講述的內容目錄以下：github
業務背景
咱們目前的業務是中臺業務，須要開發面向公司內部配置的toB產品，這種管理後臺系統。當須要開發愈來愈多的管理系統，咱們會發現，不少系統直接能夠有些複用的東西，好比：通用的用戶數據、UI架構風格、類似的業務邏輯等。web
因而，咱們要解決的問題就是：如何多個應用項目直接，共享一些資源。npm
按照以往，咱們可能會選擇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在我司內部其實應用了挺多的業務項目和中臺項目，其中拿四個項目來說解一下具體的實戰過程：
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微前端，成功解決了剩下的兩個痛點。
這是咱們的效果圖。
詳細的cocos2d遊戲項目接入微前端，能夠看：
YY PC客戶端
YY語音是歡聚時代旗下一款知名的集娛樂，交友，遊戲，教育等於一身，幷包含移動端、web端，PC端三端的國內聊天直播軟件。
爲了可以讓用戶在產品中獲得更好的體驗，同時摒棄過期技術，保持對前沿技術的探索，與時俱進，公司決定對YY PC客戶端（如下簡稱PC端）現有一些主要模板進行web改造。
改造以前，咱們存在以上三點痛點。
這是改造的主要經歷，一共有三段。
第一段，改造現有項目爲EMP微前端。開始改造新頻道模板的時候，用create-react-app搭建了一個普通項目進行開發和部署。但後面要繼續接新模板的時候，想要每一個模板都抽離成一個個獨立部署的應用，方便專門的人維護（一個模板的邏輯很複雜不少，能夠抽離成一個項目了）。因而，這時候對新頻道模板的項目進行了微前端改造，花了半天的時間。
第二段，用emp腳手架新建應用項目。在改造了新頻道模板的項目爲微前端後，咱們將須要用到的功能資源，所有都整和到了基站管理，而後emp init項目以後，能夠直接使用基站資源，起一個新項目非常迅速。
第三段，一鍵更新多個項目，同時維護多個項目。後面，有愈來愈多的模板改形成一個個不一樣的應用項目，這時候就體驗到一鍵更新的好處了。若是多個模板的應用項目使用的共享資源須要更新，只須要更新基站，就能夠很好達到咱們的目的了。
這是產品效果圖。
這是咱們前先後後使用EMP微前端後帶來的收益。
更詳細的YY PC客戶端實戰內容，能夠看：
歡聚變色龍
在開發過程當中，常常會遇到不一樣的業務方須要快速上線一些諸如協議頁、圖文介紹頁、引導頁等的靜態頁面和榜單、抽獎等動態頁面來支撐線上業務，可是不管是靜態仍是動態頁面，這樣的研發和上線成本無疑是巨大的，這樣一個可以提供讓不一樣業務方的產品和運營可以快速配置活動上線的平臺的需求就油然而生了，下面列舉一些痛點：
- 活動上線成本
- 支持多語言
- 不一樣業務之間的活動組件沒法複用
- 組件沒法實現動態更新
這是效果圖。
中途有代碼展現，能夠看錄屏。
更詳細關於歡聚變色龍項目實戰，能夠看： 歡聚變色龍落地EMP微前端
感謝
這是咱們的開源倉庫是efoxTeam/emp，歡迎你們關注。另外，咱們的掘金團隊帳號是：Efox。