『壹』 qiankun微前端框架處理
https://blog.csdn.net/qq_41694291/article/details/113842872
概念：微前端的概念借鑒於後端的微服務，一般以業務功能為拆分單元
解決問題：大型項目的變更、擴展、維護困難的問題
總體積變大，插件可上傳cdn，但公共函數資源不便於共享
iframe ：隔離性和兼容性好，性能和使用感差（性能差因為不會有緩存，每次重新載入）
基座模式 ：基於 路由分發 ，由基座監聽路由變化，載入不同的應用，實現應用解耦，single-spa、qiankun
組合式集成 ：組件單獨打包發布，類似於npm包
EMP ：主要基於Webpack5 Mole Federation
web components ：
我們採用的是qiankun，主要思路是將一個大應用，拆分為更小的、可獨立開發、測試、部署的子應用。
傳統的大型項目：所有模塊都在一個應用里，由應用本身負責路由管理，屬於 應用分發路由 方式
拆分微應用的項目：屬於基座模式下的系統架構，各應用互相獨立，單獨運行在不同的服務上，基座（基座一般是用戶最終訪問的應用）根據路由去載入不同的應用到頁面上，即 路由分發應用 方式
微前段主要需要解決的問題有兩個
qiankun和single-spa對比
activePath與當前的hash對比一致
『貳』 阿里 qiankun 微前端框架實踐
qiankun ——— 一套完整的微前端解決方案： https://github.com/umijs/qiankun
如圖所示，在qiankun框架中，有主程序與子程序。主程序會留出指定的DOM作為子程序的容器，並且通過主程序里的路由轉發載入子應用。
修改主程序main.js注冊子應用
修改主程App.vue注冊子應用的容器
main.js
Demo： github.com/justworkhar…
與傳統的父子組件通信一樣，父程序通過props向子程序傳遞信息。子程序通過回調函數向父程序傳遞信息。
qiankun框架說白了就是通過在主程中添加一個展示子程序的DOM，經過路由判斷做轉發載入子程序。
『叄』 qiankun 微前端應用實踐與部署（四）
一般情況下，我們對應用進行配置打包，要對圖片字體等資源進行下面配置，使得資源路徑正常載入。但是，在微前端模式下，子應用打包部署後，往往會出現子應用 css 文件裡面引入資源路徑載入失敗的問題，下面就讓我們來探究一下。
👉 獨立應用下的 url-loader 配置：
因為 url-loader 的 options 項的屬性 publicPath 屬性默認是 '' ，表示相對路徑，即打包出來的資源引用 url 都會加上相對路徑尋找 static 靜態資源入口，比如：
所有應用編譯打包部署後，當主應用載入子應用，子應用載入自身的 css 文件樣式時，由於 其對應的 css 文件裡面的圖片 url 引用是相對路徑，會出現子應用的資源相對路徑拼接主應用 domain 的情況，即子應用的 ../../static/img/bg_header.790a94f4.png 會在主應用的 domain 下進行資源的尋找，導致載入失敗 404 的情況。
如果項目有用到第三方庫，比如 element-ui ，那麼就更有必要進行處理了。因為 element-ui 的字體圖標是在 css 裡面引入的，還有相關背景圖片的引入也是在 css 里，所以需要配置 webpack 的 url-loader ，生產模式情況下直接指定資源前綴，使之成為絕對路徑。
這樣配置後，打包出來的 css 樣式文件會變成：
資源是絕對路徑，就不會出現上面子應用資源載入失敗的情況。
但是，這種前端配置文件寫死路徑的做法靈活性並不好，比如不能做到編譯一次，任意部署，因為路徑寫死，所以如果需要部署到其他伺服器的話，就需要重新編譯了。
接下來，講的是實現靈活部署的方案。
我們在只編譯打包一次前端應用的前提下，為了實現靈活部署，需要藉助 nginx 來實現。
下面以 vue-cli 3 的配置為例，與 vue-cli 2 只是寫法上的區別，其他都一樣。
假設主應用部署地址是 192.168.2.192 ，子應用的部署地址是 192.168.2.192:7102 。
打包編譯部署後，子應用的 css 文件裡面的圖片資源引用 url 如下：
主應用載入子應用的時候，子應用的資源拼接主應用 domian 後，子應用的 css 文件裡面的圖片資源載入路徑 url 就會變成：
此時的關鍵就是要訪問到子應用的資源，而不是去主應用資源目錄去找。
所以我們採用 nginx 路徑代理轉發埠的方案，當應用訪問 192.168.2.192/live 這個路徑時，經過 nginx 進行路徑代理轉發配置，轉發到子應用埠。
配置 nginx 代理規則：
此時真正訪問的資源路徑（子應用資源路徑）是：
👋 至此，通過修改配置 url-loader 的 publicPath 以及配置 nginx 的路徑代理轉發，就可以實現編譯打包一次，到處部署的目的。
『肆』 qianKun + VUE 實現微前端架構 (基於vue2實現)
創建兩個項目作為實現demo，一個為主應用，一個為子應用
3.配置函數文件 microAppSetting
4.微應用出口文件 index.js
5.在App.vue內配置微應用容器及跳轉菜單
6.在main.js文件內引入微應用出口文件 index.js
7.運行後展示
8.在配置完子應用後的主應用展示
點擊子應用菜單
1.修改子應用路由文件內路由實例屬性： base 為 "/child"
2.在main.js文件內導出生命周期鉤子
3.配置Webpack、跨域與埠號
在vue.config.js內添加：
4.運行後展示
package.json
『伍』 前端微服務設計
近些年，前端發展呈百家爭鳴式發展，框架層出不窮，版本更是迭代不窮，難免會出現前端項目技術棧不統一、所用框架版本不統一的情況。
如若某些項目，沒有新的功能加入，又能線上穩定運行，但其技術棧卻用的是 vue1.0，為了將其結合到新應用中去而對其重構，成本會很高。然而，微服務可以幫我們解決這個問題。
在既不重寫原有系統的基礎之下，又可以抽出人力來開發新的業務。其不僅僅對於業務人員來說是一個相當吸引力的特性，對於技術人員來說，不重寫舊的業務，能在一些新技術上做挑戰，也是一件很有意思的事情。
除此之外，在這兩三年裡，移動應用出現了一種趨勢，用戶不想裝那麼多應用。而往往一家大的商業公司，會提供一系列的應用。這些應用也從某種程度上，反應了這家公司的組織架構。然而，在用戶的眼裡他們就是一家公司，他們就只應該有一個產品。相似的，這種趨勢也在桌面 Web 出現。聚合成為了一個技術趨勢，體現在前端的聚合就是微服務化架構。
理想的前端微服務化，應該是符合如下幾個特點：
路由分發式微前端，即通過設置路由，將不同的業務分發到不同的、獨立前端應用上。其通常可以通過 HTTP 伺服器的反向代理來實現，又或者是應用框架自帶的路由來解決。
就當前而言，通過路由分發式的微前端架構應該是採用最多、最易採用的 「微前端」 方案。但是這種方式看上去更像是多個前端應用的聚合，即我們只是將這些不同的前端應用拼湊到一起，使他們看起來像是一個完整的整體。但是，它們並不是一個完整的整體，每次用戶從 A 應用到 B 應用的時候，往往需要刷新一下頁面。
通常可通過 nginx 配置反向代理，來進行路由分發，從而實現前端微服務。
它適用於以下場景：
iframe 可以創建一個全新的獨立的宿主環境，這意味著我們的前端應用之間可以相互獨立運行。
採用 iframe 有幾個重要的前提：
即何時載入、卸載應用，如何監聽應用事件等。
不論是基於 Web Components 的 Angular，或者是 VirtualDOM 的 React 等，現有的前端框架都離不開基本的 HTML 元素 DOM。
那麼，我們只需要：
第一個問題，創建 DOM 是一個容易解決的問題。而第二個問題，則一點兒不容易，特別是移除 DOM 和相應應用的監聽。當我們擁有一個不同的技術棧時，我們就需要有針對性設計出一套這樣的邏輯。現有的框架有single-spa、qiankun、mooa等
常見的方式有：
其次，採用這種方式還有一個限制，那就是：規范！ 規范！ 規范！。在採用這種方案時，我們需要：
Web Components 組件可以擁有自己獨立的 Scripts 和 Styles，以及對應的用於單獨部署組件的域名。然而它並沒有想像中的那麼美好，要直接使用純 Web Components 來構建前端應用的難度有：
現有的微前端框架有single-spa、qiankun、mooa。其均是在前端框架之上設計通訊、載入機制來實現的。
『陸』 微前端前言
微前端是一種多個團隊通過獨立發布功能的方式來共同構建現代化 web 應用的技術手段及方法策略。
主框架不限制接入應用的技術棧，微應用具備完全自主權
微應用倉庫獨立，前後端可獨立開發，部署完成後主框架自動完成同步更新
在面對各種復雜場景時，我們通常很難對一個已經存在的系統做全量的技術棧升級或重構，而微前端是一種非常好的實施漸進式重構的手段和策略
每個微應用之間狀態隔離，運行時狀態不共享
微前端架構旨在解決單體應用在一個相對長的時間跨度下，由於參與的人員、團隊的增多、變遷，從一個普通應用演變成一個巨石應用後，隨之而來的應用不可維護的問題。這類問題在企業級 Web 應用中尤其常見。
1.url 不同步。瀏覽器刷新 iframe url 狀態丟失、後退前進按鈕無法使用。
2.UI 不同步，DOM 結構不共享。想像一下屏幕右下角 1/4 的 iframe 里來一個帶遮罩層的彈框，同時我們要求這個彈框要瀏覽器居中顯示，還要瀏覽器 resize 時自動居中。
3.全局上下文完全隔離，內存變數不共享。iframe 內外系統的通信、數據同步等需求，主應用的 cookie 要透傳到根域名都不同的子應用中實現免登效果。
4.慢。每次子應用進入都是一次瀏覽器上下文重建、資源重新載入的過程。
通過監聽 url change 事件，在路由變化時匹配到渲染的子應用並進行渲染，這個思路也是目前實現微前端的主流方式。同時single-spa要求子應用修改渲染邏輯並暴露出三個方法：bootstrap、mount、unmount，分別對應初始化、渲染和卸載，這也導致子應用需要對入口文件進行修改。過於基礎，成本太高，不建議。
qiankun是阿里推出的一個基於single-spa的微前端實現庫，旨在幫助大家能更簡單、無痛的構建一個生產可用微前端架構系統。因為是基於single-spa進行封裝，所以single-spa的特點也被qiankun繼承下來。成本低於single-spa，高於MicroApp。
MicroApp是京東推出的一款基於類WebComponent進行渲染的微前端框架，不同於目前流行的開源框架，它從組件化的思維實現微前端，旨在降低上手難度、提升工作效率。它是目前市面上接入微前端成本最低的框架，並且提供了JS沙箱、樣式隔離、元素隔離、預載入、資源地址補全、插件系統、數據通信等一系列完善的功能。是目前市面上接入微前端成本最低的方案。
single-spa github地址： https://github.com/single-spa/single-spa
qiankun官網： https://qiankun.umijs.org/zh
MicroApp官網： https://cang.org/micro-app/
『柒』 基於Vue3+TS+ElementPlus+Qiankun構建微應用項目
Hello 大家好，這里是Anyin。
最近打算把一個小型項目（小程序點餐系統）重構為微服務+微應用模式，前端的技術棧打算使用Vue3 + TS + ElementPlus + Qiankun 。這里記錄下我在構建基礎微應用的過程。
重構後的項目相關地址：
•後端： Anyin Cloud [1]
•前端基座： Anyin Cloud Parent[2]
•前端微應用： Anyin Cloud Base[3]
好了，接下來，我們來看看如何基於 Vue3+TS+ElementPlus+Qiankun 構建我們的微應用項目。
另外說下，這正銷猛里為什麼不用 Vite 進行構建，原因是 Vite 目前結合 Qiankun 構建為應用還有點問題（采坑了），所以這里就放棄了。
首先，我們使用 vue-cli 創建一個parent項目:
接著，手動選擇我們要添加的組件：
我們選擇以下組件進行應用的構建，使用空格鍵進行多選，然後回車即可：
選擇vue3.x版本
相關代碼風格、路由模式都是使用默認，css編譯我們使用less：
相關編碼規范我們使用ESLint + Airbnb Config ：
最後，完整的選項如下：
當vue-cli幫我們創建好項目，我們進入項目查看下項目目錄，如下：
首先，Qiankun的主應用是需要安裝依賴的，微應用無需安裝依賴，修改配置即可。這里我們先在主應用安裝依賴
接著，進行相關微應用配置。我們新增一個 app.ts ，用於記錄所有的微應用斗慧的入口：
然後，注冊微應用，並導出start方法
導出 start 方法之後，需要在入口處執行該方法
對於整個界面，我們希望整體的布局是這個樣子的：
所以，我們在安裝 ElementPlus 之後，需要做這樣子的布局。
首先，安裝 ElementPlus
接著，在 main.ts 引入 ElementPlus 組件，如下:
然後，創建一個布局組件 Layout.vue ，如下：
最後，在App.vue注冊該組件
運行起來呈現的效果如下：
微應用的初始化項目同主應用，這里就不詳細說明。
微應用無需依賴 Qiankun ，這里我們做一些配置即可。
在 src 目錄下新增一個 public-path.js 文件，內容如下：
在 main.ts 引入該文件
新增一個路由配置文件，這里我們創建對應的路由信息，並且兼容獨立運行，內容如下：
接著，修改 main.ts 關於實例化的代碼，如下：
這里主要是定義個渲染的方法，然後暴露舉橋Vue實例，因為等下在微應用的生命周期的鉤子會使用到。
對於微應用還需要暴露生命周期的鉤子方法，這樣子主應用才能夠識別，在 main.ts 添加如下方法：
使用 vue 創建項目是沒有 vue.config.js 文件的，這里我們手動創建一個，並且配置相關詳細，代碼如下：
•這里我們導入了 package.json 的 name 欄位，因為這里需要和主應用配置的 app.ts 文件的 name 欄位一致 • headers 添加跨域配置，因為主應用是通過 fetch 方法來獲取微應用的資源的，而微應用是啟動在另外一個埠，所以需要添加跨域配置 • output 配置了微應用的打包格式，主應用才能正確識別微應用的一些配置
還記得我們以下這個圖不？
我認為 Header 應該是屬於主應用，而下面的 Aside 和 Main 都是屬於微應用， Aside 塊一般都是用於展示菜單，個人認為各個微應用應該各自維護自己的菜單，而不是交由主應用維護。
所以，在微應用，我們還需要處理下左側的菜單布局。
我們新增一個 Layout.vue 布局文件
至此，Vue3+TS+ElementPlus+Qiankun構建微應用項目的一個基本結構我們已經處理完成，整體運行看下效果：
首頁
微應用
好了，基於 Vue3+TS+ElementPlus+Qiankun 的微應用項目基本框架我們已經搭建好了，後續就是慢慢填充一些工具和頁面了。
相關源碼地址：
•主應用： Anyin Cloud Parent
•微應用： Anyin Cloud Base
[1] Anyin Cloud : https://gitee.com/anyin/anyin-cloud
[2] Anyin Cloud Parent: https://gitee.com/anyin/anyin-cloud-parent
[3] Anyin Cloud Base: https://gitee.com/anyin/anyin-cloud-base
『捌』 輕量、高效、功能強大的微前端框架-MicroApp
這幾年後端的微服務是比較火爆，我們公司目前只要是新項目，基本上都是基於微服務去架構的，那麼微前端是什麼呢？
微前端是借鑒了微服務的架構理念，核心在於將一個龐大的前端應用拆分成多個獨立靈活的小型應用，每個應用都可以獨立開發、獨立運行、獨立部署，再將這些小型應用融合為一個完整的應用，或者將原本運行已久、沒有關聯的幾個應用融合為一個應用。微前端既可以將多個項目融合為一，又可以減少項目之間的耦合，提升項目擴展性，相比一整塊的前端倉庫，微前端架構下的前端倉庫傾向於更小更靈活
以前我們為了把幾個獨立運行的小型應用合並成一個應用都是通過iframe的方式去實現的，如果不考慮體驗問題，iframe 幾乎是最完美的微前端解決方案了。
iframe 最大的特性就是提供了瀏覽器原生的硬隔離方案，不論是樣式隔離、js 隔離這類問題統統都能被完美解決。但他的最大問題也在於他的隔離性無法被突破，導致應用間上下文無法被共享，隨之帶來的開發體驗、產品體驗的問題
micro-app不是基於iframe架構的
micro-app提供了js沙箱、樣式隔離、元素隔離、預載入、數據通信、靜態資源補全等一系列完善的開箱即用功能
micro-app沒有任何依賴
為了保證各個業務之間獨立開發、獨立部署的能力，micro-app做了諸多兼容，在任何技術框架中都可以正常運行。
下面我講一下如何在Vue中使用micro-app
1、初始化一個基座應用
2、基座應用的文件修改
main.js修改
router.js修改
3、main-page.vue頁面
4、創建一個子應用
5、子應用的router.js文件修改
6、src目錄下新建 public-path.js
7、 main.js 引入public-path.js
到此這個簡單的微應用就搭好了
覺得效果不錯的請幫忙加個關注點個贊，經常分享前端實用開發技巧