1. 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 的路徑代理轉發，就可以實現編譯打包一次，到處部署的目的。
2. 輕量、高效、功能強大的微前端框架-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
到此這個簡單的微應用就搭好了
覺得效果不錯的請幫忙加個關注點個贊，經常分享前端實用開發技巧
3. 什麼是後端開發，前端開發又是什麼
前端和後端是編程開發的兩個部分，前端後端都精通就是全棧開發
前端和後端是從開發者角度來說的，前端就是用戶可見部分的優化、交互功能開發，隨著軟體WEB化，Html5前端開發技術的發展，前端的技術方向越來越多，可開發解決的功能很多。
web前端有廣闊的發展空間，app、小程序、移動端、pc端等都是需要前端技術的開發支持才能夠完成，技術門檻相對較低、需求量較大，薪資待遇良好。只要是互聯網端的客戶界面，就需要前端來製作完成，前端開發的編程量不大，但是需要部分編程，入門簡單，但是要學的深入需要一個過程。
Web前端招聘崗位
• 前端開發工程師、Web開發工程師、網頁開發工程師、HTML開發工程師...
• H5開發工程師、移動應用開發工程師、App開發工程師、小程序開發工程師...
• JS開發工程師、Vue.js開發工程師、Node.js開發工程師、前端架構師...
• 小游戲開發工程師、數據可視化開發工程師、WebGL開發工程師、WebVR開 發工程師、Web安全工程師...
在互聯網行業，前端有WEB前端、HTML前端等，隨著互聯網技術發展，就業方向也有很多。web前端的就業方向有web架構師、web前端工程師、HTML前端開發工程師、網頁設計師等等。
HTML前端開發
與Web前端開發不同的是，使用HTML5不僅僅可以開發前端，還有網頁游戲，手機APP，使用瀏覽器進行3D渲染等一系列建立在HTML5標准與搭載其標准瀏覽器上的開發，而未來可能會有更多的功能分支並入HTML5標准。web前端工程師
這個方向是目前從事Web前端開發的主要就業方向
Web架構師
薪資普遍比較高，技術要求高，掌握多種技能，包括：後端技術、DBA、Platform等等，甚至包括網站優化SEO技術。
數據方向
數據研發這個是在Web開發的基礎上用數據附能，懂可視化的一定是有前端能力的，懂hadoop的一定java要熟悉，屬於Web開發的拓展方向。
大前端方向
比如阿里，在大量實踐rn和weex;由於公司內部安卓/ios式微，一定程度上，前端把ios和安卓收編了，統稱大前端。
圖形學方向
前端自然是與圖形學有千絲萬縷的聯系，除了上面提到了可視化，還有相關3d引擎的開發工作。做這一行要求也非常高了，圖形學相關的演算法，3d引擎的開發，這都需要圖形學相關知識。
4. 微前端——乾坤qiankun Demo
微前端就是將不同的功能按照不同的維度拆分成多個子應用。通過主應用來載入這些子應用。微前端的核心在於拆，拆完後在合！
我們可以將一個應用劃分成若干個子應用，將子應用打包成一個個的 lib 。當路徑切換 時載入不同的子應用。這樣每個子應用都是獨立的，技術棧也不用做限制了！從而解決了前端協同開發問題。
文檔地址： https://qiankun.umijs.org/zh
2018 年 Single-SPA 誕生了， single-spa 是一個用於前端微服務化的 JavaScript 前端解決方案 ( 本身沒有處理樣式隔離， js 執行隔離 ) 實現了路由劫持和應用載入。
2019 年 qiankun 基於 Single-SPA, 提供了更加開箱即用的 API （ single-spa + sandbox + import-html-entry ） 做到了，技術棧無關、並且接入簡單（像 i frame 一樣簡單）。
這里我們打算建立三個項目進行實操，一個Vue項目充當主應用，另一個Vue和React應用充當子應用
基座：qiankun-base 子應用：qiankun-vue、qiankun-react
react + react-router 技術棧的主應用：只需要讓子應用的 activeRule 包含主應用的這個路由即可。
vue + vue-router 技術棧的主應用:
用絕對路徑，不用用相對路徑，例如
qiankun 只能解決子項目之間的樣式相互污染，不能解決子項目的樣式污染主項目的樣式
沖突的樣式，採用BEM命名方式
子應用，需要增加 update 鉤子以便主應用手動更新微應用
主應用，直接調用子應用實例的 update 方法即可
5. single-spa微前端簡單實踐與優化思路
微前端是指存在於瀏覽器中的 微服務 。
基於iframe的微前端因為不使用所以不在本文中出現具體表現為每一個子系統的子頁面均是由iframe載入的，不同模塊的前端應用之間可以相互獨立運行
一開始就引入了多個應用的js。是把子應用直接載入到頁面中。所有的子應用都運行在同一個內存空間。
simple-single-spa-webpack-example
通過配置externals可以減小子項目打包出來的體積。 webpack外部擴展
通過 system.js 優化資源載入
入口index.html只有一個，不一次性引入所有CDN資源，可能子項目A使用而B不使用導致重復引用systemjs只是在載入index.html時注冊了這些CDN地址，不會直接去載入，當子項目里用到的時候，systemjs會接管模塊引入，再動態去載入資源。避免不同子項多餘載入。 參考demo地址
在獲取子應用的配置信息時，我們可以按照約定 path 的規則，Single-SPA 對應 entry js/html 配置可以減少載入。
6. 微前端 -- 乾坤（一）
在 toB 的前端開發工作中，我們往往就會遇到如下困境：
基座模式
通過一個主應用，來管理其它應用。設計難度小，方便實踐，但是通用度低。
自組織模式。應用之間是平等的，不存在相互管理的模式。設計難度大，不方便實施，但是通用度高。
就當前而言，基座模式實施起來比較方便，方案也是蠻多的。
注冊表模式
和微服務架構相似，不論是哪種微前端方式，都需要有一個應用注冊表的服務。這個應用注冊表擁有每個應用及對應的入口，即路由。
它可以是一個固定值的配置文件，如 JSON 文件，又或者是一個可動態更新的配置，又或者是一種動態的服務。
作用：
應用注冊。即提供新的微前端應用，向應用注冊表注冊功能。
應用發現。讓主應用可以尋找到其它應用。
首先看一下它的用法：
https://qiankun.umijs.org/zh/guide/getting-started
微前端每個應用都擁有自己的生命周期：
bootstrap， 只會在微應用初始化的時候調用一次，下次微應用重新進入時會直接調用 mount 鉤子，不會再重復觸發 bootstrap。 通常我們可以在這里做一些全局變數的初始化，比如不會在 unmount 階段被銷毀的應用級別的緩存等。
Mount，應用每次進入都會調用 mount 方法，通常我們在這里觸發應用的渲染方法
Unload，刪除應用的生命周期
Unmount，應用每次 切出/卸載 會調用的方法，通常在這里我們會卸載微應用的應用實例
乾坤，作為一款微前端領域的知名框架，其建立在single-spa基礎上。相較於single-spa，乾坤做了兩件重要的事情，其一是載入資源，第二是進行資源隔離。而資源隔離又分為Js資源隔離和css資源隔離.
每個微應用對全局的影響都會局限在微應用自己的作用域內。比如 A 應用在 window 上新增了個屬性 test，這個屬性只能在 A 應用自己的作用域通過 window.test 獲取到，主應用或者其他應用都無法拿到這個變數。
1、快照沙箱
2、支持多應用的代理沙箱
💪 HTML Entry 接入方式，讓你接入微應用像使用 iframe 一樣簡單。
在使用 single-spa 載入微應用時，我們載入的不是微應用本身，而是微應用導出的 JS 文件，即JS Entry。
要接入一個微應用，就需要對微應用進行一系列的改造，然而 JS Entry 的問題就出在這兒，改造時對微應用的侵入行太強，而且和主應用的耦合性太強。
微應用改造一般分為三步：
l 微應用路由改造，添加一個特定的前綴
l 微應用入口改造，掛載點變更和生命周期函數導出
在js文件的入口中會導出一個對象，這個對象上有 bootstrap、mount、unmount 這三個接入 single-spa 框架必須提供的生命周期方法，其中 mount 方法規定了微應用應該怎麼掛載到主應用提供的容器節點上。
l 打包工具配置更改
侵入型強其實說的就是第三點，更改打包工具的配置，使用 single-spa 接入微應用需要將微應用整個打包成一個 JS 文件，發布到靜態資源伺服器，然後在主應用中配置該 JS 文件的地址告訴 single-spa 去這個地址載入微應用。這就導致常見的打包優化基本上都沒了，比如：按需載入、首屏資源載入優化、css 獨立打包等優化措施。
項目發布以後出現了 bug ，修復之後需要更新上線，為了清除瀏覽器緩存帶來的應用，一般文件名會帶上 chunkcontent，微應用發布之後文件名都會發生變化，這時候還需要更新主應用中微應用配置，然後重新編譯主應用然後發布，這套操作簡直是不能忍受的。這也是 微前端框架 之 single-spa 從入門到精通 這篇文章中示例項目中微應用發布時的環境配置選擇 development 的原因。
qiankun 框架為了解決 JS Entry 的問題，於是採用了 HTML Entry 的方式，讓用戶接入微應用就像使用 iframe 一樣簡單。
https://github.com/sy-l123/qiankun-demo
7. 快速上手微前端框架 icestark （一）
微前端本質和後端微服務理念是一樣的，微前端解決方案一般包含如下特點
初始化 Vue 主應用
初始化 React 主應用
本地實例初始化的 Vue 主應用，運行如下
本地地址： http://localhost:3000
本地運行的官方主應用Demo,已經整合了官方提供的 Vue,React 子應用，接下來本地創建子應用，運行後分別掛在到本地啟動的主應用中
Vue 子應用
本地地址： http://localhost:3001
React 子應用
本地地址： http://localhost:3333
在主應用中注冊子應用，在主應用 App.vue 中的 onMounted 中修改 ice 注冊配置，修改 name, activePath, title, entry 這四個屬性即可
注意 activePath 指向子應用中的路由地址， entry 地址這里使用子應用啟動後的根路由地址, 也可以指向對應的子應用指定地址, 如 http://localhost:3333/react
在主應用的 BasicLayout.vue 文件中配置 el-sub-menu
單獨配置子應用路由對應主應用中的 activePath ，實現正常載入
React 子應用路由， 配置了一個 /react 路由地址
Vue 子應用路由, 配置一個 /vue 路由地址
這時候主應用的側邊欄的內容對應到本地啟動的子應用，並且能訪問就整合成功了，這時候已經本地示例實現了 icestark 框架的應用整合，應用接入，路由配置跳轉的能力。
接下來，將在本地示例中實現子應用間的路由切換（頁面跳轉）和應用互相通信。
8. 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對比一致
9. web前端和後端有哪些區別
Web前端: 顧名思義是來做Web的前端的。我們這里所說的前端泛指Web前端，也就是在Web應用中用戶可以看得見碰得著的東西。包括Web頁面的結構、Web的外觀視覺表現以及Web層面的交互實現。
Web後端：後端更多的是與資料庫進行交互以處理相應的業務邏輯。需要考慮的是如何實現功能、數據的存取、平台的穩定性與性能等。
web前端分為網頁設計師、網頁美工、web前端開發工程師。首先網頁設計師是對網頁的架構、色彩以及網站的整體頁面代碼負責網頁美工只針對UI這塊的東西，比如網站是否做的漂亮，web前端開發工程師是負責交互設計的，需要和程序員進行交互設計的配合。
web前端需要掌握的有腳本技術javascript DIV+CSS現下最流行的頁面搭建技術，ajax和jquery以及簡單的後端程序等。 後端的話可供開發的語言有 asp、php、jsp、.NET 這些後端開發語言的話搭建環境都不一樣
實際的開發過程中，前端、後端開發人員的定位如下：
前端開發人員：精通JS，能熟練應用JQuery，懂CSS，能熟練運用這些知識，進行交互效果的開發。
後端開發人員：會寫Java代碼，會寫SQL語句，能做簡單的資料庫設計，會Spring和iBatis，懂一些設計模式等。
10. 微前端前言
微前端是一種多個團隊通過獨立發布功能的方式來共同構建現代化 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/