前言
一個(gè)團(tuán)隊(duì)負(fù)責(zé)的項(xiàng)目（不管前后端還是全棧）建峭，隨著時(shí)間的推移，會(huì)極大的可能發(fā)生下面的變化：
1.? 單一項(xiàng)目，隨著功能的增多，會(huì)變得越來龐大
2.? 項(xiàng)目會(huì)越來越多暖璧，現(xiàn)有的人力，不足以維護(hù)當(dāng)前眾多的項(xiàng)目
3.? 隨著上述兩個(gè)問題不斷的加大挪钓，人力堆疊不可避免的產(chǎn)生
4. 人力堆疊必然會(huì)產(chǎn)生另外兩個(gè)問題：1）人的能力不同? 2）人的技術(shù)棧不同
5. 另外一個(gè)很重要的問題河质，當(dāng)人員流失產(chǎn)生的技術(shù)債務(wù)
在后端，解決上述問題比較流行的解決方案之一 ---- 微服務(wù)架構(gòu)蔑歌；
如果我們將微服務(wù)的概念擴(kuò)展到前端羹应，那么需要滿足哪些需求？
在這里我們且將前端微服務(wù)架構(gòu)叫做微前端次屠；
微前端
微前端我們希望
1. 最小程度獨(dú)立開發(fā)
2. 最小程度獨(dú)立部署
3. 輕耦合
4. 技術(shù)無關(guān)
5. 提高開發(fā)效率园匹，減少開發(fā)時(shí)間
獨(dú)立開發(fā)
細(xì)粒度開發(fā)，不論是一個(gè)大項(xiàng)目還是小項(xiàng)目劫灶，均可以拆分多個(gè)大小不一的小模塊（app）
模塊根據(jù)具體的業(yè)務(wù)場(chǎng)景偎肃，可進(jìn)行打散和重新組合
模塊與項(xiàng)目的關(guān)系可以是一對(duì)多（公用模塊）或一對(duì)一 （單業(yè)務(wù)）
獨(dú)立部署
一個(gè)單體的前端應(yīng)用最大的問題是構(gòu)建出來的前端資源文件（js,css)太大，若使用獨(dú)立開發(fā)浑此，則這些文件可以拆分成多個(gè)文件
可以按照不同的環(huán)境部署（如 CDN)
輕耦合
獨(dú)立開發(fā)中累颂，SPA的應(yīng)用開發(fā)中DOM即API
前后端數(shù)據(jù)徹底分離
數(shù)據(jù)與業(yè)務(wù)分離
技術(shù)無關(guān)
我們必須組合app模塊，若技術(shù)無關(guān)，那app可能是 angular, react, vue 等構(gòu)成
那我們可以使用以下技術(shù)：
1. 使用后端模板引擎插入 HTML（漸進(jìn)式從后端進(jìn)行加載）
2. 使用 IFrame 隔離運(yùn)行時(shí)（PostMessage)
3. 客戶端 JavaScript 異步加載
4. WebComponents 整合所有功能模塊
5. Single-SPA/Micro Frontends/Mosaic/Mooa/single-spa-angular-cli 【推薦】
6. 數(shù)據(jù)交互使用CustomEvent交互
7. 不同模塊的數(shù)據(jù)使用共享事件總線
8. 使用不同的服務(wù)器緩存（squid, varnish, nginx）紊馏，整合不同的模塊
以上種種料饥，只能更深刻說明一個(gè)觀念
微服務(wù)屬于分布式系統(tǒng)的概念之一，程式碼并不會(huì)因此變得簡(jiǎn)單朱监、短少岸啡，反而有可能為了處理外來的事件而變得更多
這似乎與我們期望的第五點(diǎn)相互矛盾，其實(shí)不然赫编；
我們期望使用微前端架構(gòu)提高個(gè)體的開發(fā)效率來相對(duì)的提高團(tuán)隊(duì)效率巡蘸；
所以我們期望：
1. 技術(shù)有關(guān)（React），盡可能的約束團(tuán)隊(duì)使用的技術(shù)棧擂送；
2. 代碼規(guī)范以及最佳實(shí)踐
3. 每個(gè)子模塊必須有自己的命名空間
4. 相關(guān)API以及工具的說明文檔
