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