背景

最近項(xiàng)目開(kāi)發(fā)中使用了qiankun框架去做微前端皮获，我是屬于半懂不懂的狀態(tài)，大概了解過(guò)微前端是什么痕寓，可以解決什么問(wèn)題蠢莺，但是沒(méi)有并系統(tǒng)的認(rèn)識(shí)和從0實(shí)戰(zhàn)過(guò)寒匙。

所以希望通過(guò)幾篇文章去重新認(rèn)識(shí)微前端這一架構(gòu)，主要會(huì)從幾個(gè)方面：

• 是什么浪秘，以及為什么會(huì)出現(xiàn)
• 實(shí)現(xiàn)原理蒋情，以及主流框架
• 項(xiàng)目實(shí)戰(zhàn)

發(fā)展歷程

微服務(wù)

在說(shuō)微前端之前埠况，我們需要先了解一下后端的微服務(wù)耸携，因?yàn)槲⑶岸吮旧砭褪俏∥⒎?wù)理念而產(chǎn)生的，所以我們先對(duì)微服務(wù)做一個(gè)簡(jiǎn)單的認(rèn)識(shí)：

2014年辕翰，Martin Fowler 與 James Lewis 共同提出了微服務(wù)的概念夺衍，定義了微服務(wù)是由以單一應(yīng)用程序構(gòu)成的小服務(wù)，自己擁有自己的進(jìn)程與輕量化處理喜命，服務(wù)依業(yè)務(wù)功能設(shè)計(jì)沟沙，以全自動(dòng)的方式部署，與其他服務(wù)使用HTTP API通信壁榕。同時(shí)服務(wù)會(huì)使用最小的規(guī)模的集中管理 (例如 Docker) 能力矛紫，服務(wù)可以用不同的編程語(yǔ)言與數(shù)據(jù)庫(kù)等組件實(shí)現(xiàn) —— 維基百科 微服務(wù)。

微服務(wù)架構(gòu)牌里，通常拿來(lái)對(duì)比的架構(gòu)是單體軟件架構(gòu)颊咬，單體軟件存在以下幾個(gè)問(wèn)題：

• 所有功能耦合在一起，互相影響牡辽，最終難以管理
• 哪怕只修改一行代碼喳篇，整個(gè)軟件就要重新構(gòu)建和部署，成本非常高
• 不可能每個(gè)功能單獨(dú)開(kāi)發(fā)和測(cè)試态辛，只能整體開(kāi)發(fā)和測(cè)試麸澜，導(dǎo)致必須采用瀑布式開(kāi)發(fā)模型

因此開(kāi)始出現(xiàn)將單體軟件拆成一個(gè)個(gè)功能單元服務(wù)+通訊協(xié)議組成，這種叫面向服務(wù)(service-oriented architecture奏黑，簡(jiǎn)稱 SOA)架構(gòu)炊邦，也是微服務(wù)的雛形编矾。

因此微服務(wù)架構(gòu)的等于面向服務(wù)架構(gòu)，它有多種實(shí)現(xiàn)方案馁害，其中最佳實(shí)踐是基于Docker容器實(shí)現(xiàn)的洽沟。

微服務(wù)的幾大特性：

• 敏捷性， 可快速迭代自己的微服務(wù)
• 彈性部署蜗细，快速持續(xù)集成與部署裆操，服務(wù)獨(dú)立性增加了應(yīng)用程序應(yīng)對(duì)故障的彈性
• 技術(shù)自由，可以自由選擇最佳工具來(lái)解決他們的具體問(wèn)題
• 可重復(fù)使用的代碼炉媒，可以將專為某項(xiàng)功能編寫的服務(wù)可以用作另一項(xiàng)功能的構(gòu)建塊

Ok踪区，微服務(wù)了解到這里基本上就有大概的認(rèn)知，微服務(wù)當(dāng)然不只是這些吊骤，還有一些其他技術(shù)點(diǎn)缎岗，如：服務(wù)發(fā)現(xiàn)、事件傳播等白粉。

微前端

了解完微服務(wù)传泊，那么微前端概念是什么開(kāi)始提出的呢？

微前端 這個(gè)名詞鸭巴，第一次被提出還是在2016年底眷细，那是在 ThoughtWorks Technology Radar。這個(gè)概念將微服務(wù)這個(gè)被廣泛應(yīng)用于服務(wù)端的技術(shù)范式擴(kuò)展到前端領(lǐng)域鹃祖。
微前端是一種多個(gè)團(tuán)隊(duì)通過(guò)獨(dú)立發(fā)布功能的方式來(lái)共同構(gòu)建現(xiàn)代化 web 應(yīng)用的技術(shù)手段及方法策略溪椎。 —— 微前端的完整介紹

簡(jiǎn)單的說(shuō)，微前端架構(gòu)是從微服務(wù)理念擴(kuò)展而來(lái)的恬口，一個(gè)適用于前端的微服務(wù)架構(gòu)校读。

微前端

是什么

從上面發(fā)展歷程我們對(duì)微前端架構(gòu)有個(gè)簡(jiǎn)單認(rèn)知和它的定義，接下來(lái)我們通過(guò)不同類型的做比較去對(duì)微前端做更深的認(rèn)知祖能。

單體巨石 VS 微前端

用單體巨石架構(gòu)和微前端架構(gòu)做一個(gè)比較歉秫，能更好的理解微前端架構(gòu)，具體如下圖所示：

image.png

簡(jiǎn)單的講养铸，就是將原本耦合在一起的單體巨石應(yīng)用按照一定原則拆分成各種微前端小應(yīng)用雁芙，最簡(jiǎn)單的拆分方案就是和微服務(wù)做一一映射。

組件 VS 微前端

我們?cè)購(gòu)牧硗庖粋€(gè)角度的去看待微前端揭厚，假設(shè)將微前端看做組件却特，是不是就好理解多了，只不過(guò)這個(gè)組件有點(diǎn)大筛圆，功能比較齊全裂明，沒(méi)有對(duì)外提供參數(shù)配置。

但是從兩者的實(shí)際應(yīng)用場(chǎng)景來(lái)說(shuō)，還是有很多不同的地方闽晦，具體如下：

• 從應(yīng)用場(chǎng)景來(lái)看扳碍，組件是不可運(yùn)行，被調(diào)用的仙蛉，是應(yīng)用中一部分笋敞，而微前端是完整可運(yùn)行的一個(gè)應(yīng)用
• 從技術(shù)上來(lái)看，組件是基于某個(gè)框架實(shí)現(xiàn)的荠瘪，而微前端應(yīng)用不依賴任何框架夯巷，但是微前端架構(gòu)會(huì)依賴某個(gè)框架實(shí)現(xiàn)

總結(jié)

微前端架構(gòu)，就是把復(fù)雜問(wèn)題簡(jiǎn)單化哀墓，每個(gè)微前端項(xiàng)目都只需要關(guān)心自己的事情趁餐。因此微前端架構(gòu)的核心思維如下：

• 技術(shù)不可知，每個(gè)微前端都應(yīng)該選擇自己的技術(shù)棧和技術(shù)進(jìn)化路線篮绰，而不是和其他團(tuán)隊(duì)保持一致，同時(shí)架構(gòu)師應(yīng)該考慮的是如何高效的提供可復(fù)用的WebComponent會(huì)成為核心問(wèn)題
• 環(huán)境隔離吠各，微前端架構(gòu)中每個(gè)子項(xiàng)目不共享運(yùn)行時(shí)環(huán)境，即是：不依賴共享狀態(tài)或全局變量候学，同時(shí)也可以通過(guò)命名規(guī)范（如：前綴）或命名空間，去隔離每個(gè)微前端應(yīng)用
• 原生API優(yōu)先磕瓷，使用 用于通信的原生瀏覽器事件機(jī)制 盒齿，而不是自己構(gòu)建一個(gè)PubSub系統(tǒng)
• 獨(dú)立性困食，微前端架構(gòu)中每個(gè)子項(xiàng)目是完整的翎承，可以獨(dú)立運(yùn)行硕盹、獨(dú)立開(kāi)發(fā)、獨(dú)立部署
• 高可用叨咖，微前端架構(gòu)是高可用的，即使某個(gè)子應(yīng)用異常也不會(huì)影響其他子應(yīng)用的訪問(wèn)

以上就是要實(shí)現(xiàn)微前端架構(gòu)所需要考慮的點(diǎn)垛贤，同時(shí)也是架構(gòu)中的核心思維趣倾。

缺點(diǎn)

微前端架構(gòu)在上面描述了很多優(yōu)勢(shì)，但是如果沒(méi)做好架構(gòu)設(shè)計(jì)善绎，它也可能會(huì)帶來(lái)一些問(wèn)題黔漂，因此我們需要提前了解微前端架構(gòu)可能會(huì)帶來(lái)的缺陷：

• 增加運(yùn)維成本炬守，因?yàn)橛稍局恍枰l(fā)布一個(gè)應(yīng)用剂跟，變成需要發(fā)布N個(gè)應(yīng)用
• 拆分粒度越小，架構(gòu)越復(fù)雜观蜗，開(kāi)發(fā)維護(hù)成本越高
• 微前端支持不同技術(shù)棧衣洁，那么也帶來(lái)了不同技術(shù)棧帶來(lái)技術(shù)棧混亂的風(fēng)險(xiǎn)砖第，同時(shí)也提高了開(kāi)發(fā)維護(hù)成本
• 微前端架構(gòu)本身就是將項(xiàng)目完全獨(dú)立环凿，可能導(dǎo)致部分公共代碼無(wú)法通用
• 還有一些其他問(wèn)題，如：當(dāng)采用某類微前端框架增加開(kāi)發(fā)成本等

上面這些問(wèn)題智听，在項(xiàng)目是否要用微前端架構(gòu)都需要考慮的事情，但是也有一句話可以提供給大家參考考赛。

工程就是權(quán)衡的藝術(shù)莉测，而微服務(wù)（microframeworks）架構(gòu)給你提供了一個(gè)可以權(quán)衡的維度。

了解完是什么忍抽，接下來(lái)就當(dāng)項(xiàng)目中要實(shí)施微前端架構(gòu)的時(shí)候要怎么做了董朝。

怎么做

在項(xiàng)目要實(shí)施微前端架構(gòu)，主要有幾個(gè)工作項(xiàng)：

• 首先祟绊，就是需要搞清楚如何將項(xiàng)目拆分一個(gè)個(gè)微前端子項(xiàng)目
• 其次，選型浅辙，采用哪種微前端框架去實(shí)施
• 最后阎姥，使用漸進(jìn)式方案去實(shí)施，而不是一口氣全切換泽腮，如果是新項(xiàng)目直接采用微前端架構(gòu)衣赶，那么這里推薦采用Monorepo大倉(cāng)+微前端，這里會(huì)讓極大降低項(xiàng)目的管理成本碧磅。

如何拆分

微前端架構(gòu)主要工作就是拆分遵馆，那么問(wèn)題來(lái)了，我們應(yīng)該依據(jù)什么樣的標(biāo)準(zhǔn)去拆分呢秆撮？我們大體可以從下幾點(diǎn)去考慮：

• 第一换况，拆分條件戈二，項(xiàng)目是否適合微前端架構(gòu)
• 第二，拆分原則挽拂，項(xiàng)目拆分時(shí)候需要遵循的設(shè)計(jì)原則
• 第三亏栈，拆分方法宏赘，項(xiàng)目拆分可以依據(jù)哪些因素進(jìn)行拆分

拆分條件

我們要對(duì)項(xiàng)目進(jìn)行微前端架構(gòu)設(shè)計(jì)的時(shí)候，我們應(yīng)該從下面幾方面去考慮是否適合：

• 是否有快速迭代的需求闷游，如果有快速迭代需求，則表示業(yè)務(wù)需要快速響應(yīng)休吠，那么采用微前端架構(gòu)去拆分业簿，不僅支持快速迭代，還支持業(yè)務(wù)快速試錯(cuò)
• 是否有代碼提交出現(xiàn)大量沖突柜思，如果有巷燥，則表示代碼管理成本較高，微前端架構(gòu)可以降低項(xiàng)目的管理成本
• 是否小功能需要等待大版本的場(chǎng)景陨享，如果有钝腺，則表示小功能會(huì)影響到大版本的功能拍屑，這個(gè)時(shí)候微前端架構(gòu)的獨(dú)立發(fā)布特性，可隨時(shí)回滾喷斋，風(fēng)險(xiǎn)變小蒜茴，時(shí)間變短，影響面小顽腾，從而降低大版本發(fā)布延期風(fēng)險(xiǎn)

從上面幾個(gè)方面诺核，我們可以很清晰的判斷當(dāng)前項(xiàng)目是否需要做微前端架構(gòu)調(diào)整，只有這個(gè)時(shí)候漓摩，微前端的拆分才是有確定收益的入客，增加的運(yùn)維成本才是值得的。

拆分原則

當(dāng)我們面對(duì)需要拆分微前端的時(shí)候夭咬，以下幾個(gè)原則可以作為參考：

• 單一職責(zé)原則卓舵，每個(gè)微前端只需關(guān)心自己的業(yè)務(wù)規(guī)則，確保職責(zé)單一边器，避免職責(zé)交叉
• 服務(wù)自治原則忘巧，每個(gè)微前端的開(kāi)發(fā)，必須擁有開(kāi)發(fā)十酣、測(cè)試际长、運(yùn)維、部署等整個(gè)過(guò)程虾宇，表示該應(yīng)用可以獨(dú)立運(yùn)行而不需要依賴其他應(yīng)用
• 持續(xù)演進(jìn)原則如绸，單體架構(gòu)向微服務(wù)架構(gòu)拆分過(guò)程中，無(wú)法做到一蹴而就搪泳，應(yīng)逐步拆分細(xì)化扼脐，持續(xù)演進(jìn)瓦侮，避免微服務(wù)數(shù)量的瞬間爆炸性增長(zhǎng)
• 服務(wù)粒度適中，先粗后細(xì)的原則猖毫，再按照拆分條件判斷粗粒度的微前端是否需要拆分
• 避免循環(huán)依賴须喂，循環(huán)依賴的情況會(huì)導(dǎo)致微前端在迭代發(fā)布的時(shí)候不知道優(yōu)先發(fā)布哪個(gè)，在拆分的時(shí)候需要考慮仔役，針對(duì)依賴部分進(jìn)行下沉是己，拆分成公共模塊
• 橫向拆分原則卒废，拆分微前端應(yīng)該按照依賴層次的橫向去拆，而不是縱向拆分逆皮，因?yàn)椴鸱衷缴畈胃ぃS護(hù)成本越高

拆分方法

以上兩個(gè)主要針對(duì)拆分的假設(shè)條件，當(dāng)真正去拆分操作的時(shí)候剿牺，我們應(yīng)當(dāng)從這些方面去入手：

• 按照業(yè)務(wù)領(lǐng)域环壤，參考領(lǐng)域模型郑现，將同類業(yè)務(wù)歸為同一個(gè)微前端，按照單一職責(zé)原則竹习、功能完整性進(jìn)行拆分
• 按照組織架構(gòu)列牺，應(yīng)盡量避免對(duì)組織架構(gòu)和團(tuán)隊(duì)的調(diào)整，避免由于功能的重新劃分泌辫，而增加大量且不必要的團(tuán)隊(duì)之間的溝通成本
• 按照技術(shù)棧九默，簡(jiǎn)單點(diǎn)說(shuō)React的技術(shù)棧放一個(gè)微前端驼修，Vue的技術(shù)棧放另外一個(gè)微前端
• 按需求迭代頻率诈铛，將迭代頻率高的放在一個(gè)微前端墨礁，頻率低放在另外一個(gè)微前端

學(xué)會(huì)了拆分方法恩静，里面的優(yōu)先級(jí)應(yīng)該有大概排序，業(yè)務(wù)領(lǐng)域 > 組織架構(gòu) > 技術(shù)棧 > 需求迭代頻率邑飒，我推薦的做法如下：

• 先按照業(yè)務(wù)領(lǐng)域去拆分
• 拆分的粒度不夠级乐，還要再拆分就按照組織結(jié)構(gòu)再拆分
• 再往下，就是按照技術(shù)棧拆分
• 再往下罕扎，就是需求迭代頻率

微前端框架

了解完如何拆分丐重，那么接下來(lái)就是對(duì)微前端架構(gòu)實(shí)現(xiàn)的框架進(jìn)行選型扮惦，下面是我從網(wǎng)上收集目前市場(chǎng)主流的幾大微前端框架：

• single-spa，將多個(gè)單頁(yè)面應(yīng)用聚合為一個(gè)整體應(yīng)用的 JavaScript 微前端框架
• qiankun浊仆，基于single-spa豫领，能更簡(jiǎn)單等恐、無(wú)痛構(gòu)建可用微前端架構(gòu)的框架
• 無(wú)界，基于iframe囱稽，實(shí)現(xiàn)路由同步機(jī)制的微前端架構(gòu)框架
• micro-app二跋，借鑒WebComponent思想，結(jié)合自定義的ShadowDom吞获，將微前端封裝成一個(gè)類WebComponent組件的微前端框架
• webpack 模塊聯(lián)邦，在webpack構(gòu)建時(shí)候加載遠(yuǎn)程應(yīng)用而實(shí)現(xiàn)的微前端架構(gòu)方案

以上茎刚，就是目前實(shí)現(xiàn)微前端架構(gòu)的主流框架，當(dāng)然每個(gè)框架都自己的優(yōu)缺點(diǎn)粮坞，我們?cè)谶x型的時(shí)候主要還是通過(guò)以下幾點(diǎn)去判斷是否適合：

• 對(duì)現(xiàn)有項(xiàng)目是否需要改造莫杈，改造成本多少
• 是否有學(xué)習(xí)成本，學(xué)習(xí)成本有多復(fù)雜
• 未來(lái)是否足夠的擴(kuò)展性
• 團(tuán)隊(duì)內(nèi)是否有熟悉媳叨、精通該選型的人关顷，否則遇到問(wèn)題，容易入坑
• 項(xiàng)目維護(hù)的情況痘番，issue 是否有響應(yīng)平痰，迭代是否在正常進(jìn)行

到了這里宗雇，本篇介紹微前端架構(gòu)基本上就結(jié)束了，雖然很多理論知識(shí)泌神，但是我們可以再次回顧一下嘹履，總結(jié)一下要點(diǎn)：

• 微前端架構(gòu)源自微服務(wù)架構(gòu)砾嫉，兩者主要都是為了解決巨石應(yīng)用的痛點(diǎn)，迭代慢舶沿、開(kāi)發(fā)復(fù)雜
• 微前端架構(gòu)拆分需要注意幾個(gè)點(diǎn)：拆分條件、拆分原則和拆分方法
• 微前端架構(gòu)主流框架：single-spa高镐、qiankun畸冲、無(wú)界邑闲、micro-app、webpack 模塊聯(lián)邦等

當(dāng)然州邢，我不會(huì)只寫理論知識(shí)點(diǎn)褪子，后面我會(huì)針對(duì)每個(gè)框架的寫一篇深入實(shí)戰(zhàn)文章，從背后原理呀枢，適用場(chǎng)景去一一描述渔扎，前端架構(gòu)之路不好走晃痴，希望大家一起努力加油。

其他概念

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

要了解一個(gè)新的東西泣侮，首先弄明白它解決了什么問(wèn)題紧唱？領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)主要是為了解決：

• 幫助團(tuán)隊(duì)更好理解業(yè)務(wù)世界
• 能協(xié)助開(kāi)發(fā)構(gòu)建良好的設(shè)計(jì)
• 降低業(yè)務(wù)邏輯與開(kāi)發(fā)邏輯的耦合漏益，降低復(fù)雜性

那么現(xiàn)在，我們就明白領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)是什么了铜犬？它是強(qiáng)調(diào)業(yè)務(wù)概念、專業(yè)術(shù)語(yǔ)的開(kāi)發(fā)設(shè)計(jì)理念癣猾。以下是一些官方解釋纷宇，后面在前端架構(gòu)系列文里，會(huì)寫專門文章做深入介紹：

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain-Driven Design上陕，簡(jiǎn)稱DDD）是一種強(qiáng)調(diào)業(yè)務(wù)概念作岖、專業(yè)術(shù)語(yǔ)以及原則的開(kāi)發(fā)范式痘儡，旨在幫助用戶枢步，團(tuán)隊(duì)和軟件開(kāi)發(fā)者來(lái)解決復(fù)雜的信息系統(tǒng)和軟件。它使用圖形模型作為核心矾瑰，其目標(biāo)是使開(kāi)發(fā)者能夠理解殴穴、分析和把握業(yè)務(wù)概念货葬，并將這些概念轉(zhuǎn)化為可操作的軟件⌒莅—— 【ChatGPT回答】

領(lǐng)域模型

領(lǐng)域模型磨取，來(lái)自領(lǐng)域驅(qū)動(dòng)架構(gòu)(DDD)中的一個(gè)概念柴墩，與開(kāi)發(fā)模型(解決實(shí)際問(wèn)題所抽象出來(lái)的概念模型) 設(shè)計(jì)模型(描述了所要構(gòu)建的系統(tǒng))不同的是， 領(lǐng)域模型是表達(dá)與業(yè)務(wù)相關(guān)的事實(shí)逢净，它更加關(guān)注業(yè)務(wù)知識(shí)汹胃，能否顯性化、清晰的表達(dá)業(yè)務(wù)語(yǔ)義犀农。

參考資料

-模塊聯(lián)邦在微前端架構(gòu)中的實(shí)踐
-微服務(wù)是什么宰掉？ —— 阮一峰
-微前端的完整介紹
-領(lǐng)域驅(qū)動(dòng)架構(gòu)（DDD）建模中的模型到底是什么轨奄？

更多精彩內(nèi)容，可以到個(gè)人博客訪問(wèn)：【qborfy的個(gè)人博客】挨务。