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