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