關于微前端技術選型與說明

目前各產(chǎn)品均為單個獨立產(chǎn)品温眉，但后期若聚合起來成為矩陣糯俗，那如果通過單純的柔和代碼，將會打造一個巨石項目壤巷，維護成本極高媳搪，且后期迭代時會局限在單一框架內铭段，擴展性也會很差，基于以上幾點秦爆，我們基本確定后期需要使用微前端去重構項目

一序愚、為什么我們需要微前端

1. 系統(tǒng)本身是需要集成和被集成的 一般有兩種情況：

   • 舊的系統(tǒng)不能下，新的需求還在來等限。
     沒有一家商業(yè)公司會同意工程師以單純的技術升級的理由爸吮，直接下線一個有著一定用戶的存量系統(tǒng)的芬膝。而你大概又不能簡單通過 iframe 這種「靠譜的」手段完成新功能的接入，因為產(chǎn)品說需要「彈個框彈到中間」
   • 你的系統(tǒng)需要有一套支持動態(tài)插拔的機制拗胜。
     這個機制可以是一套精心設計的插件體系蔗候，但一旦出現(xiàn)接入應用或被接入應用年代夠久遠、改造成本過高的場景埂软，可能后面還是會過渡到各種微前端的玩法锈遥。

2. 系統(tǒng)中的部件具備足夠清晰的服務邊界

   • 通過微前端手段劃分服務邊界，將復雜度隔離在不同的系統(tǒng)單元中勘畔，從而避免因熵增速度不一致帶來的代碼腐化的傳染所灸，以及研發(fā)節(jié)奏差異帶來的工程協(xié)同上的問題。

二炫七、 什么是微前端

微前端是一種多個團隊通過獨立發(fā)布功能的方式來共同構建現(xiàn)代化 web 應用的技術手段及方法策略爬立。

微前端架構具備以下幾個核心價值：

• 技術棧無關
  主框架不限制接入應用的技術棧，微應用具備完全自主權

• 獨立開發(fā)万哪、獨立部署
  微應用倉庫獨立侠驯，前后端可獨立開發(fā)，部署完成后主框架自動完成同步更新

• 增量升級

  在面對各種復雜場景時奕巍，我們通常很難對一個已經(jīng)存在的系統(tǒng)做全量的技術棧升級或重構吟策，而微前端是一種非常好的實施漸進式重構的手段和策略

• 獨立運行時
  每個微應用之間狀態(tài)隔離，運行時狀態(tài)不共享

三的止、微前端技術選型

市面框架對比：

• magic-microservices 一款基于 Web Components 的輕量級的微前端工廠函數(shù)峦椰。
• icestark 阿里出品，是一個面向大型系統(tǒng)的微前端解決方案
• single-spa 是一個將多個單頁面應用聚合為一個整體應用的JavaScript 微前端框架
• qiankun 螞蟻金服出品汰规，基于 single-spa 在 single-spa 的基礎上封裝
• EMP YY出品汤功，基于Webpack5 Module Federation 除了具備微前端的能力外，還實現(xiàn)了跨應用狀態(tài)共享溜哮、跨框架組件調用的能力
• MicroApp 京東出品滔金，一款基于WebComponent的思想色解，輕量、高效餐茵、功能強大的微前端框架

綜合以上方案對比之后科阎，我們確定采用了 qiankun 特定中心路由基座式的開發(fā)方案，原因如下：

• 保證技術棧統(tǒng)一 Vue忿族、微應用之間完全獨立锣笨，互不影響。
• 友好的“微前端方案“肠阱，與技術棧無關接入簡單票唆、像iframe一樣簡單
• 改造成本低，對現(xiàn)有工程侵入度屹徘、業(yè)務線遷移成本也較低走趋。
• 和原有開發(fā)模式基本沒有不同，開發(fā)人員學習成本較低噪伊。
• qiankun 的微前端有 3 年使用場景以及 Issue 問題解決積累簿煌，社區(qū)也比較活躍，在踩坑的路上更容易自救～

四鉴吹、我們需要明確的

微前端并不是萬能的”解藥“姨伟，沒有正確治理，所有的 codebase 的歸宿都是”屎山”

1豆励、微前端的運行時容器

• qiankun 所幫我們解決的這一塊實際上是微前端的運行時容器夺荒，這是整個微前端工程化里面其中一個環(huán)節(jié)
• 從這個角度來講 qiankun 不算是一個完整的微前端解決方案，而是微前端運行時容器的一個完整解決方案良蒸，當我們用了 qiankun 之后技扼，我們幾乎能解決所有的微前端運行時容器的問題，但是更多的一些涉及工程和平臺的問題嫩痰，則需要我們去思考與處理剿吻。
• 我們的版本管控、配置下發(fā)串纺、監(jiān)控發(fā)布丽旅，安全檢測、等等這些怎么做纺棺，都不是 qiankun 作為一個庫所能解答的

2榄笙、遷移成本

對于后期將Lims、IOT等平臺接入時祷蝌，我們很難做到零成本的接入办斑，須要在開發(fā)的時候要預留足夠的踩坑，魔改代碼的時間。并且會因為前期項目不規(guī)范編碼乡翅，所產(chǎn)生的各種奇怪的兼容性問題。

3罪郊、 技術棧的選擇

• 微前端的核心不是多技術共存蠕蚜，而是分解復雜度，提升協(xié)作效率悔橄，支持靈活擴展靶累，能把“一堆復雜的事情”變成“簡單的一件事情”，但是也不是無腦使用的癣疟，每多一個技術棧都會增加：維護成本挣柬，兼容成本，資源開銷成本睛挚，這些都會無形的拖累生產(chǎn)力邪蛔。
• 基座應用與微應用之間，盡量使用相同的技術棧扎狱，相同的技術棽嗟剑可以實現(xiàn)公共依賴庫、UI庫等抽離淤击，減少資源開銷匠抗，提升加載速度，最重要的是：“減少沖突的最好方式就是統(tǒng)一”污抬，通過約束技術椆常可以盡可能的減少項目之間的沖突，減少工作量與維護成本印机。（目前我們產(chǎn)品都是使用Vue所以可以很好的去避免沖突矢腻，但由于Lims、IOT耳贬、VMC等系統(tǒng)的架構與UI設計風格差距較大踏堡，后期在接入時，如何去平衡各項目之間兼容問題是一個大問題）

4咒劲、標準化才能提升生產(chǎn)力

• 混亂的項目會拖累生產(chǎn)效率顷蟆，同時混亂的微前端也會加劇內耗，所以只有標準化才能提升生產(chǎn)力腐魂。
• 解決微前端的接入問題是最簡單的帐偎，但是微前端接入后的：工程化，應用監(jiān)控蛔屹，應用規(guī)范削樊，應用管理才是微前端中困難的地方，如果我們只是想簡單的嵌入一個應用，推薦使用Iframe解決（目前IOT項目嵌入安全即是此方案）

5漫贞、qiankun 不支持 Vite

6甸箱、qiankun并不難

• 對于qiankun的學習不用很擔心，因為 qiankun 真的很簡單滿打滿算 10個API 都沒有迅脐，但是難在創(chuàng)建基座項目與接入老項目時對各子應用的魔改
• [Link qiankun 官網(wǎng)文檔]

五芍殖、微應用拆分規(guī)則

微應用的拆與合思考：拆的是系統(tǒng)復雜度，合的是系統(tǒng)復用度 核心原則：高內聚谴蔑，低耦合

1. “盡量減少彼此的通信和依賴“豌骏，微前端的通信交互、鏈接跳轉等操作所帶來等成本其實是很大的隐锭，所以在拆分的時候盡量“完全獨立窃躲，互不依賴”

2. 微應用的拆分的時候切忌“盲目細致拆分”，過度拆分會導致 “做的很牛逼钦睡，但是沒有用的困局”蒂窒，微應用的拆分并不是一步到位的，我們要根據(jù)實際情況逐步拆分赎婚。如果一開始不知道應該劃分多細刘绣，可以先粗粒度劃分，然后隨著需求的發(fā)展挣输，逐步拆分纬凤。

   • 如：現(xiàn)在有一個售后管理系統(tǒng)，我們按業(yè)務線拆分為：客服管理撩嚼，庫存管理停士，物流管理，未來客服管理需求功能持續(xù)龐大再拆解為：智能客服完丽、電話客服恋技、在線客服。而這些客服逻族，又可以嵌入LIMS等相關項目使用蜻底。

3. 在拆分的時候我們應該盡量考慮未來場景：漸變式技術棧遷移，前端應用聚合聘鳞、多系統(tǒng)業(yè)務復用薄辅，如何做業(yè)務解耦和代碼復用。

4. 應用之間應該盡量解耦抠璃，子應用的事情就應該由子應用來做站楚。

   • 如：子應用的一些標識，如：路由前綴搏嗡，應用名稱窿春，根節(jié)點容器名稱拉一，依賴庫的使用
   • 需要明確什么是子應用應該維護的，什么是父應用應該維護的旧乞，如果什么資源都一股腦的使用父應用下發(fā)蔚润，則會導致應用之間耦合嚴重。