乾坤 微前端_最全汇总之微前端知识和实战（EMP技术方案）
前言
大家好，今天我們將帶來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包方式帶來的第二個痛點，就是構建速度慢。
假如一個大型管理應用系統，引入了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游戲項目接入微前端，可以看：
《cocos2d 項目如何使用和接入EMP》
YY PC客戶端
YY語音是歡聚時代旗下一款知名的集娛樂，交友，游戲，教育等于一身，并包含移動端、web端，PC端三端的國內聊天直播軟件。
為了能夠讓用戶在產品中得到更好的體驗，同時摒棄過時技術，保持對前沿技術的探索，與時俱進，公司決定對YY PC客戶端（以下簡稱PC端）現有一些主要模板進行web改造。
改造之前，我們存在以上三點痛點。
這是改造的主要經歷，一共有三段。
第一段，改造現有項目為EMP微前端。開始改造新頻道模板的時候，用create-react-app搭建了一個普通項目進行開發和部署。但后面要繼續接新模板的時候，想要每個模板都抽離成一個個獨立部署的應用，方便專門的人維護（一個模板的邏輯很復雜很多，可以抽離成一個項目了）。于是，這時候對新頻道模板的項目進行了微前端改造，花了半天的時間。
第二段，用emp腳手架新建應用項目。在改造了新頻道模板的項目為微前端后，我們將需要用到的功能資源，全部都整和到了基站管理，然后emp init項目之后，可以直接使用基站資源，起一個新項目很是迅速。
第三段，一鍵更新多個項目，同時維護多個項目。后面，有越來越多的模板改造成一個個不同的應用項目，這時候就體驗到一鍵更新的好處了。如果多個模板的應用項目使用的共享資源需要更新，只需要更新基站，就可以很好達到我們的目的了。
這是產品效果圖。
這是我們前前后后使用EMP微前端后帶來的收益。
更詳細的YY PC客戶端實戰內容，可以看：
EMP微前端實戰之YY語音PC客戶端模板重構
歡聚變色龍
在開發過程中，經常會遇到不同的業務方需要快速上線一些諸如協議頁、圖文介紹頁、引導頁等的靜態頁面和榜單、抽獎等動態頁面來支撐線上業務，但是無論是靜態還是動態頁面，這樣的研發和上線成本無疑是巨大的，這樣一個能夠提供讓不同業務方的產品和運營能夠快速配置活動上線的平臺的需求就油然而生了，下面列舉一些痛點：
- 活動上線成本
- 支持多語言
- 不同業務之間的活動組件無法復用
- 組件無法實現動態更新
這是效果圖。
中途有代碼展示，可以看錄屏。
更詳細關于歡聚變色龍項目實戰，可以看： 歡聚變色龍落地EMP微前端
感謝
這是我們的開源倉庫是efoxTeam/emp，歡迎大家關注。另外，我們的掘金團隊賬號是：Efox。
總結
以上是生活随笔為你收集整理的乾坤 微前端_最全汇总之微前端知识和实战（EMP技术方案）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python在多个组中选一组_pytho
- 下一篇： jsp 导入java类_JSP页面导入问