微前端究竟是什么，可以帶來(lái)什么收益
作者：Efox
https://juejin.im/post/6893307922902679560
本文將講解微前端誕生的背景，詳細(xì)解說(shuō)微前端概念的緣由以及其深入理解，讀完本文，相信你對(duì)微前端有一個(gè)比較全面的認(rèn)知，明白它可以解決您團(tuán)隊(duì)以及整個(gè)企業(yè)什么問(wèn)題，帶來(lái)怎么樣的收益。
一.背景
現(xiàn)在很多企業(yè)，基本在物理上進(jìn)行了應(yīng)用代碼隔離，實(shí)行單個(gè)應(yīng)用單個(gè)庫(kù)，閉環(huán)部署更新測(cè)試環(huán)境、預(yù)發(fā)布環(huán)境和正式環(huán)境。于是，我們的探討的是，基于不同應(yīng)用不同庫(kù)并獨(dú)立部署的情況下，如何實(shí)現(xiàn)多個(gè)應(yīng)用之間的資源共享？
之前比較多的處理方式是npm包形式抽離和引用，比如多個(gè)應(yīng)用項(xiàng)目之間，可能有某業(yè)務(wù)邏輯模塊或者其他是可復(fù)用的，便抽離出來(lái)以npm包的形式進(jìn)行管理和使用。但這樣卻帶來(lái)了以下幾個(gè)問(wèn)題：
發(fā)布效率低下。如果需要迭代npm包內(nèi)的邏輯業(yè)務(wù)，需要先發(fā)布npm包之后，再每個(gè)使用了該npm包的應(yīng)用都更新一次npm包版本，再各自構(gòu)建發(fā)布一次，過(guò)程繁瑣。如果涉及到的應(yīng)用更多的話，花費(fèi)的人力和精力就更多了。 多團(tuán)隊(duì)協(xié)作容易不規(guī)范。包含通用模塊的npm包作為共享資產(chǎn)，“每個(gè)人”擁有它，但在實(shí)踐中，這通常意味著沒(méi)有人擁有它。它很快就會(huì)充滿雜亂的風(fēng)格不一致的代碼，沒(méi)有明確的約定或技術(shù)愿景。
這些問(wèn)題讓我們意識(shí)到，擴(kuò)展前端開(kāi)發(fā)規(guī)模以便于多個(gè)團(tuán)隊(duì)可以同時(shí)開(kāi)發(fā)一個(gè)大型且復(fù)雜的產(chǎn)品是一個(gè)重要但又棘手的難題。
因此，早在2016年，微前端概念誕生了。
二. 微前端概念
Micro Frontends 官網(wǎng)定義了微前端概念：
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.
翻譯成中文：
從Micro Frontends 官網(wǎng)可以了解到，微前端概念是從微服務(wù)概念擴(kuò)展而來(lái)的，摒棄大型單體方式，將前端整體分解為小而簡(jiǎn)單的塊，這些塊可以獨(dú)立開(kāi)發(fā)、測(cè)試和部署，同時(shí)仍然聚合為一個(gè)產(chǎn)品出現(xiàn)在客戶面前。可以理解微前端是一種將多個(gè)可獨(dú)立交付的小型前端應(yīng)用聚合為一個(gè)整體的架構(gòu)風(fēng)格。
值得留意的幾個(gè)點(diǎn)：
微前端不是一門(mén)具體的技術(shù)，而是整合了技術(shù)、策略和方法，可能會(huì)以腳手架、輔助插件和規(guī)范約束這種生態(tài)圈形式展示出來(lái)，是一種宏觀上的架構(gòu)。這種架構(gòu)目前有多種方案，都有利弊之處，但只要適用當(dāng)前業(yè)務(wù)場(chǎng)景的就是好方案。 微前端并沒(méi)有技術(shù)棧的約束。每一套微前端方案的設(shè)計(jì)，都是基于實(shí)際需求出發(fā)。如果是多團(tuán)隊(duì)統(tǒng)一使用了react技術(shù)棧，可能對(duì)微前端方案的跨技術(shù)棧使用并沒(méi)有要求；如果是多團(tuán)隊(duì)同時(shí)使用了react和vue技術(shù)棧，可能就對(duì)微前端的跨技術(shù)棧要求比較高。
三. 微前端的優(yōu)勢(shì)
同步更新
對(duì)比了npm包方式抽離，讓我們意識(shí)到更新流程和效率的重要性。微前端由于是多個(gè)子應(yīng)用的聚合，如果多個(gè)業(yè)務(wù)應(yīng)用依賴同一個(gè)服務(wù)應(yīng)用的功能模塊，只需要更新服務(wù)應(yīng)用，其他業(yè)務(wù)應(yīng)用就可以立馬更新，從而縮短了更新流程和節(jié)約了更新成本。
增量升級(jí)
由于歷史包袱，有團(tuán)隊(duì)依舊存在使用著陳舊而龐大的前端單體模式，被過(guò)時(shí)的技術(shù)棧或趕工完成的代碼質(zhì)量死死拖住后腿，其程度嚴(yán)重到了讓人想推翻重寫(xiě)。為了避免完全重寫(xiě)的風(fēng)險(xiǎn)，我們更加傾向于將舊的應(yīng)用程序逐步地翻新，與此同時(shí)不受影響地繼續(xù)為我們的客戶提供新功能。
微前端能使我們更加自由地對(duì)產(chǎn)品的各個(gè)部分做出獨(dú)立的決策，讓團(tuán)隊(duì)能做到持續(xù)地增加新功能并且對(duì)原有的整體幾乎不做修改，使我們的架構(gòu)、依賴以及用戶體驗(yàn)都能夠增量升級(jí)。
另外，如果主框架中有一個(gè)非兼容性的重要更新，每個(gè)微前端可以選擇在合適的時(shí)候更新，而不是被迫中止當(dāng)前的開(kāi)發(fā)并立即更新。如果我們想要嘗試新的技術(shù)，或者是新的交互模式，對(duì)整體的影響也會(huì)更小。
簡(jiǎn)單、解耦的代碼庫(kù)
每個(gè)單獨(dú)的微前端項(xiàng)目的源代碼庫(kù)會(huì)遠(yuǎn)遠(yuǎn)小于一個(gè)單體前端項(xiàng)目的源代碼庫(kù)。這些小的代碼庫(kù)將會(huì)更易于開(kāi)發(fā)。更值得一提的是，我們避免了不相關(guān)聯(lián)的組件之間無(wú)意造成的不適當(dāng)?shù)鸟詈稀Ｍㄟ^(guò)增強(qiáng)應(yīng)用程序的邊界來(lái)減少這種意外耦合的情況的出現(xiàn)。
當(dāng)然了，一個(gè)獨(dú)立的、高級(jí)的架構(gòu)方式（例如微前端），不是用來(lái)取代規(guī)范整潔的優(yōu)秀老代碼的。我們不是想要逃避代碼優(yōu)化和代碼質(zhì)量提升。相反，我們加大做出錯(cuò)誤決策的難度，增加正確決策的可能性，從而使我們進(jìn)入成功的陷阱。例如，我們將跨邊界共享域模型變得很困難，所以開(kāi)發(fā)者不太可能這樣做。同樣，微前端會(huì)促使您明確并慎重地了解數(shù)據(jù)和事件如何在應(yīng)用程序的不同部分之間傳遞，這本是我們?cè)缇蛻?yīng)該開(kāi)始做的事情！
獨(dú)立部署
與微服務(wù)一樣，微前端的獨(dú)立可部署性是關(guān)鍵。它減少了部署的范圍，從而降低了相關(guān)風(fēng)險(xiǎn)。無(wú)論您的前端代碼在何處托管，每個(gè)微前端都應(yīng)該有自己的連續(xù)交付通道，該通道可以構(gòu)建、測(cè)試并將其一直部署到生產(chǎn)環(huán)境中。我們應(yīng)當(dāng)能夠在不考慮其他代碼庫(kù)或者是通道的情況下來(lái)部署每個(gè)微服務(wù)。做到即使原來(lái)的單體項(xiàng)目是固定的按照季度手動(dòng)發(fā)布版本，或者其他團(tuán)隊(duì)提交了未完成的或者是有問(wèn)題的代碼到他們的主分支上，也不會(huì)對(duì)當(dāng)前項(xiàng)目產(chǎn)生影響。如果一個(gè)微前端項(xiàng)目已準(zhǔn)備好投入生產(chǎn)，它應(yīng)該具備這種能力，而決定權(quán)就在構(gòu)建并且維護(hù)它的團(tuán)隊(duì)手中。
自主的團(tuán)隊(duì)
將我們的代碼庫(kù)和發(fā)布周期分離的更高階的好處，是使我們擁有了完全獨(dú)立的團(tuán)隊(duì)，可以參與到自己產(chǎn)品的構(gòu)思、生產(chǎn)及后續(xù)的過(guò)程。每個(gè)團(tuán)隊(duì)都擁有為客戶提供價(jià)值所需的全部資源，這就使得他們可以快速且有效地行動(dòng)。為了達(dá)到這個(gè)目的，我們的團(tuán)隊(duì)需要根據(jù)業(yè)務(wù)功能縱向地劃分，而不是根據(jù)技術(shù)種類(lèi)。一種簡(jiǎn)單的方法是根據(jù)最終用戶將看到的內(nèi)容來(lái)分割產(chǎn)品，因此每個(gè)微前端都封裝了應(yīng)用程序的單個(gè)頁(yè)面，并由一個(gè)團(tuán)隊(duì)全權(quán)負(fù)責(zé)。與根據(jù)技術(shù)種類(lèi)或“橫向”關(guān)注點(diǎn)（如樣式、表單或驗(yàn)證）來(lái)組成團(tuán)隊(duì)相比，這會(huì)使得團(tuán)隊(duì)工作更有凝聚力。
四. 微前端方案種類(lèi)
目前國(guó)內(nèi)微前端方案大概分為：
基座模式：通過(guò)搭建基座、配置中心來(lái)管理子應(yīng)用。如基于SIngle Spa的偏通用的乾坤方案，也有基于本身團(tuán)隊(duì)業(yè)務(wù)量身定制的方案。 自組織模式：通過(guò)約定進(jìn)行互調(diào)，但會(huì)遇到處理第三方依賴等問(wèn)題。 去中心模式：脫離基座模式，每個(gè)應(yīng)用之間都可以彼此分享資源。如基于Webpack 5 Module Federation實(shí)現(xiàn)的EMP微前端方案，可以實(shí)現(xiàn)多個(gè)應(yīng)用彼此共享資源分享。
其中，目前值得關(guān)注是去中心模式中的EMP微前端方案，既可以實(shí)現(xiàn)跨技術(shù)棧調(diào)用，又可以在相同技術(shù)棧的應(yīng)用間深度定制共享資源，如果剛開(kāi)始調(diào)研微前端的話，可以先嘗試了解一下EMP微前端方案，或許會(huì)給你帶來(lái)不錯(cuò)的使用體驗(yàn)
推薦閱讀
我的公眾號(hào)能帶來(lái)什么價(jià)值？(文末有送書(shū)規(guī)則，一定要看) 每個(gè)前端工程師都應(yīng)該了解的圖片知識(shí)(長(zhǎng)文建議收藏) 為什么現(xiàn)在面試總是面試造火箭？
“在看轉(zhuǎn)發(fā)”是最大的支持